‏ارزیابی و بنچمارک مدل‌های زبانی

نویسنده با یه مثال آشنا شروع می‌کنه: تیم یه آپدیت روی پرامپت می‌فرسته، مدل تو تست «بهتر حس می‌شه» و همون رو می‌فرستن production. به گفته نویسنده بیشتر تیم‌ها همین‌جوری کار می‌کنن و دقیقاً به همین دلیله که ۶۰٪ مشکلات مدل‌های زبانی تو production رو اول کاربرها پیدا می‌کنن نه مهندس‌ها. حرف اصلیش اینه که ارزیابی، با اینکه جذاب و چشم‌گیر نیست، مهم‌ترین دیسیپلینیه که تیم‌های سازنده محصول AI رو از تیم‌های دموساز جدا می‌کنه.

نویسنده چهار روش ارزیابی رو معرفی می‌کنه. اولی بنچمارک‌های چندگزینه‌ای مثل MMLU، HumanEval و GSM8K هستن — سریع، ارزون و قابل‌تکرار. مثلاً MMLU حدود ۱۴٬۰۰۰ سؤال تو ۵۷ حوزه آکادمیک داره و HumanEval تولید کد رو با تست واحد می‌سنجه. ولی اینا نمی‌گن مدل روی تسک‌های واقعیِ کاربرای تو چطور کار می‌کنه؛ یه مدل می‌تونه تو MMLU عالی باشه ولی سیاست بازگشت وجهِ محصول تو رو از خودش دربیاره.

روش دوم ارزیابی مبتنی بر verifier برای ریاضی و کده: مدل آزادانه جواب می‌ده، بعد جواب استخراج و در برابر ground truth بررسی می‌شه، اغلب با یه مفسر کد. این روش عینی و مقیاس‌پذیره و ستون فقرات توسعه مدل‌های استدلالیه، ولی فقط جایی کار می‌کنه که درستیِ جواب قطعی باشه — مثل ایجنت‌های کدنویسی یا تولیدکننده‌های SQL. روش سوم لیدربرد و ترجیح انسانی مثل Chatbot Arena هست که با رتبه‌بندی Elo (همون سیستم شطرنج) و رأی کورِ انسان‌ها می‌گه مردم کدوم مدل رو ترجیح می‌دن؛ سبک و لحن واقعی رو خوب نشون می‌ده ولی کنده و گرونه و سخت می‌شه داخلی اجراش کرد.

روش چهارم LLM-as-a-Judge ـه که الان بیشتر تیم‌های محصول دارن سراغش می‌رن: یه مدل توانمند (مثل GPT-4o) با یه روبریک ساختاریافته جواب‌های مدلِ تو رو خودکار ارزیابی می‌کنه. مقیاس‌پذیر و دقیقه و به تیم بزرگ برچسب‌زنی نیاز نداره، ولی به‌اندازه روبریکته خوبه و سوگیریِ موقعیتی (positional bias) هم واقعیه؛ نویسنده توصیه می‌کنه مقایسه‌ها رو همیشه دوطرفه (pairwise در هر دو ترتیب) اجرا کنی تا این سوگیری خنثی بشه.

بعد نویسنده «هرم ارزیابی» رو پیشنهاد می‌ده، شبیه هرم تست: پایینش زیاد، بالاش کم. تو پایه‌ش unit eval هست (چک با regex، اعتبارسنجی JSON، تطبیق دقیق) که روی هر کامیت اجرا می‌شه؛ بعد LLM-as-Judge روی هر ریلیز؛ بعد shadow testing که مدل جدید رو موازی اجرا می‌کنی و خروجی‌ها رو قبل از سوییچ ترافیک مقایسه می‌کنی؛ و در نهایت A/B testing با سیگنال کاربر واقعی که فقط برای تغییرهای بزرگ نگهش می‌داری. قانون طلایی اینه: هیچ‌وقت بدون اجرای eval، تغییرِ پرامپت یا مدل رو نفرست، چون تغییرهای به‌ظاهر بی‌خطر مدام باعث افتِ بی‌سروصدا می‌شن.

نویسنده چند کار عملیِ زودبازده هم پیشنهاد می‌ده: ساختن یه دیتاستِ طلایی از ۲۰۰ تا ۵۰۰ کوئریِ واقعیِ کاربرها (ناشناس‌شده، با جواب مرجع و برچسب سختی و موضوع)؛ گذاشتن یه آستانه قبولی و بلاک کردن دیپلویِ مردود با ابزارهایی مثل DeepEval و Promptfoo تو CI/CD؛ ارزیابی جدای RAG از تولید با متریک‌های RAGAS (مثلاً faithfulness زیر ۰٫۹۰ یعنی مدل داره فراتر از context بازیابی‌شده توهم می‌زنه)؛ و red-team کردنِ سیستماتیک قبل از لانچ با ابزاری مثل Garak. جمع‌بندی نویسنده اینه که ارزیابی یه کار یک‌باره قبل از لانچ نیست، یه دیسیپلینِ مهندسیِ مداومه و تیم‌های برنده اونایی‌ان که دقیق می‌دونن مدلشون چطور کار می‌کنه، قبل از اینکه کاربرها بفهمن.

نکات کلیدی:

• چهار روش ارزیابی: بنچمارک چندگزینه‌ای، verifier-based، لیدربرد/ترجیح انسانی، و LLM-as-a-Judge
• بنچمارک‌های آکادمیک مثل MMLU نمی‌گن مدل روی تسک واقعیِ کاربرای تو چطور کار می‌کنه
• هرم ارزیابی: unit eval روی هر کامیت، LLM-as-Judge روی هر ریلیز، shadow testing، بعد A/B
• هیچ تغییرِ پرامپت یا مدلی رو بدون اجرای eval نفرست؛ تغییرهای بی‌خطر باعث افت بی‌سروصدا می‌شن
• RAG رو جدا از تولید با RAGAS ارزیابی کن و قبل لانچ سیستماتیک red-team کن