Память для LLM агентов [PART 1]
Привет... Спишь? Тема оказалась огромной, поэтому разбиваю на несколько постов. Сегодня — обзор ландшафта, общие паттерны и картинка, куда движется индустрия. Далее — разбор одного моего любимчика и сравнение с остальными.
RAG — это умный поиск, а не память!
В моей голове есть образ ассистента, который реально ускоряет тебя в бытовых задачах. Но для этого он должен запоминать прошедшие интеракции — причём сам, без тычков «пожалуйста, запомни это». Как человек: в живом общении подмечает интересные факты, просьбы, требования и использует их в будущем. Без этого колонка — просто продвинутый поисковик и переключатель треков, не более.
Недавно наш слоняра Андрей Карпатый
https://x.com/karpathy/status/2039805659525644595 а позже разжился https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f с более подробным описанием системы курирования знаний с помощью LLM. Суть: RAG — stateless, агент каждый раз «переоткрывает» знания, тратит токены впустую. Нужна постоянная, накапливаемая, «живая» память, которую курирует LLM по сути для себя, опционально под вашим контролем.
Тут же полезно вспомнить как устроена память у человека. Из когнитивной психологии https://arxiv.org/abs/2603.07670v1 несколько типов:
😳 Рабочая — то что держишь в голове прямо сейчас, это ~ context window у LLM
🤠 Эпизодическая — конкретные события с контекстом: что, где, когда ~ «12 апреля посреди ночи дописывал этот пост»
🌟 Семантическая — абстрагированные факты: «юзер не любит азиатскую кухню», «в этом проекте не используем глобальные переменные»
🧠 Процедурная — паттерны действий: «как заказать такси через сервис X»
Общие подходы
За последние полгода я отсмотрел, наверное, с десяток проектов и статей. Если смотреть на решения, выделяются три крупные категории:
📁 File-based [1]
Основа — Markdown файлы в формате вики. LLM компилирует сырые заметки в структурированные документы, при необходимости связывает их друг с другом бэклинками. Обязательно хотя бы по одному файлу для каждого из упомянутых выше типов памяти. Без БД и инфраструктуры. Карпатый описал это так: «Obsidian — IDE, LLM — программист, Wiki — кодовая база». Ровно это же активно https://docs.openclaw.ai/concepts/memory с его MEMORY.md и ежедневными YYYY-MM-DD.md.
+ Плюсы: zero-ops, прозрачно, человекочитаемо.
– Минусы: плохо масштабируется, часто требуют ручной модерации, без механизма ротации или архивирования документов базы разрастаются и превращаются в месиво, которое только путает агента и нереально отсмотреть человеку.
🤴 Graph-based [2]
Основа — графовая база знаний. LLM преобразует знания в сущности и связи между ними. Примеры — https://github.com/getzep/graphiti от Zep, https://github.com/HKUDS/LightRAG от HKUDS.
+ Плюсы: явные связи, можно делать запросы на обход графа в глубину/в ширину, хорошо для Enterprise с огромными, раскидистыми, но структурированными данными.
– Минусы: нужна графовая БД, сложный setup, медленнее (vs векторный поиск).
🧠 Brain-inspired [3]
Способ хранения вторичен, основа — организация данных и процедуры, вдохновлённые устройством мозга и нейронаукой: есть забывание данных (decay), укрепление при вспоминании (reinforcement), гибридные стратегии поиска. https://github.com/hebbs-ai/hebbs https://github.com/milla-jovovich/mempalace https://github.com/samvallad33/vestige — все отсюда.
+ Плюсы: максимально близко к тому, как работает память человека, хороши для долгосрочного использования.
– Минусы: сложнее в настройке, в понимании, некоторые идеи ещё экспериментальные. Как правило, в таких системах требуется тюнинг настроек/параметров под конкретный домен данных.
И, конечно, никто не запрещает всё это миксовать!
Репы про Agent Memory на GitHub штопаются сейчас не хуже JS фреймворков. Те, что на картинке просто успел посмотреть/поковырять и раскрою далее
