Yapay Zekânın Yaptığı İşi Nasıl Kontrol Ederiz? 5 Katmanlı Doğrulama Sistemi

Bir yapay zekâ size “iş tamamlandı” dediğinde, gerçekten ne biliyorsunuz?

Dosyanın oluşturulduğunu biliyor olabilirsiniz. Modelin yaptığı işi beğendiğini de biliyorsunuz. Fakat doğru dosyayı değiştirdiğini, kaynakları uydurmadığını, başka bir özelliği bozmadığını veya gönder tuşuna basıldığında yanlış kişiye mesaj gitmeyeceğini henüz bilmiyorsunuz.

Bir önceki yazıda kendi eval sistemimizi kurmayı öğrendik. Eval bize hangi model ve çalışma biçiminin gerçek görevlerimizde daha güvenilir olduğunu gösteriyordu. Şimdi bir adım daha ileri gideceğiz: Tek bir işi teslim alırken doğruluğu nasıl kanıtlayacağımızı birlikte kuracağız.

Bu yazıda acele etmeyeceğiz. Önce doğrulamanın neden ayrı bir sistem olması gerektiğini anlayacağız. Ardından beş katmanı tek tek kuracak, içerik üretimi, yazılım geliştirme ve müşteri iletişimi gibi gerçek örneklere uygulayacağız. Son bölümde de kendi işiniz için kullanabileceğiniz bir doğrulama sözleşmesi hazırlayacağız.

Yapay zekâya güvenmek, söylediği her şeyi doğru kabul etmek değildir. Ona yaptığı işi kanıtlayabileceği bir çalışma ortamı vermektir.

Üretim kolaylaştı, teslim almak zorlaştı

Eskiden bir işin büyük bölümü üretime gidiyordu. Yazıyı yazmak, kodu oluşturmak, veriyi sınıflandırmak veya uzun bir raporu özetlemek saatler sürüyordu. Kontrol aşaması da üretimin doğal bir parçasıydı; işi yapan kişi süreç boyunca ayrıntıları gördüğü için nerelere bakması gerektiğini biliyordu.

Yapay zekâ bu dengeyi değiştirdi. Model birkaç dakika içinde onlarca dosyayı değiştirebilir, yüzlerce satır kod yazabilir veya binlerce kelimelik bir rapor hazırlayabilir. Üretimin hızlanması güzel haber. Fakat insan artık sonucun nasıl oluştuğunu adım adım görmediği için kontrolün maliyeti büyüyor.

Burada iki farklı boşluk ortaya çıkıyor:

• Tanım boşluğu: Biz ne istediğimizi eksik anlattığımız için model yanlış işi doğru biçimde yapabilir.
• Kanıt boşluğu: Model doğru işi yapmış olabilir ama bunu gösterecek ölçüm veya test bulunmayabilir.

İlk boşluğu intent engineering ile küçültürüz: Neden bu işi yaptığımızı, iyi sonucun neye benzediğini ve kırmızı çizgileri açıklarız. İkinci boşluk ise doğrulama sistemi gerektirir.

Yazılım mühendisliğinde sık kullanılan iki kavram burada bize yardımcı olur:

• Verification: İşi tanımladığımız kurallara uygun yaptık mı?
• Validation: En başta doğru işi mi tanımladık; ortaya çıkan sonuç gerçek ihtiyacı çözüyor mu?

Bir form bütün testleri geçebilir ama kullanıcı formu tamamlayamıyorsa teknik olarak doğrulanmış, gerçek hayatta geçersiz bir iş üretmiş oluruz. Bu nedenle iyi bir sistem yalnızca dosyalara veya puanlara değil, sonucun kullanıldığı gerçek ortama da bakmalıdır.

Doğrulama neden katmanlı olmalı?

Tek bir kontrol yöntemi her hata türünü yakalayamaz. Testler, yalnızca yazdığımız beklentileri kontrol eder. İkinci bir model, yazılı olmayan çelişkileri fark edebilir ama o da ikna edici biçimde yanılabilir. İnsan güçlü bir genel değerlendirme yapabilir fakat yorgunluk, dikkat ve zaman sınırları vardır.

