LLM Hakem Testleri Neden Çalıştırmalar Arası Kararsız?
Aynı kod, aynı girdi, farklı LLM hakem skoru: CI gate'lerinde flapping sorununun kaynakları; sıcaklık, model pinleme, k-örnekleme ve kuantalama ile çözüm.
Bir mühendis, merge öncesi çalışan bir 'faithfulness' gate'inin hiçbir kod değişikliği olmadan bir çalıştırmada başarısız, bir sonrakinde başarılı olduğunu keşfediyor. LLM'i hakem olarak kullanan bu kontrol, aynı girdilerde farklı skorlar üretiyor ve bu tutarsızlık, gerçek regresyonlardan daha fazla güven kaybına yol açıyor: insanlar kırmızıyı görünce yeniden çalıştırıp yeşile dönmesini bekleyen bir alışkanlık geliştiriyor.
Sorunun dört kaynağı var: sıfırdan büyük sampling sıcaklığı, sabitlenmemiş model versiyonları (kayan alias'lar gece skorları kaydırıyor), belirsiz rubrikler (bir puanın ne anlama geldiği net değilse model her seferinde farklı yorumluyor) ve eşik değerine yakın sınırda kararların gürültüye kalması.
Çözüm, hakemi tam determinist yapmak değil, gürültüyü eşiği anlamlı kılacak kadar küçültmek. Bunun için sıcaklığı sıfırlamak, tarihli model snapshot'ını pinlemek, rubrik versiyonunu cache anahtarına dahil etmek, k defa örnekleyip ortalama/oy birliği almak ve skorları kaba bir ızgaraya yuvarlamak gerekiyor. Asıl kavramsal düzeltme ise gate mantığının kendisi: tek bir skoru gerçek kabul etmek yerine ortalama ile standart sapmayı ölçüp, ortalama eşiğin gözlenen gürültü payından daha fazla altına düştüğünde başarısız saymak.
Bu yaklaşımla ölçülen çalıştırmalar arası sapma yaklaşık 0.03'ten 0.01'in altına iniyor; bu da kırmızının artık gerçek bir düşüşü, gürültüyü değil, işaret ettiği anlamına geliyor. Mühendisler için ders net: LLM tabanlı değerlendirme gate'lerini üretime almadan önce çalıştırmalar arası varyansı ölçmeden güvenmemek gerekiyor.