Yapay Zeka Ajanlarında Bellek Mimarileri: Kısa ve Uzun Vadeli Hafızayı Tasarlamak

TL;DR — Yapay zeka ajanları için bellek, "modelin ne kadar akıllı olduğu" kadar önemli bir tasarım problemi. Belleği kabaca ikiye ayırıyoruz: bağlam penceresinin içinde yaşayan kısa vadeli hafıza (sistem mesajı, sohbet geçmişi, son araç çağrıları, düşünce zinciri) ve oturumlar arasında kalıcı olan uzun vadeli hafıza (kullanıcı tercihleri, görev geçmişi, öğrenilmiş bilgi). Uzun vadeli hafıza kendi içinde semantik (gerçekler), prosedürel (iş akışları) ve epizodik (geçmiş olaylar) olarak üçe ayrılıyor. Bu yazıda ikisini de üretim ortamına nasıl taşıyacağınızı; vektör veritabanı, özet tamponları, bellek skorlama/çürütme politikaları, ACE (Agentic Context Engineering) döngüsü, "context rot" ve bellek zehirlenmesi gibi arıza modlarını; ve KVKK açısından veri saklamanın getirdiği yükümlülükleri somut bir referans mimari ve kontrol listesiyle anlatıyorum.

Bir ajanı ilk kez üretime aldığınızda karşılaştığınız hayal kırıklığı çoğu zaman modelin zekasıyla ilgili değildir. Model soruyu anlıyor, aracı doğru çağırıyor, cevabı güzel yazıyor. Ama üçüncü mesajda kullanıcının iki tur önce söylediği şeyi unutuyor; ya da yarın aynı kullanıcı geldiğinde onu hiç tanımıyormuş gibi davranıyor. Sahada gördüğüm en yaygın sorun bu: ajanın "beyni" iyi, ama "hafızası" yok ya da yanlış tasarlanmış. Bu yazıyı, danışmanlık yaptığım ekiplerde defalarca çizdiğim beyaz tahta şemasını yazıya dökmek için hazırladım.

Büyük dil modelleri durumsuzdur (stateless). Her API çağrısında modele gönderdiğiniz her şey o an için "dünyanın tamamı"dır; çağrı bittiğinde model hiçbir şey hatırlamaz. Sohbet uygulamalarında bu gerçeği geçmişi tekrar tekrar göndererek gizleriz. Ama bir ajan haftalarca süren bir görevi yürütüyorsa, yüzlerce araç çağrısı yapıyorsa ve aynı kullanıcıyla aylar boyunca çalışıyorsa, "her şeyi tekrar gönder" stratejisi hem imkansız hem de pahalı hale gelir.

Bellek mühendisliği tam da bu boşluğu doldurur: hangi bilginin bağlam penceresine girmesi gerektiğine, hangisinin dışarıda kalıcı bir depoda tutulup ihtiyaç anında geri çağrılacağına ve hangisinin tamamen unutulacağına karar verme sanatı. Bu, prompt yazmaktan farklı bir beceri; daha çok bir işletim sisteminin sanal bellek yöneticisini tasarlamaya benziyor. Sınırlı ve pahalı bir "RAM" (bağlam penceresi) ile büyük ve ucuz bir "disk" (kalıcı depo) arasında sürekli veri taşıyorsunuz.

Şunu erkenden içselleştirmenizi öneririm: bağlam penceresini büyütmek belleği çözmez. 200 bin, hatta bir milyon token'lık pencereler bile "her şeyi içeri tıkıştır" stratejisini kurtarmaz, çünkü aşağıda anlatacağım "context rot" olgusu devreye girer. Bellek bir kapasite problemi değil, bir seçicilik problemidir.

Kısa vadeli hafıza, o anki API çağrısında modele gönderdiğiniz her şeydir. Bunu şöyle parçalara ayırabiliriz:

• Sistem mesajı: Ajanın kimliği, görevi, kuralları, üslubu. Genelde uzun ve statiktir.
• Çalışma belleği (working memory): İçinde bulunulan görevin o anki durumu — hangi adımdayız, hangi ara sonuçları elde ettik, kullanıcı neyi onayladı.
• Sohbet geçmişi: İnsan ve asistan mesajlarının sırası.
• Son araç çağrıları ve sonuçları: Ajanın az önce çağırdığı fonksiyonlar ve döndürdükleri veri.
• Düşünce zinciri (chain-of-thought): Modelin akıl yürütme izleri, plan adımları.