Bu yüzden doğrulamayı havaalanı güvenliği gibi düşünmek daha doğru. Kimlik kontrolü, bagaj taraması ve kapı kontrolü aynı işi tekrar etmiyor; farklı hata ve risk sınıflarını yakalıyor. Yapay zekâ çıktısında da birbirinden bağımsız savunma katmanları kurmak istiyoruz.

Güvenilir teslim =
net başarı tanımı
× zorunlu koşullar
× deterministik kontroller
× bağımsız denetim
× gerçek ortam kanıtı
× riske uygun insan kararı

Buradaki çarpma işareti bilinçli. Katmanlardan biri tamamen yoksa diğerlerinin yüksek kalitesi her zaman yeterli olmaz. Kaynakları uyduran bir yazının çok iyi görünmesi onu güvenilir yapmaz. Bütün testleri geçen bir ödeme akışının iki kez para çekmesi de kabul edilemez.

Katmanlardan önce: Bitti tanımını yazın

Kontrole başlamadan önce işin hangi durumda biteceğini tanımlamalıyız. Aksi hâlde ajan yaptığı ilk makul çıktıyı tamamlanmış iş sanabilir, denetçi de ne arayacağını bilemez.

Bitti tanımı, ayrıntılı bir uygulama tarifi değildir. Modele her adımı dikte etmek yerine hedefi, ölçülebilir sonucu ve sınırları verir. Şu beş soruyla başlayabilirsiniz:

1. Ortaya çıkması gereken somut çıktı nedir?
2. Bu çıktıyı kim ve hangi amaçla kullanacak?
3. Mutlaka doğru olması gereken üç şey nedir?
4. Asla gerçekleşmemesi gereken şey nedir?
5. İşin bittiğini hangi kanıtlarla anlayacağız?

Örneğin “Blog yazısını hazırla” belirsizdir. Daha iyi bir bitti tanımı şöyle olabilir:

Çıktı:
Yeni başlayanlara kişisel AI eval sistemini öğreten
Türkçe bir blog yazısı.

Başarı:
- Okuyucu bir saat içinde ilk evalini kurabilmeli.
- İddialar kaynaklarla uyumlu olmalı.
- İç bağlantılar çalışmalı.
- Okuma süresi gerçek kelime sayısından hesaplanmalı.

Kırmızı çizgi:
Kaynakta olmayan deneyim veya sayı yazılmamalı.

Kanıt:
Kaynak kontrolü + link kontrolü + render incelemesi
+ bağımsız editoryal değerlendirme.

Şimdi bu sözleşmeyi beş doğrulama katmanından geçirebiliriz.

1. katman: Zorunlu koşullar ve biçim kapısı

İlk katman en basit soruyu sorar: Çıktı beklediğimiz biçimde ve eksiksiz mi?

Burada kaliteyi tartışmıyoruz. Önce işin teslim alınabilecek bir yapıda olup olmadığına bakıyoruz. Bir formun zorunlu alanları, bir API cevabının şeması veya bir yazının kaynak bölümü bu katmana girer.

İçerik görevi için zorunlu kapılar şunlar olabilir:

• Başlık, açıklama ve gövde mevcut.
• Metin istenen dilde.
• Kelime sayısı belirlenen aralıkta.
• Bütün dış kaynaklarda adres ve açıklama var.
• Yasaklanan ifadeler veya hassas bilgiler bulunmuyor.

Bir müşteri kayıt görevi için ise:

• E-posta adresi geçerli biçimde.
• Aynı müşteri ikinci kez oluşturulmuyor.
• Zorunlu izin alanı boş değil.
• Para birimi ve tarih biçimi doğru.
• Gönderilecek veride dahili not bulunmuyor.

Bu kontroller mümkün olduğunca ikili sonuç vermelidir: geçti veya kaldı. Modelden “Sence bütün alanlar tamam mı?” diye yorum istemek yerine sistem alanların gerçekten varlığını kontrol etmelidir.

