LLM Eval Nedir? Yapay Zeka Modellerini Doğru Değerlendirme Kılavuzu

Soldaki model, sağdaki ölçüm kartı: eval bu ikisini birbirine bağlayan köprü.

İki farklı modeli aynı prompt’a soktunuz. Birinin yanıtı daha akıcı göründü, öbürü kısaydı ama doğrudandı. Hangisi gerçekten daha iyi?

Bu soruyu “hissettim” diye yanıtlayanlar, aslında kararlarını n=1 bir test üzerine kuruyor. Aynı prompt, farklı bir saatte farklı bir çıktı üretebilir. Model dün güncellenmiş olabilir. Ya da beklentilerinizle örtüşen yanıtı tercih etmiş olabilirsiniz, farkında olmadan. Evallar olmadan “daha iyi” bir sezgidir; ölçüm değil.

LLM eval, bir modelin veya pipeline’ın belirli görevlerdeki performansını sistematik ve tekrarlanabilir biçimde puanlayan süreçtir.

Gut feeling sol kefede kalıyor, eval sağa ağır basıyor.

LLM Eval Nedir?

LLM eval tek bir soruyu yanıtlar: “Bu model, bu görevde ne kadar iyi?”

Ölçüm için üç koşul gerekir: bir test seti (girdi-çıktı çiftleri veya gerçek senaryolar), bir skorlama fonksiyonu (beklenen çıktıyla ne kadar örtüşüyor?) ve tekrarlanabilirlik (aynı testi yarın da çalıştırabilmeli, sonuçları karşılaştırabilmeliyim).

Sezgisel değerlendirmenin yetmediği birkaç somut neden var. Birincisi, dil modelleri stokastiktir: aynı giriş, sıcaklık (temperature) parametresi sıfır olmadığında farklı çıktılar üretir. İkincisi, insan gözü örnekleme yanlılığına açıktır; birkaç etkileyici yanıt gördüğünüzde modelin genel kalitesini abartma eğilimi taşırsınız. Bir de modeller güncellenir; dün doğru çalışan bir davranışın bugün de geçerliliğini koruyup korumadığını yalnızca eval koşarak anlayabilirsiniz.

Eval sadece model seçimi için değil, regresyon tespiti için de kritik bir araçtır. Bir sistem prompt değişikliği veya LoRA ile fine-tuning adımı sonrasında önceki davranışın bozulmadığını kontrol etmek, üretimde sürprizleri önler. “Düzelttim” yerine “koşturup gördüm” diyebilmek, takımlar arası güven kurar.

Eval Türleri: Offline mi, Online mi?

Eval’ın iki ana ekseni var: nerede ve ne zaman yapıldığı.

Offline eval, geliştirme aşamasında sabit bir test setiyle yürütülür. Model henüz canlıya alınmamıştır; değişkenleri kontrol altında tutarsınız. Skorlama otomatikleştirilebilir: exact match (beklenen çıktı aynen eşleşiyor mu?), F1 skoru (token örtüşmesi), BLEU (çeviri kalitesi için) veya LLM-as-judge (başka bir modeli hakem olarak kullanmak). Hızlı, ucuz ve tekrarlanabilir.

Online eval, model canlı trafikle karşılaştığında yapılır. A/B testi (iki model sürümünü gerçek kullanıcılara gösterip hangisinin daha iyi geri bildirim aldığını ölçmek), thumbs up/down gibi kullanıcı sinyalleri veya shadow mode (yeni modeli sessizce çalıştırarak eski modelle paralel karşılaştırmak) bu kategoriye girer. Gerçek kullanıcı davranışını yansıtır; ancak gürültülüdür ve sonuç almak daha uzun sürer.

Sağlıklı bir akış şöyle işler: offline eval geliştirme döngüsünde sık koşulur, online eval ise canlıya almadan önce veya kritik karar noktalarında devreye girer.

Popüler Benchmark’lar ve Ne Ölçtükleri

Akademik ve endüstriyel alanda yerleşmiş benchmark’lar, modellerin farklı yetenek katmanlarını ayrı ayrı test eder. Bu benchmark’ları tek tek tanımak, hangi sorular için hangi ölçütü kullanacağınız konusunda net bir tablo sunar.

