Yapay Zekâ Test Seti: Demo Başarısını Ürün Kalitesinden Ayırın

Test sorularını satış demosundan toplamayın

Demo soruları genellikle sistemin güçlü olduğu örneklerdir. Üretim testinde sık gelen kolay soruların yanında az görülen ama önemli hatalar da yer almalıdır. Başlangıç için iş ekiplerinin geçmiş sorun türlerini sınıflandırması faydalıdır. Gerçek kayıtlardan yararlanılıyorsa gizlilik ve kullanım izinleri ayrıca değerlendirilmelidir.

Her soruya bir amaç ekleyin: doğru belgeyi bulma, iki bilgiyi birleştirme, bilinmeyeni belirtme veya yetkisiz içeriği göstermeme. Aynı cevabı bekleyen onlarca benzer cümle, test setini görünürde büyütürken kapsamı çok az genişletebilir.

Arama kalitesi ile cevap kalitesini ayırın

RAG sisteminde doğru kaynak bulunmamışsa iyi yazılmış cevap yine yanlış olabilir. AWS değerlendirme dokümantasyonu yalnızca getirilen bilginin ve bilgiyle üretilen cevabın ayrı değerlendirme türlerini açıklar. [1] Test sonuçlarını da bu iki katmana ayırmak hatanın nerede oluştuğunu araştırmayı kolaylaştırır.

Örneğin doğru belge ilk sonuçlarda var ama model yanlış maddeyi kullanıyorsa üretim aşaması incelenir. Doğru belge hiç gelmiyorsa sorgu, indeks veya erişim filtresi araştırılır. Her başarısızlığı “model yetersiz” diye etiketlemek yanlış çözüm seçimine yol açabilir.

Örnek: destek bilgi tabanı için dört test grubu

Varsayımsal sistem ürün kurulum sorularını cevaplıyor. Bazı sorular tek belgeden, bazıları iki sürümün farkından yanıtlanıyor. Bazılarının cevabı hiç yok. Sistem bütün sorulara kesin cevap vermek yerine kaynak bulunmadığında bunu doğru anlatmalıdır.

Testlerin ağırlıkları işletmenin riskine göre belirlenmelidir. Bir yetki ihlalinin çok sayıda doğru cevabın ortalamasında kaybolması uygun bir kabul yaklaşımı değildir.

Beklenen cevabı tek bir cümleye hapsetmeyin

Aynı doğru cevap farklı kelimelerle yazılabilir. Bu nedenle gerekli bilgi parçaları, kabul edilen kaynaklar ve yasak çıkarımlar tanımlanabilir. Sayısal veya kod çıktılarında ise daha kesin doğrulama uygun olabilir. Değerlendirme yöntemi çıktı türüne göre seçilmelidir.

İnsan değerlendiriciler kullanılıyorsa aynı örneği nasıl puanlayacakları konusunda ortak yönerge hazırlayın. Görüş ayrılıklarını kaydedin. Otomatik değerlendirici model kullanmak da tek başına doğruluk garantisi değildir; kritik örneklerde bağımsız kontrol gerekir.

Geliştirme seti ile son kontrol setini ayırın

Sürekli aynı sorulara göre ayar yapmak, sistemin o örneklere fazla uyarlanmasına yol açabilir. Önerilen süreçte bir grup örnek geliştirme için, ayrı bir grup nihai karşılaştırma için korunur. Yeni bulunan gerçek hata türleri kontrollü biçimde test kapsamına eklenir.

NIST AI risk yönetimi çerçevesi, yapay zekâ risklerinin bağlam içinde ele alınmasına yönelik bir yapı sunar. [2] Buradaki test planı da yalnızca model puanını değil, kullanım bağlamını ve hatanın etkisini kaydetmelidir. Bu, bir sertifikasyon iddiası değildir.

Kabul raporunda kapsam ve sınırlama görünsün

Toplam puanın yanında soru grupları, başarısız örnekler, değerlendirici yöntemi ve kullanılan sürümler yer alsın. Model, istem, bilgi tabanı ve uygulama sürümü kaydedilmeden sonuç tekrar üretilemez. Küçük bir test setinden bütün müşteri trafiği için kesin başarı oranı çıkarmayın.

Teslimde çalıştırılabilir test verisi, değerlendirme yönergesi ve hata inceleme listesi isteyin. İlk yayın sonrası bulunan yeni sorunlar için güncelleme süreci de planlansın. Kalite, yalnızca bir defalık demo onayından oluşmamalıdır.

Sık sorulan sorular

### Kaç test sorusu yeterli? Tek bir evrensel sayı yoktur. İş türleri, riskler, diller ve istisnalar temsil edilmeli; yeterlilik kapsam üzerinden değerlendirilmelidir.

Yüksek ortalama puan yayına çıkmak için yeterli mi?

Kritik hata grupları ayrıca geçmelidir. Yetki ihlali veya ciddi yanlış yönlendirme, ortalama içinde gizlenmemelidir.