ارزیابی RAG و کنترل هزینه؛ فراتر از یک پاسخ خوش‌خوان

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

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

مجموعهٔ آزمون را از کار واقعی بسازید

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

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

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

بازیابی و تولید را جدا اندازه بگیرید

ابتدا بپرسید آیا شاهد درست در میان نامزدهای بازیابی‌شده هست؟ اگر نیست، تغییر دستورِ تولید احتمالاً مسئله را حل نمی‌کند. سپس ببینید شاهد درست در چه رتبه‌ای قرار دارد و آیا به زمینهٔ نهایی رسیده است. مرحلهٔ سوم این است که مدل از شواهد موجود، پاسخ درست و کامل ساخته یا نه.

چارچوب Ragas به ارزیابی خودکار ابعاد سامانه‌های RAG می‌پردازد و RAGChecker نیز تشخیص ریزدانه‌ترِ خطا در بازیابی و تولید را بررسی می‌کند. ۱ ۲ استفاده از یک چارچوب، مسئولیت تعریف «پاسخ مناسب برای این محصول» را برنمی‌دارد؛ معیار و دادهٔ مرجع همچنان باید با سناریوی شما سازگار باشند.

یک امتیاز کلی، علت خطا را پنهان می‌کند

از اسم شاخص تا تعریف قابل محاسبه

برای هر شاخص، واحد ارزیابی را بنویسید: سند، صفحه، قطعه یا ادعای پاسخ؟ اگر پاسخ به سه صفحه نیاز دارد، یافتن یک قطعهٔ درست با پوشش کامل شواهد یکسان نیست. در تعریف متداول Recall@k، تعداد موارد مرتبطِ یافته‌شده در k نتیجهٔ نخست، بر تعداد کل موارد مرتبطِ مرجع تقسیم می‌شود. Precision@k سهم نتایج مرتبط در همان k نتیجه را می‌سنجد. مرجع ناقص می‌تواند هر دو را گمراه‌کننده کند. ۵

Recall@k = relevant retrieved items in top k / all relevant reference items
Precision@k = relevant retrieved items in top k / k

مثال فرضی برای فهم محاسبه: اگر برای یک سؤال چهار شاهد لازم باشد و در ده نتیجهٔ نخست سه شاهد پیدا شود، Recall@10 برابر ۰٫۷۵ است. اگر همان سه نتیجه، تنها نتایج مرتبط آن ده مورد باشند، Precision@10 برابر ۰٫۳۰ است. این عددها نتیجهٔ پروژهٔ واقعی نیستند. برای پرسش چندمرحله‌ای، علاوه بر میانگین پوشش، جدا بررسی کنید آیا همهٔ شاهدهای ضروریِ همان سؤال به زمینهٔ نهایی رسیده‌اند یا خیر.

در ارزیابی ترتیب، شاخصی مانند nDCG می‌تواند درجهٔ ارتباط و جایگاه نتایج را با هم در نظر بگیرد. پیش از انتخاب آن، مقیاس برچسب ارتباط، روش حل اختلاف ارزیابان و نقطهٔ برش را مشخص کنید. گزارش «امتیاز بالاتر» بدون این تعریف‌ها، برای مقایسهٔ نسخه‌ها کافی نیست. ۵

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

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

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

داوری با مدل، ابزار کمکی است

مدل داور می‌تواند بررسی تعداد زیادی پاسخ را آسان‌تر کند، اما خودش هم محدودیت و سوگیری دارد. بهتر است معیار داوری روشن باشد و نمونه‌هایی از داوری با بازبینی انسانی مقایسه شوند. برای ادعاهای حساس، وجود یک امتیاز خودکارِ بالا نباید به‌تنهایی معیار پذیرش باشد.

به داور همان چیزی را بدهید که برای سنجش لازم است. اگر درستی استناد را می‌سنجید، متن شاهد باید در دسترسش باشد. اگر می‌خواهید نبود پاسخ را بررسی کنید، وضعیت مرجع را مشخص کنید. سؤال مبهم از داور، معمولاً خروجی مبهم تولید می‌کند؛ حتی اگر نتیجه به‌صورت عددی نمایش داده شود.

هزینه را به مسیرهای قابل توضیح تقسیم کنید

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

برای برآورد اولیه، رابطهٔ زیر مفید است. مقادیر باید از اندازه‌گیری و تعرفهٔ همان زیرساخت به دست آیند، نه از عدد ثابت یک مقاله:

Total operating cost =
  ingestion and refresh
  + storage and search
  + per-request model and tools
  + monitoring and operations

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

زمینهٔ بیشتر، همیشه پاسخ بهتر نمی‌سازد

افزودن هر قطعهٔ نزدیک به سؤال، می‌تواند ورودی را طولانی و شلوغ کند. پژوهش Lost in the Middle، حساسیت استفادهٔ مدل‌ها از اطلاعات در موقعیت‌های مختلفِ زمینهٔ بلند را بررسی کرده است. ۳ از این پژوهش نباید یک قاعدهٔ ساده برای همهٔ مدل‌ها استخراج کرد؛ پیام اجرایی این است که جایگاه، ترتیب و انتخاب شواهد را هم آزمایش کنیم.

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

REFRAG چه نوع بهینه‌سازی‌ای است؟

REFRAG در پژوهش سال ۲۰۲۵ به بازاندیشی رمزگشاییِ مبتنی بر RAG می‌پردازد. ایدهٔ آن شامل استفاده از نمایش‌های فشردهٔ قطعه‌ها و انتخاب بخش‌هایی برای گسترش است. این موضوع را باید از الگوریتم پیدا کردن سند جدا دانست: REFRAG راهبردی در سمت استفاده از زمینه و رمزگشایی است، نه نام دیگری برای بازیابی برداری. ۴

نکتهٔ کاربردی مهم، وابستگی آن به قابلیت‌ها و تغییرات مدل است. نمی‌توان فرض کرد هر API متنیِ عمومی، بردار فشردهٔ قطعه را به‌عنوان ورودی رمزگشا می‌پذیرد. اگر چنین قابلیتی در مدل یا زیرساخت شما وجود ندارد، نوشتن چند پارامتر با نام REFRAG به معنی پیاده‌سازی این روش نیست. ابتدا پشتیبانی واقعی را بررسی کنید و سپس آن را با خط مبنای قابل اجرا مقایسه کنید.

یک مسیر بهینه‌سازی با اولویت روشن

در مسیر عامل، هزینه را به تصمیم‌ها وصل کنید

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

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

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

گزارش بهره‌برداری چه چیزی را نشان دهد؟

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

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