# Yapay Zeka Ajanlarında Hafıza: Kısa ve Uzun Süreli Bellek Mimarileri

> Source: https://sukruyusufkaya.com/blog/ai-ajan-hafiza-mimarisi
> Updated: 2026-08-05T08:11:13.915Z
> Type: blog
> Category: yapay-zeka
**TLDR:** Durumsuz LLM çağrıları ajanlar için yetmez. Kısa/uzun süreli bellek, epizodik-semantik-prosedürel hafıza ve KVKK Etken Yapay Zeka rehberi ışığında pratik mimari.

**TL;DR —** Bir yapay zeka ajanını "akıllı" yapan şey aslında modelin kendisi değil, o modele ne hatırlattığınızdır. Stateless (durumsuz) bir LLM çağrısı, her seferinde sıfırdan başlayan bir danışman gibidir; dün konuştuğunuz hiçbir şeyi bilmez. Gerçek bir ajan inşa etmek istiyorsanız, kısa süreli çalışma belleğini (context window, scratchpad, mesaj geçmişi) ve uzun süreli hafızayı (episodik, semantik, prosedürel) birbirinden ayırmayı, ne zaman yazıp ne zaman unutacağını bilmeyi ve bunu KVKK'nın Mart 2026'da yayımladığı "Etken Yapay Zeka" rehberiyle uyumlu şekilde tasarlamayı öğrenmeniz gerekiyor. Bu yazıda, saha tecrübemden süzdüğüm pratik bir hafıza mimarisi rehberi sunuyorum.

## Neden Stateless LLM Çağrıları Yetmiyor?

Kurumsal projelerde en sık karşılaştığım yanılgılardan biri şu: "Zaten GPT-4 ya da Claude çok akıllı, bir de ajan yapalım, kendi kendine öğrenir." Hayır, öğrenmez. Büyük dil modelleri, eğitim aşaması bittikten sonra donmuş (frozen) ağırlıklarla çalışır. Siz bir API çağrısı yaptığınızda model, o anki prompt'ta ne varsa onu görür; bir önceki çağrıda ne konuştuğunuzu, hangi kararı aldığınızı, hangi hatayı yaptığını bilmez. Bu, teknik literatürde "stateless" (durumsuz) mimari olarak adlandırılır ve aslında bilinçli bir tasarım tercihidir — modelin ölçeklenebilir, paralel ve öngörülebilir çalışmasını sağlar.

Ama işte tam burada bir ajan ile bir "chatbot" arasındaki fark ortaya çıkıyor. Bir müşteri hizmetleri chatbot'u tek seferlik, kısa soru-cevaplarla idare edebilir. Ama bir ajan — diyelim ki bir satın alma sürecini yöneten, bir müşteri şikayetini haftalarca takip eden ya da bir yazılım projesinde kod tabanında değişiklik yapan bir sistem — zaman içinde tutarlı kalmak zorunda. Danışmanlık yaptığım bir lojistik firmasında, ajanın her konuşmada "Bu müşteriyle daha önce hangi anlaşmazlığı yaşadık?" sorusuna cevap verememesi, güveni sıfırlayan bir sorundu. Müşteri "Size geçen hafta anlattım" dediğinde, ajanın "Üzgünüm, bu konuşmayı hatırlamıyorum" demesi, kurumsal itibara zarar veren bir deneyimdi.

Stateless mimarinin yetersiz kaldığı dört temel alan var:

1. **Süreklilik (continuity):** Çok adımlı görevlerde, ajan attığı her adımı hatırlamak zorunda; aksi halde döngüye girer ya da aynı hatayı tekrar eder.
2. **Kişiselleştirme:** Bir kullanıcının tercihlerini, geçmiş kararlarını, iş bağlamını hatırlamayan bir ajan, her seferinde sıfırdan başlayan bir stajyer gibi davranır.
3. **Öğrenme ve iyileşme:** Ajan bir hatadan ders çıkaramıyorsa, aynı hatayı sonsuza kadar tekrarlar. Prosedürel hafıza olmadan "deneyim biriktirme" imkansızdır.
4. **Uzun vadeli hedef takibi:** Karmaşık iş akışlarında (örneğin bir tedarik zinciri optimizasyonu ya da aylar süren bir proje yönetimi), ajanın "büyük resmi" unutmaması gerekir.

Bu dört ihtiyacı karşılamak için mühendisler, modelin kendisine değil, modelin *çevresine* bir hafıza katmanı eklemeyi öğrendiler. Bu yazının geri kalanı, tam olarak bu katmanın nasıl tasarlandığını anlatıyor.

## Kısa Süreli Hafıza: Çalışma Belleği

Kısa süreli hafıza, bir insanın kısa süreli belleğine (working memory) benzer — o an üzerinde çalıştığınız bilgiyi tutar ama kapasitesi sınırlıdır ve kalıcı değildir. Ajan dünyasında bu, üç bileşenden oluşur:

