Ortalamanın gizlediği hata

RAG uygulamaları için küçük bir değerlendirici yazdım. RAG, modelin cevap vermeden önce belgelerinizi okuması demek. Araç; cevabın gerçek kaynaklara atıf yapmasını, beklenen kaynakları kullanmasını, beklenen bilgileri içermesini ve kanıt yokken yanıt vermemesini kontrol ediyor. Sonra bu dört puanın ortalamasını alıyor.

Kontrollerin çoğunun inceleyecek bir şeyi yoksa ne olacağını görmek istedim. Mevcut kanıtsız vakayı alıp temkinli cevabı uydurma bir cevapla değiştirdim. Oyun alanı, model çağırmadan bu hesabı tekrar üretiyor. Kaynak kodu, bu örnekte incelediğim sürüme sabitledim.

Bir cevap, dört puan

Soru şuydu: “Şirket Mars ofisini destekleyecek mi?” Getirilmiş kaynak, beklenen atıf ve beklenen bilgi yoktu. Test, eldeki bilginin yetmediğini söylemeyi bekliyordu.

Ben şu cevabı verdim: “Evet, Mars ofisi 2027'de açılıyor.” Bu, kurduğum bir test cevabı. Gerçek bir şirket hakkında iddia ya da production olayı değil.

Üç tam puan. Cevap hâlâ uydurma.

İlk üç sonuç, değerlendiricinin boş küme kuralından geliyor. Yardımcı fonksiyon, payda sıfırken 1.0 döndürüyor:

def safe_ratio(numerator: int, denominator: int, *, empty_value: float = 1.0) -> float:
    return empty_value if denominator == 0 else numerator / denominator

Tek bir metrik için bu yararlı olabilir. Sıfıra bölmeyi önler; beklenen öğelerden hiçbirinin eksik kalmadığını söyler. Fakat bu vakada, cevabın verilmesinin doğru olup olmadığını ölçmez.

Sorun eşikte ortaya çıkıyor

Ortalama (1 + 1 + 1 + 0) / 4 = 0.75. Kaynak koddaki varsayılan alt sınır 0.80. Cevap kalıyor. Diğer her şeyi sabit tutup sınırı 0.75'e indirince geçiyor.

Hata listesinde hâlâ abstention_policy var. Mevcut geçme kararı, ortalamaya ve gecikme sınırına bakıyor. Hata listesinin boş olmasını ayrıca şart koşmuyor.

passed = score >= suite.config.minimum_case_score and latency

Görünür kılmak istediğim boşluk buydu. Başarısız bir kuralı kaydetmek, onu yayın engeline dönüştürmüyor. Cevap iyileşmeden yapılan eşik değişikliği, başarısız vakayı geçirebiliyor.

Yerine kullanacağım kapı

Bu değerlendiricide ortalamayı raporlama sayısı olarak tutardım. Yayın kararında önce hangi kontrollerin vakaya uygulanabildiğini belirler, sonra gerekli her kontrol için açık bir alt sınır koyardım. Yanıt vermeme ihlali tek başına vakayı engellerdi.

const requiredPass = abstentionCorrect &&
  checks.filter(check => check.applies)
    .every(check => check.score >= check.minimum);

Lab, bu öneriyi mevcut ortalama kapısıyla karşılaştırıyor. Sınırı kolayca araştırmak için uygulanabilir kontrollerde ortak eşik kullanıyor. İlk üç boş kontrol önerilen kapının dışında kalıyor. Kaynak koddaki yanıt vermeme kontrolü doğru/yanlış döndürdüğü için dördüncü sürgü yalnız 0 veya 1 alıyor.

Sürgüyü değiştirmek farklı bir puanı simüle eder. Modelden cevabı düzeltmesini istemez; dil hakemini yeniden çalıştırmaz. İki sütunda da gecikme sınırının sağlandığı kabul edilir. Bu yüzden yanıt vermeme puanını 1 yapmak, “bu kontrol geçseydi” anlamına gelir. Sabit Mars iddiasını doğru yapmaz. Önerilen politika bu oyun alanında uygulanıyor; Python değerlendiricisine çoktan eklendiğini iddia etmiyorum.

Kapının kendisini test et

Karar kuralını metriklerden ayrı test ederdim. Yalnız ortalamayı kontrol eden bir test, kritik hatanın geçip geçemeyeceğini söylemez. Yararlı doğrulama, son yayın kararını açıkça belirtir.

Önce tam sınırı test ederdim: uydurma cevap 0.80'de kalmalı, mevcut ortalama kuralında 0.75'te geçmeli. İkinci doğrulama, tartışılan davranışı belgeliyor. Önerilen kuralda aynı cevap iki eşikte de kalmalı. Eşik sıfır olduğunda da kalmalı; zorunlu kural, sayısal alt sınır değişince ortadan kalkmamalı.

Sonra tersini test ederdim. Yanıt vermeme kontrolü geçiyorsa ve diğer kontroller uygulanamıyorsa boş kontroller yeni kapıyı başarısız yapmamalı. İlgili bir kontrol kendi alt sınırının altındaysa, daha güçlü üç puan onu kurtarmamalı. Eksik puanlar ve geçersiz sayılar da sessizce geçmek yerine reddedilmeli.

Bu testler incelemede politikayı okunabilir kılıyor. Gelecekteki eşik değişikliği için de somut bir karşılaştırma sunuyor. Her uygulamanın doğru iş politikasını seçmiyorlar. Hangi hataların kabul edilemez olduğuna ayrıca karar vermek gerekiyor.

Bu örnek neyi kanıtlamaz?

Tek bir sentetik vaka, sistemin production hata oranını ölçemez. Araç; kaynak kimliklerini, beklenen metni ve basit yanıt vermeme ifadelerini kullanıyor. Daha iyi kapılar da doğru etiketlere, temsil edici örneklere ve önemsediğiniz davranışı ölçen kontrollere ihtiyaç duyar.

İncelemede sormak istediğim soru daha dar: Hangi kontroller, hiçbir şey test edilmediği için geçiyor? Bu puanlar, bir kural ihlalini telafi edebiliyor mu? Biri geçme eşiğini değiştirmeden önce cevabın görünür olmasını istiyorum.