Agent Akışını Dağıtık Bir Sistem Olarak Modelleyin

Üretimdeki bir agent yalnızca model yanıtı üreten bir bileşen değildir. Planlama, model çağrıları, retrieval, tool calling ve dış sistemlerdeki yan etkilerden oluşan dağıtık bir iş akışıdır. Bu nedenle “yanıt döndü” metriği tek başına başarıyı göstermez. Geçerli bir yanıt üretirken yanlış kayıt oluşturmak veya yetkisiz belge kullanmak sistem açısından başarısızlıktır.

İlk adım, akışı açık durumlara ayırmaktır: planlandı, doğrulanıyor, tool çalıştırılıyor, insan onayı bekleniyor, tamamlandı ve başarısız. Her geçiş için zaman aşımı, yeniden deneme politikası ve güvenli durma davranışı tanımlanmalıdır. Modelin serbestçe sonsuz adım üretmesine izin vermek yerine maksimum adım, süre, token ve maliyet bütçeleri orkestratör tarafından uygulanmalıdır.

Üretim hedefleri en az şu sinyalleri kapsamalıdır:

• Uçtan uca görev başarı oranı ve insan müdahalesi gerektiren akışların payı
• Tool şemasına uygun çağrı, yetkili işlem ve iş kuralı doğrulama oranı
• P50, P95 ve P99 gecikme değerleri
• Model, embedding, retrieval ve dış servis maliyetinin istek başına dağılımı
• Yanlış işlem, veri sızıntısı, tekrar eden işlem ve güvenli durma sayıları

Tek Trace İçinde Uçtan Uca Gözlemlenebilirlik

Her kullanıcı isteği için tek bir trace oluşturulmalı; planlama, model çağrıları, belge arama, tool doğrulama ve sonuç üretimi bu trace altında ilişkilendirilmelidir. Sadece “tool çağrıldı” kaydı hata ayıklamak için yeterli değildir. Akış sürümü, model sürümü, tool sürümü, tenant bağlamı, izin sonucu ve kararın hangi kurala dayanarak verildiği de görülebilmelidir.

Örnek olay alanları:

• Trace ve istek kimliği, akış sürümü ve korelasyon kimliği
• Model adı, çağrı amacı, token kullanımı, gecikme ve durdurma nedeni
• Tool adı, doğrulanmış parametre özeti, yetki sonucu ve hata sınıfı
• Retriever sorgusunun güvenli özeti, belge kimlikleri ve kaynak sürümü
• Retry sayısı, fallback nedeni, insan onayı ve son durum

Prompt, erişim belirteci, kişisel veri ve müşteri içeriği ham biçimde loglanmamalıdır. Alan bazlı redaksiyon, maskeleme, erişim kontrolü ve saklama süresi politikası birlikte uygulanmalıdır. Hassas veriler için ayrı güvenlik olayları üretilebilir; ancak operasyonel debug kayıtları bu verilerin kopyasına dönüşmemelidir. Alarm tasarımında yalnızca hata oranı değil, belirli tool’larda artan belirsiz sonuçlar, maliyet sıçraması ve P95 gecikme de izlenmelidir.

Tool Calling’de İdempotency, Yetki ve Hata Sınıfları

Yan etkili her tool açık bir giriş şemasına, sunucu tarafı doğrulamaya ve dar kapsamlı yetkilendirmeye sahip olmalıdır. Modelin ürettiği parametreyi doğrudan dış servise aktarmak yerine tip, aralık, sahiplik ve iş kuralı kontrolleri yapılmalıdır. Kritik işlemlerde model öneri üretir; gerçekleştirme kararı deterministik politika katmanına veya insan onayına bırakılır.

Ödeme, bilet oluşturma, sipariş değiştirme ve silme gibi işlemlerde istemci tarafından üretilen idempotency anahtarı kullanılmalıdır. Sunucu bu anahtarı işlem sonucu ile birlikte saklamalı; aynı anahtarla gelen istekte işlemi yeniden yapmak yerine önceki sonucu döndürmelidir. Yanıt alınamadığında tekrar göndermeden önce işlem durumu sorgulanmalıdır. Geri alma mümkün değilse işlem öncesi onay, işlem sonrası uzlaştırma ve açık kullanıcı bildirimi gerekir.

Hataları sınıflandırmadan retry uygulamak riski büyütür:

• Geçici: Ağ sorunu, oran sınırı veya kısa süreli servis kesintisi. Üstel bekleme, jitter ve sınırlı deneme kullanılabilir.
• Kalıcı: Geçersiz parametre, yetki eksikliği veya bulunamayan kaynak. Retry yerine düzeltme ya da kullanıcıdan ek bilgi istenir.
• Belirsiz sonuç: İstek gönderilmiş, yanıt alınamamıştır. Durum sorgulanmadan tekrar işlem yapılmaz.
• Politika ihlali: Yetki kapsamı, güvenlik kuralı veya veri erişim sınırı aşılmıştır. Akış durdurulur ve olay kaydedilir.

Retry sayısı, toplam süre ve bütçe birleştirilmiş bir hata bütçesiyle sınırlandırılmalıdır. Circuit breaker, kuyruk sınırı ve kontrollü fallback mekanizmaları dış servis arızasının tüm agent akışına yayılmasını önler.

RAG, Güvenlik ve Agent Kalitesini Ayrı Değerlendirin

RAG sisteminde akıcı yanıt doğruluk anlamına gelmez. Retrieval isabeti, gereksiz belge oranı, kaynak güncelliği ve yanıtın gerçekten kaynaklarla desteklenmesi ayrı ölçülmelidir. Değerlendirme kümesine normal soruların yanı sıra eksik bilgi, çelişkili kaynak, yetkisiz belge, eski doküman ve prompt injection örnekleri eklenmelidir.

Belge içeriği talimat gibi yorumlanmamalı; sistem talimatları, kullanıcı isteği ve getirilen veri ayrı güven sınırlarında işlenmelidir. Belge erişimi tenant, kullanıcı ve kaynak politikalarıyla filtrelenmeli; yalnızca retrieval katmanına güvenmek yerine tool ve uygulama katmanında da yetki kontrolü yapılmalıdır. Sistem güvenilir kaynak bulamadığında uydurma cevap vermek yerine açıkça belirsizlik bildirmeli veya insan onayı istemelidir.

Kalite kapısında şu sonuçları birlikte inceleyin:

• Retrieval isabeti ve kaynakla desteklenmeyen iddia oranı
• Tool parametrelerinin şema ve iş kurallarına uygunluğu
• Güvenli biçimde “bilmiyorum” deme ve insan onayına geçiş oranı
• Maliyet ve gecikme artışının sağladığı kalite kazanımı
• Prompt injection, veri sızıntısı ve yetkisiz erişim testlerinin sonucu

Hata Bütçesi ve Üretime Alma Kontrolü

Hata bütçesi yalnızca HTTP hata oranından oluşmamalıdır. Uçtan uca başarısızlık, hatalı yan etki, güvenlik olayı, aşırı maliyet ve hedeflenen gecikmenin aşılması ayrı bütçeler olarak izlenebilir. Bütçe tüketimi belirli bir eşiği geçtiğinde yeni özellik yayınları durdurulmalı, model veya tool sürümü geri alınmalı ve kök neden analizi başlatılmalıdır.

Canary yayın, hızlı geri alma ve sürümlenebilirlik temel gerekliliklerdir. Prompt, tool şeması, politika, retrieval ayarı ve model seçimi birlikte sürümlenmeli; bir trace hangi kombinasyonla üretildiğini gösterebilmelidir.

• Her tool için giriş şeması, yetki kontrolü, timeout ve hata sözleşmesi tanımlı mı?
• Yan etkili işlemlerde idempotency, onay ve geri alma veya uzlaştırma planı var mı?
• Trace ve metriklerde hassas veriler maskeleniyor mu?
• Maliyet, gecikme, kalite ve güvenlik için alarm eşikleri belirlenmiş mi?
• Model veya dış servis kullanılamadığında güvenli fallback devreye giriyor mu?
• Gerçek kullanıcı verisi içermeyen, yeniden üretilebilir test senaryoları mevcut mu?

Agent güvenilirliği daha büyük bir model seçmekten çok sınırları doğru çizmekle kazanılır. Orkestratörün neyi modele bıraktığı, neyi doğruladığı, hangi koşulda retry yaptığı ve ne zaman işlemi durdurduğu açıkça tanımlanırsa sistem daha denetlenebilir, daha güvenli ve daha öngörülebilir bir maliyetle işletilebilir.