İlk katman kaliteyi garanti etmez; fakat eksik ve biçimsiz işlerin daha pahalı kontrol aşamalarına geçmesini önler.

2. katman: Deterministik testler

İkinci katmanda sonucu yoruma ihtiyaç duymayan kontrollerle sınarız. Aynı girdi her çalıştırıldığında aynı sonucu veren bu kontroller, doğrulama sisteminin en güvenilir parçalarıdır.

Yazılım görevinde bunlar oldukça tanıdıktır:

• Unit ve integration testleri
• Type-check ve lint
• Build işlemi
• Şema ve migrasyon kontrolleri
• Güvenlik ve bağımlılık taramaları
• Değişmemesi gereken dosyaların diff kontrolü

Fakat deterministik kontrol yalnızca kod için kullanılmaz. Bir içerikte bütün bağlantılara istek atıp çalışıp çalışmadığını kontrol edebilir, okuma süresini kelime sayısından hesaplayabilir, yinelenen başlıkları bulabilir ve HTML yapısının geçerli olduğunu sınayabilirsiniz. Bir tabloda toplamların eşitliğini, boş hücreleri ve beklenmeyen değerleri otomatik kontrol edebilirsiniz.

Burada size önemli bir ayrım göstereyim:

Zayıf kontrol:
“Yazıdaki bağlantıları kontrol et.”

Güçlü kontrol:
“Bütün dış bağlantılara HEAD veya GET isteği gönder.
HTTP durumlarını kaydet. 4xx/5xx dönen bağlantı varsa
işi başarısız say ve rapora adresi ekle.”

İkinci tarif modelin iyi niyetine değil, görülebilir bir kanıta dayanır. İyi doğrulama sistemi “kontrol ettim” cümlesini değil, kontrolün çıktısını saklar.

3. katman: Bağımsız yapay zekâ denetçisi

Her kalite ölçütünü kodla ifade edemeyiz. Bir açıklamanın gerçekten anlaşılır olup olmadığı, bir çözümün gereksiz karmaşıklığı veya bir metnin kaynakla çelişen ince bir çıkarım yapması yorum gerektirir. Burada bağımsız bir model denetçisinden yararlanabiliriz.

Bağımsız kelimesi önemli. Üretici model aynı konuşma içinde kendi işini kontrol ettiğinde önceki kararlarını savunmaya yatkın olabilir. Bu psikolojik bir inat değil; bağlamında çözümün neden seçildiğine dair güçlü bir hikâye bulunmasından kaynaklanır. Denetçi temiz bir oturumda yalnızca görev sözleşmesini, çıktıyı ve kanıtları görmelidir.

Denetçiye “Bir hata var mı?” demek de yeterli değildir. Ona rolünü, ölçütlerini ve beklenen rapor biçimini verin:

Rol:
Bu işi üretmedin. Amacın onay vermek değil,
teslim koşullarını ihlal eden noktaları bulmak.

Kontrol et:
1. Her iddia verilen kaynakta destekleniyor mu?
2. Sonuç hedef kitlenin seviyesine uygun mu?
3. Zorunlu koşullardan biri görünürde geçip özünde kalıyor mu?
4. Hangi iddia için yeterli kanıt yok?

Çıktı:
- Geçti / kaldı
- Bulgular ve kanıtları
- Güven düzeyi
- İnsan kararı gereken belirsizlikler

Mümkünse üretici ve denetçide farklı modeller kullanın. Aynı model ailesi benzer kör noktalara sahip olabilir. Farklı bir model aynı işi başka bir düşünme biçimiyle inceleyebilir.

Ancak burada yeni bir hata yapmayalım: İki modelin aynı fikirde olması gerçeğin kanıtı değildir. Denetçi bir bulgu üretir; önemli bulgu mümkünse kaynak, test veya gerçek ortam gözlemiyle doğrulanır.

4. katman: Gerçek ortam ve senaryo testi

Dördüncü katmanda dosyalardan çıkıp işin kullanılacağı ortama geçiyoruz. Çünkü doğru görünen çıktı gerçek kullanıcıyla karşılaşınca farklı davranabilir.

