BİLGİSAYAR ERİŞİM SİSTEMİ

Üretimde Ajan Sistemleri: Dört Gerçek Dünya Vaka Çalışması


Üretimde Ajan Sistemleri: Dört Gerçek Dünya Vaka Çalışması

Ajan demoları etkileyicidir. Ajan dağıtımları ise dağınıktır. “Kendi bilgisayarımda çalışıyor” ile “üretimde çalışıyor” arasındaki boşluk; kenar durumlarla, beklenmedik maliyetlerle ve hiçbir eğitim materyalinin sizi hazırlamadığı hata modlarıyla doludur.

Hepimiz o parlak demoyu görmüşüzdür: bir ajan iki dakikalık ekran kaydında uçak bileti ayarlıyor, rapor yazıyor ve hata kaydı oluşturuyor. Görmediğiniz şeyler ise ilk haftadaki %40 yükseltme oranı, sorgu başına 12 dolarlık API faturası ya da veri bozulması sorununu düzeltmek yerine daha da kötüleştiren ajandır.

Bu dört vaka çalışması bu boşluğu kapatıyor. Gerçek mimarileri, gerçek rakamları ve üretim ajan dağıtımlarından gerçek hataları ele alıyor. Her vaka çalışması bağımsız olarak sunulmuştur—dördünü birden okuyabilir ya da kendi kullanım durumunuza uyan birini seçebilirsiniz.

Neler öğreneceksiniz:

  • Her sistemin nasıl tasarlandığı ve neden
  • Neyin işe yaradığı, neyin feci biçimde başarısız olduğu
  • Somut metrikler: doğruluk, maliyet, gecikme süresi ve insan müdahale oranları
  • Farklı alanlara uygulanabilecek çıkarılan dersler

Vaka Çalışması 1: Müşteri Destek Önceliklendirme Ajanı

Problem

Orta ölçekli bir SaaS (Hizmet Olarak Yazılım) şirketi günde 500’den fazla destek talebi alıyor. Birinci kademe yanıtlar—şifre sıfırlama, fatura soruları, bilinen hata geçici çözümleri—destek ekibinin zamanının yaklaşık %60’ını tüketiyor. Zor sorunları çözmesi gereken mühendisler, aynı on soruyu tekrar tekrar kopyalayıp yapıştırıyor.

İş hedefi açıktı: müşteri memnuniyetini düşürmeden birinci kademe çözümü otomatize etmek.

Mimari

┌─────────────────────────────────────────────────┐
│ Incoming Ticket │
└──────────────────────┬──────────────────────────┘
┌────────────────┐
│ Router Agent │
│ (Intent Class.)│
└──┬───┬───┬──┬─┘
│ │ │ │
┌────────┘ │ │ └────────┐
▼ ▼ ▼ ▼
┌─────────┐ ┌────────┐ ┌──────┐ ┌──────────┐
│ Billing │ │Technical│ │Account│ │ Feature │
│ Handler │ │ Handler │ │Handler│ │ Request │
└────┬────┘ └───┬────┘ └──┬───┘ └────┬─────┘
│ │ │ │
└──────────┴────┬────┴───────────┘
┌──────────────────┐
│ Confidence Check │
│ ≥ 0.85 → Reply │
│ < 0.85 → Human │
└──────────────────┘

Araçlar ve entegrasyonlar:

  • Talep sistemi API’si (Zendesk) talepleri okumak ve yanıtlamak için
  • Bilgi tabanı araması (yardım makaleleri üzerinde vektör deposu)
  • Müşteri verisi sorgulama (hesap durumu, abonelik katmanı, son etkileşimler)

Temel yapılandırma:

router_agent:
model: gpt-4o-mini
system_prompt: |
You are a support ticket classifier. Classify into exactly one category:
billing, technical, account, feature_request.
Return JSON: {"category": "...", "confidence": 0.0-1.0, "summary": "..."}
temperature: 0.0
handler_agents:
escalation_threshold: 0.85
max_knowledge_base_results: 5
response_tone: "professional, empathetic, concise"

Sonuçlar

MetrikÖnceSonraDeğişim
İnsan müdahalesi olmadan çözülen 1. kademe talepler%0%70+%70
Ortalama yanıt süresi4 saat3 dakika-%98,75
Müşteri memnuniyeti (CSAT)4,2/54,1/5Önemli değişiklik yok
Yükseltme oranı%15 (ayar sonrası)
Talep başına maliyet (destek iş gücü)8,50 $2,40 $-%72

Neler Başarısız Oldu

İlk haftada aşırı yükseltme. Başlangıçtaki yükseltme oranı %40’tı. Yönlendirici ajan fazla temkinli davranıyordu—belirsiz ifade içeren her talep bir insana yönlendiriliyordu. Çözüm: güven eşiğini 0,95’ten 0,85’e düşürmek ve yönlendirici istemine sınır durumundaki talepler için az sayıda örnek (few-shot) eklemek.