Bu bileşenlerin hepsi aynı sınırlı token bütçesini paylaşır. Görev uzadıkça sohbet geçmişi ve araç çıktıları şişer; bir noktada pencereye sığmaz. İşte burada iki klasik strateji devreye girer: kesme (truncation) ve özetleme (summarization).

Kesme mi, özetleme mi?

Kesme en basit yöntemdir: en eski mesajları at, son N mesajı tut. Kayan pencere (sliding window) mantığı. Hızlı, öngörülebilir, ucuz. Ama acımasız — iki saat önce kullanıcının verdiği kritik kısıtı (örneğin "bütçe 50 bin TL'yi geçmesin") çöpe atabilir.

Özetleme daha zariftir: eski turları modele özetletip yerine kısa bir özet koyarsınız. Böylece bilgiyi korurken yer açarsınız. Ama burada sahada sık gördüğüm bir tuzak var: aşırı özetleme (over-summarization). Uzun bir diyaloğu her seferinde yeniden özetlerseniz, özetin özetinin özetini alırsınız ve her turda biraz daha bilgi buharlaşır. Kullanıcının 40. mesajda söylediği ince bir tercih, 60. mesaja gelindiğinde özet zincirinde erimiş olur. Ajan aniden "neden bunu unuttun?" sorusuyla karşılaşır.

Pratikte ben hibrit bir yaklaşım öneriyorum:

"

Son K turu ham (verbatim) tutun, ondan öncesini yuvarlanan bir özete sıkıştırın; ama kritik "gerçekleri" (kullanıcı kısıtları, kararlar, kimlik bilgileri) özetin dışında yapılandırılmış bir "çalışma belleği" bloğunda ayrı ayrı saklayın.

Böylece özetleme kayıplarının en çok canınızı yakacağı bilgiyi özet akışından çıkarıp koruma altına almış olursunuz. Çalışma belleği bloğu bir JSON gibi düşünülebilir: kullanıcı adı, dil tercihi, aktif hedef, onaylanan bütçe, kesinleşmiş kararlar. Bu bloğu her turda deterministik olarak yeniden yazarsınız; modele "unutma" demeye çalışmazsınız.

Context rot: uzayan bağlam neden kaliteyi düşürür?

Sezgimiz "daha fazla bağlam = daha iyi cevap" der. Gerçek daha karmaşık. Bağlam penceresi doldukça modelin dikkati dağılır; alakasız ya da tekrar eden bilgi, ilgili sinyali gölgeler. Bu olguya sektörde context rot (bağlam çürümesi) deniyor: bağlam büyüdükçe, özellikle içine gürültü, eski araç çıktıları ve tekrar eden özetler biriktikçe, çıktı kalitesi kademeli olarak düşer. Model teknik olarak 200 bin token'ı "görebilir" ama bunların hepsine eşit ve doğru şekilde dikkat edemez.

Bunun pratik sonucu şudur: bağlam penceresini bir çöp tenekesi gibi kullanmayın. Her araç çıktısını, her ara adımı, her ham log satırını içeri atmak kısa vadede kolaydır ama ajanı yavaş yavaş körleştirir. Bağlamı küratörlükle yönetmek — neyin girip neyin çıkacağına bilinçli karar vermek — üretim ajanlarının en önemli, en az konuşulan işidir.

Kısa vadeli hafıza görev bitince ya da pencere temizlenince kaybolur. Uzun vadeli hafıza ise oturumlar, günler, aylar boyunca kalır. İnsan bilişinden ödünç alınan bir sınıflandırmayla üç alt türe ayırıyoruz:

1. Semantik hafıza — gerçekler ve yeniden kullanılabilir bilgi

