Bir LLM uygulamasını nasıl değerlendirirsiniz? Benchmark'lar ve LLM-as-judge yaklaşımının sınırlamaları nelerdir?
Cevap
LLM değerlendirmesi zordur: çoğu görevde tek bir doğru cevap yoktur, çıktılar stokastiktir ve küçük prompt değişiklikleri beklenmedik regresyonlar yaratır. Sağlam bir yaklaşım birden çok katmanı birleştirir.
1. Genel benchmark'lar (model seçimi için)
MMLU-Pro, GPQA (bilgi ve reasoning), HumanEval, SWE-bench (kod), IFEval (talimat takibi), Arena tarzı insan tercihi sıralamaları. Sınırlamaları: veri kontaminasyonu (test soruları eğitim verisine sızmış olabilir), doygunluk (en iyi modeller tavana yaklaştı) ve sizin göreviniz için temsili olmamaları. Sadece ilk eleme için kullanılmalıdır.
2. Uygulamaya özel eval seti (asıl önemli olan)
- Gerçek kullanım senaryolarından 100–1000 örneklik bir golden set: tipik vakalar, kenar durumlar, adversarial girdiler, geçmiş hatalar.
- Her prompt veya model değişikliğinde otomatik koşulur (CI'da regresyon testi).
3. Değerlendirme yöntemleri
| Yöntem | Ne zaman | Not |
|---|---|---|
| Kesin eşleşme / kural tabanlı | Sınıflandırma, JSON şeması, çıkarım | Ucuz, deterministik |
| Kod çalıştırma / unit test | Kod üretimi, SQL | En güvenilir otomatik sinyal |
| Referans tabanlı metrikler (BLEU, ROUGE) | Çeviri, özetleme | Anlamsal kaliteyle zayıf korelasyon |
| LLM-as-judge | Açık uçlu cevap, faithfulness, ton | Ölçeklenebilir, kalibrasyon gerekir |
| İnsan değerlendirmesi | Altın standart, judge kalibrasyonu | Pahalı, yavaş |
| Online metrikler | A/B testi, kullanıcı geri bildirimi | Gerçek etki |
LLM-as-judge sınırlamaları ve önlemleri
- Position bias: Karşılaştırmada ilk (veya ikinci) cevabı kayırma. Önlem: sırayı değiştirip iki kez sormak.
- Verbosity bias: Uzun cevapları kayırma.
- Self-preference: Kendi model ailesinin çıktılarını kayırma.
- Muğlak ölçekler (1–10) tutarsızdır. Net rubrik, ikili (geçti/kaldı) kriterler ve gerekçe istemek daha güvenilirdir.
- Judge'ı insan etiketleriyle karşılaştırıp uyumunu (agreement, Cohen's kappa) ölçmek gerekir.
RAG için ek metrikler
Retrieval tarafında recall@k ve MRR, generation tarafında faithfulness, answer relevance ve context precision ayrı ayrı ölçülmelidir. Böylece hatanın retrieval'da mı generation'da mı olduğu anlaşılır.
Stokastiklik nedeniyle her örneği birden çok kez koşup ortalama ve varyans raporlamak, küçük farkları anlamlı sanmamayı sağlar.
İlgili LLM & Üretken YZ soruları
- RAG'de chunking stratejisi, hybrid search ve reranker neden önemlidir? Retrieval kalitesi düşükse ne yaparsınız?
- Şirket içi dokümanlar (Confluence, PDF, wiki) üzerinde soru cevaplayan bir RAG sistemi tasarlayın.
- Hangi prompt engineering tekniklerini kullanırsınız? Few-shot ve chain-of-thought ne zaman işe yarar?
- LLM'lerde temperature, top-k ve top-p (nucleus) sampling parametreleri ne işe yarar?
- Production'daki bir LLM uygulamasında maliyeti ve gecikmeyi (latency) nasıl düşürürsünüz?
- Prompt injection nedir? LLM tabanlı bir uygulamayı ve agent'ı buna karşı nasıl korursunuz?
Bu konuda başka bir soru biliyor musun?
Mülakatta karşılaştığın soruları ekle, onaylandıktan sonra yayına alınsın.