Foundry’de kapalı döngü değerlendirmeyle ajanlar

Üretimdeki bir ajan, kodunda tek bir değişiklik olmadan isabetini kaybedebilir ya da pahalılaşabilir. Canlı trafik büyüdükçe yeni kullanıcı istekleri ajan talimatlarındaki boşlukları ortaya çıkarır; aynı zamanda yeni modeller daha iyi kalite ya da daha düşük maliyet sunabilir. Ancak prompt’ları elle düzenlemek ya da modeli yerinde değiştirmek, çalışan iş akışlarını bozma riski taşır. Microsoft’un Foundry blogundaki bu rehber, sürekli değerlendirme, Agent Optimizer ve GitHub Actions ile kapalı döngüde ajanları güvenle iyileştirmeyi anlatıyor.

Diyagramda v1 ve v2, etkin taban sürümü ve aday sürümü temsil ediyor; gerçek sürüm numaralarını Microsoft Foundry atıyor.

Ön koşullar ve sorumluluklar

• Microsoft Foundry kaynakları: Agent Optimizer SDK ile barındırılan (hosted) bir ajan dağıtın; Application Insights’ı bağlayın, onaylı modelleri dağıtın ve Microsoft Entra ID izinlerini verin.
• Uygulama ekibinin sorumlulukları: Sandbox’lı araç test ortamı, gözden geçirilmiş sonuç etiketleri (ground_truth), CI/CD sürüm politikası script’i ve oturum bazlı canary yönlendirmesi (version_indicator).

Döngü uçtan uca nasıl çalışıyor?

Her döngüyü zamanlanmış bir GitHub Actions iş akışı ya da bir Azure Monitor uyarısı başlatıyor. İş akışı son sürekli değerlendirme skorlarını, Application Insights hata metriklerini ve yeni onaylanan model dağıtımlarını okuyor. Triyaj bir kalite düşüşünü ya da planlı bir model değerlendirmesini doğrularsa son izlerden insan etiketlemesi için bir veri seti örnekleniyor. Agent Optimizer, eğitim ve doğrulama setlerinde talimatlar, skill’ler, araç açıklamaları ve modeller arasında arama yapıyor. Sürüm otomasyonu seçilen adayı uygulayıp mühendis incelemesi için pull request açıyor, terfiyi ayrılmış bir regresyon setine bağlıyor ve terfiden sonra .agent_configs/baseline/ klasörünü güncelliyor.

1. Canlı trafiği sürekli değerlendirmeyle izleyin

Güvenli terfi, her aday karşılaştırmasının tabanı olan mevcut üretim yapılandırmasını ölçmekle başlıyor. Foundry sürekli değerlendirmesi canlı trafikte çalışma izlerini puanlayarak kalite, araç kullanımı, gecikme ve maliyetin zaman içindeki değişimini izliyor:

• Araç çıktısı ve yanıt (groundedness): Yanıtın verilen bağlamla desteklenip desteklenmediğini kontrol ediyor, desteksiz “tamamlandı” iddialarını işaretliyor.
• Talimatlar ve eylemler (task_adherence): Ajanın sistem prompt’u kurallarına uyup uymadığını kontrol ediyor.
• Sorgu ve araç çağrıları (tool_call_accuracy, intent_resolution): Doğru aracın doğru argümanlarla seçildiğini doğruluyor.
• Güvenlik ve iz kuralları (indirect_attack, span kontrolleri): Enjekte edilmiş talimatları, araç hatalarını ve tekrarlanan yazma çağrılarını tespit ediyor.

Uyarıları ayıklayın, hedefi belirleyin

Bir kalite uyarısında önce Application Insights izlerine ve Azure Monitor metriklerine bakın; optimizer çalıştırmadan önce ajan yapılandırması sorununu diğer operasyonel değişikliklerden ayırın:

• Arka uç ya da araç kesintileri: Artan zaman aşımları ve API hataları ajan ayarından önce altyapı kurtarması gerektirir.
• Trafik karışımı değişimi: Yeni bir istek tipindeki artış, optimizasyondan önce yeni araç, politika ya da test kapsamı gerektirebilir.
• Değerlendirici veya rubrik güncellemeleri: Değişen bir puanlama prompt’u ya da eşik, ajan davranışı değişmese de skorları kaydırır.

2. Üretim izlerini izole, çalıştırılabilir veri setlerine çevirin

Foundry’nin iz veri seti üretimi (project_client.datasets.begin_create_generation_job), Application Insights’taki üretim izlerinden projenizde kayıtlı, sürümlü bir veri seti örnekliyor. max_samples ayarlandığında MinHash örneklemesi tekrar eden mesajları eleyip çeşitli konuşmaları seçiyor. agent_version sabitlenerek tek bir bilinen sürümün davranışı örnekleniyor ve özel içerik varsayılan olarak gizleniyor (redact_private_content=True). Örneğin bir sipariş iade ajanında işaretlenen izler genellikle üç hata kalıbı gösteriyor:

• Zaman aşımından sonra güvensiz tekrar: Ajan submit_refund çağırıyor, çağrı outcome_unknown ile zaman aşımına uğruyor ve ajan ilk isteğin durumunu kontrol etmeden yazma isteğini tekrarlıyor. Arka uç da mükerrer işlemleri engellemeli.
• Asenkron işte erken tamamlandı iddiası: Ajan get_refund_status adımını atlayıp işlem hâlâ beklerken iadeyi tamamlandı olarak bildiriyor.
• Güvenilmeyen araç verisinde prompt injection: Ajan bir müşteri iade notundaki (untrusted_return_note) enjekte metne uyup doğrulanmamış bir durum bildiriyor.

Kayıtlı izlerden güvenli test çalıştırmaya

Üretilen veri seti konuşma geçmişini yakalıyor. Bunları güvenli ve tekrarlanabilir değerlendirme vakalarına çevirmek için doğrulanmış beklenen sonuçlar ve sandbox’lı bir test arka ucu gerekiyor. Tüm değerlendirme çalıştırmaları canlı ödeme API’lerinden ve müşteri veritabanlarından izole edilmeli:

• Beklenen sonuçları gözden geçirin (ground_truth): Her izi inceleyip doğrulanmış iş sonucunu (status, order_id, refund_id, reason) ekleyin; orijinal yanıtı tarihsel kayıt olarak saklayın.
• Araç çalıştırmayı test ortamında izole edin: Her vakayı kontrollü araç kopyalarına ve sıfırlanabilir bir test veritabanına bağlayın; her çalıştırma bu sandbox’a karşı yeni araç çağrıları yapsın.
• Optimizer verisini sürüm regresyon setinden ayırın: Vakaları Agent Optimizer için eğitim ve doğrulama setlerine (2a) bölün, CI/CD sürüm kapısı için ayrı bir regresyon seti (2b) tutun. Aynı olaya ait tüm istekleri aynı bölümde tutun.

3. eval.yaml ve değerlendiricileri sabit gereksinimlere göre yapılandırın

eval.yaml dosyası taban ajan yapılandırmasını, eğitim ve doğrulama setlerini, değerlendiricileri ve onaylı model arama alanını birbirine bağlıyor:

name: Refund agent configuration search
agent:
  name: refund-release-loop
  kind: hosted
  model: gpt-5.4-mini
  config: .agent_configs/baseline/metadata.yaml
dataset:
  name: refund-loop-training
  version: "1"
validation_dataset:
  name: refund-loop-validation
  version: "1"
evaluators:
  - builtin.task_adherence
  - name: refund-state
    version: "3"
options:
  eval_model: gpt-5.4-mini
  optimization_model: gpt-5.4
  max_candidates: 4
  optimization_config:
    model_search_space:
      - gpt-5.4-mini
      - gpt-5.4

Ayrılmış regresyon setini (refund-loop-release) ayrı bir CI/CD değerlendirme yapılandırmasında tutun ki Agent Optimizer arama sırasında bu vakalara erişip onlara aşırı uyum sağlamasın.

Sürüm kriterlerini aday talimatlardan bağımsız tutun

builtin.task_adherence gibi prompt değerlendiricileri talimat sapmasını yakalıyor; Agent Optimizer ise performansı artırmak için instructions.md ve SKILL.md dosyalarını yeniden yazıyor. Bu yüzden her aday, düzenlenebilir yapılandırmanın dışında tutulan sabit iş gereksinimlerine göre puanlanmalı:

Araçla desteklenen iddialarda builtin.groundedness kullanmak için serileştirilmiş araç çıktılarını bağlam olarak verin ve değerlendirici girdilerinde eşleyin. Testten önce kalite tabanını, hedef artışı ya da maliyet tasarrufunu ve izin verilen regresyon marjını belirleyin; örnekleme belirsizliğini ayrıca değerlendirin. Aşağıdaki örnek özel kod değerlendirici mantığı, mükerrer iade gönderimlerini ve doğrulama aracıyla ya da defterle uyuşmayan durum iddialarını engelliyor:

# Illustrative custom code evaluator logic
submissions = [e for e in events if e["tool"] == "submit_refund"]
if len(submissions) > 1:
    failures.append("repeated_submission")

verifications = [e["result"] for e in events if e["tool"] == "get_refund_status"]
claimed = output.get("status")
if claimed in {"completed", "pending", "failed"}:
    if not verifications or verifications[-1].get("status") != claimed:
        failures.append("unverified_claim")
    if not ledger or ledger[-1].get("status") != claimed:
        failures.append("claim_state_mismatch")

Özel kod değerlendiricileri ağ erişimi olmayan izole bir ortamda çalıştığı için değerlendirme ortamı, oluşan sandbox durum anlık görüntüsünü her değerlendirme öğesine ekliyor.

4. Agent Optimizer’ı çalıştırın

eval.yaml hazır olunca ajan projesinin kökünden Agent Optimizer’ı çalıştırın:

azd ai agent optimize

