LLM-as-judge testleri neden çalıştırma başına farklı sonuç verir
CI'da faithfulness eşiğini kontrol eden LLM hakem, aynı kodda bir gün 0.79 bir gün 0.82 verebilir. Sıcaklık, model sürümü ve belirsiz rubric jitter'ın kaynağı; k-örnekleme ve gürültü bandı çözüm.
Bir mühendis, merge öncesi çalışan faithfulness kapısının (eşik 0.80) aynı commit üzerinde bir çalıştırmada 0.79 ile başarısız olup, hiçbir değişiklik yapılmadan tekrar çalıştırıldığında 0.82 ve 0.80 verdiğini fark ediyor. Sorun kodda değil, LLM hakemin kendisinde: sıfırdan büyük sampling sıcaklığı, kayan model sürümü aliasları (örneğin 'gpt-4o-latest'), belirsiz rubric tanımları ve sınırda kalan puanlarda gürültünün kararı vermesi jitter'ın dört temel kaynağı olarak sıralanıyor.
Çözüm, hakemi bit-seviyesinde deterministik yapmak değil, eşik geçişinin gerçek bir regresyonu yansıtacak kadar gürültüyü küçültmek. Önerilen yaklaşım: sıcaklığı sıfırlamak ve destekleniyorsa seed kullanmak, hakem model sürümünü ve rubric versiyonunu cache anahtarına sabitlemek, k=5 gibi birden fazla örnek alıp ortalama veya çoğunluk oyu kullanmak, skorları kaba bir ızgaraya (0.25 adımlarla) yuvarlamak ve rubric metnini kod gibi versiyonlamak.
Asıl kavramsal düzeltme ise tek bir hakem skorunu mutlak doğru saymamak: k kez puanlayıp ortalama ile standart sapmayı hesaplamak, yalnızca ortalama eşikten ölçülen gürültü payından fazla düşükse başarısız saymak. Paylaşılan Python örneğinde bu mantık stable_judge_score ve gate fonksiyonlarıyla uygulanıyor; SystemExit çıkış kodu CI'nin okuduğu asıl sinyal. Bu değişiklikle çalıştırmalar arası sapma yaklaşık 0.03'ten 0.01'in altına iniyor ve kırmızı sonuç artık gerçek bir düşüşü işaret ediyor.
Mühendislere pratik öneri: hakem çağrısındaki sıcaklığı loglayın, başarılı/başarısız çalıştırmalar arasında model string'ini diff'leyin ve eşiği güvenmeden önce metriğin çalıştırma-içi standart sapmasını ölçün; sapma eşik marjından genişse kapı gürültüyü ölçüyor demektir.