Oturum kayıtlarını hatırlamak ajanlar için faydalı değil
(12gramsofcarbon.com)- SWE çalışmalarında bir ajan zaten dokümanlar, PR’lar ve commit’ler gibi bağlamı görebiliyorsa, geçmiş oturum kaydı araması performans avantajı sağlamadı
- Yaygın uygulama, tüm transcript’leri bir veritabanına kaydedip ardından vektör araması, Elasticsearch, SQL araması ve grafik ekleyerek bunları MCP veya CLI skill olarak sunmak; ancak aylar süren karşılaştırmalı testlerde fark yaratmadı ve bazen model kalitesini düşürebildi
- İyi commit mesajları, PR mesajları, dokümantasyon ve metadata’nın kaldığı ortamlarda önemli bilgiler zaten kodlama çıktıları içinde düzenlenmiş oluyor; oturum kayıtları ise yinelenen bilgileri ve geçici notları token olarak yeniden okutuyor
- Ajanlar uzun süreli bellek için gerekli bağlam temizliğini iyi yapamıyor; durumsuz oldukları için giriş bağlamındaki kodu, notları ve token’ları niyet olarak ele alıp intent drift’in birikmesine yol açabiliyor
- Oturum kayıtları ekip gözlemlenebilirliği için yararlı olabilir, ancak performans iyileştirme aracı olarak olumsuz; nori bots’un haftalık değişiklik önerilerinde de insanların diff’i incelemesi gerekiyordu ve gerçek kabul oranı %20’nin altındaydı
Oturum kaydı aramasının performansı artırmamasının nedeni
- SWE çalışmalarında geçmiş oturum kayıtlarını aratmak, başka bağlamların mevcut olduğu koşullarda 0 performans avantajı gösterdi
- Oturum kayıtlarını otomatik tarayarak ajan bağlamını iyileştirme girişimleri de insan incelemesi olmadan büyük bir avantaj sağlamadı
- Yaygın oturum tabanlı bellek mimarisi şu akışa sahiptir
- Kuruluş genelindeki tüm transcript’leri bir veritabanına kaydetmek
- Bunun üzerine vektör araması, Elasticsearch ve SQL araması katmanları eklemek
- Daha iddialı ekiplerin üçünü de kullanıp grafiği de dahil etmesi
- MCP veya skill’e sahip bir CLI üzerinden ajana sunmak
- Aylar boyunca oturum araması yaklaşımının olup olmamasını karşılaştırınca, bu ek çalışma fark yaratmadı ve bazı durumlarda modeli daha kötü hale getirebildi
- Yararlı bilgiler zaten kodlama çıktıları içinde düzenlenmiş durumda
- Kod değişiklikleri iyi commit mesajları, PR mesajları, kapsamlı dokümantasyon ve kodla birlikte commit edilen metadata içerir
- Ajanlara belirli bir kod üzerinde çalışırken dokümanlara ve önceki PR’lara bakmaları söylenir
- Oturum kaydı araması, zaten bilinenleri tekrar okutuyor; en baştan kaydedilmemesine karar verilmiş geçici yargıları ve scratchpad’leri de token olarak tüketiyor
Otomatik belleğin sendelediği noktalar
- Ajanlar uzun süreli bellek tutmada kritik olan bellek temizliğini yapamıyor
- Binlerce oturumda bağlamın gerçekten kaldırıldığı bir örnek görülmedi
- Bu, prompt engineering ile çözülebilecek bir özellik değil; ajanlar durumsuz olduğu için giriş bağlam penceresindeki her şeyi ground truth olarak ele alıyor
- Kod, mevcut bellek ve tüm token’lar niyetin ifadesi olarak görülüyor; önceki ajan oturumlarının rastgele kararları ya da insanların incelemediği içerikler de buna dahil
- Bu süreçte intent drift birikiyor
- Ajan bellek tabanını otonom şekilde büyüttükçe önceki girdilerdeki hatalı niyet yorumları birikmeye devam ediyor
- Girdi verisinin kirli olduğunu varsayan kodlama benchmark’ı yok; modeller girdi verisinin yanlış olduğunu varsayarsa aksine dezavantaj yaşar
- “Kod tabanını silme” ile “bazı giriş bağlamlarını sil” şartlarını aynı anda sağlamanın kolay bir yolu da yok
- Otomatik ezberleme eninde sonunda token harcayan, maliyeti artıran ve model kalitesini düşüren gereksiz çöp bağlam ile sonuçlanıyor
- Oturum kayıtları ekip gözlemlenebilirliği için yararlı olabilir, ancak ajanı daha iyi hale getiren bir araç olarak görmek zor
nori bots’un insan incelemesi yaklaşımı
- Zaman içinde bağlam öğrenme yönteminin kendisi imkânsız değil; nori bots her hafta PR, Slack, Drive gibi şirkette olup bitenleri inceleyerek yerleşik nori skillsets için değişiklik önerileri sunuyor
- Değişiklik önerileri Slack’te ekibi etiketliyor, ancak varsayılan olarak hepsi reddediliyor
- Bir değişikliği kabul etmek için diff’i bizzat görüp niyete uygun olduğunu doğrulamak gerekiyor
- Kabul oranı %20’nin altında; kalan %80’lik “otomatik” güncellemenin modeli daha kötü hale getirmiş olacağı düşünülüyor
- Yüzlerce kişilik bir kuruluş bu tür güncellemeleri her zaman otomatik kaydederse, durum daha da sürdürülemez hale gelebilir
1 yorum
Hacker News yorumları
OpenAI’ın ChatGPT’ye oturumlar arası bellek özelliği eklediğini söylediği zamanı hatırlatıyor. Sonunda bana, açık rızam olmadan hakkımdaki alakasız bilgileri bulup istemlerin arasına kopyalayıp yapıştıran bir özellik gibi gelmişti.
“Şu üç arabayı karşılaştır. Ha, bu arada ben veri mühendisiyim, annemin kızlık soyadı Joana, kötü şiire alerjim var. Kod DRY olmalı, Python yerine SQL’i tercih ederim ve İskandinavya’daki en zehirli çiçek hangisi?” gibi bir şey.
Hatırlanan bağlam, hiç ilgisi olmayan projelere ve konuşmalara sızıp çok fazla tuhaf çıktı ürettiği için ilk kapattığım özellik bu.
Kesinlikle katılıyorum. claude-code’un bellek sistemi bazen işe yarıyor, ama mevcut işi bulandıran eski bilgileri çekip getirdiği için zararlı olduğu durumlar çok daha fazla. Claude’un kendi belleğinin Claude’u ciddi biçimde yanlış yönlendirdiğini sık sık gördüm.
Tahminimce bu, eğitim süreci yüzünden modelin “şu anda olan şey” ile “daha önce olmuş şey”i ayırt edememesiyle ilgili görünüyor. Bellekten akıl yürütme sürecinin kendisi eğitime dahil edilmiş olsaydı farklı olurdu, ama yalnızca çıkarım anında eklenen bir özellik olduğu için modeli kafasını karıştırıyor gibi.
LLM’ler hafif bir bağlam kirlenmesini bile kaldıracak kadar zeki değil.
Onu o tarafa götüren düşünce ya da bağlamda bir atalet oluyor; olduğu gibi bırakılırsa yapışkan şekilde kalıyor.
Ama sonra bunu bellekten tekrar çıkarıp getirirse epey sinir bozucu oluyor.
Belleği dahil ederek eğitme fikri ilginç.
Kodu “ne yaptırmaya çalıştığınız” çoğu zaman önemli değildir. Önemli olan kodun gerçekte ne yaptığıdır.
Oturum günlükleri kesinlikle faydalı olabilir, ama onların üzerine sürekli geliştirme yaparken değil, doğrulama aşamasına girildiğinde faydalıdır. Markdown planı ile CI’ın geçmesi arasında, 800 satır yeni kodun oluştuğu ve tıklayınca kabaca iyi göründüğü o aralıkta.
Oturum günlükleri hangi manuel doğrulamaların yapıldığını gösterebilir. CI mevcut testleri çalıştırır, kod yeni birim testlerinin ne olduğunu gösterir; ama oturum günlüğü, ajanın Playwright ile uygulamayı doğrudan kullanıp kullanmadığını, yalnızca dev ayarlarını değil prod ayarlarını da okuyup dikkate alıp almadığını gösterir.
Kusursuz değil, ama tüm doğrulama çalışmalarının depoda sonsuza kadar kalacak testlere dönüşmesi gerekmez. Oturumları yeniden analiz ederek ajanın sormadan karar aldığı noktaları bulmakta ve bu kararlar için doğrulama düşünmeye zorlamakta çok fayda gördük. Bunları baştan talimat olarak vermek zor, ama oturum günlüklerinde kolayca ortaya çıkıyor.
Sinir bozucu bir sorun. Daha önce sorduğum varsayımsal bir soru yüzünden sürekli sahte öncüller üretiyor.
Bir şeyi araştırmasını istemiş olmam nedeniyle veri merkezi sahibi olduğumu ve çok sayıda GPU’m bulunduğunu varsayıyor.
Bu sadece çıkarılmış derslerin bir türü değil mi diye düşünüyorum. Emek vererek oluşturduğumuz bağlam ve ajanlar, daha büyük ve daha iyi modeller çıktığında ortadan kalkabilir.
Böyle konuşma kayıtları kapasitesi düşük modeller için çok yararlı, ama en ileri modeller için neredeyse gereksiz olabilir.
https://minimal-agent.com/ tabanlı özel bir harness kullanıyorum; bu swe-mini-agent tabanlı ve çekirdek mantığı yaklaşık 50 satır. Bash yeterli.
Küçük işlerde her modelin standart harness’ına göre yaklaşık 8 kat hızlı ve 8 kat daha az token kullanıyor.
Büyük işlerde fazla test etmedim. Çalışıyor, ama o durumda daha az odaklı ve biraz daha düşük verimli gibi. Büyük harness’ların 20 bin token’lık sistem istemi, yazılım geliştirme akışını yönlendirmede önemli bir iş yapıyor olabilir. Örneğin Fable’ın Claude Code’da özel bir sistem istemi olduğunu duydum; çok daha proaktif davranmasının nedeni bu olabilir.
Bu yüzden bağlam mühendisliğinin hâlâ değerli olduğuna inanmak istiyorum. Yine de her yeni model çıktığında bu değerin azaldığını düşünüyorum. Çünkü modeller genel olarak daha az aptalca davranacak şekilde ince ayarlandığından, elinden tutma ihtiyacı azalıyor.
Öncelikle modellerin hâlâ bir bağlam katmanına ihtiyaç duyduğunu düşünüyorum. Bağlamı düşünmenin bir yolu sıkıştırmadır. Modelin ne yapması gerektiğini anlamasını kolaylaştırmak için bağlam sağlarsınız. Model kapasitesinin ve bağlam uzunluğunun sonsuz olduğu bir dünyada bile, her seferinde her şeyi ilk ilkelerden yeniden türetmemeyi sağladığı için hâlâ yararlıdır. Model daha az token ile daha iyi performans gösterdiği ve biz token maliyetini önemsediğimiz sürece bağlam faydalı, hatta belki gerekli bir kestirmedir.
Herhangi bir biçimde bağlam katmanı gerektiğini kabul edersek, sıradaki soru bunun nasıl bir katman olacağıdır. Burada modelin aşina olduğu yöntemlerle, örneğin kodun yanında duran Markdown dosyalarıyla çalışmanın daha iyi olduğuna katılıyorum. Ama bu, bağlama ihtiyaç olup olmamasından çok, aşırı tasarlanmış çözümlerin asıl kullanıcıyı, yani ajanı anlamaması sorunu gibi.
Ama çok daha iyi bir sonraki token tahmininin bu bütün yapıyı bir anda eski hale getirip getirmeyeceğini gerçekten merak ediyorum. Hangi yönde sonuçlanırsa sonuçlansın, çok şeyi açığa çıkaracak.
Beynin yapısının da öğrenildiğini hatırlamak gerek. Sadece bireyin yaşamından çok daha uzun zaman ölçeklerinde öğreniliyor.
Ayrıntılı bir bellek sistemi kurmaya gerek olmadığı görüşüne katılıyorum. Hatırlanmaya değer şeyler dokümanlarda, kılavuzlarda, kaynak yorumlarında, commit mesajlarında ve ticket’larda olmalı
Başka bir katmana gerek yok. Aklıma gelebilecek her ayrıntı düzeyi zaten mevcut en iyi uygulamalar tarafından kapsanıyor
Bu eklenti şunları yapıyor: https://github.com/gitsense/pi-brains
Şimdilik bilgiye erişim biçimine ilişkin yönlendirme kurallarını “insanın” tanımlaması gerekiyor, ama ileride konuşmaları izleyip gerektiğinde bağlam enjekte eden bir “bilgi ajanını” desteklemeyi planlıyoruz
~/.claude/…gibi bir şey söz konusuysaBelleğe ihtiyaç duyduğum projelerde AGENTS.md’ye sadece, belleği saklamak için MEMORY.md kullanmasını ya da ilerlemeyi takip etmek için STATUS.md kullanmasını söyleyen tek bir satır ekledim
Ama bunları izleme loglarına etiket olarak eklerseniz, gerektiğinde verimli biçimde bulunabilirler. Üstelik dokümanlar eskir; izleme loglarının ömrü ise commit hash’i veya başka bilgiler eklenerek daha net hale getirilebilir
Buna güçlü biçimde karşı çıkıyorum
Ben Claude/Codex’e log tutturuyorum [1]. Bunu AGENTS.md’de [0] prompt olarak söylemiş durumdayım
“Her oturum ya bir oturum logu ya da bir plan oluşturmalı ve sonunda yazılmış bir özet eklemelidir. Varsayılan logdur; plan yalnızca kayda değer tasarım çalışmaları için kullanılır.”
Bu inanılmaz derecede değerli. Örneğin bugün birkaç oturuma şöyle başladım: “Renovate işinin durumu ne?”, “Yakın zamanda X üzerinde çalışmıştık, bulur musun?”, “Yedekleme sorunu düzeltildi mi? Sonraki adım ne?”, “Bu hata tekrar çıktı. Bunu zaten düzeltmemiş miydik?”
[0]: https://github.com/shepherdjerred/monorepo/blob/main/AGENTS....
[1]: https://github.com/shepherdjerred/monorepo/tree/main/package...
Genel olarak bellek sistemlerini seviyorum. Not olarak, ağırlıklı olarak Opus 4.8 + Max effort kullanıyorum
Bellekten ilgili şeyleri oldukça sık çıkarıyor. Örneğin kendi barındırdığımız OIDC sağlayıcısı için birkaç aday önermesini istersem, “operasyon ekibinin büyüklüğü düşünüldüğünde X ve Y nedeniyle şu taraf daha uygun olabilir” gibi şeyler söylüyor
Elbette bunlar CLAUDE.md’ye konması gereken bilgiler olabilir. Ama o durumda bunu CLAUDE.md’ye koymam gerektiği aklıma gelmemişti; belleğin bunu ortaya çıkarması iyi oldu
Bazen hedefi ıskalıyor. Bugün bir kimlik doğrulama sorunu sordum; “uygulamayı haproxy arkasına koyduğunuz için bu trusted proxy ayarına takılmış olabilir” dedi. Uygulamalarımızın %95’i için doğru ve bahsetmeye değer bir şeydi, ama bu sefer öyle değildi; düzeltmem gerekti. Yine de eğer proxy arkasında olsaydı çok zaman kazandırabilirdi, bu yüzden söylemesi iyiydi
Özellikle varsayımsal soruları sık soruyorsanız ya da başkalarının sorunlarına yardım ediyorsanız bu daha da zorlaşıyor. Bir insan muhtemelen varsayım yapmak yerine “Bu, X’in operasyon ekibiyle mi ilgili? Ölçek hâlâ Y mi?”, “Bu uygulama da daha önce bahsettiğin diğer uygulamalar gibi proxy arkasında mı?” gibi doğrulama soruları sorardı
Bu tür bağlamlarda doğru modellenmesi gereken belirgin bir hiyerarşi de var. Örneğin aynı anda farklı kuralların uygulandığı birden fazla ekiple ilgileniyor olabilirsiniz; insanlar bunu doğal olarak anlar
Belleği kapatsanız bile tek bir konuşma içinde böyle şeyler oluyor
Eski bir konuşmadan bir şey hatırlayıp, ben çoktan gelişmiş ve değişmiş olmama rağmen bunu sürekli önüme süren sinir bozucu bir arkadaş gibi
Temelde bu bir donanım sorunu. 1 milyon token, bir kod tabanını insanın anladığı gibi anlamak için yeterli bağlam değil
Seçici olarak unutabilme yeteneği potansiyel olarak çok değerli. Ama şu anda, insanın bir şeyin kabaca şeklini hatırlama, ilginç olmadığına karar verme ve onun ilginç olmadığını hatırlama becerisinin yerini tutma düzeyinde
Belleğin ancak insan yönlendirdiğinde faydalı olduğu söyleniyor, ama doğru çözümün bundan daha derin olduğunu düşünüyorum. Belki tüm kod tabanını ve tüm ajan oturumlarını modelin ince ayarına koymak yönünde olabilir. Ancak o noktada belirli bir oturumu modele dahil etmemesi için yönlendirme gerekebilir. Ya da gerekmeyebilir; çıkarılan ders uygulanabilir de