LLM as a Judge Nedir? Yapay Zeka ile Model Değerlendirme

Yeni bir modeli test ettiğinizi düşünün. Yanıt kalitesini ölçmek için 5.000 adet soru-cevap çiftini insan uzmanlarına göndermek zorundasınız. Her annotator saat başı ücret alıyor, her değerlendirme biraz farklı çıkıyor. Altı hafta ve on iki bin dolar sonra elinizde hâlâ gürültülü sinyaller var. Bu tablo, büyük dil modeli geliştirmenin en sıkıcı darboğazıydı. 2023’te bir fikir bu döngüyü kırdı: modeli değerlendirmek için başka bir model kullanmak.

LLM as a Judge tam da bu fikrin sistematik hale getirilmiş biçimi. GPT-4 veya Claude gibi güçlü bir frontier model, başka bir sistemin çıktısını puanlıyor ya da karşılaştırıyor. İnsan annotator’ın yerini tam anlamıyla almıyor; ama insan değerlendirmesinin ölçeklenemediği, yetişemediği yerlerde devreye giriyor.

LLM as a Judge Nedir?

LLM as a Judge, bir dil modelini başka bir modelin çıktısını değerlendirmek amacıyla “hakem” olarak kullanma pratiği. GPT-4, Claude veya Gemini gibi yetenekli bir model, bir yanıtın doğruluğunu ya da belirli bir kritere uygunluğunu değerlendirmek üzere çağrılıyor.

Bu fikri ölçeğe taşıyan ilk büyük çalışma Zheng ve diğerlerinin 2023 tarihli MT-Bench makalesi (arXiv:2306.05685). Araştırmacılar çok turlu sohbet görevlerini değerlendirmek için GPT-4’ü hakem olarak kullandı ve GPT-4’ün insan uzman değerlendirmeleriyle yüksek korelasyon gösterdiğini buldu. Bu, LLM hakem ile insan tercih verisiyle karşılaştırılabilir sinyal üretilebileceğinin ilk sistematik kanıtıydı.

Pratik sonucu basit: bir RLHF döngüsünde ya da süregelen A/B testinde, her model çıktısı için insan değerlendirmesi beklemek mümkün değil. LLM-as-a-Judge bu boşluğu dolduruyor.

Neden LLM as a Judge? İnsan Değerlendirmesinin Kısıtları

İnsan değerlendirmesi uzun süre altın standart kabul edildi. Ama pratikte dört ciddi sorunu var.

Maliyet açısından bakıldığında, bin adet istem için üç farklı annotator tutmak bütçeye ciddi yük bindiriyor. Büyük ölçekli benchmark çalışmaları onlarca bin dolar harcıyor. Hız da bir sorun: model iterasyonları arasında insan değerlendirme sonuçlarını beklemek geliştirme döngüsünü haftalarca uzatabiliyor, CI/CD pipeline’larında bu kabul edilemez.

Tutarlılık daha ince bir sorun. Annotator’lar arasındaki uyum (inter-annotator agreement) beklenenden düşük çıkıyor; aynı çıktıyı iki uzman farklı puanlıyor. Bu gürültü modelin gerçek gelişimini maskeliyor. Ölçek ise doğrudan duvarla çarpmak demek: MMLU’nun 14.000 sorusu veya HumanEval’ın programlama görevlerini insan annotation ile geçmek pratikte mümkün değil.

LLM-as-a-Judge bu dört sorunu aynı anda çözüyor. Bir API çağrısı saniyeler içinde sonuçlanıyor; paralel değerlendirme mümkün; aynı prompt tutarlı biçimde çalışıyor.

Değerlendirme Modelleri (Judgment Paradigms)

LLM-as-a-Judge monolitik bir yöntem değil. Farklı kullanım durumlarına göre dört ana paradigma belirginleşmiş durumda.

Tek Hakem (Single-Judge / Pointwise)

En yalın yaklaşım: bir model çıktısına 1-10 (ya da 1-5) arası puan verilmesi. Hakem modele değerlendirilecek yanıt verilir, kriterleri tarif eden bir rubric eklenir, ve numerik bir skor istenir.