Bir arayüz geliştirdiyseniz yalnızca kodu okumayın. Uygulamayı açın, formu doldurun, mobil ekranda görün, klavyeyle gezinin ve hata durumunu tetikleyin. Bir içerik yayımladıysanız sayfayı render edin; koyu temada, küçük ekranda, tablo ve kod bloklarıyla birlikte okuyun. Bir otomasyon hazırladıysanız gerçek veri göndermeden önce dry-run yapın ve hangi dış işlemlerin oluşacağını görün.

Gerçek ortam testini üç tür senaryoyla kurabilirsiniz:

1. Mutlu yol: Her şey beklendiği gibi olduğunda görev tamamlanıyor mu?
2. Sınır durumu: Boş veri, uzun metin, Türkçe karakter veya yavaş bağlantıda ne oluyor?
3. Başarısızlık yolu: Servis cevap vermezse, yetki biterse veya işlem yarıda kalırsa güvenli duruyor mu?

Bu katman validation sorusuna yaklaşır: Yalnızca kurallara uygun bir çıktı mı ürettik, yoksa gerçek ihtiyacı gerçekten çözen bir sonuç mu?

5. katman: Riske göre insan onayı

Son katmanda insanı her işin üzerine geri koymak istemiyoruz. Bunu yaparsak otomasyonun bütün hızını kaybederiz. İnsan onayını yalnızca geri dönüşü zor, belirsiz veya yüksek etkili kararlarda kullanmalıyız.

Şu eylemler çoğunlukla insan kapısı gerektirir:

• Para gönderme veya ücretli satın alma
• Müşteriye, geniş kitleye ya da kamuya mesaj gönderme
• Üretim verisini silme veya geri dönüşü zor biçimde değiştirme
• Yeni erişim yetkisi verme
• Hukuki, sağlık veya güvenlik etkisi taşıyan karar verme
• Doğrulama katmanlarının çeliştiği belirsiz durumlar

İnsana yalnızca “Onaylıyor musun?” sorusunu göndermek iyi bir onay mekanizması değildir. Karar verebilmesi için kısa ve kanıtlı bir paket hazırlayın:

İnsan onay paketi:
- Ne yapılacak?
- Neden yapılacak?
- Hangi kontroller geçti?
- Hangi belirsizlik kaldı?
- Dış dünyada ne değişecek?
- Geri alma yolu nedir?

İnsan bu paketle modelin bütün çalışmasını baştan okumak zorunda kalmadan sorumluluk taşıyan son kararı verebilir.

Gerçek uygulama 1: Bir blog yazısını teslim almak

Şimdi beş katmanı gerçek bir işe uygulayalım. Görevimiz, üç kaynaktan yararlanarak yeni başlayanlara yapay zekâ ajanlarını anlatan bir blog yazısı hazırlamak olsun.

Bu sistemde yapay zekâ yalnızca yazıyı üretmez. Kaynakları toplar, ilk taslağı hazırlar, kontrolleri çalıştırır, denetçi bulgularını düzeltir ve editör için bir yayımlama paketi oluşturur. İnsan bütün virgülleri düzeltmek yerine ana fikrin doğru ve yayımlanmaya değer olup olmadığına odaklanır.

Gerçek uygulama 2: Bir yazılım değişikliğini teslim almak

İkinci örnekte ajanımız bir giriş formuna telefon numarası alanı eklesin.

Bitti tanımımız yalnızca “alan ekranda görünsün” olursa ajan görsel olarak doğru ama veriyi kaydetmeyen bir form üretebilir. Bu yüzden sözleşmeyi genişletiriz:

• Alan doğru sayfada ve erişilebilir etikete sahip olmalı.
• Türkiye numaraları kabul edilmeli, geçersiz değerler açıklanmalı.
• Veri API’ye ve veritabanına doğru biçimde ulaşmalı.
• Mevcut kayıt ve giriş akışı bozulmamalı.
• Loglarda telefon numarası açık biçimde görünmemeli.

Ardından katmanları uygularız:

