Agentic uygulamalarda kanıt odaklı test mimarisi

Agentik bir uygulama, klasik bir yazılımdan daha fazla karar verir ve daha fazla sonuç üretir. Bir kullanıcı isteğini yorumlar, bilgi toplar, araç seçer, dış sistemlere erişir, işi daha sonra sürdürür ve bazen insandan onay ister. Bu akışın bir yerinde hata oluştuğunda sorun yalnızca yanlış bir yanıt değildir. Yanlış kişiye giden bir bildirim, iki kez yapılan bir işlem, yetkisiz bir veri erişimi ya da geri alınamayan bir dış etki olabilir.

Bu yüzden agentik sistemlerde testin amacı "çalışıyor mu?" sorusunu yanıtlamak değildir. Asıl soru şudur: Sistem, belirsizlik altında doğru sınırda kalabildiğini ve yaptığı işin izlenebilir olduğunu gösterebiliyor mu?

Kanıt odaklı test mimarisi bu soruyu merkeze alır. Her kritik davranış için beklenen sonucu, kabul edilebilir kanıtı, başarısızlık halinde güvenli durma biçimini ve üretimde izlenecek sinyalleri birlikte tanımlar. Test, geliştirme ekibinin son kontrolü olmaktan çıkar. Ürün kararlarını, operasyonu ve risk yönetimini bağlayan bir çalışma biçimine dönüşür.

Neden geleneksel test yaklaşımı yetmez?

Klasik uygulamalarda temel risk çoğu zaman belirli bir girdinin belirli bir çıktıyı üretmemesidir. Agentik sistemlerde ise yol değişkendir. Aynı talep farklı bilgi kaynaklarına, araçlara veya ara adımlara gidebilir. Modelin ürettiği metin tek başına etkili olmayabilir, ama bu metnin tetiklediği araç çağrısı etkili olabilir.

Bu fark dört sonucu beraberinde getirir.

İlki, doğruluk tek boyutlu değildir. Yanıt anlamlı görünse bile yanlış kaynağa dayanabilir, yanlış yetkiyle işlem yapabilir veya kullanıcının istediği sınırı aşabilir.

İkincisi, yeniden üretilebilirlik zorlaşır. Model davranışı, bağlam, zaman, bağlı servislerin durumu ve kullanıcı verisi değişebilir. Aynı testin her koşumda aynı sonucu vermesi, bu yüzden tasarım kararıdır.

Üçüncüsü, sistemin etkisi çok aşamalıdır. Planlama, araç seçimi, onay, işlem, kayıt ve bildirim farklı bileşenlerde gerçekleşebilir. Sadece son yanıtı test etmek, zincirin ortasındaki kritik sapmaları görünmez bırakır.

Dördüncüsü, güvenlik ve kalite ayrılmaz hale gelir. Aşırı yetki, istem yönlendirmesi, hassas veri sızıntısı ve sınırsız kaynak tüketimi, işlev testi geçse bile iş açısından kabul edilemez sonuçlar doğurur. OWASP'ın büyük dil modeli uygulamaları için yayımladığı riskler bu sınırların doğrudan test edilmesini gerektirir.¹

Bu nedenle güçlü bir mimari, testleri "birim, entegrasyon, uçtan uca" diye sıralamakla yetinmez. Her katmanın hangi riski düşürdüğünü ve hangi kanıtı ürettiğini tanımlar.

Kanıt odaklılık ne demektir?

Kanıt odaklılık, her iddianın ölçülebilir bir karşılığı olmasıdır. "Sistem güvenli", "onay var" veya "uçtan uca test edildi" gibi cümleler tek başına kanıt değildir. Bunların yerine şu sorular sorulur:

Hangi davranışın güvence altına alındığı açık mı?
Beklenen ve yasaklanan sonuçlar yazılı mı?
Test, yalnız metni mi yoksa dış etkiyi de mi doğruluyor?
Sonucun hangi sürüm, politika ve veri koşulunda elde edildiği kaydediliyor mu?
Üretimde aynı davranış bozulduğunda bunu gösterecek sinyal var mı?

