Bir LLM uygulaması için ilk test kümenizi kurmak: değerlendirme (eval) rehberi

Bir ekip, müşteri mesajlarını sınıflandıran sistemin prompt'unu yeniden yazıyor. Ekipten üç kişi yeni sürümü birkaç örnekle deniyor ve "çok daha iyi" diyor. Yeni prompt yayına alınıyor. Altı hafta sonra biri, fatura şikâyetlerinin önemli bir kısmının bu süre boyunca yanlış ekibe gittiğini fark ediyor. Yeni prompt genel olarak gerçekten daha iyiydi; yalnızca bir kategoride belirgin biçimde daha kötüydü ve kimse o kategoriye bakmamıştı.

Değerlendirme, bir yapay zeka sistemini demo eden kişiyle onu yayına alan kişi arasındaki en net çizgidir. Ve en çok atlanan adımdır.

LLM değerlendirmesi nedir?

Bir sistemin cevaplarını sabit bir soru kümesi üzerinde, tekrarlanabilir bir yöntemle ölçmektir.

Amaç tek bir soruyu cevaplamaktır: yaptığım değişiklik sistemi iyileştirdi mi, kötüleştirdi mi? Bunun için her seferinde aynı sorular, aynı "doğru" tanımı ve aynı puanlama yöntemi kullanılır. Böylece iki sürüm arasındaki fark, ölçüm yönteminin değil sistemin farkı olur.

Neden "bence iyi oldu" yetmez?

Çünkü birkaç örnek ve bir izlenim, değişikliğin bozduğu şeyi göstermez.

Bir dil modelinin davranışı girdiye göre değişir. Bir prompt değişikliği on sorunun dokuzunu iyileştirip onuncuyu bozabilir; birkaç örnekle yapılan bir deneme büyük ihtimalle o onuncuyu içermez. Ayrıca insanlar yeni bir sürümü, onu yazdıkları için iyi görmeye yatkındır. Sabit bir ölçüm bu iki sorunu da ortadan kaldırır.

İlk test kümesi nasıl kurulur?

Gerçek kullanımdan alınmış otuz ila elli örnekle ve "doğru"nun ne olduğunu cevaplara bakmadan önce yazarak.

Başlamak için büyük bir küme gerekmez. Gerçek kullanıcı mesajlarından (ya da yoksa, gerçekçi biçimde yazılmış örneklerden) otuz ila elli tane toplayın ve her biri için kabul edeceğiniz cevabı yazın. Bu cevapları sistemin çıktısını görmeden önce yazmak önemlidir; aksi hâlde gördüğünüz cevaba göre cömert davranırsınız. Kümeye kolay örneklerin yanında mutlaka şunları da koyun: zor ve sınırda örnekler, yazım hatası içeren mesajlar, birden fazla soru içeren mesajlar ve sistemin "bilmiyorum" demesi gereken sorular.

Taban çizgisi neden gereklidir?

Çünkü bir puan, karşılaştırılacak bir şey olmadan hiçbir şey ifade etmez.

"Doğruluk yüzde seksen beş" cümlesi, tek başına iyi mi kötü mü olduğunu söylemez. Değişiklik yapmadan önce mevcut sistemin aynı kümedeki puanını ölçün; bu sizin taban çizginizdir. Mümkünse en basit alternatifi de ölçün: daha küçük bir model, daha kısa bir prompt ya da hiç model kullanmayan basit bir kural. Bazen pahalı çözümün, basit olanı neredeyse hiç geçmediği ortaya çıkar. Taban çizgisi olmayan bir puan, ölçüm gibi hissettiren bir sayıdır.

Ortalama neden yanıltır?

Çünkü belirli bir alandaki büyük bir düşüşü, diğer alanlardaki küçük artışların arkasına saklar.

Yukarıdaki ekibin yaşadığı tam olarak buydu: genel doğruluk arttı, fatura kategorisindeki doğruluk ise düştü. Bu yüzden puanı yalnızca toplam olarak değil, kategori kategori raporlayın. Bazı hataların bedeli diğerlerinden çok daha yüksektir: acil bir mesajın "acil değil" sayılması, acil olmayan bir mesajın "acil" sayılmasından çok daha pahalıdır. Bu tür hataları ayrı bir sayı olarak izlemek, ortalamanın gizleyeceği riski görünür kılar.

Ne ölçülmelidir?

Biçimi kodla, içeriği bir puanlama yöntemiyle, maliyeti ve gecikmeyi de her seferinde.

Cevabın biçimi (geçerli JSON mu, beklenen alanlar var mı, izin verilen kategorilerden biri mi) kodla kesin olarak kontrol edilebilir ve her zaman edilmelidir. İçeriğin doğruluğu, cevabın türüne göre ya birebir karşılaştırmayla ya da bir puanlama yönergesiyle ölçülür. Bunlara ek olarak her çalıştırmada ortalama maliyeti ve gecikmeyi de kaydedin: daha doğru ama iki kat pahalı bir sürüm, her zaman doğru seçim değildir.

Bir modelin başka bir modeli puanlaması ne zaman güvenilirdir?

İnsan değerlendirmesiyle karşılaştırılıp ne kadar uyuştuğu ölçüldüğünde.

Açık uçlu cevapları (bir özet, bir açıklama) birebir karşılaştırmak mümkün değildir. Bu durumlarda bir modelin, bir yönergeye göre başka bir modelin cevabını puanlaması (LLM-as-judge) pratik bir yoldur. Ama bu puanlayıcının da yanılgıları vardır: uzun cevapları daha iyi bulmaya, iki seçenekten ilk gösterileni tercih etmeye ve kendi yazdığı cevaplara benzeyenleri ödüllendirmeye yatkın olabilir. Bu yüzden puanlayıcıyı kullanmadan önce, bir insanın da puanladığı küçük bir örnek üzerinde ne kadar uyuştuklarını ölçün. Uyuşma düşükse, puanlayıcının verdiği sayılar ölçüm değildir.

Yayındaki sistem nasıl izlenir?

Gerçek trafikten düzenli örnek alarak ve test kümesini her değişiklikte otomatik çalıştırarak.

Test kümesi, yayından önceki ölçümünüzdür. Yayından sonra gerçek kullanıcılar test kümenizde olmayan sorular sorar. Gerçek trafikten düzenli olarak örnek alıp bunları kontrol etmek, kullanıcıların olumsuz geri bildirimlerini toplamak ve yeni bulunan hataları test kümesine eklemek, kümeyi zamanla gerçeğe yaklaştırır. Test kümesini kodla birlikte her değişiklikte otomatik çalıştırmak ise, bir puan düşüşünü kullanıcılar fark etmeden yakalamanın yoludur. Bir kursun değerlendirmeyi öğretip öğretmediğinin neden en önemli soru olduğunu kurs seçimi yazımızda anlattık.

Kaynaklar

• Hugging Face: Evaluation Guidebook: dil modeli değerlendirmesinin pratik rehberi; LLM-as-judge'ın yanılgıları dahil. (eklenme: 2026-09)
• Anthropic: Create strong empirical evaluations: bir test kümesinin nasıl tasarlanacağı. (eklenme: 2026-09)
• EleutherAI: LM Evaluation Harness: modellerin standart görevlerde ölçüldüğü açık bir araç. (eklenme: 2026-09)
• Hugging Face: Evaluate library: yaygın ölçütlerin hazır uygulamaları. (eklenme: 2026-09)