MODULE 05 / LESSON 38

Customized Evaluation در RAG

ساخت یک Custom Evaluation Dataset یکی از مهم‌ترین کارها برای تبدیل یک RAG آزمایشی به یک سیستم Production واقعی است. ایده اصلی: به جای تست کردن RAG با سؤال‌های فرضی، از سؤال‌های واقعی کاربران استفاده کنیم و ببینیم تغییرات سیستم چه…

نویسنده: محمد ابوطالبی۹۹۳ واژهماژول ۵: Productionشامل افزودهٔ پژوهشی ۲۰۲۶

ساخت یک 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 ارزیابی است.