چند سال پیش، در پروژه‌ای که یک دستیار هوش مصنوعی را برای یک شرکت حقوقی طراحی می‌کردیم، با مشکلی بنیادین روبه‌رو شدیم: مدل زبانی، در پاسخ به پرسش‌های تخصصی دربارهٔ قوانین داخلی شرکت، با اعتمادبه‌نفس تمام، اطلاعات نادرست تولید می‌کرد. بعضی پاسخ‌ها شبیه قانون بودند ولی هیچ‌کدام در اسناد رسمی وجود نداشت. مسئله، نه در ضعف مدل بود و نه در کمبود دادهٔ آموزشی؛ مسئله در ماهیت مدل‌های زبانی نهفته بود: این مدل‌ها، ماشین‌های پیش‌بینی توکن بعدی هستند، نه پایگاه‌های دانش قابل‌اتکا. راه‌حل، در آن پروژه، استفاده از RAG (Retrieval-Augmented Generation یا تولید تقویت‌شده با بازیابی) بود — معماری‌ای که به مدل اجازه می‌دهد پیش از پاسخ‌دهی، اطلاعات مرتبط را از یک پایگاه دانش بیرونی بازیابی کند و پاسخ خود را بر پایه شواهد واقعی بسازد. RAG در سال‌های اخیر، از یک تکنیک تحقیقاتی به ستون فقرات اکثر سیستم‌های هوش مصنوعی سازمانی تبدیل شده است. این مقاله، تلاش می‌کند در سطح بالاترین عمق فنی، این معماری را کالبدشکافی کند.

فصل اول: RAG چیست و چرا به آن نیاز داریم؟

RAG یا Retrieval-Augmented Generation، در سادگی، معماری‌ای است که به مدل زبانی، یک حافظه بیرونی متصل می‌کند. به‌جای اینکه مدل، پاسخ را صرفاً بر اساس دانش درونی و پارامترهای آموزش‌دیده‌اش بسازد، قبل از تولید، اطلاعات مرتبط را از یک پایگاه دانش بیرونی بازیابی می‌کند و آن‌ها را در زمینه پاسخ قرار می‌دهد. این مفهوم، در سال ۲۰۲۰ در مقاله‌ای از Patrick Lewis و همکارانش در Facebook AI Research (که امروز Meta AI است) با عنوان «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» معرفی شد و از آن زمان، به یکی از پراستنادترین معماری‌های حوزه هوش مصنوعی تبدیل شده است.

سادگی مفهومی RAG، فریبنده است. در نگاه اول، RAG چیزی بیشتر از «بازیابی متن مرتبط + تزریق به prompt» به نظر نمی‌رسد. ولی در عمل، این سادگی، در سه سطح دیگر پیچیده می‌شود: سطح معماری (چند مؤلفه جدا که با هم کار می‌کنند)، سطح داده (چگونه اسناد را تکه‌تکه کنیم، چطور بردارسازی کنیم، کجا ذخیره کنیم) و سطح عملیاتی (چگونه در مقیاس، سرعت و دقت را متعادل کنیم).

سه دلیل بنیادین که RAG را ضروری می‌کند:

دلیل اول: مدل زبانی، پایگاه دانش نیست

مدل‌های زبانی، در فرآیند آموزش، حجم عظیمی از متن را دیده‌اند. ولی این متن، در قالب پارامترهای عددی ذخیره می‌شود، نه به‌صورت پایگاه داده قابل‌جستجو. نتیجه: مدل نمی‌تواند دقیقاً به‌خاطر بیاورد که «این جمله در کدام سند بوده»، فقط می‌تواند الگوهای آماری را بازتولید کند. این محدودیت، در پاسخ به سؤالات تخصصی که نیاز به دقت بالا دارند، تبدیل به یک ضعف بنیادین می‌شود.

دلیل دوم: دانش مدل، در زمان آموزش قفل می‌شود

مدل GPT-4، در یک نقطه زمانی مشخص آموزش دیده است. هر اطلاعاتی که بعد از آن تاریخ منتشر شده، در دانش مدل وجود ندارد. برای کسب‌وکارها، این یعنی مدل نمی‌تواند به آخرین قیمت‌ها، آخرین اخبار، یا آخرین تغییرات در قوانین پاسخ دهد. RAG، این محدودیت را حل می‌کند: به‌جای آموزش مجدد مدل، فقط کافی است پایگاه دانش را به‌روز نگه دارید.

دلیل سوم: مدل، دسترسی به دانش اختصاصی ندارد

اطلاعات داخلی یک شرکت — اسناد پروژه، مکالمات پشتیبانی، دانش تخصصی — در آموزش مدل وجود ندارند. آموزش مجدد مدل روی این داده‌ها، هم گران است، هم پرخطر (چون ممکن است مدل، اطلاعات را افشا کند). RAG، راه‌حل امن‌تر و سریع‌تری ارائه می‌دهد.

RAG، تلاش نمی‌کند مدل را باهوش‌تر کند؛ تلاش می‌کند مدل را متصل‌تر کند. تفاوت این دو، تفاوت میان دانش ذخیره‌شده در حافظه و دانش قابل‌دسترسی در لحظه است.

فصل دوم: سه محدودیت بنیادین LLM که RAG حل می‌کند

برای درک دقیق RAG، باید محدودیت‌هایی که آن را ضروری می‌کند، لایه‌به‌لایه باز کنیم. سه محدودیت بنیادین:

محدودیت اول: توهم‌زایی (Hallucination)

توهم‌زایی، پدیده‌ای است که در آن، مدل اطلاعات نادرست تولید می‌کند، با اعتمادبه‌نفس کامل. ریشه این پدیده، در ماهیت آموزش مدل نهفته است: مدل، آموزش دیده که توکن بعدی را با احتمال بالا پیش‌بینی کند، نه آنکه صحت اطلاعات را بررسی کند. در نتیجه، وقتی مدل در مورد موضوعی اطلاعات کافی ندارد، به‌جای گفتن «نمی‌دانم»، پاسخی با احتمال آماری بالا تولید می‌کند که ممکن است کاملاً اشتباه باشد.

در تجربه‌ام، نرخ توهم‌زایی در مدل‌های زبانی روی سؤالات عمومی حدود ۵ تا ۱۵ درصد است، ولی روی سؤالات تخصصی که مدل آموزش کافی ندیده، به بالای ۳۰ درصد هم می‌رسد. RAG با تزریق شواهد واقعی در زمینه، این نرخ را به‌طور چشمگیری کاهش می‌دهد.

محدودیت دوم: قطع دانش (Knowledge Cutoff)

هر مدل زبانی، یک تاریخ آموزش دارد. دانش مدل، در آن تاریخ متوقف می‌شود. مثلاً مدلی که تا ژانویه ۲۰۲۴ آموزش دیده، دربارهٔ رویدادهای بعد از آن تاریخ چیزی نمی‌داند. این محدودیت، در سه سناریو بحرانی می‌شود: پاسخ به سؤالات دربارهٔ رویدادهای اخیر، پاسخ به سؤالات دربارهٔ قیمت‌ها و نرخ‌های متغیر، و پاسخ به سؤالات دربارهٔ محصولات یا خدمات تازه.

راه‌حل‌های جایگزین برای این محدودیت، گران هستند: آموزش مجدد مدل (پرهزینه و زمان‌بر)، Fine-Tuning دوره‌ای (محدودتر از آن است که به‌سرعت به‌روز شود)، و RAG (به‌روزرسانی آنی، بدون آموزش).

محدودیت سوم: عدم شفافیت منبع

وقتی مدل زبانی پاسخی می‌دهد، مشخص نیست آن پاسخ از کجا آمده. برای کاربر حرفه‌ای (مثلاً پزشک، حقوقدان، یا تحلیلگر مالی)، این عدم شفافیت، یک ضعف جدی است. RAG، با تزریق اطلاعات همراه با منبع در زمینه، به مدل اجازه می‌دهد پاسخ‌هایش را با ارجاع به منبع تولید کند. این ویژگی، در کاربردهای حقوقی، پزشکی و مالی، حیاتی است.

محدودیتپیامدراه‌حل RAG
توهم‌زاییاطلاعات نادرست با اطمینان بالاتزریق شواهد واقعی در زمینه
قطع دانشعدم پاسخ به اطلاعات جدیدبه‌روزرسانی آنی پایگاه دانش
عدم شفافیتعدم امکان ردیابی منبعتولید با استناد به منبع

فصل سوم: تاریخچه و سه نسل RAG

RAG از زمان معرفی در سال ۲۰۲۰، سه نسل متمایز را طی کرده است. درک این سه نسل، برای درک اینکه امروز کجا هستیم، ضروری است:

نسل اول: Naive RAG (۲۰۲۰ تا ۲۰۲۲)