**1. Context window (bağlam penceresi).** Modelin tek bir çağrıda görebildiği token miktarı. Bugün kullanılan modellerin çoğu 128K ile 1M token arasında bağlam penceresine sahip, ancak "büyük pencere" demek "sınırsız hafıza" demek değil. Bağlam penceresi büyüdükçe, modelin en alakalı bilgiyi bulma becerisi (retrieval accuracy) düşme eğilimi gösterir — buna literatürde "lost in the middle" (ortada kaybolma) sorunu deniyor. Yani sadece pencereyi büyütüp her şeyi içine tıkmak, çözüm değil, yeni bir sorun.

**2. Scratchpad (taslak alanı).** Ajanın bir görevi çözerken ara adımlarını, hesaplamalarını, "düşünme" sürecini yazdığı geçici alan. ReAct (Reasoning + Acting) gibi ajan mimarilerinde scratchpad, "Thought → Action → Observation" döngüsünün kaydını tutar. Bu bilgi genellikle görev bitince silinir; kalıcı değildir.

**3. Mesaj geçmişi (conversation history).** Kullanıcı ile ajan arasındaki ham diyalog. Kısa konuşmalarda bu geçmişi olduğu gibi context window'a koymak yeterli olabilir. Ama konuşma uzadıkça (örneğin 50-100 mesajlık bir destek görüşmesi), ham geçmişi taşımak hem maliyetli hem de performans düşürücü hale gelir.

Burada önemli bir mühendislik kararı devreye giriyor: **ne zaman özetleme (summarization) yapılacak?** Yaygın yaklaşımlardan biri, "sliding window + rolling summary" tekniğidir: Son N mesaj ham haliyle tutulur, daha eski mesajlar periyodik olarak özetlenip tek bir "konuşma özeti" bloğuna sıkıştırılır. Bir e-ticaret müşterisi için kurduğumuz destek ajanında bu yaklaşımı şöyle uyguladık: son 10 mesaj ham metin olarak, öncesi ise "müşteri X ürünü iade etmek istiyor, sebep Y, daha önce Z çözümü önerildi ama kabul edilmedi" gibi 2-3 cümlelik yapılandırılmış özetler halinde tutuluyordu.

Kısa süreli hafızanın kritik özelliği şu: **oturum (session) bitince genellikle kaybolur.** Bir ajan sohbeti kapattığınızda, context window'daki her şey uçar gider — tabii ki siz bunu kalıcı hale getirmek için ayrı bir mekanizma kurmadıysanız. İşte tam da bu noktada uzun süreli hafıza devreye giriyor.

## Uzun Süreli Hafıza Nedir ve Neden Gerekli?

Uzun süreli hafıza, oturumlar arasında (cross-session) kalıcı olan, ajanın harici bir depolama sisteminde (veritabanı, vektör mağazası, dosya sistemi) sakladığı bilgidir. İnsan biliş biliminden ödünç aldığımız bir sınıflandırmayla, üç türe ayırıyoruz: episodik, semantik ve prosedürel hafıza. Bu ayrım akademik bir süs değil — her biri farklı bir mühendislik problemi ve farklı bir depolama stratejisi gerektiriyor.

### Episodik Hafıza: "Geçmişte Ne Oldu?"

Episodik hafıza, ajanın yaşadığı belirli olayların, geçmiş etkileşimlerin kaydıdır. "12 Ocak'ta müşteri X, Y ürünü hakkında şikayette bulundu ve biz Z çözümünü sunduk" gibi zaman damgalı, bağlama özgü kayıtlar. Bu, bir insanın "geçen yıl o toplantıda ne konuşmuştuk" diye hatırladığı türden hafızaya benzer.

Kurumsal ajan projelerinde episodik hafıza genellikle şu senaryolarda kritik:
- Bir müşteri temsilcisi ajanının, aynı müşteriyle önceki tüm etkileşimleri hatırlaması
- Bir kod asistanının, bir projede daha önce hangi mimari kararların alındığını hatırlaması
- Bir satış ajanının, bir müşteri adayıyla geçmişte hangi tekliflerin görüşüldüğünü bilmesi

Episodik hafıza genellikle olay bazlı (event-based) kayıtlar halinde tutulur ve zaman damgası, oturum kimliği, katılımcılar gibi meta veri içerir.

### Semantik Hafıza: "Genel Olarak Ne Biliyorum?"

Semantik hafıza, zamana bağlı olmayan, genelleştirilmiş bilgi ve gerçeklerdir. "Bu müşterinin şirketi X sektöründe faaliyet gösteriyor, 200 çalışanı var, ödeme koşulu net 30 gün" gibi bilgiler. Bu bilgi, belirli bir konuşmadan çıkarılmış olabilir ama artık o konuşmadan bağımsız, kalıcı bir "gerçek" olarak saklanır.

