بعد از اینکه RAG وارد محیط Production می‌شود، مهم‌ترین سؤال این است:
آیا سیستم واقعاً خوب کار می‌کند؟
صرفاً اینکه پاسخ تولید می‌شود کافی نیست.
باید بدانیم:
- سریع است؟
- هزینه مناسب دارد؟
- Retriever خوب کار می‌کند؟
- LLM جواب باکیفیت می‌دهد؟
- کاربران راضی هستند؟
برای این کار به یک سیستم Observability + Evaluation نیاز داریم.
1. سیستم Observability در RAG
یک پلتفرم Observability باید چند نوع اطلاعات را جمع‌آوری کند.
بخش اول: Performance Metrics
معیارهای فنی سیستم:
Latency
زمان پاسخ‌دهی.
مثال:
User Question
↓
Retriever: 100ms
↓
LLM: 3s
↓
Total: 3.1s
Throughput
تعداد درخواست قابل پردازش.
مثلاً:
100 requests/sec
Memory Usage
مصرف RAM و VRAM.
مخصوصاً برای:
- Embedding Model
- Vector Database
- LLM
Compute Usage
مصرف:
- CPU
- GPU
این Metrics به ما می‌گویند:
آیا سیستم از نظر زیرساخت سالم است؟
بخش دوم: Quality Metrics
فقط سرعت مهم نیست.
باید کیفیت را هم بسنجیم.
مثلاً:
User Satisfaction
آیا کاربر جواب را قبول دارد؟
Retriever Quality
آیا Document درست پیدا شده؟
مثلاً:
Question:
How to reset password?
Retrieved:
✓ Password Reset Guide
✗ Employee Vacation Policy
LLM Quality
آیا LLM:
- جواب مرتبط داده؟
- Hallucination داشته؟
- Citation درست داده؟
2. دو نوع خروجی Evaluation
یک سیستم ارزیابی خوب دو نوع خروجی دارد:
A) Aggregate Statistics
اطلاعات کلی در طول زمان.
مثلاً:
Daily Report
Average latency:
2.3 sec
Retriever recall:
87%
User satisfaction:
92%
برای پیدا کردن:
- Trend
- Regression
- افت کیفیت
استفاده می‌شود.
B) Detailed Logs
لاگ جزئی هر درخواست.
مثلاً:
Request ID: 12345
User Query:
"What is refund policy?"
Retriever:
Returned:
doc1
doc5
doc9
LLM Prompt:
(system + context + question)
Final Answer:
....
این برای Debug بسیار مهم است.
مثلاً کاربر می‌گوید:
"جواب اشتباه بود"
می‌توانیم بفهمیم:
مشکل از کجاست؟
Question
↓
Wrong Retrieval?
↓
Wrong Prompt?
↓
LLM Hallucination?
3. امکان Experimentation
یک سیستم Production خوب باید اجازه آزمایش بدهد.
مثلاً:
می‌خواهیم تغییر دهیم:
- مدل LLM
- System Prompt
- Embedding Model
- Retriever Settings
باید بتوانیم:
A/B Testing
انجام دهیم.
مثلاً:
نسخه A:
GPT-4
temperature=0.7
نسخه B:
Claude
temperature=0.3
بعد مقایسه کنیم:
- کیفیت
- هزینه
- سرعت
4. چارچوب ارزیابی RAG
برای طراحی Evaluation دو محور مهم داریم:
محور اول: Scope
یعنی چه چیزی را ارزیابی می‌کنیم؟
دو حالت:
1. Component-level Evaluation
ارزیابی یک بخش خاص.
مثلاً:
Retriever.
سؤال:
آیا Document درست پیدا می‌کند؟
یا:
LLM.
سؤال:
آیا جواب درست تولید می‌کند؟
2. System-level Evaluation
کل سیستم.
مثلاً:
کاربر سؤال می‌پرسد:
آیا پاسخ نهایی خوب است؟
مثال:
مشکل:
Total Latency = 8 sec
برای پیدا کردن علت:
Component Evaluation لازم است.
بررسی:
Retriever:
200ms
Embedding:
100ms
LLM:
7.7s
مشخص می‌شود مشکل LLM است.
محور دوم: Evaluator Type
سه روش اصلی داریم:
1. Code-based Evaluation
ارزان‌ترین روش.
با کد انجام می‌شود.
مثال:
Latency
response_time = end - start
Throughput
requests / second
JSON Validation
مثلاً:
LLM باید:
{
"name":"Ali",
"age":20
}
برگرداند.
کد بررسی می‌کند:
Valid?
مزایا:
✅ سریع
✅ ارزان
✅ اتوماتیک
✅ Deterministic
2. Human Evaluation
انسان جواب را بررسی می‌کند.
مثال:
کاربر:
👍 Good
👎 Bad
یا:
فرم:
How useful was this answer?
1 2 3 4 5
مزیت:
انسان چیزهایی را می‌بیند که Metric نمی‌بیند.
مثلاً:
- لحن بد
- پاسخ غیرطبیعی
- اطلاعات ناقص
عیب:
- گران
- کند
3. LLM as a Judge
یک LLM دیگر، خروجی سیستم را ارزیابی می‌کند.
مثلاً:
Question:
What is refund policy?
Answer:
You can refund within 30 days.
Judge LLM:
Is answer relevant?
YES
مزایا:
بین دو روش قبلی است.
یعنی:
- ارزان‌تر از انسان
- انعطاف‌پذیرتر از Code
اما مشکل:
Bias دارد.
مثلاً:
یک مدل ممکن است پاسخ مدل خودش را بیشتر دوست داشته باشد.
نکته مهم در LLM Judge
بهتر است سؤال‌ها Binary باشند.
خوب:
Is this document relevant?
YES / NO
بد:
Rate from 0 to 100
5. یک معماری Evaluation پیشنهادی برای RAG
یک سیستم پایه:
RAG System
|
|
----------------------------
| |
Performance Quality
| |
Latency User Feedback
Throughput Retriever Recall
Memory LLM Evaluation
Tokens/sec Citation Quality
6. ارزیابی Retriever
برای Retriever معمولاً:
Human Annotation Dataset
ساخته می‌شود.
مثلاً:
Question:
How do I reset password?
Expected Documents:
doc12
doc45
بعد Metrics:
Precision
چقدر نتایج برگشتی درست بودند؟
فرمول:
[ Precision= \frac{Relevant Retrieved}{Total Retrieved} ]
مثال:
برگرداندیم:
10 سند
که:
8 تا مرتبط بودند.
Precision = 8/10 = 80%
Recall
چقدر از کل اطلاعات لازم را پیدا کردیم؟
مثلاً:
کل اسناد مرتبط:
10
پیدا شده:
8
Recall = 8/10 = 80%
7. ارزیابی LLM در RAG
برای LLM معمولاً از ابزارهایی مثل:
RAGAS
استفاده می‌شود.
معیارهای مهم:
Response Relevancy
آیا جواب به سؤال مربوط است؟
مثال:
Question:
How to reset password?
Answer:
Our company was founded in 1998.
Relevancy پایین است.
Faithfulness
آیا جواب بر اساس Context داده شده است؟
یعنی:
Hallucination دارد؟
مثال:
Retrieved:
Refund available within 30 days
Answer:
Refund available within 90 days
Faithfulness پایین.
Citation Quality
آیا منابع درست استفاده شده‌اند؟
8. یک ترکیب عملی پیشنهادی
برای شروع Production RAG:
| بخش | Metric |
|---|---|
| System | Latency |
| System | Throughput |
| System | Cost |
| Retriever | Recall |
| Retriever | Precision |
| LLM | Faithfulness |
| LLM | Response Relevancy |
| User | Thumbs Up/Down |
معماری نهایی پیشنهادی
User
|
RAG API
|
-------------------
| |
Retriever LLM
| |
Recall/Precision RAGAS Metrics
|
Logging Layer
|
Observability Dashboard
نکته کلیدی این درس
در Production RAG:
فقط ساختن سیستم مهم نیست.
باید بتوانی جواب بدهی:
- چرا جواب بد شد؟
- مشکل از Retriever بود یا LLM؟
- تغییر جدید بهتر شد یا بدتر؟
- آیا کاربران واقعاً راضی هستند؟
به همین دلیل:
Evaluation یک بخش اصلی از خود RAG است، نه یک مرحله بعد از آن.