بعد از ساخت اولین سیستم RAG یا هنگام بهبود یک سیستم موجود، باید بدانیم:
آیا LLM واقعاً خوب کار میکند؟
مثلاً:
- آیا تغییر Temperature بهتر شده؟
- آیا System Prompt جدید نتیجه بهتری داده؟
- آیا مدل جدید بهتر است؟
- آیا هزینه بیشتر ارزش کیفیت بالاتر را دارد؟
برای پاسخ، نیاز به Evaluation Metrics داریم.
تفاوت وظیفه Retriever و LLM
در یک سیستم RAG دو بخش اصلی داریم:
User Query
↓
Retriever
↓
Relevant Documents
↓
LLM
↓
Final Answer
وظیفه Retriever
Retriever مسئول:
- پیدا کردن اطلاعات مرتبط
- جستجو در Knowledge Base
- برگرداندن Documentهای مناسب
است.
وظیفه LLM
LLM مسئول:
- فهم سؤال کاربر
- استفاده از Context بازیابیشده
- ساخت پاسخ مناسب
- استفاده نکردن از اطلاعات بیربط
- Citation درست
است.
بنابراین اگر پاسخ بد است، اول باید مشخص کنیم مشکل کجاست:
Bad Answer
↓
Retriever مشکل دارد؟
یا
LLM مشکل دارد؟
مثال:
Retriever:
Wrong documents retrieved
مشکل:
❌ Prompt Engineering نیست
❌ تغییر مدل LLM نیست
مشکل:
✅ Retrieval Pipeline
اما اگر:
Retriever:
Correct documents retrieved
ولی جواب:
Wrong answer
مشکل:
✅ LLM
چرا Evaluation LLM سخت است؟
برخلاف Retriever که معیارهای مشخص دارد:
مثل:
- Precision
- Recall
- MAP
- MRR
ارزیابی LLM پیچیدهتر است.
چون باید بررسی کنیم:
- آیا جواب به سؤال مرتبط است؟
- آیا لحن مناسب است؟
- آیا اطلاعات را درست استفاده کرده؟
- آیا از Context خارج شده؟
اینها تا حدی ذهنی هستند.
راهحل: استفاده از LLM به عنوان داور
امروزه بسیاری از Evaluationها این شکلی هستند:
Generated Answer
↓
Another LLM
↓
Score
یعنی یک مدل دیگر کیفیت پاسخ را بررسی میکند.
RAGAS Library
یکی از معروفترین ابزارهای ارزیابی RAG:
RAGAS
است.
این کتابخانه Metricهای مخصوص RAG ارائه میدهد.
مهمترین Metricها:
- Response Relevancy
- Faithfulness
- Context Relevancy
- Citation Accuracy
1. Response Relevancy
سؤال:
آیا پاسخ واقعاً به سؤال کاربر مربوط است؟
مثال:
User:
What is the refund policy?
Answer:
Our company was founded in 1998.
از نظر اطلاعات شاید درست باشد،
اما مرتبط نیست.
پس:
Low Response Relevancy
روش محاسبه
مراحل:
مرحله 1
پاسخ تولید شده:
Generated Response
به یک LLM دیگر داده میشود.
مرحله 2
LLM داور چند سؤال احتمالی تولید میکند:
مثلاً:
Response:
You can return products within 30 days.
LLM میگوید:
Possible questions:
What is the return period?
How long do customers have to return items?
مرحله 3
Question اصلی و سؤالهای تولیدشده Embedding میشوند.
مرحله 4
Cosine Similarity محاسبه میشود.
فرمول مفهومی:
Original Query
|
|
Cosine Similarity
|
Generated Questions
نتیجه:
عدد بالاتر:
More relevant response
نکته مهم
Response Relevancy بررسی نمیکند:
آیا جواب درست است؟
فقط میپرسد:
آیا جواب مربوط به سؤال است؟
ممکن است:
Very relevant
ولی:
Factually wrong
باشد.
2. Faithfulness
مهمترین Metric برای کاهش Hallucination.
سؤال:
آیا پاسخ LLM واقعاً بر اساس Retrieved Context ساخته شده؟
مثال:
Retrieved Context:
Senior customers receive 10% discount.
Answer:
Students receive 10% discount.
پاسخ:
مرتبط است، اما در Context وجود ندارد.
پس:
Low Faithfulness
روش کار
مرحله 1
LLM تمام ادعاهای موجود در پاسخ را استخراج میکند.
مثلاً:
Answer:
The company offers 10% discount.
Students are eligible.
Claims:
Claim 1:
Company offers 10% discount.
Claim 2:
Students are eligible.
مرحله 2
برای هر Claim بررسی میشود:
آیا در Documents پشتیبانی میشود؟
مثلاً:
Claim 1 ✔ Supported
Claim 2 ✘ Not supported
فرمول:
Faithfulness =
Supported Claims / Total Claims
مثال:
5 ادعا داریم.
4 مورد پشتیبانی شده:
4/5 = 80%
3. بررسی Citation
یک RAG خوب باید بتواند بگوید:
این اطلاعات از کجا آمده.
مشکل:
LLM ممکن است Citation جعلی بسازد.
مثلاً:
Source:
company_policy.pdf
در حالی که وجود ندارد.
پس باید بررسی شود:
Claim
↓
Source Document
↓
Is it actually supported?
4. ارزیابی با Feedback کاربران
یک روش عملی:
داده واقعی کاربران.
مثلاً:
کاربر جواب را Rate کند:
👍 Good
👎 Bad
بعد:
A/B Testing انجام میدهیم.
مثلاً:
نسخه A:
Old System Prompt
نسخه B:
New System Prompt
مقایسه:
User Satisfaction A
vs
User Satisfaction B
اگر B بهتر بود:
تغییر موفق بوده.
ترکیب روشهای Evaluation
یک سیستم حرفهای معمولاً فقط یک Metric ندارد.
ترکیب:
RAG Evaluation
|
------------------------------------------------
Retriever Metrics
- Recall
- Precision
LLM Metrics
- Response Relevancy
- Faithfulness
- Citation Quality
Human Feedback
- User Rating
چه زمانی از کدام استفاده کنیم؟
| مشکل | Metric مناسب |
|---|---|
| جواب بیربط است | Response Relevancy |
| مدل اطلاعات میسازد | Faithfulness |
| منبع اشتباه است | Citation Accuracy |
| کاربر ناراضی است | Human Feedback |
| Retriever ضعیف است | Recall / Precision |
نکته مهم برای توسعه RAG
قبل از تغییر LLM همیشه بررسی کنید:
Bad Answer
↓
Retriever OK?
↓
Yes
↓
Change LLM / Prompt
خیلی از تیمها اشتباه میکنند و مشکل Retrieval را با تغییر مدل حل میکنند.
جمعبندی نهایی
ارزیابی LLM در RAG سخت است چون کیفیت پاسخ فقط با عدد ساده مشخص نمیشود.
بهترین روش:
1. RAGAS Metrics
+
2. LLM-as-a-Judge
+
3. Human Feedback
و مهمترین معیارهای LLM در RAG:
| Metric | بررسی |
|---|---|
| Response Relevancy | پاسخ چقدر به سؤال مربوط است |
| Faithfulness | پاسخ چقدر به Context وفادار است |
| Citation Quality | منابع درست هستند یا نه |
| User Feedback | تجربه واقعی کاربر |
هدف نهایی:
Retrieved Knowledge
+
LLM Reasoning
+
Evaluation Loop
↓
Reliable RAG System
یعنی فقط تولید متن زیبا مهم نیست؛ تولید پاسخ دقیق، قابل استناد و قابل اعتماد هدف اصلی است.