Semantik hafızanın önemli bir alt kümesi, kullanıcı profili ve tercihleridir: "Bu kullanıcı teknik detay yerine özet rapor tercih ediyor", "Bu müşteri fiyat konusunda hassas, indirim teklifine olumlu yanıt veriyor" gibi. Bu tür bilgiler, kişiselleştirme için altın değerinde ama aynı zamanda — birazdan KVKK bölümünde döneceğim gibi — kişisel veri koruması açısından en riskli kategori.

### Prosedürel Hafıza: "Bunu Nasıl Yaparım?"

Prosedürel hafıza, ajanın öğrendiği becerileri, kuralları, iş akışlarını ve "nasıl yapılır" bilgisini kapsar. İnsan biliminde bisiklete binmeyi öğrenmek gibidir — bir kez öğrenilir, sonra otomatikleşir. Ajan bağlamında bu, genellikle şu şekillerde karşımıza çıkar:

- Sistem promptunun zamanla güncellenen, öğrenilmiş talimatlar içeren versiyonları
- "Bu tür bir talepte şu adımları izle" şeklinde kodlanmış iş akışı kuralları
- Geçmiş hatalardan çıkarılan ve gelecekte kullanılacak "ders" kayıtları — örneğin "kullanıcı X formatını istediğinde asla Y aracını kullanma, geçen sefer hata verdi"

Prosedürel hafıza, üç tür arasında mühendislik açısından en az standartlaşmış olanı. Bazı ekipler bunu basitçe sistem promptuna eklenen, insan tarafından onaylanan kural listeleri olarak yönetiyor; bazıları ise otomatik "reflection" (öz-değerlendirme) döngüleriyle ajanın kendi hatalarından çıkardığı dersleri otomatik olarak biriktirmesini sağlıyor. İkinci yaklaşım güçlü ama riskli — denetimsiz bırakılırsa ajan yanlış genellemeler öğrenip bunları kalıcı hale getirebilir.

Aşağıdaki tablo üç hafıza türünü özetliyor:

| Hafıza Türü | İçerik | Örnek | Tipik Depolama |
|---|---|---|---|
| Episodik | Geçmiş olaylar, etkileşimler | "15 Mart'ta müşteri iade talep etti" | Zaman damgalı log + vektör index |
| Semantik | Genel gerçekler, profil bilgisi | "Müşteri net 30 gün ödeme yapıyor" | Yapılandırılmış DB / vektör store |
| Prosedürel | Kurallar, öğrenilmiş beceriler | "Bu senaryoda önce onay iste" | Sistem prompt / kural motoru |

## Uzun Süreli Hafızanın Teknik Uygulaması: Vektör Store + Retrieval

Peki bu üç hafıza türü teknik olarak nasıl hayata geçiriliyor? En yaygın yaklaşım, vektör tabanlı depolama ve getirimdir (retrieval). Mantık şu:

1. Saklanacak bilgi (bir konuşma özeti, bir gerçek, bir kural) metin haline getirilir.
2. Bu metin bir **embedding modeli** ile sayısal bir vektöre dönüştürülür — bu vektör, metnin anlamsal içeriğini yüksek boyutlu bir uzayda temsil eder.
3. Vektör, bir **vektör veritabanında** (Pinecone, Weaviate, Qdrant, pgvector, Chroma gibi) meta veriyle birlikte (kullanıcı ID, zaman damgası, hafıza türü, kaynak) saklanır.
4. Yeni bir görev geldiğinde, mevcut bağlam da bir vektöre dönüştürülür ve veritabanında **benzerlik araması** (cosine similarity, dot product gibi) yapılarak en alakalı k kayıt getirilir.
5. Getirilen kayıtlar, context window'a enjekte edilerek modelin "hatırlaması" sağlanır.

Bu akış aslında RAG (Retrieval-Augmented Generation) ile neredeyse birebir aynı teknik altyapıyı kullanır — ama amaç ve içerik farklıdır (bu farkı birazdan detaylandıracağım). Basit bir mimari şeması şöyle:

```
Kullanıcı Girdisi
      │
      ▼
[Embedding Modeli] ──► Sorgu Vektörü
      │
      ▼
[Vektör Veritabanı] ──► Benzerlik Araması (top-k)
      │
      ▼
[İlgili Hafıza Kayıtları]
      │
      ▼
[Context Window'a Enjeksiyon] ──► LLM Çağrısı ──► Yanıt
                                        │
                                        ▼
                              [Yeni Bilgi Hafızaya Yazılır]
```

