تا اینجا تمام مهارت‌های لازم برای طراحی و ساخت یک سیستم RAG را یاد گرفتیم:
- طراحی Retriever
- Vector Database
- Embedding
- Chunking
- Query Parsing
- Re-ranking
- Prompt Engineering
- کنترل LLM
- کاهش Hallucination
- Agentic RAG
اما زمانی که بخواهیم این سیستم را واقعاً در محیط Production اجرا کنیم، چالش‌های جدیدی ظاهر می‌شوند.
تفاوت Prototype و Production
یک نمونه آزمایشی ممکن است:
User
↓
Retriever
↓
LLM
↓
Answer
باشد.
اما در Production باید بدانیم:
- آیا سیستم همیشه درست جواب می‌دهد؟
- چرا بعضی جواب‌ها بد هستند؟
- هزینه هر درخواست چقدر است؟
- latency چقدر است؟
- کدام بخش باعث مشکل شده؟
- بعد از تغییر مدل بهتر شد یا بدتر؟
بخش‌های اصلی Module 5
این ماژول روی Production Engineering برای RAG تمرکز دارد.
چهار موضوع اصلی:
1. Evaluation در Production
اولین موضوع:
چگونه بفهمیم RAG ما خوب کار می‌کند؟
در محیط واقعی باید بخش‌های مختلف را جداگانه ارزیابی کنیم:
Retriever Evaluation
بررسی:
- آیا Document درست پیدا می‌کند؟
- آیا Chunk مناسب انتخاب شده؟
- آیا Search Quality خوب است؟
Metricها:
- Recall
- Precision
- MRR
- MAP
LLM Evaluation
بررسی:
- آیا پاسخ درست است؟
- آیا Hallucination دارد؟
- آیا به Context وفادار است؟
Metricها:
- Faithfulness
- Answer Relevance
- Citation Accuracy
System Evaluation
کل سیستم:
User Question
↓
Retriever
↓
LLM
↓
Final Answer
بررسی می‌شود.
2. Observability و Monitoring
در Production فقط Score کافی نیست.
باید بتوانیم سیستم را مشاهده کنیم.
مثلاً:
کاربر می‌گوید:
جواب اشتباه گرفتم.
باید بدانیم:
آیا مشکل از:
Query
↓
Retriever
↓
Wrong Documents?
↓
LLM
↓
Bad Generation?
است؟
برای این کار نیاز به:
Logging
داریم.
Logging در RAG
هر Request باید قابل Trace باشد.
مثلاً:
{
"query":
"What is refund policy?",
"retrieved_documents":
[
"policy.pdf",
"faq.pdf"
],
"reranker_score":
0.87,
"model":
"GPT",
"temperature":
0.2,
"response":
"..."
}
با این اطلاعات می‌توان فهمید:
- چه چیزی پیدا شده؟
- مدل چه چیزی دیده؟
- چرا جواب داده؟
3. ساخت Dataset از رفتار واقعی کاربران
یکی از مهم‌ترین بخش‌های Production:
ساخت Evaluation Dataset واقعی.
در ابتدا ممکن است:
Manual Dataset:
Question 1
Expected Answer
Question 2
Expected Answer
بسازیم.
اما بعد از Production:
کاربران واقعی بهترین داده هستند.
مثلاً:
از Traffic:
User Question
+
Retrieved Context
+
Generated Answer
+
User Feedback
ذخیره می‌کنیم.
بعد:
Dataset می‌سازیم:
Test Dataset
Question:
...
Expected:
...
Actual:
...
حالا هر تغییر:
- مدل جدید
- Prompt جدید
- Retriever جدید
را روی همین Dataset تست می‌کنیم.
4. Trade-offهای Production RAG
در Production همیشه باید بین چند چیز تعادل برقرار کنیم.
کیفیت
↑
اما:
هزینه بیشتر
سرعت
↑
اما:
ممکن است کیفیت کم شود.
سه عامل مهم:
Cost
هزینه LLM.
راهکارها:
- مدل کوچک‌تر
- Cache
- کاهش Token
- Prompt کوتاه‌تر
- استفاده از مدل‌های تخصصی کوچک
Latency
زمان پاسخ.
راهکارها:
- Parallel Retrieval
- Streaming
- مدل سریع‌تر
- کاهش تعداد LLM Call
Memory
فضای ذخیره‌سازی.
مخصوصاً:
Vector Database
مثال:
Bi-Encoder:
Document
↓
1 Vector
ColBERT:
Document
↓
1000 Token
↓
1000 Vector
کیفیت بیشتر، حافظه بیشتر.
5. Multimodal RAG
RAG فقط برای متن نیست.
در Production ممکن است Knowledge Base شامل:
- متن
- تصویر
- نمودار
- اسکن
- فایل صوتی
باشد.
مثال:
یک PDF پزشکی:
Text
+
X-Ray Image
+
Table
سیستم باید بتواند:
- تصویر را درک کند
- متن استخراج کند
- ارتباط بین آن‌ها را پیدا کند
معماری:
PDF/Image
↓
Multimodal Embedding
↓
Vector Database
↓
Retriever
↓
Multimodal LLM
↓
Answer
هدف اصلی Module 5
در پایان این ماژول باید بتوانید:
یک RAG بسازید که فقط کار کند نه اینکه فقط Demo باشد.
یعنی:
Prototype RAG
↓
Evaluation
↓
Monitoring
↓
Optimization
↓
Production RAG
جمع‌بندی Module 5
موضوعات اصلی:
| بخش | هدف |
|---|---|
| RAG Evaluation | اندازه‌گیری کیفیت |
| Observability | فهمیدن مشکل سیستم |
| Logging | Trace کردن درخواست‌ها |
| Dataset Creation | تست تغییرات |
| Optimization | کاهش هزینه و latency |
| Multimodal RAG | کار با تصویر و PDF |
هدف نهایی:
ساخت یک سیستم RAG قابل اعتماد، قابل اندازه‌گیری و آماده استفاده واقعی در مقیاس بالا.