Bir ekibin, modelin API'sini hiç çağırmadan, LLM tabanlı bir özellik üzerinde 28 birim testi çalıştırmasını sağlayan dahili bir araç geliştirdiniz. Bunu, modeli taklit edilebilir (fakeable) bir arayüz içine alarak ve üç katmanlı (deterministik, sezgisel ve LLM tabanlı) bir değerlendirme yapısı ekleyerek başardınız.

Standart assertion'lar, bir LLM düzyazı üretmeye başladığı anda bozulur. Aynı istem (prompt), her çalıştırmada farklı bir cümle üretebilir; bu nedenle assertEqual(output, expected) ifadesi, model doğru davranıyor olsa bile bir hata bildirir. Çoğu mühendislik grubu ya özelliği hiçbir doğrulama yapmadan yayına alır ya da sürekli değişen bir hedefi sanki statik bir kütüphaneymiş gibi ele alarak modelin kendisini test etmeye çalışır.

Bu sorun neden önemli

LLM'ler artık müşteriyle temas kuran iş akışlarının içinde yer alıyor: e-posta erişimi, destek yanıtları, içerik üretimi. Tek bir halüsinasyon içeren bilgi veya sızdırılmış bir tanımlayıcı; marka itibarına zarar verebilir, özel verileri açığa çıkarabilir veya uyumluluk ihlallerini tetikleyebilir. Güvenilir bir test stratejisi olmadan, ekipler kararsız (flaky) hataların peşinde zaman kaybeder veya yalnızca üretim ortamında (production) ortaya çıkan hataları yayına alır.

Yaklaşım: modelin sorumluluğunu küçültmek

İlk adım, LLM'in gerçekte ne yapacağını sınırlandırmaktı. Yazarın sisteminde model sadece erişim mesajlarının taslağını oluşturur. Tüm yönlendirme mantığı, durum yönetimi ve güvenlik kontrolleri normal kod içerisinde kalır. Modeli tek ve iyi tanımlanmış bir çıktı ile sınırlandırarak, çevredeki sistemin deterministik ve test edilebilir kalması sağlanır.

Bunu mümkün kılmak için LLM, testlerde sahte (fake) bir versiyonun kullanılmasına olanak tanıyan bir sağlayıcı arayüzünün (provider interface) arkasında yer alır. Üretim ortamında uygulama harici API'yi çağırırken, test paketinde hafif bir sahte (fake) nesne hazır bir yanıt döndürür. Kodun geri kalanı yalnızca arayüzle etkileşime girdiği için, tüm iş akışı ağa hiç dokunmayan birim testleri ile yürütülebilir. Sonuç, 28 testin doğruladığı öngörülebilir bir çekirdektir.

Dürüst bir değerlendirme düzeneği (harness)

Kapsam daraltılmış olsa bile modelin çıktısı deterministik değildir. Bu nedenle yazar; her katmanı farklı bir risk sınıfını ele alan üç katmanlı bir değerlendirme düzeneği oluşturdu.

  • Katman 1 – Deterministik kontroller Basit düzenli ifade (regex) kuralları, yanlış bina kimliği veya yasaklı belirteçler gibi somut hataları yakalar. Bu kontroller hızlıdır ve ikili (pass/fail) sonuç verir.

  • Katman 2 – Sezgisel (heuristic) kontroller Betikler, halüsinasyon içeren sayıları veya tarihleri arayarak bariz gerçek dışı uydurmacılıkları işaretler. Sayısal ipuçları içermeyen yanlış iddiaları gözden kaçırabilirler ve yazar bu sınırlamayı açıkça kabul etmektedir.

  • Katman 3 – LLM yargıcı İkincil bir model, tonu ve profesyonelliği değerlendirir. Bu adım başka bir olasılıksal sisteme dayandığı için yalnızca deterministik kuralların imkansız olacağı öznel yönler için kullanılır.

Düzeneğin anahtarı, değerlendirme için kullanılan veri setidir. Yazar, bilinen hata modellerini —belirli tuzaklar ve alan bilgisi— kodlayarak düzeneğin tam olarak pratikte ortaya çıkan hataları test etmesini sağlamıştır. Bu, sihirli bir "her şeyi yakalayan" araç değil, hedeflenmiş bir güvenlik ağıdır.

Bu ekipler için ne anlama geliyor

  • LLM'in görevini küçük tutun. Daha az sorumluluk, izolasyonu ve testi kolaylaştırır.
  • Yönlendirme, durum ve güvenliği koda koyun. Geleneksel mantık deterministik ve tam test edilebilir kalır.
  • Modeli taklit edilebilir bir arayüz üzerinden sunun. Birim testleri harici çağrılar yapmadan çalışarak test paketini hızlı ve güvenilir tutar.
  • Değerlendirmelerinizi katmanlandırın. Deterministik kurallarla başlayın, bilinen halüsinasyonlar için sezgisel yöntemler ekleyin ve LLM yargıcılarını yalnızca öznel kalite kontrolleri için ayırın.
  • Sınırları belirtin. Hiçbir katman mükemmelliği garanti etmez; düzenek yalnızca açıkça tespit etmesi için programladığınız şeyleri yakalar.

Karşı görüş: modeli yine de birim testiyle test edemezsiniz

Yazar, bir modelin sürekli değişen bir hedef olduğunu kabul ediyor. LLM yargıcı katmanı bile değerlendirmeye çalıştığı aynı deterministik olmayan yapıyı miras alır. Sonuç olarak sistem, her halüsinasyonun veya politika ihlalinin sürümden önce yakalanacağını asla garanti edemez. Bu yaklaşım riski ortadan kaldırmaz, sadece azaltır ve yeni hata modları ortaya çıktıkça değerlendirme verilerini güncel tutma yeteneğine dayanır.

Sonuç

Bir LLM'in tam çıktısını doğrulayan klasik bir birim testi yazamazsınız, ancak modelin etkisinin sınırlandırıldığı, arayüzünün değiştirilebilir olduğu ve çıktısının katmanlı, şeffaf kontrollerle tarandığı bir sistem kurabilirsiniz. Bu kombinasyon, aksi takdirde kararsız bir bileşeni, daha büyük ve test edilebilir bir uygulamanın öngörülebilir bir parçasına dönüştürür.