Avantajı hız ve basitlik. Dezavantajı kalibrasyon: farklı hakem modeller aynı yanıta farklı puan veriyor, ve “8/10 ne anlama geliyor?” sorusu yanıtsız kalabiliyor. Karşılaştırmalı değerlendirme yapılmayacaksa ve mutlak kalite ölçümü yeterliyse tercih edilen yöntem bu.

İkili Karşılaştırma (Pairwise)

İki farklı modelin aynı soruya verdiği yanıt yan yana sunuluyor, hakem hangisinin daha iyi olduğuna karar veriyor. Çıktı bir kazananın adı ya da “tie” işareti.

Chatbot Arena’nın temelinde bu yöntem yatıyor. LMSYS organizasyonunun platformunda gerçek kullanıcılar iki modelle sohbet ediyor ve hangisinin daha iyi yanıt verdiğini seçiyor. Bu tercihlerden ELO puanı hesaplanıyor. LLM hakem de aynı prensibi otomatize ediyor.

Pairwise’ın avantajı, modelin neyi iyi bulduğunu mutlak terimlerle tanımlamaya gerek bırakmaması. Karşılaştırma yeterli; kalibrasyon problemi büyük ölçüde ortadan kalkıyor.

Referansa Dayalı (Reference-Based)

Doğru cevap (altın standart) belli olduğunda devreye giriyor. Model çıktısı referans yanıtla karşılaştırılıyor, hakem sapmaları, eksiklikleri ve hataları işaret ediyor.

Soru-cevap görevlerinde, özetlemede ve belirli gerçekleri doğrulamayı gerektiren görevlerde kullanılıyor. Açık uçlu yaratıcı yazarlık ya da görüş tabanlı sohbetlerde ise referans çoğu zaman tanımlanabilir olmadığından sınırları var.

Çoklu Hakem (Multi-Judge / Panel)

Birden fazla model jüri olarak kullanılıyor: GPT-4, Claude, Gemini gibi modeller aynı çıktıyı değerlendiriyor, oylamaya gidiliyor ya da puanlar ortalaması alınıyor.

Bir hakem modelin taşıdığı sistematik önyargıyı dengeleme açısından etkili. Bir modelin kaçırdığını diğeri yakalıyor; yüksek uyuşmazlık, değerlendirilmekte olan örneğin gerçekten zor ya da muğlak olduğuna işaret ediyor. Maliyet daha yüksek, ama kritik karar noktalarında bu yatırım karşılığını veriyor.

Bias ve Sınırlılıklar

LLM-as-a-Judge’ün en ciddi eleştirileri güvenilirlik sorunlarından geliyor. Dört ana bias kategorisi var.

Pozisyon Biası (Position Bias)

Pairwise değerlendirmede hakem model, sıralamaya göre sistematik tercih gösterebiliyor: birinci sunulan yanıtı ya da ikinci sunulan yanıtı tutarlı biçimde seçme eğilimi. MT-Bench araştırması bu etkiyi ölçtü ve standart bir önlem önerdi: swap augmentation.

Swap augmentation şöyle işliyor: aynı iki yanıt ikinci kez değerlendiriliyor, ama sıraları ters çevrilmiş biçimde. Hakem her iki sırada da A’yı seçiyorsa sonuç güvenilir; sıra değiştiğinde karar da değişiyorsa bu bir pozisyon biası sinyali. Nihai karar tutarlı çiftlerden alınıyor.

Uzunluk Biası (Verbosity Bias)

Uzun yanıtlar çoğu hakem modelde daha yüksek puan alıyor. Yanıtın içerik yoğunluğundan bağımsız olarak, daha fazla kelimeden oluşan bir çıktı “daha kapsamlı” ya da “daha yardımsever” görünüyor.

AlpacaEval 2.0 bu sorunu doğrudan ele almak için LC (Length-Controlled) Win Rate metriğini geliştirdi. Uzunluk kontrolü yapılmadan hesaplanan win rate ile kontrol edilen arasındaki fark, modelin gerçek kalitesini mu yoksa yalnızca uzun yanıt üretme eğilimini mi ölçtüğünü ortaya koyuyor.