NIST'in AI Risk Management Framework yaklaşımı, test, değerlendirme, doğrulama ve geçerleme süreçlerinin nesnel, tekrarlanabilir ve belgelenmiş olmasını önerir.² Agentik sistemlerde bunun pratik karşılığı, kritik yolculukları test senaryosu olmaktan çıkarıp kanıt paketine dönüştürmektir.

Örnek bir kanıt paketi şunları içerir: kullanıcının niyeti, sistemin oluşturduğu plan, izin verilen araçlar, çağrılan araçlar, onay kararı, işlem sonucu, hata veya geri alma kaydı ve ilgili telemetri. Böyle bir paket, hem bir testin neden geçtiğini açıklar hem de üretimde yaşanan olayın kök nedenini araştırmayı kolaylaştırır.

Kurulması gereken test katmanları

Katmanlı yapı, daha çok test yazmanın değil, doğru soruyu doğru maliyetle sormanın yoludur. Her katman bir sonrakinin yerine geçmez.

Davranış çekirdeği

İlk katman, sistemin deterministik kurallarını sınar. Yetki denetimi, durum geçişleri, idempotency anahtarları, bütçe hesapları, zaman aşımı kuralları, veri filtreleri ve politika değerlendirmesi burada yer alır.

Bu testler hızlı çalışmalıdır. Gerçek ağ, saat, rastgelelik veya model çağrısı içermezler. Saat enjekte edilir, rastgelelik sabitlenir ve dış bağımlılıklar kontrollü ikamelerle değiştirilir. Amaç, geliştiricinin her değişiklikten sonra saniyeler içinde güvenilir geri bildirim almasıdır.

Mevcut davranışı korumak da bu katmanın işidir. Büyük ve karmaşık bir bileşen yeniden tasarlanmadan önce characterization testleriyle gözlemlenen davranış kayda alınabilir. Böylece ekip, refactor sırasında "ne değişti?" sorusunu tahminle değil, test sonucuyla yanıtlar.

Sözleşme ve entegrasyon katmanı

Agentik uygulamalar araçlar, kuyruklar, veri depoları, kimlik sistemleri ve insan onay mekanizmaları arasında çalışır. Bu sınırların her biri bir sözleşmedir.

Entegrasyon testleri, gerçek şema ve hata davranışına yakın koşullarda şunları doğrular: bir işin güvenli biçimde oluşturulması, olayın yinelenmesi durumunda tekilleştirilmesi, onay sonrası işlemin doğru bağlamda sürmesi, başarısızlık halinde kaydın tutarlı kalması. Araç katmanında ise izin verilen parametreler, çağrı sınırları, hata kodları ve geri dönüş biçimleri test edilir.

Burada sık yapılan hata, her şeyi mock'lamaktır. Mock, bir çağrının gerçekleştiğini denetlemek için iyidir. Davranışı olan küçük ikameler, yani fake'ler ise kuyruk, saat, bellek ya da dosya deposu gibi bileşenlerde daha anlamlı güvence verir. Fixture'lar okunabilir ve sabit test verisidir. Bu ayrım korunmadığında testler uygulamanın gerçek sözleşmesini değil, kendi varsayımlarını doğrular.

Karar kalitesi ve değerlendirme katmanı

Modelin ürettiği yanıtların test edilmesi, yalnızca kelime eşleştirmesiyle yapılamaz. Beklenen davranış; görevin doğru anlaşılması, uygun aracın seçilmesi, gerekirse soru sorulması, belirsizlikte işlem yapmaması ve kaynakla tutarlı sonuç vermesi gibi ölçütlere ayrılmalıdır.