MMLU — Genel Bilgi ve Akıl Yürütme

Massive Multitask Language Understanding, 57 konuyu kapsayan çoktan seçmeli sorulardan oluşur: tıp, hukuk, tarih, fizik, etik ve daha fazlası. Modelin formal eğitim gerektiren bilgi alanlarındaki performansını, başka bir deyişle skolastik zekanın proxy’sini ölçer.

GPT-4, Claude ve Gemini gibi modeller MMLU’da %80 üzeri skorlar alıyor. Bu sayıyı tek başına yorumlamak yanıltıcı olabilir; alt kategorilerdeki dağılıma bakmak, modelin gerçekte nerede güçlü, nerede zayıf olduğunu ortaya koyar.

HumanEval ve LiveCodeBench — Kod Üretimi

HumanEval, OpenAI’nin 2021’de yayımladığı 164 Python probleminden oluşur. Her problem için model bir fonksiyon yazar; fonksiyon, gizli birim testlerini geçerse başarılı sayılır. pass@1 en yaygın kullanılan ölçüt: tek denemede doğru çözüm üretme oranı.

HumanEval’ın temel dezavantajı eskimesidir. Sorular artık kamuya açık ve eğitim verilerine sızmış olabilir. LiveCodeBench bu açığı kapatmak için aktif programlama yarışmalarından derlenen, gerçek zamanlı güncellenen problemler kullanır. Model, daha önce görmediği sorularla sınanır.

GPQA — Uzmanlık Gerektiren Sorular

Graduate-Level Google-Proof Q&A, adından da anlaşıldığı gibi arama motorlarıyla bile zor yanıtlanabilecek sorular içerir: PhD düzeyinde biyoloji, kimya ve fizik. Doğru yanıta ulaşmak için salt ezber yetmez; derin akıl yürütme kapasitesi gerekir. Mevcut en güçlü modellerin %60–70 aralığında kaldığı bu ölçüt, performans tavanlarını zorlamaya devam ediyor.

MATH ve AIME — Matematiksel Akıl Yürütme

MATH benchmark, lise ve lisans düzeyinde 12.500 problemden oluşur; cevabın doğru olması yetmez, çözüm adımları da değerlendirilir. AIME ise Amerikan liselerarası matematik olimpiyatından seçilmiş sorularla chain-of-thought akıl yürütmeyi zorlar. Bu benchmark’larda model, tek adımda bir sayı bulmak yerine art arda çıkarımlar yaparak hedefe ulaşmak zorundadır.

MT-Bench / Chatbot Arena — Konuşma Kalitesi

MT-Bench, çok turlu konuşma kalitesini ölçmek için GPT-4’ü hakem olarak kullanan bir LLM-as-judge sistemidir. Chatbot Arena ise gerçek kullanıcıların iki modelin yanıtını görmeden hangisini tercih ettiğini oyladığı bir platformdur. Elo sistemiyle güncellenen sıralamalar, gerçek dünya tercihlerini yansıtması bakımından değerlidir; ancak örneklem yanlılığına açıktır.

RAG Pipeline’larını Değerlendirmek: RAGAS

RAG mimarisi birden fazla bileşen içerir: belgelerden ilgili parçaları çeken bir retriever ve bu parçaları kullanarak yanıt üreten bir generator. Her bileşen ayrı ayrı hata yapabilir. Retriever ilgisiz belgeler getirebilir; generator getirilen belgeleri görmezden gelerek kendi bilgisinden yanıt üretebilir.

RAGAS’ın dört boyutu, RAG pipeline’ının farklı katmanlarını ayrı ayrı ölçer.

RAGAS (Retrieval-Augmented Generation Assessment) bu iki katmanı ayrı ayrı ölçen dört temel metrik sunar:

• Faithfulness: Üretilen yanıt, getirilen bağlama ne kadar sadık? Modelin halüsinasyon üretip üretmediğini doğrudan test eder.
• Answer Relevancy: Yanıt, kullanıcının sorusuna ne kadar alakalı?
• Context Recall: Doğru yanıt için gereken bilginin ne kadarı retrieve edildi?
• Context Precision: Getirilen belgeler arasında gereksiz gürültü ne kadar?

Basit bir Python örneği:

from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall
from datasets import Dataset

data = {
    "question": ["LLM eval nedir?"],
    "answer": ["LLM eval, modelin performansını sistematik biçimde ölçen süreçtir."],
    "contexts": [["Eval, bir modelin belirli görevlerdeki çıktısını puanlayan sistematik yöntemdir."]],
    "ground_truth": ["LLM eval, modeli sistematik biçimde ölçen bir süreçtir."]
}

dataset = Dataset.from_dict(data)
result = evaluate(dataset, metrics=[faithfulness, answer_relevancy, context_recall])
print(result)

Bir RAG sisteminde prompt veya retrieval stratejisini değiştirmeyi planlıyorsanız, RAGAS metrikleri değişikliğin hangi bileşeni hangi yönde etkilediğini net biçimde ortaya koyar. Faithfulness düşüyorsa sorun generatorda; Context Recall düşüyorsa retriever’da demektir.

Eval Çerçeveleri: Braintrust, LangSmith, Inspect

Eval altyapısını sıfırdan kurmak zorunda değilsiniz. Birkaç olgun araç bu iş için tasarlanmıştır.

Braintrust

Braintrust, eval çalıştırma, skor takibi ve dataset yönetimi odaklı bir platformdur. Python ve TypeScript için kod tabanlı API’si mevcut; her eval koşusunun sonuçlarını depolayıp geçmiş koşularla karşılaştırma yapabilirsiniz. Özellikle üretim ortamında gerçek kullanıcı girdilerini log’layıp bunları test setiyle birleştirme akışında güçlü bir çözüm sunar.

LangSmith

LangChain ekosisteminde çalışıyorsanız LangSmith doğal bir seçim noktasıdır. Trace kaydı ve eval entegrasyonunu aynı arayüzden yönetebilirsiniz: bir koşunun her adımını izleyip hangi adımda puanın düştüğünü görebilirsiniz. LangChain bağımlılığı olmadan da kullanılabilir; ancak asıl güç, LangChain pipeline’larıyla derin entegrasyondan gelir.

Inspect (UK AI Safety Institute)

Inspect, Birleşik Krallık Yapay Zeka Güvenlik Enstitüsü tarafından açık kaynak olarak yayımlanan, model agnostik bir eval çerçevesidir. HumanEval, MMLU ve GPQA gibi yaygın benchmark’lar için hazır entegrasyonlar barındırır; herhangi bir model sağlayıcısıyla çalışır. Kendi task tanımlarınızı yazıp güvenlik odaklı testler oluşturmak için özellikle uygun bir altyapı sunar.

Kendi Özel Eval’ını Yazmak

Standart benchmark’lar genel kapasiteyi ölçer; sizin uygulamanızın gerçek kullanım durumunu değil. Müşteri destek botu için halüsinasyon oranı, hukuki metin özeti için terminoloji doğruluğu veya kod yardımcısı için derleme başarısı gibi domain-spesifik metrikler, ancak özel eval ile ölçülebilir.

Ne zaman custom eval gerekir?

• Görev, standart benchmark’larla örtüşmüyorsa
• Üretimde tutulmak istenen belirli bir kalite boyutu varsa
• LoRA veya fine-tuning gibi adaptasyon teknikleri uygulandıysa ve regresyon riski varsa

Temel adımlar:

1. Test seti hazırla. En az 50, ideal olarak 200 üzeri örnek. Mümkünse gerçek üretim girdilerinden derlemek, test setini daha gerçekçi kılar.
2. Skorlama fonksiyonu yaz. Exact match, regex tabanlı kural veya LLM-as-judge. Görevin yapısına göre seçin.
3. Baseline oluştur. Mevcut modelin ya da en basit çözümün skorunu kayıt altına alın. Baseline olmadan iyileşmeyi kanıtlayamazsınız.
4. Regresyon koşu otomasyonu kur. Her değişiklik sonrasında otomatik tetiklenecek bir CI adımı ekleyin.

