Model Çağrısından Denetlenebilir İş Akışına

Üretim ortamında güvenilirlik yalnızca daha güçlü bir model seçmekle sağlanmaz. Planlama, araç kullanımı, doğrulama ve yanıt üretimi açık bir iş akışı olarak tasarlanmalıdır. Serbest biçimli bir agent yerine, sınırları belirlenmiş durumlar ve geçişler kullanmak hata ayıklamayı, yeniden çalıştırmayı ve denetimi kolaylaştırır.

Her çalıştırma için benzersiz bir run_id, her adım için de step_id üretin. Örnek durumlar , , , , ve olabilir. Durum geçişlerini kod içinde örtük bırakmak yerine açık bir durum makinesiyle tanımlayın; hangi hatanın akışı durdurduğu, hangisinin yeniden denendiği ve insan onayının nerede gerektiği görünür olsun.

Modelin doğrudan veritabanı, dosya sistemi veya ödeme servisi gibi kritik kaynaklara erişmesine izin vermek yerine, dar kapsamlı ve doğrulanmış araç sözleşmeleri kullanın. Tool katmanı kimlik doğrulama, yetki kontrolü, parametre doğrulama ve çıktı normalizasyonundan sorumlu olmalıdır.

Durum Yönetimi, Yeniden Deneme ve İdempotency

Bir tool çağrısı zaman aşımına uğradığında işlemin karşı tarafta gerçekleşip gerçekleşmediği bilinmeyebilir. Bu nedenle yan etki üreten her çağrıda idempotency anahtarı kullanın. Aynı mantıksal işlem için yeniden denemelerde anahtar değişmemeli ve servis, tekrar istekte güvenli biçimde aynı sonucu döndürmelidir. Anahtar; kullanıcı, iş akışı, kaynak ve işlem bağlamını taşımalı, ancak hassas bilgileri doğrudan içermemelidir.

Her hatayı yeniden denemek veri çoğaltılmasına ve maliyet artışına yol açar. Geçici ağ hataları, servis kullanılamaması ve oran sınırlamaları için üstel geri çekilme ve sınırlı deneme sayısı uygulanabilir. Geçersiz parametre, yetkisiz erişim, politika ihlali ve şema doğrulama hataları ise doğrudan başarısızlık ya da insan onayı gerektirmelidir.

• Tool şeması çağrıdan önce doğrulanmalı, bilinmeyen alanlar reddedilmelidir.
• Maksimum adım sayısı, toplam çalışma süresi ve token bütçesi belirlenmelidir.
• Yan etkili işlemler için

  dry_run

  veya açık onay durumu bulunmalıdır.
• Bozulmuş ya da beklenmeyen durumlar güvenli biçimde duraklatılmalı ve operatöre aktarılmalıdır.
• Kuyruk tüketicileri, zaman aşımı ve yeniden başlatma sonrasında aynı işi güvenle sürdürebilmelidir.

Gözlemlenebilirlik: Logların Ötesinde Karar İzleri

Bir agent yanıtı yanlış olduğunda yalnızca son metni saklamak kök nedeni açıklamaz. Kullanıcı isteği, akış sürümü, model sürümü, prompt sürümü, araç adı, girdinin güvenli özeti, sonuç durumu, gecikme, token tüketimi ve hata sınıfı ilişkilendirilebilir biçimde izlenmelidir. Hassas veriler loglara ham olarak yazılmamalı; maskeleme, alan bazlı redaksiyon, saklama süresi ve erişim kontrolü uygulanmalıdır.

Trace hiyerarşisini en az üç seviyede kurmak yararlıdır: kullanıcı isteği, agent çalıştırması ve tekil model veya tool çağrısı. Böylece toplam gecikmenin modelden, RAG sorgusundan, kuyruktan veya harici servisten kaynaklandığı ayrıştırılabilir.

Başarıyı yalnızca “yanıt üretildi” metriğiyle ölçmeyin. Aşağıdaki sinyalleri görev, model ve akış sürümü bazında izleyin:

• Geçerli şemayla tamamlanan çağrı oranı
• İnsan müdahalesine düşen akış oranı
• Tool timeout, hata ve yeniden deneme oranı
• Görev başına maliyet ile p50, p95 ve p99 gecikme değerleri
• Kullanıcı düzeltmesi, geri alma ve yeniden çalıştırma oranı
• RAG yanıtlarında kaynak bulunabilirliği ve alıntı doğrulama oranı

RAG ve Tool Calling İçin Güvenlik Sınırları

RAG çıktısı talimat değil, güvenilmeyen bağlam olarak ele alınmalıdır. Belgelerde bulunan “şu aracı çağır” benzeri ifadeler modelin yetkisini genişletmemelidir. Sistem talimatları, kullanıcı içeriği, alınan belgeler ve tool sonuçları ayrı katmanlarda tutulmalı; her katmanın güven seviyesi ve izinleri açıkça tanımlanmalıdır.

Tool izinlerini en dar kapsamla sınırlandırın. Bir araç yalnızca gerekli alanları okuyabilmeli, belirli kaynak türlerine erişebilmeli ve kritik işlemlerde kullanıcı onayı istemelidir. Sunucu tarafında yetki kontrolü yapılmadan modelin ürettiği kullanıcı kimliği, dosya yolu, sorgu filtresi veya URL güvenilir kabul edilmemelidir. SSRF için hedef allowlist'i, dosya erişimi için yol kısıtlaması, sorgular için kaynak ve satır sınırı uygulanmalıdır.

Prompt injection, veri sızıntısı, aşırı yetkilendirme, zehirli doküman ve kötü amaçlı tool çıktıları için olumsuz testler düzenli çalıştırılmalıdır. Modelin güvenlik kararını tek başına vermesine izin vermeyin; kritik kontrolleri deterministik sunucu kodunda gerçekleştirin.

Maliyet, Sürümleme ve Yayın Kontrolleri

Maliyeti azaltmanın ilk adımı her aşamada model kullanmamak ve bağlamı gereksiz büyütmemektir. Sınıflandırma ve yönlendirme için küçük modeller, belirsiz veya uzun planlama gerektiren adımlar için daha güçlü modeller seçilebilir. RAG sorgularında önbellekleme yapılacaksa anahtara kullanıcı yetkisi, tenant, sorgu normalizasyonu ve veri sürümü dahil edilmelidir; aksi halde bir kullanıcının sonucu başka kullanıcıya sızabilir.

Model, prompt, tool şeması, retrieval ayarları ve yönlendirme kuralları birlikte sürümlenmelidir. Değişiklikleri kademeli yayınlayın; hata oranı, maliyet, gecikme ve insan müdahalesi için geri dönüş eşikleri önceden tanımlansın. Sabit test kümelerine ek olarak, anonimleştirilmiş gerçek başarısız örneklerden oluşan regresyon seti ve araç sözleşmesi testleri tutulmalıdır.

İyi bir agent mimarisi etkileyici bir demodan çok; durabildiği, güvenle tekrar çalıştırılabildiği, neden başarısız olduğunu gösterebildiği ve yetkisini aşamadığı zaman değerlidir. Tasarım incelemesine model seçimiyle değil, durum makinesi, hata sınıfları, gözlem sinyalleri, maliyet sınırları ve güvenlik kontrolleriyle başlamak üretim riskini belirgin biçimde azaltır.