LLM özelliklerini golden setler, deterministik kontroller ve CI'daki eval geçitleriyle test etmek

Ahmed Mahmoud'un dev.to'da yayımladığı saha rehberi, büyük dil modelleri üzerine kurulu özellikleri test etme yaklaşımını ortaya koyuyor ve geleneksel unit testlerin asıl önemli hataları göremediğini savunuyor. Onların yerine property tabanlı eval'lar, sürüm kontrolüne alınmış bir golden set, deterministik assertion'lar ve CI'a bağlı bir gerileme geçidi öneriyor.

Makale, onu motive eden hatayla açılıyor: serbest metin destek mesajlarını yapılandırılmış ticket'lara dönüştüren bir route, bir meslektaşı system prompt'taki ton talimatlarının ifadesini değiştirene kadar sorunsuz çalışıyordu. Çıkarım (extraction), hiç içermeyen mesajlar için sipariş numarası uydurmaya başladı ve depodaki her test yeşil kaldı; çünkü testler modelin etrafındaki kodu kapsıyordu, modelin söylediğini değil.

Neden birebir eşleşme testleri başarısız olur

Mahmoud'a göre bir LLM deterministik olmayan bir fonksiyondur; bu yüzden çıktının sabit bir dizgeye eşit olduğunu iddia etmek, doğrulukla ilgisi olmayan nedenlerle başarısız olur. Temperature'ı sıfıra ayarlamak çıktıyı daha kararlı kılar ama bayt bayt aynı yapmaz: sağlayıcılar istekleri toplu işler ve kayan nokta birikimi toplu işler arasında farklılık gösterir; ayrıca hiçbir büyük sağlayıcı yeniden üretilebilir token garantisi vermez. Tam dizge eşleşmesi kullanan test paketleri kod değişmeden kırmızıyla yeşil arasında gidip gelir ve ekipler bunları yok saymayı öğrenir.

Önerilen çözüm, kodu model sınırından bölmektir. Prompt oluşturma, retry mantığı, çıktı ayrıştırma ve ayrıştırılan sonucu tüketen her dal sıradan deterministik fonksiyonlardır ve sıradan unit testleri hak ederler. Modele geçen çağrı tek başına eval alır ve bu eval, her doğru yanıtta doğru olan özellikleri puanlar: çıktı şemaya göre ayrıştırılabiliyor mu, istenen dilde mi kalıyor, yalnızca girdide var olan tanımlayıcılara mı atıf yapıyor ve bağlamda yanıt yoksa reddediyor mu.

Üretim hatalarından büyüyen golden setler

Yazarın tanımına göre golden set, gerçek girdilerle çıktılarının sağlaması gereken özelliklerin eşleştiği, sürüm kontrolüne alınmış bir dosyadır. Kendisininki yaklaşık bir düzine vakayla başladı ve üretim her sürpriz yaptığında büyüdü; bir AI özelliğinde düzelttiği her hata dosyada yeni bir satır oldu. Sentetik vakalar yerine gerçekleri tercih ediyor, çünkü tuhaf olanlar gerilemeleri yakalar: boş mesaj, Arapça yazılmış mesaj, yalnızca bir sipariş numarasından oluşan mesaj, bir e-postadan kopyalanmış prompt injection denemesi.

İki saklama kuralının işe yaradığını yazıyor: fixture'ları JSON veya JSONL olarak test ettikleri prompt'un yanında tutun, böylece vaka listesi bir pull request'te incelenebilir olsun; ve prompt'u bir route handler içindeki template literal yerine kendi dosyasında tutun, böylece bir prompt değişikliği ile eval sonuçları aynı diff'te görünsün. Örnek kodu, Vercel AI SDK'nın generateObject fonksiyonunu bir Zod şemasıyla kullanıyor; böylece bir şekil gerilemesi, sonuçlar assertion'lara akmadan önce hata fırlatıyor.

Herhangi bir judge çağrısından önce deterministik kontroller

Rehberin pratik kuralı şu: hata dizge üzerinde bir koşul (predicate) olarak ifade edilebiliyorsa deterministik bir kontrol kullanın ve yalnızca okuma anlayışı gerektiren özellikler için judge'a başvurun. Deterministik kontroller — şema doğrulama, zorunlu alt dizgeler, yasak dizgeler, sayısal aralıklar — gerilemelerin çoğunu yakalar, milisaniyeler içinde çalışır ve hiçbir maliyeti yoktur.

Yazar özellikleri yöntemlere eşliyor: çıktı şekli için şema doğrulama, grounding için alt dizge veya küme kontrolleri (halüsinasyon tanımlayıcılar dizge olarak algılanabilir ve en zarar verici hata sınıfıdır), prompt sızıntısı gibi yasak içerik için regex kara listeleri, dil, uzunluk ve biçim için basit hesaplama. Yanıtın gerçekten soruyu ele alıp almadığı ise judge'a bırakılıyor.

LLM-as-judge'ı dürüst tutmak

Judge, ilk modelin çıktısını yazılı bir rubrik üzerinden puanlayan ikinci bir model çağrısıdır; kendi hata oranı ve kendi faturası vardır. Mahmoud judge'ı sürümü olan bir üretim kodu gibi ele alır: tam model kimliğini sabitleyin, kayan bir alias değil; çünkü sağlayıcı tarafındaki sessiz bir model değişikliği ürününüzde bir kalite gerilemesi olarak okunur. Birden ona puanlama yerine ikili sorular sorun; çünkü yanıtın iade son tarihinin bildirilip bildirilmediğini sormak yeniden üretilebilirken faydalılık puanları kayar. Rubriki commit'lenmiş, gözden geçirilen bir dosyada tutun. Yirmi otuz çıktıyı elle etiketleyip judge'ın kararlarıyla karşılaştırarak kalibre edin — bir judge insan etiketleriyle karşılaştırılmadan puanının kanıtlanmış bir anlamı yoktur. Bütaje izin veriyorsa, yargılamada üretimde kullanılandan farklı bir model ailesi kullanın; çünkü modeller kendi ifade biçimlerine olumlu puan verme eğilimindedir.

CI'ı mükemmelliyete değil gerilemeye göre geçitlemek

Son öneri: pass rate, depoya commit'lenmiş bir eşiğin altına düştüğünde build'i başarısız kılın ve o eşiği yükseltmeyi gözden geçirilmiş bir commit olarak ele alın. Geçit, mükemmel bir puanı değil gerilemeyi hedefler.

Neden önemli

AI özellikleri yayınlayan çoğu ekipte zaten müşterilerin gerçekte gördüğü davranış dışında her şeyi doğrulayan bir CI var. Bu rehber, mevcut test koşturucularına uyan ve yeni bir platform gerektirmeyen kademeli bir yol sunuyor — property assertion'ları, büyüyen bir golden set, kalibre edilmiş bir judge ve bir gerileme geçidi. Ayrıca bir AI özelliğindeki en riskli yapıtları, yani prompt'ları, fixture'ları, rubrikleri ve eşikleri, diff'lerde incelenebilir hale geldikleri sürüm kontrolünün içine çekiyor.