RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند

برای ارزیابی یک سامانهٔ RAG، مجموعه‌ای ثابت از سؤال‌ها بسازید و برای هر سؤال، شواهد لازم و پاسخ مورد انتظار را ثبت کنید. سپس کیفیت بازیابی را جدا از کیفیت پاسخ بسنجید: Context Precision و Context Recall نشان می‌دهند چه شواهدی پیدا شده‌اند، و Faithfulness و Response Relevancy نشان می‌دهند پاسخ چگونه از شواهد استفاده کرده و به پرسش پرداخته است. یک امتیاز خوب برای پاسخ به‌تنهایی نمی‌گوید همهٔ اطلاعات لازم بازیابی شده‌اند.

این جداسازی برای پیدا کردن محل خطا ضروری است. مقالهٔ Ragas کیفیت زمینهٔ بازیابی‌شده، وفاداری پاسخ به آن و ارتباط پاسخ با پرسش را ابعاد متمایز ارزیابی معرفی می‌کند. اگر بخش لازم از منبع به مدل نرسد، تغییر دستور تولید پاسخ لزوماً مشکل را حل نمی‌کند؛ باید خروجی مرحلهٔ بازیابی را نیز برای همان سؤال دید.

مجموعهٔ ارزیابی را از سؤال تا شاهد بسازید

ردیفی که فقط سؤال و پاسخ مرجع دارد، برای تشخیص همهٔ خطاهای بازیابی کافی نیست. در کنار هر سؤال، محل شواهد لازم را در نسخهٔ مشخصی از اسناد ثبت کنید. بهتر است این محل به سند و بازهٔ متن اشاره کند، نه فقط به شناسهٔ یک بخش حاصل از chunking؛ با تغییر روش بخش‌بندی، شناسهٔ بخش ممکن است عوض شود، در حالی که شاهد مورد انتظار همان است.

• سؤال را با زبان و شکل پرسش کاربران بنویسید و پرسش‌های کوتاه، چندبخشی و دارای اسناد مشابه را متناسب با کاربرد سامانه وارد کنید.
• برای هر ردیف، نسخهٔ سند، محل شواهد ضروری و نکته‌های لازم در پاسخ مرجع را نگه دارید. پاسخ مرجع باید محتوای لازم را مشخص کند، نه یک جمله‌بندی اجباری را.
• اگر پاسخ در مجموعهٔ اسناد وجود ندارد، انتظار «شاهد کافی نیست» را ثبت کنید. چنین ردیفی برای سنجش خودداری از پاسخ مفید است، اما نباید مانند سؤال دارای شاهد در محاسبهٔ recall تفسیر شود.
• در هر اجرا، نتایج بازیابی‌شده به‌ترتیب رتبه، متنی که واقعاً به مدل رسیده، پاسخ نهایی و نتیجهٔ ارزیابی همان ردیف را ذخیره کنید.

مجموعه را با پرسش‌های نمایندهٔ استفادهٔ واقعی شروع کنید و نمونه‌های دشوار را برای آشکار کردن شکست‌های مشخص بیفزایید: شاهدی که میان چند سند پخش شده، سندی قدیمی در کنار نسخهٔ تازه، یا عبارتی مشابه که به موضوع دیگری اشاره می‌کند. این‌ها نمونه‌های طراحی ارزیابی‌اند، نه نتایج یک آزمون انجام‌شده. هنگام تغییر محتوای اسناد، پاسخ مرجع و محل شواهد را نیز بازبینی کنید؛ برچسب کهنه می‌تواند افتی ساختگی در امتیاز ایجاد کند.

در بازیابی، رتبهٔ نتایج را از پوشش شواهد جدا کنید

Context Precision به مفید بودن نتایج بازیابی‌شده و جایگاه آن‌ها در رتبه‌بندی حساس است؛ بخش مرتبطی که زودتر می‌آید، برای این معیار اهمیت دارد. Context Recall می‌سنجد چه مقدار از اطلاعات لازم برای پاسخ در متن بازیابی‌شده حاضر است. فهرست معیارهای Ragas این دو را در کنار Faithfulness، Response Relevancy و Noise Sensitivity برای ارزیابی RAG آورده است.

تفاوت آن‌ها در یک مثال فرضی روشن می‌شود: پرسشی به دو شرط در دو بخش منبع نیاز دارد، اما بازیاب فقط بخش مربوط به شرط نخست را در رتبهٔ بالا برمی‌گرداند. نتیجهٔ نخست می‌تواند کاملاً مرتبط باشد و به precision کمک کند، ولی شاهد شرط دوم غایب است و پوشش شواهد پایین می‌ماند. پاسخی که فقط شرط نخست را توضیح دهد حتی ممکن است به همان شاهد موجود وفادار باشد؛ با این حال پاسخ کامل پرسش نیست. همین وضعیت نشان می‌دهد چرا امتیاز خوش‌ظاهر یک لایه نباید جای مشاهدهٔ لایهٔ دیگر را بگیرد.

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

در تولید، پشتیبانی ادعا را از پاسخ‌دادن به پرسش جدا کنید

Faithfulness ادعاهای پاسخ را با متن بازیابی‌شده می‌سنجد: آیا هر ادعا از آن متن قابل استنتاج است؟ امتیاز بالا به‌تنهایی درستی مستقل پاسخ را ثابت نمی‌کند. اگر سند بازیابی‌شده قدیمی یا نادرست باشد، پاسخ می‌تواند به آن وفادار بماند و همچنان برای کاربر غلط باشد؛ به همین دلیل نسخه و اعتبار سند بخشی از بررسی نمونهٔ مسئله‌دار است.

Response Relevancy می‌پرسد پاسخ چقدر به خواستهٔ کاربر مربوط است و سنجهٔ صحت ادعاها نیست. پاسخی روان ممکن است از پرسش اصلی منحرف شود؛ پاسخی مرتبط نیز ممکن است ادعای بی‌پشتوانه داشته باشد. در سؤال‌های چندبخشی، نکته‌های ضروری پاسخ مرجع را جداگانه کنترل کنید تا حذف یک شرط یا استثنا پشت پاسخ کوتاه و مرتبط پنهان نماند.

ارزیابی خودکار می‌تواند مرور نمونه‌های فراوان را آسان‌تر کند، اما موارد مرزی به خواندن سؤال، شاهد و پاسخ کنار هم نیاز دارند. اگر داور خودکار دربارهٔ یک پاسخ فارسی یا بخشی از سند اختلاف‌برانگیز امتیاز می‌دهد، چند نمونه از همان گروه را دستی بازبینی کنید. تغییر امتیاز زمانی به تصمیم فنی کمک می‌کند که بدانید داور چه چیزی را مرتبط، کافی یا مستند شمرده است.

افت هر معیار را به بخش مناسب خط لوله وصل کنید

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

• اگر Context Recall پایین است و شاهد لازم در مخزن وجود دارد، پوشش نمایه، مرزهای chunking، ساخت پرس‌وجو و embedding را بررسی کنید. اگر شاهد در نتایج جست‌وجو هم دیده نمی‌شود، اصلاح prompt تولید راه مستقیمی برای رساندن آن به مدل نیست.
• اگر شاهد لازم پیدا می‌شود اما پایین‌تر از متن‌های نامرتبط قرار می‌گیرد، reranking و فیلترهای بازیابی را بیازمایید. اندازهٔ بخش‌ها نیز مهم است: بخش بسیار بزرگ ممکن است شاهد مفید را همراه متن نامرتبط به زمینه بفرستد.
• اگر شواهد درست به مدل رسیده‌اند ولی Faithfulness پایین است، ادعاهای بی‌پشتوانه را مشخص کنید و دستور استفاده از زمینه، قالب پاسخ و مدل تولید را جداگانه بیازمایید. اگر زمینه خود نامرتبط است، بررسی بازیابی باید پیش از تغییر دستور تولید انجام شود.
• اگر Faithfulness مناسب است ولی Response Relevancy افت دارد، ببینید کدام بخش پرسش بی‌پاسخ مانده یا کدام توضیح حاشیه‌ای جای آن را گرفته است. در این حالت، دستور توجه به خواستهٔ کاربر و معیار کامل بودن پاسخ به بررسی نیاز دارند.

افزودن نتایج بیشتر ممکن است شاهد جاافتاده را به زمینه برساند، اما هم‌زمان متن نامرتبط بیشتری وارد کند. بنابراین اثر چنین تغییری را با recall، precision و کیفیت پاسخ کنار هم بخوانید. اگر پاسخ از متن نامرتبط ادعای غلط می‌سازد، Noise Sensitivity نیز می‌تواند برای بررسی این نوع شکست مفید باشد.

نسخه‌های RAG را با شرایط قابل‌مقایسه بسنجید

راهنمای عملی Ragas چرخه‌ای از ساخت مجموعه‌داده، اجرای مبنا، تحلیل خطا و مقایسهٔ تغییرات را شرح می‌دهد. برای اجرای تکرارپذیر این چرخه، نسخهٔ اسناد، روش بخش‌بندی، embedding، بازیاب، reranker، تعداد نتایج، محدودیت متن ورودی، مدل تولید و prompt را همراه خروجی هر اجرا ثبت کنید. وقتی اثر یک تغییر را می‌سنجید، سایر اجزا را تا جای ممکن ثابت نگه دارید.

میانگین هر معیار نمای کلی می‌دهد، اما نتیجهٔ هر سؤال نشان می‌دهد بهبود از کجا آمده است. نسخه‌ای ممکن است در پرسش‌های ساده بهتر شود و در پرسش‌های چندمنبعی یا موارد فاقد شاهد افت کند. نتیجه‌ها را بر اساس نوع سؤال و مرحلهٔ خطا گروه‌بندی کنید، سپس تغییر پیشنهادی را هم روی گروه هدف و هم روی کل مجموعهٔ ثابت بسنجید. این مقایسه روشن می‌کند آیا اصلاح یک شکست، شکست تازه‌ای در بازیابی یا تولید ایجاد کرده است.