حالت شکست خاموش
وقتی یک فروشنده چک‌پوینت جدیدی از یک مدل قاضی منتشر می‌کند، امتیازاتی که تولید می‌کند تغییر می‌کنند. سیستم تحت تست تغییر نکرده است، اما متریک تغییر کرده است. در بیشتر تنظیمات ارزیابی، این جابه‌جایی به agent نسبت داده می‌شود، نه به گریدر. این حالت شکست خاموش LLM-as-judge است: ابزار اندازه‌گیری منحرف می‌شود و داشبورد آن را به‌عنوان تغییری در چیزی که اندازه‌گیری می‌شود گزارش می‌کند.
مشکل تشدید می‌شود زیرا انحراف روبریک نامرئی است. یک پرامپت قاضی در طول زمان ویرایش‌هایی جمع می‌کند: یک جمله توضیحی اینجا، یک edge case جدید آنجا. هیچ diff، هیچ مالکی و هیچ تستی وجود ندارد. عدد حرکت می‌کند، اما علت آن نه. تا زمانی که کسی بپرسد چرا یک متریک تغییر کرده است، قاضی قبلاً به‌صورت خاموش در کل تاریخچه دوباره امتیازدهی شده است.
یک مشخصات قاضی شامل چه چیزی است
یک قاضی یک مدل نیست. یک تاپل است: شناسه مدل و هش چک‌پوینت، دمای دیکودینگ و top-p، system prompt، متن روبریک، نمونه‌های few-shot و اسکیمای خروجی. هر عنصر بر حکم تأثیر می‌گذارد. هر یک را تغییر دهید، و امتیازات تغییر می‌کنند.
آن تاپل را به‌عنوان یک ورودی lockfile در نظر بگیرید. اجرای قاضی بدون یک مشخصات قابل حل، یک اندازه‌گیری نیست؛ یک نظر است. مشخصات باید در کنار نسخه مجموعه eval و کامیت agent تحت تست ذخیره شود. این هر امتیاز را قابل بازتولید و هر مقایسه را معنادار می‌کند.
در عمل، یک مشخصات قاضی ممکن است به این شکل باشد:
judge_spec:
model: "vendor/model-name"
checkpoint: "sha256:abc123..."
temperature: 0.0
top_p: 1.0
system_prompt: |
You are a strict evaluator. Score the response on a scale of 1-5 for correctness.
rubric: |
Correctness: 5 = fully correct, 3 = partially correct, 1 = incorrect.
exemplars:
- input: "What is 2+2?"
output: "4"
score: 5
- input: "What is 2+2?"
output: "5"
score: 1
output_schema:
type: object
properties:
score: { type: integer, minimum: 1, maximum: 5 }
reasoning: { type: string }
معاوضه، سربار است. پین و نسخه‌بندی هر قاضی اصطکاک را به آزمایش اضافه می‌کند. اما جایگزین آن متریکی است که نمی‌توانید به آن اعتماد کنید، که بدتر از نداشتن متریک است.
کالیبراسیون در برابر برچسب‌های انسانی
یک قاضی یک پروکسی برای قضاوت انسانی است. برای دانستن اینکه این پروکسی چقدر خوب است، به یک مجموعه لنگر ثابت با برچسب انسانی نیاز دارید. این مجموعه کوچکی از نمونه‌هاست که در آن انسان‌ها بر حکم صحیح توافق کرده‌اند. قبل از اعتماد به هر مقایسه پایین‌دستی، توافق قاضی را روی آن مجموعه لنگر گزارش دهید.
توافق باید به‌ازای هر بُعد روبریک ردیابی شود، نه به‌عنوان یک دقت تجمیعی واحد. یک قاضی ممکن است ۹۰٪ مواقع در صحت با انسان‌ها توافق کند اما فقط ۶۰٪ در لحن. تجمیع آن را پنهان می‌کند. ردیابی به‌ازای هر بُعد نشان می‌دهد قاضی کجا ضعیف است و بازبینی انسانی کجا لازم است.
ابعاد با توافق پایین را علامت‌گذاری کنید و آن‌ها را به بازبینی انسانی هدایت کنید نه به گیت‌های خودکار. این شکلی از یادگیری فعال است: قاضی به شما می‌گوید کجا مطمئن نیست، و شما تلاش انسانی را آنجا صرف می‌کنید. معاوضه این است که بازبینی انسانی کند و گران است، بنابراین نمی‌توانید آن را همه‌جا انجام دهید. مجموعه لنگر باید کوچک و پایدار باشد، و قاعده مسیریابی باید صریح باشد.
تست‌های رگرسیون برای گریدر
یک قاضی کد است. باید تست داشته باشد. ابتدایی‌ترین آن‌ها مسیرهای known-good و known-bad با احکام مورد انتظار هستند. اگر تغییری در قاضی آن‌ها را برگردان
ators-fe71ad-47747d.jpg)
موارد خصمانه به همان اندازه مهم هستند: پاسخ‌های پرگو اما اشتباه، پاسخ‌های مختصر اما صحیح، رد کردن‌ها و خروجی‌های فقط tool-call. این‌ها تست می‌کنند که آیا قاضی به شکل سطحی حساس است یا به محتوا. قاضی‌ای که به یک پاسخ اشتباه پرگو امتیاز بالاتری از یک پاسخ صحیح مختصر می‌دهد، آنچه فکر می‌کنید را اندازه‌گیری نمی‌کند.
پایداری امتیاز تست دیگری است. قضاوت مکرر یک trace یکسان نباید فراتر از یک تلورانس اعلام‌شده تغییر کند. اگر قاضی غیرقطعی است، آن واریانس بخشی از خطای اندازه‌گیری است و باید گزارش شود. قاضی‌ای که به ورودی‌های یکسان امتیازات متفاوتی می‌دهد، ابزار قابل اعتمادی نیست.
معاوضه در اینجا نگهداری تست است. هر edge case جدید به یک تست تبدیل می‌شود. اما هزینه یک قاضی شکسته، یک تاریخچه ارزیابی خراب است، که تعمیر آن بسیار گران‌تر است.
اختلاف بین قاضی‌ها به‌عنوان یک سیگنال
اجرای دو قاضی از خانواده‌های مدل مختلف روی یک نمونه می‌تواند زبان روبریک مبهم را محلی‌سازی کند. وقتی آن‌ها اختلاف دارند، اغلب به این دلیل است که روبریک نامشخص است، نه به این دلیل که یک قاضی اشتباه می‌کند. اختلاف یک گزارش نقص روبریک است، نه یک تساوی که باید میانگین گرفته شود.
نرخ اختلاف را در کنار امتیاز منتشر کنید تا خوانندگان نوار خطا را بدانند. امتیاز ۴.۲ با نرخ اختلاف ۳۰٪ بسیار متفاوت از امتیاز ۴.۲ با نرخ اختلاف ۲٪ است. اولی نشان می‌دهد روبریک نیاز به کار دارد؛ دومی نشان می‌دهد قاضی‌ها هم‌راستا هستند.
معاوضه هزینه است: اجرای دو قاضی inference را دو برابر می‌کند. اما اطلاعات به‌دست‌آمده درباره کیفیت روبریک اغلب ارزش آن را دارد، به‌ویژه در طول توسعه روبریک.
نتیجه‌گیری
LLM-as-judge یک تکنیک قدرتمند است، اما تنها به‌قدر ضعیف‌ترین حلقه‌اش قابل اعتماد است. مدل، پرامپت، روبریک و پارامترهای دیکودینگ را پین کنید. آن‌ها را مانند هر وابستگی دیگر نسخه‌بندی کنید. گریدر را رگرسیون‌تست کنید. در برابر برچسب‌های انسانی کالیبره کنید. اختلاف بین قاضی‌ها را به‌عنوان یک سیگنال در نظر بگیرید، نه نویز. وقتی قاضی یک کامپوننت است، ارزیابی به یک اندازه‌گیری تبدیل می‌شود.