نسل اول RAG، ساده‌ترین و ابتدایی‌ترین شکل معماری است: یک Query می‌آید، Embedding آن محاسبه می‌شود، جستجوی شباهت در پایگاه داده برداری انجام می‌شود، Top-K اسناد بازیابی می‌شوند، و به Prompt تزریق می‌شوند. مدل، بر اساس این زمینه، پاسخ تولید می‌کند. مشکل اصلی این نسل، سادگی خودش بود: کیفیت پاسخ، به‌شدت وابسته به کیفیت Chunking، کیفیت Embedding Model، و کیفیت Query بود. اگر یکی از این سه لنگ می‌زد، کل پاسخ لنگ می‌زد.

نسل دوم: Advanced RAG (۲۰۲۲ تا ۲۰۲۴)

نسل دوم، با اضافه‌کردن لایه‌های قبل و بعد از بازیابی، این مشکلات را حل کرد. قبل از بازیابی: Query Rewriting، Query Expansion، Multi-Query، HyDE (Hypothetical Document Embeddings). بعد از بازیابی: Reranking، Context Compression، Context Filtering. حاصل، سیستم‌هایی بودند که هم دقت بهتری داشتند و هم انعطاف بیشتری در مواجهه با پرسش‌های متنوع.

نسل سوم: Modular RAG (۲۰۲۴ تا امروز)

نسل سوم RAG، معماری را ماژولار می‌کند: به‌جای یک Pipeline ثابت، مجموعه‌ای از ماژول‌های قابل‌ترکیب که برای هر سناریو، ترکیب متفاوتی از آن‌ها ساخته می‌شود. ماژول‌های کلیدی: Routing (انتخاب منبع مناسب برای هر پرسش)، Adaptive Retrieval (تصمیم‌گیری درباره اینکه آیا اصلاً بازیابی لازم است)، Iterative Retrieval (چند دور بازیابی برای پرسش‌های پیچیده)، و Self-Reflection (ارزیابی پاسخ‌های تولیدشده). مفاهیم پایه‌ای این نسل، در پیشرفت‌های جدید در یادگیری ماشین پوشش داده شده‌اند.

فصل چهارم: معماری کلی RAG در یک نگاه

هر سیستم RAG، صرف‌نظر از سطح پیچیدگی، از دو فاز اصلی تشکیل می‌شود: فاز Indexing (پیش از پرسش) و فاز Retrieval-Generation (در زمان پرسش). در ادامه، هر فاز را لایه‌به‌لایه باز می‌کنم.

فاز Indexing (Offline)

این فاز، یک‌بار یا به‌طور دوره‌ای انجام می‌شود و شامل پنج گام است:

  1. Document Loading: بارگذاری اسناد از منابع مختلف (PDF، HTML، Word، پایگاه داده، API).
  2. Chunking: تقسیم اسناد به قطعات کوچک‌تر قابل مدیریت.
  3. Embedding: تبدیل هر Chunk به یک بردار عددی با یک مدل Embedding.
  4. Storage: ذخیره بردارها در یک پایگاه داده برداری، همراه با Metadata.
  5. Index Building: ساخت ایندکس مناسب (HNSW، IVF، PQ و...) برای جستجوی سریع.

فاز Retrieval-Generation (Online)

این فاز، در زمان هر پرسش کاربر اجرا می‌شود و شامل چهار گام است:

  1. Query Processing: پردازش پرسش کاربر (تصحیح، گسترش، یا بازنویسی).
  2. Retrieval: جستجوی K نتیجه نزدیک‌ترین از پایگاه داده برداری.
  3. Reranking و Context Building: بازرتبه‌بندی نتایج و ساخت Context نهایی.
  4. Generation: تولید پاسخ توسط مدل زبانی، بر اساس Context.
┌──────────────────────────────────────────────────────────┐
│                     OFFLINE PHASE                         │
├──────────────────────────────────────────────────────────┤
│  Documents → Chunking → Embedding → Vector DB → Index    │
└──────────────────────────────────────────────────────────┘
                          │
                          ▼
┌──────────────────────────────────────────────────────────┐
│                     ONLINE PHASE                          │
├──────────────────────────────────────────────────────────┤
│  Query → Processing → Retrieval → Reranking → Generation │
└──────────────────────────────────────────────────────────┘

فصل پنجم: لایه Indexing — از سند خام تا بردار

فاز Indexing، در نگاه سطحی، یک Pipeline ساده به نظر می‌رسد. ولی در تجربه‌ام، تفاوت بین یک RAG موفق و ناموفق، در همین فاز نهفته است. بیایید لایه‌به‌لایه باز کنیم.

Document Loading و پردازش داده خام

مرحله اول، بارگذاری اسناد از منابع مختلف است. چالش اصلی، ناهمگونی فرمت‌هاست: PDF، HTML، Word، متن ساده، Markdown، اسناد اسکن‌شده، جداول، و حتی فایل‌های صوتی که باید تبدیل به متن شوند. در پروژه‌های واقعی، ۴۰ تا ۶۰ درصد زمان پروژه صرف همین مرحله می‌شود، نه صرف بخش‌های «هوشمند» RAG.

برای PDF، دو چالش جدی وجود دارد: PDF های متنی (که متن قابل‌استخراج دارند) و PDF های تصویری (که نیاز به OCR دارند). کتابخانه‌هایی مثل pdfplumber و PyPDF2 برای متنی، و Tesseract یا Azure Document Intelligence برای تصویری، استانداردهای این حوزه هستند. نکته مهم: در PDF های متنی با ساختار پیچیده (ستون‌های متعدد، جداول، پانویس)، استخراج متن ساده ممکن است اطلاعات ساختاری را از بین ببرد. راه‌حل، استفاده از ابزارهای ساختار-آگاه مثل Unstructured یا LlamaParse است.

پاک‌سازی و نرمال‌سازی متن

پس از استخراج، متن خام نیاز به پاک‌سازی دارد:

  • حذف Header/Footer تکراری: در PDF های چندصفحه‌ای، هر صفحه ممکن است لوگو، شماره صفحه و عنوان تکرار داشته باشد. این عناصر، اگر حذف نشوند، در Embedding اثر منفی می‌گذارند.
  • نرمال‌سازی کاراکترهای فارسی: یکسان‌سازی «ی» و «ي»، «ک» و «ك»، نیم‌فاصله، و اعداد فارسی/عربی به لاتین. این مرحله، برای اسناد فارسی حیاتی است، چون در غیر این صورت، جستجوهای معنایی دقت لازم را ندارند.
  • تصحیح شکست خطوط: در PDF ها، هر خط ممکن است به‌طور مصنوعی شکسته شود. ادغام این خطوط، کیفیت Chunking را بالا می‌برد.
  • حذف کاراکترهای کنترلی: حذف کاراکترهای غیرقابل‌چاپ که بر Embedding اثر می‌گذارند.

Metadata Extraction و Enrichment

Metadata، اطلاعاتی است که همراه با Chunk ذخیره می‌شود و در زمان بازیابی، می‌تواند برای فیلترکردن استفاده شود. Metadata های کلیدی:

  • منبع (Source): نام فایل، URL، یا شناسه سند.
  • تاریخ (Date): تاریخ ایجاد یا آخرین به‌روزرسانی.
  • نویسنده (Author): اگر در دسترس باشد.
  • دسته‌بندی (Category): نوع سند (فنی، حقوقی، بازاریابی).
  • سطح دسترسی (Access Level): برای پیاده‌سازی کنترل دسترسی.
  • زبان (Language): برای سیستم‌های چندزبانه.

در تجربه‌ام، Metadata Enrichment یکی از پراثرترین کارهایی است که به RAG اضافه می‌کنم. با فیلترهای Metadata، می‌توان دقت بازیابی را ۲۰ تا ۴۰ درصد افزایش داد — بدون تغییر در مدل Embedding یا استراتژی Chunking.

فصل ششم: Chunking — هنر تقسیم سند

Chunking، فرآیند تقسیم اسناد بلند به قطعات کوچک‌تر است. این مرحله، به‌ظاهر ساده به نظر می‌رسد، ولی در تجربه‌ام، بیشترین اثر را روی کیفیت نهایی RAG دارد. اگر Chunk ها بیش‌ازحد کوچک باشند، زمینه کافی برای فهم ندارند. اگر بیش‌ازحد بزرگ باشند، نویز زیاد می‌شود و دقت بازیابی پایین می‌آید. Chunking خوب، یک تعادل ظریف است که بسته به نوع سند، متفاوت می‌شود.

استراتژی‌های کلاسیک Chunking

استراتژی اول: Fixed-Size Chunking

ساده‌ترین و سریع‌ترین استراتژی: تقسیم متن به قطعات با طول ثابت (مثلاً ۵۱۲ توکن)، با Overlap (پوشش هم‌پوشان) برای حفظ پیوستگی. این استراتژی، در اسناد بدون ساختار روشن (مثل متن‌های توییتری یا مکالمات) مناسب است. ضعف اصلی: ممکن است یک جمله یا پاراگراف را در میانه قطع کند.

استراتژی دوم: Recursive Character Text Splitting

