یک امتیاز در واقع چه چیزی را می‌سنجد
یک اجرای بنچمارک، اندازه‌گیری مدل نیست. نمونه‌ای است از یک توزیع مشترک روی دست‌کم چهار چیز: وزن‌های مدل و تنظیمات decoding، تعریف ابزارهایی که به مدل داده می‌شود، محدودیت‌های زمان اجرایی که مدل تحت آن کار می‌کند، و محیطی که آن ابزارها به آن دسترسی دارند. هر یک از این‌ها را تغییر دهید و عدد جابه‌جا می‌شود. بیشتر لیدربوردهای منتشرشده مورد اول را ثابت نگه می‌دارند و بقیه را ضمنی رها می‌کنند؛ به همین دلیل دو آزمایشگاه می‌توانند همان بنچمارک را با همان مدل گزارش کنند و با اختلافی ناهم‌خوان باشند که اختلاف میان خود مدل‌های مقایسه‌شده را تحت‌الشعاع قرار می‌دهد.
این شکایت از طراحی بنچمارک نیست. بنچمارک‌ها عمدتاً خوب‌اند. مشکل این است که هارنس — همان داربستی که یک مدل را به agent تبدیل می‌کند — به‌عنوان جزئیات پیاده‌سازی تلقی می‌شود، در حالی که در واقع همان متغیر مستقلی است که تعیین می‌کند agent اصلاً چه چیزی را می‌تواند بیازماید. مدلی که در چهار گام برنامه‌ریزی می‌کند و مدلی که بیست گام دست‌وپا می‌زند، زیر سقف گام بیست‌وپنج و بودجه تلاش مجدد پنج، از هم قابل تفکیک نیستند. هارنس پیش از آنکه از مدل پرسشی پرسیده شود، پاسخ را داده است.
هارنس را بخشی از خود محصول بدانید. یک رکورد eval باید اسکیمای ابزارها را با هش، ایمیج زمان اجرا را با digest، تعداد تلاش مجدد، سقف گام، بودجه زمان واقعی و token، و سیاست شبکه sandbox را ثبت کند. بدون این فیلدها، امتیاز شایعه‌ای است با یک رقم اعشار.
حالت‌های شکستی که هارنس پنهان می‌کند
سقف‌های سخاوتمندانه گام، تلاش‌های مجدد brute-force را به‌جای برنامه‌ریزی پاداش می‌دهند. اگر یک agent بتواند همان ابزار جست‌وجو را یازده بار با کوئری‌های کمی متفاوت فراخوانی کند، مدلی که هرگز برنامه‌ای نمی‌سازد هم به پاسخ می‌رسد و دقیقاً شبیه مدلی به نظر می‌رسد که یک بار برنامه‌ریزی کرده و پاکیزه اجرا کرده است. سقف را به چهار گام کاهش دهید و رتبه‌بندی وارونه می‌شود. هیچ‌کدام از این دو پیکربندی غلط نیست؛ هر دو محصولاتی مشروع‌اند. اما یک عدد منتشرشده واحد نمی‌تواند نماینده هر دو باشد، و خوانندگان فرض می‌کنند نماینده وضعیت خودشان است.
شکست مقابل به همان اندازه بی‌صدا است. محدودیت‌های تنگ مدل‌هایی را جریمه می‌کنند که خوب بازیابی می‌کنند. agentی که پاسخ بدشکل ابزار را تشخیص می‌دهد، آرگومان‌هایش را اصلاح می‌کند و در تلاش دوم موفق می‌شود، دقیقاً همان کاری را می‌کند که سیستم‌های production نیاز دارند، و در عوض کندتر و پرهزینه‌تر از مدلی امتیاز می‌گیرد که تصادفاً بار اول درست انجامش داده است. اگر سیاست تلاش مجدد منتشر نشود، خواننده نمی‌تواند بفهمد امتیاز پاداش شایستگی است یا شانس.
سیاست شبکه sandbox مهم‌ترین تنظیم نامرئی است. اجرایی با egress غیرفعال، برنامه‌ریزی و استدلال درباره ابزارها را می‌سنجد، نه استفاده از ابزار را. اجرایی با egress فعال می‌سنجد که آیا مدل می‌تواند از latency واقعی، شکست‌های جزئی و اسکیماهای ناسازگار جان سالم به در ببرد. این‌ها دو محصول متفاوت‌اند. وقتی فروشنده‌ای امتیاز استفاده از ابزار را بدون ذکر سیاست شبکه گزارش می‌کند، خواننده هیچ راهی ندارد بداند کدام‌یک از این دو سنجیده شده، و این دو با هم قابل مقایسه نیستند.
stubهای قطعی ابزار تله‌ای مرتبط است. stub کردن یک API جست‌وجو برای بازگرداندن یک سند ثابت، ابهامی را که agentهای production واقعاً با آن روبه‌رو هستند حذف می‌کند — نتایج بریده، ایندکس‌های کهنه، محدودیت نرخ، انحراف اسکیما. stub باعث می‌شود eval بازتولیدپذیر شود، که ارزشمند است، و آن را غیرنماینده می‌کند، که همان بده‌بستانی است که باید صریحاً بیانش کنید نه اینکه بی‌صدا بپذیرید. موضع صادقانه اجرای هر دو است: یک مجموعه stubشده برای تشخیص regression و یک مجموعه زنده برای ادعاهای توانمندی، که به‌صورت اعداد جداگانه با manifest هارنس پیوست‌شده به هرکدام منتشر می‌شوند.
یک قرارداد انتشار برای نتایج eval
اگر قرار است به یک امتیاز استناد شود، باید همراه با شرایطی که آن را تولید کرده منتشر شود. یک قرارداد عملی چهار بخش دارد.
manifest هارنس را همراه با امتیاز منتشر کنید. دست‌کم: هش‌های اسکیمای ابزار، digest ایمیج زمان اجرا، بودجه‌های گام و زمان، تعداد تلاش‌های مجدد، سیاست شبکه، پارامترهای decoding و مجموعه seed. manifest باید ماشین‌خوان باشد تا خواننده بتواند دو نتیجه را diff کند و فوراً ببیند آیا قابل مقایسه‌اند یا نه. امتیاز بدون manifest یک حکایت است.
واریانس را گزارش کنید، نه یک برآورد نقطه‌ای. روی seedها و دست‌کم روی دو گونه هارنس — یک بودجه تنگ و یک بودجه گشاد — اجرا کنید و پراکندگی را منتشر کنید. اگر امتیاز مدلی وقتی سقف گام از بیست به هشت کاهش می‌یابد فرو می‌ریزد، این مفیدترین چیزی است که می‌توانید به خواننده بگویید، و یک میانگین واحد کاملاً آن را پنهان می‌کند.
بازپخش رخدادها را در برابر همان نسخه هارنس قابل اجرا کنید. وقتی agentی در production بدرفتاری می‌کند، regression تنها در صورتی قابل انتساب است که بازپخش در برابر همان هارنسی اجرا شود که آن رفتار را تولید کرده است. هارنس را همان‌طور نسخه‌بندی کنید که مدل را نسخه‌بندی می‌کنید، و نسخه‌های قدیمی را قابل اجرا نگه دارید. این همان بخشی است که تیم‌ها از آن می‌گذرند، و همان بخشی است که مجموعه eval را از یک محصول زمان عرضه به یک ابزار مهندسی تبدیل می‌کند.
بده‌بستانی را که پذیرفته‌اید بیان کنید. هر انتخاب هارنس بازتولیدپذیری را به بهای نمایندگی می‌خرد، یا برعکس. بگویید کدام راه را رفته‌اید. یک مجموعه stubشده، شبکه‌جداشده و با بودجه تنگ چیز خوبی برای انتشار است، تا زمانی که برچسبش همین را بگوید.
چرا این یک مسئله مهندسی است، نه یک مسئله گزارش‌دهی
وسوسه این است که افشای هارنس را یک کار مستندسازی بدانیم — جدولی به پیوست اضافه کنیم و برویم. این‌طور نیست. وقتی هارنس نسخه‌بندی شد، به چیزی تبدیل می‌شود که می‌توانید تستش کنید، regressionاش را رصد کنید و درباره‌اش استدلال کنید، و این نحوه ساخت سیستم را تغییر می‌دهد. اسکیماهای ابزار مثل قراردادهای API بازبینی می‌شوند. سیاست‌های تلاش مجدد بر اساس نرخ‌های بازیابی اندازه‌گیری‌شده تنظیم می‌شوند نه شهود. سقف‌های گام به تصمیمی محصولی با دلیل بیان‌شده تبدیل می‌شوند، نه پیش‌فرضی که از یک نمونه فریم‌ورک به ارث رسیده است.
هزینه واقعی است: نگهداری چند گونه هارنس، قابل اجرا نگه داشتن ایمیج‌های قدیمی زمان اجرا، و اجرای هر مجموعه روی یک مجموعه seed، محاسبات و زمان مهندسی را چند برابر می‌کند. تیم‌هایی با یک مدل و یک محصول این را سنگین‌تر از نیاز خود خواهند یافت. موضع صادقانه این است که قرارداد کامل زمانی به سود می‌رسد که در حال مقایسه میان مدل‌ها یا میان آزمایشگاه‌ها هستید — که دقیقاً همان زمانی است که احتمال نقل‌قول عدد خارج از زمینه بیشترین است.
برای پیش‌زمینه‌ای درباره اینکه این مقایسه‌ها اکنون چگونه گزارش می‌شوند و شکاف‌ها کجا هستند، این بحث اخیر درباره رویه ارزیابی agent را ببینید.
بنچمارک متغیری نیست که از دست داده‌اید. هارنس است، و همان چیزی است که امروز می‌توانید نسخه‌بندی کنید.
