Neden Tool Calling Sözleşmesi İlk Tasarım Kararıdır?

Bir agent sisteminde modelin araç çağırabilmesi, yalnızca fonksiyon tanımlayıp çağrıyı çalıştırmaktan ibaret değildir. Üretim ortamında her araç; giriş şeması, yetki kapsamı, zaman aşımı, tekrar deneme davranışı ve çıktı sözleşmesiyle birlikte tasarlanmalıdır. Aksi hâlde model doğru aracı seçse bile eksik parametre, yanlış veri biçimi veya beklenmeyen yan etki üretilebilir.

Her araç için şu sınırlar açıkça tanımlanmalıdır:

• Girdi doğrulama: Zorunlu alanlar, veri türleri, uzunluk sınırları ve izin verilen değerler.
• Yetki: Aracın hangi kullanıcı, tenant veya servis adına işlem yapabileceği.
• Yan etki: Okuma işlemi mi, yoksa kalıcı değişiklik yapan bir işlem mi olduğu.
• İdempotency: Aynı çağrının yeniden çalıştırılmasında mükerrer işlem oluşup oluşmayacağı.
• Çıktı: Modelin yorumlaması kolay, sürümlenebilir ve gereksiz hassas veri içermeyen sonuç biçimi.

Özellikle ödeme, silme, yayınlama veya kullanıcı yetkisi değiştirme gibi işlemler doğrudan modele bırakılmamalıdır. Bu araçlar için onay adımı, politika kontrolü veya insan incelemesi eklenmelidir.

Orchestrator Tasarımı: Model Değil, Politika Merkezi

Agent orkestratörü, modelin verdiği kararı sorgusuz çalıştıran ince bir geçit olmamalıdır. Orchestrator; akış durumunu, bütçeyi, çağrı sayısını, kullanıcı bağlamını ve güvenlik politikalarını yöneten katman olmalıdır.

Örnek bir akış şu şekilde kurulabilir:

• İsteği sınıflandır ve risk seviyesini belirle.
• Kullanıcı ve tenant bağlamını doğrula.
• Yalnızca bu bağlama uygun araçları modele sun.
• Model çıktısını şema doğrulamasından geçir.
• Yan etkili araçlarda politika ve onay kontrolü uygula.
• Araç sonucunu normalize ederek modele geri ver.
• Maksimum adım, süre ve maliyet sınırına ulaşıldığında akışı kontrollü biçimde sonlandır.

Her adımın devam edip etmeyeceği yalnızca modelin “devam et” kararına bağlı olmamalıdır. Örneğin aynı aracın art arda çağrılması, döngüsel plan üretimi veya başarısız bir aracın tekrar tekrar denenmesi orkestratör tarafından engellenebilmelidir. Durum makinesi yaklaşımı, karmaşık akışlarda serbest biçimli agent döngülerine göre daha öngörülebilir sonuç verir.

RAG ve Tool Sonuçlarında Güven Sınırları

RAG katmanından gelen metin ile güvenilir uygulama verisi aynı statüde değerlendirilmemelidir. Belgeler güncel olmayabilir, erişim kapsamı yanlış uygulanabilir veya içerik içinde agent davranışını etkilemeye çalışan talimatlar bulunabilir. Alınan her parçaya kaynak kimliği, erişim kapsamı, güncellik bilgisi ve güven seviyesi gibi metadata eklemek faydalıdır.

RAG akışında kontrol edilecek noktalar:

• Arama öncesi kullanıcının erişebileceği veri kümesini sınırla.
• Chunk sonuçlarını yalnızca benzerliğe göre değil, yetki ve içerik türüne göre de filtrele.
• Modelin kaynakta bulunmayan bilgiyi kesin ifadeyle üretmesini engelleyen cevap politikası tanımla.
• Çelişkili veya yetersiz kaynaklarda açıklama isteme ya da güvenli geri dönüş davranışı kullan.
• Araç sonucundaki metni talimat değil, veri olarak işaretle ve komut yürütme bağlamından ayır.

Bir cevap değerlendirilirken yalnızca akıcılık ölçülmemeli; doğru kaynağa dayanma, erişim ihlali yapmama ve belirsizliği doğru ifade etme de kontrol edilmelidir.

Gözlemlenebilirlik: Sadece Log Tutmak Yetmez

Üretimde hata ayıklayabilmek için tek bir istekten başlayıp model çağrısı, retrieval, tool call ve son cevaba kadar iz sürülebilmelidir. Bunun için her çalışmaya bir correlation ID, her agent adımına da ayrı bir span veya adım kimliği verilmesi yararlı olur.

İzleme verilerinde en az şu alanlar bulunabilir:

• Akış ve model sürümü
• Araç adı, doğrulama sonucu ve çağrı süresi
• Başarı, hata veya zaman aşımı durumu
• Girdi ve çıktı boyutları; hassas içeriklerin maskelenmiş hâli
• Toplam adım sayısı ve tahmini maliyet
• Kullanıcı geri bildirimi veya görev başarı sonucu

Ham prompt ve araç çıktıları sınırsız biçimde saklanmamalıdır. Hassas veriler maskeleme, erişim kontrolü ve saklama süresi politikalarıyla korunmalıdır. Metrikler de ortalamayla sınırlı kalmamalı; gecikme, hata oranı, tekrar deneme oranı, başarısız görev oranı ve araç bazlı maliyet birlikte izlenmelidir.

Hata Yönetimi, Maliyet ve Değerlendirme Döngüsü

Model hatası, araç hatası ve altyapı hatası birbirinden ayrılmalıdır. Geçici ağ hatalarında sınırlı ve artan aralıklı tekrar deneme uygulanabilir; geçersiz parametre veya yetki hatalarında aynı çağrıyı tekrar etmek sorunu çözmez. Araç başarısız olduğunda modele açık bir hata kodu ve güvenli bir açıklama dönmek, belirsiz boş yanıt vermekten daha yararlıdır.

Maliyet kontrolü için:

• Akış başına maksimum token, araç çağrısı ve süre bütçesi belirle.
• Basit sınıflandırma veya biçimlendirme işlerini daha pahalı modellere göndermeme kuralı koy.
• Uzun geçmişi özetle, ancak özetin kritik kararları bozmadığını test et.
• Başarısız görevleri yalnız maliyet değil, kullanıcı etkisi açısından da raporla.

Dağıtımdan önce sabit bir değerlendirme kümesi oluşturulmalı; doğru araç seçimi, parametre doğruluğu, kaynak kullanımı, güvenlik ihlali ve güvenli geri dönüş senaryoları ayrı ayrı puanlanmalıdır. Üretim geri bildirimleri anonimleştirilerek bu kümeye eklenebilir. Böylece yeni prompt, model veya orchestrator değişiklikleri yalnızca “cevap daha iyi görünüyor” ölçütüyle değil, tekrarlanabilir testlerle karşılaştırılır.

Bu mimaride temel hedef, tamamen otonom görünen bir agent değil; sınırları belirli, izlenebilir, gerektiğinde durabilen ve hatasını kontrollü biçimde raporlayan bir üretim sistemi kurmaktır.