Agent’ı Serbest Sohbetten İş Akışına Taşımak

Bir AI agent’ı yalnızca iyi prompt yazılmış bir sohbet botu gibi tasarlamak, üretimde öngörülemeyen sonuçlara yol açabilir. Daha sağlam yaklaşım; modelin karar verebildiği, fakat hangi araçları hangi koşullarda çağırabileceğinin uygulama tarafından sınırlandığı bir iş akışı kurmaktır.

Önce görevleri açık adımlara ayırın: isteği sınıflandırma, gerekli veriyi toplama, işlem planı oluşturma, aracı çağırma, sonucu doğrulama ve kullanıcıya yanıt verme. Bu adımların tamamını modele bırakmak yerine kritik geçişleri backend yönetsin. Böylece model yanlış bir araç seçse bile yetkisiz veya geri döndürülemez işlem doğrudan gerçekleşmez.

Tool Şeması ve Yetki Sınırları

Tool calling kullanırken her araç için belirsiz açıklamalar yerine dar ve doğrulanabilir bir şema tanımlanmalıdır. Parametre türleri, zorunlu alanlar, izin verilen değerler ve yan etkiler açıkça belirtilmelidir. Modelin ürettiği argümanları doğrudan çalıştırmak yerine sunucu tarafında tekrar doğrulayın.

Örnek bir araç tanımı mantıksal olarak şu bilgileri içerebilir:

• Amaç: Bir destek talebinin durumunu okumak.
• Girdi: Yalnızca geçerli bir talep kimliği.
• Yetki: Kullanıcının erişebildiği kayıtlarla sınırlı.
• Yan etki: Yok; yalnızca veri okur.
• Hata davranışı: Kayıt bulunamazsa kontrollü hata döndürür.

Ödeme başlatma, kayıt silme veya dışarıya mesaj gönderme gibi işlemlerde iki aşamalı onay, idempotency anahtarı ve işlem günlüğü düşünülmelidir. Modelin “kullanıcı onayladı” varsayımı, gerçek bir kullanıcı onayı yerine geçmemelidir. Hassas araçlar için insan onayı veya ayrı bir politika servisi daha güvenli olabilir.

Durum Yönetimi, Yeniden Deneme ve Fallback

Agent belleğini tek ve sınırsız bir sohbet geçmişi olarak tutmak yerine durumları açıkça modelleyin. Örneğin awaiting_input, planning, tool_running, needs_confirmation ve completed gibi durumlar, hata ayıklamayı kolaylaştırır. Her geçişte hangi girdinin, hangi araç çıktısının ve hangi kararın kullanıldığını kaydetmek gerekir; ancak gereksiz kişisel verileri loglamayın.

Araç çağrısı zaman aşımına uğrarsa modelin aynı işlemi sınırsızca tekrarlamasına izin vermeyin. Uygulanabilir bir politika şu şekilde olabilir:

• Geçici ağ hatalarında sınırlı sayıda ve artan beklemeli yeniden deneme.
• Aynı işlem için idempotency kontrolü.
• Belirsiz sonuçta işlemi tamamlandı varsaymama.
• Kritik işlem başarısızsa kullanıcıya açık durum ve sonraki adım sunma.
• Model yanıt veremediğinde kural tabanlı veya insan destekli fallback kullanma.

Fallback, yalnızca “üzgünüm, tekrar deneyin” mesajı olmamalıdır. Kullanıcıdan eksik alanı istemek, salt okunur moda geçmek veya işlemi onay kuyusuna almak daha işlevsel seçeneklerdir.

Prompt’u Değil, Davranışı Değerlendirmek

Bir agent’ın kalitesini yalnızca akıcı yanıtlarla ölçmek yanıltıcıdır. Değerlendirme seti, gerçek kullanım senaryolarını ve kötüye kullanım denemelerini içermelidir. Her testte beklenen araç seçimi, izin verilen parametreler, yanıtın doğruluğu, gecikme ve maliyet ayrı ayrı incelenebilir.

Ölçülebilecek başlıca sinyaller:

• Doğru aracı seçme oranı.
• Geçersiz veya eksik argüman üretme oranı.
• Gereksiz tool calling sayısı.
• Yetkisiz işlem denemelerinin engellenme oranı.
• Başarısız işlemlerde doğru fallback’e geçiş oranı.
• İnsan müdahalesi gerektiren akışların oranı.

Prompt veya model değişikliğinden önce aynı testleri tekrar çalıştırmak, regresyonları görünür kılar. Model sağlayıcısının belirli bir özelliği desteklediği doğrulanmadıysa uygulamayı o özelliğe bağımlı kurmayın; özellik yokmuş gibi çalışan bir yedek akış tasarlayın.

Üretime Almadan Önce Kontrol Listesi

• Her aracın girdi ve çıktı şeması backend’de doğrulanıyor mu?
• Salt okunur ve yan etkili araçlar ayrılmış mı?
• Kullanıcı yetkisi her çağrıda yeniden kontrol ediliyor mu?
• Tekrarlanan çağrılar çift işlem oluşturmuyor mu?
• Modelin ürettiği metin, sorgu veya komut doğrudan çalıştırılmıyor mu?
• Hatalar, gecikmeler ve araç sonuçları kişisel veri sızıntısı yaratmadan izleniyor mu?
• Prompt, model veya araç değişiklikleri sabit test senaryolarıyla karşılaştırılıyor mu?

İyi bir agent, her soruyu kendi başına çözmeye çalışan sistem değil; sınırları belirli, başarısız olduğunda güvenli biçimde duran ve kararlarının ölçülebilir olduğu sistemdir. Önce dar kapsamlı, düşük riskli bir iş akışını uçtan uca gözlemleyin; ardından araç sayısını ve otonomi düzeyini kademeli olarak artırın.