Altı ay önce LLM destekli bir özelliği piyasaya sürdünüz. Lansmandan önce iyi bir şekilde test edildi. Kullanıcılar başlangıçta mutlu görünüyordu. Ancak son zamanlarda yapay zeka kalitesiyle ilgili destek biletleri hızla artıyor. Model sağlayıcı geçen ay sizin gerçekten değerlendirmediğiniz bir güncelleme yayınladı. Değerlendirme veri kümeniz lansmandan bu yana yenilenmedi. Bu özelliği geliştiren ekip, yalnızca bir şey dikkat gerektirecek kadar kötü bir şekilde bozulduğunda kontrol ederek başka projelere geçti.
Bu, devam eden değerlendirme olmaksızın LLM özellikleri için varsayılan gidişattır. Model değişir, veriler değişir, kullanıcı beklentileri değişir ve gerçek bir sorun haline gelinceye kadar hiç kimse kalitenin düştüğünü fark etmez.
LLM retrospektif değerlendirmeler bu yavaş bozulmayı önleyen uygulamadır. Lansmandan önce tek seferlik bir test aşaması değil; kaliteyi ölçme, hataları anlama ve sistematik olarak iyileştirme konusunda yinelenen bir alışkanlık.
LLM Değerlendirme Temelde Neden Farklıdır?
Geleneksel yazılım geliştirmeden geliyorsanız, test etme konusundaki içgüdüleriniz sizi LLMs ile yanıltacaktır. İşte nedeni:
Çıktılar belirleyici değildir. Aynı girdi her seferinde farklı çıktılar üretebilir. Bu, basit "beklenen çıktı eşittir gerçek çıktı" iddialarıyla test yapamayacağınız anlamına gelir. Çıktı kalitesini ikili başarılı/başarısız yöntemiyle değil, bir spektrum üzerinden değerlendirmeniz gerekir.
Doğruluk özneldir. Birçok LLM görevi için tek bir doğru cevap yoktur. İyi bir özet, yararlı bir müşteri hizmetleri yanıtı, iyi yazılmış bir e-posta; bunlar, makul kişilerin aynı fikirde olmadığı yargılama çağrılarını içerir. Değerlendirme çerçevenizin bu öznelliği açıkça ele alması gerekir.
Kalite sessizce düşer. Geleneksel yazılımlar yüksek sesle bozulur: hatalar, çökmeler, başarısız testler. LLM kalite giderek düşüyor: biraz daha az doğru çıktılar, biraz farklı ton, biraz daha az alakalı yanıtlar. Birisi bunu fark ettiğinde kalite haftalardır düşüyor olabilir.
Model sizin altınızda değişir. API tabanlı bir model kullanıyorsanız (çoğu ekip de öyledir), model sağlayıcı modeli istediği zaman güncelleyebilir. Bu güncellemeler genellikle genel olarak iyileştirmeler yapar, ancak özel kullanım durumunuza ilişkin davranışı beklemediğiniz şekillerde değiştirebilirler.
Bu farklılıklar, önce test et sonra gönder yaklaşımına değil, sürekli bir değerlendirme uygulamasına ihtiyacınız olduğu anlamına gelir.
Ne Ölçülmeli
Her şeyi ölçmenize gerek yok. Özel kullanım durumunuz için önemli olan şeyleri ölçmeniz ve bunları eğilimleri tespit edecek kadar tutarlı bir şekilde ölçmeniz gerekir. İşte pratik bir çerçeve.
Doğruluk ve Sadakat
Model doğru bilgi üretiyor mu? Bu boyut en çok gerçeklere dayalı görevler için önemlidir: soru yanıtlama, özetleme, veri çıkarma, analiz.
Nasıl değerlendirilir? Son üretim çıktılarından bir örnek alın. Gerçek hatalar, halüsinasyonlar (sağlanan bağlam tarafından desteklenmeyen bilgiler) ve eksiklikler (mevcut olan ancak dahil edilmeyen önemli bilgiler) açısından bir insan incelemecinin her birini kontrol etmesini sağlayın.
Ne izlenecek? Örnek başına gerçek hataların oranı ve bu oranın yükseliş mi yoksa düşüş eğilimi mi gösterdiği. Ayrıca hataların ciddiyetini de takip edin; yanlış yazılmış bir ad, yanlış bir mali rakamdan daha az endişe vericidir.
Talimatların İzlenmesi
Model kendisinden yapmasını istediğiniz şeyi yapıyor mu? Bu, format uyumluluğunu, kısıtlamalara uyumu ve görev tamamlamayı kapsar.
Nasıl değerlendirilir? Görevin "doğru" yürütülmesinin nasıl görüneceğine ilişkin net kriterleri tanımlayın. Çıktı istenen formatla eşleşiyor mu? Uzunluk kısıtlamalarına uyuyor mu? Tanımlanan kapsam dahilinde kalıyor mu? Bunlar, kalite kararlarına göre daha nesnel olarak ölçülebilir.
Ne izlenecek: Tüm talimatları izleyen çıktıların yüzdesi. İhlalleri kategorilere ayırın; bunlar biçim sorunları mı, kısıtlama ihlalleri mi yoksa kapsam sapması mı? Her biri farklı bir düzeltmeye işaret ediyor.
Kullanıcı Tarafından Algılanan Kalite
Kullanıcılar çıktıları faydalı, iyi yazılmış ve kullanışlı buluyor mu? Bu, ölçülmesi en zor ama tartışmasız en önemli boyuttur.
Nasıl değerlendirilmelidir? İki yaklaşım iyi sonuç verir. Birincisi, ürün içi sinyaller: beğenilme/olmama, açık derecelendirmeler, takip soruları (kullanıcı bir takip sorusu sorarsa ilk yanıt tamamlanmamış olabilir). İkincisi, periyodik insan değerlendirmesi: Bir örnek alın ve özelliğiniz için "iyi"nin ne anlama geldiğini tanımlayan bir değerlendirme ölçeğine göre derecelendirin.
Ne izlenecek? Genel memnuniyet eğilimleri ve kullanıcıların memnuniyetsizliğini ifade ettiği belirli kalite boyutları.
Güvenlik ve Hizalama
Model zararlı, taraflı veya uygunsuz çıktılar mı üretiyor? Bu boyut işin ciddiyetidir; buradaki başarısızlıkların etkisi çok büyüktür.
Nasıl değerlendirilmelidir? Güvenlik testi paketinizi düzenli olarak çalıştırın (yalnızca lansman sırasında değil). Rekabetçi testleri dahil edin: Zararlı çıktıları teşvik etmek için tasarlanmış girdiler. İçerik denetleme katmanınızın işaretlediği tüm çıktıları inceleyin.
Ne izlenecek? Filtrelerin yakaladığı ramak kala olaylar da dahil olmak üzere güvenlik ihlallerinin oranı. Model güncellemelerinde rakip test sonuçlarını takip edin. Güncellemeden önce güvenli olan bir model, güncellemeden sonra güvenli olmayabilir.
Değerlendirme Retrospektifi
Kadans
Aylık çoğu ekip için iyi çalışıyor. Riskli bir alandaysanız (sağlık, finans, hukuk) veya istemleri hızla yineliyorsanız daha sık. Özelliğiniz kararlı ve düşük riskliyse daha az sıklıkla, ancak asla üç ayda bir defadan az olmamak üzere.
Hazırlık
Geçmişe dönük, yalnızca ona getirdiğiniz veriler kadar iyidir. Ekipten birinin (bu rolü dönüşümlü olarak değiştirin) aşağıdakileri hazırlaması gerekiyor:
Metrik kontrol paneli. Önceki dönemle karşılaştırmalı olarak mevcut döneme ait temel kalite metrikleriniz. Yukarıdaki boyutlara doğrudan bağlı olarak maksimum 4-6 metrik kullanarak buna odaklanın.
Değerlendirme örneği sonuçları. Değerlendirme paketinizi çalıştırın ve sonuçları getirin. İnsan değerlendirmesi yapıyorsanız bunu toplantı sırasında değil, toplantıdan önce tamamlayın.
Başarısızlık örnekleri. Dönemin en kötü 5-10 çıktısı. İçeriğin tamamını ekleyin: giriş, bilgi istemi, çıkış ve neden kötü olduğu. Bu somut örnekler en verimli tartışmanın gerçekleştiği yerdir.
Değişiklik günlüğü. Kaliteyi etkilemiş olabilecek tüm değişiklikler: istem güncellemeleri, model sürümü değişiklikleri, veri güncellemeleri, özellik değişiklikleri, kullanım düzenlerindeki değişiklikler.
Toplantı Yapısı (60 dakika)
Metrik incelemesi (10 dakika). Her boyutta gelişiyor muyuz, azalıyor muyuz yoksa sabit mi kalıyoruz? Önem verdiğimiz eşiği aşan herhangi bir ölçüm var mı? Açıklayamadığımız beklenmedik değişiklikler var mı?
Arızanın ayrıntılı incelemesi (25 dakika). Arıza örneklerini inceleyin. Ekibin her biri için şunları tartışması gerekir:
- Özellikle ne yanlış gitti?
- Bu yeni bir arıza modu mu yoksa daha önce gördüğümüz bir arıza modu mu?
- Temel neden nedir; bilgi istemi, model, veri veya başka bir şey?
- Gelecekte bunu otomatik olarak nasıl yakalarız?
Amaç toplantıdaki her başarısızlığı düzeltmek değildir. Kalıpları anlamak ve öncelikleri belirlemektir.
Değerlendirme sürecinin gözden geçirilmesi (10 dakika). Değerlendirmemiz gerçekten doğru şeyleri ölçüyor mu? Yakalayamadığımız arıza modları var mı? Test senaryolarımızı güncellememiz gerekiyor mu? Değerlendirme kriterlerimiz hâlâ kullanıcıların önem verdiği şeylerle uyumlu mu?
Bu meta inceleme önemlidir. Değerlendirme süreçleri de her şey gibi bayatlayabilir. Test senaryolarınızın tümü altı ay öncesine aitse ve kullanıcılarınızın ihtiyaçları değiştiyse değerlendirmeniz size yanlış bir güvenlik duygusu veriyor demektir.
Eylem öğeleri (15 dakika). 2-3 spesifik iyileştirme seçin. Bunlar genellikle kategorilere ayrılır:
- Belirli hata modellerini ele almak için değişiklikleri isteme
- Değerlendirme iyileştirmeleri (yeni test senaryoları, güncellenmiş değerlendirme listeleri, daha iyi otomasyon)
- Korkuluk güncellemeleri (yeni güvenlik filtreleri, ek işlem sonrası kontroller)
- İnceleme görevleri (açıklanamayan bir kalite değişikliğini araştırmak, belirli bir hata modunun profilini çıkarmak)
Değerlendirme Yığınınızı Oluşturma
Başlamak için pahalı aletlere ihtiyacınız yok. İşte pratik bir ilerleme.
Aşama 1: Manuel Değerlendirme (Buradan Başlayın)
Haftalık olarak 20-30 üretim çıktısını örnekleyin. İki ekip üyesinin her birini kalite değerlendirme listenize göre bağımsız olarak derecelendirmesini sağlayın. Derecelendirmelerini karşılaştırın; eğer sıklıkla aynı fikirde değillerse değerlendirme listenizin daha spesifik olması gerekir. Bu derecelendirmeleri bir e-tabloda izleyin.
Bu gösterişsiz ama etkilidir. Modelinizin davranışı hakkında herhangi bir otomatik metrikten ziyade 30 gerçek çıktıyı okuyarak daha fazla bilgi edineceksiniz.
2. Aşama: Yarı Otomatik Değerlendirme
Bir değerlendirme veri kümesi oluşturun: Girdi, beklenen çıktı özellikleri (kesin çıktılar olması gerekmez) ve kalite ek açıklamalarını içeren 100-200 örnek. İstemleri veya modelleri değiştirdiğinizde bunu otomatik olarak çalıştırın. Regresyonları üretime ulaşmadan önce yakalamak için sonuçları kullanın.
İyi çalıştığı boyutlar için LLM hakem değerlendirmesini ekleyin: format uyumu, talimat takibi, temel olgusal doğrulama. İnsan değerlendirmesini, ince ayrıntılar, yardımseverlik, üslup uygunluğu gibi boyutlar için kullanmanın mümkün olmadığı durumlarda kullanın.
Aşama 3: Sürekli İzleme
Üretim trafiğinde otomatik kalite kontrolleri ayarlayın. Bunların her şeyi yakalaması gerekmez; kalite önemli ölçüde değiştiğinde sizi uyaracak kadar yakalamaları gerekir. Basit bir yaklaşım: Üretim sorgularının küçük bir yüzdesini rastgele örnekleyin, otomatik kontroller çalıştırın ve başarısızlık oranı bir eşiği aşarsa uyarı verin.
Bu, insani değerlendirmenizin yerine geçmek yerine onu tamamlar. Otomatik izleme, ani değişiklikleri hızlı bir şekilde yakalar. İnsan değerlendirmesi, otomatik metriklerin gözden kaçırdığı ince kalite sapmalarını yakalar.
Yaygın Değerlendirme Hataları
Yalnızca kolay örnekler üzerinde değerlendirme. Değerlendirme veri kümeniz zor durumları içermiyorsa, gerçek dünya performansını değil, en iyi durum performansını ölçüyorsunuz demektir. Rakip girdileri, belirsiz sorguları, alana özgü içeriği ve gerçek kullanıcılarınızın gönderdiği karmaşık girdi türlerini ekleyin.
Otomatik metriklerin tek ölçü olarak kullanılması. Otomatik metrikler (BLEU, ROUGE, BERTScore) eğilimleri izlemek için kullanışlıdır ancak birçok görev için insan kalitesi kararlarıyla zayıf bir korelasyona sahiptir. Otomatik ölçümleriniz kalitenin iyi olduğunu söylüyor ancak kullanıcılar şikayet ediyorsa kullanıcılara güvenin.
Farklı değerlendirme kümelerindeki modelleri karşılaştırma. Modelleri değiştirip değiştirmemeyi değerlendiriyorsanız her ikisi için de tamamen aynı değerlendirme kümesini kullanın. Model A'yı bir örnek grubu üzerinde, Model B'yi ise farklı bir örnek grubu üzerinde test ederseniz karşılaştırma anlamsız olur.
Değerlendiriciler arası anlaşmayı takip etmemek. Eğer insan değerlendiricileriniz derecelendirmelerin %40'ı konusunda aynı fikirde değilse, değerlendirme verileriniz gürültülü olur. Ya değerlendirme listenizi geliştirin, daha fazla eğitim sağlayın ya da görevin doğası gereği öznel olduğunu kabul edin ve metriklerinizi buna göre tasarlayın.
Çok seyrek değerlendirme. Haftalık model değişiklikleriyle aylık değerlendirme, her zaman eski verilere baktığınız anlamına gelir. Değerlendirme temponuzu değişim temponuzla eşleştirin.
Değerlendirmeyi Kültürün Bir Parçası Haline Getirmek
LLM değerlendirmesinin en zor kısmı metodoloji değil, uygulamayı sürdürmektir. Değerlendirme, özellikle işler iyi gittiğinde, yük gibi gelir. "Sadece bu ay"ı atlama isteği gerçek.
Ne yardımcı olur: Değerlendirme sonuçlarını görünür hale getirin. Bunları ekip kanallarında paylaşın. Kalite iyileştirmelerini kutlayın. Kalite gerilemelerini araştırılmayı hak eden olaylar olarak ele alın. Değerlendirme, kullanıcılar fark etmeden bir sorunu ortaya çıkardığında onu da görünür hale getirin; bu, devam eden yatırımın haklılığını gösterir.
Güçlü bir değerlendirme uygulamasına sahip ekipler zamanla modelleri hakkında daha iyi sezgiler geliştirir. Başarısızlık modlarını öngörürler. Daha güvenli bir şekilde hızlı değişiklikler yaparlar. Sorunlar ortaya çıktığında daha hızlı yakalarlar. Retrospektif, bu kurumsal bilgiyi inşa eden mekanizmadır.
NextRetro'yi ücretsiz deneyin — Metrik incelemesi, arıza analizi ve iyileştirme planlaması aşamalarıyla değerlendirmenizi geriye dönük olarak yapılandırın.
Son Güncelleme: Şubat 2026
Okuma Süresi: 8 dakika
