ارزیابی پایپ‌لاین RAG: معیارهای بازیابی، رتبه‌بندی و پاسخ

وقتی یک سیستم تولید متن مبتنی بر بازیابی (RAG) پاسخ غلط تولید می‌کند، ریشه‌یابی خطا بدون معیارهای کمی دقیق غیرممکن است. بسیاری از تیم‌ها خطای پاسخ نهایی را به‌اشتباه گردن مدل زبانی می‌اندازند؛ در حالی که ممکن است مشکل اصلی از مرزبندی نامناسب قطعات متن (chunking)، ناتوانی بخش بازیابی در یافتن سند، یا رتبه‌بندی نادرست قطعات توسط بازرتبه‌بند باشد.

در این درس یاد می‌گیرید که چطور پایپ‌لاین RAG را به دو بخش ارزیابی بازیابی (شامل Precision@k، Recall@k، MRR و nDCG) و ارزیابی تولید پاسخ (شامل وفاداری و ارتباط پاسخ) تقسیم کنید و روی یک فایل داده‌ی آزمون برچسب‌خورده (qrels)، این سنجه‌ها را به‌طور قطعی و آفلاین بسنجید تا دقیقاً بدانید هر تغییر مهندسی در کجای سیستم اثرگذار است.

اگر نتوانید بازیابی و پاسخ نهایی را به‌طور هم‌زمان ارزیابی کنید، نمی‌توانید سیستم را به محیط عملیاتی (پروداکشن) بفرستید. این دو یک معیار نیستند و یک پرامپت یکسان ممکن است در محورهای متفاوتی شکست بخورد.

اهداف یادگیری

• محاسبه‌ی چهار معیار بازیابی از روی مجموعه‌ی برچسب‌خورده‌ی مرجع (gold qrels): معیار precision@k، معیار recall@k، معیار MRR (میانگین رتبه‌ی معکوس یا mean reciprocal rank) و nDCG@k.
• محاسبه‌ی دو معیار ارزیابی پاسخ: وفاداری (faithfulness؛ ارجاع کامل تمام ادعاها به بافت بازیابی‌شده) و ارتباط پاسخ (answer relevance؛ این‌که پاسخ به خود پرسش پرداخته باشد).
• ساخت یک فایل داده‌ی آزمون ثابت (fixture qrels شامل پرسش‌ها، شناسه‌ی اسناد مرجع و متن پاسخ مرجع) که فرآیند ارزیابی آن را به‌صورت سرتاسری (end-to-end) بخواند.
• تحلیل مقادیر این معیارها برای ریشه‌یابی محل شکست پایپ‌لاین: بازیابی، رتبه‌بندی، تولید متن یا ارجاع‌دهی مکانی (grounding).

صورت مسئله

یک سیستم RAG حداقل از چهار بخش متحرک تشکیل شده است: قطعه‌بند (chunker)، بازیاب (retriever)، بازرتبه‌بند (reranker) و تولیدکننده (generator). هرکدام از این بخش‌ها می‌توانند علت ایجاد یک پاسخ اشتباه باشند. بدون داشتن معیارهای تفکیک‌شده برای هر مرحله، در تاریکی مطلق حرکت می‌کنید.

کاربری گزارش می‌دهد که پاسخ اشتباه دریافت کرده است. آیا به این دلیل است که قطعه‌بند، بخش پاسخ (answer span) را بریده است؟ آیا بازیاب نتوانسته قطعه را در میان k خروجی برتر (top-k) بیاورد؟ یا شاید بازرتبه‌بند قطعه‌ی درست را از رتبه‌ی اول به پایین push کرده است؟ شاید هم تولیدکننده اصلاً قطعه را نادیده گرفته و از خودش پاسخی سرهم کرده است؟ پاسخ نهایی به‌تنهایی هیچ‌کدام از این موارد را نشان نمی‌دهد. شما به این ابزارها نیاز دارید:

• معیارهای بازیابی برای سنجش کیفی خروجی بازیاب.
• معیارهای رتبه‌بندی برای سنجش جایگاه قطعه‌ی درست در ترتیب نتایج.
• وفاداری برای سنجش این‌که آیا مدل تولیدکننده در چارچوب بافت بازیابی‌شده مانده است یا نه.
• ارتباط پاسخ برای سنجش این‌که آیا پاسخ اصلاً به پرسش پرداخته است یا خیر.

در این درس هر شش معیار را روی یک فایل داده‌ی آزمون qrels پیاده‌سازی می‌کنیم. این ارزیابی به‌صورت آفلاین و قطعی (deterministic) اجرا می‌شود؛ در محیط عملیاتی (پروداکشن)، مدل زبانی در نقش داور (LLM-as-judge) ماکت را با یک مدل واقعی جایگزین می‌کنید.

مفاهیم پایه

Precision@k

از میان k سند برتری که بازیاب برگردانده، چه کسری از آن‌ها در مجموعه‌ی مرجع (gold set) وجود دارند؟ اگر مجموعه‌ی مرجع شامل 3 سند باشد و 3 خروجی برتر شامل 2 سند درست و 1 سند اشتباه باشند، مقدار precision@3 برابر 2 / 3 خواهد بود. زمانی از دقت (precision) استفاده کنید که هزینه‌ی بازگرداندن یک قطعه‌ی نامرتبط بالا باشد (مثلاً تولیدکننده توکن‌هایش را روی آن هدر دهد یا قطعه پاسخ را مسموم کند).

Recall@k

چه کسری از اسناد مرجع در میان k سند برتر قرار گرفته‌اند؟ اگر مجموعه‌ی مرجع شامل 3 سند باشد و 5 سند برتر هر سه را در بر داشته باشند، مقدار recall@5 برابر 1.0 است. زمانی از بازخوانی (recall) استفاده کنید که هزینه‌ی از دست دادن یک پاسخ بالا باشد (یعنی ترجیح می‌دهید یک قطعه‌ی نامرتبط اضافه ببینید، اما قطعه‌ی حاوی پاسخ را کاملاً از دست ندهید).

در RAG محیط عملیاتی (پروداکشن)، معیاری که معمولاً گزارش می‌شود recall@k است؛ زیرا بخش تولید متن می‌تواند قطعات نامرتبط را به‌راحتی کنار بگذارد، اما هرگز نمی‌تواند پاسخی را از روی قطعه‌ای که اصلاً ندیده خلق کند.

MRR (میانگین رتبه‌ی معکوس)

برای هر پرسش، جایگاه اولین سند مرتبط در لیست رتبه‌بندی‌شده را پیدا کنید. رتبه‌ی معکوس برابر 1 / position است. سپس میانگین آن را در کل پرسش‌ها محاسبه کنید. معیار MRR خلاصه‌ای تک‌عددی از توانایی بازیاب در قرار دادن بهترین پاسخ در بالاترین جایگاه است.

معیار MRR وزن بسیار سنگینی به رتبه‌ی 1 می‌دهد. پرسشی که سند مرجع در آن در رتبه‌ی 1 قرار دارد، سهم 1.0 می‌گیرد. رتبه‌ی 2 سهم 0.5 و رتبه‌ی 10 سهم 0.1 دارد. بنابراین وضعیت صدر لیست، مقدار این معیار را تعیین می‌کند.

nDCG@k

سود تجمعی تخفیف‌خورده‌ی نرمال‌شده (Normalized Discounted Cumulative Gain). در فرمول کامل، به هر سند بازیابی‌شده یک امتیاز سود داده می‌شود (معمولاً 1 برای مرتبط و 0 برای نامرتبط)، این امتیاز بر لگاریتم موقعیت تقسیم می‌شود، حاصل جمع می‌گردد و بر مقدار ایده‌آل DCG (همان مقداری که در رتبه‌بندی بی‌نقص به دست می‌آمد) تقسیم می‌شود. دامنه‌ی این معیار بین 0 تا 1 است.

