LLM'lerle ne kadar uzun süre çalıştıysam, kendimi o kadar çok yeterli bağlam, çok fazla bağlam, token israfı ve sıkıştırma savaşı arasındaki ebedi mücadelede buluyorum. Ajanik bellek sistemlerine baktığımızda, bu konuda bize yardımcı olabilecek güçlü silahlar olduğunu görüyoruz.
İncelediğim 19 sistemde sürekli karşıma çıkan bulgu, daha büyük pencerelerin bütçe sorununu çözmek yerine daha da kötüleştirdiği yönünde. 200K tokenlik bir pencere, 200K tokenin tamamına eşit dikkat göstermez. Pencere dolmadan çok önce performans düşer. Bu düşüş tek tip değildir: uzun bir bağlamın ortasındaki materyale, kenarlardakine kıyasla daha az dikkat edilir. Ve ajanın asıl görevi, pencere ne kadar büyük olursa olsun pencerenin sabit bir dilimini işgal eder, bu da geri kalan her şeyin aynı dikkat bütçesi için rekabet eden bir ek yük olduğu anlamına gelir.
Bu durumu iyi yöneten sistemler, altı mekanizmada birleşmiştir. Hiçbiri egzotik değil. Birkaçı utanç verici derecede basit. Ancak bunları atlayanlar bunun bedelini ödüyor.
Altı mekanizma
Sıkıştırma geçişleri
En belirgin mekanizma. Uzun bir konuşmayı veya büyük bir bellek parçasını alır, özetler ve orijinalini özetle değiştirirsiniz. MemoryOS bunu parça düzeyinde yapar: konuşma parçası bir eşiği aştığında parça özetleyicisi devreye girer ve çalışma bağlamını kalabalıklaştırmadan önce onu kompakt bir temsile indirger. Karpathy-deseni wikiler (purpose.md, overview.md) bunu bilgi düzeyinde yapar: wiki, ajanın bir konu hakkında öğrendiği her şeyin, oturumlar arasında korunan sıkıştırılmış halidir.
Ödünleşim bilgi kaybıdır. Sıkıştırma, tanımı gereği kayıplı bir işlemdir. Özet, özetleyicinin sıkıştırma anında alakalı olduğuna karar verdiği şeyi yakalar. Ajan daha sonra alakalı olduğuna karar verilmeyen bir ayrıntıya ihtiyaç duyarsa, o ayrıntı kaybolur. Bu, sıkıştırmadan kaçınmak için bir neden değildir, ancak onu tek mekanizma olarak ele almamak için bir nedendir.
Gözden kaçması kolay ikinci bir maliyet daha vardır. Sıkıştırma çalışma zamanında ücretsiz değildir. MemoryOS, parça özetlerini korumak için tek bir etkileşimde 20 veya daha fazla LLM çağrısı yapabilir. Yüksek etkileşim sıklığına sahip sistemler için bu gerçek bir operasyonel maliyettir.
Sonuç-önizleme kırpma
Her getirmede tam bellek içeriğini döndürmek yerine, kısa bir önizleme döndürün ve ajanın tam kaydı getirip getirmeyeceğine karar vermesine izin verin. supermemory, arayanların sonuç başına ne kadar metin döndüğünü ayarlamasına izin veren snippet uzunluğu kontrollerini kullanıma sunar. mem9 daha da ileri gider: kaynak dönüşlerini, operatörlere kaç kaynak dönüşünün görüneceği ve hangi minimum alaka düzeyi puanında görüneceği konusunda hassas kontrol sağlayan üç ortam değişkeniyle (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) süsler.
Ödünleşim, ekstra bir araç çağrısıdır. Ajanın tam içeriğe ihtiyacı varsa, bunu açıkça istemesi gerekir. Çoğu getirme modeli için bu doğru ödünleşimdir: ajan, kaydı tam olarak okumanın token maliyetini ödemeden önce kaydın alakalı olup olmadığına karar vermek için yeterli sinyali alır.
İki aşamalı getirme
Önizleme kırpmasının belirli ve önemli bir çeşididir. Arama, tanımlayıcıları ve kısa önizlemeleri döndürür. Gerektiğinde tam kaydı getiren ayrı bir GetByID çağrısı vardır. mem9'un MemoryRepo arayüzü bu model etrafında inşa edilmiştir: arama ve getirme, farklı token ayak izlerine sahip ayrı işlemlerdir.
Rakamlar durumu açıkça ortaya koyuyor. Her biri 1.500 token olan on eşleşme, ajan kullansın ya da kullanmasın, bağlama enjekte edilen 15.000 tokendir. İki aşamalı getirme, toplamda yaklaşık 450 token olan 10 tanımlayıcı ve kısa önizleme döndürür, ardından yalnızca ajanın gerçekten ihtiyaç duyduğu kayıtları getirir. Bir oturumdaki 20 geri çağırma adımında bu fark, yaklaşık 200.000 token tasarrufu anlamına gelir.
Bu, benimseyebileceğiniz en ucuz disiplindir. Bellek deposunda herhangi bir mimari değişiklik, ek LLM çağrısı veya bilgi kaybı gerektirmez. Bu bir getirme arayüzü kararıdır.
Ayrıştır-sonra-çağır
Kullanıcı sorgusunun tamamını getirme katmanına göndermek yerine, önce onu alt sorgulara ayrıştırın. SimpleMem'in niyet farkındalıklı getirme planlayıcısı, gelen sorguları bellek deposuna ulaşmadan önce atomik getirme niyetlerine ayırır. GitNexus, sorgu aracı ayrıştırmasıyla benzer bir şey yapar: karmaşık sorgular, her biri bellek grafiğinin odaklanmış bir dilimini getiren hedefli alt sorgulara bölünür.
Faydası kesinliktir. Ayrıştırılmış bir sorgu daha az alakasız materyal getirir, bu da bağlamda daha az gürültü anlamına gelir. Ödünleşim gecikmedir: ayrıştırma, getirme başlamadan önce bir planlama adımı ekler. Etkileşimli ajanlar için bu önemlidir. Toplu veya arka plan ajanları için genellikle önemli değildir.
Bütçe filtresi olarak katmanlı depolama
Zaten katmanlı bir bellek mimarisi inşa ettiyseniz (geçen haftaki yazının konusu), bütçe filtrelemeyi bir yan etki olarak elde edersiniz. supermemory'nin üç katmanlı modeli, sıcak, sık erişilen materyalin kompakt, yüksek sinyalli sonuçlar döndüren bir katmanda yaşadığı anlamına gelir. Soğuk materyal, varsayılan olarak sorgulanmayan bir katmandadır. Hindsight'ın gözlem katmanı da aynı şekilde çalışır: ham gözlemler doğrudan bağlama enjekte edilmez; getirme adayı olmadan önce daha yüksek katmanlara yükseltilirler.
Ödünleşim, geri çağırma bütünlüğüdür. Yükseltilmemiş materyal alakalı olabilir ancak standart bir getirme geçişinde yüzeye çıkmaz. Bu, sıkıştırmayla aynı ödünleşimdir, ancak başarısızlık modu farklıdır: özetleme yoluyla bilgi kaybetmek yerine, düşürme yoluyla kaybedersiniz.
Kendini yönlendiren araç yanıtları
En az tartışılan mekanizma ve en ilginçlerinden biri. Ajanın bir araç çağrısından sonra ne yapacağına karar vermesine izin vermek yerine, araç yanıtının kendisi bir sonraki adımda ne yapılacağına dair bir ipucu içerir. GitNexus, araç yanıtlarına takip eylemleri öneren bir ---
**Sıradaki:** bloğu ekler. mem9, kaynak dönüşlerini ajanın bir sonraki getirme adımını yönlendiren yapılandırılmış meta verilerle süsler.
Etkisi, ajanın araç çağrıları arasında planlamaya daha az token harcamasıdır. Araç yanıtı, bir sonraki adımı belirgin kılmak için yeterli yapıyı taşır. Ödünleşim, prompt mühendisliği çabasıdır: iyi kendini yönlendiren yanıtlar yazmak, ajanın bir sonraki adımda neye ihtiyaç duyacağını önceden bilmeyi gerektirir ve bu her zaman mümkün değildir.
Tolaria sınır durumu
Tolaria'yı ayrıca incelemeye değer çünkü bütçe disiplininin uç noktaya götürülmesinin mantıksal sonucunu temsil eder. ADR-0009, sistemden yerleştirmeleri (embeddings) tamamen kaldırma kararını belgeler. Tolaria yalnızca alt dize araması kullanır. Vektör indeksi, anlamsal getirme veya yerleştirme çağrısı yoktur.
Gerekçe doğrudandır: en ucuz token, en başta hiç getirmediğiniz tokendır. Yerleştirme tabanlı getirme, anlamsal olarak benzer sonuçlar döndürür, yani ajanın açıkça istemediği sonuçları döndürür. Bu sonuçların bazıları kullanışlıdır. Çoğu değildir. Hepsine token maliyeti vardır.
Tolaria'nın konumu, alakasız-ancak-benzer sonuçların bir oturum boyunca birleşik maliyetinin, kullanım durumu için anlamsal geri çağırmanın faydasını aştığı yönündedir. Bu ödünleşimin sizin sisteminiz için geçerli olup olmadığı, sisteminizin ne için olduğuna bağlıdır. Sorguların kesin ve yapılandırılmış olduğu sistemler (kod gezinme, tanımlayıcıya göre belge arama) için Tolaria'nın konumu savunulabilir. Sorguların belirsiz ve keşfedici olduğu sistemler için yerleştirmeleri kaldırmak, geri çağırmayı kurtarılması zor şekillerde bozar.
Tolaria örneğinin değeri, onu kopyalamanız gerektiği değildir. Anlamsal getirmenin maliyetini çoğu sistemin yapmadığı şekilde görünür kılmasıdır.
Sadece sıkıştırma yapan sistemlere karşı argüman
19 sistemden birkaçı, birincil veya tek bütçe mekanizması olarak sıkıştırmaya güveniyor. Başarısızlık modlarını adlandırmakta fayda var.
Birincisi, özetlemenin, sıkıştırma anında alakalı olduğuna karar verilmeyen ancak daha sonra alakalı hale gelen ayrıntıları kaybetmesidir. Bu varsayımsal değildir: gelecekteki alaka düzeyi bilinmeyen bilgilere uygulanan herhangi bir kayıplı sıkıştırma şemasının standart başarısızlık modudur.
İkincisi, sıkıştırmanın bir sıcak yol maliyeti olmasıdır. MemoryOS'un etkileşim başına 20'den fazla LLM çağrısı yapması, sıkıştırma ağırlıklı sistemler için olağandışı değildir. Ölçekte bu maliyet göz ardı edilemez.
Üçüncüsü ve en ince olanı, bir kaçış yolu olmayan sıkıştırmanın yavaş unutma olmasıdır. Bağlam boyutunu azaltmanın tek yolu özetlemekse ve özetler kayıplıysa, sistem sürekli olarak bilgiyi atıyor ve onu kurtarmanın hiçbir yolu yoktur. İki aşamalı getirme, katmanlı depolama ve sonuç-önizleme kırpmanın tümü orijinal kaydı korur. Sıkıştırma korumaz.
Bunların hiçbiri sıkıştırmanın yanlış olduğu anlamına gelmez. Sadece sıkıştırmanın tek başına yeterli olmadığı anlamına gelir.
Güncellik ağırlıklandırması ve kalıcı kuyruk
Yukarıdaki altı kategoriye tam olarak uymayan iki mekanizmayı not etmekte fayda var.
graymatter, güncelliğe yarı ağırlık veren RRF füzyonu kullanır. Bu kesin anlamda bir bütçe mekanizması değildir, ancak böyle işlev görür: getirme sıralamalarında eski materyali düşük ağırlıklandırarak, bayat, düşük sinyalli kayıtların yeni, yüksek sinyalli olanları dışarıda bırakma olasılığını azaltır. Etkisi, açık katman yükseltmesi yerine sıralama ağırlıkları aracılığıyla yumuşak katmanlamadır.
llm-wiki'nin 540 satırlık ekleme kuyruğu durum makinesi farklı bir yaklaşım benimser. Kuyruk, ekleme işlemlerini serileştirir ve belleğe hiçbir şey girmeden önce dört sinyalli bir alaka düzeyi sıralayıcısı uygular. Bütçe kontrolü, okuma zamanı yerine yazma zamanında gerçekleşir. Alaka düzeyi eşiğini geçemeyen materyal depolanmaz, bu da getirilemeyeceği ve bağlam tüketemeyeceği anlamına gelir. Bu dolaylı bütçe kontrolüdür, ancak dayanıklıdır: tasarruflar gelecekteki her oturumda birikir.
İyi tasarlanmış sistemlerin ortak noktaları
19 sisteme baktığımızda, bağlam bütçelerini iyi yönetenlerin birkaç ortak özelliği vardır.
Getirmeyi, tek aşamalı enjeksiyon yerine iki aşamalı bir işlem olarak ele alırlar. Tam kayıtlardan önce önizlemeler döndürürler. Orijinal kayıtları özetlerle değiştirmek yerine korurlar. Operatörlere, sabit kodlanmış varsayılanlar yerine açık parametreler aracılığıyla getirme hacmi üzerinde kontrol verirler. Ve bütçeyi hem yazma zamanında hem de okuma zamanında düşünürler.
Bunu kötü yönetenler, genellikle sıkıştırma gibi tek bir mekanizmaya güvenme ve bağlam penceresini yönetilmesi gereken bir kaynak yerine doldurulması gereken bir tampon olarak görme eğilimindedir.
Araştırmadan çıkan sonuç basittir. Daha büyük pencereler daha az değil, daha fazla disiplin gerektirir. Onları doldurmak prensipte yanlış olduğu için değil, yanlış malzemeyle doldurmak, odayı boş bırakmaktan daha pahalıya mal olduğu için.
Bir sonraki yazımda bellek-enjeksiyon modelinden bellek-araç modeline geçmeyi planlıyorum ve 19 sistemin otomatik olarak bağlama itilenler ile ajanın açıkça istemesi gerekenler arasındaki sınırı nasıl ele aldığını ele alacağım.
Her zaman olduğu gibi, bunu ilginç, faydalı bulduysanız veya sadece bilginin yayılmasına yardımcı olmak istiyorsanız:
Lütfen Paylaşın
