Память для ИИ-агентов: Mem0, Zep и как это устроено

Большие языковые модели забывают всё, как только заканчивается диалог. Контекстное окно закрывается — и агент снова не помнит, как вас зовут, какой у вас проект и что вы просили вчера. Вокруг этой дыры выросла отдельная категория продуктов: слои персистентной памяти для ИИ-агентов. Два самых заметных игрока — Mem0 (open-source библиотека и облачный сервис) и Zep (память на основе временного графа знаний). Оба обещают одно: чтобы агент помнил пользователя между сессиями, не запихивая в промпт всю историю переписки.

Что вообще значит «память» у агента

Разберём, чем память отличается от того, что уже умеют делать через RAG¹. Классический RAG достаёт релевантные куски из базы документов и подкладывает их в промпт. Память в понимании этих стартапов — это про факты о конкретном пользователе и ходе разговора: предпочтения, решения, имена, обещания, изменившиеся во времени данные.

Ключевая проблема, которую решают Mem0 и Zep, — не «найти документ», а «понять, что факт устарел». Если в марте вы сказали агенту, что работаете в компании А, а в сентябре — что перешли в компанию Б, наивный векторный поиск вернёт обе записи и запутает модель. Хорошая система памяти должна пометить первый факт как неактуальный.

Два разных подхода под капотом

Mem0 работает так: после каждого обмена репликами специальный пайплайн извлекает из диалога факты, сравнивает с уже сохранёнными и решает, что добавить, обновить или удалить. Хранилище — комбинация векторной базы и графа. Разработчик получает простой SDK на Python и JavaScript: add(), search(), get_all().

Zep делает ставку на темпоральный граф знаний (движок Graphiti): факты становятся узлами и рёбрами с отметками времени, когда факт был верен и когда перестал. Это позволяет отвечать на вопросы вида «что клиент предпочитал полгода назад» — то, что обычная векторная память теряет.

Память — это не «больше контекста», а «правильный контекст». Разница между тем, чтобы вывалить агенту всю историю чата, и тем, чтобы дать ему три актуальных факта в нужный момент.

Сравнение подходов

Прямое сравнение упирается в то, что часть продуктов — библиотеки, которые вы разворачиваете сами, а часть — облачные сервисы с оплатой за использование. Сводим то, что известно публично.

Цифры производительности эти проекты публикуют в собственных бенчмарках (Mem0 приводил сравнения на датасете LOCOMO для оценки долгих диалогов), но самостоятельно перепроверенных независимых замеров по единой методике пока мало. Относитесь к маркетинговым графикам осторожно: тест на диалогах — не то же самое, что ваш продакшн.

Сколько это стоит

Open-source части бесплатны — платите за инфраструктуру, где всё крутится. Облачные тарифы обеих компаний устроены по принципу «оплата за операции с памятью и объём хранения» и периодически меняются. Актуальные цены и лимиты бесплатного плана сверяйте на официальных страницах Mem0 и Zep, а не по цифрам из обзоров: они устаревают за месяцы.

Скрытая стоимость важнее прайса. Каждое извлечение фактов из диалога — это дополнительные вызовы LLM. При активном использовании счёт за токены на обработку памяти может оказаться сопоставим со счётом за сами ответы агента. Считайте обе статьи.

Кому это пригодится и кому нет

Персистентная память оправдана не везде. Разложим по сценариям.

• Стоит брать: персональные ассистенты и коучинг-боты. Пользователь возвращается неделями, агент должен помнить контекст. Здесь память — половина ценности продукта.
• Стоит брать: агенты поддержки с долгой историей клиента. Когда важно, что клиент менял тариф, жаловался на конкретную проблему полгода назад, — темпоральный граф Zep здесь по делу.
• Стоит брать: многошаговые агенты. Когда задача растягивается на много сессий, а вываливать всю историю в контекст дорого и шумно.
• Не нужно: одноразовые задачи. Суммаризация документа, генерация текста, разовый запрос — памяти между сессиями там нет по определению.
• Не нужно: чистый поиск по базе знаний. Если задача — «найти ответ в документации», хватит обычного RAG без слоя фактов о пользователе.
• Спорно: MVP на выходных. Пока не ясно, вернётся ли пользователь, тащить внешний сервис памяти рано. Начните с сохранения краткого профиля в своей БД.

Что стоит проверить перед внедрением

1. Где физически хранятся данные пользователей и подходит ли это под ваши требования к персональным данным.
2. Как система разрешает конфликты фактов — обновляет, дублирует или молча теряет старое.
3. Сколько дополнительных вызовов LLM порождает запись и чтение памяти — считайте на реальном объёме диалогов.
4. Есть ли self-hosted вариант, если вендор поднимет цены или закроется. Открытое ядро здесь — страховка.
5. Насколько легко экспортировать накопленную память, если решите сменить поставщика.

¹ RAG (Retrieval-Augmented Generation) — генерация с дополнением поиском: перед ответом система находит релевантные фрагменты во внешнем хранилище и подкладывает их в промпт модели, чтобы та отвечала на основе актуальных данных, а не только на памяти обучения.