معیار nDCG ارتباط درجه‌بندی‌شده (graded relevance) را پشتیبانی می‌کند؛ به این معنی که مجموعه‌ی مرجع می‌تواند مشخص کند «سند A امتیاز 3، سند B امتیاز 2 و سند C امتیاز 1 دارد». در مقابل، MRR و recall@k همه‌چیز را باینری و صفر و یکی می‌بینند. زمانی از nDCG استفاده کنید که در مجموعه‌ی داده‌هایتان برای هر پرسش، چندین سند با درجات ارتباط متفاوتی وجود دارد.

وفاداری (Faithfulness)

برای تک‌تک ادعاهای مطرح‌شده در پاسخ نهایی بررسی کنید که آیا بافت بازیابی‌شده آن را پشتیبانی می‌کند یا خیر. پیاده‌سازی استاندارد این کار از یک پرامپت LLM-as-judge استفاده می‌کند که ورودی‌های (claim, context) را می‌گیرد و پاسخ «بله» یا «خیر» می‌دهد. خروجی این معیار، کسری از ادعاهاست که تأیید شده‌اند.

معیار وفاداری همان حالت شکستی را در بخش تولید تشخیص می‌دهد که در آن مدل از خودش اطلاعات می‌سازد. حتی اگر بازیاب قطعات درستی را برگردانده باشد، تولیدکننده‌ای که دچار توهم می‌شود خراب است. وفاداری را با نام‌هایی مثل ارجاع‌دهی مکانی (groundedness)، پشتیبانی (support) و اسناددهی (attribution) نیز می‌شناسند.

این درس وفاداری را با یک داور ماکت قطعی پیاده‌سازی می‌کند؛ به این صورت که بررسی می‌کند آیا توکن‌های هر ادعا بیش از یک آستانه مشخص با بافت بازیابی‌شده هم‌پوشانی دارند یا نه. در محیط عملیاتی (پروداکشن)، این بخش را با فراخوانی یک مدل واقعی جایگزین می‌کنید. ساختار کلی معیار دقیقاً همین خواهد بود.

ارتباط پاسخ (Answer Relevance)

آیا پاسخ تولیدشده واقعاً به پرسش طرح‌شده جواب می‌دهد؟ وفاداری این سؤال را می‌پرسد: «آیا پاسخ متکی بر بافت است؟». اما ارتباط پاسخ می‌پرسد: «آیا پاسخ متکی بر پرسش است؟». پاسخی که کاملاً وفادار به متن بازیابی‌شده ولی بی‌ربط به سؤال باشد، در وفاداری امتیاز بالا و در ارتباط پاسخ امتیاز پایینی می‌گیرد. برعکس، پاسخی کوتاه و مرتبط با سؤال که بافت ارائه‌شده را کاملاً نادیده گرفته باشد، در ارتباط امتیاز بالا و در وفاداری امتیاز پایینی می‌گیرد.

پیاده‌سازی استاندارد این مورد نیز از LLM-as-judge استفاده می‌کند: ورودی‌های (question, answer) را به آن می‌دهید و می‌پرسید که آیا پاسخ به پرسش پرداخته است یا خیر. این درس یک جایگزین بر پایه‌ی هم‌پوشانی توکن‌ها همراه با داور را پیاده می‌کند.

داده‌های آزمون qrels

{
  "qid": "q1",
  "query": "what is the abort threshold for multipart uploads",
  "gold_doc_ids": ["d1", "d3"],
  "gold_answer_substring": "three failed parts",
  "graded_relevance": {"d1": 3, "d3": 2},
}

هر پرسش شامل این موارد است:

• متن پرسش،
• مجموعه‌ای از شناسه‌های اسناد مرجع (برای محاسبه‌ی precision / recall / MRR)،
• یک دیکشنری از درجات ارتباط (برای nDCG)،
• زیررشته‌ی پاسخ مرجع (که به‌عنوان متادیتای مرجع روی هر qrel نگهداری می‌شود؛ در این درس وفاداری با ارزیابی ادعاهای استخراج‌شده در برابر بافت بازیابی‌شده سنجیده می‌شود، نه در برابر این زیررشته).

