این آموزش نشان میدهد چگونه بهجای قضاوت مبهم درباره خوب یا بد بودن پاسخ، نیاز اطلاعاتی، معیار relevance و failure mode را دقیق تعریف کنیم تا evaluation برای search، RAG و assistantهای سازمانی واقعا مفید شود.
این آموزش برای چیست؟
این آموزش برای تیمی است که میخواهد کیفیت پاسخهای LLM را در search، RAG یا دستیار دانشی با دادهای بسنجند که به تصمیم محصولی منتهی شود، نه فقط یک score نمایشی.
پیشنیازها
- فهرستی از queryها یا درخواستهای واقعی کاربران
- چند reviewer که دامنه مسئله را بشناسند
- taxonomy ساده برای intent، ambiguity و نوع failure
- نمونه پاسخ مدل یا خروجی retrieval برای مقایسه
مرحله 1: درخواست خام را به نیاز اطلاعاتی تبدیل کنید
بهجای نگه داشتن query در شکل خام، روشن کنید کاربر چه تصمیمی میخواهد بگیرد، چه زمینهای لازم است و چه نوع مدرکی پاسخ را مفید میکند.
مرحله 2: rubric ارزیابی را روی چند بعد ببندید
معیارهایی مثل پوشش نکات کلیدی، دقت factual، تناسب با context و usefulness عملی را جدا کنید تا reviewer مجبور نباشد همه چیز را در یک نمره خلاصه کند.
مرحله 3: edge caseها را عمدا وارد dataset کنید
پرسشهای چندمعنایی، درخواستهای دارای پیشفرض نادرست و سوالهای چندسندی را جداگانه نگه دارید، چون همینها quality واقعی سیستم را آشکار میکنند.
مرحله 4: retrieval و answer generation را جداگانه بسنجید
اگر سند درست پیدا نشده، نباید failure را فقط به مدل مولد نسبت داد. این تفکیک در تصمیمگیری برای tuning بسیار حیاتی است.
مرحله 5: روی disagreement بین reviewerها تمرکز کنید
مواردی که دو reviewer به نتیجه متفاوت میرسند، بهترین منبع برای اصلاح rubric و شفاف کردن معیار پذیرش هستند.
مرحله 6: نتیجه را به backlog محصولی ترجمه کنید
در پایان فقط score ندهید؛ مشخص کنید مشکل اصلی از query rewrite، retrieval، prompt، citation policy یا UI explanation میآید.
نمونه input
«برای قراردادهای تامین، چه بندی تعیین میکند جریمه تاخیر چگونه محاسبه شود؟»
نمونه output
نیاز اطلاعاتی بازنویسیشده، rubric مربوط به citation و completeness، و تفکیک failure بین retrieval ناقص و answer اشتباه.
خطاهای رایج و محدودیتها
- امتیازدهی کلی بدون تعریف معیارهای قابلتکرار
- استفاده از datasetهای خیلی تمیز که شرایط واقعی را بازنمایی نمیکنند
- نادیده گرفتن disagreement بین ارزیابها
نتیجه نهایی
خروجی نهایی باید dataset و rubricی باشد که هم برای سنجش نسخههای مختلف مدل مفید باشد و هم مستقیما به اولویتهای repair در محصول تبدیل شود.
جمعبندی اجرایی
اگر قرار است از این الگو در محصول یا تیم خود استفاده کنید، از یک دامنه محدود و قابلاندازهگیری شروع کنید. evaluation خوب از تعریف دقیق intent شروع میشود، نه از امتیازدهی کلی. باید retrieval failure و generation failure را از هم جدا کرد. تفاوت بین محتوای خوب و سیستم قابلاتکا دقیقاً در همین فاصله است: اینکه ایده از سطح خلاصه یا demo عبور کند و به تصمیم عملیاتی قابلردیابی برسد.
قدم بعدی
پس از ساخت rubric، حداقل ۵۰ query واقعی را annotate کنید و گزارش را نه فقط بر اساس score، بلکه بر اساس نوع failure و تصمیم اصلاحی منتشر کنید.