Pratikte gördüğüm önemli tuzaklardan biri: ekipler genellikle her şeyi tek bir vektör indekste toplamayı tercih ediyor. Ama episodik, semantik ve prosedürel hafızayı ayrı indekslerde (ya da en azından ayrı meta veri etiketleriyle filtrelenebilir şekilde) tutmak, hem getirim kalitesini artırıyor hem de veri yönetişimini (özellikle KVKK uyumluluğu açısından) kolaylaştırıyor. Bir bankacılık müşterimizde, episodik hafızayı (müşteri etkileşim geçmişi) ayrı bir indekste tutup 90 günlük otomatik silme politikası uygularken, semantik hafızayı (ürün bilgisi, genel politikalar) süresiz ama düzenli olarak doğrulanan (validated) bir indekste tutuyorduk.

Bazı çerçeveler (LangChain'in memory modülleri, LlamaIndex'in memory sınıfları, Anthropic'in Claude ajan SDK'sında kullanılan dosya tabanlı hafıza yaklaşımları gibi) bu deseni hazır bileşenler olarak sunuyor. Ancak hazır bir kütüphane kullanmak, doğru mimari kararı vermenizi gerektirmiyor değil — hangi bilginin ne kadar süre saklanacağı, hangi bilginin asla saklanmayacağı gibi kararlar mühendislik değil, iş ve hukuk kararlarıdır.

## Hafızaya Yazma ve Konsolidasyon

Hafıza mimarisinde en çok göz ardı edilen adım, "ne zaman ve ne yazılacağı" kararıdır. Naif bir yaklaşım, her mesajı olduğu gibi hafızaya yazmaktır — ama bu hem depolama maliyetini şişirir hem de getirim kalitesini düşürür (çünkü alakasız, gürültülü kayıtlar arasında "iğneyi" bulmak zorlaşır).

Olgun bir hafıza yazma stratejisi genellikle şu adımları içerir:

**1. Filtreleme.** Her etkileşim hafızaya değer katmaz. "Merhaba", "teşekkürler" gibi mesajlar genellikle atlanır. Yazma kararı, çoğu zaman ayrı bir LLM çağrısı ya da kural tabanlı bir filtre ile veriliyor: "Bu konuşmada hafızada saklanmaya değer yeni bir bilgi var mı?"

**2. Özetleme (summarization).** Ham konuşma yerine, bilginin özü çıkarılıp saklanır. "Müşteri üç kez aynı soruyu sordu, üçüncüsünde X çözümünü kabul etti" gibi bir özet, ham diyalogdan çok daha kompakt ve retrieval için daha kullanışlıdır.

**3. Yapılandırma (structuring).** Serbest metin yerine, mümkün olduğunca yapılandırılmış format (JSON, anahtar-değer çiftleri) kullanmak, hem tutarlılığı artırır hem de ileride sorgulamayı kolaylaştırır. Örneğin bir semantik hafıza kaydı şöyle olabilir:

```json
{
  "type": "semantic",
  "subject": "musteri_123",
  "fact": "odeme_kosulu",
  "value": "net_30_gun",
  "confidence": 0.95,
  "source_session": "sess_8821",
  "last_updated": "2026-06-14"
}
```

**4. Deduplikasyon (dedup).** Aynı bilginin farklı ifadelerle tekrar tekrar hafızaya yazılması, hem depolama israfı hem de çelişkili kayıtların birikmesi anlamına gelir. Olgun sistemler, yeni bir kayıt yazılmadan önce mevcut hafızada benzer bir kayıt olup olmadığını kontrol eder (yine vektör benzerliği ile) ve varsa günceller, yoksa yeni kayıt oluşturur — buna "upsert" mantığı deniyor.

**5. Konsolidasyon (consolidation).** Zaman içinde biriken çok sayıda episodik kaydı, periyodik olarak daha üst düzey semantik bilgiye dönüştürmek. Örneğin "müşteri son 6 ayda 3 kez teslimat gecikmesi şikayeti yaptı" şeklindeki tekil episodik kayıtlar, konsolidasyon sürecinde "bu müşteri teslimat gecikmelerine karşı hassas, proaktif bilgilendirme tercih ediyor" gibi tek bir semantik profil bilgisine dönüşebilir. Bu, insan hafızasındaki uyku sırasında gerçekleşen hafıza konsolidasyonuna benzer bir süreçtir — biyolojik metaforu severim çünkü mühendislere neden bu adımın gerekli olduğunu çok net anlatıyor.

Bir üretim şirketinde kurduğumuz bakım-destek ajanında, konsolidasyonu haftalık batch job olarak çalıştırıyorduk: o hafta biriken episodik kayıtlar bir LLM'e verilip "bu kayıtlardan çıkarılabilecek genel örüntüler nedir?" sorusu soruluyor, çıkan öneriler insan onayından geçtikten sonra semantik hafızaya ekleniyordu. Bu insan-onay adımı kritik — otomatik konsolidasyonu tamamen serbest bıraktığınızda, model yanlış genellemeler ("bu müşteri hep şikayet ediyor" gibi adaletsiz ve yanlış çıkarımlar) üretebiliyor.

