Суть
«Затолкать всю историю в контекст и надеяться, что модель уследит» — мёртвая парадигма (Agent Memory). Mem0 на каждый диалог вызывает LLM с инструкцией «извлеки факты о пользователе в JSON» и кладёт в хранилище именно факты, а не сырой текст.
Mem0 vs RAG
- RAG: нарежет диалог на чанки, заэмбедит вместе с «I'm», «Got it», «Also» и забудет; зальёшь документ дважды → дубль в индексе («у документа нет жизни»).
- Mem0: хранит факты с «жизнью» —
- дедуп: «user is vegetarian» ≈ «user doesn't eat meat» (similarity > 0.85) → merge в одну запись;
- конфликт: январь «vegetarian» → май «started eating chicken» → LLM помечает старый факт outdated, новый актуальным (или хранит оба с timestamp, отдавая свежий при retrieve).
- Это поиск по личной истории конкретного пользователя (метаданные
user_idв фильтре — обязательный паттерн), а не по всей корпоративной базе.
Mem0 в мультиагентных системах
В single-agent Mem0 — это «помни пользователя между сессиями». В MAS (например, crew {Researcher, Writer, Critic} в CrewAI) Mem0 становится слоем координации: по умолчанию между задачами передаётся только output предыдущей (context=[task1]), а общий слой памяти меняет архитектуру команды. Подключается через memory=True + memory_config со scope по user_id. Запись в память в проде делают асинхронной (async_mode=True), чтобы не блокировать ответ.
- Scopes: User / Agent / Session / Org.
- Entity Memory (в CrewAI через ChromaDB): извлечённые сущности — люди, места, концепции.
- MemSearch — узкоспециализированный аналог для кодинг-агентов (Claude Code, Codex): source of truth — markdown-файлы под Git, Milvus как теневой индекс.
Бенчмарки (LoCoMo, LongMemEval, BEAM)
В 2026 это стандарт сравнения архитектур памяти. Алгоритм Mem0: LoCoMo 92.5, LongMemEval 94.4, при ~6 900 токенах/запрос; прирост +29.6 на temporal reasoning, +23.1 на multi-hop. Против full-context: −90% токенов, −91% latency. Открытые проблемы: cross-session identity, temporal abstraction at scale, memory staleness.
⚠️ Цифры бенчмарков и «лучшие алгоритмы памяти» быстро меняются — сверяй перед использованием.
Формула извлечения: не только близость
Отдельная деталь, которая объясняет, почему Mem0 ведёт себя иначе, чем векторный поиск. Релевантность воспоминания считается как сумма трёх слагаемых:
R(M_i, C) = α · Sim(M_i, C) + β · e^(−λΔt) + γ · F_i
- α — векторная близость. Косинусное сходство воспоминания с текущим контекстом; то единственное, что учитывает обычный RAG.
- β — свежесть. Экспоненциальное затухание: чем дольше воспоминание не использовалось, тем слабее оно тянет. Это механизм забывания, встроенный в саму формулу ранжирования.
- γ — важность. Частота обращений: то, что пригождается часто, поднимается вверх.
Эффект: система сама перестаёт вспоминать устаревшие предпочтения пользователя, не требуя явного удаления. Если человек полгода назад любил один инструмент, а теперь пользуется другим, старый факт формально в памяти останется, но перестанет попадать в контекст.
Отсюда же следует, чем настраивать поведение: соотношением коэффициентов. Поднимая β, получаем агента, живущего последними неделями; поднимая γ — агента, цепляющегося за привычное.
Когда нужен внешний слой и как его проверить
Развилка со встроенной памятью фреймворка разобрана со стороны CrewAI в CrewAI: внешний слой оправдан, когда память должна пережить смену фреймворка, быть общей для нескольких систем или уметь то, чего встроенная не умеет — извлечение фактов, разрешение противоречий, дедупликацию. Если ни одного признака нет, внешний слой добавляет сетевой вызов и зависимость, не покупая ничего.
Проверка качества извлечения на своём домене делается не бенчмарками из раздела выше — они меряют другое. Нужен небольшой набор диалогов вашего типа с вручную выписанным списком фактов, которые должны быть извлечены. Дальше меряются три вещи: доля извлечённых фактов из размеченных (пропуски), доля извлечённого, чего в диалоге не было (выдумывание), и поведение на противоречии — когда пользователь сначала сказал одно, потом другое, память обязана сохранить последнее, а не оба.
Третий пункт важнее первых двух и чаще всего ломается: система, которая аккуратно извлекает факты, но не умеет их обновлять, со временем накапливает взаимоисключающие утверждения и начинает отвечать по устаревшему. Набор для проверки поэтому обязан содержать диалоги с изменением решения по ходу.
Соседи по классу
Mem0 не единственный слой памяти между сессиями, и знать соседей полезно уже потому, что они по-разному решают вопрос «что делать с устаревшим фактом».
memora (github.com/agentic-box/memora, MIT, Python) — тот же класс: постоянная память поверх SQLite, поставляется агенту как MCP-сервер. Отличается двумя решениями, которые стоит знать независимо от выбора инструмента:
- дедупликация при записи вместо накопления повторов — то, что в Mem0 приходится строить политикой (Memory Write Policy);
- линия вытеснения вместо удаления: устаревший факт не стирается, а помечается как заменённый другим, и цепочка замен сохраняется. Это даёт ответ на вопрос «почему система теперь считает иначе», который при простом удалении теряется навсегда.
Второе — общий приём, а не особенность инструмента: та же логика лежит в основе правила вытеснения при ведении этой базы (V3 в .claude/CONTRACT.md).
Exabase (exabase.io, платформа для разработчиков, выделенная из продукта Fabric) — тот же класс, но поставляемый сервисом, а не библиотекой. Три решения, которые стоит знать независимо от выбора инструмента:
- изоляция «базами»: отдельный контейнер памяти на арендатора или проект, выбираемый заголовком запроса, — та же граница, что в Multi Tenancy AI, но вынесенная в адресацию вместо фильтра по метаданным;
- два режима записи: извлечение фактов по умолчанию, дословное сохранение по флагу, — то есть выбор «интерпретировать или сохранить букву» отдан вызывающей стороне (Memory Write Policy);
- признак неизменности у записи, запрещающий автоматическому разрешению противоречий её трогать, плюс откат базы к прежней версии. Вместе это ответ на вопрос, который сама идея автоматического вытеснения создаёт: чем восстанавливать верный факт, вытесненный неверным (Memory Poisoning).
Связано с
- Memory Write Policy — что должно проверяться до сохранения факта
- Memory Boundaries — почему профильная память не то же самое, что база фактов
- Agent Memory — общая модель памяти агента (4 вида, pointers, bi-temporal); Mem0 — конкретная реализация long-term
- Multi Agent Systems — Mem0 как слой координации команды
- CrewAI —
memory_configс провайдером mem0 - RAG — чем Mem0 принципиально отличается (факты vs тексты)
- Memory Poisoning — обратная сторона автоматического вытеснения: вредная запись стирает верную