در پروداکشن شما این موارد را برچسب‌گذاری می‌کنید. این درس یک نمونه‌ی دست‌ساز آماده ارائه می‌دهد تا ارزیابی بدون نیاز به تنظیمات خاصی بلافاصله اجرا شود.

پیاده‌سازی

فایل code/main.py این توابع را پیاده‌سازی می‌کند:

• precision_at_k(retrieved, gold, k) - پیاده‌سازی دقیق تعریف ریاضی.
• recall_at_k(retrieved, gold, k) - پیاده‌سازی دقیق تعریف ریاضی.
• mean_reciprocal_rank(retrieved_list_of_lists, gold_list) - میانگین روی کل پرسش‌ها.
• ndcg_at_k(retrieved, graded_relevance, k) - مقدار DCG / IDCG با امتیازهای باینری یا درجه‌بندی‌شده.
• extract_claims(answer) - تفکیک یک پاسخ به ادعاهایی در قالب جملات.
• faithfulness(claims, context_texts, judge) - کسری از ادعاها که پشتیبانی آن‌ها توسط داور تأیید شده است.
• answer_relevance(question, answer, judge) - قضاوت داور درباره‌ی این‌که آیا پاسخ به پرسش مربوط است یا خیر.
• MockJudge - داور قطعی مبتنی بر هم‌پوشانی توکن‌ها برای اجرای آفلاین ارزیابی.
• evaluate_pipeline(pipeline_fn, qrels, ks) - هماهنگ‌کننده‌ای (orchestrator) که تمام این معیارها را اجرا می‌کند.
• دموای که سه گونه‌ی مختلف پایپ‌لاین (خط مبنای قطعه‌بند، بازیابی ترکیبی و بازیابی ترکیبی + بازرتبه‌بندی) را روی qrels اجرا می‌کند و جدول معیارها را در خروجی می‌آورد.

اجرای آن:

python3 code/main.py

خروجی برنامه مقادیر precision@k، recall@k، MRR، nDCG@k، وفاداری و ارتباط پاسخ را برای هر گونه در یک جدول واحد نمایش می‌دهد. ردیف بازیابی ترکیبی در بازخوانی نسبت به خط مبنای قطعه‌بند برتر است؛ ردیف بازرتبه‌بندی نیز در معیار MRR از بازیابی ترکیبی پیشی می‌گیرد.

تحلیل معیارها برای ریشه‌یابی خطاها

حالت‌های شکستی که این دمو نشان نمی‌دهد

سوگیری مدل در نقش داور (LLM-as-judge bias). مدل‌ها خروجی‌های خودشان را وفادارتراز آن‌چه واقعاً هستند ارزیابی می‌کنند. برای داور از خانواده‌ی مدلی متفاوتی نسبت به مدل تولیدکننده استفاده کنید یا نمونه‌ای از خروجی‌ها را به‌صورت دستی ارزیابی نمایید.

پوسیدگی داده‌های مرجع (Qrels rot). هم‌زمان با تغییر اسناد و متون، پاسخ‌های مرجع هم تغییر می‌کنند. سندی که در ژانویه‌ی 2024 پاسخ مرجع سؤال 1 بوده، ممکن است در اکتبر 2024 دیگر پاسخ درستی نباشد چون تیم نام یک تابع را تغییر داده است. یک برنامه‌ی بازبینی فصلی برای داده‌های qrels در نظر بگیرید.

بررسی‌های ریزبینانه‌ی وفاداری، خطاهای کلان را نادیده می‌گیرند. وفاداری تک‌تک جملات ممکن است تأیید شود، اما ساختار کلی پاسخ نهایی گمراه‌کننده باشد. علاوه بر معیارهای خودکار، بازبینی کیفی روی نمونه‌ها انجام دهید.