Bu katman için temsil gücü olan bir değerlendirme seti gerekir. Set, normal örneklerin yanında sınır durumları, çelişkili istekler, eksik bağlam, yetki aşımı talepleri ve kötü niyetli yönlendirmeler içermelidir. Her örnek için yalnız ideal yanıt değil, kabul edilemez eylem de belirtilmelidir.

Amaç modeli her seferinde aynı cümleyi yazmaya zorlamak değildir. Amaç, kabul edilebilir davranış alanını tanımlamaktır. Değerlendirici insan, kural tabanlı kontrol veya ayrı bir model olabilir. Kritik iş akışlarında birden fazla kanıt türünü birlikte kullanmak daha güvenlidir.

Uçtan uca işlem yolculukları

Uçtan uca test, bir kullanıcının talebinden başlayıp gözlenebilir sonuca kadar uzanır. Agentik sistemlerde en değerli yolculuklar genellikle şunlardır: bilgi isteği, plan oluşturma, yetki kontrolü, onay toplama, araç çağrısı, sonuç kaydı ve kullanıcıya bildirim.

Bu testlerde yalnız başarılı yol değil, kesintili yol da çalıştırılmalıdır. Araç yanıt vermediğinde, onay zaman aşımına uğradığında, aynı olay yeniden geldiğinde veya işlem ortasında iptal edildiğinde sistem ne yapıyor? Kalıcı etkisi olan bir işte tekrar deneme güvenli mi? Kullanıcıya gösterilen durum gerçek sistem durumuyla uyumlu mu?

E2E testi pahalıdır. Bu yüzden sayısı sınırlı, seçimi risk odaklı olmalıdır. Her ekran için E2E yazmak yerine, iş ve güvenlik açısından geri döndürülemez sonuç üreten yolculuklara odaklanmak daha iyi sonuç verir.

Güvenlik, kötüye kullanım ve dayanıklılık

Agentik sistemlerin güvenlik testi, klasik yetki kontrollerinin ötesine geçer. İstem yönlendirmesi araç kullanımı üzerinde etkili oluyor mu? Model, erişememesi gereken veriyi bir araç sonucundan çıkarabiliyor mu? Okuma izni olan bir iş akışı yazma etkisi doğurabiliyor mu? Bir kullanıcı, maliyet veya çağrı sınırlarını aşabiliyor mu?

Bu katman, negatif testlerle güçlenir. Sistem yalnız izin verilen davranışı yapmamalı, yasaklanan davranışı da tutarlı biçimde reddetmelidir. Varsayılan yaklaşım en az yetki olmalıdır. Araçların parametre şemaları, veri kapsamı, işlem limiti ve onay gereksinimleri açıkça sınanmalıdır.

Dayanıklılık testleri de burada önemlidir. Uzun süreli koşumlar kuyruk birikmesini, bellek kaybını, tekrar deneme fırtınasını ve dış bağımlılık kesintilerini ortaya çıkarır. Kısa bir demo akışının başarılı olması, sistemin saatler sonra da güvenilir olduğu anlamına gelmez.

Tasarım ilkeleri

İyi bir test mimarisi, test aracından önce birkaç net ilkeye dayanır.

Yan etkileri ayırın. Planlama, karar verme ve dış dünyada işlem yapma birbirinden ayrılmalıdır. Saf karar mantığı kolay test edilir. Dış etki noktaları dar ve görünür olduğunda onay, kayıt ve geri alma kuralları da netleşir.

Politikayı kod gibi yönetin. Kimlerin hangi aracı hangi bağlamda kullanabileceği, sadece dokümanda kalmamalıdır. Politikalar sürümlenmeli, test edilmeli ve her işlemde kayda geçmelidir. Politika değişikliği de yazılım değişikliği kadar dikkat ister.

Varsayılanı güvenli seçin. Belirsiz yetki, eksik veri veya tutarsız plan varsa sistem daha fazla özerklik kazanmak yerine durmalı, açıklama istemeli ya da onaya gitmelidir.

