– AWS, Automated Reasoning bulgularını kullanıp yanıtı tekrar tekrar yeniden yazan ve gerektiğinde açıklayıcı soru soran açık kaynak bir chatbot örneği paylaştı.
– Sistem, Soru-Yanıt çiftini ApplyGuardrail API ile doğruluyor; VALID/INVALID gibi statüler ve yeniden yazım geri bildirimi üretiyor.
– Her iterasyonda bulgular ve prompt’lar saklanarak matematiksel olarak denetlenebilir bir audit trail oluşturuluyor.
Excerpt:
AWS’nin referans chatbot’u, LLM yanıtlarını Automated Reasoning ile “ispatlayıp” bulgulara göre yeniden yazıyor; üstelik audit log üretiyor.
Meta Description:
AWS, Automated Reasoning kontrolleriyle LLM yanıtlarını yinelemeli biçimde yeniden yazan bir referans chatbot yayınladı; denetlenebilir audit trail sunuyor.
Yazı:
Giriş
LLM’lerin en pahalı kusuru “yanlış ama ikna edici” olmaları değil; yanlışın nereden çıktığını kanıtlayamamak. AWS’nin paylaştığı referans uygulama, yanıt üretimini bir adım geri çekip “doğrulama bulguları” ile yeniden yazım döngüsüne çevirerek bu boşluğu hedefliyor.
🧩 Ne oldu?
– AWS Machine Learning Blog’da Stefano Buliani imzalı (9 Şubat 2026) yazıda, Automated Reasoning geri bildirimiyle yanıtı iteratif biçimde yeniden yazan açık kaynak bir chatbot referans uygulaması duyuruldu.
– Soru girildikten sonra sistem Amazon Bedrock üzerinden bir LLM’den ilk yanıtı alıyor; ardından ApplyGuardrail API ile Soru-Yanıt çiftini doğruluyor ve “findings” listesi döndürüyor.
– Bulgular VALID, INVALID, SATISFIABLE, TRANSLATION_AMBIGUOUS, IMPOSSIBLE gibi durumlarla geliyor; yeniden yazım döngüsünde öncelik sırası TRANSLATION_AMBIGUOUS → IMPOSSIBLE → INVALID → SATISFIABLE → VALID ve “diğerleri çözülmeden” VALID’e geçilmiyor.
🎯 Neden önemli?
LLM güvenliği uzun süredir “filtrele ve um” yaklaşımına sıkışıyor: zararlı içerik, PII, jailbreak vb. Buradaki iddia daha sert bir yere temas ediyor: Doğruluk, sınıflandırma skoru değil; mantıksal çıkarım ve matematiksel ispatla ele alınabilecek bir şey. Yani “yüksek ihtimalle doğru” yerine “kanıtlanabilir şekilde tutarlı/uyumlu” hedefi.
İkinci kritik nokta denetlenebilirlik. Uygulama, her iterasyonda bulguları ve LLM’e giden prompt’ları thread verisinde tutarak audit trail üretiyor. Bu, üretim ortamında “neden böyle dedi?” sorusunu sadece model açıklamasıyla değil, adım adım karar kaydıyla yanıtlamaya yaklaşır.
Üçüncüsü, kullanıcı deneyimi: sistem yalnızca yeniden yazmıyor, gerektiğinde açıklayıcı soru sorabiliyor. Bu pratikte şu demek: doğrulama, modeli susturmak yerine belirsizliği görünür kılıp spesifik bilgi talep eden bir diyalog tasarımına dönüşüyor.
👥 Kim etkilenir?
– Regülasyon baskısı yüksek sektörler: finans, sigorta, sağlık, kamu
– Kurumsal müşteri destek/IT helpdesk ekipleri (yanlış yönlendirme maliyeti yüksek olanlar)
– LLM ürün ekipleri: “guardrail + audit” mimarisi kurmak isteyenler
– Uyum ve risk ekipleri: denetlenebilir kayıt (audit trail) gerektiren süreçler
– Açık kaynak referans uygulamadan hızla PoC çıkarmak isteyen startup’lar
AI Sözlük görüşü
Buradaki asıl yenilik, “cevabı üret → filtreden geçir” düzenini tersine çevirmesi değil; doğrulamayı bir son kapı olarak değil, bir editör gibi konumlandırması. LLM ilk taslağı yazar; Automated Reasoning ise hangi cümlelerin mantıksal olarak sorunlu olduğunu bulgularla işaretler; model ikinci taslağı bu işaretlere göre düzeltir. Bu, yazım editörlüğünün otomasyonu gibi: amaç yaratıcı metin değil, hataya dayanıklılık.
Risk/ödül dengesi net: Ödül tarafında denetlenebilirlik ve sistematik hata azaltma var; özellikle “TRANSLATION_AMBIGUOUS” gibi belirsizlikleri erken yakalamak, yanlış kesinlik üretimini törpüler. Risk tarafında ise gecikme ve maliyet: her iterasyon ek LLM çağrısı ve ek doğrulama demek; ayrıca yanlış yapılandırılmış politikalar, doğru yanıtları bile “IMPOSSIBLE/INVALID”a sürükleyip kullanıcı deneyimini bozabilir.
Tasarım tercihi dersi: “Daha büyük model” yerine “daha sıkı döngü” bazen daha iyi üründür. Yani doğruluğu model boyutuyla satın almak yerine, küçük/orta bir modeli doğrulama-geri bildirim döngüsüyle disipline etmek; maliyet, hız ve uyum üçgeninde daha kontrol edilebilir bir mimari verebilir. Bu yaklaşım, güveni metinden değil süreçten üretir.
👀 Ne izlenmeli?
– İterasyon sayısı dağılımı: Ortalama kaç yeniden yazımda VALID’e ulaşılıyor? (p50/p95 iterasyon)
– Bulguların oranı: TRANSLATION_AMBIGUOUS ve IMPOSSIBLE yüzdesi zamanla düşüyor mu, yoksa prompt/politika tasarımı belirsizlik üretiyor mu?
– Maliyet ve doğruluk birlikte: “VALID’e ulaşma maliyeti” (token + doğrulama çağrısı) / “iş sonucu doğruluğu” (ör. case resolution accuracy) oranı
– Hata türü kırılımı: INVALID’den VALID’e geçişlerde hangi sınıflar düzeliyor; hangi alanlar sürekli takılıyor? (domain bazlı failure mode analizi)
