Sessiz Arıza Modu
Bir tedarikçi yargıç modelinin yeni bir checkpoint'ini yayınladığında, ürettiği skorlar değişir. Test edilen sistem değişmemiştir, ancak metrik değişmiştir. Çoğu değerlendirme kurulumunda bu hareket, değerlendiriciye değil agent'a atfedilir. Bu, LLM-as-judge'ın sessiz arıza modudur: ölçüm aracı kayar ve dashboard bunu ölçülen şeydeki bir değişiklik olarak raporlar.
Sorun, rubrik kaymasının görünmez olması nedeniyle daha da kötüleşir. Bir yargıç prompt'u zaman içinde düzenlemeler biriktirir: burada açıklayıcı bir cümle, orada yeni bir edge case. Diff yok, sahip yok ve test yok. Sayı hareket eder, ancak neden hareket etmez. Birisi bir metriğin neden kaydığını sorduğunda, yargıç zaten tüm geçmiş boyunca sessizce yeniden skorlanmıştır.
Bir Yargıç Spesifikasyonu Neler İçerir
Bir yargıç bir model değildir. Bir tuple'dır: model tanımlayıcısı ve checkpoint hash'i, decoding temperature ve top-p, system prompt, rubrik metni, few-shot örnekleri ve output schema. Her öğe kararı etkiler. Herhangi birini değiştirin, skorlar değişir.
Bu tuple'ı bir lockfile girdisi olarak ele alın. Çözümlenebilir bir spec olmadan yapılan bir yargıç çalıştırması bir ölçüm değildir; bir görüştür. Spec, eval set sürümü ve test edilen agent commit'i ile birlikte saklanmalıdır. Bu, her skoru yeniden üretilebilir ve her karşılaştırmayı anlamlı kılar.
Pratikte, bir yargıç spec'i şöyle görünebilir:
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 }

Ödünleşim ek yüktür. Her yargıcı sabitlemek ve sürümlemek deneylere sürtünme ekler. Ancak alternatif, güvenemeyeceğiniz bir metriktir ki bu hiç metrik olmamasından daha kötüdür.
İnsan Etiketlerine Karşı Kalibrasyon
Bir yargıç, insan yargısının bir vekilidir. Bu vekilin ne kadar iyi olduğunu bilmek için sabit bir insan etiketli anchor set'e ihtiyacınız vardır. Bu, insanların doğru karar üzerinde anlaştığı küçük bir örnek setidir. Herhangi bir downstream karşılaştırmaya güvenmeden önce, bu anchor set üzerindeki yargıç uyumunu raporlayın.
Uyum, tek bir toplu doğruluk olarak değil, rubrik boyutu başına izlenmelidir. Bir yargıç, doğruluk konusunda insanlarla %90 oranında uyuşabilirken ton konusunda yalnızca %60 oranında uyuşabilir. Toplulaştırma bunu gizler. Boyut başına izleme, yargıcın nerede zayıf olduğunu ve insan incelemesinin nerede gerekli olduğunu ortaya koyar.
Düşük uyumlu boyutları işaretleyin ve bunları otomatik kapılara değil insan incelemesine yönlendirin. Bu bir aktif öğrenme biçimidir: yargıç size nerede belirsiz olduğunu söyler ve siz insan emeğini oraya harcarsınız. Ödünleşim, insan incelemesinin yavaş ve pahalı olmasıdır, bu yüzden her yerde yapamazsınız. Anchor set küçük ve kararlı olmalı ve yönlendirme kuralı açık olmalıdır.
Değerlendirici için Regresyon Testleri
Bir yargıç koddur. Testleri olmalıdır. En temel olanlar, beklenen kararlarla bilinen-iyi ve bilinen-kötü trajectory'lerdir. Bir yargıç değişikliği bunları tersine çevirirse,
ators-fe71ad-47747d.jpg)

Adversarial vakalar da aynı derecede önemlidir: ayrıntılı-ama-yanlış yanıtlar, kısa-ama-doğru yanıtlar, reddetmeler ve yalnızca tool-call çıktıları. Bunlar, yargıcın özden ziyade yüzey biçimine duyarlı olup olmadığını test eder. Ayrıntılı yanlış bir yanıtı kısa doğru bir yanıttan daha yüksek puanlayan bir yargıç, düşündüğünüz şeyi ölçmüyor demektir.
Skor kararlılığı başka bir testtir. Aynı trace'in tekrarlanan yargılanması, beyan edilen bir toleransın ötesinde değişmemelidir. Yargıç deterministik değilse, bu varyans ölçüm hatasının bir parçasıdır ve raporlanmalıdır. Aynı girdilerde farklı skorlar veren bir yargıç güvenilir bir araç değildir.
Buradaki ödünleşim test bakımıdır. Her yeni edge case bir test haline gelir. Ancak bozuk bir yargıcın maliyeti, onarımı çok daha pahalı olan bozulmuş bir değerlendirme geçmişidir.
Sinyal Olarak Yargıçlar Arası Uyuşmazlık
Bir örnek üzerinde farklı model ailelerinden iki yargıç çalıştırmak, belirsiz rubrik dilini yerelleştirebilir. Uyuşmadıklarında, bu genellikle rubriğin net olmamasından kaynaklanır, bir yargıcın yanlış olmasından değil. Uyuşmazlık bir rubrik kusur raporudur, ortalaması alınacak bir beraberlik değil.
Uyuşmazlık oranını skorun yanında yayınlayın ki okuyucular hata payını bilsin. %30 uyuşmazlık oranıyla 4.2'lik bir skor, %2 uyuşmazlık oranıyla 4.2'lik bir skordan çok farklıdır. İlki rubriğin çalışmaya ihtiyacı olduğunu düşündürür; ikincisi yargıçların uyumlu olduğunu düşündürür.
Ödünleşim maliyettir: iki yargıç çalıştırmak inference'ı ikiye katlar. Ancak rubrik kalitesi hakkında kazanılan bilgi, özellikle rubrik geliştirme sırasında, genellikle buna değer.
Sonuç
LLM-as-judge güçlü bir tekniktir, ancak yalnızca en zayıf halkası kadar güvenilirdir. Modeli, prompt'u, rubriği ve decoding parametrelerini sabitleyin. Bunları diğer bağımlılıklar gibi sürümleyin. Değerlendiriciyi regresyon testine tabi tutun. İnsan etiketlerine karşı kalibre edin. Yargıçlar arası uyuşmazlığı gürültü değil sinyal olarak ele alın. Yargıç bir bileşen olduğunda, değerlendirme bir ölçüm haline gelir.
