Deep Agents + Cosmos DB: Operasyonel Veride Plan-Eylem-Doğrulama
Birkaç haftadır LangGraph üstünde dolaşan ajan mimarilerine kafa yoruyorum. Açık konuşayım, “tek prompt-tek cevap” devri yavaş yavaş geride kalıyor gibi geliyor bana. Artık mesele, bir LLM’in sırayla düşünüp araç çağırması, çıktıyı okuması, kararını yeniden tartması ve sonra bir araç daha çalıştırması. E peki, sonuç ne öldü? İşte Deep Agents tam bu noktada devreye giriyor — Azure Cosmos DB ile yan yana gelince de işin rengi baya değişiyor.
Lafı dolandırmayayım: Microsoft DevBlogs’ta Abhishek Gupta’nın yayınladığı “Support Ops Agent” örneği — yanı destek bileti kuyruğunu yöneten ajan — pratikte gördüğüm en derli toplu “operasyonel veriyle çalışan ajan” demosu olabilir. Bugün hem bu yapıya dürüst gözle bakacağım hem de Türkiye’deki kurumsal müşterilerde nasıl karşılık bulur, ona değineceğim.
Evet, doğru duydunuz.
Deep Agents Tam Olarak Ne, Neden Önemli?
Klasik bir LangChain ajanını düşünün (bizzat test ettim). Tool çağırıyor, sonucu alıyor, sonraki adımı seçiyor. Güzel. Ama iş uzayınca tablo biraz dağılıyor; context window doluyor, ajan az önce ne yaptığını unutabiliyor, tool çıktıları prompt’u şişiriyor ve en kötüsü de kilit bir veri değişikliği öncesinde “dur bakalım” diyebileceğiniz net bir kapı olmuyor.
Şunu fark ettim: Deep Agents, LangGraph üstüne kurulmuş bir agent harness. Yanı ajanın etrafına geçirilen, ona biraz disiplin veren bir iskelet gibi düşünebilirsiniz. Üç tane işe yarar parçası var:
- Skills: Talimatları prompt’a boca etmek yerine ihtiyaç anında yüklüyor. Token tarafında baya iş görüyor.
- Offload: Büyük tool çıktıları context’i boğmasın diye dışarı taşıyor. (bu kritik)
- Human-in-the-loop onay: Veri değiştirecek bir adımdan önce ajan dürüyor, “bunu yapayım mı?” diye soruyor. — bunu es geçmeyin
Bir de kendi içinde todo listesi tutuyor; küçük gibi dürüyor ama sahada etkisi büyük. Evet. Multi-step iş yapan ajanların 5-6 adımdan sonra “ben neyi çözüyordum?” moduna girdiğini ben de çok gördüm. Bu liste o hafıza kaymasını epey azaltıyor.
Support Ops Agent: Demo Senaryosu
Peki demo ne yapıyor? Bir müşteri destek bileti kuyruğu üzerinde çalışıyor. Şöyle sorular sorabiliyorsunuz:
- Hangi biletler riskli? SLA kaçırma ihtimali olanlar hangileri?”
- Kim şu an fazla yük altında?”
- Son 2 saatte gelen 7 benzer şikayet var; burada outage kokusu var mı?”
- Bu bileti çöz, kapat ve ilgili tarafları logla.” — bunu es geçmeyin
Bilet verisi Azure Cosmos DB for NoSQL’de tutuluyor. Ekip zaten operasyonel veritabanını orada kullanıyor. Ajan da gidip yan tarafta ayrı bir indeks aramıyor; doğrudan canlı veriyle konuşuyor. Bence burada asıl kıymet pek konuşulmuyor: birçok ajan demosunda “önce vektör DB’ye senkronlayalım, sonra oradan okuyalım” yaklaşımı var. Ama destek operasyonu gibi taze verinin kilit olduğu yerlerde ayrı indeks = gecikme = yanlış karar riski demek.
Hangi İstek, Hangi Cosmos Operasyonuna Düşüyor?
Aşağıdaki tablo ajanın yaptığı işleri Cosmos DB tarafındaki karşılığıyla özetliyor (ciddiyim). Bakınca aslında ortada sihir değil, düzgün tool tasarımı olduğunu görüyorsunuz.
| İstek | Ajanın Yaptığı | Cosmos DB Operasyonu |
|---|---|---|
| Kuyruk triyajı | Riskli biletleri bul, gerçekten önemli olanları raporla | Cross-partition query, ORDER BY |
| Bilet çözümü | Point read yap, ilgili biletleri ara, durum/sahip/history güncelle, sonra tekrar oku doğrula | Point read + query + patch + verify read |
| Outage tespiti | Müşteriler arasında benzer sorun kümesi bul, “known issue” etiketi baş | Multi-step query + tekrarlı patch |
| Kuyruk sağlığı | Status, alan ve sorumlu kişi bazında özet çıkar | Aggregation query |
Neden Cosmos DB Bu İşe Yakışıyor?
Bak şimdi, burada atlanmaması gereken birkaç teknik nokta var. Cosmos DB’nın bu senaryoya uymasının üç ana nedeni var:
Şunu söyleyeyim, Birincisi, esnek şema (evet, doğru duydunuz). Ajan bir bilete yeni etiket ekleyebilmeli ya da history dizisine kayıt iliştirebilmeli; yoksa her seferinde ilişkisel tarafta ekstra uğraş çıkıyor. JSON document yapısı sayesinde bu iş çok daha rahat ilerliyor.
Doğrusu, İkincisi, partition key disiplini. Müşteri bazlı sorgular ve point read’ler ucuz kalıyor; yanı “şu müşterinin son 10 bileti” sorusu birkaç RU ile dönebiliyor. Ama dikkat: kuyruk geneline yayılan sorular (“bütün açık high-priority biletler”) cross-partition’a düştüğü için RU faturasını kabartabiliyor. O yüzden ajanın kullandığı tool’lar projection yapıyor; sadece lazım olan alanlar çekiliyor. Daha fazla bilgi için
Outage Tespiti
Tam da öyle.
“
Aynı anda farklı müşterilerden gelen benzer şikayetleri düşünün — kelimeler farklı olsa bile anlam aynı kalabiliyor (“login olamıyorum”, “auth hatası”, “giriş yapamıyorum”).
Ajan keyword cluster’larını tarayıp ortak paterni yakalarsa bunları topluca “known issue”-vari bir etiketle işaretleyebiliyor.
Böylece destek ekibi elli ayrı bilete tek tek cevap yazmak yerine tek incident üstünden ilerleyebiliyor.
Kısacası gürültü azalıyor.
Production’da bu tip sorguları rate-limit etmek veya continuation token ile sayfalama yapmak iyi fikir olabilir.
Aksi hâlde tek bir “ajanı boş bırak” anı ay sonunda faturayı beklenmedik biçimde büyütebilir.
“>
Türkiye’deki Kurumsal Gerçeklik: Bu Yapı Bize Uyar mı?
Lokal tarafa geçeyim biraz.
Yıllardır bulut göç projelerinde gördüğüm şey şu:
Türkiye’deki kurumlar ajan teknolojisine meraklı. Üç temel kaygıyla yaklaşıyorlar:
“Bizim veri içeride kalsın”, “halüsinasyon olmasın”, “audit trail olsun”.
Deep Agents ile Cosmos DB kombinasyonu bu üç kaygıyı da fena olmayan şekilde adresliyor:
- |Veri yerinde kalmaya devam ediyor| ayrı vektör DB senkronu gerekmiyor | bilet veritabanına doğrudan erişiliyor.|
Sıkça Sorulan Sorular
Deep Agents, LangChain’in yerini mi alıyor?
Hayır, aslında tam tersi. Deep Agents, LangGraph’ın üstüne kurulu bir harness — yanı LangChain ekosisteminin doğal bir uzantısı gibi düşünebilirsiniz. Hani tek seferlik basit ajan işleri için biraz fazla ağır kaçıyor. Çok adımlı, uzun süreli, veri yazma içeren işlerde gerçekten fark yaratıyor.
Cosmos DB yerine PostgreSQL kullansam ne kaybederim?
JSON esnekliği ve global dağıtım kolaylığını kaybedersiniz. PostgreSQL’in JSONB desteği fena değil aslında, ama document-first bir yapı değil. Bir de patch API muadili biraz daha zahmetli oluyor. Yine de küçük ölçekte PostgreSQL pekâlâ yapar bu işi — özellikle ekibiniz SQL’e hâkimse bence makul bir tercih.
Approval gate olmadan production’a çıkmak güvenli mi?
Açıkçası bence değil. En azından can alıcı alanlar için — mesela status değişimi, ticket silme, müşteriye gönderilen mesajlar — human-in-the-loop olmadan canlıya almak ciddi risk taşıyor. LLM halüsinasyonu gerçek bir şey ve tecrübeme göre beklenmedik anlarda karşınıza çıkıyor (bizzat test ettim). Approval gate’i her şeye değil, kritik aksiyonlara akıllıca konumlandırın.
RU maliyeti tahmin edilebilir mi?
Bence, Tam değil, ama yaklaşık bir fikir verebilirim: point read ~1 RU, küçük patch ~10 RU, filtreli cross-partition query işe 50-500 RU arası gidiyor. Ajan başına günlük 1000 etkileşim varsayarsak kabaca 100K-500K RU/gün çıkıyor. Serverless modda bu birkaç dolar/gün ediyor yanı. Provisioned’a geçmeyi düşünüyorsanız autoscale max RU cap’i genelde kullanın — bence bu konuda gevşek davranmamak lazım.
Türkçe destek biletleriyle çalışır mı?
Evet çalışıyor, ama LLM seçimi burada gerçekten önemli. GPT-4 sınıfı modeller Türkçe’de gayet iyi iş çıkarıyor. Hani embedding modeli kullanacaksanız Türkçe’ye uyumlu olmasına dikkat edin — bu noktayı atlamamak lazım. Hani ne farkı var diyorsunuz, değil mi? Keyword arama tarafı zaten Cosmos üzerinde dil bağımsız çalışıyor.
Kaynaklar ve İleri Okuma
Orijinal makale: How to Use Deep Agents with Azure Cosmos DB (Microsoft DevBlogs)
Azure Cosmos DB Partial Document Update (Patch API) Dokümantasyonu
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
3 comments