eval خوب نمره نمیده، تصمیم میده
هوش مصنوعی
تستخلاصهٔ کاملتر
تو این راهنما اومده که کار رو نباید از فهرست تسکها شروع کنی، بلکه از تصمیمها و جریانهای کاریای که سیستم هوش مصنوعی قراره پشتیبانی کنه. یعنی سراغ کارهای پرتکرار روزمره، موارد پرریسک یا پرارزش، کارهایی که قضاوت میخوان و جاهایی برو که مدل همین الان هم میلنگه. لازم نیست همهچیز رو یکسان بسنجی؛ مجموعهٔ تست باید روی همون تصمیمهایی تمرکز کنه که میخوای ازش جواب بگیری.
هر نمونهٔ eval یه بستهٔ کامله: خود درخواست کاربر، سند و دیتایی که مدل باید بگیره، ابزارهایی که در دسترسشه، خروجی مورد انتظار، یه پاسخ مرجع اگه وجود داره، rubric یا معیار نمرهدهی، و متادیتا مثل نوع کار و سطح ریسک. برای کارهای ساده همین که یه prompt و یه جواب درست باشه کافیه؛ برای یه workflow ایجنتی ممکنه کل یه محیط شبیهسازیشده لازم بشه. ساختار باید طوری باشه که همون تست رو بشه روی مدلها و نسخههای مختلف عین هم اجرا کرد.
نمایندگیبودن مجموعه یعنی چی؟ به گفتهٔ نویسنده لزوماً کپیکردن ترافیک واقعی نیست. یه سناریوی نادر که ضرر مالی یا حقوقی بزرگی میسازه ممکنه باید وزنی بیشتر از فراوانی واقعیش بگیره. تستکردن فقط روی مسیر خوشبینانه هم گمراهکنندهست، یعنی حالتی که همهچی مرتب و کامل به مدل میرسه؛ کاربر واقعی دستور ناقص میده، اطلاعات متناقض میده و ابزارها گاهی خطا میدن.
دو تا اصطلاح رو جدا توضیح داده: edge case یعنی موقعیت غیرعادی و سخت بیرون از مسیر معمول، و adversarial case یعنی مثالی که عمداً ساخته شده تا مدل رو به اشتباه بندازه، مثل اطلاعات گمراهکننده یا دستور متناقض. سمت داوری هم calibration (یعنی همکوککردن نمرهدهندهها با مثال و راهنمای مشترک) و inter-rater agreement (یعنی اینکه چقدر داورهای مختلف روی یه خروجی به یه نتیجه میرسن) مهمن. توافق پایین معمولاً یعنی rubric مبهمه.
نکتهٔ عملیتر اینه که همهٔ خطاها یه وزن ندارن. یه جملهٔ ناجور و یه مشاورهٔ حقوقیِ اشتباه هر دو «یک شکست» شمرده میشن ولی نباید یه جور حساب شن، پس بهتره سطح شدت تعریف کنی و خطاهای بحرانی رو جدا گزارش کنی. شکستهای محیط واقعی هم بهترین منبع مثال جدیدن، و برای اینکه مدل به همون مجموعه نچسبه (چیزی که بهش میگن overfit شدن به eval) بخشی از مثالها رو از تیم توسعه پنهان نگه دار و مرتب مثال تازه اضافه کن.
نکات کلیدی:
- مجموعهٔ تست باید از تصمیمهای کسبوکار ساخته شه، نه از مثالهایی که جمعکردنشون راحتتره.
- هر نمونه شامل درخواست، context، ابزارهای در دسترس، خروجی مورد انتظار، rubric و متادیتای ریسک ـه.
- edge case موقعیت نادر و سخته؛ adversarial case عمداً برای بهاشتباهانداختن مدل ساخته میشه.
- توافق پایین بین داورها یعنی rubric مبهمه؛ سراغ همون نمونههای اختلافی برو بهجای میانگینگرفتن نمرهها.
- برای جلوگیری از overfit، بخشی از مثالها رو از فرایند توسعه پنهان نگه دار و مجموعهٔ توسعه و نهایی رو جدا کن.
