هزینهٔ پنهان یک قاضی ارزان‌تر
خطوط ارزیابی تحت فشار کاهش هزینه هستند. یک اقدام رایج جایگزینی مدل قاضی گران با مدلی ارزان‌تر است. صورتحساب inference کاهش می‌یابد، خط لوله همچنان امتیاز تولید می‌کند و داشبورد سبز می‌ماند. آنچه دیده نمی‌شود این است که امتیازها دیگر روی یک مقیاس نیستند. قاضی یک ابزار اندازه‌گیری بی‌طرف نیست. قاضی مدلی است با سوگیری‌ها، رفتار decoding و حالت‌های شکست خاص خود. جایگزینی آن اندازه‌گیری را تغییر می‌دهد، نه فقط هزینه را.
این مقاله استدلال می‌کند که جایگزینی قاضی تنها زمانی مشروع است که قاضی به‌عنوان یک وابستگی نسخه‌بندی‌شده تلقی شود: پین‌شده، ثبت‌شده و آزمون‌شده با رگرسیون. بدون این انضباط، صرفه‌جویی به بهای از دست رفتن قابلیت مقایسه پرداخت می‌شود، و قابلیت مقایسه تمام هدف یک خط لولهٔ ارزیابی است.
چرا جایگزینی قاضی تاریخ را می‌شکند
دو نسخهٔ قاضی امتیازهایی تولید می‌کنند که مستقیماً قابل مقایسه نیستند، حتی وقتی متن rubric بایت‌به‌بایت یکسان است. مدل قاضی پیشین خود را وارد می‌کند: اینکه یک بند rubric را چقدر سخت‌گیرانه تفسیر می‌کند، امتیاز جزئی را چگونه وزن‌دهی می‌کند، و ابهام را چگونه مدیریت می‌کند. rubricی که می‌گوید «پاسخ باید به یک منبع ارجاع دهد» توسط مدل کوچکی که بر حضور یک URL الگو‌یابی می‌کند و مدل بزرگ‌تری که بررسی می‌کند آیا منبع ارجاع‌شده از ادعا پشتیبانی می‌کند یا نه، متفاوت خوانده می‌شود. rubric یکسان است؛ اندازه‌گیری یکسان نیست.
این یک نگرانی نظری نیست. این رایج‌ترین علت جابه‌جایی توضیح‌ناپذیر امتیاز در ارزیابی agent است. یک leaderboard که نسخه‌های قاضی را با هم مخلوط می‌کند، در واقع قاضی را اندازه می‌گیرد، نه سیستم تحت آزمون را. وقتی قاضی جدیدی بی‌سروصدا مستقر می‌شود، امتیازهای تاریخی به مخلوطی از دو توزیع تبدیل می‌شوند. روندها در طول زمان غیرقابل تفسیر می‌شوند. رگرسیونی که در هفتهٔ ششم ظاهر می‌شود ممکن است ارتقای قاضی در هفتهٔ پنجم باشد.
پیامد عملی این است که هر مقایسه‌ای میان اجراها مستلزم ثابت نگه داشتن نسخهٔ قاضی است، یا مدل‌سازی صریح جابه‌جایی مقیاس. بیشتر تیم‌ها هیچ‌کدام را انجام نمی‌دهند. آن‌ها قاضی را زیرساختی می‌دانند که می‌توان در جای خود ارتقا داد، مانند یک patch زمان اجرا. اما یک patch زمان اجرا معنای یک متریک را تغییر نمی‌دهد. ارتقای قاضی تغییر می‌دهد.
با قاضی مانند یک مؤلفه رفتار کنید
راه‌حل این است که با قاضی همان‌گونه رفتار شود که یک سیستم جدی با یک schema یا یک checkpoint مدل رفتار می‌کند. این یعنی ثبت هویت کامل قاضی که امتیاز را تولید کرده، در هر رکورد نتیجه:
- شناسهٔ مدل و revision ارائه‌دهنده؛
- پارامترهای decoding (temperature، top-p، max tokens، seed در صورت وجود)؛
- هش prompt قاضی و متن rubric؛
- شمارهٔ revision rubric.
یک رکورد نتیجه بدون این فیلدها بازتولیدپذیر نیست. یک حکایت است.
یک سازوکار مشخص این است که خروجی خام قاضی را در کنار خروجی کاندید ذخیره کنید. اگر قاضی یک حکم ساختاریافته برمی‌گرداند، پاسخ کامل را ذخیره کنید، نه فقط امتیاز تجزیه‌شده را. این کار بازنمره‌دهی را بدون اجرای مجدد agent تحت آزمون ممکن می‌کند. وقتی قاضی ارتقا می‌یابد، خروجی‌های کاندید قدیمی می‌توانند تحت قاضی جدید بازنمره‌دهی شوند و دو مجموعه امتیاز مستقیماً مقایسه شوند. بدون خروجی‌های ذخیره‌شدهٔ قاضی، مهاجرت قاضی اجرای کامل مجدد agent را تحمیل می‌کند، که معمولاً بخش گران خط لوله است.
قاضی را همان‌گونه نسخه‌بندی کنید که یک schema را نسخه‌بندی می‌کنید. وقتی مقیاس جابه‌جا می‌شود، یک یادداشت مهاجرت بنویسید: چه چیزی تغییر کرد، چرا، و اثر مورد انتظار بر امتیازها چیست. یادداشت مهاجرت بوروکراسی نیست. این تنها راهی است که خوانندهٔ داشبورد می‌تواند یک رگرسیون واقعی را از یک تغییر اندازه‌گیری تشخیص دهد.
قاضی‌های ارزان به ارزیابی خود نیاز دارند
قاضی ارزان‌تر یک مؤلفهٔ جدید است، و مؤلفه‌های جدید به ارزیابی خود نیاز دارند. پرسش مرتبط این نیست که آیا قاضی ارزان به‌طور کلی خوب است، بلکه این است که آیا با یک مرجع مورد اعتماد روی خانواده‌های وظیفه‌ای که خط لوله واقعاً پوشش می‌دهد توافق دارد. مرجع می‌تواند یک نمونهٔ انسانی نگه‌داشته‌شده یا یک قاضی گران‌تر باشد که به‌ندرت به‌عنوان oracle استفاده می‌شود.
توافق را به تفکیک هر خانوادهٔ وظیفه اندازه بگیرید، نه به‌صورت تجمیعی. یک قاضی می‌تواند در طبقه‌بندی قابل اعتماد و در صحت چندمرحله‌ای بی‌فایده باشد. توافق تجمیعی این را پنهان می‌کند. اگر خط لوله ده خانوادهٔ وظیفه را پوشش دهد و قاضی ارزان در نُه مورد با oracle توافق داشته باشد اما در مهم‌ترین مورد واگرا شود، عدد تجمیعی گمراه‌کننده است.
آستانهٔ عدم توافق را طوری تعیین کنید که خط لوله را مسدود کند، نه اینکه به داشبورد هشدار دهد. هشدار سیگنالی است که تحت فشار ضرب‌الاجل نادیده گرفته می‌شود. مسدودسازی سیگنالی است که باید حل شود. آستانه باید به تفکیک هر خانوادهٔ وظیفه تعریف شود، با یک fallback مستند: وقتی نرخ عدم توافق قاضی ارزان از آستانه فراتر می‌رود، خط لوله آن خانوادهٔ وظیفه را به قاضی گران یا بازبینی انسانی هدایت می‌کند. این صرفه‌جویی هزینه را در جایی که ایمن است حفظ می‌کند و در جایی که نیست حذف می‌کند.
اینجا یک بده‌بستان صادقانه وجود دارد. مسدودسازی بر اساس عدم توافق latency و اصطکاک عملیاتی اضافه می‌کند. این مستلزم نگهداری یک نمونهٔ oracle و اجرای مجدد بررسی‌های توافق هنگام تغییر rubric است. تیم‌هایی که این را نادیده می‌گیرند در حال صرفه‌جویی در تلاش نیستند؛ آن را به لحظه‌ای موکول می‌کنند که 
etwork-cables-macro-e398d9-23b10f.jpg)
استدلال هزینه، صادقانه بیان‌شده
هزینهٔ قاضی معمولاً کسر کوچکی از هزینهٔ اجرای agent است. agent تحت آزمون ممکن است فراخوانی‌های مدل زیادی انجام دهد، از ابزارها استفاده کند و دوباره تلاش کند. قاضی برای هر خروجی کاندید یک فراخوانی انجام می‌دهد. بهینه‌سازی قاضی پیش از agent اغلب ترتیب اشتباه عملیات است. اهرم بزرگ‌تر معمولاً بودجهٔ token و ابزار خود agent است، نه هزینهٔ inference قاضی.
صرفه‌جویی واقعی قاضی‌های ارزان، سرعت تکرار روی rubric است، نه هزینهٔ inference. یک قاضی ارزان به تیم اجازه می‌دهد مجموعه‌ای ذخیره‌شده از خروجی‌های کاندید را هنگام پالایش متن rubric بارها بازنمره‌دهی کند. این یک مزیت واقعی است: تکرار rubric جایی است که کیفیت ارزیابی واقعاً بهبود می‌یابد. اما این به خروجی‌های ذخیره‌شدهٔ قاضی و یک نسخهٔ پین‌شدهٔ قاضی بستگی دارد. بدون آن‌ها، قاضی ارزان فرایندی را تسریع می‌کند که اعداد غیرقابل مقایسه تولید می‌کند.
اگر قاضی ارزان آنچه را که عرضه می‌کنید تغییر دهد، صرفه‌جویی منفی است. قاضی‌ای که ارزان‌تر اما پرنویزتر است، کاندیدها را متفاوت تأیید یا رد می‌کند. اگر این تفاوت یک تصمیم انتشار را جابه‌جا کند، هزینهٔ خطای تصمیم در برابر صرفه‌جویی inference ناچیز می‌شود. مقایسهٔ درست، هزینهٔ قاضی در برابر هزینهٔ قاضی نیست. هزینهٔ قاضی به‌علاوهٔ خطای تصمیم در برابر هزینهٔ قاضی به‌علاوهٔ خطای تصمیم است.
یک انضباط حداقلی
هیچ‌کدام از این‌ها به یک پلتفرم بزرگ نیاز ندارد. به چهار عادت نیاز دارد:
- هویت قاضی را در هر رکورد نتیجه پین کنید، از جمله هش‌های prompt و rubric.
- خروجی‌های قاضی را در کنار خروجی‌های کاندید ذخیره کنید تا بازنمره‌دهی بدون اجرای مجدد agent ممکن باشد.
- یک نمونهٔ oracle نگه دارید و توافق را به تفکیک هر خانواده اندازه بگیرید، با یک آستانهٔ مسدودکننده.
- هر بار که نسخهٔ قاضی تغییر می‌کند یک یادداشت مهاجرت بنویسید، و یک مجموعهٔ کاندید ثابت را بازنمره‌دهی کنید تا جابه‌جایی مقیاس کمّی شود.
این همان انضباطی است که برای هر وابستگی مؤثر بر خروجی اعمال می‌شود. ارتقای درایور پایگاه داده پیش از رسیدن به production آزمون می‌شود. ارتقای قاضی معنای هر امتیاز در خط لوله را تغییر می‌دهد. تلقی آن به‌عنوان یک جایگزینی سرسری یک خطای مقوله‌ای است.
پرسش کاهش هزینه مشروع است. بودجه‌های ارزیابی واقعی هستند. اما صرفه‌جویی از یک قاضی ارزان‌تر تنها زمانی واقعی است که قابلیت مقایسه حفظ شود. در غیر این صورت خط لوله اعدادی تولید می‌کند که شبیه اندازه‌گیری به نظر می‌رسند و مانند نویز رفتار می‌کنند.