Faturalandırma kenar durumları. Kısmi iadeler, itiraz edilen ücretler ve çok hesaplı faturalandırma, nüanslı insan yargısı gerektiriyordu. Ajan, politikanın yalnızca kısmi iadeye izin verdiği durumlarda zaman zaman tam iade teklif ediyordu. Çözüm: para içeren faturalandırma eylemleri için sabit kodlanmış kurallar. Ajan politikayı açıklayabilir ancak 20 doların üzerindeki finansal işlemleri insan onayı olmadan gerçekleştiremez.

Eski bilgi tabanı. Ajan, iki ay önce değişmiş bir kullanıcı arayüzü akışını anlatan bir yardım makalesine atıfta bulundu. Müşteri talimatları izledi, kafası karıştı ve öfkeyle konuyu yükseltti. Çözüm: otomatik tazelik kontrolleri—90 günden uzun süredir güncellenmemiş makaleler işaretlenir ve ajan eski içeriklere atıfta bulunurken bir sorumluluk reddi beyanı ekler.

Çıkarılan Dersler

  • En kolay kategoriden başlayın. SSS tarzı hesap soruları en yüksek otomasyon oranına sahipti. Faturalandırma en sona bırakıldı.
  • Yalnızca çözüm oranını değil, müşteri memnuniyetini de ölçün. Sinirli bir müşteriyle sonuçlanan çözülmüş bir talep başarı sayılmaz.
  • Bilgi tabanı tazeliği, ajan kalitesi kadar önemlidir. Dünyanın en iyi ajanı bile güncel olmayan belgeleri telafi edemez.

Vaka Çalışması 2: Araştırma ve Rapor Oluşturma Ajanı

Problem

Bir danışmanlık ekibi, haber API’leri, finansal veritabanları ve dahili belgeler gibi birden fazla veri kaynağından pazar araştırması raporları derlemek için haftada 8–12 saat harcıyor. Raporlar tutarlı bir yapıyı takip ediyor ancak veri toplama işlemi sıkıcı ve hataya açık. Analistler zamanlarının büyük bölümünü analiz etmek yerine veri toplamakla geçiriyor.

Mimari

┌────────────────────────────────────┐
│ Research Brief (User) │
└──────────────────┬─────────────────┘
┌──────────────────┐
│ Orchestrator Agent│
│ (Task Decomposer)│
└──┬──────┬──────┬─┘
│ │ │
┌──────┘ │ └──────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌───────────┐
│ News │ │ Financial│ │ Internal │
│ Worker │ │ Worker │ │ Doc Worker│
└────┬─────┘ └────┬─────┘ └─────┬─────┘
│ │ │
└──────┬──────┴─────────────┘
┌───────────────┐
│Synthesis Agent│
│(Report Writer)│
└───────┬───────┘
┌───────────────┐
│ Review Agent │
│(Verification) │
└───────┬───────┘
┌───────────────┐
│ Final Report │
│ (w/ Citations)│
└───────────────┘

Araçlar ve entegrasyonlar:

  • Haber API’si (NewsAPI, Google News) güncel olaylar ve sektör haberleri için
  • Finansal veri API’si (Alpha Vantage, dahili veri ambarı) piyasa verileri için
  • Dahili belge araması (geçmiş raporlar ve müşteri özetleri üzerinde vektör deposu)
  • Yapılandırılmış çıktı oluşturma (Markdown → PDF ardışık düzeni)

Temel yapılandırma:

orchestrator:
model: gpt-4o
decomposition_strategy: "parallel_by_source"
max_sub_tasks: 8
synthesis_agent:
citation_requirement: "Every factual claim MUST include [Source: ...] inline"
output_format: "structured_markdown"
sections:
- executive_summary
- market_overview
- competitive_landscape
- financial_highlights
---
## İlgili Makaleler
- [Ajan Hata Kurtarma: Üretim Güvenilirliği için 5 Desen](/tr/blog/agent-error-recovery-patterns/)
- [Çok Ajanlı Desenler: Orkestratörler, İşçiler ve Boru Hatları](/tr/blog/multi-agent-patterns/)
- [Özerk Ajan Sistemlerinde Hata Ayıklama ve Gözlemlenebilirlik](/tr/blog/debugging-agent-observability/)
- [AI Ajanları için Önbellekleme Stratejileri: Maliyetleri Kısmadan Kaliteyi Korumak](/tr/blog/caching-strategies-for-ai-agents-cutting-costs-without-cutting-corners/)
- [Araç Kullanım Desenleri: Güvenilir Ajan-Araç Arayüzleri Oluşturma](/tr/blog/agent-tool-use-patterns/)