Her işlemi izlenebilir yapın. Bir kararın hangi bağlamla, hangi kuralla ve hangi araç sonucuyla alındığı sonradan anlaşılabilmelidir. Bu kayıt, kişisel veri ve gizlilik ilkeleri gözetilerek tutulmalıdır.

Test verisini izole edin. Her koşum kendi kullanıcı, çalışma alanı, işlem ve ilişki kimlikleriyle çalışmalıdır. Paylaşılan ortam verisi, saat ve global durum flaky testlerin başlıca nedenidir.

Geri alma tasarlayın. Bazı dış etkiler geri alınamaz. Bu yüzden sistem, etkili adımı mümkün olduğunca geç atmalı ve öncesinde niyeti, kapsamı ve yetkiyi doğrulamalıdır. Geri alınabilen işlemlerde ise geri alma akışı da test edilmelidir.

İşe ve teknolojiye katkısı

Kanıt odaklı yaklaşımın katkısı yalnız hata sayısını azaltmak değildir. Yönetim açısından daha erken ve daha iyi karar alma olanağı verir.

Ürün ekipleri, hangi kullanım alanının güvenle ölçeklenebileceğini görür. Mühendislik yöneticileri, test kapsamını satır yüzdesi yerine risk alanlarına göre tartışabilir. Güvenlik ekipleri, araç izinleri ve kötüye kullanım senaryoları için görünür kontrol noktaları kazanır. Operasyon ekipleri ise üretimdeki sinyalleri test planına geri bağlayabilir.

Bu yaklaşım aynı zamanda teslim hızını korur. Güvenlik ve kalite sonradan eklenen kontrol listeleri olduğunda ekipler bekler. Politika, test ve yayın kapıları iş akışının parçası olduğunda riskli değişiklikler daha erken ayrışır. Düşük riskli değişiklikler hızlı ilerler, yüksek riskli olanlar ise daha fazla kanıt üretmeden yayına çıkmaz.

Sık görülen başarısızlık biçimleri

İlk başarısızlık, test sayısını başarı ölçütü sanmaktır. Çok sayıda test, kritik iş akışının sınandığını göstermez. Yetki sınırı veya tekrar eden işlem riski test edilmemişse yüksek coverage rahatlatıcı ama yanıltıcı olabilir.

İkinci hata, modeli izole edip sistemi test etmemektir. Model değerlendirmesi iyi sonuç verse bile araç parametreleri, onay akışı veya veri erişim katmanı yanlış çalışabilir.

Üçüncüsü, üretim verisini test verisi yerine kullanmaktır. Bu yöntem hem gizlilik hem de tekrar üretilebilirlik açısından sorun yaratır. Temsili sentetik veri ve kontrollü örnekler daha güvenlidir.

Dördüncüsü, flaky testleri görmezden gelmektir. Kararsız test, ekibin test sonucuna olan güvenini yıpratır. Sorunlu testleri tekrar çalıştırarak gizlemek yerine zaman, veri ve asenkronluk kaynaklarını düzeltmek gerekir.

Son hata, insan onayını bir formaliteye çevirmektir. Onay ekranı, kullanıcıya gerçekten neyin yapılacağını, hangi verinin kullanılacağını ve etkinin ne olacağını anlatmıyorsa insan döngüde değildir. Sadece düğmeye basıyordur.

Ölçümleme ve kalite kapıları

Kalite kapısı, yalnız kodun derlenmesi değildir. Riskle orantılı kanıtın tamamlanıp tamamlanmadığını denetler.

Değişiklik önerisinde en azından şu soruların yanıtı aranmalıdır: Bu değişiklik hangi kullanıcı veya iş etkisini değiştiriyor? Hangi politikayı etkiliyor? Hangi test katmanında kanıt üretildi? Yeni bir dış etki oluşturuyor mu? Geri alma planı var mı?