استراتژی پیشرفته‌تر که در LangChain پیاده‌سازی شده: به‌جای تقسیم تصادفی، ابتدا با پاراگراف (تقسیم با \n\n) شروع می‌کند، اگر قطعه از حد مجاز بزرگ‌تر بود، با خط جدید (\n)، بعد با جمله (نقطه)، و در نهایت با کاراکتر. این ترتیب، تضمین می‌کند که قطعات تا حد ممکن به‌شکل معنایی معنا داشته باشند.

استراتژی سوم: Document-Specific Chunking

هر نوع سند، ساختار خاص خودش را دارد. Chunking ساختار-آگاه، این ساختار را حفظ می‌کند:

  • Markdown و HTML: Chunking بر اساس هدرها (H1، H2، H3). هر بخش، یک Chunk مستقل.
  • کد: Chunking بر اساس توابع یا کلاس‌ها.
  • اسناد حقوقی: Chunking بر اساس ماده و تبصره.
  • مقالات علمی: Chunking بر اساس بخش (Abstract، Introduction، Methods، ...).

استراتژی چهارم: Semantic Chunking

استراتژی پیشرفته که در سال‌های اخیر محبوب شده: به‌جای تقسیم بر اساس کاراکتر یا ساختار، تقسیم بر اساس تغییر معنایی. الگوریتم کار به این شکل است: جملات متوالی، به بردار تبدیل می‌شوند. جایی که شباهت بین دو جمله متوالی افت می‌کند (یعنی تغییر موضوع رخ می‌دهد)، یک مرز Chunk است. این استراتژی، دقت بازیابی را بالا می‌برد ولی هزینه محاسباتی آن هم بالاتر است (نیاز به Embedding همه جملات در زمان Chunking).

استراتژی پنجم: Agentic Chunking و LLM-based

پیشرفته‌ترین رویکرد: استفاده از یک LLM برای تصمیم‌گیری درباره مرزهای Chunk. یعنی به مدل، سند داده می‌شود و از او خواسته می‌شود که بهترین نقاط تقسیم را پیشنهاد دهد. مزیت: دقت بالا. عیب: هزینه و زمان بسیار بالاتر.

پارامترهای کلیدی Chunking

سه پارامتر کلیدی در Chunking، که مستقیماً روی کیفیت RAG اثر می‌گذارند:

پارامتر اول: Chunk Size

انتخاب اندازه Chunk، تعادلی بین دقت و زمینه است. Chunk های کوچک (۲۵۶ توکن) دقت بالاتر ولی زمینه کمتر دارند. Chunk های بزرگ (۱۰۲۴ توکن) زمینه بیشتر ولی نویز بیشتر دارند. در تجربه‌ام، برای اکثر کاربردها، ۵۱۲ توکن نقطه شروعی خوب است. برای اسناد فنی، ۱۰۲۴ توکن بهتر جواب می‌دهد. برای پرسش-پاسخ (FAQ)، ۲۵۶ توکن کافی است.

پارامتر دوم: Chunk Overlap

Overlap، تعداد توکن‌هایی است که بین دو Chunk متوالی تکرار می‌شود. هدف: حفظ پیوستگی معنایی در مرزها. مقدار معمول: ۱۰ تا ۲۰ درصد Chunk Size. یعنی برای Chunk ۵۱۲ توکنی، Overlap بین ۵۰ تا ۱۰۰ توکن.

پارامتر سوم: Retention of Structure

حفظ ساختار سند در Chunk ها (مثلاً نگه‌داشتن عنوان بخش در ابتدای هر Chunk)، به مدل زبانی کمک می‌کند زمینه را بهتر بفهمد. یک ترفند مؤثر: پیش از Chunk متن، عنوان بخش را در ابتدای هر Chunk تکرار کنید. این کار ساده، دقت بازیابی را ۱۵ تا ۲۵ درصد افزایش می‌دهد.

Chunking پیشرفته: Multi-Level و Hierarchical

در تجربه‌ام، یک رویکرد پیشرفته که نتایج چشمگیری داده، Chunking چندسطحی است: یعنی برای هر سند، دو نوع Chunk ساخته می‌شود: Chunk های سطح پاراگراف (برای بازیابی دقیق) و Chunk های سطح سند یا فصل (برای زمینه گسترده). در زمان بازیابی، ابتدا Chunk های سطح پایین بازیابی می‌شوند، سپس Chunk سطح بالای مرتبط هم به زمینه اضافه می‌شود. این رویکرد به‌ویژه در اسناد بلند و ساختارمند، نتایج درخشانی دارد.

فصل هفتم: Embedding Models — قلب بازیابی معنایی

Embedding، تبدیل یک متن به یک بردار عددی است، به‌طوری که متون با معنای مشابه، بردارهای نزدیک داشته باشند. این بردارها، در فضایی با ابعاد بالا (معمولاً ۳۸۴ تا ۳۰۷۲ بعد) زندگی می‌کنند. Embedding Model، قلب بازیابی معنایی است — کیفیت آن، سقف کیفیت کل RAG را تعیین می‌کند.

خانواده‌های Embedding Model

خانواده اول: Bi-Encoder

Bi-Encoder، مدلی است که Query و Document را جداگانه به بردار تبدیل می‌کند. یعنی یک رمزگذار برای Query، یک رمزگذار برای Document (یا همان رمزگذار با وزن‌های مشترک). مزیت: سرعت بالا، چون بردارهای Document پیش از پرسش محاسبه می‌شوند. عیب: دقت کمتر از Cross-Encoder، چون تعامل بین Query و Document را نمی‌بیند.

معماری Bi-Encoder:

Query  → [Encoder] → q_vec (d-dim)
Doc    → [Encoder] → d_vec (d-dim)
Similarity = cosine_similarity(q_vec, d_vec)

خانواده دوم: Cross-Encoder

Cross-Encoder، مدلی است که Query و Document را با هم در یک ورودی می‌گیرد و یک امتیاز شباهت تولید می‌کند. مزیت: دقت بسیار بالاتر، چون مدل می‌تواند تعامل پیچیده بین Query و Document را مدل کند. عیب: سرعت بسیار پایین‌تر، چون برای هر جفت Query-Document، باید یک اجرای کامل مدل انجام شود. به همین دلیل، Cross-Encoder در مرحله Reranking (روی تعداد محدودی از نتایج) استفاده می‌شود، نه در بازیابی اولیه.

معماری Cross-Encoder:

[Query, Doc] → [Encoder] → score (scalar)

خانواده سوم: Late Interaction (ColBERT)

ColBERT، رویکردی میانی است: هم بردارها را از پیش محاسبه می‌کند (مثل Bi-Encoder) و هم تعامل دقیق‌تر را حفظ می‌کند (مثل Cross-Encoder). ایده اصلی: به‌جای یک بردار برای کل متن، هر توکن یک بردار جداگانه دارد. شباهت، با یک عملیات MaxSim محاسبه می‌شود: برای هر توکن Query، نزدیک‌ترین توکن در Document پیدا می‌شود و امتیاز نهایی، مجموع این نزدیک‌ترین‌ها است. این رویکرد، دقت Cross-Encoder را با سرعت Bi-Encoder ترکیب می‌کند.

مدل‌های برتر Embedding امروز

در تجربه‌ام، پنج خانواده مدل Embedding بیشترین استفاده را در پروژه‌ها داشته‌اند:

OpenAI text-embedding-3-large

مدل از OpenAI، با ابعاد ۳۰۷۲ (قابل کاهش تا ۲۵۶ بدون افت چشمگیر). کیفیت بالا، اما وابستگی به API و هزینه. مناسب برای پروژه‌هایی که وابستگی به OpenAI مشکل‌ساز نیست.

Cohere Embed v3

مدل از Cohere، با کیفیت بالا در چندزبانه. متأسفانه برای زبان فارسی، کیفیت آن در سطح رقبا نیست. مناسب زبان‌های اروپایی.

BGE-M3 (BAAI)

مدل از Beijing Academy of AI، با پشتیبانی از چند زبان از جمله فارسی. ابعاد ۱۰۲۴، کیفیت بسیار بالا. مناسب پروژه‌هایی که می‌خواهند خودشان مدل را اجرا کنند (self-hosted).

E5-Multilingual (Microsoft)

خانواده‌ای از مدل‌ها، از Small تا Large، با پشتیبانی از چند زبان. کیفیت خوب، ابعاد ۷۶۸ یا ۱۰۲۴. مناسب برای پروژه‌های همه‌منظوره.

Multilingual-MPNet (Sentence Transformers)

مدل عمومی از Sentence Transformers، پشتیبانی از ۵۰+ زبان. کیفیت متوسط ولی سبک و سریع. مناسب برای prototype یا پروژه‌های کوچک.

معیارهای ارزیابی Embedding Models

سه معیار اصلی برای ارزیابی یک Embedding Model:

  • MTEB (Massive Text Embedding Benchmark): بنچمارک جامع با ۵۶ دیتاست و ۱۱۲ زبان. امتیاز بالاتر، کیفیت بالاتر.
  • Retrieval Accuracy @ K: نسبت مواردی که پاسخ صحیح، در Top-K نتایج بازیابی شده.
  • Latency و Throughput: سرعت Embedding در مقیاس تولید.

