یک دمو با پنج پرسش موفق نمی‌تواند کیفیت سامانه زبانی را ثابت کند. کاربران واقعی سؤال ناقص می‌پرسند، اسناد متناقض‌اند و گاهی پاسخ درست این است که سامانه پاسخ ندهد. ارزیابی مدل زبانی باید این وضعیت‌ها را پیش از انتشار به یک مجموعه آزمون قابل تکرار تبدیل کند.
واحد ارزیابی فقط مدل نیست. جست‌وجو، پرامپت، قواعد دسترسی، ابزارها و قالب خروجی همگی روی نتیجه اثر دارند. بنابراین نسخه کامل سامانه باید با داده و سناریوی واقعی سنجیده شود.
مجموعه آزمون را از کار واقعی بسازید
نمونه‌ها را از پرسش‌های کاربران، پرونده‌های قبلی و استثناهای شناخته‌شده انتخاب کنید. سؤال ساده، مبهم، چندبخشی، خارج از دامنه و دارای اطلاعات محرمانه را کنار هم قرار دهید. مجموعه فقط نباید موارد پرتکرار را پوشش دهد؛ خطاهای کم‌تکرار اما پراثر نیز ضروری‌اند.
پاسخ مرجع همیشه یک جمله ثابت نیست
برای بعضی سؤال‌ها پاسخ دقیق وجود دارد، اما در بسیاری موارد باید معیار پذیرش نوشت: نکات ضروری، ادعاهای ممنوع، منابع قابل قبول و شرایط امتناع. متخصص دامنه این معیار را تأیید کند. اگر چند پاسخ درست وجود دارد، ارزیاب نباید فقط تطابق واژه‌به‌واژه را بسنجد.
ابعاد کیفیت را جدا اندازه بگیرید
- درستی: ادعا با واقعیت و منبع مرجع سازگار است؟
- استناد: منبع مرتبط و قابل دسترس به کاربر نشان داده شده است؟
- کامل‌بودن: نکات ضروری پاسخ پوشش داده شده‌اند؟
- امتناع درست: در نبود داده یا مجوز، سامانه از حد خود عبور نمی‌کند؟
- قالب و لحن: خروجی برای مصرف بعدی و مخاطب مناسب است؟
- عملکرد: زمان پاسخ و هزینه در محدوده پذیرفته‌شده‌اند؟
ارزیابی خودکار و انسانی را ترکیب کنید
قواعد قطعی می‌توانند وجود فیلد، معتبر بودن پیوند، طول، قالب و نشت عبارت حساس را بررسی کنند. مقایسه معنایی برای غربال اولیه مفید است، اما پاسخ‌های مرزی و پراثر باید توسط متخصص بازبینی شوند. بخشی از نمونه‌ها را میان دو ارزیاب تقسیم کنید تا تفاوت برداشت مشخص و معیارها دقیق‌تر شوند.
RAG را مرحله‌به‌مرحله آزمایش کنید
ابتدا ببینید سند درست در میان نتایج بازیابی حضور دارد یا نه. سپس بررسی کنید پاسخ فقط بر همان شواهد تکیه می‌کند و منبع را درست نشان می‌دهد. اگر بازیابی و تولید را یک عدد کنید، معلوم نمی‌شود افت کیفیت از کدام بخش آمده است.
آزمون رگرسیون پیش از هر انتشار
تغییر مدل، پرامپت، تقسیم سند یا تنظیم جست‌وجو ممکن است یک دسته پاسخ را بهتر و دسته‌ای دیگر را بدتر کند. مجموعه ثابت را برای هر نسخه اجرا کنید و نتیجه را با نسخه جاری مقایسه کنید. افت در سناریوی حساس باید مانع انتشار شود، حتی اگر میانگین کل بهتر شده باشد.
دروازه انتشار تعریف کنید
برای هر بعد حد پذیرش بنویسید؛ مثلا هیچ نشت دسترسی، حداقل درصد استناد معتبر و سقف مشخص برای زمان و هزینه. نتیجه به سه حالت تبدیل شود: انتشار، انتشار محدود با کنترل بیشتر یا توقف برای اصلاح. این تصمیم نباید پس از دیدن نتایج به‌صورت سلیقه‌ای تغییر کند.
بازخورد تولید، پاسخ مرجع نیست
پسندیدن پاسخ یا ادامه گفت‌وگو سیگنال مفیدی است، اما لزوما درستی را ثابت نمی‌کند. بازخورد کاربر را با نرخ اصلاح، ارجاع به انسان، خطای گزارش‌شده و نمونه‌برداری تخصصی ترکیب کنید. موارد واقعی تازه پس از بی‌نام‌سازی و تأیید می‌توانند به مجموعه آزمون اضافه شوند.
گزارش ارزیابی باید قابل اقدام باشد
به جای یک امتیاز کلی، نتیجه را بر اساس نوع سؤال، منبع، واحد سازمانی و علت خطا نمایش دهید. تیم باید بداند کدام تغییر می‌تواند مشکل را حل کند: بهبود داده، اصلاح بازیابی، محدودکردن دامنه، تغییر پرامپت یا افزودن کنترل انسانی.
برای ساخت مجموعه مرجع، مقاله نقشه راه داده برای هوش مصنوعی و برای معماری پاسخ مستند، راهنمای پایگاه دانش RAG را ببینید. برای طراحی چارچوب ارزیابی یک کاربرد مشخص نیز از مرکز پشتیبانی سوهاب AI درخواست مشاوره ثبت کنید.