Semantik hafıza, bağlamdan bağımsız gerçeklerdir: "Bu kullanıcı bir e-ticaret şirketinin CFO'su", "Şirketin mali yıl sonu 31 Aralık", "Ürün iade politikası 14 gün". Zamana ve olaya bağlı değil; genel doğrular ve yeniden kullanılabilir akıl yürütme kalıpları. Bir müşteri destek ajanında semantik hafıza, ürün kataloğu ve politika bilgisidir. Genelde bir vektör veritabanında ya da yapılandırılmış bir bilgi tabanında tutulur ve ihtiyaç anında getirme (retrieval) ile bağlama enjekte edilir.

2. Prosedürel hafıza — iş akışları ve stratejiler

Prosedürel hafıza "nasıl yapılır" bilgisidir: bir iadeyi işleme adımları, bir raporun hangi sırayla derleneceği, belirli bir hata türüyle karşılaşınca izlenecek strateji. İnsanlardaki "kas hafızası"nın karşılığı. Ajan bir görevi başarıyla tamamladığında, izlediği adımları bir "oyun kitabına" (playbook) yazabilir ve sonraki benzer görevlerde bunu yeniden kullanabilir. Prosedürel hafıza genellikle sistem mesajına ya da araç açıklamalarına gömülür; bazı mimarilerde ayrı bir "strateji deposu" olarak tutulur.

3. Epizodik hafıza — geçmiş olayların ayrıntılı bağlamı

Epizodik hafıza belirli, tarihli olayların hatırasıdır: "Geçen salı bu kullanıcı X sorununu bildirdi, biz Y çözümünü önerdik, işe yaramadı." Zengin, bağlamsal, olaya özgü. Kişiselleştirmenin ve süreklilik hissinin kalbi budur. Kullanıcı "geçen sefer konuştuğumuz o konu" dediğinde ajanın onu hatırlamasını sağlayan şey epizodik hafızadır. Pratikte her önemli etkileşimi zaman damgasıyla vektör deposuna yazar, ilgili anıları semantik benzerlikle geri çağırırsınız.

Aşağıdaki tablo bu ayrımları özetliyor:

Bellek türü	Ne saklar	Yaşam süresi	Tipik uygulama
Kısa vadeli / çalışma	Görevin o anki durumu, son turlar	Oturum / pencere	Bağlam penceresi, özet tamponu
Semantik	Gerçekler, politikalar, genel bilgi	Kalıcı	Vektör DB, bilgi tabanı
Prosedürel	İş akışları, stratejiler, playbook	Kalıcı	Sistem mesajı, strateji deposu
Epizodik	Tarihli olaylar, geçmiş etkileşimler	Kalıcı	Vektör DB (zaman damgalı)

Şimdi bu kavramları gerçek sistemlere nasıl dönüştüreceğinize gelelim. Sahada işe yarayan birkaç somut kalıp var.

Vektör veritabanı ile epizodik ve semantik geri çağırma

En yaygın kalıp: önemli bilgileri gömme (embedding) vektörlerine çevirip bir vektör deposunda (pgvector, Qdrant, Weaviate, Pinecone gibi) saklamak. Yeni bir kullanıcı mesajı geldiğinde, mesajı vektöre çevirir, depoda en benzer K anıyı bulur ve bunları bağlama enjekte edersiniz. Bu, klasik RAG'ın (retrieval-augmented generation) belleğe uygulanmış halidir.

Dikkat edilmesi gereken üç şey var. Birincisi, neyi yazacağınız: her mesajı ham haliyle yazmak deponuzu gürültüyle doldurur. Genelde etkileşimden çıkarılmış "hatırlanmaya değer" bir özet yazmak daha iyidir ("Kullanıcı Türkçe iletişim tercih ediyor ve teknik derinliği seviyor"). İkincisi, nasıl getireceğiniz: sadece semantik benzerlik yetmez; yakınlık (recency), önem (importance) ve alaka (relevance) skorlarını birleştiren hibrit bir sıralama çoğu zaman daha iyi çalışır. Üçüncüsü, ne zaman getireceğiniz: her turda değil, ajanın "bir şey hatırlamam gerekiyor" diye karar verdiği anlarda getirmek hem ucuz hem temizdir.

Özet tamponları (summarization buffers)