Öz-tercih Biası (Self-Enhancement Bias)

Bir model kendi ürettiği metinlere ya da kendi stiline yakın çıktılara yüksek puan verme eğiliminde. GPT-4’ü hakem olarak kullandığınızda, GPT-4’ün tarzını taklit eden yanıtlar avantajlı konuma geçebiliyor.

Bu bias hem hakem seçimi hem de değerlendirme yorumlama aşamasında göz önünde bulundurulmalı. Çoklu hakem yaklaşımı bu etkiyi kısmen yumuşatıyor.

Format Biası

JSON formatında, madde işaretleriyle ya da kalın başlıklarla yapılandırılmış yanıtlar, aynı içeriği düz metin olarak sunan yanıtlara göre yüksek puan alabiliyor. Hakem model içeriği değil, görsel düzeni değerlendiriyor olabiliyor.

Rubric’e açıkça “format’ı değil, içerik doğruluğunu puanla” gibi bir yönerge eklemek bu etkiyi azaltıyor, ama tamamen ortadan kaldırmıyor.

Popüler Çerçeveler ve Benchmark’lar

LLM-as-a-Judge etrafında birkaç yıl içinde güçlü bir ekosistem oluştu.

MT-Bench: 80 soruluk çok turlu sohbet testi. Her soru için GPT-4 hakem olarak iki yanıtı karşılaştırıyor. Kategoriler matematik, akıl yürütme, yazma, kod gibi alanlara yayılıyor. Sonuçlar 1-10 skala üzerinden bildiriliyor.

Chatbot Arena: Canlı ortamda gerçek kullanıcılar iki modelle konuşuyor ve hangisinin daha iyi olduğunu seçiyor. Tercihlerden Elo puanları hesaplanıyor. Hem insan hem de LLM değerlendirmelerini bir arada kullanıyor.

AlpacaEval 2.0: GPT-4 Turbo’yu hakem olarak kullanarak modelin GPT-4’e karşı win rate’ini ölçüyor. Uzunluk kontrolü (LC Win Rate) ile verbosity bias azaltılıyor.

Prometheus 2: Ücretsiz, açık kaynak bir judge modeli. Llama tabanlı, sıfırdan judge olmak üzere fine-tune edilmiş. Ticari API kullanmak istemeyenler için güçlü bir alternatif.

RLHF ve Üretim Pipeline’larında Kullanım

LLM-as-a-Judge’ün pratik değeri en çok RLHF ve model geliştirme döngülerinde ortaya çıkıyor.

Preference dataset oluşturmada kullanım özellikle yaygın. DPO veya PPO eğitimi için “hangi yanıt daha iyi?” sorusunu yanıtlayan tercih verisi gerekiyor. Tüm çiftleri insanlarla etiketlemek yerine, bir hakem model hızlı filtreleme yapıyor; insanlar yalnızca hakemin kararsız kaldığı örneklere odaklanıyor.

Otomatik kırmızı ekip değerlendirmesinde de kullanılıyor. Modele zararlı ya da yanıltıcı girdiler gönderiliyor, yanıtlar güvenlik odaklı bir judge tarafından değerlendiriliyor. Bu insan güvenlik ekibinin yükünü ciddi ölçüde azaltıyor.

A/B testlerinde insan annotation yerine LLM judge ön filtreleme yapıyor: hakem belirsiz bulduğu örnekleri işaretliyor, bunlar insana sevk ediliyor. Her model güncellemesi sonrasında belirlenmiş bir test seti üzerinde judge değerlendirmesi çalıştırmak, regresyonları otomatik tespit etmenin en pratik yolu.

Constitutional AI ve RLAIF çerçevesinde ise bir modelin kendi çıktısını değerlendirip revize etmesi için LLM-as-a-Judge benzeri bir mekanizma kullanılıyor. RLAIF döngüsünde preference modeli eğitmek amacıyla tercih sinyalleri üretiyor.

İyi Bir Judge Prompt Nasıl Yazılır?

Hakem modele verilen prompt, değerlendirme kalitesini doğrudan belirliyor. Prompt engineering açısından birkaç pratik kural var.

