MODULE 04 / LESSON 31

Evaluating Your LLM's Performance در سیستم RAG

بعد از ساخت اولین سیستم RAG یا هنگام بهبود یک سیستم موجود، باید بدانیم: آیا LLM واقعاً خوب کار می‌کند؟ مثلاً: آیا تغییر Temperature بهتر شده؟ آیا System Prompt جدید نتیجه بهتری داده؟ آیا مدل جدید بهتر است؟ آیا هزینه بیشتر ارزش…

نویسنده: محمد ابوطالبی۸۴۰ واژهماژول ۴: LLM & Prompting

بعد از ساخت اولین سیستم 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ها:

  1. Response Relevancy
  2. Faithfulness
  3. Context Relevancy
  4. 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

یعنی فقط تولید متن زیبا مهم نیست؛ تولید پاسخ دقیق، قابل استناد و قابل اعتماد هدف اصلی است.