Bir müşteri temsilcisini düşünün. Aynı müşteriyle haftalarca çalışmış, onun tercihlerini, geçmişteki sorunlarını, beklentilerini öğrenmiş. Şimdi aynı senaryoyu bir yapay zeka ajanıyla kurmaya çalışın. Teknik altyapı doğru kurulmadığında ajan, her konuşmada adeta ilk kez karşılaşıyormuş gibi davranır. Geçmiş bağlam yok, öğrenilen tercihler yok, süreklilik yok.
Bu sadece kullanıcı deneyimini bozan bir kusur değil. Kurumsal ölçekte konuşlandırılan yapay zeka sistemlerinde bellek yönetimi, başarı ile başarısızlık arasındaki en kritik fark haline geliyor. Ve bu sorunu çözmek için doğru altyapıyı seçmek, projenin geri kalanı kadar önemli.
Sorun Göründüğünden Daha Derin
Pek çok ekip, yapay zeka ajanı projesine başlarken bellek sorununu hafife alır. İlk prototipler genellikle gayet iyi çalışır: Birkaç mesajlık sohbet geçmişi modelin bağlamına eklenir, ajan tutarlı yanıtlar üretir, herkes memnundur.
Sorun ölçek büyüdükçe ortaya çıkar.
Gerçek üretim ortamında bir ajan; yüzlerce farklı kullanıcıyla, günler hatta haftalar boyunca süren etkileşimler yürütür. Her kullanıcının geçmişi büyür. Tüm bu geçmişi her seferinde modelin bağlamına doldurmaya çalışmak kaçınılmaz olarak iki kritik soruna yol açar:
Çözüm, hafızayı tek bir büyük yığın olarak değil, amacına göre ayrıştırılmış katmanlar olarak yönetmekten geçiyor.
Belleği Doğru Sınıflandırmak: Üç Katmanlı Mimari
Modern ajan mimarileri, bilişsel psikolojiden ödünç alınan ve CoALA (Cognitive Architectures for Language Agents) gibi çerçevelerin de benimsediği bir yaklaşımla belleği üç temel kategoride ele alır. Bu sınıflandırma teorik bir egzersiz değil; her kategorinin farklı depolama, erişim ve güncelleme stratejisi gerektirdiğini kabul eden pratik bir mühendislik kararıdır.
1. Prosedürel Bellek: Ajanın Davranış Kuralları
Prosedürel bellek, ajanın ne bildiğini değil, nasıl davrandığını tanımlar. Bir anıyı ne zaman kaydedeceği, konuşmayı ne zaman özetleyeceği, hangi araçları hangi sırayla kullanacağı, bir kullanıcı sorusunu nasıl yorumlayacağı — bunların tamamı prosedürel belleğe aittir.
Bu bellek türü, uygulama kodunda ve sistem prompt’larında yaşar. Elasticsearch’e kaydedilmez; aksine Elasticsearch’i kullanan mantığı barındırır. Prosedürel belleği iyi tasarlamak, diğer iki bellek türünün ne zaman ve nasıl devreye gireceğini belirler. Zayıf bir prosedürel bellek, en iyi veri altyapısını bile işlevsiz kılar.
2. Epizodik Bellek: Kişisel Geçmiş ve Deneyimler
Epizodik bellek, ajanın belirli kullanıcılarla yaşadığı geçmiş etkileşimlerin kaydıdır. “Bu kullanıcı geçen ay hangi sorunu yaşadı?”, “Hangi çözüm önerisini reddetti?”, “Hangi ürünü tercih ettiğini söyledi?” — bu soruların yanıtları epizodik bellekte yatar.
Bu bellek türünün en kritik özelliği izolasyon gereksinimidir. Bir kullanıcının epizodik anıları başka bir kullanıcıya kesinlikle sızmamalıdır. Bu hem gizlilik hem de doğruluk açısından zorunludur. A kullanıcısının tercihleri B kullanıcısının bağlamına karışırsa, ajan anlamsız ve potansiyel olarak zararlı yanıtlar üretir.
3. Semantik Bellek: Paylaşılan Bilgi Tabanı
Semantik bellek, ajanın erişebildiği genel, paylaşılan bilgi havuzudur. Ürün dokümantasyonu, şirket politikaları, teknik kılavuzlar, SSS içerikleri, prosedür belgeleri — bunların tamamı semantik bellekte yer alır. Geleneksel RAG mimarilerinin çalıştığı alan tam olarak burasıdır.
Semantik bellek kullanıcıdan kullanıcıya değişmez; tüm ajanlara ve tüm kullanıcılara açık olan ortak bilgi deposudur. Ancak bu belleğin de akıllıca yönetilmesi gerekir: Hangi bilginin güncel olduğu, hangi bölümün hangi sorgu türüyle erişileceği, bilginin nasıl parçalanıp indeksleneceği kritik tasarım kararlarıdır.
Elasticsearch Bu Mimaride Neden Öne Çıkıyor?
Bu noktada şu soru akla geliyor: Bu üç bellek türünü yönetmek için neden Elasticsearch? Piyasada vektör veritabanları, ilişkisel veritabanları, özel bellek framework’leri mevcut. Her biri belirli bir sorunu çözüyor. Elasticsearch’ü bu senaryolarda ayrıştıran şey, tek bir platformda birden fazla kritik ihtiyacı karşılaması.
Hibrit Arama: Semantik + Anahtar Kelime, Aynı Anda
Saf vektör araması, anlam benzerliğine göre sonuç getirir. Kullanıcı “fatura sorunum var” dediğinde, “ödeme problemi” veya “invoice issue” gibi semantik olarak yakın içerikler de bulunur. Bu güçlü bir özelliktir.
Ancak gerçek dünyada yeterli değildir. Kullanıcı “PRD-2024-447 numaralı sipariş” dediğinde, bu tam eşleşme gerektiren bir sorgudur; semantik benzerlik burada işe yaramaz. Ya da teknik bir hata kodu, bir ürün SKU’su, bir sözleşme numarası arandığında vektör araması yetersiz kalır.
Elasticsearch’ün hibrit arama yaklaşımı; ELSER (Elastic Learned Sparse EncodeR) ile sağlanan sparse semantik erişimi, dense vektör aramasını ve BM25 tabanlı anahtar kelime eşleşmesini RRF (Reciprocal Rank Fusion) aracılığıyla tek bir sorguda birleştirir. Sonuç: Hem anlamı hem de tam ifadeyi yakalayan, üretim ortamında güvenilir bir arama katmanı.
Metadata Filtreleme: Arama Alanını Daraltmak
Epizodik belleği yönetirken en büyük tehlikelerden biri, alakasız anıların arama sonuçlarına karışmasıdır. Elasticsearch’ün yapısal metadata filtreleme özelliği, semantik aramadan önce arama alanını daraltır.
Örneğin bir ajan şunu yapabilir: Önce user_id = “12345“, memory_type = “episodic” ve timestamp > “son 90 gün” filtrelerini uygula, sonra bu daraltılmış küme içinde semantik arama yap. Bu yaklaşım üç kritik avantaj sağlar:
Bu filtreleme mantığı, Elasticsearch’ün arama indeksi yapısına doğal olarak entegre olur; güvenlik ve izolasyon kuralları uygulama katmanına sızmak yerine veri katmanında tanımlanır.
Belge Düzeyinde Güvenlik: Güvenliği Uygulama Katmanından Çıkarmak
Epizodik belleğin kullanıcılar arasında izole edilmesi gerektiğini söyledik. Bunu uygulamanın iki yolu var: Ya uygulama koduna her sorguda “sadece bu kullanıcının verilerini getir” mantığını yazarsınız, ya da bu güvenliği veritabanı katmanına taşırsınız.
İlk yaklaşım, her geliştirici her yeni özellik eklediğinde güvenlik açığı riski taşır. Bir filtre unutulur, bir edge case gözden kaçar ve kullanıcı verileri birbirine karışır.
Elasticsearch’ün Document-Level Security (DLS) özelliği, bu güvenliği indeks katmanına taşır. Her kullanıcı rolü için sorgu düzeyinde filtreler tanımlanır. Ajan, Melis’ın kimlik bilgileriyle sorgu yaptığında Elasticsearch otomatik olarak yalnızca Melis’e ait anıları döndürür. Uygulama kodu bu güvenliği yönetmek zorunda değildir; altyapı bunu garanti eder.
Bu yaklaşım, özellikle çok kiracılı (multi-tenant) kurumsal uygulamalarda hem güvenlik hem de geliştirici verimliliği açısından kritik bir avantaj sağlar.
Çoklu İndeks Mimarisi: Her Bellek Türüne Özel Yapı
Üç bellek türünün farklı erişim örüntüleri vardır. Epizodik anılar sık sık yazılır ve okunur; semantik bilgi tabanı daha az güncellenir ama daha geniş kitlelere açıktır; oturum verileri kısa ömürlüdür ve hızlı erişim gerektirir.
Elasticsearch’ün çoklu indeks mimarisi, her bellek türünü ayrı bir indekste tutmayı mümkün kılar. Bu sayede:
Bu mimari, monolitik bir “her şeyi tek tabloya koy” yaklaşımının aksine, sistemin büyüdükçe yönetilebilir kalmasını sağlar.
Somut Bir Senaryo: Kurumsal Müşteri Hizmetleri Ajanı
Teoriden pratiğe geçmek için gerçekçi bir kurumsal senaryo üzerinden gidelim.
Bir B2B yazılım şirketinin müşteri hizmetleri ajanını düşünün. Bu ajan, yüzlerce kurumsal müşteriyle çalışıyor. Her müşterinin farklı bir sözleşme yapısı, farklı bir kullanım senaryosu, farklı bir teknik altyapısı var.
Semantik bellek katmanında şunlar yer alır: Ürün dokümantasyonu, bilinen hata ve çözümleri, sürüm notları, entegrasyon kılavuzları. Bu bilgiler tüm müşterilere açıktır ve Elasticsearch’te vektör indeksiyle depolanır. Müşteri “API rate limiting nasıl çalışıyor?” diye sorduğunda ajan bu indekse başvurur.
Epizodik bellek katmanında şunlar yer alır: Her müşterinin geçmiş destek talepleri, uygulanan çözümler, reddedilen öneriler, bildirilen hatalar. “Geçen ay yaşadığımız senkronizasyon sorununu hatırlıyor musun?” sorusuna ajan bu katmandan yanıt üretir. Belge düzeyinde güvenlik sayesinde Müşteri A’nın destek geçmişi Müşteri B’ye asla görünmez.
Prosedürel bellek katmanında şunlar yer alır: Hangi sorunun hangi ekibe yönlendirileceği, ne zaman özet çıkarılacağı, hangi bilginin epizodik belleğe kaydedileceği. Bu mantık uygulama kodunda yaşar ve Elasticsearch’i ne zaman, nasıl kullanacağını belirler.
Müşteri “Geçen seferki sorunumuz çözüldü mü, bir de yeni bir hata var” dediğinde ajan şu adımları izler:
Tüm bu süreçte LLM’e gönderilen bağlam, tüm konuşma geçmişi değil, seçici olarak getirilen ilgili bilgilerdir. Bu hem yanıt kalitesini artırır hem de maliyeti kontrol altında tutar.
Ölçek ve Maliyet: Üretim Ortamının Gerçekleri
Prototip aşamasında bellek yönetimi maliyeti göz ardı edilebilir. Ancak milyonlarca kullanıcı etkileşimini depolayan, her gün binlerce yeni anı ekleyen bir üretim sisteminde tablo farklıdır.
1.536 boyutlu vektör gömme (embedding) kullanan bir sistemde 10 milyon anıyı depolamak, standart float32 formatında yaklaşık 61 GB bellek gerektirir. Elasticsearch’ün BBQ (Better Binary Quantization) niceleme teknolojisi, bu bellek gereksinimini %95 oranında azaltarak yaklaşık 3 GB’a düşürür. Üstelik bu niceleme, geri çağırma (recall) doğruluğunu anlamlı biçimde düşürmez; bazı senaryolarda iyileşme bile gözlemlenir.
Bu rakamlar soyut görünebilir, ancak pratik etkisi açıktır: Aynı altyapı maliyetiyle çok daha büyük bir bellek tabanı yönetilebilir hale gelir. Yatay ölçekleme, altyapı maliyetlerini kontrol dışına çıkarmadan mümkün olur.
Token maliyeti tarafında da benzer bir etki söz konusudur. Seçici bellek erişimi, LLM’e gönderilen ortalama bağlam boyutunu küçültür. Büyük ölçekli sistemlerde bu, aylık token maliyetlerinde ciddi tasarruf anlamına gelir.
Gözlemlenebilirlik: Ajanın Ne Yaptığını Anlamak
Bellek yönetiminin sıklıkla göz ardı edilen bir boyutu daha var: gözlemlenebilirlik. Ajan hangi anıları getirdi? Hangi bilgiyi bağlama ekledi? Neden bu yanıtı üretti?
Elasticsearch’ün arama altyapısı, bu soruları yanıtlamak için gereken iz verilerini (trace data) doğal olarak üretir. Hangi sorgunun hangi sonuçları döndürdüğü, hangi filtrelerin uygulandığı, hangi skorların hesaplandığı — bunların tamamı izlenebilir ve analiz edilebilir.
Bu gözlemlenebilirlik, ajan davranışını iyileştirmek için kritiktir. “Ajan neden yanlış yanıt verdi?” sorusunu yanıtlamak, bellek katmanında neyin yanlış gittiğini anlamakla başlar. Elasticsearch’ün Kibana entegrasyonu, bu analizi görsel ve erişilebilir kılar.
Elasticsearch'ü Bu Senaryolarda Konumlandırmak
Tüm bu teknik detayların ötesinde, kurumsal karar vericiler için şu soruyu yanıtlamak gerekiyor: Elasticsearch’ü yapay zeka ajan mimarisinde nasıl konumlandırmalıyız?
Elasticsearch bu senaryolarda akıllı bellek katmanı olarak konumlanır. Sadece bir vektör veritabanı değil, sadece bir arama motoru değil; her ikisinin güçlü yanlarını birleştiren, üzerine güvenlik, ölçeklenebilirlik ve gözlemlenebilirlik inşa edilmiş bir platform.
Pratik konumlandırma şöyle özetlenebilir:
Sonuç: Bellek Bir Özellik Değil, Mimari Bir Karardır
Yapay zeka ajanlarını gerçekten kullanışlı kılan şey, ne kadar zeki oldukları değil; ne kadar iyi hatırladıklarıdır. Bağlamı koruyan, geçmişten öğrenen, her kullanıcıya özel deneyim sunan bir ajan inşa etmek, bellek mimarisini ciddiye almakla başlar.
Elasticsearch, bu mimarinin merkezine oturduğunda yalnızca bir depolama çözümü olmaktan çıkar. Ajanın anlayışını, sürekliliğini ve güvenilirliğini mümkün kılan aktif bir bileşen haline gelir. Semantik anlayış, yapısal filtreleme, güvenlik izolasyonu ve ölçeklenebilirlik — bunların tamamını tek bir platformda sunması, Elasticsearch’ü bu alanda rakiplerinden ayrıştıran temel özelliktir.
Yapay zeka projenizin bellek katmanını nasıl tasarlamanız gerektiği konusunda daha fazla bilgi almak veya mevcut mimarinizi değerlendirmek için bizimle iletişime geçebilirsiniz.
Elasticsearch
kurulum, göç ve danışmanlığı
Deneyimli ekibimizle Elasticsearch çözümleri kurulum, göç ve danışmanlık hizmetlerimizle sizlerin yanındayız.
Elasticsearch çözümlerinden abonelik ve kurumsal destek almak mı istiyorsunuz?
