⚖️ Yargıç Olarak Claude

Yargıç Olarak Claude: LLM-as-a-Judge, serbest yazılmış bir kompozisyonu ezberlenmiş bir model cevaba karşı değil, bir rubriğe göre notlamaktır — ve mekanizma gevşek değil, birebi

LLM-as-a-Judge, serbest yazılmış bir kompozisyonu ezberlenmiş bir model cevaba karşı değil, bir rubriğe göre notlamaktır — ve mekanizma gevşek değil, birebir örtüşür: konuyu zaten bilen bir öğretmen, bin farklı şekilde ifade edilebilecek bir kompozisyonu okur ve belirli maddeleri kontrol eder ("tez açıkça belirtilmiş mi? kanıt gösterilmiş mi? sonuç öncülden çıkıyor mu?") — asla tek bir "doğru" kompozisyonla kelime kelime karşılaştırmaz. Bir yargıç model, bir AI çıktısına tam olarak bunu yapar — karakterleri diff'lemez, her rubrik maddesinin karşılanıp karşılanmadığını kontrol eder. Üzerinde durmaya değer soru şu: bir insan test uzmanı zaten chatbot'un yanıtlarını okuyup puanlayabiliyorsa, tahmin edilemez bir AI modelini notlamak için ikinci, tahmin edilemez bir AI modeli devreye sokmak, belirsizliği belirsizliğin üstüne yığmak değil mi? Çünkü insan ölçeklenmez: her deploy sonrası 50 serbest metin yanıtı okumak gerçek bir darboğazdır; oysa bir insanın BİR KEZ yazdığı ve küçük bir elle-puanlanmış örnekle kalibre ettiği (yargıcın puanlarının bir insanınkiyle ne kadar örtüştüğünü kontrol etmek — buna "inter-rater reliability" denir, körü körüne güven değil) bir rubrik, ucuz bir model tarafından her sürümde tutarlı biçimde uygulanabilir. Java karşılaştırması: bu assertEquals(expected, actual) değildir — daha çok, hasSeverityJustification() gibi özel bir Hamcrest matcher'ı BİR KEZ yazıp, her vaka için tek bir beklenen string hardcode etmek yerine binlerce farklı ifade edilmiş girdide yeniden kullanmaya benzer. QA açısından önemi: "Bug Analizi & Rapor" sekmesinde bir ham log'u elle bir rapora dönüştürmüştün; günde 50 AI-üretimi rapor olduğunda, rubrikle puanlanan bir yargıç, bir kalite regresyonunu (belirsiz repro adımları, gerekçesiz önem derecesi) bir geliştirici kullanılamaz bir tikete bir saat harcamadan ÖNCE yakalamanın tek yoludur — tabii önce kalibre ettiysen, ilk çıktısına körü körüne güvenmek yerine.

Assertion'dan Rubriğe

Geleneksel bir QA assertion'ı ikilidir ve tek doğru değeri vardır: assertEquals("200", actual). Bir AI çıktısının ise kabul edilebilir birçok ifade biçimi vardır, o yüzden "doğru" tek bir string olmaktan çıkıp "şu N bağımsız, kontrol edilebilir özelliği karşılıyor mu?" haline gelir — bir rubrik. Her özellik yargıç modelden kendi 1-5 puanını alır (pass/fail değil), bu da SADECE "kötü" demek yerine HANGİ boyutun başarısız olduğunu görmeni sağlar: bir rapor tamamen anlaşılır olabilir (5/5) ama tamamen tekrar üretilemez olabilir (1/5) — bu ayrımı sadece bir rubrik gösterir. Bu ayrıştırma tam olarak RAGAS gibi araçların RAG pipeline'ları için yaptığı şeydir — bulanık tek bir "kalite" puanı yerine grounding, relevance ve faithfulness'ı ayrı ayrı puanlamak.

Aşağıda, aynı bug raporunun üç farklı taslağı 4 kriterlik bir rubriğe göre puanlanır: tekrar üretilebilirlik, önem derecesi gerekçesi, anlaşılırlık ve aksiyon alınabilirlik. Kriterleri aç/kapat ya da kendi taslağını yaz, sonra Değerlendir'e bas. "Belirsiz" taslağın tam ve gramatik bir cümle olduğuna dikkat et — basit bir "açıklama alanı boş değil mi?" kontrolü onu anında geçirirdi. Rubrik, o kontrolün yakalayamadığını yakalar: ADIMLARIN numaralı ve spesifik olup olmadığını, ÖNEM DERECESİNİN somut bir etkiyle desteklenip desteklenmediğini ve bir geliştiricinin ek soru sormadan aksiyon alıp alamayacağını sorar.

🎬 LLM-as-Judge Döngüsü

AI Çıktısı (Bug Raporu)

Kriter Bazlı Puanlar

Bir judge model çağrısının GERÇEKTE ne yaptığını izleyeceksin — "belirsiz rapor" örneğini (Judge Playground'daki aynı taslak) rubrikten geçirip neden düşük puan aldığını adım adım göreceksin.

Adım 1 — Çıktı: Claude bir hata log'undan bu bug raporunu üretti. Henüz hiçbir değerlendirme yapılmadı — elimizde sadece serbest metin var.

Adım 2 — Rubrik: değerlendirmeden ÖNCE, 4 bağımsız kriter tanımlanır (reproducibility, severity, clarity, actionability). Rubrik tek doğru cevap değil, kontrol edilebilir özelliklerin listesidir.

Adım 3 — Judge çağrısı: çıktı + rubrik birlikte judge modele gönderilir. Judge karakter karakter diff yapmaz — her rubrik maddesinin karşılanıp karşılanmadığını okur.

Adım 4 — Skorlar: judge TEK bir "iyi/kötü" cevabı DEĞİL, her kriter için ayrı 1-5 puan döndürür. Bu örnekte: reproducibility 1, severity 2, clarity 3, actionability 1 — HANGİ boyutun battığı burada görünür.

Adım 5 — Eşik: her kriter, "geçer" sayılmak için gereken bir eşikle (örn. ≥4/5) karşılaştırılır. Burada 4 kriterin 3'ü eşiğin ALTINDA kalıyor.

Adım 6 — Karar: eşiği geçemeyen kriter sayısı yeterince fazla olduğu için nihai karar FAIL olur — rapor bir geliştiriciye gitmeden ÖNCE reddedilir, tıpkı bir CI gate'i gibi.