## Hafıza Getirme (Retrieval) ve İlgililik

Doğru bilgiyi saklamak yetmez; doğru anda doğru bilgiyi geri getirmek en az o kadar zor bir problem. Retrieval kalitesini etkileyen birkaç faktör var:

**Anlamsal benzerlik yeterli değil.** Sadece vektör benzerliğine dayanan retrieval, çoğu zaman yüzeysel olarak benzer ama bağlamsal olarak alakasız kayıtlar getirebilir. Bu yüzden pratik sistemler genellikle **hibrit retrieval** kullanır: vektör benzerliği + anahtar kelime araması (BM25 gibi) + meta veri filtreleme (zaman aralığı, kullanıcı ID, hafıza türü) birlikte çalışır.

**Yeniden sıralama (re-ranking).** İlk aşamada getirilen aday kayıtlar (örneğin top-50), ikinci bir model ile daha hassas şekilde yeniden sıralanır ve en alakalı k tanesi (örneğin top-5) context window'a eklenir. Bu iki aşamalı yaklaşım, hem hız hem de doğruluk açısından iyi bir denge sağlıyor.

**Zamansal ağırlıklandırma (recency weighting).** Özellikle episodik hafızada, daha yeni olaylar genellikle daha alakalıdır. Retrieval skoruna bir "yenilik" faktörü eklemek (örneğin exponential decay ile), eski ve güncelliğini yitirmiş bilgilerin gereksiz yere öne çıkmasını engelliyor.

**Bağlamsal tetikleme (context-triggered retrieval).** Her adımda hafızayı sorgulamak yerine, ajanın gerçekten hafızaya ihtiyaç duyduğu anları tespit etmek. Örneğin bir kullanıcı "geçen sefer konuştuğumuz gibi" dediğinde, bu açık bir tetikleyicidir. Ama çoğu zaman tetikleyici örtüktür ve ajanın kendisinin "bu görevi tamamlamak için geçmiş bilgiye ihtiyacım var mı?" sorusunu değerlendirmesi gerekir.

Şahsen sahada gördüğüm en büyük hata, retrieval'i "her zaman en fazla bilgiyi getir" mantığıyla tasarlamak. Bu, context bloat denen soruna yol açıyor — birazdan pitfalls bölümünde detaylandıracağım. Doğru yaklaşım, "az ama alakalı" bilgiyi getirmek.

## Unutma, Süre Sonu ve Maliyet Kontrolü

İnsan hafızasının en az öğrenme kadar önemli bir yeteneği vardır: unutmak. Ajan hafızasında da kasıtlı unutma mekanizmaları olmadan sistem zamanla verimsizleşir, maliyetler artar ve — daha önemlisi — güncelliğini yitirmiş (stale) bilgi doğru kararları bozmaya başlar.

Pratik unutma stratejileri şunlardır:

- **TTL (time-to-live) politikaları:** Her hafıza kaydına bir son kullanma tarihi atamak. Episodik kayıtlar genellikle kısa TTL'e (30-90 gün), semantik kayıtlar daha uzun ya da süresiz TTL'e sahip olabilir.
- **Erişim sıklığına dayalı budama (LRU mantığı):** Uzun süre erişilmemiş kayıtları arşivlemek ya da silmek.
- **Önem skorlaması (salience scoring):** Her kaydın "ne kadar önemli" olduğuna dair bir skor tutmak ve düşük önemli kayıtları önce budamak. Bu skor, kayıt kaç kez getirildi, ne kadar yakın zamanda kullanıldı, insan tarafından "önemli" olarak işaretlendi mi gibi sinyallerle hesaplanabilir.
- **Sıkıştırma (compression):** Silmek yerine, eski kayıtları daha kompakt bir özet haline getirip saklamak — konsolidasyon sürecinin bir parçası olarak.

Maliyet kontrolü açısından bakıldığında, hafıza sistemi aslında üç ayrı maliyet kalemi doğurur: (1) embedding oluşturma maliyeti, (2) vektör veritabanı depolama ve sorgu maliyeti, (3) context window'a eklenen ekstra token'ların LLM çağrı maliyeti. Büyük ölçekli bir müşteri hizmetleri ajanında, kontrolsüz büyüyen hafıza, bir noktada her çağrıda binlerce gereksiz token taşımaya başlayabilir — bu hem yanıt süresini hem de faturayı ciddi şekilde etkiler. Bu yüzden unutma, sadece "temizlik" değil, doğrudan bir maliyet mühendisliği konusudur.

## RAG ile Ajan Hafızası Arasındaki Fark

Bu, eğitimlerimde en sık karşılaştığım kafa karışıklıklarından biri: "RAG zaten hafıza değil mi?" Kısmen evet, ama tam olarak hayır. Aradaki farkı netleştirmek gerekiyor:

