LLM-as-a-judge nedir ve hakem modele ne zaman güvenilir?
LLM-as-a-judge, bir modelin cevabını başka bir modele puanlatma yöntemidir. Kendi hakem modelimizi nasıl denetlediğimizi anlatıyoruz.
Özet. LLM-as-a-judge (hakem model), bir modelin çıktısını başka bir dil modeline puanlatma yöntemidir. Biz diffox’u geliştirirken kod inceleme bulgularını, insanların önceden işaretlediği hatalarla eşleştirmek için kullanıyoruz. Bu yazı yöntemin bilinen yanlılıklarını ve kendi hakemimizi Ağustos 2026’da 891 çift üzerinde (her çift, bir inceleme bulgusu ile işaretli bir hatadır) nasıl denetlediğimizi anlatıyor.
- Hakeme “iyi mi?” değil, “aynı mı?” diye sorun. “Bu iki metin aynı hatayı mı anlatıyor” sorusuna tek kelimelik cevap denetlenebilir; “bu çıktı iyi mi” sorusuna verilen puan denetlenemez.
- Genel uyum yanıltır. İki hakemimiz 945 ortak çiftte %98,8 uyuştu; sonucu belirleyen olumlu çiftlerde uyum %93,5 idi.
- Ucuz hakem cömert çıktı, ama puanı az oynattı. Güçlü hakem, ucuz hakemin “eşleşiyor” dediği 400 çiftin 24’ünü reddetti (%6,0). Bir yapılandırmayı üç ayrı hakemle puanladığımızda en büyük fark 0,033 oldu; bu, ölçümün gürültü tabanının (0,09) altında.
- Asıl gürültü hakemde değil, çalıştırmada. Hakemi değiştirmek puanı en çok 0,033 oynattı; aynı sistemin çalıştırmadan çalıştırmaya standart sapması 0,094.
LLM-as-a-judge nedir?
Bir dil modelinin çıktısı çoğu zaman tek bir doğru cevapla karşılaştırılamaz: aynı hatayı anlatan iki yorum bambaşka kelimelerle yazılabilir. LLM-as-a-judge bu boşluğu doldurur: değerlendirmeyi, bir talimat (rubrik) verilmiş başka bir modele yaptırırsınız. Türkçede “hakem model” diyeceğiz.
Yöntemin adını yaygınlaştıran çalışma Zheng ve arkadaşlarının 2023 tarihli makalesidir: güçlü hakem modellerin insan tercihleriyle %80’in üzerinde uyuştuğunu, bunun insanların kendi aralarındaki uyumla aynı düzeyde olduğunu gösterdiler. Bugün kıyaslamaların çoğu bir hakem modele dayanıyor. GitHub’ın kod incelemesi için yayımladığı ReviewBench de öyle: bulguları tek bir rubrikle bir dil modeline puanlatıyor ve etiketlerini kıdemli mühendislere yeniden etiketleterek %96,6 uyum ölçtüğünü yazıyor.
Hakem model ilk seçenek değildir. Anthropic’in değerlendirme belgesi sırayı açıkça verir: önce kodla puanlama, çünkü en hızlı ve en güvenilir olan odur; sonra, kuralla ifade edilemeyen yargılar için hakem model; ve hakemi ölçeklemeden önce güvenilirliğini sınamak.
| Yöntem | Güçlü yanı | Zayıf yanı | Ne zaman |
|---|---|---|---|
| Kodla puanlama | En hızlı, en güvenilir, sınırsız ölçeklenir | Kuralla yazılamayan yargıyı veremez | Cevap tam eşleşme ya da bir metin aramasıyla denetlenebiliyorsa |
| İnsan puanlaması | En esnek, en nitelikli | Yavaş ve pahalı | Hakemi denetlemek için küçük bir örnekte |
| Hakem model | Hızlı, esnek, ölçeklenir | Yanlılıkları var; önce sınanmalı | Yargı gerekiyor ve cevap bir kuralla denetlenemiyorsa |
Kaynak: Anthropic’in değerlendirme belgesi, 18 Ekim 2026.
Hakem modellerin bilinen yanlılıkları var
Aynı makale hakem modellerin sınırlarını da sayar: konum yanlılığı, uzunluk yanlılığı, kendi çıktısına yanlılık ve sınırlı akıl yürütme. Hakemi kurarken her biri için bir önlem almalısınız.
Kendi çıktısına yanlılık en kolay önlenendir: değerlendiren model, çıktıyı üreten modelden farklı olsun. Anthropic’in örnek kodu bunu iyi uygulama olarak not eder. Konum yanlılığı, iki cevabı karşılaştıran sorularda ortaya çıkar; cevapların sırasını değiştirip iki kez sormak etkisini görünür kılar. Uzunluk yanlılığına karşı en etkili önlem, hakemden puan değil, tek bir olguya dayanan cevap istemektir.
Hakeme “iyi mi?” değil, “aynı mı?” diye sorun
Hakemin güvenilirliğini en çok soru belirler. “Bu inceleme yorumu iyi mi, 1 ile 10 arasında puanla” sorusunun doğru cevabı yoktur; iki hakem, hatta aynı hakemin iki çalıştırması farklı puan verir. Anthropic’in öğüdü de aynı yönde: hakem yalnızca “doğru” ya da “yanlış” desin ya da 1–5 arasında bir düzey seçsin; salt nitel değerlendirmeyi hızlı ve ölçekli biçimde denetlemek zordur.
Bizim hakemimizin sorusu bir karşılaştırmadır: bir inceleme yorumu ile aynı pull request’te önceden işaretlenmiş bir hata verilir ve tek şey sorulur. Rubriğin çekirdeği şuna benzer:
You are given a review comment and a known bug in the same pull request.
Do they describe the SAME defect: the same code, failing for the same reason?
- A comment about the same file but a different problem is NOT a match.
- A comment that names the symptom while the known bug names its cause IS a match.
- If the comment is too vague to tell, answer no.
Answer with one word: yes or no.Rubrikteki üç satır, hakemin en sık kararsız kaldığı durumları önceden cevaplar: aynı dosya ama başka sorun, belirti ile neden, belirsiz yorum. Bu satırlar yazılmadığında iki hakem tam bu durumlarda ayrışır.
İki hakemin genel uyumu yanıltır; olumlu çiftlere bakın
Hakemi sınamanın ilk adımı, aynı çiftleri ikinci bir hakeme de sormaktır. Biz iki ayrı modeli aynı rubrikle hakem yaptık: 945 ortak çiftte %98,8 uyuştular. Bu sayı tek başına rahatlatıcıdır ve yanıltıcıdır.
Çiftlerin büyük çoğunluğu apaçık “hayır”dır: yorum bir dosyadan, işaretli hata bambaşka bir dosyadan söz eder. İki hakem bunlarda zaten uyuşur. Sonucu belirleyen, en az bir hakemin “evet” dediği çiftlerdir ve orada uyum %93,5 idi. Bir hakemin güvenilirliğini bildirirken paydayı söyleyin: bütün çiftler mi, olumlu çiftler mi.
Ucuz hakemi güçlü bir hakemle, çiftleri gruplara ayırarak denetledik
Günlük ölçümlerimizi ucuz bir hakemle yapıyoruz. “Ya bu hakem yanlış yorumluyorsa” sorusunu cevaplamak için hakemi tümden değiştirmek gerekmiyordu: tam matris 4.185 çift istiyordu. Onun yerine daha güçlü bir modeli yüksek çaba ayarında yalnızca 891 çifte sorduk ve çiftleri rastgele değil, sorunun cevabını verecek gruplardan seçtik.
- İki hakemin de “evet” dediği 91 çift: güçlü hakem hiçbirini çevirmedi. Uzlaşılmış bir eşleşme, daha pahalı bir hakemle de eşleşme kaldı.
- İki hakemin de “hayır” dediği 400 çift: yalnızca 1 tanesi çevrildi (üst sınır %1,4). Hakem eşleşme kaçırmıyor.
- Puana sayılan “evet”lerden 400 çift: 24 tanesi reddedildi, yani %6,0. Ucuz hakem, eşleşme saymakta cömert.
Sonuç iki ayrı cümledir ve ikisini karıştırmamak gerekir. Mutlak puanlar yaklaşık 0,02–0,03 iyimserdir. Hakemi değiştirmek bir yapılandırmanın puanını 0,033’ten fazla oynatmadı; bu, ölçümün gürültü tabanının (0,09) altında. Ama bunu tek bir yapılandırmada ölçtük, bu yüzden iki yapılandırmanın sıralamasının her durumda korunacağını söylemiyoruz. Hakemin kusuru, onunla ne yaptığınıza göre önemlidir ya da değildir.
Hakemi değiştirmek puanı az, yeniden çalıştırmak çok oynatır
Aynı yapılandırmayı üç ayrı hakemle yeniden puanladığımızda F1’deki en büyük kayma 0,033 oldu. Aynı yapılandırmayı, aynı pull request’lerde ve aynı hakemle yeniden çalıştırdığımızda ise çalıştırmadan çalıştırmaya standart sapma 0,094 çıktı; bir kez, hiçbir şeyi değiştirmeden iki çalıştırma arasında 0,058 fark gördük.
Yani ölçümdeki asıl belirsizlik hakemden değil, sistemin kendi rastgeleliğinden geliyor. Bundan çıkan kural basit: iki yapılandırma arasındaki fark yaklaşık 0,09’dan küçükse, tek çalıştırmayla o fark görülemez; daha iyi bir hakem satın almak da bunu değiştirmez.
Hakemin eşleştiremediği her bulgu yanlış değildir
Bir hakem modeli çoğu kıyaslamada bulguyu bir referansla, yani önceden işaretlenmiş hatalarla karşılaştırır. Referansta olmayan bir bulgu “yanlış alarm” sayılır. Oysa bu yalnızca şunu söyler: referansı hazırlayan kişi o noktayı yazmamış. Bulgu doğru da olabilir.
ReviewBench bu yüzden iki metrik ailesi yayımlıyor: biri yalnızca mevcut etiketleri kullanır, öteki altın kümede karşılığı olmayan bulguları da ayrıca değerlendirir. Kendi ölçümünüzde de aynı ayrımı yapın: “referansla uyuşmuyor” ile “yanlış” iki ayrı etikettir ve ikincisini söylemek için bulgunun kendisine bakmak gerekir.
Hakemin kararını saklayın, kural değişikliklerini hakemsiz ölçün
Hakem çağrısı ücretlidir ve aynı çift için aynı soruyu iki kez sormanın anlamı yoktur. Her kararı çiftin ve hakemin kimliğiyle birlikte saklayın: model, çaba ayarı, rubriğin sürümü. Bunlardan biri değiştiğinde eski kararlarla yenilerini aynı tabloda göstermeyin; iki ayrı hakemle ölçülmüş iki sayı karşılaştırılamaz.
Her değişiklik hakem de gerektirmez. Bir eşiği ya da bir süzgeci değiştirdiğinizde, eski ve yeni kuralı daha önce saklanmış sonuçlar üzerinde yeniden oynatıp yalnızca ayrıştıkları yerlere bakabilirsiniz. Biz bir kapı değişikliğini böyle ölçtük: 1.405 kayıtlı bulguda eski ve yeni kural yalnızca 6 yerde ayrışıyordu ve altısını gözle okumak yetti. Yeni bir çalıştırma ne ücretsiz olurdu ne de bu kadar kesin.
Bu dersler diffox’un kendi ölçümlerinden çıktı: bir değişikliğin işe yarayıp yaramadığına tek çalıştırmayla ve denetlenmemiş bir hakemle karar vermiyoruz. Ürünün kendisinde ise bir bulgunun dayandığı alıntıyı hakem model değil, kod kontrol eder (mimari yazısı).
Sıkça sorulan sorular
LLM-as-a-judge nedir?
Bir yapay zekâ çıktısını, bir talimat (rubrik) verilmiş başka bir dil modeline puanlatma yöntemidir. Cevabın tek bir doğru metinle karşılaştırılamadığı işlerde, örneğin iki yorumun aynı hatayı anlatıp anlatmadığına karar verirken kullanılır.
LLM-as-a-judge güvenilir mi?
Soruya bağlı. 2023 tarihli bir çalışma, güçlü hakem modellerin insan tercihleriyle %80’in üzerinde uyuştuğunu gösterdi. Karşılaştırma sorularında (“bu ikisi aynı mı”) hakemler tutarlıdır; puan verdirilen açık uçlu sorularda değildir. Güvenmeden önce hakemi ikinci bir hakemle ya da insan etiketleriyle küçük bir örnekte sınayın.
LLM-as-a-judge için rubrik nasıl yazılır?
Tek bir soruya indirin ve cevabı sınırlayın: “evet/hayır” ya da 1–5 arası bir düzey. Hakemin kararsız kalacağı sınır durumları rubriğe yazın: hangi durum eşleşme sayılır, hangisi sayılmaz, belirsizse ne denir. Anthropic’in belgesi ayrıca hakemin cevaptan önce akıl yürütmesini önerir.
LLM-as-a-judge metrikleri nelerdir, hangisine bakmalı?
Hakemin kendisi için: insan etiketleriyle ya da ikinci bir hakemle uyum oranı, özellikle olumlu örneklerdeki uyum; ve güçlü bir hakemin kararı çevirme oranı, güven aralığıyla. Genel uyum, kolay olumsuz örnekler yüzünden olduğundan yüksek görünür.
Hakem model, değerlendirilen modelle aynı olabilir mi?
Olmaması daha iyi. Hakem modellerin kendi çıktısına daha yüksek puan verdiği bilinen bir yanlılıktır. Anthropic’in örnek kodu, değerlendiren modelin çıktıyı üreten modelden farklı olmasını iyi uygulama olarak not eder.
LLM-as-a-judge ile agent-as-a-judge arasındaki fark ne?
LLM-as-a-judge yalnızca son çıktıyı değerlendirir. Agent-as-a-judge, 2024 tarihli bir makalenin önerdiği uzantıdır: değerlendirmeyi araç kullanabilen bir ajan yapar ve işin ara adımlarına da geri bildirim verir. Çok adımlı ajan sistemlerini değerlendirmek için tasarlanmıştır.
diffox incelemelerinde hakem model kullanıyor mu?
Geliştirme sırasında evet: bulguları önceden işaretlenmiş hatalarla eşleştirip bir değişikliğin işe yarayıp yaramadığını ölçmek için. Bir pull request incelenirken ise bulgunun dayandığı alıntıyı hakem model değil, kod kontrol eder: alıntı dosyada gerçekten var mı, değişen satırlara mı ait.