نکته مهم در انتخاب: همیشه کیفیت را روی داده واقعی خودتان بسنجید. معیارهای عمومی، راهنما هستند ولی تصمیم نهایی باید بر پایه داده‌های اختصاصی باشد. برای درک عمیق‌تر مبانی این حوزه، مرور یادگیری ماشین در پردازش زبان طبیعی و معماری ترنسفورمر مفید است.

Fine-Tuning Embedding Models

برای دامنه‌های خاص (مثلاً حقوقی، پزشکی، فنی)، مدل‌های عمومی Embedding ممکن است دقت کافی نداشته باشند. راه‌حل: Fine-Tuning مدل روی داده اختصاصی. سه رویکرد:

  • Contrastive Learning: آموزش مدل با جفت‌های (Query, Positive Document) و (Query, Negative Document). تکنیک اصلی در آموزش مدل‌های Embedding.
  • Hard Negative Mining: انتخاب Negative Sample ها از میان موارد نزدیک ولی نادرست. کلید بهبود کیفیت.
  • In-batch Negatives: استفاده از نمونه‌های دیگر در همان Batch به‌عنوان Negative. تکنیک کم‌هزینه و مؤثر.

در پروژه‌ای حقوقی، Fine-Tuning مدل Embedding روی جفت‌های (پرسش حقوقی، ماده قانونی)، دقت بازیابی را از ۶۵ درصد به ۸۹ درصد رساند. هزینه این بهبود: چند روز کار و چند GPU ساعت. ارزشش را داشت.

فصل هشتم: Vector Databases — ذخیره و بازیابی در مقیاس

پایگاه‌های داده برداری، برای ذخیره میلیون‌ها یا میلیاردها بردار، و جستجوی سریع نزدیک‌ترین‌ها (Approximate Nearest Neighbor یا ANN) طراحی شده‌اند. این پایگاه‌ها، جایگزین پایگاه‌های داده سنتی در سیستم‌های RAG هستند.

الگوریتم‌های ANN

جستجوی دقیق نزدیک‌ترین همسایه (Exact KNN) در ابعاد بالا و مقیاس بزرگ، بسیار کند است. الگوریتم‌های ANN، با پذیرش مقداری خطا، سرعت را چند مرتبه بزرگ‌تر می‌کنند. سه خانواده اصلی:

خانواده اول: HNSW (Hierarchical Navigable Small World)

محبوب‌ترین الگوریتم ANN، که در اکثر پایگاه‌های داده برداری مدرن استفاده می‌شود. ایده: ساختن یک گراف چندلایه که لایه‌های بالا، گره‌های کمتری دارند (برای پرش‌های بزرگ) و لایه‌های پایین، گراف کامل‌تری دارند (برای جستجوی دقیق). جستجو، از لایه بالا شروع می‌شود و به‌تدریج به لایه‌های پایین می‌رود.

پارامترهای کلیدی HNSW:

  • M: حداکثر تعداد اتصالات هر گره. مقدار بالاتر، دقت بیشتر ولی حافظه بیشتر. معمولاً ۱۶ تا ۶۴.
  • ef_construction: اندازه صف در زمان ساخت. مقدار بالاتر، کیفیت ایندکس بهتر. معمولاً ۱۰۰ تا ۵۰۰.
  • ef_search: اندازه صف در زمان جستجو. مقدار بالاتر، دقت بیشتر ولی سرعت کمتر. معمولاً ۵۰ تا ۲۰۰.

خانواده دوم: IVF (Inverted File Index)

الگوریتمی که ابتدا بردارها را با K-Means به چند Cluster تقسیم می‌کند و در زمان جستجو، فقط Cluster های نزدیک به Query را بررسی می‌کند. مزیت: مصرف حافظه کمتر. عیب: دقت کمتر از HNSW، به‌ویژه در توزیع‌های پیچیده.

خانواده سوم: PQ (Product Quantization)

الگوریتمی که بردارها را فشرده می‌کند تا مصرف حافظه کاهش یابد. ایده: هر بردار به چند زیر-بردار تقسیم می‌شود، و هر زیر-بردار با نزدیک‌ترین Centroid جایگزین می‌شود. این رویکرد، حافظه را ۱۰ تا ۱۰۰ برابر کاهش می‌دهد، با قیمت افت دقت. مناسب مقیاس‌های بزرگ که حافظه محدود است.

پایگاه‌های داده برداری برتر

Pinecone

پایگاه داده ابری، بدون نیاز به مدیریت زیرساخت. کیفیت بالا، مقیاس‌پذیری عالی. مناسب برای پروژه‌های سازمانی با بودجه.

Weaviate

متن‌باز، با پشتیبانی از Hybrid Search داخلی، Multi-tenancy، و ماژول‌های Embedding. مناسب برای پروژه‌های self-hosted.

Qdrant

متن‌باز، نوشته‌شده در Rust. سرعت بالا، مصرف حافظه کمتر از رقبا. مناسب برای پروژه‌هایی که Performance حیاتی است.

Milvus

متن‌باز، طراحی‌شده برای مقیاس‌های بسیار بزرگ (میلیاردها بردار). پیچیدگی راه‌اندازی بالاتر. مناسب سازمان‌های بزرگ.

Chroma

سبک، مناسب برای prototype و پروژه‌های کوچک. راه‌اندازی ساده. مناسب توسعه اولیه.

pgvector (PostgreSQL Extension)

افزونه PostgreSQL برای ذخیره بردارها. مزیت: استفاده از پایگاه داده موجود، بدون نیاز به سرویس جدید. مناسب پروژه‌هایی که از قبل PostgreSQL دارند.

مقایسه‌ای عملی

پایگاه دادهخودمیزبانیمقیاسHybridمناسب برای
Pineconeخیرمیلیاردبلهسازمانی
Weaviateبلهصد میلیونبلهپروژه‌های عملیاتی
Qdrantبلهصد میلیونبلهPerformance-محور
Milvusبلهمیلیاردبلهمقیاس سازمانی
ChromaبلهمیلیونمحدودPrototype
pgvectorبلهمیلیونبا ترکیبپروژه‌های کوچک

فصل نهم: Sparse Retrieval و BM25

در کنار بازیابی نهفته (Dense Retrieval)، یک رویکرد کلاسیک دیگر وجود دارد که هنوز هم نقش کلیدی در RAG ایفا می‌کند: بازیابی تنک (Sparse Retrieval). این رویکرد، بر پایه تطبیق کلمات کار می‌کند، نه بر پایه شباهت معنایی.

BM25 — استاندارد طلایی Sparse Retrieval

BM25 (Best Matching 25)، یکی از مشهورترین الگوریتم‌های رتبه‌بندی متن است که از دهه ۹۰ میلادی تا امروز، استاندارد Sparse Retrieval بوده. فرمول BM25:

score(q, d) = Σ IDF(q_i) · (f(q_i, d) · (k1 + 1)) / (f(q_i, d) + k1 · (1 - b + b · |d| / avgdl))

IDF(q_i) = log((N - n(q_i) + 0.5) / (n(q_i) + 0.5) + 1)

در این فرمول:

  • f(q_i, d) = تعداد تکرار کلمه q_i در سند d
  • |d| = طول سند d
  • avgdl = میانگین طول اسناد
  • N = تعداد کل اسناد
  • n(q_i) = تعداد اسنادی که شامل q_i هستند
  • k1 و b = پارامترهای تنظیم‌شدنی (k1 ≈ 1.2 تا 2.0، b ≈ 0.75)

BM25 از دو ایده کلیدی استفاده می‌کند: TF (Term Frequency) به‌صورت اشباع‌شدنی (یعنی تکرار بی‌پایان کلمه، امتیاز بی‌پایان نمی‌دهد) و IDF (Inverse Document Frequency) که کلمات کمیاب را مهم‌تر می‌شود.

مزایای Sparse Retrieval

  • دقت در تطبیق دقیق: اگر Query شامل یک کلمه تخصصی باشد (مثلاً «قانون تجارت ماده ۱۲»)، Sparse Retrieval آن را دقیق پیدا می‌کند.
  • شفافیت: می‌توان فهمید چرا یک سند بازیابی شد (به دلیل کدام کلمات).
  • سرعت: معمولاً سریع‌تر از Dense Retrieval روی حجم‌های بزرگ.
  • عدم نیاز به آموزش: به‌طور معمول آماده استفاده است.

محدودیت‌های Sparse Retrieval

  • عدم تطبیق معنایی: Query «چطور رمز عبورم را بازیابی کنم» نمی‌تواند سندی را پیدا کند که فقط «بازیابی حساب کاربری» نوشته.
  • حساسیت به زبان: با تغییرات نگارشی، کارایی افت می‌کند (مثلاً «میروم» و «می‌روم» دو کلمه متفاوت دیده می‌شوند).
  • پرفضاوت با کلمات مشترک: کلمات متداول، امتیاز کم می‌گیرند، ولی گاهی حامل معنای کلیدی هستند.

