--- title: "Finansal Ajanınız Tüm Testleri Geçti. Peki Kararını Savunabilir misiniz?" url: https://blog.edumints.com/finansal-ajaniniz-tum-testleri-gecti-peki-kararini-savunabilir-misiniz category: "AI Araçları" date: 2026-10-19T07:07:45.841Z publisher: Edumints Blog lang: tr-TR source_name: "dev.to" source_url: https://dev.to/dailycontext/your-financial-agent-passed-every-eval-can-you-defend-its-decision-1npg --- # Finansal Ajanınız Tüm Testleri Geçti. Peki Kararını Savunabilir misiniz? Denetim süreçlerinde asıl ürün ortaya çıkan görüştür ve bir görüş ancak dayandığı temel kadar güçlüdür. Yapay zeka ajanları geliştirirken sadece doğru sonuca ulaşmak yetmez; o sonucun arkasındaki karar alma sürecini de şeffafça gösterebilmeniz gerekir. Peki, otonom ajanlarda savunulabilir karar alma süreci nasıl inşa edilir? ## Bir Ajan İnşa Edelim Finansal denetim senaryosunda özellikle yüksek hacimli ve yorucu bir iş olan banka mutabakatı testini ele alalım. Şirketler kendi defterlerindeki nakit bakiyesini banka kayıtlarıyla karşılaştırır ve aradaki farkların yoldaki mevduatlar veya tahsil edilmemiş çekler gibi kalemlerle açıklanması beklenir. Bu yapı, bir yapay zeka ajanı için harika bir kullanım alanıdır. Süreci otomatikleştirmek için ajana müşterinin kayıtlarını, mutabakat belgelerini ve banka kanıtlarını veririz. Prompt içine denetim metodolojisini ekler ve geçmiş yıl denetimlerini örnek olarak sunarız. Son olarak, daha önce incelenmiş denetimlerden bir değerlendirme (eval) seti oluşturur ve süreç tamamlanmadan önce bir insanın onayını (human-in-the-loop) şart koşarız. Metrikler harika görünür, kullanıcılar memnundur ve sistemi canlıya alırız. Ancak denetim incelemeye seçildiğinde bir uzman şu soruyu sorar: **"Bu kanıt neden yeterli kabul edildi?"** İncelemeyi yapan kişi genel değerlendirme metrikleriyle veya kullanıcı memnuniyetiyle ilgilenmez. Sadece o spesifik denetimde, o spesifik kararın neden alındığını bilmek ister. ## Savunulabilirlik İçin Dört Kontrol Denetim standartlarında savunulabilir bir yanıt, "işe yabancı deneyimli bir denetçinin süreci takip edebilmesi" olarak tanımlanır. Yazılım geliştirme perspektifinden bunu **"ajanı takip edebilmek"** şeklinde çevirebilir ve dört temel kontrol mekanizmasıyla uygulayabiliriz. Ayrıca, her zaman ajanın durduğu ve son kararı bir insanın verdiği net bir sınır çizgisi bulunmalıdır: - **Yetkilendirme (Authorization):** Bir denetçi tedarikçi listesinde olmayan bir alıcıya kesilmiş 62.500 dolarlık çeki işaretler ve incelenip onaylanır. Birkaç gün sonra yeni hesap özetleri gelir, ajan tetiklenir ve o satırı "istisna yok" olarak günceller. Artık onay imzası, kimsenin incelemediği bir yanıtı doğrulamaktadır. Ajanın kimliği veri yazmaya yetkili olsa bile, onaylanmış bir satırı değiştirmesine izin verilmemelidir. Pratik çıkarım: Yetkilendirme sadece "bu kimlik bu aracı (tool) çağırabilir mi?" demek değildir; bu eylemin, **bu nesne üzerinde, bu durumdayken (state) ve şu anda** yapılabilir olup olmadığını kontrol etmektir. - **Yürütme Kontrolü (Execution Control):** Ajan 96.400 dolarlık bir çekin tahsil edildiğini söyler. Denetçi işi yeniden çalıştırdığında sonuç 69.400 dolar çıkar. Standart loglar işin çalıştığını gösterir ancak tek bir kararı yeniden incelemenize izin vermez. Bunun yerine, iş akışını adımlara (veri çekme, çıkarma, eşleştirme, sonuçlandırma) bölün ve her adımın girdilerini, çıktılarını ve model versiyonunu sabit bir ID altında kaydedin. Böylece tartışmalı adımı tam olarak aynı girdilerle yeniden çalıştırabilirsiniz. Amaç hangi çalışmanın doğru olduğunu bulmak değil, sonucun neden öyle çıktığını kesin olarak bilmektir. - **Kanıt Kökeni (Evidence Provenance):** Ajan 61.900 dolarlık bir mevduat için "Ocak banka hesap özeti"ni kaynak gösterir. Bu bilginin yanlış olduğu ortaya çıktığında kaynağın nereden geldiğini bulmak zorlaşır; çünkü birçok belge aynı adı taşıyabilir veya zamanla değişebilir. Geliştirici olarak her alıntıyı modelin ürettiği metne değil, sabit bir kimliğe (belge ID'si, versiyon ve özet/hash değeri) bağlayın. Ardından, iddianın dayandığı kanıt niteliklerinin (örneğin güncellik veya ilgililik) gerçekten eşleştiğini kod seviyesinde zorunlu kılın. - **Değerlendirme Bütünlüğü (Evaluation Integrity):** Değerlendirme (eval) sistemimize ne kadar güvenebiliriz? Çoğu zaman eval setleri mutlak doğrular (ground truth) yerine geçen yılın sonuçları üzerine kurulur. Ajanın aslında haklı olduğu ancak geçmiş verideki etiketin yanlış olduğu durumlar (kaçırılan hatalar) yaşanabilir. Bu nedenle, test veri setlerinizin kalitesini sürekli sorgulamak ve tarihsel önyargıları doğrulamaktan kaçınmak kritik bir mühendislik pratiğidir. --- Bu konuyu derinlemesine öğrenmek isterseniz: [Production'da Agent Güvenilirliği](https://edumints.com/kesfet/production-agent-orchestration-crewai-ve-autogen-i-u3cu) modülüne göz atın. --- **Kaynak:** dev.to (https://dev.to/dailycontext/your-financial-agent-passed-every-eval-can-you-defend-its-decision-1npg) **Yayıncı:** [Edumints Blog](https://blog.edumints.com) · Alıntılarken bu URL'ye bağlantı verin: https://blog.edumints.com/finansal-ajaniniz-tum-testleri-gecti-peki-kararini-savunabilir-misiniz