LLM ve AI modeli nasıl değerlendirilir?

Önce model değil, kabul edilecek iş sonucu tanımlanmalıdır

“En iyi model hangisi?” sorusu tek başına karar üretmez. Müşteri mesajını sınıflandıran, finansal raporu özetleyen, kod üreten, belge arayan veya araç çağıran sistemlerin başarı ve hata tanımları farklıdır. Değerlendirme planı; hedef kullanıcıyı, görevi, girdiyi, beklenen çıktıyı, hata etkisini, insan kontrolünü ve kabul eşiğini birlikte kaydetmelidir.

Genel benchmark puanı kurumsal uygunluk anlamına gelmez

Genel testler modelin bazı yetenekleri hakkında karşılaştırmalı sinyal verir; fakat kurumun dili, doküman biçimi, ürün terimleri, hata toleransı, güvenlik politikası ve kullanıcı davranışını temsil etmeyebilir. Ayrıca model sağlayıcısının sürüm, sistem talimatı, araç erişimi ve güvenlik filtreleri üretim sonucunu değiştirir.

• Benchmark ile gerçek görev performansını ayrı raporlayın.
• Tek ortalama yerine hata sınıflarını ve alt grupları görünür kılın.
• Modelin açıklanan sürümünü, tarihini ve yapılandırmasını kaydedin.
• Prompt, sıcaklık, bağlam uzunluğu ve araç ayarını sürümleyin.
• Modelin kendi ürettiği değerlendirmeyi tek hakem olarak kullanmayın.

Kuruma ait test seti gerçek kullanım dağılımını ve zor örnekleri içermelidir

Test seti; normal örnekler, sınır durumları, eksik veya çelişkili girdiler, güncel olmayan belgeler, çok dilli içerik, hassas veri ve kötü niyetli talimatları kapsamalıdır. Canlı kullanım verisi kullanılacaksa veri minimizasyonu, erişim, saklama ve anonimleştirme kuralları uygulanmalıdır.

1. Sonucu etkileyen görevleri ve alt görevleri listeleyin.
2. Her görev için temsil edici, zor ve güvenlik odaklı örnekler hazırlayın.
3. Beklenen cevabı veya puanlama rubriğini uzmanlarla onaylayın.
4. Test, geliştirme ve canlı izleme setlerini birbirinden ayırın.
5. Her örneğin kaynağını, sürümünü ve kullanım iznini kaydedin.
6. Model veya süreç değiştiğinde regresyon setini yeniden çalıştırın.

Yalnız başarılı örneklerden oluşan set, üretimdeki kırılganlığı saklar. Özellikle yüksek etkili kullanımda “modelin cevap vermemesi gereken” durumlar da test edilmelidir.

Kalite, güvenlik ve işletim ölçütleri ayrı tutulmalıdır

İnsan değerlendirmesi rubrik, eğitim ve hakem uyumuyla kalibre edilmelidir

Özet kalitesi, gerekçe yeterliliği, ton veya bağlama uygunluk gibi ölçütler insan değerlendirmesi gerektirebilir. “Beğendim/beğenmedim” yorumu yerine açık rubrik, puan örnekleri ve hata sınıfları kullanılmalıdır. Kritik örneklerde birden fazla değerlendirici ve uyuşmazlık çözüm süreci kurulmalıdır.

• Değerlendirici görev ve kullanım bağlamını bilmeli.
• Referans cevap tek mümkün cevap gibi sunulmamalı.
• Kör karşılaştırma, marka ve model önyargısını azaltmalı.
• Hakemler arası uyum ve kararsız örnekler izlenmeli.
• Model yargıcı kullanılıyorsa insan örnekleriyle kalibre edilmeli.

Red teaming yalnız zararlı içerik değil, iş sürecinin kötüye kullanımını da sınamalıdır

Kurumsal değerlendirme; veri dışarı çıkarma, prompt injection, rol aşımı, sahte kaynak, yetkisiz araç çağrısı, kişisel veri üretimi, zararlı belge ve güvenlik politikası atlatma senaryolarını kapsamalıdır. Ajan sistemlerinde test, model cevabından çok kimlik, araç, işlem limiti ve geri alma zincirine odaklanır.

Üretim performansı, laboratuvar kalitesinden farklı ölçülmelidir

Gecikme, kapasite, sağlayıcı kotası, bölgesel erişim, bağlam büyüklüğü, cache, araç hatası ve insan düzeltme süresi üretim değerini belirler. Model düşük gecikmeli görünürken RAG, güvenlik filtresi ve araç zinciri toplam süreyi artırabilir. Bu nedenle uçtan uca görev süresi ve başarı maliyeti izlenmelidir.

• P50, P95 ve P99 gecikme.
• Başarılı, reddedilen ve yeniden denenen görev oranı.
• İnsan düzeltmesi ve eskalasyon süresi.
• Model, retrieval, araç ve altyapı maliyeti.
• Sürüm değişiminden sonra kalite ve güvenlik sapması.
• İş birimi veya kullanım alanı başına değer göstergesi.

Model karşılaştırması aynı koşulda ve karar ağırlıklarıyla yapılmalıdır

Modeller aynı test seti, sistem talimatı, araç politikası ve kabul sınırında karşılaştırılmalıdır. Sonuçlar yalnız “kazanma oranı” olarak değil; kritik hata, güvenlik, gecikme, maliyet ve sağlayıcı bağımlılığıyla birlikte gösterilmelidir.

Hangi modelin seçileceği kullanım alanının ağırlıklarına bağlıdır. Yüksek etkili karar desteğinde kritik hata oranı, içerik taslağında ise maliyet ve hız daha ağır basabilir.

Değerlendirme satın alma öncesi bitmez

Model, veri, prompt, retrieval, araç, politika ve kullanıcı davranışı değiştikçe test sonucu eskir. Her önemli değişiklikte regresyon testi; canlıda kalite, güvenlik, maliyet ve olay izleme; kabul sınırı aşıldığında geri alma veya kullanım daraltma kararı gerekir.

• Model ve sağlayıcı sürüm kaydı.
• Değişiklik öncesi ve sonrası karşılaştırma.
• Canlı hata örneklerinin test setine kontrollü eklenmesi.
• Dönemsel red-team ve güvenlik tekrarı.
• İnsan override ve şikâyet verisinin analizi.
• Durdurma, geri dönüş ve alternatif model planı.