شکاف امتیازدهی
بیشتر بنچمارک‌های ایجنت هنوز مثل آزمون چندگزینه‌ای نمره می‌دهند: ایجنت را اجرا کن، پاسخ نهایی‌اش را با یک مرجع مقایسه کن، یک امتیاز صادر کن. این کار یک مسیر چندمرحله‌ای کامل را به یک بیت فرو می‌کاهد. دو ایجنت می‌توانند هر دو امتیاز ۱٫۰ بگیرند، در حالی که یکی عملیاتی تمیز و برگشت‌پذیر انجام داده و دیگری یک جدول production را حذف کرده، چهار بار تلاش مجدد کرده و تصادفاً به پاسخ درست رسیده است. اگر بنچمارک نتواند تفاوت را ببیند، تیمی هم که ایجنت را عرضه می‌کند نمی‌تواند.
این یک نگرانی نظری نیست. فریم‌ورک‌های ایجنت به‌طور فزاینده‌ای برای وظایفی با عوارض جانبی واقعی به کار می‌روند: نوشتن در پایگاه‌داده، فراخوانی APIهای پرداخت، تغییر زیرساخت، ارسال پیام. در چنین شرایطی، مسیر یک جزئیات پیاده‌سازی نیست. بخشی از محصول است. بنچمارکی که آن را نادیده بگیرد، برای چیز اشتباهی بهینه‌سازی می‌کند.
چرا امتیازدهی بر اساس پاسخ نهایی شکست می‌خورد
امتیازدهی بر اساس پاسخ نهایی فرض می‌کند که پاسخ همان وظیفه است. برای پرسش‌وپاسخ تقریباً درست است. برای کار ایجنتی نه. یک ایجنت پژوهشی را در نظر بگیرید که باید دو مجموعه‌داده را تطبیق دهد. یک مسیر هر دو فایل را می‌خواند، تفاوت را محاسبه می‌کند و خلاصه‌ای می‌نویسد. مسیر دیگر فایل‌ها را می‌خواند، یک فایل میانی را در پوشه اشتباه می‌نویسد، با مسیر اصلاح‌شده دوباره تلاش می‌کند، یک نسخه کهنه از cache را می‌خواند و در نهایت همان خلاصه را تولید می‌کند. خروجی یکسان. قابلیت اطمینان متفاوت، هزینه متفاوت، دامنه اثر متفاوت.
سه ویژگی که در production اهمیت دارند برای امتیازدهی مبتنی بر خروجی نامرئی‌اند:
- هزینه. مصرف token، فراخوانی ابزار و تأخیر زمانی واقعی. ایجنتی که وظیفه را در یک فراخوانی ابزار حل می‌کند و ایجنتی که آن را در نه فراخوانی حل می‌کند، محصول یکسانی نیستند، حتی اگر پاسخ‌ها یکسان باشند.
- عوارض جانبی. هر سیستم خارجی که لمس شده، و در چه وضعیت نهایی. بنچمارکی که این را ثبت نکند نمی‌تواند ایجنت فقط‌خواندنی را از ایجنتی که وضعیت را تغییر داده و سپس پاک‌سازی کرده تشخیص دهد.
- قابلیت تکرار. اینکه آیا همان ایجنت روی همان وظیفه در seedهای مختلف همان مسیر را تولید می‌کند. یک اجرای موفق یک حکایت است، نه یک اندازه‌گیری.
چه چیزی باید ثبت شود
واحد ارزیابی باید مسیر باشد، نه پاسخ. این یعنی ابزارگذاری ایجنت برای انتشار یک ردگیری ساختاریافته از اقدامات. حداقل، هر مرحله باید ثبت کند:
- نام ابزار و آرگومان‌های کامل آن، نه فقط نام.
write_fileآموزنده نیست؛write_file(path="/etc/hosts", mode="append")آموزنده است. - مشاهده‌ای که ابزار برگردانده، شامل محتوای خطا.
- برچسب‌های زمانی و تعداد token در هر مرحله.
- وضعیت نهایی هر سیستم خارجی که اجرا لمس کرده: فایل‌های ایجادشده یا تغییرکرده، ردیف‌های درج‌شده، پیام‌های ارسال‌شده، منابع تأمین‌شده.
یک شمای حداقلی برای ردگیری می‌تواند این‌گونه باشد:
{
"run_id": "...",
"task_id": "...",
"seed": 7,
"steps": [
{
"index": 0,
"tool": "read_file",
"args": {"path": "data/input.csv"},
"observation": {"status": "ok", "bytes": 4096},
"tokens_in": 812,
"tokens_out": 44
},
{
"index": 1,
"tool": "write_file",
"args": {"path": "out/summary.md", "mode": "create"},
"observation": {"status": "ok"},
"tokens_in": 921,
"tokens_out": 130
}
],
"terminal_state": {
"files_created": ["out/summary.md"],
"files_modified": [],
"external_calls": []
},
"retries": 0,
"backtracks": 0
}
شمای دقیق کمتر از نظم اهمیت دارد: آرگومان‌ها، مشاهدات و وضعیت نهایی. بدون آرگومان‌ها، نمی‌توانید نیت را بررسی کنید. بدون وضعیت نهایی، نمی‌توانید پیامد را بررسی کنید.
تعداد تلاش‌های مجدد و عقب‌گردها معیار جانشین مفیدی برای شکنندگی هستند. ایجنتی که پس از سه تلاش مجدد به پاسخ درست می‌رسد شکننده‌تر از ایجنتی است که مستقیم به آن می‌رسد، و بسیار محتمل‌تر است که تحت تغییر توزیع شکست بخورد. این تعدادها باید در کنار نتیجه گزارش شوند، نه پنهان درون آن.
امتیازدهی به مسیرها
وقتی مسیرها ثبت شوند، امتیازدهی به یک بردار تبدیل می‌شود نه یک عدد اسکالر. چهار بُعد بیشتر نگرانی‌های production را پوشش می‌دهند:
- نتیجه. آیا ایجنت به شرط موفقیت وظیفه دست یافت؟ این همان امتیاز دودویی یا درجه‌بندی‌شده آشناست.
- اعتبار مسیر. آیا مسیر محدودیت‌های وظیفه را رعایت کرد؟ آیا ابزارهای استفاده‌شده مناسب بودند، آرگومان‌ها خوش‌ساخت بودند، مراحل میانی منسجم بودند؟
- بهداشت عوارض جانبی. آیا سیستم‌های خارجی ناخواسته دست‌نخورده ماندند؟ آیا تغییرات موردنظر دقیقاً یک بار، به‌صورت idempotent و به ترتیب درست اعمال شدند؟
- هزینه. token، تأخیر و فراخوانی ابزار، نرمال‌شده نسبت به یک مسیر مرجع یا یک بودجه.
گزارش یک بردار آموزنده‌تر از گزارش یک اسکالر است، اما جدول‌های رتبه‌بندی را پیچیده می‌کند. یک مصالحه صادقانه: امتیازهای برداری سخت‌تر رتبه‌بندی می‌شوند. تیمی که به عوارض جانبی اهمیت می‌دهد و تیمی که به تأخیر اهمیت می‌دهد، ابعاد را متفاوت وزن می‌دهند. بنچمارک باید اجزا را آشکار کند و بگذارد مصرف‌کنندگان تجمیع کنند، نه اینکه یک وزن‌دهی واحد را که ادعای جهان‌شمولی دارد درون خود بپزد.
مصالحه دوم: امتیازدهی مسیرمحور به محیط‌های ابزارگذاری‌شده نیاز دارد. نمی‌توانید وضعیت نهایی سیستم‌های خارجی دلخواه را بدون sandbox کردن آن‌ها یا ساختن آداپتور ثبت کنید. این هزینه مهندسی واقعی است، و دلیل آن است که بسیاری از بنچمارک‌ها از آن پرهیز می‌کنند.
محیط‌های نگه‌داشته‌شده و واریانس
امتیازدهی مسیرمحور فقط وقتی کار می‌کند که ایجنت نتوانسته باشد fixture را حفظ کرده باشد. محیط‌های نگه‌داشته‌شده مکانیزم این کار هستند. بنچمارک باید نمونه‌های وظیفه‌ای تولید یا رزرو کند که ایجنت هرگز ندیده است، ترجیحاً با پارامترهای تصادفی‌شده: نام فایل‌ها، چیدمان پوشه‌ها، پاسخ‌های API و وضعیت‌های اولیه. اگر ایجنت fixture را در طول آموزش یا تنظیم دیده باشد، امتیاز بالا حافظه را می‌سنجد، نه توانایی را.
گزارش واریانس به همان اندازه مهم است. یک اجرای واحد یک اندازه‌گیری نیست. ایجنت‌ها سیستم‌های تصادفی هستند: دمای نمونه‌گیری، ترتیب فراخوانی ابزار و زمان‌بندی محیط همه واریانس ایجاد می‌کنند. بنچمارک باید هر وظیفه را در چندین seed اجرا کند و توزیع امتیازها را گزارش دهد، نه فقط میانگین را. میانگین بالا با دنباله بلندی از شکست‌ها محصولی متفاوت از میانگین کمی پایین‌تر با واریانس فشرده است.
اکوسیستم بنچمارک در این جهت در حال بلوغ است. پوشش تلاش‌های ارزیابی جدید، مانند کار Vals روی بنچمارک AI، بازتاب شناخت گسترده‌تری است از اینکه ارزیابی ایجنت‌ها با ارزیابی مدل‌ها یکسان نیست. جدول‌های رتبه‌بندی مبتنی بر خروجی با ارزیابی فرایندمحور تکمیل می‌شوند، و به حق.
یک مکانیزم مشخص: هارنس بازپخش sandboxشده
یکی از روش‌های عملی برای پیاده‌سازی امتیازدهی مسیرمحور، هارنس بازپخش sandboxشده است. هارنس برای هر اجرا یک محیط تازه تأمین می‌کند: یک کانتینر با فایل‌سیستم، یک سرور API شبیه‌سازی‌شده و یک سیاست شبکه که فراخوانی‌های خروجی را مسدود یا ثبت می‌کند. ایجنت درون آن اجرا می‌شود. پس از اتمام، هارنس از محیط snapshot می‌گیرد، آن را با وضعیت اولیه مقایسه می‌کند و هم ردگیری اقدامات و هم تفاوت وضعیت نهایی را منتشر می‌کند.
چون محیط موقتی است، عوارض جانبی قابل مشاهده و مهارشده‌اند. چون سرور API شبیه‌سازی‌شده است، پاسخ‌ها را می‌توان برای هر seed تصادفی کرد. چون سیاست شبکه صریح است، فراخوانی‌های خارجی ناخواسته ثبت می‌شوند نه اینکه بی‌صدا مجاز شوند. سپس هارنس اجرا را بر اساس بردار توصیف‌شده در بالا امتیاز می‌دهد.
این کار بیشتر از اجرای ایجنت در برابر یک کلید پاسخ ثابت زحمت دارد. همچنین حداقل چیزی است که برای ادعا درباره قابلیت اطمینان ایجنت لازم است تا در برخورد با production دوام بیاورد.
چه چیزی باید گزارش شود
یک گزارش بنچمارک مسیرمحور باید برای هر وظیفه شامل این موارد باشد:
- امتیاز نتیجه، با شرط موفقیت که صریحاً بیان شده باشد.
- پرچم‌های اعتبار مسیر، با نقض‌های مشخص که برشمرده شده باشند.
- تفاوت عوارض جانبی، خلاصه‌شده به‌صورت تعداد منابع ایجادشده، تغییرکرده و حذف‌شده.
- هزینه، تفکیک‌شده بر اساس token و فراخوانی ابزار.
- تعداد تلاش‌های مجدد و عقب‌گردها.
- واریانس در seedها، گزارش‌شده به‌صورت توزیع نه یک عدد واحد.
تجمیع‌شده در وظایف، این یک پروفایل می‌دهد نه یک رتبه. پروفایل‌ها سخت‌تر بازاریابی می‌شوند. همچنین برای تصمیم‌گیری درباره اینکه آیا استقرار یک ایجنت ایمن است مفیدترند.
نتیجه‌گیری
بنچمارک‌هایی که فقط خروجی نهایی را امتیاز می‌دهند، به‌طور سیستماتیک ایجنت‌هایی را پاداش می‌دهند که از مسیرهای ناایمن یا غیرقابل‌تکرار به پاسخ درست می‌رسند. راه‌حل یک کلید پاسخ بهتر نیست. یک واحد تحلیل متفاوت است: مسیر، با آرگومان‌ها، مشاهدات، وضعیت نهایی و هزینه. بر اساس یک بردار امتیاز بدهید. از محیط‌های نگه‌داشته‌شده استفاده کنید. واریانس را گزارش کنید. یک اجرای واحد را یک حکایت بدانید.
مصالحه واقعی است: ساختن امتیازدهی مسیرمحور گران‌تر و خلاصه‌کردنش سخت‌تر است. اما جایگزین آن جدول رتبه‌بندی‌ای است که نمی‌تواند ایجنت دقیق را از ایجنت خوش‌شانس تشخیص دهد، و تصمیم استقراری که بر اساس سیگنال اشتباه گرفته شده است.