Kısa vadeli hafıza için yuvarlanan özet tamponu klasik ve etkili bir kalıptır. Sohbet geçmişini iki katmanda tutarsınız: sıcak katman (son K tur, ham) ve soğuk katman (daha eskiler, tek bir yuvarlanan özette). Yeni bir tur geldikçe en eski ham tur özete karışır. Kritik nokta, özet üretimini deterministik ve şablonlu tutmaktır: modele "önceki özeti güncelle, şu alanları koru" diye net talimat verin ki aşırı özetleme kaybı en aza insin.

Bellek skorlama ve çürütme (decay) politikaları

İnsan belleği unutur ve bu bir kusur değil, bir özelliktir. Ajan belleğinde de her anıyı sonsuza dek tutmak hem pahalı hem tehlikeli (aşağıdaki bayat bellek ve gizlilik konularına bakın). Bu yüzden her belleğe bir skor atarsınız ve bu skor zamanla çürür (decay). Basit bir formül:

"

skor = w1 * alaka + w2 * yakınlık + w3 * önem − w4 * yaş

Skoru belirli bir eşiğin altına düşen anılar arşivlenir ya da silinir. Önemli anılar (kullanıcının açıkça "bunu hatırla" dediği ya da tekrar tekrar erişilen anılar) yükseltilir; bir kez kullanılıp bir daha dokunulmayan anılar sönümlenir. Bu, hem token maliyetini hem de KVKK'nın veri minimizasyonu ilkesini aynı anda destekler.

2026'da öne çıkan yaklaşımlardan biri, bağlamı statik bir prompt gibi değil, sürekli evrilen bir "oyun kitabı" gibi ele almak. Agentic Context Engineering (ACE), bağlamı üç ajanlı bir döngüyle iyileştirir:

1. Generator (Üretici): Görevi çözmeye çalışır ve bir yörünge (trajectory) üretir — attığı adımlar, çağırdığı araçlar, aldığı sonuçlar.
2. Reflector (Yansıtıcı): Bu yörüngeyi inceler, hataları tespit eder, eksik bağlamı belirler. "Burada şu bilgiyi bilseydin farklı davranırdın" der.
3. Curator (Küratör): Yansıtıcının bulgularından öğrenmeleri çıkarır ve kalıcı bir bağlam oyun kitabına (context playbook) işler. Bir sonraki görevde Generator bu güncellenmiş playbook ile başlar.

Bu döngünün güzelliği, belleği sadece "veri saklama" olmaktan çıkarıp "deneyimden öğrenme" haline getirmesidir. Ajan hatalarından ders çıkarır ve bu dersler prosedürel hafızaya kalıcı olarak yazılır. Kendi ekiplerinize bunu anlatırken şu benzetmeyi kullanıyorum: Generator sahada oynayan futbolcu, Reflector maç sonrası analiz yapan antrenör, Curator ise taktik defterini güncelleyen teknik direktör. Oyuncu her maçta sıfırdan başlamaz; defter birikir.

Sahada ve literatürde şu yönelimleri net biçimde görüyorum:

• Hiyerarşik bellek: Sıcak/ılık/soğuk katmanlar. En sık erişilen bilgi bağlamda, orta sıklıktakiler hızlı bir önbellekte, gerisi vektör deposunda. İşletim sistemlerinin bellek hiyerarşisine çok benzer.
• Çoklu-ajan paylaşımlı bellek: Birden fazla ajanın ortak bir bellek katmanına yazıp okuması. Bir araştırma ajanının bulduğunu bir yazım ajanının kullanması. Burada tutarlılık ve kilitleme (concurrency) yeni zorluklar getirir.
• Getirme-destekli uzun vadeli bellek: Vektör deposu artık standart. Fark, saf benzerlikten hibrit ve graf-tabanlı getirmeye kayış.
• Bellek yazma/unutma politikaları: Neyin yazılacağı ve neyin unutulacağı artık açıkça tasarlanan bir politika. "Her şeyi sakla" devri bitiyor.

Bellek sistemlerinin kendine has kırılma biçimleri var. Bunları önceden bilmek, üretimde gece 3'te uyanmanızı önler.

Bellek zehirlenmesi (memory poisoning)