Sparse Retrieval مدرن: SPLADE

SPLADE (Sparse Lexical and Expansion)، رویکردی است که Sparse Retrieval را با یادگیری عمیق ترکیب می‌کند. ایده: به‌جای بردار تنک باینری (0/1) برای هر کلمه، یک بردار تنک با وزن‌های یادگیری‌شده تولید می‌شود. مزیت: هم تطبیق دقیق Sparse را حفظ می‌کند و هم به سمت گسترش معنایی حرکت می‌کند.

فصل دهم: Hybrid Search — ترکیب قدرت‌های دو دنیا

Dense و Sparse Retrieval، هر کدام نقاط قوت و ضعف خود را دارند. Hybrid Search، ترکیب این دو رویکرد است تا از نقاط قوت هر دو استفاده کند. این رویکرد، در تجربه‌ام، یکی از پراثرترین بهبودها در RAG است.

الگوهای ترکیب

الگوی اول: RRF (Reciprocal Rank Fusion)

ساده‌ترین و پرکاربردترین روش ترکیب. ایده: هر روش بازیابی، یک لیست رتبه‌بندی می‌دهد. RRF، امتیاز نهایی هر سند را بر اساس رتبه آن در هر لیست محاسبه می‌کند:

RRF_score(d) = Σ 1 / (k + rank_i(d))

که k معمولاً ۶۰ است. مزیت: نیازی به نرمال‌سازی امتیازها بین دو روش ندارد. عیب: اطلاعات وزن امتیاز از دست می‌رود (فقط رتبه اهمیت دارد).

الگوی دوم: Weighted Sum

در این روش، امتیازها ابتدا نرمال می‌شوند (مثلاً با Min-Max یا Z-Score) و بعد با وزن‌های مشخص با هم ترکیب می‌شوند:

combined_score(d) = α · dense_score(d) + (1 - α) · sparse_score(d)

انتخاب α، تصمیم مهمی است. در تجربه‌ام، مقدار ۰.۵ تا ۰.۷ برای اکثر کاربردها مناسب است، ولی در دامنه‌های تخصصی (مثلاً حقوقی) با اصطلاحات دقیق، مقدار پایین‌تر (۰.۳ تا ۰.۵) بهتر جواب می‌دهد.

الگوی سوم: Cascade Reranking

در این روش، ابتدا Sparse Retrieval اجرا می‌شود (سریع)، سپس Dense Retrieval روی نتایج اجرا می‌شود (دقیق‌تر)، و در نهایت RRF یا ترکیب نهایی اعمال می‌شود. مزیت: تعادل سرعت و دقت.

پیاده‌سازی Hybrid Search در عمل

اکثر پایگاه‌های داده برداری مدرن (Weaviate، Qdrant، Milvus)، Hybrid Search را به‌طور داخلی پشتیبانی می‌کنند. یعنی کافی است Query را با هر دو نوع بردار بفرستید و پایگاه، نتایج ترکیبی را برگرداند. در غیر این صورت، ترکیب باید در لایه اپلیکیشن انجام شود.

فصل یازدهم: Query Transformation — وقتی پرسش خام کافی نیست

در بسیاری از موارد، پرسش کاربر به‌شکلی که نوشته شده، بهترین شکل برای جستجو نیست. کاربر ممکن است پرسش را مبهم، کوتاه، یا با کلمات متفاوت از اسناد بیان کند. Query Transformation، مجموعه‌ای از تکنیک‌ها برای بهبود پرسش پیش از بازیابی است.

تکنیک اول: Query Rewriting

ساده‌ترین تکنیک: بازنویسی پرسش با یک LLM برای شفاف‌سازی. مثلاً «اون قانونی که درباره مالیات بود» به «ماده قانونی مربوط به مالیات بر ارزش افزوده» بازنویسی می‌شود.

تکنیک دوم: Query Expansion

گسترش پرسش با کلمات مترادف یا مرتبط. مثلاً «خودرو» به «خودرو، ماشین، اتومبیل، وسیله نقلیه» گسترش می‌یابد. این تکنیک، Sparse Retrieval را بهبود می‌دهد.

تکنیک سوم: Multi-Query

تولید چند نسخه از پرسش، اجرای بازیابی برای هر کدام، و ترکیب نتایج. مزیت: پوشش بیشتر موضوعات مرتبط. مرجع این تکنیک، مقاله Multi-Query از LangChain است.

تکنیک چهارم: HyDE (Hypothetical Document Embeddings)

یکی از نوآورانه‌ترین تکنیک‌ها: به‌جای Embedding پرسش، یک پاسخ فرضی تولید می‌شود (توسط یک LLM) و Embedding آن پاسخ، برای جستجو استفاده می‌شود. ایده: پاسخ فرضی، از نظر معنایی به اسناد واقعی نزدیک‌تر است تا پرسش. این تکنیک، در تجربه‌ام، دقت را ۱۰ تا ۲۰ درصد افزایش می‌دهد.

Query → LLM → Hypothetical Answer → Embedding → Search

تکنیک پنجم: Query Decomposition

برای پرسش‌های پیچیده که چند موضوع دارند، پرسش به چند زیر-پرسش تجزیه می‌شود و هر کدام به‌طور جداگانه بازیابی می‌شود. مثلاً «تفاوت بین RAG و Fine-Tuning چیست و کدام برای پروژه من بهتر است؟» به دو پرسش تجزیه می‌شود: «تفاوت RAG و Fine-Tuning چیست؟» و «کدام برای پروژه من بهتر است؟»

تکنیک ششم: Step-Back Prompting

در این تکنیک، ابتدا یک پرسش کلی‌تر تولید می‌شود که زمینه را فراهم می‌کند، سپس پرسش اصلی با آن زمینه بازیابی می‌شود. مثال: پرسش «چطور یک شهروند می‌تواند مالیات خود را پرداخت کند؟»، ابتدا با پرسش کلی «قوانین مالیاتی چیست؟» زمینه‌سازی می‌شود.

فصل دوازدهم: Reranking — الک دوم برای دقت

پس از بازیابی اولیه (Retrieval)، معمولاً بین ۲۰ تا ۱۰۰ سند بازیابی می‌شود. ولی فقط بخش کوچکی از این‌ها به مدل زبانی فرستاده می‌شود (معمولاً ۳ تا ۱۰). اینجا جایی است که Reranking وارد می‌شود: بازرتبه‌بندی نتایج بازیابی‌شده برای انتخاب بهترین‌ها.

چرا Reranking ضروری است؟

سه دلیل بنیادین:

  1. محدودیت Bi-Encoder: مدل‌های Bi-Encoder، Query و Document را جداگانه Embedding می‌کنند و تعامل دقیق بین آن‌ها را نمی‌بینند.
  2. محدودیت بودجه توکن: ارسال ۱۰۰ سند به مدل زبانی، از نظر هزینه و طول Context غیرممکن است.
  3. ترتیب مهم است: مدل‌های زبانی، به ترتیب اسناد در Context حساس هستند (پدیده Lost in the Middle).

روش‌های Reranking

روش اول: Cross-Encoder Reranking

دقیق‌ترین روش: استفاده از یک Cross-Encoder برای محاسبه امتیاز شباهت بین Query و هر سند. مدل‌های معروف این حوزه: ms-marco-MiniLM، bge-reranker، Cohere Rerank. این روش، دقت را ۱۰ تا ۳۰ درصد افزایش می‌دهد.

روش دوم: LLM-based Reranking

استفاده از یک LLM برای امتیازدهی یا رتبه‌بندی اسناد. مثال: به LLM داده می‌شود «کدام سند به این پرسش مرتبط‌تر است؟» و مدل، بهترین را انتخاب می‌کند. مزیت: دقت بالا. عیب: هزینه و زمان بیشتر.

روش سوم: Diversity-aware Reranking

روش MMR (Maximal Marginal Relevance): نه‌فقط مرتبط‌بودن، بلکه تنوع را هم در نظر می‌گیرد. یعنی از بین اسناد مرتبط، آن‌هایی انتخاب می‌شوند که اطلاعات متنوعی ارائه دهند.

پیاده‌سازی Reranking

from sentence_transformers import CrossEncoder

reranker = CrossEncoder('BAAI/bge-reranker-v2-m3')

query = "چگونه مالیات ارزش افزوده محاسبه می‌شود؟"
candidates = ["سند اول...", "سند دوم...", "سند سوم..."]

pairs = [[query, doc] for doc in candidates]
scores = reranker.predict(pairs)

# مرتب‌سازی بر اساس امتیاز
ranked = sorted(zip(candidates, scores), key=lambda x: x[1], reverse=True)

فصل سیزدهم: Context Construction و مدیریت بودجه توکن

پس از Reranking، باید اسناد نهایی در قالب یک Context به مدل زبانی ارسال شوند. این مرحله، ظریف‌تر از آن است که به‌نظر می‌رسد.

بودجه توکن (Token Budget)