| Boyut | RAG (Klasik) | Ajan Hafızası |
|---|---|---|
| Veri kaynağı | Statik, harici doküman kümesi (kılavuzlar, politikalar, dokümantasyon) | Dinamik, ajanın kendi deneyiminden üretilen veri |
| Güncelleme sıklığı | Genellikle periyodik, insan kontrollü (yeni doküman yüklenir) | Sürekli, ajan çalışırken kendi kendine yazılır |
| İçerik türü | Genel bilgi, kurumsal doküman, ürün kataloğu | Kişiye özel etkileşim geçmişi, öğrenilmiş kurallar |
| Amaç | Modelin bilmediği/güncel olmayan bilgiye erişmesini sağlamak | Ajanın "kim olduğunu ve kiminle konuştuğunu" hatırlamasını sağlamak |
| Sahiplik | Genellikle kurum çapında paylaşılan bir bilgi tabanı | Genellikle kullanıcı/oturum bazlı, kişiye özel |

Pratikte bu iki sistem aynı teknik altyapıyı (embedding + vektör store + retrieval) paylaşabilir, hatta bazı mimarilerde aynı vektör veritabanında farklı koleksiyonlar olarak yaşayabilirler. Ama kavramsal olarak ayrı tutulmaları gerekiyor çünkü yönetişim kuralları farklı: RAG'deki bir doküman yanlışsa, kaynağı düzeltip yeniden indexlersiniz; ajan hafızasındaki bir kayıt yanlışsa (örneğin yanlış bir müşteri çıkarımı), bu doğrudan o kullanıcıyla ilgili gelecekteki her etkileşimi bozabilir ve çoğu zaman kişisel veri koruması sorunlarına dokunur.

Bazı modern mimariler bu ikisini birleştirerek "hibrit bellek" kuruyor: RAG katmanı genel bilgiyi sağlarken, ajan hafıza katmanı kişiye özel bağlamı sağlıyor ve ikisi aynı prompt'ta birleştiriliyor. Bu, benim önerdiğim yaklaşım — ikisini birbirinin yerine değil, birbirini tamamlayan katmanlar olarak tasarlamak.

## Çoklu Oturum Kalıcılığı ve Kişiselleştirme

Uzun süreli hafızanın en somut iş değeri, çoklu oturum (multi-session) kalıcılık ve kişiselleştirmede ortaya çıkıyor. Bir kullanıcı bugün bir ajanla konuşup yarın geri döndüğünde, ajanın "sıfırdan başlamaması" — işte kurumsal müşterilerimin en çok talep ettiği özellik bu.

Pratik uygulamada bu genellikle şu şekilde kurgulanıyor:

- Her kullanıcıya bağlı kalıcı bir **kullanıcı profili** (semantik hafıza) tutulur: tercihler, geçmiş kararlar, iletişim tarzı.
- Her oturum sonunda, o oturumdan çıkarılan önemli bilgiler (varsa) profile ya da episodik geçmişe yazılır.
- Yeni bir oturum başladığında, ajan önce kullanıcı profilini ve son N episodik kaydı getirip bağlamına ekler — buna bazen "hafıza ön yükleme" (memory priming) deniyor.

Kişiselleştirmenin gücü tartışılmaz — bir eğitim danışmanlığı platformunda, ajanın kullanıcının önceki oturumlarda hangi konularda zorlandığını hatırlayıp yeni içeriği ona göre uyarlaması, kullanıcı memnuniyetini belirgin şekilde artırdı. Ama burada dengeyi tutturmak gerekiyor: aşırı kişiselleştirme, kullanıcıyı "kutuya kapatma" (filter bubble) riski taşıyor ve daha önemlisi, ne kadar çok kişisel veri biriktirirseniz o kadar çok hukuki ve etik sorumluluk üstleniyorsunuz. Bu dengeyi kurarken benim önerim: kişiselleştirme için gerekli minimum veriyi tutun, "olur da lazım olur" mantığıyla veri biriktirmeyin.

## Hafıza Kalitesinin Değerlendirilmesi

Bir hafıza sisteminin "iyi çalıştığını" nasıl anlarsınız? Bu, çoğu ekibin atladığı ama en kritik adımlardan biri. Değerlendirme genellikle üç boyutta yapılır:

**1. Doğruluk (accuracy):** Hafızaya yazılan bilgi gerçeği yansıtıyor mu? Halüsinasyon riski burada da var — model, konuşmadan yanlış bir çıkarım yapıp bunu "gerçek" olarak hafızaya yazabilir.

**2. Getirim kalitesi (retrieval precision/recall):** İhtiyaç duyulan bilgi doğru zamanda getirilebiliyor mu (recall) ve getirilen bilgi gerçekten alakalı mı (precision)? Bunu ölçmek için genellikle etiketlenmiş test setleri kullanılır: "Bu sorguda şu kayıtların getirilmesi beklenir" gibi altın standart (gold standard) senaryolar hazırlanır.

