# Bir LLM uygulaması katman katman nasıl test edilir?

> Bu saha notunda veridive, LLM uygulamaları için katmanlı bir test planı sunuyor. Deterministik parçalar, model çağrılarının yerine sahte yanıtlar konarak sıradan kod gibi test edilir; bilgi erişimi ayrı ölçülür, yanıt kalitesini değerlendirme setleri sınar, saldırı ve uçtan uca testler aradaki bağlantıları kapsar. Not, tekrarlı çalıştırmaları, toleransları, CI kapılarını ve değerlendirmelerin maliyetini anlatıyor.

Deterministik parçaları sıradan yazılım gibi, dil parçalarını değerlendirme setleriyle, aradaki bağlantıları da ayrıca test edin. Tek bir uçtan uca doğruluk sayısı, sorunun gerçekte nerede olduğunu gizler.

## Öne çıkanlar

- Deterministik kodu, model çağrılarının yerine sahte yanıtlar koyarak sıradan yazılım gibi test edin; birim testleri hızlı, ücretsiz ve tekrarlanabilir kalsın.
- Bilgi erişimini ayrı ölçün: doğru pasaj hiç gelmediyse hiçbir prompt yanıtı düzeltemez.
- Değişken çıktıyı tekrarlı çalıştırmalar, özellik kontrolleri ve referans sürümün çalıştırmalar arası oynamasından ölçülen toleranslarla yönetin.
- Her değişikliği hızlı testlere ve değerlendirme setinin küçük bir dilimine bağlayın; tam seti, saldırı vakalarını ve uçtan uca kontrolleri her gece çalıştırın.

Bir ekip yönlendirme komitesine tek bir sayı raporluyor: asistanın değerlendirme setinde ne sıklıkla doğru yanıt verdiği. Bir değişiklikten sonra sayı düşüyor ve kimse nedenini söyleyemiyor. Sorun bilgi erişimi dizini, bir prompt düzenlemesi, bir tarih ayrıştırıcısı, sağlayıcının bir model güncellemesi ya da yeni gelen bir belge grubu olabilir. Tek sayı, sorunun gerçekte nerede olduğunu gizler.

Bir LLM uygulamasını kurulduğu gibi test edin: deterministik parçaları sıradan yazılım gibi, dil parçalarını değerlendirme setleriyle, aradaki bağlantıları da ayrıca.

## LLM uygulamalarını test etmenin farkı nedir?

Dört şey. Çıktı dildir; bu yüzden karşılaştırılacak tek bir kesin yanıt nadiren vardır. Çıktı çalıştırmadan çalıştırmaya değişir ve arkasındaki model, sizin tarafınızda hiçbir sürüm çıkmadan değişebilir. Sistem ayrıştırma, bilgi erişimi, prompt oluşturma, model çağrısı, doğrulama ve entegrasyondan oluşan bir işlem hattıdır; herhangi bir aşamadaki hata “yapay zeka yanlış yaptı” gibi görünür. Son olarak, model çağıran testler para ve zaman harcar.

Yine de uygulamanın çoğu sıradan koddur. Bu plan her test türünü, en ucuz ve en bilgilendirici olduğu yerde tutar:

| Katman | Neyi test eder | Nasıl | Ne zaman |
|---|---|---|---|
| Birim | Ayrıştırma, prompt oluşturma, doğrulayıcılar, iş kuralları | Sıradan testler; model çağrıları yerine sahte yanıtlar | Her commit’te |
| Bileşen | Tek başına bilgi erişimi ve veri çıkarma | Etiketli sorgular ve belgeler | O bileşendeki her değişiklikte |
| Değerlendirme seti | Gerçek vakalarda yanıt kalitesi | Referans yanıtlar, puanlama ölçütü, tekrarlı çalıştırmalar | Her prompt, model ya da kaynak değişikliğinde ve her gece |
| Uçtan uca | Gerçek entegrasyonlar üzerinden akışın tamamı | Test ortamında senaryosu yazılmış birkaç vaka | Her sürümden önce |
| Saldırı | Enjeksiyon, veri sızıntısı, onayı atlatma | Reddedilmesi beklenen saldırı vakaları | Değerlendirme setiyle birlikte |

## Hangi parçalar sıradan kod gibi test edilebilir?

Sanıldığından fazlası:

- **Girdi işleme.** Tarih ve tutar ayrıştırma, karakter kodlaması ve Türkçedeki İ ile ı için büyük-küçük harf dönüşümü; dil ayarını dikkate almayan basit bir küçük harf dönüşümü bu harflerde hata yapar.
- **Prompt oluşturma.** Doğru talimatlar, örnekler ve getirilen pasajlar prompta doğru sırayla ve uzunluk bütçesi içinde girer. Anlık görüntü (snapshot) testleri kazara yapılan değişiklikleri yakalar.
- **Doğrulayıcılar ve iş kuralları.** Şema kontrolleri, alanlar arası toplamlar, eşikler.
- **Altyapı kodu.** Araç sarmalayıcıları, yetkiler, tekrar denemeler, zaman aşımları ve hata yönetimi.