Komut eval.yaml‘ı otomatik buluyor. Agent Optimizer önizlemede; desteklenen bayraklar ve bölgeler için optimizasyon hızlı başlangıcına bakın. İş sırasında .agent_configs/baseline/ puanlanıyor, eğitim görevlerinden en fazla max_candidates aday üretiliyor ve adaylar doğrulama setinde sıralanıyor:

Seçilen talimatları, skill’leri, modeli ve araç açıklamalarını çalışma zamanında load_config() ile yükleyin. Uygulama mantığını, yetkilendirmeyi ve araç sözleşmelerini optimizasyon kapsamı dışında tutun. Örnekteki zaman aşımı senaryosunda bir aday, iade skill’ini ve araç açıklamalarını önce get_refund_status kontrol edecek şekilde güncelleyebiliyor.

5. Adayı GitHub Actions’ta sürüm kapısından geçirin

Agent Optimizer’da bir aday seçtikten sonra yapılandırmasını .agent_configs/ klasörüne uygulayıp inceleme için pull request açın:

azd ai agent optimize apply --candidate <candidate-id>

GitHub Actions iş akışı Microsoft Entra ID ile Azure’a giriş yapıyor ve canlı trafik v1’de kalırken dört adımlı bir sürüm kapısı çalıştırıyor:

• Aday sürümü (v2) dağıtın: azd deploy --no-prompt ile aday container’ı uç nokta seçicisini (v1) değiştirmeden kaydedin.
• İki sürümü ayrılmış sette değerlendirin: refund-loop-release üzerinde v1 ve v2 için bulut değerlendirmeleri çalıştırın (ya da sürüm başına azd ai agent eval run).
• Puanları ve kaynak metriklerini toplayın: Tüm değerlendirici skorlarını, gecikme metriklerini ve token sayılarını alın.
• Sürüm politikasını uygulayın: v2’yi 1. adımdaki hedefe göre v1 ile karşılaştırın; politika başarısızsa sıfır dışı kodla çıkın.

Değerlendirme işinin sağlığını ajan performansından ayırın: Her vaka eksiksiz bir değerlendirme kaydı ve tüm gerekli skorları döndürmeli; eksik kayıtlar ya da başarısız değerlendirici işleri sürümü her zaman engellemeli. Hatalı yanıt gibi ajan çalışma hatalarını görev başarısızlığı olarak puanlayın. Tek bir hata kalıbını düzeltmek tüm sürüm gereksinimlerini karşılamaya yetmez.

6. Canary yayını, terfi ve sonraki döngü

Ayrılmış seti geçmek, adayın bu testlerin kapsadığı gereksinimleri karşıladığını gösteriyor. Tam terfiden önce canlı trafik dört adımda doğrulanmalı:

• Duman testi: version_indicator v2 olarak ayarlanmış sentetik oturumlarla container başlangıcını, kimlik bilgilerini ve araç bağlantılarını doğrulayın.
• Canlı kontrol grubuyla canary: Barındırılan uç noktalar varsayılan trafiğin tamamını v1’e gönderiyor. Minimum örnek sayısını, gözlem penceresini ve eşikleri baştan belirleyin; yeni oturumların bir dilimini (önce %5, sonra %25) v2’ye yönlendirin.
• Sonuçların oturmasını bekleyin: v1 ve v2 yeterli skor, metrik ve tamamlanmış iade sonucu toplayana kadar bekleyin.
• Terfi et, bekle ya da geri al:

Geri almada hem oturum yönlendirmesini hem arka uç durumunu planlayın. Canary sırasında version_indicator‘ı temizlemek yeni oturumları varsayılan sürüme (v1) gönderiyor. Terfiden sonra geri almak için uç nokta seçicisini v1’e çevirmek gerekiyor. Mevcut v2 oturumları açıkça durdurulana (örneğin project_client.agents.stop_session) ya da bitene kadar v2’de devam ediyor. Canary sırasında gönderilmiş işlemler için arka uçta idempotency anahtarları ve telafi edici geri alma işlemleri kullanın.

v2 trafiğin tamamına terfi ettikten sonra sürüm otomasyonu yapılandırmasını yeni taban olarak .agent_configs/baseline/‘a kaydediyor; v1 tüm aktif oturumlar bitene kadar kullanılabilir kalmalı. Ayrılmış setin güncel trafiği temsil etmesi için düzenli olarak hem eğitim setlerine hem sürüm setine yeni, gözden geçirilmiş üretim izleri ekleyin; bu, tek bir sabit test setine aşırı uyum riskini azaltıyor.

Rehberin en önemli mesajı, optimizer’ın göremediği ayrı bir regresyon seti tutmak ve sürüm kriterlerini düzenlenebilir talimatların dışında sabitlemek. Agent Optimizer önizlemede; sandbox’lı araç ortamı, ground truth etiketleri ve canary yönlendirmesi ise uygulama ekibinin hazırlaması gereken parçalar.

Kaynak: https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/improve-production-agents-with-closed-loop-evaluations-in-microsoft-foundry/4569762