معیار Recall@k شکست‌های موردی در پرسش‌ها را پنهان می‌کند. میانگین بازخوانی 90 درصدی می‌تواند این واقعیت را پنهان کند که یک دسته‌ی خاص از پرسش‌ها همیشه با شکست مواجه می‌شوند. فایل qrels را بر اساس نوع پرسش (عینی، بازنویسی‌شده، چندموضوعی) دسته‌بندی و قطعه‌بندی کنید و گزارش را به‌تفکیک هر بخش ثبت نمایید.

استفاده از الگوها در محیط عملیاتی

الگوهای محیط عملیاتی:

• ارزیابی را بعد از هر تغییر در بازیاب یا تولیدکننده اجرا کنید. با افت در معیار recall@k مانند خطای تست‌های نرم‌افزاری برخورد کنید.
• ردگیری محاسبات (trace) معیارها را به‌ازای هر پرسش ذخیره کنید. وقتی کاربری شکایتی ثبت کرد، رکورد متناظر را در qrels بررسی کنید تا ببینید آیا تست‌ها این خطا را شناسایی می‌کردند یا نه.
• داده‌های qrels را سطح‌بندی کنید: یک دسته‌ی تست سریع (smoke set) با 20 پرسش برای اجرا در CI؛ یک دسته‌ی تست رگرسیون با 200 پرسش برای اجرای شبانه؛ و یک دسته‌ی عمیق با 2000 پرسش برای اجرای هفتگی.

آماده‌سازی نهایی

درس 69 تمام اجزای پایپ‌لاین (قطعه‌بند، بازیاب، بازرتبه‌بند و تولیدکننده) را به هم متصل کرده و این ارزیابی را روی کل سیستم به‌صورت سرتاسری اجرا می‌کند.

تمرین‌ها

1. یک معیار بازیابی پنجم به نام نرخ اصابت در k (hit-rate@k) اضافه کنید. آن را با recall@k مقایسه کرده و مواردی را که این دو تفاوت دارند توضیح دهید.
2. وفاداری درجه‌بندی‌شده را پیاده کنید: 0 (بدون پشتیبانی متن)، 1 (پشتیبانی نسبی)، 2 (پشتیبانی کامل). سپس معیار را بر این اساس به‌روزرسانی کنید.
3. داور ماکت را با فراخوانی یک مدل واقعی جایگزین کنید. میزان اختلاف قضاوت میان داور ماکت و داور واقعی را روی داده‌های تستی بسنجید.
4. دسته‌بندی پرسش‌ها را پیاده کنید ("عینی"، "بازنویسی‌شده"، "چندموضوعی") و معیارها را به‌تفکیک این دسته‌ها گزارش دهید.
5. معیاری برای «طول پاسخ» اضافه کرده و همبستگی آن با وفاداری را بررسی کنید. سپس نمودار آن را رسم نمایید.

اصطلاحات کلیدی

برای مطالعه‌ی بیشتر

• مقاله‌ی Buckley, Voorhees با عنوان «Evaluating Evaluation Measure Stability» در SIGIR 2000؛ مقاله‌ی مرجع کلاسیک در زمینه‌ی معیارهای رتبه‌بندی
• مقاله‌ی Jarvelin, Kekalainen با عنوان «Cumulated Gain-based Evaluation of IR Techniques»؛ مقاله‌ی اصلی معرفی‌کننده‌ی nDCG
• Ragas: Automated Evaluation of RAG Pipelines
• Anthropic, Introducing Contextual Retrieval؛ ارزیابی بازیابی با فرمول 1 منهای recall@20
• فاز 11 درس 10 - مبانی چارچوب‌های ارزیابی
• فاز 19 درس‌های 64 تا 67 - اجزایی که در این درس ارزیابی می‌شوند
• فاز 19 درس 69 - پایپ‌لاین سرتاسری که این ارزیابی آن را می‌سنجد