هر مدل زبانی، یک حداکثر Context Window دارد (مثلاً ۸K، ۳۲K، ۱۲۸K توکن). این بودجه، باید بین سه بخش تقسیم شود: سیستم Prompt (دستورالعمل‌های پایه)، Context (اسناد بازیابی‌شده)، و فضای پاسخ (توکن‌های در دسترس برای تولید).

در تجربه‌ام، یک تخصیص متعارف: ۵-۱۰٪ برای سیستم Prompt، ۷۰-۸۰٪ برای Context، و ۱۵-۲۵٪ برای پاسخ. اگرچه این نسبت بسته به کاربرد تغییر می‌کند.

الگوهای چیدمان Context

الگوی اول: Stuff (همه در یک Prompt)

ساده‌ترین: همه اسناد در یک Prompt قرار می‌گیرند. مناسب تعداد کم اسناد کوچک.

الگوی دوم: Map-Reduce

هر سند جداگانه پردازش می‌شود و نتایج با هم ترکیب می‌شوند. مناسب تعداد زیاد اسناد، ولی هزینه بالاتر.

الگوی سوم: Refine

سند اول پاسخ می‌سازد، سند دوم آن پاسخ را اصلاح می‌کند، و به همین ترتیب. مناسب سناریوهایی که دقت تدریجی مهم است.

پدیده Lost in the Middle

مطالعات نشان داده‌اند که مدل‌های زبانی، به اسنادی که در ابتدا یا انتهای Context قرار دارند توجه بیشتری می‌کنند و اسناد میانی را نادیده می‌گیرند. راه‌حل: مهم‌ترین اسناد را در ابتدا (یا انتها) قرار دهید و اسناد کم‌اهمیت‌تر را در میانه.

Context Compression

اگر اسناد بازیابی‌شده حجم زیادی داشته باشند، می‌توان با تکنیک‌های فشرده‌سازی (مثل خلاصه‌سازی یا استخراج جملات کلیدی)، حجم را کاهش داد. این کار، هزینه را کاهش و کیفیت را افزایش می‌دهد.

فصل چهاردهم: Generation — تولید با استناد

مرحله نهایی RAG، تولید پاسخ توسط مدل زبانی بر اساس Context است. کیفیت این مرحله، بستگی به دو عامل دارد: کیفیت Context و کیفیت Prompt.

اصول Prompt Engineering برای RAG

سه اصل بنیادین:

  1. محدودسازی به Context: به مدل دستور داده شود که فقط بر اساس Context پاسخ دهد، نه دانش درونی. این کار، توهم‌زایی را کاهش می‌دهد.
  2. الزام به استناد: به مدل دستور داده شود که برای هر ادعا، به منبع ارجاع دهد. این کار، شفافیت را افزایش می‌دهد.
  3. اجازه اعتراف به ناآگاهی: به مدل اجازه داده شود که اگر پاسخ در Context نبود، بگوید «نمی‌دانم».

الگوی Prompt استاندارد RAG

شما یک دستیار هوش مصنوعی هستید که بر اساس اسناد ارائه‌شده پاسخ می‌دهد.

دستورالعمل‌ها:
1. فقط بر اساس اطلاعات موجود در اسناد زیر پاسخ دهید.
2. برای هر ادعا، شماره سند را در قالب [سند ۱]، [سند ۲] ذکر کنید.
3. اگر پاسخ در اسناد نبود، صریحاً بگویید «در اسناد موجود، پاسخ این پرسش نیست».
4. از دانش عمومی خود استفاده نکنید.

اسناد:
[سند ۱] {متن سند اول}
[سند ۲] {متن سند دوم}
[سند ۳] {متن سند سوم}

پرسش کاربر: {query}

پاسخ:

الگوی Advanced: Self-Ask و Chain-of-Thought در RAG

برای پرسش‌های پیچیده، می‌توان از مدل خواست که ابتدا استدلال کند و بعد پاسخ دهد. این تکنیک، دقت را در پرسش‌های چندمرحله‌ای افزایش می‌دهد.

فصل پانزدهم: Advanced RAG Patterns — از Naive تا Modular

پس از فهم لایه‌های پایه، برویم سراغ الگوهای پیشرفته که RAG را از یک Pipeline ساده، به یک سیستم هوشمند تبدیل می‌کنند.

الگوی اول: Routing

در سیستم‌های سازمانی که چند پایگاه دانش مختلف دارند (فنی، حقوقی، مالی)، Routing به معنای انتخاب پایگاه داده مناسب بر اساس نوع پرسش است. این کار با یک LLM Classifier یا با قواعد ساده انجام می‌شود.

الگوی دوم: Adaptive Retrieval

تصمیم‌گیری درباره اینکه آیا اصلاً بازیابی لازم است. بعضی پرسش‌ها (مثل «سلام، حال شما؟») نیازی به بازیابی ندارند. با یک طبقه‌بند ساده یا با LLM، می‌توان این تصمیم را خودکار کرد.

الگوی سوم: Iterative Retrieval

برای پرسش‌های پیچیده، بازیابی در چند دور انجام می‌شود. یعنی پاسخ دور اول، به تولید پرسش دقیق‌تر برای دور بعد کمک می‌کند. این رویکرد، در ITER-RETGEN و Self-RAG پیاده‌سازی شده است.

الگوی چهارم: Recursive Retrieval

اگر Chunk های اولیه اطلاعات کافی نداشتند، سیستم می‌تواند در سطح سند کامل یا فصل، دوباره بازیابی کند.

فصل شانزدهم: Self-RAG — بازیابی خودمختار

Self-RAG، معماری‌ای است که در آن، مدل خودش تصمیم می‌گیرد چه زمانی بازیابی کند، چه چیزی بازیابی کند، و پاسخ‌هایش را چطور ارزیابی کند. این معماری، در سال ۲۰۲۳ در مقاله‌ای از Akari Asai و همکارانش معرفی شد.

چهار نوع توکن بازتاب

Self-RAG از چهار توکن خاص استفاده می‌کند:

  • Retrieve: آیا بازیابی لازم است؟ (بله/خیر)
  • IsRel: آیا سند بازیابی‌شده مرتبط است؟ (مرتبط/نامرتبط)
  • IsSup: آیا پاسخ تولیدشده توسط سند پشتیبانی می‌شود؟ (کامل/جزئی/خیر)
  • IsUse: آیا پاسخ برای کاربر مفید است؟ (۱ تا ۵)

این توکن‌ها، در زمان آموزش به مدل تزریق می‌شوند و مدل یاد می‌گیرد که در زمان اجرا، خودش آن‌ها را تولید کند.

مزایای Self-RAG

  • کاهش بازیابی غیرضروری: برای پرسش‌های ساده، بازیابی انجام نمی‌شود.
  • افزایش دقت: اسناد نامرتبط فیلتر می‌شوند.
  • افزایش شفافیت: مدل، درباره اطمینان خودش اطلاعات می‌دهد.

فصل هفدهم: CRAG — ارزیابی اصلاحی بازیابی

CRAG (Corrective RAG)، معماری‌ای است که پس از بازیابی، کیفیت نتایج را ارزیابی می‌کند و در صورت لزوم، اصلاح یا گسترش می‌دهد. این معماری در سال ۲۰۲۴ معرفی شد و در تجربه‌ام، نتایج چشمگیری در دامنه‌های حساس داشته است.

معماری CRAG

CRAG یک Evaluator دارد که کیفیت نتایج بازیابی را در سه دسته طبقه‌بندی می‌کند:

  • Correct: نتایج مرتبط هستند. فقط یک Refinement جزئی انجام می‌شود.
  • Incorrect: نتایج نامرتبط هستند. بازیابی از منابع دیگر (مثلاً جستجوی وب) انجام می‌شود.
  • Ambiguous: نتایج جزئی مرتبط هستند. ترکیبی از Refinement و گسترش.

فصل هجدهم: GraphRAG — معرفی ساختار گراف دانش

GraphRAG، معماری‌ای است که در سال ۲۰۲۴ توسط Microsoft معرفی شد. ایده اصلی: به‌جای ذخیره‌سازی دانش در قالب Chunk های متنی، دانش را در قالب یک گراف ساختاریافته ذخیره کنید. گره‌های گراف، موجودیت‌ها (مثل افراد، سازمان‌ها، رویدادها) و یال‌ها، روابط بین آن‌ها هستند.

چرا GraphRAG؟

RAG سنتی، در پاسخ به پرسش‌های «چندمرحله‌ای» (مثل «چه کسانی در شرکت X با Y همکاری کرده‌اند؟») ضعیف است، چون نیاز به استنتاج از چند سند دارد. GraphRAG با استفاده از ساختار گراف، این نوع پرسش‌ها را حل می‌کند.

مراحل ساخت GraphRAG

  1. Entity Extraction: استخراج موجودیت‌ها (افراد، مکان‌ها، رویدادها) از اسناد.
  2. Relationship Extraction: استخراج روابط بین موجودیت‌ها.
  3. Graph Construction: ساخت گراف از موجودیت‌ها و روابط.
  4. Community Detection: کشف جوامع (Cluster های موجودیت‌های مرتبط).
  5. Community Summarization: خلاصه‌سازی هر جامعه با LLM.

