‏چرا eval با string contains ممکنه بهت دروغ بگه

نویسنده تو این مقاله سراغ یه عادت رایج تو ساختن eval (یعنی آزمون خودکار برای سنجیدن کار ایجنت) برای ایجنت‌های کدنویسی می‌ره: grader از نوع string contains. این روش سریع، قطعی و تقریباً مجانیه و می‌شه تو هر CI اجراش کرد. ولی به گفتهٔ نویسنده، اگه grader فقط دنبال کلمهٔ Azure بگرده و پاس بشه، تنها چیزی که می‌دونی اینه که این کلمه یه جایی تو فایل‌ها اومده.

این کلمه می‌تونه تو یه کامنت باشه که دقیقاً برعکسشو می‌گه، مثل // Don't use Azure here.. کد مرده، یه dependency بی‌استفاده، مستندات یا فایل تنظیماتی که برنامه هیچ‌وقت لودش نمی‌کنه هم همین grader رو پاس می‌کنن. برعکسش هم درسته: ایجنت می‌تونه از SDK استفاده کنه بی‌اینکه اسم Azure رو بیاره. پس نبودن کلمه هم چیزی رو ثابت نمی‌کنه.

نویسنده یه تست ساده پیشنهاد می‌کنه: این دو جمله رو خیلی تحت‌اللفظی کامل کن. «اگه این grader پاس بشه، الان می‌دونم که ...» و «اگه fail بشه، الان می‌دونم که ...». برای string contains جوابش فقط اینه که رشته هست یا نیست. اگه بنویسی «ایجنت درست از Azure استفاده کرده»، یه پرشی کردی که شواهدت پشتش نیست. یعنی grader لزوماً اشتباه نمی‌کنه، ما داریم ازش چیزی می‌خوایم که نمی‌تونه ثابت کنه.

به نظر نویسنده، راه درست اینه که سؤال رو از سیستمی بپرسی که جوابشو واقعاً داره. می‌خوای بدونی کد build می‌شه؟ buildش کن. تیمشون دیده راه‌حل‌هایی از LLM judge نمرهٔ کامل گرفتن ولی کامپایل نشدن. restore شدن dependencyها، اعتبارسنجی JSON با schema، پاس شدن تست‌ها و اگه بشه اجرای خود برنامه هم همین‌طوره. اینجاست که grader قطعی واقعاً می‌درخشه. قبول داره که اجرای برنامهٔ واقعی سخته، چون credential، داده و زیرساخت می‌خواد؛ ولی می‌گه اون‌وقت گزارش eval باید روشن بگه چی رو ثابت کرده و چی رو نه.

LLM judge به درد سؤال‌های معنایی می‌خوره، مثلاً فرق «از Azure برای ذخیرهٔ داده استفاده کن» با «استفاده نکن» رو می‌فهمه. ولی جای کامپایلر و تست‌رانر رو نمی‌گیره. نویسنده پیشنهاد می‌کنه evalهای ایجنتی رو مثل integration test ببینی، نه unit test. تو evalهای خودشون build، تست، اجرا و deploy گیت‌های جدا هستن و LLM judge کنارشون ویژگی‌های معنایی رو می‌سنجه. جمع‌بندی‌اش اینه که eval با اجرا روی هر commit قابل اعتماد نمی‌شه؛ وقتی قابل اعتماده که شواهدش پشت ادعاهایی باشه که ازش درمیاری.

نکات کلیدی:

• string contains فقط ثابت می‌کنه یه رشته تو خروجی هست، نه اینکه رفتار مورد نظر اتفاق افتاده.
• یه کامنت مثل // Don't use Azure here. هم grader Azure رو پاس می‌کنه.
• تست دو جمله‌ای: «اگه پاس بشه می‌دونم که...» و «اگه fail بشه می‌دونم که...».
• برای build، تست و schema از خود کامپایلر، تست‌رانر و validator استفاده کن، نه LLM.
• LLM judge برای سؤال‌های معنایی خوبه ولی جای اجرای واقعی کد رو نمی‌گیره.
• build، تست، اجرا و deploy رو گیت‌های جدا کن تا معلوم بشه دقیقاً کجا خراب شده.