Başarısızlık Akışını Ana Mimari Karar Olarak Tasarlamak
Üretimde bir agent’ın yalnızca doğru yanıt üretmesi yeterli değildir. Modelin belirsiz kaldığı, retrieval sonuçlarının yetersiz olduğu, bir aracın zaman aşımına uğradığı veya aynı isteğin yeniden işlendiği durumlarda sistemin güvenli davranması gerekir. Bu nedenle başarı yolu kadar kontrollü geri dönüş yolu da tasarlanmalıdır.
Her görev için açık sonuç durumları tanımlamak faydalıdır:
Durum Makinesi, Sözleşmeler ve İdempotent İş Akışı
Agent orchestration katmanını serbest biçimli bir sohbet döngüsü yerine açık bir durum makinesi olarak modellemek daha güvenlidir. Örneğin destek talebi akışı alındı → sınıflandırıldı → veri toplandı → öneri hazırlandı → onay bekliyor → uygulandı adımlarından oluşabilir. Her geçişin ön koşulu, zaman aşımı, yetki kontrolü ve başarısızlık davranışı kayıt altına alınmalıdır.
Tool çağrılarında giriş ve çıkış şemaları sürümlenmeli; modelin ürettiği parametreler uygulama katmanında yeniden doğrulanmalıdır. İş etkisi oluşturan her çağrı, akış ve kullanıcı bağlamında benzersiz bir idempotency anahtarı taşımalıdır:
Aynı anahtarla gelen tekrar çağrıda araç yeni işlem açmak yerine önceki sonucu döndürmelidir. Retry yalnızca geçici hatalarda çalışmalı; üstel bekleme, rastgele sapma, maksimum deneme sayısı ve toplam süre bütçesi araç bazında tanımlanmalıdır. Şema hatası, yetki reddi veya iş kuralı ihlali doğrudan güvenli duruşa yönlendirilmelidir.
İnsan Onayını Risk Sınırı Olarak Konumlandırmak
İnsan onayı her adımda istenirse akış yavaşlar; hiç istenmezse yüksek etkili hatalar oluşabilir. Onay noktası belirlenirken işlemin geri alınabilirliği, finansal ve hukuki etkisi, verinin hassasiyeti, hedef sistemin kritikliği ve model güveni birlikte değerlendirilmelidir.
Onay ekranı yalnızca Devam et düğmesi göstermemelidir. En az şu bilgiler sunulmalıdır:
Gözlemlenebilirlik, Maliyet ve Replay
Toplam gecikme ve hata oranı agent sistemlerini işletmek için yetersizdir. Her çalışmada korelasyon kimliği, akış adımı, model ve araç sürümü, prompt veya şablon kimliği, token kullanımı, gecikme, retry sayısı, hata sınıfı, retrieval sonuç özeti ve politika kararı ilişkilendirilmelidir. Hassas veriler ham olarak loglanmamalı; maskeleme, alan bazlı erişim ve saklama süresi uygulanmalıdır.
Maliyet gözlemlenebilirliği de akışın parçasıdır. Model çağrıları, embedding üretimi, retrieval, araç kullanımı ve insan bekleme süreleri ayrı izlenmelidir. Token veya para bütçesi aşıldığında daha ucuz modele geçmek, bağlamı daraltmak ya da güvenli duruşa geçmek önceden tanımlanmalıdır. Bu geçişler sessizce yapılmamalı; trace içinde neden ve sonuç açıkça görünmelidir.
Replay, üretim olayını doğrudan yeniden çalıştırmak değildir. Aynı girdiler, araç sözleşmeleri ve ilgili sürümlerle; üretim araçları yerine sahte, salt-okunur veya simülasyon adaptörleri kullanılarak kontrollü inceleme yapılmalıdır. Böylece şu sorular yanıtlanabilir:
Üretim Öncesi Güvenlik ve Dayanıklılık Kontrolü
Pilot öncesinde yalnızca başarılı örnekler değil, bozuk ve kötü niyetli girdiler de test edilmelidir. Prompt injection, aşırı uzun bağlam, çelişkili kaynaklar, eksik araç yanıtı, tekrar oynatma, yetkisiz kaynak erişimi, kota aşımı ve kısmi servis kesintisi için senaryolar hazırlanmalıdır.
Üretimde bir agent’ın yalnızca doğru yanıt üretmesi yeterli değildir. Modelin belirsiz kaldığı, retrieval sonuçlarının yetersiz olduğu, bir aracın zaman aşımına uğradığı veya aynı isteğin yeniden işlendiği durumlarda sistemin güvenli davranması gerekir. Bu nedenle başarı yolu kadar kontrollü geri dönüş yolu da tasarlanmalıdır.
Her görev için açık sonuç durumları tanımlamak faydalıdır:
- Başarılı: Çıktı doğrulanmış ve işlem tamamlanmıştır.
- Beklemede: İnsan onayı, harici sistem yanıtı veya ek veri gereklidir.
- Tekrar denenebilir hata: Geçici ağ, kota, servis yoğunluğu veya zaman aşımı oluşmuştur.
- Kalıcı hata: Şema, yetki, doğrulama veya iş kuralı ihlali vardır.
- Güvenli duruş: Agent yeterli kanıta sahip değildir ya da risk, maliyet veya süre eşiği aşılmıştır.
Durum Makinesi, Sözleşmeler ve İdempotent İş Akışı
Agent orchestration katmanını serbest biçimli bir sohbet döngüsü yerine açık bir durum makinesi olarak modellemek daha güvenlidir. Örneğin destek talebi akışı alındı → sınıflandırıldı → veri toplandı → öneri hazırlandı → onay bekliyor → uygulandı adımlarından oluşabilir. Her geçişin ön koşulu, zaman aşımı, yetki kontrolü ve başarısızlık davranışı kayıt altına alınmalıdır.
Tool çağrılarında giriş ve çıkış şemaları sürümlenmeli; modelin ürettiği parametreler uygulama katmanında yeniden doğrulanmalıdır. İş etkisi oluşturan her çağrı, akış ve kullanıcı bağlamında benzersiz bir idempotency anahtarı taşımalıdır:
request_id: "akış-kapsamında-tekil-değer"
tool: "create_ticket"
mode: "dry_run | execute"
requires_approval: true
Aynı anahtarla gelen tekrar çağrıda araç yeni işlem açmak yerine önceki sonucu döndürmelidir. Retry yalnızca geçici hatalarda çalışmalı; üstel bekleme, rastgele sapma, maksimum deneme sayısı ve toplam süre bütçesi araç bazında tanımlanmalıdır. Şema hatası, yetki reddi veya iş kuralı ihlali doğrudan güvenli duruşa yönlendirilmelidir.
İnsan Onayını Risk Sınırı Olarak Konumlandırmak
İnsan onayı her adımda istenirse akış yavaşlar; hiç istenmezse yüksek etkili hatalar oluşabilir. Onay noktası belirlenirken işlemin geri alınabilirliği, finansal ve hukuki etkisi, verinin hassasiyeti, hedef sistemin kritikliği ve model güveni birlikte değerlendirilmelidir.
Onay ekranı yalnızca Devam et düğmesi göstermemelidir. En az şu bilgiler sunulmalıdır:
- Agent’ın ulaşmaya çalıştığı hedef ve mevcut durum.
- Çağrılacak araçlar, parametreler ve beklenen dış etki.
- Kullanılan kaynakların özeti, retrieval güveni ve önemli belirsizlikler.
- İşlemin geri alınabilir olup olmadığı ve tahmini maliyeti.
- Onaylama, düzenleme, reddetme veya güvenli duruş seçenekleri.
Gözlemlenebilirlik, Maliyet ve Replay
Toplam gecikme ve hata oranı agent sistemlerini işletmek için yetersizdir. Her çalışmada korelasyon kimliği, akış adımı, model ve araç sürümü, prompt veya şablon kimliği, token kullanımı, gecikme, retry sayısı, hata sınıfı, retrieval sonuç özeti ve politika kararı ilişkilendirilmelidir. Hassas veriler ham olarak loglanmamalı; maskeleme, alan bazlı erişim ve saklama süresi uygulanmalıdır.
Maliyet gözlemlenebilirliği de akışın parçasıdır. Model çağrıları, embedding üretimi, retrieval, araç kullanımı ve insan bekleme süreleri ayrı izlenmelidir. Token veya para bütçesi aşıldığında daha ucuz modele geçmek, bağlamı daraltmak ya da güvenli duruşa geçmek önceden tanımlanmalıdır. Bu geçişler sessizce yapılmamalı; trace içinde neden ve sonuç açıkça görünmelidir.
Replay, üretim olayını doğrudan yeniden çalıştırmak değildir. Aynı girdiler, araç sözleşmeleri ve ilgili sürümlerle; üretim araçları yerine sahte, salt-okunur veya simülasyon adaptörleri kullanılarak kontrollü inceleme yapılmalıdır. Böylece şu sorular yanıtlanabilir:
- Agent hangi kararla yanlış yola girdi?
- Sorun modelden, retrieval katmanından, politika motorundan veya araçtan mı kaynaklandı?
- Aynı bağlamda yeni model sürümü farklı bir karar veriyor mu?
- Replay sırasında gerçek dış etki, hassas veri sızıntısı veya yinelenen işlem oluşuyor mu?
Üretim Öncesi Güvenlik ve Dayanıklılık Kontrolü
Pilot öncesinde yalnızca başarılı örnekler değil, bozuk ve kötü niyetli girdiler de test edilmelidir. Prompt injection, aşırı uzun bağlam, çelişkili kaynaklar, eksik araç yanıtı, tekrar oynatma, yetkisiz kaynak erişimi, kota aşımı ve kısmi servis kesintisi için senaryolar hazırlanmalıdır.
- Her aracın giriş ve çıkış şeması sürümlü ve uygulama katmanında doğrulanıyor mu?
- Araç izinleri görev, kullanıcı ve kaynak kapsamıyla sınırlı mı?
- Retry, timeout, devre kesici ve toplam maliyet bütçesi araç bazında tanımlı mı?
- Dış etki oluşturan işlemler idempotent ve gerektiğinde dry-run destekli mi?
- İnsan onayı gerektiren risk sınıfları açıkça belirlenmiş mi?
- Trace ve replay akışlarında hassas veri sızıntısı engelleniyor mu?
- Bir model veya araç sürümü değiştiğinde regresyon testleri çalıştırılıyor mu?