1. Diff beklenen dosyalarla sınırlı mı?
2. Type-check, test ve build geçiyor mu?
3. Bağımsız denetçi güvenlik, veri akışı ve gereksiz karmaşıklığı inceliyor mu?
4. Ajan tarayıcıda formu gerçekten doldurup geçerli ve geçersiz senaryoları deniyor mu?
5. Veri şeması değişiyorsa migration ve rollback insan tarafından onaylanıyor mu?

Burada ekran görüntüsü tek başına yeterli kanıt değildir. Arayüz doğru görünürken API bozuk olabilir. Test sonucu da tek başına yeterli değildir; test etmediğimiz mobil yerleşim bozulmuş olabilir. Katmanlar tam olarak bu nedenle birbirini tamamlar.

Gerçek uygulama 3: Müşteriye mesaj göndermek

Üçüncü örnek koddan daha basit görünür ama dış dünyadaki etkisi daha yüksektir. Bir ajan destek talebini okuyup müşteriye cevap hazırlayacak olsun.

İlk aşamada ajana gönderme yetkisi vermeyiz. Yalnızca taslak oluşturur. Zorunlu koşullar müşteri adı, talep konusu ve yasaklı hassas bilgileri kontrol eder. Bağımsız denetçi tonun uygunluğunu, verilen sözlerin şirket politikasıyla uyumunu ve talebin gerçekten cevaplanıp cevaplanmadığını inceler.

Gerçek ortam katmanında mesajın hangi adrese, hangi konu satırıyla ve hangi eklerle gönderileceğini gösteren bir dry-run oluştururuz. İnsan son paketi görüp gönderme kararını verir.

Sistem zamanla güven kazandığında düşük riskli kategoriler otomatik gönderilebilir. Para iadesi, hukuki tehdit, kişisel veri veya öfkeli müşteri gibi kategoriler ise kalıcı olarak insan onayında kalır. Yetkiyi bir anda değil, kanıtlanan güvenilirliğe göre genişletmiş oluruz.

Her işte beş katmanı aynı ağırlıkta kullanmayın

Doğrulama faydalıdır ama ücretsiz değildir. Her sosyal medya taslağını beş model ve üç insanla incelemek işi gereksiz yere yavaşlatır. Sistemi görevin riskine göre ayarlamalıyız.

Burada kendinize iki soru sorun: Hata olursa geri alabilir miyim ve hatayı ne kadar hızlı fark ederim? Geri dönüş zor, fark edilme süresi uzunsa kontrolü derinleştirin.

En sık yapılan doğrulama hataları

Üreticiye “kendini kontrol et” demek

Öz kontrol yararlıdır ama tek savunma olamaz. Üretici modelin gözden kaçırdığı varsayımları temiz bağlamdaki bağımsız denetçi daha kolay görebilir.

“Her şeyi kontrol et” gibi belirsiz görev vermek

Denetçi neyin önemli olduğunu bilmezse yüzeysel bir özet üretir. Başarı ölçütlerini, riskleri ve beklenen kanıt biçimini açıkça verin.

Model görüşünü kanıt sanmak

Model “bağlantılar çalışıyor” diyorsa bağlantıların HTTP sonuçlarını isteyin. “Testler geçti” diyorsa komut çıktısını saklayın. İddia ile kanıtı ayırın.

Yalnızca mutlu yolu denemek

Gerçek sistemler boş veri, zaman aşımı, tekrar eden olay ve yarıda kalan işlemle karşılaşır. En az bir sınır ve bir başarısızlık senaryosu ekleyin.

Sonsuz düzeltme döngüsü kurmak

Denetçi her turda yeni bir küçük sorun bulabilir. Yeniden deneme sınırı koyun. İki veya üç turdan sonra hâlâ zorunlu koşul geçmiyorsa işi insana devredin ya da yaklaşımı temiz bağlamla yeniden kurun.

Her işi yüksek riskli saymak

Aşırı kontrol de sistemi kullanılmaz hâle getirir. Geri döndürülebilir taslaklarla para veya veri kaybı yaratabilecek işlemleri aynı süreçten geçirmeyin.

Doğrulama döngüsünü nasıl tasarlarız?

