LLM Değerlendirme: Ölçüm Sistemi Modeli Küçük Gösteriyordu

Bağlam

Türkçe LLM fine-tuning sürecinde model iterasyonlarını karşılaştırmak için bir değerlendirme sistemi kullanılıyordu. Bu sistem, hangi modelin üretime alınacağına dair kararların temelini oluşturuyordu.

Problem

Fine-tuning iterasyonları arasında model karşılaştırmaları yapılırken sonuçlar tutarsız ve güvensiz görünüyordu. Bazı modeller beklentilerin çok altında kalıyor, bazıları ise mantıkla açıklanamayacak ölçüde iyi puan alıyordu. Değerlendirme sisteminin mi, modelin mi sorunlu olduğunu ayırt etmek gerekliydi.

Neden Önemliydi?

Üretim kararları bu sisteme dayanıyordu. Yanlış ölçüm, yanlış modeli üretime almak demek. Daha da tehlikelisi: eğer ölçüm sistemi kötü modelleri iyi, iyi modelleri kötü gösteriyorsa, fine-tuning çabası ters yönde iterasyon yapıyor olabilirdi.

Ben Neyi Sorguladım?

Tek sorum şuydu: değerlendirme sisteminin güvenilirliğini kanıtlayan bir şey var mı? Pipeline'ı kuranın "bu çalışıyor" demesi yetmez; bir sistemi güvenilir kabul etmek için onun ne zaman yanıldığını da bilmek gerekir. Mevcut sistemin nerede hata yaptığını bulmak için onu kasıtlı olarak zorladım.

Teşhis

Pipeline'ı adım adım incelediğimde 12'den fazla tutarsızlık tespit ettim. Başlıcaları şunlardı: hakem model promptu aynı kalite için farklı boyuttaki modelleri sistematik olarak farklı puanlıyordu (uzunluk yanlılığı); bazı soru kategorileri, Türkçe dilbilgisi açısından nötr olmayan görev tanımları içeriyordu; puanlama rubriği subjektif ve yoruma açık ifadeler barındırıyordu. Bütün bu etkenler toplandığında gerçek model performansı yaklaşık 15 puan baskılanıyordu.

Değerlendirilen Seçenekler

• Mevcut sistemi yama yap: Hızlı ancak sorunları kök nedeninden çözmez; her yama yeni tutarsızlık riski taşır.
• Farklı hakem model kullan: Hakem model tek sorun değil; soru kalitesi ve rubrik de sorunlu. Model değiştirmek yetersiz kalır.
• Sıfırdan yeniden tasarla: Zaman alır ama gelecekteki tüm kararların temeli sağlam olur.

Verdiğim Karar

Sistemi sıfırdan yeniden tasarladım. Kısmi yama yapmak, güvensiz temeli yalnızca gizlerdi; sonraki altı ay boyunca her model karşılaştırması bu sisteme dayanacaktı. Kısa vadeli hız kayıpları uzun vadeli karar güvenliğinden daha ucuz.

Uygulama

• 12 tutarsızlık belgelendi ve kök nedenlerine göre kategorize edildi
• 200+ soruluk Türkçe benchmark yeniden yazıldı: her soru dil ve biçim açısından nötr hale getirildi
• Puanlama rubriği somutlaştırıldı; "iyi bir yanıt X içerir" kriterleri netleştirildi
• Hakem model promptu uzunluk yanlılığını giderecek şekilde revize edildi
• Pipeline, async API çağrılarıyla paralel model değerlendirmesini destekleyecek şekilde yeniden yazıldı

Ölçüm Yöntemi

Yeni sistemin güvenilirliğini iki yöntemle doğruladım: (1) iki insan değerlendirici aynı 50 yanıtı ayrı ayrı puanladı, ardından sistem sonuçlarıyla karşılaştırıldı; (2) kasıtlı olarak kötü hazırlanmış yanıtlar sisteme verildi ve beklenen düşük puan alındı mı kontrol edildi.

Sonuç

Yeni sistem, insan değerlendirme kararlarıyla %85 oranında örtüştü. Sonraki tüm fine-tuning model karşılaştırmaları bu altyapıya dayandırıldı.

Sınırlamalar

• %85 insan uyumu, değerlendirme sistemlerinde iyi bir oran; ama kritik üretim kararları için hâlâ belirsizlik içeriyor.
• Benchmark soruları Türkçe pazarlama alanına odaklı; farklı alanlara genelleştirilmesi için yeni sorular gerekir.
• Hakem model puanlaması deterministik değil; aynı yanıt farklı çalıştırmalarda farklı puan alabilir.

Öğrendiklerim

Bir değerlendirme sistemini güvenilir kabul etmek için onun ne zaman hata yaptığını bilmek gerekiyor. "Pipeline çalışıyor" ifadesi bir güvenilirlik kanıtı değil. Bu projeden sonra yeni bir ölçüm sistemi kurduğumda ilk adımım artık kasıtlı hata senaryolarıyla sistemi zorlamak: beklenen hataları üretiyor mu?