در زمان جستجو، پاسخ می‌تواند از سه منبع بیاید: Graph Query (پرسش‌های ساختاری)، Vector Search (روی خلاصه جوامع)، و Hybrid.

مقایسه GraphRAG و RAG سنتی

معیارRAG سنتیGraphRAG
نوع پرسشساده و مستقیمچندمرحله‌ای و استنتاجی
هزینه ساختپایینبالا (LLM برای ساخت)
سرعت پاسخسریعوابسته به ساختار گراف
مناسب برایFAQ، اسناد فنیروابط پیچیده، تحلیل

فصل نوزدهم: Agentic RAG — عاملی که خودش تحقیق می‌کند

Agentic RAG، پیشرفته‌ترین شکل RAG امروز است. ایده: به‌جای یک Pipeline ثابت، یک ایجنت هوش مصنوعی که خودش تصمیم می‌گیرد چه زمانی و چگونه بازیابی کند. ایجنت می‌تواند: تصمیم بگیرد کدام پایگاه دانش، تصمیم بگیرد چند دور بازیابی، پرسش‌های فرعی تولید کند، و پاسخ را ارزیابی کند.

چهار الگوی Agentic RAG

  • Router-based: ایجنت بین چند پایگاه دانش، انتخاب می‌کند.
  • Planning-based: ایجنت ابتدا یک برنامه بازیابی می‌سازد، سپس اجرا می‌کند.
  • Iterative: ایجنت در چند دور بازیابی می‌کند.
  • Reflective: ایجنت پاسخ‌هایش را ارزیابی می‌کند و در صورت لزوم بازمی‌گردد.

مبانی این معماری، در عامل‌های هوش مصنوعی چگونه تصمیم‌گیری می‌کنند و عامل‌های هوش مصنوعی در کسب‌وکار پوشش داده شده است.

فصل بیستم: Multimodal RAG و RAG برای تصویر و ویدئو

Multimodal RAG، گسترش RAG به مودالیتی‌های مختلف (تصویر، ویدئو، صدا) است. سه رویکرد اصلی:

رویکرد اول: Unified Embeddings

استفاده از مدل‌های Embedding که می‌توانند چند مودالیتی را به یک فضای مشترک نگاشت کنند. مثال: CLIP برای تصویر-متن.

رویکرد دوم: Multi-Index

ذخیره جداگانه بردارهای متنی و تصویری، با استفاده از Link بین آن‌ها. مثال: برای هر تصویر، یک Caption متنی ذخیره می‌شود و بردار هر دو در پایگاه ذخیره می‌شود.

رویکرد سوم: Multimodal LLM

استفاده از مدل‌های چندوجهی (مثل GPT-4V، Gemini) برای پردازش مستقیم چند مودالیتی.

اگر به این حوزه علاقه دارید، مرور پیشرفت‌های هوش مصنوعی در تصویر و ویدئو دید فنی عمیق‌تری می‌دهد.

فصل بیست‌ویکم: Long-Context vs RAG — بحث داغ امروز

با ظهور مدل‌هایی که پنجره‌های طولانی (مثلاً یک میلیون توکن) دارند، بحثی جدی شکل گرفته: آیا RAG ضروری است؟

استدلال موافق RAG

  • هزینه: ارسال یک میلیون توکن به مدل، پرهزینه است. RAG فقط بخش‌های مرتبط را می‌فرستد.
  • سرعت: Context طولانی، تأخیر پاسخ را افزایش می‌دهد.
  • دقت: پدیده Lost in the Middle در Context های طولانی، شدیدتر می‌شود.
  • به‌روزرسانی: RAG امکان به‌روزرسانی آنی دانش را می‌دهد.

استدلال مخالف RAG

  • سادگی: بدون RAG، معماری ساده‌تر است.
  • جامعیت: Context طولانی، اطلاعات کامل‌تری می‌دهد.
  • عدم خطای بازیابی: در RAG، اگر بازیابی اشتباه باشد، پاسخ اشتباه می‌شود.

در تجربه‌ام، پاسخ واقع‌بینانه این است: هر دو رویکرد، کاربرد خودشان را دارند. Context طولانی برای تحلیل‌های عمیق، RAG برای پرسش‌های مکرر با دانش بزرگ. ترکیب هر دو، بهترین جواب است: RAG برای فیلترکردن، Context طولانی برای پردازش.

فصل بیست‌ودوم: ارزیابی RAG — معیارها، چارچوب‌ها و RAGAS

ارزیابی RAG، چالش‌هایی دارد که با ارزیابی LLM معمولی متفاوت است. باید هم کیفیت بازیابی و هم کیفیت تولید سنجیده شود.

معیارهای اصلی

  • Context Precision: نسبت اسناد بازیابی‌شده که مرتبط هستند.
  • Context Recall: نسبت اطلاعات مرتبط که بازیابی شده‌اند.
  • Faithfulness: نسبت ادعاهای پاسخ که در Context پشتیبانی می‌شوند.
  • Answer Relevancy: ارتباط پاسخ با پرسش.
  • Answer Correctness: صحت پاسخ در مقایسه با پاسخ مرجع.

RAGAS — چارچوب ارزیابی

RAGAS (Retrieval-Augmented Generation Assessment)، چارچوبی متن‌باز برای ارزیابی سیستم‌های RAG است. مزیت: بدون نیاز به Ground Truth برای همه معیارها. با استفاده از LLM به‌عنوان Judge، معیارها را محاسبه می‌کند.

from ragas import evaluate
from ragas.metrics import (
    faithfulness, answer_relevancy,
    context_precision, context_recall
)

result = evaluate(
    dataset,
    metrics=[faithfulness, answer_relevancy,
             context_precision, context_recall]
)

ارزیابی انسانی

در کنار ارزیابی خودکار، ارزیابی انسانی هم ضروری است. سه رویکرد:

  • Side-by-Side: مقایسه دو پاسخ کنار هم.
  • Likert Scale: امتیازدهی روی مقیاس ۱ تا ۵.
  • Error Analysis: دسته‌بندی خطاها برای شناسایی الگوها.

فصل بیست‌وسوم: الگوهای شکست در RAG و راه‌حل‌ها

در تجربه‌ام، شکست‌های RAG در هفت الگوی اصلی طبقه‌بندی می‌شوند:

الگوی اول: Missing Content

پاسخ در پایگاه دانش وجود ندارد. راه‌حل: گسترش پایگاه یا اعلام صریح ناآگاهی.

الگوی دوم: Retrieved but Not Relevant

اسناد بازیابی‌شده مرتبط نیستند. راه‌حل: بهبود Embedding، Reranking، یا Hybrid Search.

الگوی سوم: Retrieved Not Enough

اسناد مرتبط هستند ولی کافی نیستند. راه‌حل: افزایش K، Multi-Query، یا Iterative Retrieval.

الگوی چهارم: Not Extracted

اطلاعات در Context هست ولی مدل استخراج نمی‌کند. راه‌حل: بهبود Prompt، کاهش نویز، Context Compression.

الگوی پنجم: Wrong Format

مدل پاسخ را در قالب اشتباه تولید می‌کند. راه‌حل: Few-shot Examples، Structured Output.

الگوی ششم: Incorrect Specificity

پاسخ بیش‌ازحد کلی یا بیش‌ازحد جزئی است. راه‌حل: تنظیم Prompt، آموزش با Examples.

الگوی هفتم: Hallucination Despite Context

مدل با وجود Context درست، اطلاعات نادرست می‌سازد. راه‌حل: Self-RAG، CRAG، تقویت ارزیابی Faithfulness.

فصل بیست‌وچهارم: بهینه‌سازی و مهندسی تولید

RAG در محیط تولید، چالش‌هایی دارد که در توسعه دیده نمی‌شوند.

بهینه‌سازی Latency

سه سطح بهینه‌سازی:

  • Pre-computation: محاسبه Embedding ها به‌صورت Offline.
  • Caching: ذخیره نتایج پرسش‌های تکراری.
  • Async Processing: موازی‌سازی مراحل مختلف Pipeline.

بهینه‌سازی هزینه

  • Prompt Caching: ذخیره بخش‌های ثابت Prompt.
  • Smaller Models: استفاده از مدل‌های کوچک‌تر برای مراحل ساده.
  • Batch Processing: پردازش گروهی برای کاهش هزینه.

پایش در تولید

سه سطح پایش:

  • Operational Metrics: Latency، Throughput، Error Rate.
  • Quality Metrics: Faithfulness، Relevancy (به‌طور پیوسته).
  • User Feedback: Thumbs up/down، رضایت کاربر.

امنیت RAG

RAG، چند ریسک امنیتی جدید ایجاد می‌کند:

  • Prompt Injection: اسناد آلوده که دستورهای مخرب دارند.
  • Data Leakage: افشای اطلاعات محرمانه از طریق پاسخ.
  • Poisoning: تزریق اسناد نادرست برای گمراه‌کردن سیستم.