Ajan, belleğine yanlış ya da kötü niyetli bir bilgi yazarsa, bu bilgi sonraki tüm kararları kirletir. Daha da tehlikelisi, bir saldırgan kullanıcı mesajları yoluyla ajanın belleğine kasıtlı olarak yanlış "gerçekler" enjekte edebilir (dolaylı prompt injection'ın kalıcı hali). Ajan bunu semantik hafızasına yazarsa, zehir kalıcı olur. Savunma: belleğe yazmadan önce doğrulama katmanı, güvenilmeyen kaynaklardan gelen bilgiyi "iddia" olarak etiketleme, ve kritik belleklerde insan onayı.

Bayat bellek (stale memory)

Dünya değişir ama bellek değişmez. Kullanıcının altı ay önce yazdığı "şu an İstanbul'da yaşıyorum" bilgisi bugün yanlış olabilir. Ajan bayat bilgiye güvenerek yanlış kişiselleştirme yapar. Savunma: belleklere zaman damgası ve son-doğrulama tarihi eklemek, çürütme politikaları, ve çelişki tespit edildiğinde yeniyi tercih edip eskiyi geçersiz kılmak.

Gizlilik sızıntısı (privacy leakage)

En sinsi arıza. Ajan, bir kullanıcının belleğinde tuttuğu bilgiyi yanlışlıkla başka bir kullanıcıya ya da yanlış bağlama sızdırabilir. Çoklu-ajan paylaşımlı bellekte bu risk katlanır. Savunma: bellekleri katı biçimde kullanıcı/kiracı (tenant) bazında izole etmek, getirme sorgularına erişim kontrolü uygulamak ve hassas alanları maskelemek.

Ajanın belleğine kullanıcı verisi yazdığınız an, o bellek bir kişisel veri işleme faaliyeti haline gelir ve KVKK'nın (6698 sayılı Kanun) tüm yükümlülükleri devreye girer. Bunu üretim öncesi mimaride düşünmek, sonradan yamamaktan çok daha ucuzdur.

• Veri minimizasyonu: Ajan belleğine "her ihtimale karşı" her şeyi yazma dürtüsü, KVKK'nın ölçülülük ve amaçla bağlılık ilkesine doğrudan aykırıdır. Sadece belirtilen amaç için gerekli olanı saklayın. Skorlama ve çürütme politikaları burada teknik bir uyum aracıdır.
• Saklama süreleri: Her bellek türü için bir saklama süresi tanımlayın. Epizodik anılar sonsuza dek kalmamalı. Otomatik silme/arşivleme işleri kurun.
• Silme hakkı (unutulma hakkı): Kullanıcı "verilerimi sil" dediğinde, bunun vektör deposundaki gömme vektörlerini, özet tamponlarını ve kalıcı playbook'lardaki kişisel referansları da kapsaması gerekir. Uygulamada bu zordur çünkü kişisel veri özetlere ve gömmelere dağılmıştır. Bellek kayıtlarını kullanıcı kimliğiyle etiketleyip toplu silme yapabilecek şekilde tasarlayın.
• Aydınlatma ve açık rıza: Kullanıcıya, ajanın onunla ilgili bilgi hatırladığını ve bunu nasıl kullandığını şeffaf biçimde bildirin.
• Yurt dışına aktarım: Vektör deposu ya da LLM sağlayıcısı yurt dışındaysa, KVKK'nın aktarım rejimi ve varsa EU AI Act'in şeffaflık yükümlülükleri gündeme gelir. Yüksek riskli kullanımlarda AB AI Yasası'nın kayıt tutma ve insan gözetimi gereklilikleri de belleği ilgilendirir.

Kısacası: bellek sadece bir performans özelliği değil, aynı zamanda bir uyum yüzeyidir. Mimariyi çizerken hukuk ve güvenlik ekiplerini masaya erken davet edin.

Sahada önerdiğim katmanlı referans mimari şöyle görünüyor:

1. Orkestrasyon katmanı: Her turda hangi belleklerin bağlama gireceğine karar veren "bellek yöneticisi". Bir işletim sisteminin bellek yöneticisi gibi çalışır.
2. Çalışma belleği bloğu: Deterministik olarak yeniden yazılan yapılandırılmış durum (kullanıcı kısıtları, aktif hedef, kararlar). Özetleme kayıplarından korunur.
3. Özet tamponu: Sıcak (ham son turlar) + soğuk (yuvarlanan özet) iki katman.
4. Uzun vadeli depo: Vektör DB (epizodik + semantik) ve strateji deposu (prosedürel). Kullanıcı/kiracı bazında izole.
5. Bellek yazma servisi: Neyin, ne zaman, hangi doğrulamayla yazılacağını yöneten kapı. Zehirlenmeye karşı ilk savunma hattı.
6. Getirme servisi: Hibrit skorlama (alaka + yakınlık + önem), erişim kontrolü, maskeleme.
7. Bakım işleri: Çürütme, arşivleme, KVKK silme talepleri, tutarlılık denetimi.
8. Gözlemlenebilirlik: Hangi belleğin hangi karara etki ettiğini izleyen loglar — hem hata ayıklama hem denetim için.

Somutlaştıralım. Bir B2B SaaS şirketi için kurduğumuz destek ajanını düşünün. Aynı müşteri firmasındaki farklı kullanıcılar aylar boyunca ajanla konuşuyor. İlk versiyonda hiç uzun vadeli bellek yoktu; her konuşma sıfırdan başlıyordu. Kullanıcılar en çok "her seferinde aynı şeyi baştan anlatıyorum" diye şikayet etti. Belleği eklerken şu katmanları sırayla kurduk.

Önce çalışma belleği bloğunu ekledik: aktif destek talebinin numarası, ürün sürümü, daha önce denenmiş çözümler. Bu blok her turda yeniden yazılıyor ve özet akışının dışında tutuluyordu, böylece uzun bir konuşmanın ortasında bile ajan "hangi sürümdesiniz?" diye tekrar sormuyordu. Sonra epizodik hafızayı ekledik: her kapanan destek talebinin bir özeti (sorun, kök neden, çözüm, sonuç) zaman damgasıyla vektör deposuna yazılıyordu. Yeni bir talep açıldığında, benzer geçmiş talepler geri çağrılıyor ve ajan "bu firmada üç ay önce benzer bir sorun yaşanmıştı, o zaman şu işe yaramıştı" diyebiliyordu.

Kök nedenlerden öğrenilen tekrarlanabilir çözüm adımlarını ise prosedürel hafızaya, bir strateji deposuna yazdık. Zamanla ajan, belirli hata imzalarına karşı en etkili tanı sırasını kendisi biriktirdi. Burada ACE benzeri bir döngü kurmadık ama Reflector mantığını haftalık bir insan gözden geçirmesiyle taklit ettik: bir mühendis, başarısız konuşmaları inceleyip playbook'a düzeltme ekliyordu. Bu, tamamen otomatik bir döngüye geçmeden önce güvenli bir ara adımdı ve size de bunu öneririm — belleğe otomatik yazmayı, önce insan denetimli bir kapıdan başlatın.

Sonuç, çözüm süresinde belirgin bir iyileşme ve tekrar eden soruların gözle görülür azalması oldu. Ama asıl ders şuydu: değeri yaratan model değişikliği değil, belleğin doğru katmanlanmasıydı. Aynı modelle, belleği doğru tasarlayarak, ajan çok daha yetkin göründü.

Tek ajanlı sistemlerde bellek zaten zor; birden fazla ajan aynı belleği paylaşınca zorluk katlanıyor. Bir araştırma ajanının yazdığını bir planlama ajanı okuyor, bir uygulama ajanı güncelliyor. Burada klasik dağıtık sistem problemleri geri geliyor: yarış koşulları (race conditions), tutarsız okumalar, çelişen yazmalar.

Sahada işe yarayan birkaç ilke var. Belleği tek yazıcılı (single-writer) tutmaya çalışın: her bellek parçasının net bir "sahibi" olsun, başkaları sadece okusun. Yazma işlemlerini idempotent ve zaman damgalı yapın ki çelişki durumunda hangisinin kazanacağı belirli olsun. Ve paylaşımlı belleği olabildiğince "olaylar" (events) olarak modelleyin — üzerine yazılan bir durum yerine, biriken bir olay günlüğü çelişkileri çözmeyi kolaylaştırır. Bu ilkeler kulağa mikroservis mimarisinden tanıdık geliyorsa şaşırmayın; ajan belleği giderek daha çok bir dağıtık durum yönetimi problemine benziyor ve o alandaki birikimden faydalanmak akıllıca.

Belleği sadece bir kalite özelliği gibi görmeyin; doğrudan bir maliyet kalemi. Bağlama giren her token para. Bir ajan her turda gereksiz yere on binlerce token'lık geçmişi taşıyorsa, faturanız görevin karmaşıklığıyla değil, belleğinizin savurganlığıyla orantılı büyür. İyi tasarlanmış bir bellek — küratörlükle yönetilen bağlam, akıllı özetleme, ihtiyaç anında getirme — hem kaliteyi yükseltir hem faturayı düşürür. Bu ikisi burada nadiren çatışır; genelde birlikte iyileşir. Bir sonraki yazıda LLM maliyet optimizasyonunu ayrıntılı ele alırken, prompt önbelleğe almanın (prompt caching) neden ancak istikrarlı önekler (stable prefixes) varsa işe yaradığına değineceğim; bellek tasarımınız bu istikrarı ya kurar ya da bozar. Sistem mesajınızı ve prosedürel hafızanızı önekte sabit tutar, değişken kısımları sona koyarsanız, önbellek isabet oranınız ve dolayısıyla maliyetiniz belirgin biçimde iyileşir.

Bir ajan bellek sistemini üretime almadan önce şu listeyi ekibinizle birlikte geçin:

• Kısa ve uzun vadeli belleği net biçimde ayırdık mı?
• Kritik gerçekler (kullanıcı kısıtları, kararlar) özetleme akışının dışında, korunmuş bir çalışma belleği bloğunda mı?
• Özetleme aşırı özetlemeye karşı şablonlanmış ve deterministik mi?
• Bağlam penceresini gürültüyle mi dolduruyoruz, yoksa küratörlükle mi yönetiyoruz? (context rot kontrolü)
• Uzun vadeli belleği semantik / prosedürel / epizodik olarak sınıflandırdık mı?
• Vektör deposu getirme sıralaması saf benzerlikten öte hibrit skorlama içeriyor mu?
• Her belleğin skoru ve çürütme politikası var mı?
• Belleğe yazmadan önce doğrulama/etiketleme yapıyor muyuz? (zehirlenme savunması)
• Belleklerde zaman damgası ve tazelik takibi var mı? (bayat bellek savunması)
• Bellekler kullanıcı/kiracı bazında katı biçimde izole mi? (gizlilik sızıntısı savunması)
• KVKK: veri minimizasyonu, saklama süreleri, silme hakkı teknik olarak uygulanabilir mi?
• Yurt dışı aktarım ve EU AI Act şeffaflık yükümlülüklerini değerlendirdik mi?
• Hangi belleğin hangi karara etki ettiğini gösteren gözlemlenebilirlik var mı?

Her şeyi bir anda kurmaya çalışmayın. Sahada işe yarayan sıralama şu: Önce kısa vadeli hafızayı sağlamlaştırın — iyi bir özet tamponu ve korunan bir çalışma belleği bloğu, çoğu ajanın "unutkanlık" şikayetinin yüzde seksenini çözer. İkinci aşamada epizodik hafızayı ekleyin: önemli etkileşimleri özetleyip vektör deposuna yazın, ilgili anıları geri çağırın. Kişiselleştirme hissi burada devreye girer. Üçüncü aşamada semantik ve prosedürel hafızayı olgunlaştırın; ACE benzeri bir döngüyle ajanın kendi playbook'unu biriktirmesini sağlayın. Her aşamada KVKK ve güvenlik kontrollerini geriye bırakmayın; belleği izole, skorlanabilir ve silinebilir kurun ki büyüdüğünüzde uyum bir kriz değil, hazır bir yetenek olsun. Bellek, ajanınızın zamanla akıllanmasının değil, zamanla güvenilir olmasının anahtarıdır; ve güvenilirlik, üretimde zekadan daha değerlidir.