ساخت یک Custom Evaluation Dataset یکی از مهمترین کارها برای تبدیل یک RAG آزمایشی به یک سیستم Production واقعی است.
ایده اصلی:
به جای تست کردن RAG با سؤالهای فرضی، از سؤالهای واقعی کاربران استفاده کنیم و ببینیم تغییرات سیستم چه اثری روی عملکرد واقعی دارد.
1. Custom Dataset چیست؟
یک مجموعه داده از درخواستهایی است که سیستم قبلاً پردازش کرده است.
حداقل شامل:
{
"user_prompt": "...",
"rag_response": "..."
}
اما میتواند اطلاعات بسیار بیشتری ذخیره کند.
مثلاً:
{
"prompt":
"How can I return my product?",
"rewritten_query":
"product return policy",
"retrieved_documents":
[
"return_policy.pdf",
"refund_rules.pdf"
],
"reranker_scores":
[
0.91,
0.72
],
"final_answer":
"You can return within 30 days..."
}
2. چه اطلاعاتی ذخیره کنیم؟
سؤال اصلی:
چه چیزی را میخواهیم ارزیابی کنیم؟
سطح ساده: End-to-End Evaluation
اگر فقط کیفیت نهایی مهم است:
ذخیره کنیم:
Input Prompt
سؤال کاربر:
How do I cancel my subscription?
Final Response
جواب سیستم:
You can cancel from account settings.
با همین دو مورد میتوانیم بررسی کنیم:
- آیا Prompt بهتر شد؟
- آیا مدل جدید بهتر جواب میدهد؟
3. Component-Level Evaluation
اگر بخواهیم بفهمیم مشکل کجاست، اطلاعات بیشتری لازم داریم.
مثلاً:
Retriever
ذخیره:
User Query
↓
Retrieved Documents
Query Rewriter
ذخیره:
Original:
How do I fix this?
Rewritten:
Troubleshooting procedure for device error
Re-ranker
ذخیره:
قبل:
doc5
doc8
doc12
بعد:
doc12
doc5
doc8
Agent Workflow
اگر Agentic RAG داریم:
ذخیره:
خروجی هر Agent:
Router LLM:
Need retrieval = YES
Evaluator LLM:
Need more documents = YES
4. جدول Logging در Production
در سیستم واقعی جدول لاگ ممکن است دهها ستون داشته باشد.
مثلاً:
| Field | توضیح |
|---|---|
| request_id | شناسه درخواست |
| user_id | کاربر |
| timestamp | زمان |
| prompt | سؤال |
| rewritten_query | Query اصلاح شده |
| retrieved_chunks | متنهای پیدا شده |
| embedding_model | مدل embedding |
| reranker_score | امتیاز reranker |
| llm_model | مدل LLM |
| temperature | تنظیمات sampling |
| response | جواب نهایی |
| latency | زمان پاسخ |
5. چرا ذخیره جزئیات مهم است؟
چون میتوانیم مشکل را پیدا کنیم.
مثال:
یک Chatbot فروشگاهی داریم.
گزارش کاربران:
سؤالهای مربوط به تأخیر ارسال جواب خوبی نمیگیرند.
با Dataset بررسی میکنیم:
موضوع:
Shipping Delay
نتیجه:
Refund Questions:
Quality = 95%
Shipping Questions:
Quality = 45%
حالا Trace را بررسی میکنیم:
میبینیم:
Question:
Where is my delayed order?
Retriever:
Returned:
Refund Policy
Payment Guide
مشکل:
Retriever اطلاعات مناسب ندارد.
راهحل:
- اضافه کردن Document جدید
- بهبود Chunking
- تغییر Embedding Model
6. مثال واقعی Production
یک تیم یک RAG ساخته بود که:
- متن تولید میکرد
- تصویر میساخت
- نمودار با Mermaid.js تولید میکرد
مشکل:
کاربران میگفتند:
نمودارها کیفیت خوبی ندارند.
با بررسی Logs:
مشخص شد:
کاربر گفته:
Draw a flowchart
Router LLM اشتباه تشخیص داده:
Image generation required
بنابراین درخواست رفت به:
Text-to-image Model
در حالی که باید میرفت:
Code generation → Mermaid.js
راهحل:
فقط System Prompt مربوط به Router تغییر کرد.
نتیجه:
Diagram request
↓
Mermaid code
↓
Correct chart
7. تحلیل دستهای دادهها
وقتی داده زیاد شد، فقط نگاه کردن به تک تک Promptها کافی نیست.
باید Visualization داشته باشیم.
مثلاً:
Prompt Clustering
با Embedding:
کاربران را گروهبندی کنیم.
نتیجه:
Cluster 1:
Refund questions
Cluster 2:
Shipping problems
Cluster 3:
Account issues
بعد جداگانه Evaluation کنیم:
مثلاً:
Refund:
Faithfulness 95%
Shipping:
Faithfulness 60%
8. اتصال به Evaluation Pipeline
معماری:
User
↓
RAG System
↓
Logging Layer
↓
Custom Dataset
↓
Evaluation Pipeline
↓
Metrics + Dashboard
9. کاربردهای Custom Dataset
با داشتن Dataset واقعی میتوانیم:
تغییر LLM را تست کنیم
مثلاً:
قبل:
GPT-4
Faithfulness:
88%
بعد:
Claude
Faithfulness:
93%
تغییر Prompt را تست کنیم
Prompt A:
Answer normally
Prompt B:
Only use retrieved documents
تغییر Retriever
مقایسه:
BM25
vs
Hybrid Search
vs
Vector Search
10. نکات طراحی Custom Dataset
1. همیشه Prompt اصلی را نگه دار
چون مهمترین داده است.
2. Response نهایی را ذخیره کن
برای مقایسه نسخهها.
3. Context بازیابی شده را ذخیره کن
برای Debug Retriever.
4. Versioning داشته باش
مثلاً:
dataset_v1
dataset_v2
چون ممکن است:
- Knowledge Base تغییر کند
- Prompt تغییر کند
- مدل تغییر کند
معماری Production پیشنهادی
User
↓
RAG Application
↓
----------------------------
| |
Response Logs
|
↓
Custom Evaluation Dataset
|
----------------------------
| |
RAGAS Evaluation Human Feedback
|
↓
Improvement Cycle
نکته کلیدی درس
Custom Dataset یعنی:
ثبت حافظه واقعی سیستم.
بدون آن فقط حدس میزنیم که RAG بهتر شده یا نه.
با آن میتوانیم:
- مشکل را پیدا کنیم
- تغییرات را اندازه بگیریم
- کیفیت را دائماً بهتر کنیم
در Production RAG، داده واقعی کاربران بهترین Dataset ارزیابی است.