ملاحظات امنیتی مرتبط با این حوزه، با اصولی که در راهنمای امنیت وردپرس برای مبتدیان و افزونه‌های امنیتی باز کرده‌ام، هم‌راستاست.

فصل بیست‌وپنجم: پیاده‌سازی گام‌به‌گام با کد پایتون

حالا برویم سراغ پیاده‌سازی عملی. یک سیستم RAG کامل با LangChain، OpenAI، و Chroma می‌سازم.

# نصب پکیج‌ها
# pip install langchain langchain-openai chromadb
#   tiktoken pypdf sentence-transformers

from langchain_community.document_loaders import PyPDFLoader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_openai import OpenAIEmbeddings, ChatOpenAI
from langchain_community.vectorstores import Chroma
from langchain.chains import RetrievalQA
from langchain.prompts import PromptTemplate

# گام اول: بارگذاری اسناد
loader = PyPDFLoader("knowledge_base.pdf")
documents = loader.load()

# گام دوم: تقسیم اسناد
splitter = RecursiveCharacterTextSplitter(
    chunk_size=512,
    chunk_overlap=100,
    separators=["\n\n", "\n", ".", " "]
)
chunks = splitter.split_documents(documents)

# گام سوم: Embedding و ذخیره‌سازی
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")
vectorstore = Chroma.from_documents(
    documents=chunks,
    embedding=embeddings,
    persist_directory="./chroma_db"
)

# گام چهارم: بازیابنده
retriever = vectorstore.as_retriever(
    search_type="mmr",
    search_kwargs={"k": 10, "fetch_k": 20}
)

# گام پنجم: Prompt
prompt_template = """شما یک دستیار هستید که فقط بر اساس
اسناد زیر پاسخ می‌دهید.

اسناد:
{context}

پرسش: {question}

پاسخ:"""
prompt = PromptTemplate(
    template=prompt_template,
    input_variables=["context", "question"]
)

# گام ششم: Chain نهایی
llm = ChatOpenAI(model="gpt-4o", temperature=0)
qa_chain = RetrievalQA.from_chain_type(
    llm=llm,
    retriever=retriever,
    chain_type="stuff",
    chain_type_kwargs={"prompt": prompt},
    return_source_documents=True
)

# گام هفتم: اجرا
result = qa_chain.invoke({
    "query": "چگونه می‌توانم ...؟"
})
print(result["result"])

پیاده‌سازی پیشرفته: Hybrid Search + Reranking

from rank_bm25 import BM25Okapi
from sentence_transformers import CrossEncoder
import numpy as np

# 1. ساخت ایندکس BM25
tokenized_chunks = [chunk.page_content.split()
                     for chunk in chunks]
bm25 = BM25Okapi(tokenized_chunks)

# 2. تابع Hybrid Search
def hybrid_search(query, k=10, alpha=0.5):
    # Dense
    dense_results = vectorstore.similarity_search_with_score(
        query, k=k
    )

    # Sparse
    query_tokens = query.split()
    sparse_scores = bm25.get_scores(query_tokens)
    sparse_top = np.argsort(sparse_scores)[-k:][::-1]

    # ترکیب با RRF
    combined = {}
    for rank, (doc, score) in enumerate(dense_results):
        combined[doc.page_content] = 1 / (60 + rank)

    for rank, idx in enumerate(sparse_top):
        content = chunks[idx].page_content
        combined[content] = combined.get(content, 0) \
                            + 1 / (60 + rank)

    # مرتب‌سازی
    ranked = sorted(combined.items(),
                    key=lambda x: x[1], reverse=True)
    return ranked[:k]

# 3. Reranking با Cross-Encoder
reranker = CrossEncoder('BAAI/bge-reranker-v2-m3')

def rerank(query, candidates, top_n=5):
    pairs = [[query, doc] for doc, _ in candidates]
    scores = reranker.predict(pairs)
    ranked = sorted(zip(candidates, scores),
                    key=lambda x: x[1], reverse=True)
    return [doc for (doc, _), _ in ranked[:top_n]]

فصل بیست‌وششم: RAG در وردپرس و سیستم‌های CMS

RAG در بستر وردپرس، کاربردهای خاص خودش را دارد. یک کسب‌وکار وردپرسی می‌تواند از RAG برای ساخت دستیار پشتیبانی، جستجوی هوشمند در محتوای سایت، یا تولید خودکار پاسخ به مشتریان استفاده کند.

منابع داده در RAG وردپرسی

  • نوشته‌ها و برگه‌ها: از جدول wp_posts.
  • محصولات ووکامرس: از wp_posts با نوع product.
  • نظرات مشتریان: از wp_comments.
  • پرسش‌های متداول: از افزونه‌های FAQ.
  • تیکت‌های پشتیبانی: از سیستم‌های تیکت.

اتصال RAG به وردپرس

سه رویکرد:

  1. REST API وردپرس: با استفاده از API داخلی، محتوا را خوانده و به سیستم RAG بفرستید. مرجع: REST API در وردپرس.
  2. مستقیم از دیتابیس: خواندن محتوا از دیتابیس MySQL. مرجع: اتصال پایتون به MySQL.
  3. افزونه‌های آماده: افزونه‌های وردپرسی که RAG را پیاده‌سازی کرده‌اند. مرجع: بهترین افزونه‌های هوش مصنوعی برای وردپرس.

برای پیاده‌سازی حرفه‌ای، معمولاً ترکیب رویکرد اول و دوم بهترین جواب را می‌دهد. برای درک عمیق‌تر معماری وردپرس، مراجع ساختار هسته وردپرس و آموزش مدیریت دیتابیس وردپرس مفیدند.

فصل بیست‌وهفتم: افق پیش رو و مسائل باز

RAG در حال تکامل است. سه جهت‌گیری اصلی که در سال‌های آینده شاهد خواهیم بود:

جهت اول: ترکیب RAG و Long-Context

با ظهور مدل‌های Context طولانی، RAG و Long-Context به‌جای رقیب، مکمل یکدیگر می‌شوند. یعنی RAG برای فیلترکردن اولیه، Long-Context برای پردازش عمیق.

جهت دوم: RAG خودآموز

سیستم‌های RAG در آینده، از بازخورد کاربران یاد می‌گیرند و خودشان را بهبود می‌دهند. یعنی هر بار که کاربر پاسخ نادرستی می‌گیرد، سیستم این را ثبت می‌کند و در آموزش‌های بعدی استفاده می‌کند.

جهت سوم: RAG چندعاملی

به‌جای یک ایجنت بازیابی، مجموعه‌ای از ایجنت‌های تخصصی که با هم کار می‌کنند: یک ایجنت برای هر پایگاه دانش، یک ایجنت برای ارزیابی، و یک ایجنت برای ترکیب.

مسائل باز

  • ارزیابی دقیق: هنوز چارچوب استانداردی برای ارزیابی RAG وجود ندارد.
  • حافظه بلندمدت: RAG فعلی، حافظه بین مکالمات ندارد.
  • هزینه: RAG در مقیاس بزرگ، هزینه‌بر است.
  • امنیت: Prompt Injection و Poisoning، ریسک‌های جدی هستند.
  • چندزبانه: کیفیت RAG در زبان‌های کم‌منبع (مثل فارسی) کمتر از انگلیسی است.

خط پایانی این نقشه

RAG، از یک تکنیک تحقیقاتی در سال ۲۰۲۰، به ستون فقرات اکثر سیستم‌های هوش مصنوعی سازمانی تبدیل شده است. این تحول، نه از سر مد روز، بلکه به‌دلیل یک نیاز بنیادین: مدل‌های زبانی، بدون دسترسی به دانش قابل‌اتکا، نمی‌توانند در کاربردهای حساس استفاده شوند. RAG این شکاف را پر می‌کند، با معماری‌ای که از Chunking و Embedding شروع می‌شود، از Hybrid Search و Reranking عبور می‌کند، و در Generation با استناد به پایان می‌رسد.

در این مقاله، سه نسل RAG را مرور کردیم، معماری پنج‌لایه را کالبدشکافی کردیم، الگوهای پیشرفته (Self-RAG، CRAG، GraphRAG، Agentic RAG) را بررسی کردیم، و پیاده‌سازی گام‌به‌گام را با کد دیدیم. اما نکته مهمتر از همه این‌ها: RAG یک پروژه یک‌باره نیست، یک سرمایه‌گذاری مستمر است. کیفیت آن، به کیفیت داده، کیفیت Embedding، کیفیت Chunking، و کیفیت ارزیابی مستمر بستگی دارد.

اگر تجربه‌ای از پیاده‌سازی RAG در پروژه‌های واقعی دارید — چه موفق، چه ناموفق — آن را در دیدگاه بنویسید. این نوع داده واقعی، برای خواننده بعدی که در همان مرحله ایستاده، از هر مقاله تئوریک ارزشمندتر است. 🤖