Mem0

Универсальный слой памяти для агентов: SDK подключается к агенту (LangChain/CrewAI/AutoGen), сам извлекает факты из диалога и хранит их в векторной БД. Ключевое отличие от RAG: RAG хранит тексты, Mem0 хранит факты, извлечённые LLM, — с разрешением конфликтов и дедупликацией. В 2026 память стала самостоятельным архитектурным компонентом со своими бенчмарками.

Суть

«Затолкать всю историю в контекст и надеяться, что модель уследит» — мёртвая парадигма (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 — обратная сторона автоматического вытеснения: вредная запись стирает верную