- شهریور ۵, ۱۴۰۵
- زمان مطالعه : 11دقیقه
مدلهای زبانی بزرگ یا LLMها در تولید متن بسیار قدرتمندند، اما یک مسئله بنیادی دارند: دانش اختصاصی و بهروز سازمان را لزوماً در اختیار ندارند اگر از یک LLM بپرسیم:
«طبق آییننامه داخلی شرکت ما، سقف مرخصی استعلاجی کارکنان چقدر است؟»
مدل ممکن است پاسخی روان و حتی بسیار قانعکننده تولید کند، اما اگر آییننامه شرکت را در اختیار نداشته باشد، دلیلی وجود ندارد که پاسخ آن مطابق سیاست واقعی سازمان باشد.
اینجاست که Retrieval-Augmented Generation یا RAG وارد معماری میشود.ایده اصلی RAG این است که به جای اینکه همه دانش را در وزنهای مدل زبانی ذخیره کنیم، دانش خارجی را در یک لایه قابل جستوجو نگهداری کنیم و در زمان سؤال، اطلاعات مرتبط را بازیابی کرده و در اختیار LLM قرار دهیم. این ایده از معماریهای اولیه RAG برای ترکیب حافظه پارامتریک مدل و حافظه غیرپارامتریک خارجی سرچشمه میگیرد
- معماری RAG در یک نگاه
یک RAG استاندارد را میتوان به دو مرحله اصلی تقسیم کرد:
مرحله اول: ساخت Knowledge Base
مرحله دوم: پاسخگویی
نکته مهم این است که ساخت Knowledge Base معمولاً یک فرآیند آفلاین یا نیمهآفلاین است. یعنی وقتی کاربر سؤال میپرسد، سیستم دوباره کل سایت یا کل اسناد را Chunk نمیکند.
- اولین مرحله: Document Ingestion
منابع دانش میتوانند شامل موارد مختلفی باشند:
- Word
- Excel
- صفحات وب
- قراردادها
- آییننامهها
- دستورالعملها
- گزارشها
- پایگاههای داده
- مستندات فنی
- سیستمهای داخلی سازمان
در این مرحله باید متن و ساختار سند استخراج شود.
اما یک اشتباه رایج این است که تصور کنیم:
PDF → تمام شد → متن
در واقع کیفیت استخراج بسیار مهم است مثلاً اگر یک PDF دارای جدول باشد، استخراج ساده متن ممکن است ترتیب سلولها را خراب کند. در نتیجه حتی اگر Embedding عالی باشد، اطلاعات ورودی اشتباه خواهد بود.
بنابراین: کیفیت RAG از Data Ingestion شروع میشود، نه از LLM
- Chunking چیست؟
مدل RAG معمولاً سند کامل را به عنوان یک واحد جستوجو ذخیره نمیکند.
سند به بخشهای کوچکتر تقسیم میشود:
Document
↓
Chunk 1
Chunk 2
Chunk 3
…
Chunk N
به هر بخش Chunk میگوییم Chunk میتواند یک پاراگراف، چند پاراگراف، یک بخش از یک سند یا یک واحد معنایی باشد.
مثلاً یک آییننامه ۵۰ صفحهای را تصور کنید.
اگر سؤال کاربر این باشد:
«شرایط مرخصی استعلاجی چیست؟»
ما نمیخواهیم کل ۵۰ صفحه را به مدل بدهیم.
میخواهیم بخشی را پیدا کنیم که واقعاً درباره مرخصی استعلاجی صحبت میکند.
- Chunk Size و Overlap
Chunk اندازه ثابتی ندارد میتوان آن را بر اساس:
- Token
- Character
- Sentence
- Paragraph
- ساختار معنایی
تعریف کرد مثلاً:
Chunk Size = 500 tokens
Overlap = 50 tokens
در این حالت بخشی از انتهای Chunk قبلی در Chunk بعدی نیز تکرار میشود این کار برای حفظ ارتباط معنایی در مرز Chunkها مفید است اما Chunk بزرگتر الزاماً بهتر نیست.
Chunk خیلی کوچک:
- Context کافی ندارد.
- ممکن است مفهوم ناقص شود.
Chunk خیلی بزرگ:
- نویز بیشتری وارد Retrieval میکند.
- Context LLM را مصرف میکند.
- تشخیص بخش دقیق مرتبط سختتر میشود.
بنابراین Chunking باید با ارزیابی Retrieval تنظیم شود، نه صرفاً با یک عدد قراردادی.
- . Embedding چیست؟
بعد از Chunking، هر Chunk به یک بردار عددی تبدیل میشود.
مثلاً:
Chunk
↓
Embedding Model
↓
[0.12, -0.34, 0.81, …]
این بردار یک نمایش عددی از معنای متن است همین کار برای سؤال کاربر نیز انجام میشود:
Question
↓
Embedding Model
↓
Query Vector
سپس Query Vector با Vectorهای موجود در پایگاه دانش مقایسه میشود در جستوجوی معنایی، هدف این است که متنهایی با معنای مشابه در فضای برداری به یکدیگر نزدیکتر باشند. Qdrant نیز جستوجوی k-NN و معیارهایی مانند Cosine، Dot Product و Euclidean را پشتیبانی میکند
- Similarity Search
فرض کنیم سؤال:
«شرایط استفاده از مرخصی استعلاجی چیست؟»
و پنج Chunk امتیازهای زیر را دارند:
Chunk | Similarity |
C127 | 0.93 |
C542 | 0.89 |
C881 | 0.86 |
C102 | 0.82 |
C912 | 0.79 |
سیستم آنها را بر اساس شباهت مرتب میکند.
اینجا Similarity یک مفهوم است و Recall مفهوم دیگری.
Similarity میگوید:
این Chunk چقدر به سؤال نزدیک است؟
Recall میگوید:
آیا چیزی که واقعاً باید پیدا میکردیم، پیدا شد؟
- . Top-K چیست؟
در Vector Search معمولاً از کل مجموعه، تعدادی نتیجه اول را انتخاب میکنیم.
مثلاً:
100,000 Chunk
↓
Similarity Search
↓
Top-K = 20
↓
20 Candidate
K را طراح سیستم تعیین میکند و باید با آزمایش و Validation Dataset تنظیم شود. Qdrant نیز Top-K را بهعنوان تعداد نتایجی که از جستوجوی نزدیکترین بردارها برگردانده میشوند توضیح میدهد
یک معماری رایج:
Qdrant
↓
Top-20
↓
Reranker
↓
Top-5
↓
LLM
است.
- چرا مستقیماً نتیجه Retrieval را به LLM نمیدهیم؟
چون Top-K اولیه همیشه بهینه نیست Embedding Search سریع است، اما ممکن است دو Chunk از نظر کلی شبیه باشند ولی یکی دقیقاً پاسخ سؤال را ندهد اینجا Reranking وارد میشود.
- Reranking چیست؟
در مرحله اول از یک روش سریع برای پیدا کردن Candidateها استفاده میکنیم سپس یک مدل دقیقتر سؤال و هر Candidate را با هم بررسی میکند.
مثلاً:
Question
+
Chunk 1
↓
Cross Encoder
↓
Score = 0.91
و:
Question
+
Chunk 2
↓
Cross Encoder
↓
Score = 0.47
Cross-Encoderها معمولاً برای همین مرحله استفاده میشوند: ابتدا یک Bi-Encoder یا روش سریعتر Top-K را پیدا میکند و سپس Cross-Encoder آنها را دقیقتر رتبهبندی میکند
- Retrieval و Reranking دو مسئله متفاوتاند
این تفکیک بسیار مهم است
Retrieval
آیا سند/Chunk مناسب را پیدا کردیم؟
Reranking
آیا مناسبترین Chunkها را در رتبههای بالاتر قرار دادیم؟
پس ممکن است Retrieval خوب باشد ولی Ranking ضعیف باشد.
مثلاً:
Top 20
شامل پاسخ صحیح است، اما پاسخ صحیح در رتبه 19 قرار گرفته.
از نظر Recall@20:
موفق
اما از نظر تجربه کاربر:
ضعیف
چون ممکن است بعداً فقط پنج نتیجه اول را به LLM بدهیم.
- Evidence Selection
بعد از Retrieval و Reranking باید تصمیم بگیریم:
کدام شواهد واقعاً ارزش ورود به Context را دارند؟
ممکن است از ۲۰ Chunk بازیابیشده فقط ۴ یا ۵ مورد واقعاً برای پاسخ لازم باشند.
بنابراین:
Top-K = 20
↓
Reranking
↓
Evidence Selection
↓
5 Evidence
این مرحله برای کنترل:
- نویز
- Context
- Token Usage
- هزینه
- احتمال Hallucination
اهمیت زیادی دارد.
- Prompt Assembly
حالا Prompt نهایی ساخته میشود Prompt فقط سؤال کاربر نیست.
مثلاً:
SYSTEM:
شما دستیار دانشمحور سازمان هستید.
فقط بر اساس شواهد ارائهشده پاسخ دهید.
اگر شواهد کافی نیست، از پاسخ قطعی خودداری کنید.
CONTEXT:
Evidence 1:
…
Evidence 2:
…
Evidence 3:
…
USER:
شرایط مرخصی استعلاجی چیست؟
سپس این Prompt وارد Tokenizer مدل میشود:
Prompt
↓
Tokenizer
↓
Token IDs
↓
LLM
- نقش LLM در RAG چیست؟
در معماری RAG، LLM الزاماً مسئول پیدا کردن دانش نیست.
این تفکیک بسیار مهم است:
Embedding Model:
پیدا کردن فضای معنایی
Vector Database:
بازیابی Candidateها
Reranker:
بهبود ترتیب
Evidence Selection:
انتخاب شواهد
LLM:
تفسیر شواهد و تولید پاسخ
این همان معماریای است که باعث میشود یک مدل کوچک محلی نیز بتواند روی یک Knowledge Base اختصاصی عملکرد قابلقبولی داشته باشد.
- . Answerability؛ آیا اصلاً باید پاسخ بدهیم؟
یکی از مهمترین بخشهای RAG حرفهای، چیزی است که در سیستم ما با Answerability Guard دنبال کردهایم.
فرض کنیم کاربر سؤال میپرسد:
«بودجه پروژه سال ۱۴۰۷ چقدر است؟»
اما هیچ سندی درباره سال ۱۴۰۷ وجود ندارد.
LLM ممکن است وسوسه شود یک پاسخ تولید کند.
سیستم حرفهای باید بتواند بگوید:
INSUFFICIENT
یا:
REVIEW
به جای اینکه یک پاسخ ساختگی تولید کند.این مسئله از نظر اعتمادپذیری بسیار مهم است. NIST نیز در چارچوب مدیریت ریسک GenAI بر ارزیابی و مدیریت ریسکهای سیستمهای مولد در چرخه عمر آنها تأکید میکند
- مهمترین اشتباه در ارزیابی RAG
نباید فقط بپرسیم:
«پاسخ خوب بود؟»
چون RAG چند لایه دارد و هر لایه ممکن است خراب شود.
یک پاسخ بد میتواند ناشی از این باشد:
Chunking غلط
↓
Embedding ضعیف
↓
Retrieval غلط
↓
Reranking غلط
↓
Evidence غلط
↓
Prompt غلط
↓
Generation غلط
بنابراین ارزیابی باید Layered باشد.
- شاخصهای Retrieval
Recall@K
سؤال اصلی:
آیا شواهد صحیح در Top-K پیدا شده است؟
مثلاً اگر 100 سؤال داشته باشیم و برای 98 سؤال، سند/Chunk صحیح در پنج نتیجه اول وجود داشته باشد:
- MRR
MRR به رتبه اولین نتیجه مرتبط توجه میکند.
اگر نتیجه درست رتبه 1 باشد:
اگر رتبه 2 باشد:
اگر رتبه 5 باشد:
و میانگین Reciprocal Rank روی تمام Queryها میشود:
اما باید توجه داشت که برای یک گزارش نهایی حرفهای باید مشخص کنیم این MRR دقیقاً روی کدام مرحله و با چه Ground Truth محاسبه شده است.
- Coverage@5
Coverage سؤال متفاوتی میپرسد:
آیا پنج نتیجه اول اطلاعات کافی برای پوشش مسئله دارند؟
این با Exact Chunk Recall یکسان نیست.
مثلاً ممکن است یک سؤال به سه بخش اطلاعاتی نیاز داشته باشد.
اگر Top-5 فقط یکی از آنها را پیدا کند، ممکن است Exact Match موفق باشد، اما پوشش واقعی ناقص باشد.
- شاخصهای Reranking
دو شاخص مهم:
NDCG@K
برای زمانی مهم است که درجه ارتباط نتایج اهمیت دارد.
مثلاً:
Result 1 → بسیار مرتبط
Result 2 → بسیار مرتبط
Result 3 → متوسط
Result 4 → ضعیف
NDCG فقط نمیپرسد «نتیجه درست بود؟»؛ به ترتیب و میزان relevance نیز توجه میکند.
MRR
میتواند برای ارزیابی اینکه اولین نتیجه مرتبط بعد از Reranking کجا قرار گرفته استفاده شود.
برای ارزیابی Cross-Encoder، ابزارهای Sentence Transformers نیز معیارهایی مانند MRR@K، NDCG@K و MAP را ارائه میکنند
- شاخصهای Answerability
اینجا میخواهیم بدانیم:
آیا سیستم درست تشخیص داده که سؤال قابل پاسخ است یا نه؟
مثلاً چهار حالت:
واقعیت | تصمیم سیستم |
قابل پاسخ | SUPPORTED |
قابل پاسخ | INSUFFICIENT ❌ |
غیرقابل پاسخ | INSUFFICIENT |
غیرقابل پاسخ | SUPPORTED ❌ |
از اینجا میتوانیم:
- Accuracy
- Precision
- Recall
- F1
- Abstention Precision
- Abstention Recall
را محاسبه کنیم.برای یک دستیار سازمانی، Abstention یک ویژگی مثبت است، نه شکست سیستم.
اگر اطلاعات کافی نداریم، پاسخ ندادن بهتر از تولید اطلاعات جعلی است.
- ارزیابی Generation
حالا به مهمترین قسمت میرسیم:
آیا پاسخ نهایی واقعاً خوب است؟
چند معیار مهم داریم.
Answer Correctness
آیا پاسخ واقعاً جواب سؤال را درست داده؟
Faithfulness / Groundedness
آیا ادعاهای پاسخ از Context پشتیبانی میشوند؟
مثلاً اگر Context بگوید:
مرخصی استعلاجی با تأیید پزشک امکانپذیر است.
و مدل بگوید:
مرخصی استعلاجی بدون تأیید پزشک امکانپذیر است.
پاسخ:
Not Grounded
حتی اگر از نظر زبانی عالی باشد.
Ragas نیز Faithfulness را از Correctness جدا میکند و تأکید دارد که پاسخ میتواند کاملاً grounded باشد ولی همچنان ناقص یا نامرتبط باشد؛ بنابراین یک معیار بهتنهایی کافی نیست
- Citation Accuracy
اگر سیستم میگوید:
طبق آییننامه منابع انسانی، مرخصی استعلاجی…
باید بتوانیم بررسی کنیم:
آیا Citation واقعاً همان ادعا را پشتیبانی میکند؟
این برای Enterprise AI بسیار مهم است.
چون:
Citation داشتن ≠ Citation صحیح
- ارزیابی System
حتی اگر پاسخ کاملاً صحیح باشد، سیستم ممکن است در Production قابل استفاده نباشد.
بنابراین باید اندازه بگیریم:
Latency
چند میلیثانیه/ثانیه از سؤال تا پاسخ؟
Token Usage
چند Token برای:
- Input
- Context
- Output
مصرف شده؟
Error Rate
چند درصد درخواستها با خطای:
- API
- Retrieval
- Model
- Timeout
- Database
مواجه شدهاند؟
- . Golden Dataset؛ قلب ارزیابی
بدون Dataset ارزیابی، نمیتوانیم با اطمینان بگوییم:
«RAG ما بهتر شده است.»
یک Golden Dataset مناسب باید شامل:
Question
Ground Truth Answer
Relevant Document
Relevant Chunk
Expected Evidence
Answerability
Difficulty
Category
باشد.
و فقط سؤالهای آسان نباید در آن باشند.
باید داشته باشیم:
- سؤال ساده
- سؤال چندبخشی
- سؤال مبهم
- سؤال بدون پاسخ
- سؤال با Negative Evidence
- سؤال مشابه
- سؤال چند سندی
- سؤال دارای اطلاعات متناقض
رویکردهای ارزیابی RAG نیز معمولاً از Dataset شامل سؤال، Context مورد انتظار و پاسخ مرجع برای اجرای سیستم و ارزیابی خروجی استفاده میکنند
- یک سؤال واقعی را از ابتدا تا انتها ببینیم
فرض کنید سازمان ۲۰٬۰۰۰ Chunk دارد.
کاربر میپرسد:
«آخرین دستورالعمل ثبت فاکتور چیست؟»
مرحله اول
سؤال به Embedding تبدیل میشود.
مرحله دوم
Qdrant جستوجو میکند:
20,000 Chunk
↓
Top-K = 20
مرحله سوم
Cross-Encoder:
20 Candidate
↓
Reranking
↓
Top-5
مرحله چهارم
Evidence Selection:
5 Chunk
↓
3 Evidence
مرحله پنجم
Prompt:
System Instruction
+
3 Evidence
+
User Question
مرحله ششم
Tokenizer:
Prompt
↓
Token IDs
مرحله هفتم
Qwen:
Qwen 2.5 3B
↓
Answer
مرحله هشتم
Answerability / Groundedness:
آیا شواهد کافی بود؟
آیا پاسخ از شواهد پشتیبانی میشود؟
مرحله نهم
پاسخ:
طبق آخرین دستورالعمل ثبت فاکتور، درخواست باید…
همراه با منبع.
- یک نکته بسیار مهم: Recall بالا به معنی پاسخ خوب نیست
فرض کنید:
Recall@5 = 98.2%
این فوقالعاده است، اما هنوز نمیتوانیم بگوییم:
«سیستم 98.2٪ پاسخ درست میدهد.»
چرا؟
چون ممکن است:
Retrieval = عالی
↓
Reranking = ضعیف
↓
Evidence = غلط
↓
Generation = غلط
بنابراین:
Retrieval Quality ≠ Answer Quality
این یکی از مهمترین اصول ارزیابی RAG است.
- ماتریس ارزیابی پیشنهادی برای یک RAG حرفهای
من برای یک سیستم Enterprise این Dashboard را پیشنهاد میکنم:
Layer | Metric | هدف |
Retrieval | Recall@1 | یافتن پاسخ در رتبه اول |
Retrieval | Recall@3 | پوشش Top-3 |
Retrieval | Recall@5 | پوشش Top-5 |
Retrieval | MRR | کیفیت رتبهبندی |
Retrieval | Context Recall | کامل بودن شواهد |
Retrieval | Context Precision | نسبت سیگنال به نویز |
Reranking | NDCG@5 | کیفیت ترتیب |
Reranking | MRR@5 | رتبه اولین نتیجه مرتبط |
Answerability | Accuracy | تشخیص قابلپاسخ بودن |
Answerability | Abstention Precision/Recall | کیفیت خودداری |
Generation | Answer Correctness | درستی پاسخ |
Generation | Faithfulness | اتکا به Evidence |
Generation | Citation Accuracy | صحت منابع |
Generation | Answer Relevancy | ارتباط با سؤال |
System | Latency | سرعت |
System | Token Usage | مصرف Context |
System | Error Rate | پایداری |
ابزارهایی مانند Ragas نیز مجموعهای از معیارهای Retrieval و Generation از جمله Context Precision، Context Recall، Faithfulness، Response Relevancy و Factual Correctness را ارائه میکنند.
- چگونه RAG را بهبود دهیم؟
اگر Recall پایین است:
Chunking
Embedding
Query rewriting
Hybrid Search
Top-K
را بررسی کنید.
اگر Recall خوب ولی NDCG ضعیف است:
Reranker
Hard Negatives
Ranking
را بررسی کنید.
اگر Retrieval خوب ولی پاسخ غلط است:
Evidence Selection
Prompt
LLM
Answerability
را بررسی کنید.اگر پاسخ درست ولی کند است:
Embedding latency
Qdrant
Reranker
Context size
LLM inference
را بررسی کنید.
این همان چیزی است که یک RAG حرفهای را از یک Demo ساده جدا میکند.
- . Fine-tuning کجای این معماری قرار میگیرد؟
Fine-tuning الزاماً اولین راهحل نیست.اگر دانش سازمان تغییر میکند، معمولاً بهتر است آن را در Knowledge Base نگهداری کنیم.
مثلاً:
آییننامه جدید
↓
Chunk
↓
Embedding
↓
Qdrant
و نه اینکه برای هر تغییر کوچک دوباره LLM را Fine-tune کنیم Fine-tuning بیشتر برای تغییر رفتار، سبک، فرمت یا توانایی خاص مدل مناسب است؛ RAG برای دسترسی به دانش خارجی و قابلبهروزرسانی بسیار مناسب است. ایده اصلی RAG نیز دقیقاً ترکیب حافظه پارامتریک مدل با حافظه غیرپارامتریک خارجی است
- چکلیست نهایی طراحی RAG
قبل از Production این موارد باید پاسخ مشخص داشته باشند:
Data
- منابع دانش چیست؟
- استخراج چگونه انجام میشود؟
- PDF و جدول چگونه پردازش میشوند؟
- نسخهبندی اسناد چگونه است؟
Chunking
- Chunk Size چقدر است؟
- Overlap چقدر است؟
- آیا Chunk معنایی است یا صرفاً طولی؟
- Metadata چیست؟
Embedding
- چه مدل Embedding استفاده میشود؟
- Dimension چیست؟
- Metric چیست؟
- آیا زبان فارسی پشتیبانی میشود؟
Retrieval
- Dense یا Hybrid؟
- Top-K چقدر است؟
- Filter داریم؟
- Threshold داریم؟
Qdrant علاوه بر Dense Search از قابلیتهای lexical و BM25 و Hybrid Retrieval نیز پشتیبانی میکند که برای دادههای دارای اصطلاحات دقیق، شناسهها و کلمات تخصصی میتواند مهم باشد
Reranking
- مدل چیست؟
- چند Candidate را Rerank میکنیم؟
- Top-N نهایی چند است؟
Evidence
- چگونه Evidence انتخاب میشود؟
- Duplicateها حذف میشوند؟
- Conflict بین اسناد چگونه مدیریت میشود؟
Generation
- System Prompt چیست؟
- Context چگونه وارد Prompt میشود؟
- Citation چگونه تولید میشود؟
- مدل چه زمانی باید Abstain کند؟
Evaluation
- Golden Dataset داریم؟
- Negative Cases داریم؟
- Recall@K؟
- NDCG؟
- MRR؟
- Answer Correctness؟
- Faithfulness؟
- Citation Accuracy؟
- Latency؟
- Token Usage؟
جمعبندی
اگر بخواهیم RAG را در یک جمله تعریف کنیم:
RAG معماریای است که دانش خارجی را قبل از تولید پاسخ بازیابی میکند و آن را بهعنوان Context در اختیار مدل زبانی قرار میدهد.
اما یک RAG واقعی فقط:
Embedding + Qdrant + LLM
نیست.
و مهمترین اصل این است:
RAG را نباید با کیفیت LLM بهتنهایی ارزیابی کرد.
باید بدانیم کدام لایه خراب است:
آیا اطلاعات پیدا نشده؟ رتبهبندی بد بوده؟ Evidence ناقص بوده؟ مدل پاسخ را اشتباه ساخته؟ یا سیستم اصلاً نباید پاسخ میداده؟
