‏وقتی نمرهٔ قبولی ایجنت هیچی رو نشون نمی‌ده

به گفتهٔ نویسنده‌ها، که از تیم Frontier AI بخش Data Cloud گوگل هستن، ما ایجنت‌های هوش مصنوعی رو مثل یه امتحان قبولی/رد ارزیابی می‌کنیم: یه بنچمارک ثابت می‌گیریم، یه نمره درمیاریم و می‌گیم پیشرفت کردیم. مشکل اینه که این نمره نمی‌گه شکست‌ها چقدر نزدیک بودن، قبولی‌ها چقدر راحت بودن، و بعدش باید چی رو بهتر کرد. چیزی که واقعاً لازمه یه «نقشه»‌ست که نشون بده توانایی ایجنت دقیقاً کجا افت می‌کنه.

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

اهرم کارشون یه مفهوم شناخته‌شده تو نظریهٔ اطلاعاته به اسم surprisal: یعنی چقدر عدم‌قطعیت دربارهٔ دیتاست درست باقی می‌مونه. یه کلمهٔ نادر و دقیق کلی «بیت» اطلاعات داره و هدف رو از بقیه جدا می‌کنه. تو یه مثال واقعی از بنچمارک KramaBench، توکن TLE تقریباً مستقیم به یه جدول خاص اشاره می‌کنه؛ همینو که برداری، سؤال مبهم می‌شه و به چند جدول مختلف می‌خوره. با کم و زیاد کردن این کلمه‌ها، سختی سؤال قابل تنظیم می‌شه.

قلب ماجرا یه حلقهٔ بازآرایی به اسم iSQR هست که برای هر سؤال نسخه‌های «آسون» و «سخت» می‌سازه. نتیجه دو تا یافتهٔ مهم بود که تو ارزیابی معمولی اصلاً دیده نمی‌شدن. اول «پرتگاه‌ها»: یه سؤال با عبارت خنثی نمرهٔ کامل F1=۱.۰۰ می‌گیره ولی با کمی ابهام می‌شه ۰.۰۰. بنچمارک ثابت فقط حالت خنثی رو تست می‌کنه و می‌گه «حل شد»، در حالی که درست کنار جواب یه پرتگاهه.

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

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

نویسنده می‌گه حتی خودِ مولّدِ سختی رو هم نباید کورکورانه باور کرد. اون‌ها همون سوییپ ابهام رو دو جور ساختن؛ یکی با حدس صرفِ مدل زبانی و یکی با پایهٔ TF-IDF surprisal. این دو تا شدید با هم اختلاف داشتن و نسخهٔ پایه‌دار قابل‌اعتمادتر بود. پیامش روشنه: خودِ ابزار سنجش رو هم باید سنجید.

نکات کلیدی:

• ارزیابی پاس/رد فقط می‌گه ایجنت قبول شد یا نه، نه اینکه کجا و چقدر ضعیفه
• با مفهوم surprisal از نظریهٔ اطلاعات می‌شه سختی هر سؤال رو تنظیم کرد و «نقشهٔ» توانایی ساخت
• حلقهٔ iSQR نسخه‌های آسون و سخت هر سؤال رو تولید می‌کنه
• خیلی از بنچمارک‌های معتبر خودشون ایراد دارن و باید ground-truth رو خوند
• شعار مقاله: «ارزیاب‌هات رو هم ارزیابی کن»