LLM-as-judge pattern’i, insan değerlendirmesi gerektiren açık uçlu görevlerde işe yarar: başka bir modeli hakem olarak kullanıp yapılandırılmış puan ve gerekçe üretmesini istiyorsunuz. Structured outputs ile JSON formatında skor ve gerekçe döndürmek, bu süreci otomatize etmeyi kolaylaştırır. Dikkat edilmesi gereken nokta: hakem modeli de hata yapar; bu yüzden ara sıra insan onayıyla kalibrasyon yapılması gerekir.

Benchmark Savaşı: Neden Liderlik Tabloları Yanıltıcı Olabilir

Bir model belirli bir benchmark’ta en yüksek skoru aldığında bunu büyük harflerle duyurmak cazip gelir. Bu tablolara körü körüne güvenmek ise yanıltıcı olabilir.

Goodhart Yasası burada güçlü bir çekimle işler: bir ölçüt hedef haline geldiğinde, artık o ölçütü optimize etmeye başlarsınız; gerçek performansı değil. Modeller yayımlanmış benchmark sorularını eğitim verisine dahil ederse veya benchmark formatına aşırı uyum gösterirse skor yükselir ama gerçek dünya performansı yerinde sayar.

Sızıntı riski de ciddi bir sorundur. Birçok benchmark sorusu internettte kamuya açık. Eğitim veri setlerinin bu sorulardan temizlenmediği durumlarda, model test sorularını fiilen ezberleyen bir yapıya bürünmüş olabilir. “Test veri sızıntısı yok” garantisi sunamayan benchmark’lar, özellikle açık ağırlıklı modeller için güvenilirliği tartışmalıdır.

Akademi ve endüstrinin tepkisi, sızıntı geçirmez benchmark girişimleri biçiminde geldi. LiveCodeBench gerçek zamanlı güncelleme yapıyor. GPQA arama motorlarıyla zor çözülebilecek sorular içeriyor. Chatbot Arena ise insan tercihine dayandığı için format ezberinin bir yararı yok.

Bir modeli değerlendirirken tek bir sıralamaya bakmak yerine görevinize en yakın benchmark’ı seçmek, mümkünse kendi test setinizi oluşturmak ve sonuçları hem offline hem online koşullarda doğrulamak daha sağlam bir tablo verir.

Başlamak İçin Pratik Adımlar

Sıfırdan bir eval süreci kurarken aşağıdaki kontrol listesi iyi bir başlangıç noktası olabilir:

• Projenizin birincil görevi nedir? (soru yanıtlama, kod üretimi, özetleme, sınıflandırma)
• Bu göreve en yakın standart benchmark var mı? Varsa baseline alın.
• 50–100 örnekten oluşan bir golden set oluşturun; tercihen gerçek kullanıcı girdilerinden.
• Başarı kriterini tanımlayın: exact match mi, F1 mi, LLM-as-judge mi?
• Eval’ı CI/CD pipeline’ına ekleyin; her model veya prompt değişikliğinde otomatik koşsun.
• Sonuçları tarihsel olarak takip edin: skor eğrisi regresyonları erken gösterir.

Minimum geçerli eval 50 örnekten oluşabilir. Rakibinizin binlerce soruluk test setine erişmeniz gerekmiyor; asıl önemli olan tekrarlanabilir ve otomatik bir sürecin var olması. Bir kez kurulduğunda, her iyileştirme adımında size nesnel bir zemin sunar.

LLM tokenization katmanından pipeline kurulumuna kadar her adım, düzgün bir eval olmadan kör bir uçuşa benzer. Hangi modeli seçtiğiniz, nasıl ince ayar yaptığınız, hangi prompt stratejisini benimsediğiniz: bunların tümünün etkisini ancak ölçerek anlayabilirsiniz. Eval yazmak başlangıçta fazladan iş gibi görünür; ama ilk regresyon krizi yaşandığında neden bu zahmete değdiği çok net biçimde ortaya çıkar.