Yayın öncesi kapılar, değişikliğin niteliğine göre ayrılabilir. Her değişiklikte hızlı davranış testleri, tür kontrolleri ve temel güvenlik taramaları çalışır. Entegrasyon içeren değişikliklerde sözleşme testleri eklenir. Araç yetkisi, hassas veri veya mali etkisi olan değişikliklerde insan onayı, negatif güvenlik testleri ve sınırlı yayın gerekir.

Ölçümleme tarafında şu göstergeler anlamlıdır:

Kritik yolculukların başarılı tamamlama oranı
Güvenli reddetme ve doğru onaya yönlendirme oranı
Tekrar eden olayların tekilleştirilme başarısı
Onay bekleme, araç çağrısı ve uçtan uca işlem gecikmesi
Politika ihlali veya yetki reddi oranı
Değerlendirme setinde davranış kalitesi ve gerileme oranı
Flaky test oranı ve kararsızlığın kaynağı
Yayın sonrası geri alma, hata bütçesi tüketimi ve kullanıcı etkisi

Bu göstergeler tek başına hedef değildir. Birlikte okunmaları gerekir. Örneğin daha yüksek otomasyon oranı, yanlış işlemler veya yetki reddi artıyorsa gerçek ilerleme sayılmaz.

Yayın güvenliği için kademeli dağıtım da güçlü bir araçtır. Google SRE yaklaşımı, değişikliğin küçük bir trafik diliminde gözlemlenmesini ve doğrulama geçmezse otomatik geri alınmasını önerir.³ Agentik sistemlerde bu yaklaşım, yeni model, politika veya araç sürümünün sınırlı kullanıcı ve etki alanında denenmesi anlamına gelir.

Benimseme yol haritası

Bu mimariyi bir defada kurmak gerekmez. Başlangıç noktası en yüksek riskli işlemlerdir.

İlk aşamada, sistemin geri döndürülemez veya hassas sonuç üreten akışları listelenir. Her akış için izin verilen etki, yasaklanan etki, insan onayı gereksinimi ve üretim sinyalleri yazılır. Ardından en temel durum geçişleri ile yetki kuralları hızlı ve deterministik testlerle güvence altına alınır.

İkinci aşamada, araçlar ve dış sistemler için sözleşme testleri kurulur. Onay, tekrar deneme, zaman aşımı ve hata sonrası toparlama senaryoları eklenir. Test verisi izolasyonu ve gözlemlenebilirlik bu aşamada standart hale getirilir.

Üçüncü aşamada, karar kalitesini ölçen değerlendirme seti geliştirilir. Gerçek kullanıcı sorunlarından türetilmiş, fakat güvenle anonimleştirilmiş örnekler kullanılır. Üretim olayları, yeni test örneği ve politika iyileştirme girdisi olur.

Son aşamada yayın kapıları risk seviyesine göre işletilir. Sınırlı dağıtım, canary gözlemi, geri alma ve olay sonrası öğrenme sürecin parçası haline gelir. Böylece test mimarisi statik bir kontrol listesi değil, sistem olgunlaştıkça gelişen bir güvence mekanizması olur.

Son söz

Agentik uygulamalarda güven, modelin etkileyici yanıtlar üretmesinden doğmaz. Sistem, belirsizlikte hangi sınırda durduğunu, hangi etkiyi neden oluşturduğunu ve hata halinde nasıl güvenli kaldığını gösterebildiğinde güvenilir olur.

Kanıt odaklı test mimarisi bunu mümkün kılar. Hızlı davranış testleri günlük geliştirmeyi korur. Sözleşme ve entegrasyon testleri sistem sınırlarını denetler. Değerlendirme, uçtan uca yolculuk, güvenlik ve dayanıklılık katmanları ise gerçek dünyadaki riski görünür kılar. Teknoloji liderleri için hedef, daha çok test değil, daha güçlü kararlar üreten bir kanıt zinciri kurmaktır.