Amazon araştırmacıları: Model ağırlıklarında saklanan bellek, daha düşük maliyetle retrieval kalitesini yakalayabilir

Sohbet botu belleği genellikle retrieval anlamına gelir: geçmiş konuşmalar metin notlarına dönüştürülür, en alakalı satırlar seçilir ve her istekte prompt'un içine geri yapıştırılır. Amazon araştırmacıları şimdi farklı bir ayrımın — kalıcı bilgileri doğrudan daha küçük bir modelin parametrelerine gömüp değişken ayrıntıları retrieval'da bırakmanın — bu yaklaşımla aynı kaliteye, sorgu başına çok daha az token okuyarak ulaşabildiğini bildiriyor.

Fathom News'e göre Amazon araştırmacısı Omar Sanseviero çalışmayı X'te paylaştı ve ağırlık tabanlı yaklaşımın, sorgu başına daha az token işlerken metin retrieval'ı ile eşit ya da daha iyi performans gösterdiğini; en iyi yapılandırmanın ise ikisini birleştirdiğini ve hangi belleğe başvurulacağına bir router'ın karar verdiğini söyledi.

Kurulum belleği nasıl bölüyor

Raporda açıklanan sistemin üç parçası var. Metin retrieval'ı, ham notları ve özetleri modelin dışında tutuyor; tıpkı geleneksel retrieval ile güçlendirilmiş sistemlerde olduğu gibi. Bir student modeli, kalıcı bilgileri — kullanıcı tercihleri, roller, tekrarlayan iş akışları — özdamıtma (self-distillation) yoluyla içselleştiriyor ve bunları metin olarak depolamak yerine ağırlıklarına öğreniyor. Bir router da her sorgu için cevabın eğitilmiş ağırlıklardan mı geleceğini yoksa dış metin mi çağrılacağını seçiyor.

Bu ayrım önemli, çünkü tüm anılar aynı şekilde eskimiyor. Bir kullanıcının işi ya da tercih ettiği biçimlendirme stili nadiren değişir; bir siparişin durumu ya da bugün öğleden sonraya planlanmış bir toplantı ise sık sık değişir. Çalışmanın çerçevesi bunları eşitsiz ele alıyor: sık ve kalıcı bilgiler içselleştirilirken, hızla değişen bilgiler anında güncellenebilecekleri retrieval'da kalıyor.

Sonucu taşıyan router

Fathom News, çalışmanın en güçlü sonuçlarının aday cevapları kontrol edip sorguları buna göre farklı bellek türlerine yönlendiren bir "önce doğrula sonra yeniden üret" router'ından geldiğini bildiriyor. Rapora göre makalenin pratik çıkarımı, ağırlık belleğinin retrieval'ın yerini alması gerektiği değil; kazançların asıl hangi anıların içselleştirileceğine ve hangilerinin dışarıda tutulacağına karar veren bellek seçiminde yatması.

Maliyetler gerçekte nereye gidiyor

Ekonomi kaybolmuyor, yer değiştiriyor. Retrieval belleği depolama ve prompt boyutuyla ölçekleniyor: her sorgu çağrılan metni okumak için ödeme yapıyor. Eğitilmiş student yaklaşımı ise önden eğitim masrafı ödüyor, sonra servis aşamasında tekrarlayan okuma maliyetlerini düşürüyor.

Fathom News'in analizine göre net tasarruf aritmetiğe bağlı: birim başına çıkarım (inference) maliyeti ancak, tasarruf edilen token çözme (decoding) harcaması, eğitim, depolama ve özelleştirilmiş servise yapılan ek harcamayı aştığında düşüyor. Student modeller ayrıca emebilecekleri bilgi sayısında bir kapasite tavanıyla karşı karşıya ve tedarik zinciri ile veri merkezi güç kısıtları, bir sağlayıcının üretimde böyle modelleri ne kadar büyük ve kaç tane çalıştırabileceğini sınırlıyor. Yaklaşım, saat başi değişen bilgilerden çok kalıcı tercihlere uyuyor.

Rapor alıcılar için şüpheci bir not da ekliyor: bir satıcı hafif, retrieval'sız asistanlar pazarlıyorsa, asıl sinyal model eğitimine ve adanmış servis altyapısına harcamayı sürdürüp sürdürmediğidir. Bu harcama yoksa, bu söylem büyük ölçekte konuşlandırılabilir, ağırlıklara gömülü asistanlara giden bir yol haritasından çok bir konumlandırma çabası gibi okunuyor.

Neden önemli

Kalıcı asistanlar artık bir ürün kategorisi — kullanıcıların haftalar ya da aylar boyunca geri döndüğü destek botları, kodlama yardımcıları ve kişisel asistanlar. Bu ortamda bellek bir darboğaz haline geldi: kullanıcı bilgilerini unutan modeller bozuk hissettirirken, geniş bağlamı yeniden yükleyen modeller yavaş ve pahalı hale geliyor. Çıkarım maliyetleri ölçekle birlikte biriktiği için, sorgu başına token sayısını düşüren her şey sohbet botu geliştiricileri için doğrudan bütçe sonuçları doğuruyor.

Bulgular çalışmanın ötesinde de geçerliyse, geliştiricilere pratik bir kalıp sunuluyor: kalıcı bilgiyi küçük bir modele damıtın, geçici durumu retrieval'da tutun ve ikisi arasında yönlendirme yapın. Rapora göre izlenecek bir sonraki sinyal, Amazon'un bu çalışmayı Bedrock ya da AgentCore içinde ürün kalıplarına dönüştürüp dönüştürmeyeceği — o noktada geliştiricilerin sorusu benchmark puanlarından hangi anıların ağırlıklara, hangilerinin veritabanına ait olduğuna kayacak.