**3. Görev başarımına etkisi (downstream task performance):** En nihayetinde önemli olan, hafızanın ajanın gerçek görev başarısını artırıp artırmadığı. Bir A/B testi kurgusu ile, hafıza aktif ve pasif iken ajanın görev tamamlama oranı, kullanıcı memnuniyeti, hata oranı karşılaştırılabilir.

Ayrıca **unutma değerlendirmesi** de yapılmalı: sistem, artık geçersiz olan bilgiyi doğru şekilde eskitip eskitmediğini (staleness detection) test etmeli. Bir müşterimizde, ajanın 8 ay önce iptal edilmiş bir aboneliği hâlâ "aktif" olarak hatırlaması, ciddi bir güven kaybına yol açmıştı — bu, retrieval'in çalıştığı ama unutma/güncelleme mekanizmasının çalışmadığı klasik bir örnekti.

## Sık Yapılan Hatalar

Sahada en sık gördüğüm hafıza mimarisi hatalarını burada topluyorum:

> **Context bloat (bağlam şişkinliği):** "Her ihtimale karşı" mantığıyla context window'a mümkün olduğunca çok geçmiş bilgi tıkıştırmak. Sonuç: model hem yavaşlıyor hem maliyet artıyor hem de "lost in the middle" etkisiyle asıl önemli bilgiyi kaçırıyor.

> **Stale memory (güncelliğini yitirmiş hafıza):** Bilgi bir kez yazıldıktan sonra hiç güncellenmiyor ya da doğrulanmıyor. Müşterinin adresi değişti ama ajan hâlâ eski adresi "hatırlıyor."

> **Deduplikasyon eksikliği:** Aynı bilginin farklı zamanlarda farklı şekillerde tekrar tekrar yazılması, çelişkili kayıtların birikmesine ve retrieval kalitesinin düşmesine yol açıyor.

> **Gizlilik/güvenlik sızıntısı:** En ciddi risk. Bir kullanıcının hafızasındaki bilginin, yanlış bir prompt mühendisliği ya da retrieval hatası sonucu başka bir kullanıcıya sızması. Çok kullanıcılı (multi-tenant) sistemlerde hafıza izolasyonu, mimari tasarımın en kritik güvenlik gereksinimlerinden biri.

> **Otomatik konsolidasyonu denetimsiz bırakmak:** Modelin kendi kendine "öğrendiği" yanlış genellemelerin, insan onayı olmadan kalıcı hafızaya işlenmesi. Bu, zamanla ajanın önyargılı ya da hatalı kararlar almasına yol açabilir.

> **Hafızayı test etmemek:** Üretime çıkmadan önce hafıza sisteminin retrieval kalitesini, unutma davranışını ve gizlilik izolasyonunu sistematik olarak test etmemek — çoğu ekip bunu "sonra bakarız" diye erteliyor ve sorun canlı ortamda müşteri şikayeti olarak ortaya çıkıyor.

## Türkiye Bağlamı: KVKK ve Etken Yapay Zeka Rehberi

Türkiye'de faaliyet gösteren ya da Türk kullanıcılara hizmet veren her ajan projesinde, hafıza mimarisi tasarımı artık sadece bir mühendislik kararı değil, aynı zamanda bir uyumluluk (compliance) kararı. Kişisel Verileri Koruma Kurumu (KVKK), Mart 2026'da "Etken Yapay Zeka" (Agentic AI) başlıklı bir rehber yayımlayarak, otonom karar alan ve kendi kendine eylem gerçekleştiren yapay zeka sistemlerinin kişisel veri işleme risklerine özel olarak dikkat çekti. Bu rehberin önemi şurada: geleneksel yapay zeka sistemlerinden farklı olarak ajan sistemleri, kişisel veriyi sadece işlemekle kalmıyor, zaman içinde biriktiriyor, ilişkilendiriyor ve bu birikmiş veriyi kullanarak otonom kararlar alıyor — tam olarak bu yazıda anlattığımız hafıza mimarisi.

Danışmanlık verdiğim kurumlarda, bu rehber sonrası hafıza mimarisi tasarımında dikkat ettiğimiz somut noktalar şunlar:

**1. Ajan hafızasına yazılan her kişisel veri, bir işleme faaliyetidir.** Bir müşterinin adı, iletişim bilgisi, satın alma alışkanlığı, sağlık durumu, finansal bilgisi episodik ya da semantik hafızaya yazıldığı anda, KVKK'nın 6698 sayılı kanun kapsamındaki genel yükümlülükleri (hukuki sebep, aydınlatma, amaç sınırlaması, veri minimizasyonu) devreye giriyor. "Ajan otomatik yazdı, biz elle girmedik" savunması, hukuki sorumluluğu ortadan kaldırmıyor.

**2. Veri minimizasyonu, hafıza tasarımının merkezine oturmalı.** Konsolidasyon ve özetleme adımlarını sadece performans için değil, gereksiz kişisel verinin kalıcı hafızaya sızmasını önlemek için de kullanmak gerekiyor. Örneğin bir müşteri destek konuşmasında geçen bir sağlık detayının, işin gereği olmadığı sürece semantik hafızaya "kalıcı gerçek" olarak yazılmaması gerekiyor.

**3. Anonimleştirme ve takma adlandırma (pseudonymization).** Mümkün olduğunca, episodik kayıtlarda doğrudan kimliklendirici bilgi yerine iç referans kimlikleri (customer_id gibi) kullanmak, hafıza sistemi ihlal edilse bile doğrudan kişisel veri sızıntısı riskini azaltıyor.

**4. KVKK md. 15 ve insan gözetimi beklentisi.** KVKK'nın otomatik/otonom karar alma süreçlerinde insan müdahalesi ve gözetimini öngören yaklaşımı, ajan hafızasının beslediği otonom kararlar için özellikle önemli. Bir ajan, hafızasındaki bilgiye dayanarak bir müşteri hakkında otomatik bir sonuca varıyorsa (örneğin "bu müşteri riskli, hizmeti kısıtla" gibi), bu kararın insan onayından geçmesi ya da en azından itiraz edilebilir/denetlenebilir olması bekleniyor. Pratikte bu, hafıza tabanlı otonom kararlar için bir "human-in-the-loop" kapısı kurmak anlamına geliyor — özellikle hukuki sonuç doğuran ya da kişiyi önemli ölçüde etkileyen kararlarda.

**5. Silme ve düzeltme hakkının teknik karşılığı olmalı.** KVKK kapsamında veri sahibinin silme (unutulma) ve düzeltme talep etme hakkı var. Hafıza mimarinizde, "bir kullanıcının tüm episodik ve semantik kayıtlarını sil" işlemini teknik olarak gerçekleştirebiliyor musunuz? Vektör veritabanınızda bu kadar granüler silme mümkün mü? Bu soruyu mimari tasarım aşamasında sormak, üretime çıktıktan sonra sormaktan çok daha ucuz.

Sahadaki gözlemim şu: Etken Yapay Zeka rehberi yayımlandıktan sonra, kurumsal müşterilerimin çoğu artık ajan projelerinde "hafıza veri yönetişim planı"nı proje başlangıcında, mimari tasarımdan önce istiyor. Bu iyi bir gelişme — çünkü hafıza mimarisini sonradan uyumlu hale getirmek, baştan doğru tasarlamaktan çok daha maliyetli.

## Sonuç: Pratik Bir Yol Haritası

Bu yazıda anlattığım kavramları bir araya getirip, bir ajan projesine başlarken izlenebilecek somut bir sıra öneriyorum:

1. **İhtiyaç analizi yapın.** Ajanınız gerçekten uzun süreli hafızaya mı ihtiyaç duyuyor, yoksa iyi tasarlanmış bir kısa süreli çalışma belleği yeterli mi? Her ajan uzun süreli hafıza gerektirmez — basit, tek seferlik görevler için bu bir aşırı mühendislik olabilir.
2. **Hafıza türlerini ayırın.** Episodik, semantik ve prosedürel hafızayı baştan ayrı tasarlayın; sonradan ayırmak çok daha zor.
3. **Yazma politikasını tanımlayın.** Ne yazılacak, ne zaman özetlenecek, kim (insan mı, model mi) onaylayacak — bunları kod yazmadan önce bir belgeye dökün.
4. **Unutma politikasını gün 1'de tasarlayın.** TTL'ler, arşivleme kuralları, silme mekanizmaları sonradan eklenecek bir özellik değil, temel mimarinin parçası olmalı.
5. **Veri yönetişimini KVKK ile birlikte kurgulayın.** Özellikle Etken Yapay Zeka rehberi sonrası, hukuk ve mühendislik ekiplerinin hafıza tasarımını birlikte gözden geçirmesi artık bir lüks değil, gereklilik.
6. **Ölçün.** Retrieval kalitesini, unutma davranışını, gizlilik izolasyonunu üretime çıkmadan önce ve çıktıktan sonra düzenli olarak test edin.

Hafıza, bir ajan projesinin en "gösterişsiz" ama en belirleyici katmanı. Modelin kendisi ne kadar güçlü olursa olsun, doğru bilgiyi doğru zamanda hatırlamayan bir ajan, kullanıcı gözünde güvenilmez kalır. Kurumsal projelerde gördüğüm en başarılı ajanlar, en büyük modeli kullananlar değil, hafızasını en özenli tasarlayanlar oldu.