Kontrol Düzlemi Neden Ayrı Tasarlanmalı?
Bir agent sistemi yalnızca modele istek gönderip araç çağıran bir döngü olarak tasarlandığında, geliştirme ortamında çalışan akış üretimde hızla belirsizleşir. Modelin hangi bağlamla karar verdiği, hangi aracın neden çağrıldığı, aynı isteğin tekrar işlenip işlenmediği ve başarısızlık sonrasında ne yapılacağı açıkça yönetilmelidir.
Pratik bir mimaride agent çalışma zamanı ile kontrol düzlemini ayırmak faydalıdır. Çalışma zamanı oturumu yürütür; kontrol düzlemi ise araç kayıtlarını, politika kurallarını, model ve prompt sürümlerini, bütçeleri, zaman aşımını ve gözlemlenebilirlik ayarlarını yönetir. Böylece bir prompt değişikliği veya yeni araç eklenmesi, tüm üretim trafiğini kontrolsüz biçimde etkilemez.
Kontrol düzlemi ayrıca sürümleme ve kademeli dağıtım için kullanılabilir. Yeni bir model, araç şeması veya retrieval politikası önce sınırlı bir trafik diliminde denenmeli; hata oranı, maliyet ve insan devri gibi metrikler kabul edilebilir sınırlar içindeyse yaygınlaştırılmalıdır.
RAG ve Tool Calling Sözleşmeleri
RAG katmanı yalnızca benzer metin döndüren bir arama servisi olmamalıdır. Her sonuç en azından kaynak kimliği, erişim kapsamı, içerik sürümü, güncellik bilgisi ve güvenilirlik sinyali taşımalıdır. Erişim kontrolü arama sonrasına bırakılmamalı; kullanıcı yetkisi retrieval sorgusuna ve sonuç filtreleme aşamasına uygulanmalıdır.
Agent yetkisi olmayan bir dokümanı geri çağırmamalı; düşük kaliteli, güncel olmayan veya çelişkili sonuçlarda kesin cevap üretmek yerine açıklayıcı bir belirsizlik durumu döndürmelidir. Kaynakların cevapta gösterilmesi, hem kullanıcı güvenini hem de hata incelemesini kolaylaştırır. RAG içindeki talimatlar güvenilir sistem talimatı değil, işlenmesi gereken veri olarak kabul edilmelidir.
Araçlar için modelin gördüğü açıklama ile gerçek API sözleşmesi aynı olmalıdır. Şema doğrulaması, zorunlu alanlar, enum değerleri, maksimum boyutlar ve hata kodları açıkça tanımlanmalıdır. Araç sonucu doğrudan modele bırakılmadan önce sunucu tarafında doğrulanmalı; hassas alanlar maskeleme katmanından geçirilmelidir.
Örnek bir araç sözleşmesinde şu alanlar bulunabilir:
Agent döngüsünde her adımın durumunu kalıcı olarak kaydetmek, geçici ağ hatası ile iş kuralı hatasını ayırmayı sağlar. Ağ zaman aşımı veya geçici servis kullanılamazlığı yeniden denenebilir; geçersiz parametre, yetki reddi ve veri doğrulama hataları aynı girdilerle tekrar tekrar çalıştırılmamalıdır. Yeniden denemeler üstel geri çekilme, deneme sayısı üst sınırı ve toplam zaman bütçesiyle sınırlandırılmalıdır.
Yan etkisi olan işlemler için iki aşamalı yürütme daha güvenlidir: önce taslak veya önizleme oluşturulur, ardından politika kontrolü ve gerekiyorsa insan onayı alınır. Para transferi, kayıt silme, erişim verme veya dış sisteme mesaj gönderme gibi işlemler yalnızca modelin kararına bırakılmamalıdır.
İdempotency anahtarı agent oturumuna değil, iş emrine bağlı olmalıdır. Aynı olay kuyruğa iki kez düşse bile araç, daha önce başarıyla tamamlanan işlemi yeniden uygulamak yerine önceki sonucu döndürebilmelidir. Kalıcı durum ile modelin kısa süreli bağlamı ayrı tutulmalı; model bağlamı kaybolsa bile işin gerçek durumu güvenilir bir sistemden okunabilmelidir.
Gözlemlenebilirlik ve Maliyet Kontrolü
Tek bir toplam istek süresi üretim sorunlarını açıklamak için yetersizdir. Her çalışma için korelasyon kimliği, model ve prompt sürümü, RAG arama süresi, getirilen kaynak sayısı, araç adı, araç gecikmesi, token kullanımı, yeniden deneme sayısı ve sonlanma nedeni izlenmelidir. Kullanıcı verisi ve gizli içerik loglara ham biçimde yazılmamalı; trace alanları maskeleme ve saklama politikalarına tabi olmalıdır.
Maliyet ölçümünde yalnızca model çağrısı değil; embedding, vektör arama, araç çalıştırma, kuyrukta bekleme ve insan incelemesi de hesaba katılmalıdır. Oturum, ekip veya müşteri bazında bütçe sınırları ve devre kesiciler uygulanabilir:
Bu sınırlar kaliteyi düşürmemesi için ölçülmelidir. Başarı oranı, doğru kaynak kullanımı, insan devrine düşen akışlar, yanlış araç çağrıları, gecikme ve ortalama maliyet birlikte değerlendirilmelidir. Daha uzun cevap veya daha yüksek otomasyon oranı tek başına başarı göstergesi değildir.
Güvenlik Testleri ve Üretime Geçiş
Prompt injection, veri sızıntısı, araç parametresi manipülasyonu ve yetki yükseltme senaryoları normal test paketinin parçası olmalıdır. Kullanıcı yetkisi her araç çağrısında sunucu tarafında yeniden kontrol edilmelidir. Modelin daha önceki bağlamda bir yetki iddiasında bulunması, gerçek yetkilendirme kanıtı sayılmamalıdır.
Üretime geçmeden önce şu kontroller uygulanabilir:
Bir agent sistemi yalnızca modele istek gönderip araç çağıran bir döngü olarak tasarlandığında, geliştirme ortamında çalışan akış üretimde hızla belirsizleşir. Modelin hangi bağlamla karar verdiği, hangi aracın neden çağrıldığı, aynı isteğin tekrar işlenip işlenmediği ve başarısızlık sonrasında ne yapılacağı açıkça yönetilmelidir.
Pratik bir mimaride agent çalışma zamanı ile kontrol düzlemini ayırmak faydalıdır. Çalışma zamanı oturumu yürütür; kontrol düzlemi ise araç kayıtlarını, politika kurallarını, model ve prompt sürümlerini, bütçeleri, zaman aşımını ve gözlemlenebilirlik ayarlarını yönetir. Böylece bir prompt değişikliği veya yeni araç eklenmesi, tüm üretim trafiğini kontrolsüz biçimde etkilemez.
Kontrol düzlemi ayrıca sürümleme ve kademeli dağıtım için kullanılabilir. Yeni bir model, araç şeması veya retrieval politikası önce sınırlı bir trafik diliminde denenmeli; hata oranı, maliyet ve insan devri gibi metrikler kabul edilebilir sınırlar içindeyse yaygınlaştırılmalıdır.
RAG ve Tool Calling Sözleşmeleri
RAG katmanı yalnızca benzer metin döndüren bir arama servisi olmamalıdır. Her sonuç en azından kaynak kimliği, erişim kapsamı, içerik sürümü, güncellik bilgisi ve güvenilirlik sinyali taşımalıdır. Erişim kontrolü arama sonrasına bırakılmamalı; kullanıcı yetkisi retrieval sorgusuna ve sonuç filtreleme aşamasına uygulanmalıdır.
Agent yetkisi olmayan bir dokümanı geri çağırmamalı; düşük kaliteli, güncel olmayan veya çelişkili sonuçlarda kesin cevap üretmek yerine açıklayıcı bir belirsizlik durumu döndürmelidir. Kaynakların cevapta gösterilmesi, hem kullanıcı güvenini hem de hata incelemesini kolaylaştırır. RAG içindeki talimatlar güvenilir sistem talimatı değil, işlenmesi gereken veri olarak kabul edilmelidir.
Araçlar için modelin gördüğü açıklama ile gerçek API sözleşmesi aynı olmalıdır. Şema doğrulaması, zorunlu alanlar, enum değerleri, maksimum boyutlar ve hata kodları açıkça tanımlanmalıdır. Araç sonucu doğrudan modele bırakılmadan önce sunucu tarafında doğrulanmalı; hassas alanlar maskeleme katmanından geçirilmelidir.
Örnek bir araç sözleşmesinde şu alanlar bulunabilir:
- İşlemin amacı ve yetki kapsamı
- Girdi şeması, boyut sınırları ve varsayılan değerler
- İdempotency anahtarı gereksinimi
- Beklenen hata sınıfları ve yeniden deneme davranışı
- Yan etki oluşturup oluşturmadığı
- İşlemin önizleme, onay veya doğrudan yürütme modları
Agent döngüsünde her adımın durumunu kalıcı olarak kaydetmek, geçici ağ hatası ile iş kuralı hatasını ayırmayı sağlar. Ağ zaman aşımı veya geçici servis kullanılamazlığı yeniden denenebilir; geçersiz parametre, yetki reddi ve veri doğrulama hataları aynı girdilerle tekrar tekrar çalıştırılmamalıdır. Yeniden denemeler üstel geri çekilme, deneme sayısı üst sınırı ve toplam zaman bütçesiyle sınırlandırılmalıdır.
Yan etkisi olan işlemler için iki aşamalı yürütme daha güvenlidir: önce taslak veya önizleme oluşturulur, ardından politika kontrolü ve gerekiyorsa insan onayı alınır. Para transferi, kayıt silme, erişim verme veya dış sisteme mesaj gönderme gibi işlemler yalnızca modelin kararına bırakılmamalıdır.
İdempotency anahtarı agent oturumuna değil, iş emrine bağlı olmalıdır. Aynı olay kuyruğa iki kez düşse bile araç, daha önce başarıyla tamamlanan işlemi yeniden uygulamak yerine önceki sonucu döndürebilmelidir. Kalıcı durum ile modelin kısa süreli bağlamı ayrı tutulmalı; model bağlamı kaybolsa bile işin gerçek durumu güvenilir bir sistemden okunabilmelidir.
Gözlemlenebilirlik ve Maliyet Kontrolü
Tek bir toplam istek süresi üretim sorunlarını açıklamak için yetersizdir. Her çalışma için korelasyon kimliği, model ve prompt sürümü, RAG arama süresi, getirilen kaynak sayısı, araç adı, araç gecikmesi, token kullanımı, yeniden deneme sayısı ve sonlanma nedeni izlenmelidir. Kullanıcı verisi ve gizli içerik loglara ham biçimde yazılmamalı; trace alanları maskeleme ve saklama politikalarına tabi olmalıdır.
Maliyet ölçümünde yalnızca model çağrısı değil; embedding, vektör arama, araç çalıştırma, kuyrukta bekleme ve insan incelemesi de hesaba katılmalıdır. Oturum, ekip veya müşteri bazında bütçe sınırları ve devre kesiciler uygulanabilir:
max_steps = 8
max_tool_calls = 4
max_cost_units = 20
if steps >= max_steps or tool_calls >= max_tool_calls:
return "bounded_failure"
Bu sınırlar kaliteyi düşürmemesi için ölçülmelidir. Başarı oranı, doğru kaynak kullanımı, insan devrine düşen akışlar, yanlış araç çağrıları, gecikme ve ortalama maliyet birlikte değerlendirilmelidir. Daha uzun cevap veya daha yüksek otomasyon oranı tek başına başarı göstergesi değildir.
Güvenlik Testleri ve Üretime Geçiş
Prompt injection, veri sızıntısı, araç parametresi manipülasyonu ve yetki yükseltme senaryoları normal test paketinin parçası olmalıdır. Kullanıcı yetkisi her araç çağrısında sunucu tarafında yeniden kontrol edilmelidir. Modelin daha önceki bağlamda bir yetki iddiasında bulunması, gerçek yetkilendirme kanıtı sayılmamalıdır.
Üretime geçmeden önce şu kontroller uygulanabilir:
- Her araç için şema, yetki, yan etki ve idempotency testi
- Bozuk, eksik, güncel olmayan ve çelişkili RAG sonuçlarıyla değerlendirme
- Model veya araç erişilemezken güvenli geri dönüş davranışı
- Bütçe, zaman aşımı ve maksimum adım sınırlarının doğrulanması
- Hassas verilerin log, trace ve hata mesajlarından temizlenmesi
- Prompt, model, retrieval ve araç sürümlerinin geriye dönük izlenebilmesi
- Canary dağıtım ve başarısızlık halinde hızlı geri alma prosedürü