Katmanları tek seferlik kontrol listesi olmaktan çıkarıp çalışma döngüsüne dönüştürelim:

1. Üret
2. Zorunlu kapıları kontrol et
3. Deterministik testleri çalıştır
4. Bağımsız denetçiye gönder
5. Gerçek ortam senaryosunu çalıştır
6. Bulguları düzelt
7. En fazla iki kez yeniden doğrula
8. Geçerse teslim et, kalırsa insana devret

Her turda yalnızca sonucun değil, kanıtların da güncellenmesi gerekir. Ajan eski test çıktısını yeni değişikliğin kanıtı olarak kullanmamalıdır. Değişiklik yapıldıysa ilgili kontroller yeniden çalışmalıdır.

Bu döngünün durumlarını açık tutmak da önemlidir:

draft → verifying → needs_fix → verifying
                         ↓
             approved veya escalated

Böylece ajan saatlerce çalışsa bile hangi aşamada olduğunu, neden durduğunu ve insanın neye karar vermesi gerektiğini görebiliriz.

Uygulama: Kendi doğrulama sözleşmenizi hazırlayın

Şimdi bu yazıyı yalnızca okumakla bırakmayalım. Düzenli yaptığınız tek bir işi seçin ve aşağıdaki şablonu doldurun:

Görev:
[Modelin tamamlayacağı tek ve somut iş]

Kullanıcı ve ihtiyaç:
[Çıktıyı kim, neden kullanacak?]

Bitti tanımı:
[İş hangi durumda tamamlanmış sayılacak?]

Zorunlu koşullar:
- [Geçti/kaldı biçiminde ölçülebilen koşul]
- [...]

Deterministik kontroller:
- [Çalıştırılacak test, komut veya hesap]
- [...]

Bağımsız denetçi:
- [İnceleyeceği kalite ve risk ölçütleri]

Gerçek ortam senaryoları:
- Mutlu yol:
- Sınır durumu:
- Başarısızlık yolu:

İnsan onayı gereken durumlar:
- [Geri dönüşü zor eylem veya belirsizlik]

Kanıt paketi:
- [Saklanacak rapor, ekran görüntüsü, diff veya log]

Yeniden deneme ve devretme:
- En fazla [N] düzeltme turu
- Sonrasında [kişiye/sisteme] devret

İlk sözleşmeniz uzun olmak zorunda değil. Bir sayfalık net bir belge, konuşma içinde kaybolan onlarca talimattan daha değerlidir. Sistemi gerçek işte kullandıkça yeni hata türlerini görecek ve sözleşmeyi geliştireceksiniz.

Doğrulamanın asıl amacı hata avlamak değil

Bu kadar kontrol konuşunca yapay zekâya sürekli şüpheyle yaklaşmamız gerektiği düşünülebilir. Benim çıkardığım sonuç bunun tam tersi. İyi doğrulama sistemi modele daha fazla alan açmamızı sağlar.

Geri alma mekanizması, testleri ve insan kapıları olmayan bir ajana doğal olarak küçük işler veririz. Çünkü yanlış yaptığında ne olacağını bilemeyiz. Kanıt üreten ve güvenli biçimde duran bir ajan ise daha uzun süre çalışabilir, daha fazla araç kullanabilir ve bizi sürekli yanında beklemek zorunda bırakmaz.

Kontrol, otonominin karşıtı değildir. Güvenli otonominin altyapısıdır.

Bir sonraki işinizde modelden yalnızca sonucu istemeyin. Daha işe başlamadan şu soruyu ekleyin: “Bu işi doğru yaptığını bana hangi kanıtlarla göstereceksin?”

Bu soru çalışma biçiminizi yavaş yavaş değiştirecek. Model cevap üreten bir araç olmaktan çıkıp hedefi, sınırları ve teslim koşulları olan bir çalışma sisteminin parçasına dönüşecek. Bizim asıl kurmaya çalıştığımız şey de tam olarak bu.

Kaynaklar

• Anthropic — Building effective agents
• NIST — AI Risk Management Framework
• OWASP GenAI Security Project — LLM Top 10