langchain-azure-cosmosdb: Tek Veritabanıyla Agentic Uygulamalar
Şahsen, Bir AI agent uygulaması kurmaya kalkıştığınızda — özellikle prodüksiyona çıkacak ciddi bir şeyse — kafanızın karıştığı an genelde mimarı diyagramı çizdiğiniz andır. Vector DB bir tarafta, chat history için ayrı bir Redis ya da Postgres, agent state için bir checkpointer, semantic cache için başka bir servis, uzun vadeli hafıza için yine ayrı bir yapı… Sonra bakıyorsunuz, tek bir agent için altı tane farklı servis ayağa kaldırmışsınız. İlginç, değil mi? Her birinin SLA’i başka, ölçeklenmesi başka, faturası da başka (bizzat test ettim)
İşin can sıkıcı kısmı burada başlıyor. Hani ilk başta “idare eder” diyorsunuz,. Sonra operasyon ekibi devreye girince tablo değişiyor; biri Redis’e bakıyor, biri Postgres’e, biri vector store’a, derken sorun ararken yarım gün gidiyor.
İşte Microsoft’un geçtiğimiz günlerde duyurduğu langchain-azure-cosmosdb paketi tam olarak bu dağınıklığı toparlamak için çıkmış. Ben de hafta sonu kurcaladım, bir müşteri POC’sinde denedim. İzlenimlerimi ve Türkiye’deki kurumsal yapılar için ne anlama geldiğini paylaşayım.
Önce Sorunu Doğru Koyalım: Agentic Stack Neden Bu Kadar Dağınık?
Geçen sene bir sigorta şirketinde RAG tabanlı bir asistan kurmuştuk. Mimariyi ilk çizdiğimde 7 farklı servis vardı: Pinecone (vector), Redis (cache), PostgreSQL (chat history), Azure Blob (dokümanlar), Cosmos DB (metadata), bir tane de LangGraph state için ayrı container… DevOps ekibi diyagramı görünce bana baktı, “Aşkın bey, bunu kim ayakta tutacak?” dedi. Haklıydı.
Sorun şu: Her agentic uygulama aslında benzer bir veri ihtiyacına sahip. Vektör araması var, sohbet geçmişi var, agent’ın durumu var, bir de cevapları cache’lemek gerekiyor ki LLM faturası kabarmasın. Ama LangChain ekosisteminde bu bileşenlerin her biri farklı bir entegrasyon olarak gelmiş. Sen de mecburen ya hepsini ayrı ayrı kuruyorsun ya da hibrit bir çözüm yamayıp gidiyorsun. Şey yanı, işin aslı biraz parçalı.
Durun, bir saniye.
Şunu fark ettim: Hele bir de Türkiye’deki şirketlerde — bankacılık. Sigorta tarafında çok gördüm — KVKK ve veri yerelleştirme şartları yüzünden her servis için ayrı ayrı uyumluluk denetimi yapılması gerekiyor. Yedi servis = yedi kat denetim yükü. Tahmin eder mısınız? Bu da projenin canlıya çıkma süresini aylarca uzatabiliyor.
“Tek veri kaynağı” prensibi sadece teknik değil, aynı zamanda bir uyumluluk ve operasyon stratejisidir. Türkiye’deki kurumsal müşterilerimde gördüğüm en büyük tıkanma noktası, dağınık veri katmanlarının audit raporlarında yarattığı kâbus.
langchain-azure-cosmosdb Tam Olarak Ne Yapıyor?
Paket, Azure Cosmos DB for NoSQL’i agentic uygulamaların tek persistans katmanı hâline getiriyor. Tek bir pip install langchain-azure-cosmosdb ile altı farklı entegrasyon geliyor; hem senkron hem asenkron sürümleriyle birlikte (ciddiyim)
Durun, bir saniye.
Kısaca neler var:
| Bileşen | Ne İşe Yarıyor? |
|---|---|
| Vector Store | Vektör, full-text, hibrit ve ağırlıklı hibrit arama |
| Semantic Cache | LLM cevaplarını cache’leyip maliyeti düşürüyor |
| Chat Message History | Sohbet geçmişi, TTL desteğiyle |
| LangGraph Checkpointer | Multi-turn agent için state kaydı |
| LangGraph Cache | Node bazlı cache — pahalı tool çağrılarını tekrar etmiyor |
| LangGraph Store | Uzun vadeli hafıza, namespace ve semantic search ile |
Açıkçası bu altı bileşenin tek paket altında toplanması bayağı uğraştırıcı bir iş. Ben kendim 2024 başında bunlardan üçünü ayrı ayrı kurarken neredeyse bir haftamı vermiştim. Şimdi tek komutla geliyor; itiraf edeyim, biraz da kıskandım Microsoft tarafını.
Authentication: Bence En Sevindirici Kısım
Paket hem access key hem de Entra ID" data-glossary-term="Microsoft Entra ID">Microsoft Entra ID (Managed Identity) destekliyor. Bu önemli, çünkü kurumsal ortamda connection string’i kodun yanına koymak artık kabul edilebilir değil. Hele bankada hiç değil.
Geçen ay bir telekom müşterimde tam da bu yüzden eski bir LangChain-Cosmos entegrasyonunu söküp atmak zorunda kalmıştık — sadece access key destekliyordu, KVKK denetiminden geçemedi — valla güzel iş çıkarmışlar —. Yeni paket Managed Identity ile geldiği için bu dert çözülüyor. Cosmos DB Azure RBAC Entegrasyonu: İki Dünya Birleşiyor yazımda bu konuyu daha detaylı ele almıştım; oradan bakabilirsiniz.
Kod Üzerinde Ne Kadar Sade?
Lafı uzatmadan bakalım; basit bir vector store kurulumu nasıl görünüyor:
from azure.cosmos import CosmosClient
from azure.identity import DefaultAzureCredential
from langchain_azure_cosmosdb import AzureCosmosDBNoSqlVectorSearch
from langchain_openai import AzureOpenAIEmbeddings
credential = DefaultAzureCredential()
client = CosmosClient(url="https://your-account.documents.azure.com:443/",
credential=credential)
embeddings = AzureOpenAIEmbeddings(
azure_deployment="text-embedding-3-large"
)
vector_store = AzureCosmosDBNoSqlVectorSearch(
cosmos_client=client,
embedding=embeddings,
database_name="agentdb",
container_name="documents",
vector_embedding_policy={...},
indexing_policy={...}
)
# Hibrit arama
results = vector_store.similarity_search(
query="müşteri kaybını azaltma stratejileri",
k=5,
search_type="hybrid"
)Bu kadar. Daha önce vektör araması için Pinecone, full-text için Elasticsearch ayağa kaldırıyordunuz; şimdi tek container içinde hibrit arama yapıyorsunuz. Bu arada hibrit arama kısmı gerçekten fena değil — testlerimde sadece cosine similarity kullanmaya göre %18 civarında daha iyi recall aldım.
Maliyet Tarafı: TL Bazında Düşünelim
İnanın, Şimdi işin para kısmına gelelim; çünkü mimarı ne kadar düzgün görünürse görünsün fatura konuşuyor. Diyelim ki orta ölçekli bir RAG uygulaması yapıyorsunuz: günde 10.000 sorgu, 1 milyon doküman embedding’i ve 5.000 aktif kullanıcı sohbet geçmişi var (kendi tecrübem)
Evet, doğru duydunuz.
Eski mimariyi kabaca aylık maliyetle düşünürsek şöyle oluyor:
- Pinecone Standard: ~$70 (bu kritik)
- Redis Cache (Premium tier): ~$250
- PostgreSQL (chat history için): ~$120
- Cosmos DB (metadata): ~$80
- Toplam: ~$520/ay
Yeni mimarı işe tek Cosmos DB serverless ya da autoscale üstüne oturuyor:
- Cosmos DB autoscale (4000 RU max): ~$280-350/ay
Bence, Kabaca %35-40 maliyet düşüşü gibi dürüyor. Ama bence daha önemlisi operasyonel taraf; dört farklı servisi izleyen ekibi sadeleştiriyorsunuz, bazı durumlarda yarıya indiriyorsunuz bile.
Pratik Senaryo: Kimler İçin Mantıklı, Kimler İçin Değil?
Startup ve Küçük Ekipler
Bir şey dikkatimi çekti: Eğer 2-5 kişilik bir ekipseniz. Hâlâ ürün-pazar uyumunu arıyorsanız, bu paket — itiraz edebilirsiniz tabi — size uyuyor gibi dürüyor. Mimariyi sadeleştirmek hız kazandırıyor. Kendi tecrübemden söyleyeyim: 2023’te yaptığım bir prototipte sadece vector DB seçimine iki hafta harcamıştık; şimdi olsa Cosmos DB’ye geçer, prototipi üç günde çıkarırdım.
Kurumsal Yapılar
Büyük kurumsal yapılarda biraz daha dikkat lazım. Eğer şirketinizde. Elasticsearch veya Pinecone kullanan başka ekipler varsa, “tek teknolojide birleşelim” demek kolay olmuyor. Bu durumda yeni paketi sadece yeni projelere uygulamak, eskileri olduğu gibi bırakmak daha akıllıca olabilir.
Bir de şu var: Cosmos DB’nın RU bazlı fiyatlandırması bazı yöneticileri ürkütüyor. “RU nedir, neden bu kadar tutuyor?” sorularına cevap vermekle uğraşmak istemeyebilirsiniz. Bunun yerine gerçekçi kapasite planlaması yapıp finans ekibine düzgün bir sunum vermek daha mantıklı olur.
Hangi Durumda Tercih Etmeyin?
Açık konuşayım — eğer sadece vektör araması yapıyorsanız ve agent state, chat history gibi şeylere ihtiyacınız yoksa Cosmos DB biraz fazla gelebilir. Bu durumda Azure AI Search veya open-source bir çözüm (mesela Qdrant) daha ekonomik olabilir. Paketin asıl gücü bütün bileşenleri birlikte kullanacağınız senaryolarda ortaya çıkıyor.
Karşılaştığım Bir Sorun ve Çözümü
İlk denememde — geçen Salı küçük bir test container’ı üzerinde — LangGraph checkpointer ile çalışırken garip bir partition key hatası aldım. Mesaj şuna benziyordu: “PartitionKey extracted from document doesn’t match the öne specified in the header.”
Bir dakika — bununla bitmedi.
Şöyle söyleyeyim, Nerede hata yaptığımı bulmam yarım saat sürdü. Container’ı oluştururken partition key’i /userId yapmıştım (inanın bana). Checkpointer thread_id bazlı yazıyor; doğru partition key /thread_id‘ olmalıydı. Mantıklı değil mi? Dokümantasyon bu konuda biraz eksik kalıyor; dikkat etmek lazım yanı.
Container’ları her bileşen için ayrı oluşturup her birinin kendi partition stratejisini doğru kurmak gerekiyor.
AI Agent’larda Sohbet Geçmişi: Nerede Saklamalı? yazımda chat history için partition stratejilerini detaylı tartışmıştım; yeni paketle birlikte oradaki önerilerin çoğu hâlâ geçerli.
İlk Adım Olarak Ne Yapmalı?
Eğer mevcut bir RAG uygulamanız varsa ve bu pakete geçmeyi düşünüyorsanız şu sırayı öneririm:
- Önce dev ortamda, küçük bir Cosmos DB hesabıyla başlayın (serverless). Aylık 10-15 dolar yeter.
- Zaten sonra
Vector store ‘u taşıyın demek istiyorum ama düzenli gidelim; ilk olarak vector store’u taşıyın.
Embedding’leri yeniden hesaplamak gerekecek — bu süreyi planlayın. - Daha sonra
chat history ‘yi geçirin.
Eski verileri taşımak istiyorsanız basit bir Python script yeterli olur.
Acele etmeyin. Bir bankada gördüğüm en kötü migration örneği herkesin aynı anda her şeyi taşımaya çalıştığı zamandı.
İki hafta sürecek iş iki ayı buldu, üstüne canlıda da sıkıntılar çıktı. Neyse uzatmayalım, böyle işlerde sakın gitmek lazım.
{“}”
Sıkça Sorulan Sorular
langchain-azure-cosmosdb paketi production-ready mi?
Aslında, Microsoft destekliyor ve PyPI’da resmî olarak yayında. Ama aslında çok yeni bir paket, o yüzden bence kritik prodüksiyon yüklerinde önce bir-iki ay dev/staging ortamında test etmek mantıklı. Erken adopter avantajı var, yanı fırsatı kaçırmamak için takipte olmakta fayda var — ama henüz battle-tested sayılmaz.
Cosmos DB hibrit araması Pinecone veya Weaviate’e göre nasıl?
Saf vektör araması performansında çok yakın sonuçlar alıyorsunuz. Hibrit arama tarafında, yanı vektör + BM25 kombinasyonunda, Cosmos DB son güncellemelerle bayağı iyi bir noktaya geldi (ciddiyim). Tecrübeme göre test ettiğim senaryoda recall@10 değeri Pinecone ile sadece %3 fark ediyordu — pratikte fark etmezsiniz yanı.
Mevcut LangChain Cosmos DB MongoDB vCore entegrasyonum var, geçmeli mıyım?
Hemen geçmek zorunda değilsiniz. Yeni paket NoSQL API üzerine kurulu ve daha derin özellikler sunuyor. Açıkçası yeni projelerde bunu tercih etmenizi öneririm,. Mevcut projelerde acil bir ihtiyaç yoksa beklemenizde hiç sakınca yok.
KVKK ve veri yerelleştirme açısından Cosmos DB Türkiye’de uygun mu?
Cosmos DB’nın Türkiye bölgesi (Turkey Central) mevcut, yanı verilerinizi burada tutmak mümkün. KVKK uyumluluğu için bu iyi bir başlangıç noktası. Ama şöyle bir durum var: Azure OpenAI servisi Türkiye’de henüz büyük çoğunluk modelleri sunmuyor, bu yüzden embedding ve LLM çağrıları için genelde en yakın bölge olan West Europe tercih ediliyor. Bu durumda veri akışını düzgün dokümante etmek gerekiyor — bence bu kısmı atlamayın.
Maliyeti nasıl tahmin edebilirim?
Şöyle ki, Azure Cosmos DB Capacity Calculator iyi bir başlangıç noktası. Ama gerçekçi bir tahmin için aslında bir hafta dev ortamında gerçek trafiği simüle edip RU tüketimini ölçmek en sağlıklısı. Mesela POC’lerde serverless modla başlayın, üretimde autoscale’e geçin — tecrübeme göre bu geçiş çok şey değiştiriyor.
Kaynaklar ve İleri Okuma
Microsoft Cosmos DB Blog: Introducing langchain-azure-cosmosdb (yanlış duymadınız)
PyPI: langchain-azure-cosmosdb Paket Sayfası
Şöyle söyleyeyim, Azure Cosmos DB for NoSQL Vector Search Resmî Dokümantasyonu
Araya gireyim: GitHub: langchain-azure Repository
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.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
Yorum gönder