Birim testlerinde modelin yerine sahte yanıtlar (mock) koyun: her çağrının yerine kaydedilmiş ya da hazır yanıtlar kullanın; bozuk bir JSON, boş bir yanıt ve bir zaman aşımı da bunlara dahil olsun. Testler hızlı, ücretsiz ve tekrarlanabilir kalır; model ne döndürürse döndürsün, kodunuzun onunla ne yaptığını kontrol eder.

## Bilgi erişimi tek başına nasıl test edilir?

İçerik sahibiyle birlikte yazılmış, etiketli bir sorgu setiyle ve her sorguda gelmesi gereken pasajlarla; kaynaklarda yanıtı olmayan sorular da bu sette yer almalı. Her sorgu için iki şey sorun: doğru pasaj ilk sonuçlar arasında çıktı mı ve bu kullanıcının görmeye yetkili olmadığı bir şey geldi mi? Bilgi erişiminin bir RAG (erişimle zenginleştirilmiş üretim) sisteminde nerede durduğunu [iş ekipleri için hazırlanan RAG notu](https://veridive.com/tr/saha-notlari/rag-nedir-nasil-calisir/) gösteriyor.

Bilgi erişimini ayrı ölçmek, sistemin hangi yarısını düzeltmeniz gerektiğini söyler. Son çıktıda ise bilgi erişimindeki bir ıskalama ile üretimdeki bir hata aynı görünür.

> Doğru pasaj hiç gelmediyse hiçbir prompt yanıtı düzeltemez.

Metni parçalara bölme yönteminde, embedding’lerde, dizinde ya da kaynak belgelerde yapılan her değişiklikte bilgi erişimi testlerini yeniden çalıştırın.

## Değerlendirme setleri bu planda nereye oturur?

Katmanların ortasına: dil parçalarını, süreç sahibinin onayladığı yanıtlarla gerçek vakalar üzerinde test ederler. Nasıl oluşturulacağı [değerlendirme setlerinin yeni gereksinim dokümanı olduğunu anlatan notta](https://veridive.com/tr/saha-notlari/llm-degerlendirme-seti/) yer alıyor. Test açısından üç nokta önemlidir. Kesin alanları kesin olarak, serbest metni bir puanlama ölçütüyle puanlayın. Sonuçları tek bir ortalama olarak değil, vaka türüne göre ve referans sürümle karşılaştırarak raporlayın. Yanıtları bir model puanlıyorsa, puanlayıcıyı önce insanlarla karşılaştırarak doğrulayın; bunu [bir yapay zekanın başka bir yapay zekayı puanlamasına ne zaman güvenilebileceğini anlatan not](https://veridive.com/tr/saha-notlari/llm-ile-otomatik-degerlendirme/) açıklıyor.

## Her çalıştırmada değişen çıktıyla nasıl başa çıkılır?

Görev izin verdiği ölçüde rastgeleliği azaltın ama aynı çıktılara güvenmeyin; en düşük ayarlarda bile aynı çıktı vaat edilmez. Ardından testleri değişkenliğe göre tasarlayın:

- **Tekrarlı çalıştırmalar.** Her değerlendirme vakasını birkaç kez çalıştırın. Yalnızca bazen geçen bir vaka bir bulgudur; genellikle belirsiz bir talimata ya da gerçekten belirsiz bir vakaya işaret eder.
- **Özellik kontrolleri.** Birebir ifadeyi değil, doğru olması gerekeni kontrol edin: tutar sipariş toplamına eşit mi, yanıt doğru politikadan bir paragrafı kaynak gösteriyor mu, başka bir müşterinin verisi görünüyor mu?
- **Ölçülmüş gürültüye dayanan toleranslar.** Mevcut sürümü birkaç kez çalıştırıp puanının tesadüfen ne kadar oynadığını görün. Bir değişiklik, önemli her vaka türünde referans sürüme bu pay kadar yakın kalırsa geçer.

## Her değişiklikte ne çalışır, her gece ne çalışır?

Sürekli entegrasyon (CI) hattına kalite kapıları koyun. Sahte model yanıtlarıyla çalışan birim testleri her commit’te çalışır. Bir promptta, bilgi erişimi ayarında, modelde ya da kaynakta yapılan her değişiklik bileşen testlerini ve değerlendirme setinin hızlı bir dilimini çalıştırır; önemli bir vaka türü eşiğinin altına düşerse değişiklik ana dala birleştirilemez. Her gece tam değerlendirme seti tekrarlarıyla birlikte, saldırı vakaları ve uçtan uca senaryoyla yan yana çalışır. Gece çalıştırmaları, kodunuzda hiçbir şey değişmediğinde sağlayıcı tarafında olan değişiklikleri de yakalar.

Değerlendirmeler model çağrısı harcar: vaka sayısı çarpı çalıştırma sayısı çarpı vaka başına çağrı sayısı; buna bir de puanlama eklenir. Hızlı dilimi küçük tutun, tam seti bilgi kattığında çalıştırın ve bütçesini diğer derleme altyapısı gibi planlayın.

Temsili bir örnek ele alalım: çalışanların seyahat ve masraf sorularını kaynak göstererek yanıtlayan bir politika asistanı (sayılar varsayımsaldır):

- **Birim:** tarih ayrıştırıcı “31.12” ve “çeyrek sonu” ifadelerini doğru işler; prompt oluşturma bütçe içinde kalır; kaynak bağlantıları paragrafa gider. Model çağrılarının yerinde sahte yanıtlar vardır.
- **Bileşen:** yüz yirmi etiketli soru, doğru paragrafın geldiğini ve erişimi kısıtlı İK dosyalarından hiçbir şeyin gelmediğini kontrol eder.
- **Değerlendirme seti:** politika sahibinin yanıtladığı üç yüz gerçek soru; doğruluk ve kaynağın desteklemesi açısından puanlanır, her biri üç kez çalıştırılır.
- **Saldırı:** bir çalışma arkadaşının masraf beyanlarını isteyen talepler ve onay limitini yok saymayı söyleyen talimatlar.
- **Kalite kapıları:** her commit’te birim ve bileşen testleri; her prompt ya da bilgi erişimi değişikliğinde elli vakalık bir dilim; her gece de tam set, saldırı vakaları ve on soruluk bir uçtan uca senaryo.

## Tek bir doğruluk sayısı nasıl parçalanır?

Uygulamanızın yalnızca uçtan uca bir doğruluk sayısı varsa onu parçalayın: birim testlerinizde modelin yerine sahte yanıtlar koyun ve bir bilgi erişimi test seti kurun. Bir dahaki sefere puan düştüğünde hangi katmanı açmanız gerektiğini bilirsiniz. Geliştirdiğimiz her [özel yapay zeka yazılımı](https://veridive.com/tr/hizmetler/ozel-yapay-zeka-yazilimi/) sistemiyle birlikte bir değerlendirme seti ve regresyon kontrolleri gelir; [yapay zeka güvenilirliği](https://veridive.com/tr/hizmetler/yapay-zeka-guvenilirligi/) çalışmamız da bunları canlıya geçişten sonra çalışır halde tutar.

## Sık sorulan sorular

### Bir LLM uygulaması nasıl test edilir?

Katman katman. Ayrıştırmayı, prompt oluşturmayı, doğrulayıcıları ve iş kurallarını, model çağrılarının yerine sahte yanıtlar koyarak sıradan kod gibi test edin. Bilgi erişimini ve veri çıkarmayı etiketli verilerle bileşen olarak test edin. Yanıt kalitesini gerçek vakalardan oluşan bir değerlendirme setiyle ölçün, enjeksiyon ve veri sızıntısı için saldırı vakaları ekleyin ve her sürümden önce gerçek entegrasyonlar üzerinden birkaç uçtan uca senaryo çalıştırın.

### Dil modeli çağıran kod için birim testi nasıl yazılır?

Model çağrısının yerine kaydedilmiş ya da hazır yanıtlar koyun; bozuk yanıtlar da bunlara dahil olsun. Böylece testler hızlı, ücretsiz ve deterministik olur. Ardından kodunuzun bu yanıtlarla ne yaptığını test edin: prompt oluşturma, ayrıştırma, doğrulama, tekrar denemeler, zaman aşımları ve hata yönetimi. Yanıt kalitesine ilişkin yargıları, gerçek vakalar üzerinde gerçek model çağrılarıyla çalışan değerlendirme setine bırakın.

### Her çalıştırmada değişen LLM çıktısı nasıl test edilir?

Her değerlendirme vakasını birkaç kez çalıştırın ve tek bir sonuca değil, dağılıma bakın. Birebir metin yerine özellikleri kontrol edin: tutar siparişle eşleşiyor mu, doğru politika paragrafı kaynak gösterilmiş mi? Referans sürümün puanlarının çalıştırmalar arasında ne kadar oynadığını ölçün ve geçme eşiklerini bu gürültüye dayanan bir payla belirleyin.

## Kaynaklar

1. OWASP Top 10 for Large Language Model Applications. OWASP Gen AI Security Project. https://genai.owasp.org/llm-top-10/
2. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, NIST AI 600-1. ABD Ulusal Standartlar ve Teknoloji Enstitüsü (NIST). https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf