Ajan Bellek Sisteminiz Neden Ham Veri Getirme (Raw Retrieval) Karşısında Yeniliyor?

Son bir yılda ajan (agent) mimarileri oldukça spesifik bir karmaşıklık etrafında şekillendi. Bir ajanın uzun oturumlar boyunca bilgileri hatırlaması gerektiğinde, standart yaklaşım ona doğrudan ham kayıtları (raw logs) vermemektir. Bunun yerine bir bellek hattı (memory pipeline) inşa edersiniz: Atomik gerçekleri çıkarır, kullanıcı tercihlerini profiller halinde kümeler, yaşam döngüsü grafikleri tutar ve her çalışmadan sonra özetler sentezlersiniz. Tüm bu kodların arkasındaki varsayım basittir: Geçmişi önceden yapılandırmak, ajan yarın bir cevaba ihtiyaç duyduğunda düz metin parçalarını aramaktan daha iyi sonuç vermelidir.

Ancak Xuan He ve ekibinin (UIUC, Tsinghua, Renmin Üniversitesi, Verdent.ai ve Waterloo Üniversitesi) yayımladığı yeni bir makale (Memory Tax: Dissecting the Net Value of Agent Memory, arXiv:2610.34073) bu varsayımı gerçek bir karşılaştırmayla test etti. Araştırmacılar 11 özel bellek sistemini aldılar, bunları üç kıyaslama testine (LongMemEval-s, PersonaMem-v2 ve MINT-Eval) tabi tuttular ve üç model omurgası (Qwen3.5-4B, Qwen3.6-27B ve GPT-5.6 Luna) üzerinde naif RAG ile karşılaştırdılar. Temel referans noktası kasıtlı olarak basitti: Ham geçmiş parçaları üzerinde sadece bir veya iki turluk düz veri getirme işlemi.

Sonuçlar çarpıcıydı: Özel bellek sistemlerinin çoğu naif RAG'ın gerisinde kaldı. Qwen3.6-27B ile yapılan LongMemEval-s testinde iki turluk naif RAG %81,4 puan aldı. Buna karşılık:

• A-Mem gibi düz depolar %79,4, MemOS %76,6 ve SimpleMem %73,6 seviyesinde kaldı.
• Hiyerarşik kurulumlar da bu durumdan kurtulamadı; MemoryOS %73,4 ve LightMem %78,8 puan elde etti.

Özel bellek sistemleri bilgiyi işlemek ve depolamak için önemli ölçüde daha fazla token harcamasına rağmen negatif net değer üretti.

Ajan Belleğinin Bilançosu#

Sorgu bazlı sonuçlar incelendiğinde, bellek sistemlerinin her alanda aynı şekilde başarısız olmadığı görülür. Özellikle oturumlar arası sentez veya profil birleştirmenin gerçekten önemli olduğu durumlarda, düz RAG'ın kaçırdığı belirli bir sorgu dilimini çözerler. Yazarlar bu kazanımları bellek faydası (memory benefit) olarak sınıflandırıyor. Sorun, bilançonun diğer sütununda yatıyor: Özel bellek sistemleri, ham veri getirmenin hiç zorlanmadan hallettiği görevlerde başarısız oluyor. Yazarlar buna bellek vergisi (memory tax) adını veriyor.

Ham geçmiş ile bellek işlemleri arasındaki fark iki temel akışla özetlenebilir:

• Ham Geçmiş -> Naif RAG: Tam ve birebir metni korur, minimum maliyetlidir.
• Ham Geçmiş -> Bellek İşlemleri (çıkarma, damıtma, özetleme) -> Bozulmuş Bellek Birimi: Kesin terimleri düşürür (erişim kayıplarına yol açar) ve model değişimlerinde format uyumsuzluğu yaratır.

Ham bir konuşmayı atomik bir gerçeğe veya özete her dönüştürdüğünüzde, asıl gerçekten (ground truth) sapmış olursunuz. Özetleme sırasında önemsiz görünen belirli bir yapılandırma bayrağını (configuration flag), tam dosya yolunu veya zaman damgasını düşürebilirsiniz. Bu detay bellek inşası sırasında bir kez kaybolduğunda, hiçbir erişim stratejisi onu geri getiremez.

Araştırmacılar, inşa sürecinden ne kadar bilginin sağ çıktığını ölçmek için örneklenen gerçekleri inceledi:

• MemOS üzerinde örneklenen gerçeklerin %11,4'ü kısmi veya büyük bilgi kaybına uğradı, %2,8'i içinse hiçbir bellek birimi oluşturulmadı.
• OpenViking üzerinde %22,6 kısmi veya büyük kayıp yaşanırken, %38,0'ı için hiçbir bellek birimi üretilmedi. On gerçekten dördü depoya hiç giremiyorsa, ajanınız daha sorgu başlamadan kör uçuş yapıyor demektir.

Erişilebilirlik ve Dayanıklılık Cezası#

Temel gerçek bir bellek birimine sağ salim ulaşsa bile, onu tekrar dışarı çıkarmanın ham kayıtları aramaktan daha zor olduğu ortaya çıkıyor.

Yazılım Geliştirme ve Öğrenme Açısından Pratik Çıkarımlar#

• Erken Karmaşıklıktan Kaçının: Üretimde ajan güvenilirliği (Production Agent Reliability) sağlarken varsayılan olarak karmaşık bellek grafiklerine yönelmeyin. Önce ham kayıtlar üzerinde çalışan basit bir RAG hattını temel (baseline) olarak kurun.
• Kayıpsız Depolama İlkesi: Kod parçacıkları, dosya yolları ve hata kayıtları gibi kesinlik gerektiren verileri özetleyerek saklamak yerine ham metin indekslerini koruyun.
• Bellek Vergisini Ölçün: Eklediğiniz her özetleme ve çıkarım katmanının token maliyetini ve bilgi kaybı oranını RAG değerlendirme araçlarıyla mutlaka test edin.