Önce açık bir rubric yaz. “Bu yanıt kaliteli mi?” gibi muğlak bir soru işe yaramıyor; “doğruluk, netlik ve soruya uygunluk açısından 1-5 arası puanla” gibi ölçütler ve her puan seviyesinin ne anlama geldiğine dair örnekler gerekiyor.

Sayısal skalayı açıkla. Sadece “1-10 arası puan ver” yetmiyor. “1: tamamen yanlış ya da ilgisiz; 5: kısmen doğru ama eksik; 10: eksiksiz, doğru ve iyi organize edilmiş” gibi tanımlamalar modelin kalibrasyona oturmasını sağlıyor.

Chain-of-thought zorla. “Önce gerekçeni yaz, ardından puanı ver” yapısı puanın kalitesini artırıyor; CoT olmadan model bir sayı üretiyor ama neden o sayıyı seçtiği belirsiz kalıyor. Pairwise değerlendirmelerde swap augmentation da zorunlu: sırayı ters çevirip ikinci kez değerlendir, tutarsız sonuçlar pozisyon biasına işaret ediyor.

İki ya da üç few-shot örnek eklemek hakem modelin beklenen çıktı formatına oturmasını hızlandırıyor. Çıktıyı JSON formatında almak da değerlendirmeleri downstream pipeline’a entegre etmeyi kolaylaştırıyor; structured outputs kullanarak hakem yanıtını {"score": 7, "reasoning": "..."} gibi makine okunabilir hale getirmek mümkün.

Sınırlılıklar: Ne Zaman İnsan Gerekir?

LLM-as-a-Judge her kullanım durumuna uygun değil. Bazı senaryolarda insan değerlendirmesi zorunlu.

Güvenlik kararları bunların başında geliyor. Bir modelin tehlikeli içerik üretip üretmediğini değerlendirmek, hakem modelin kendi güvenlik kısıtlarıyla çelişiyor olabilir. Kırmızı ekip bulgularının son onayı insan güvenlik uzmanına kalmalı.

Kültürel nüans da sorunlu. Dil, mizah, argo ya da belirli topluluklara özgü referanslar LLM hakemler tarafından sıklıkla kaçırılıyor ya da yanlış yorumlanıyor.

Öznel yaratıcı değerlendirme de LLM’lerin zayıf noktası. Bir şiirin estetik kalitesi ya da bir metaforun özgünlüğü üzerinde anlamlı bir rubric yazmak güç; insan yargısı bu tür görevlerde daha güvenilir.

Yüksek riskli tıp ve hukuk içeriği ayrı bir kategori. Tanı önerileri, ilaç dozajları ya da hukuki yorumlar yanlış değerlendirildiğinde gerçek zarar doğurabiliyor. LLM hakem bu alanlarda ek doğrulama mekanizmasının yanında çalışabilir, onun yerine geçemez.

LLM-as-a-Judge Nerede Duruyor?

LLM-as-a-Judge iki yıl içinde deneysel bir fikir olmaktan çıkıp üretim pipeline’larının standart bileşenine dönüştü. MT-Bench ve AlpacaEval gibi akademik benchmark’lar, Chatbot Arena gibi canlı platformlar, RLHF tercih verisi üretimi ve sürekli regresyon testi bu dönüşümün somut örnekleri.

Yöntemin temel iddiası şu: yetenekli bir dil modeli, daha zayıf modellerin çıktılarını değerlendirmede insan uzmanlarla karşılaştırılabilir sinyal üretiyor. Bu iddia test edildi ve büyük ölçüde doğrulandı. Ama kapsamı da netleşti; bias’lar gerçek, sınırlılıklar somut.

Bunları bilerek kullanırsanız değerlendirme verimliliği ciddi ölçüde artıyor. Bilmeden kullanırsanız, gürültülü bir insan sürecini gürültülü bir otomasyonla değiştirmiş oluyorsunuz.

Başlangıç için pratik bir öneri: önce swap augmentation uygula, ardından rubric yaz ve CoT’u zorla. Sonuçlar tutarlıysa ölçekle.