Память и история чата - разные вещи

Это ключевая идея, без которой код Mem0 выглядит почти магией. По умолчанию библиотека не складывает в базу каждую реплику дословно - она получает сообщения и извлекает из них компактные факты.

Именно поэтому память обычно намного компактнее полного лога переписки: в модель возвращаются не все старые сообщения подряд, а небольшое количество фактов, связанных с текущим вопросом.

Технически это разворачивается в две фазы, и в приложении Mem0 появляется ровно в двух местах. При вызове add() начинается фаза записи: библиотека ищет связанный существующий контекст, извлекает из новых сообщений факты, удаляет точные дубли, создаёт embeddings и сохраняет результат вместе с идентификаторами и метаданными. При вызове search() работает фаза чтения: запрос превращается в пригодное для поиска представление, Mem0 ранжирует кандидатов, применяет фильтры и возвращает лучшие воспоминания. Что делать дальше, решает ваш код - сколько результатов вставить в prompt и как сформулировать системную инструкцию.

Одна оговорка сэкономит вам время, если вы будете сверяться со статьями в интернете. В апреле 2026 проект сменил схему извлечения и поиска, поэтому многие старые примеры описывают предыдущую архитектуру. Изменилось три вещи. Автоматическое извлечение стало ADD-only: оно добавляет новые факты и больше не пытается в том же проходе модели сделать update или delete старых - если пользователь сообщил новый факт, тот может встать рядом с прежним, а явное исправление и удаление выполняет ваше приложение. Поиск стал multi-signal: он сочетает семантическую близость, ключевые слова по BM25 и совпадение сущностей, то есть смотрит не только на похожесть смысла. И появился entity linking: из памяти извлекаются именованные сущности - люди, организации, места, объекты, события и ещё несколько типов, всего одиннадцать принимаемых, - и совпадение по ним поднимает запись в выдаче. Даты, числа и денежные суммы при этом отбрасываются намеренно. Важная оговорка: сущности и BM25 только меняют порядок, но не расширяют выборку - кандидатов по-прежнему приносит семантический поиск. Полноценная Graph Memory в текущей архитектуре остаётся функцией Mem0 Platform, а не отдельным модулем OSS.

Из той же миграции вытекает деталь, на которой спотыкается старый код: в актуальном Python OSS user_id для search() и get_all() передаётся внутри filters. Вызов вида search("...", user_id="alice") относится к прежнему API.

Из каких частей собрана память

Mem0 удобнее воспринимать не как одну базу данных, а как небольшой конвейер, где основные компоненты в OSS меняются независимо друг от друга. Это и есть главная причина, по которой люди выбирают открытую версию.

В конфигурации Python по умолчанию документация указывает модель OpenAI gpt-5-mini, embeddings text-embedding-3-small, локальный Qdrant в /tmp/qdrant и историю в SQLite по пути ~/.mem0/history.db. Держите этот список в голове: он объясняет, почему для первого же запуска понадобится ключ доступа к модели.

Установка и первый сохранённый факт

Минимальная установка Python-версии выглядит так:

Если вы остаётесь на конфигурации по умолчанию, нужен ключ OpenAI:

Ключ нужен не потому, что библиотека платная, а потому, что Mem0 сам разговор не "понимает": модель используется для извлечения фактов, а embedding-модель - для представления текста в виде векторов. В открытой версии оба компонента заменяемы, в том числе на локальные через Ollama - к этому мы вернёмся ближе к концу.

Для расширенного гибридного поиска README отдельно предлагает NLP-зависимости:

Теперь самое интересное - первая запись. Обратите внимание, что мы передаём не заранее подготовленный факт, а обычные сообщения диалога:

Memory() создаёт движок памяти с компонентами по умолчанию, add() анализирует сообщения и выделяет то, что стоит сохранить, а user_id="alex" привязывает память к конкретному человеку - и это критично, как только пользователей становится больше одного. В базе появится что-то компактное вроде "Пользователя зовут Алекс" и "Алекс любит баскетбол и видеоигры", а не обязательная копия всей переписки.

Поиск и рабочий цикл

Достать факт можно тем же человеческим языком, которым он был сказан:

Здесь происходит принципиально иная операция, чем в обычной базе. Мы не просим найти строку "баскетбол" - мы задаём вопрос, а Mem0 ищет воспоминания, смысл которых связан с запросом, и возвращает лучших кандидатов. Параметр top_k=3 означает "верни не больше трёх подходящих воспоминаний"; это не магическое правильное число, его подбирают под конкретный продукт по качеству ответов, задержке и размеру контекста. Если вы переезжаете со старой версии, учтите, что в актуальном OSS значение top_k по умолчанию равно 20, а порог threshold - 0.1, так что количество результатов может неожиданно измениться.

Но сама память пользователю не отвечает. Её результаты нужно передать модели, и вот как выглядит полный цикл:

Порядок здесь важнее синтаксиса. Сначала читаем память - до обращения к модели ищем факты, которые могут помочь с текущим вопросом. Затем превращаем результаты в обычный текст, потому что модель не знает, что такое объект Mem0, ей нужен текстовый контекст. Модель отвечает, воспринимая эти воспоминания как дополнительную информацию, а не как встроенную магию. И уже после ответа мы отдаём свежую пару реплик обратно в память, чтобы из неё извлеклись новые долговременные факты.

Получается цикл: найти прошлое, ответить с учётом прошлого, сохранить новое. Именно он превращает обычный вызов модели без состояния в приложение, которое постепенно накапливает контекст.

Чья это память

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

На практике это выглядит так:

Дальше можно искать строго в памяти нужного пользователя и нужной категории, а не надеяться, что поиск по смыслу сам случайно не подхватит чужой факт.

Память нужно уметь не только добавлять

Реальный продукт обязан позволять исправлять и удалять знания: человек меняет адрес, отказывается от прежнего предпочтения или просто просит удалить данные о себе.

После перехода на ADD-only алгоритм это стало особенно важным. Автоматическое извлечение только добавляет факты, поэтому если приложению нужно гарантированно заменить конкретное старое знание, делайте это явным вызовом update() или delete(), а не надейтесь, что новый факт вытеснит прежний сам.

Иногда интерпретация вообще не нужна - текст надо сохранить дословно. Для этого есть отдельный флаг:

Такой режим полезен для уже подготовленных фактов, машинных событий и текстов, где любое перефразирование нежелательно. Но если вы передаёте обычный длинный диалог, автоматическое извлечение обычно даёт более чистую и удобную для поиска память.

С обратной стороны цикла - на чтении - у вас тоже есть управление. Семантическая близость не должна быть единственным способом выбрать память: иногда вы точно знаете, что искать нужно только среди рабочих заметок или только у конкретного пользователя.

Сначала фильтры отсекают заведомо неподходящие записи, а reranker, если он настроен, вторым проходом меняет порядок найденных кандидатов. Это может улучшить точность, но добавляет задержку, а с внешним провайдером - и стоимость.

Конфигурация, с которой можно выходить в production

Конструктор Memory() хорош для первого запуска, но в продакшене лучше явно решить, где живут данные и какими моделями они обрабатываются.

По сравнению с настройками по умолчанию меняются четыре вещи. Qdrant вынесен явно, и вы контролируете адрес сервера и имя коллекции вместо неявного локального хранилища. Модель для извлечения настроена отдельно, так что провайдера и параметры можно менять. Embedder независим от LLM - это разные задачи, и решать их могут разные модели. А reranker остаётся опциональным: его стоит подключать после того, как вы измерили качество базового поиска, а не просто потому, что он существует. Отдельно стоит запомнить рекомендацию документации держать температуру модели для извлечения около 0.2 или ниже - так память получается стабильнее.

То же самое на Node.js

Концепция от языка не меняется, отличаются синтаксис и соглашения об именах: Python использует snake_case, а TypeScript - camelCase. Единственная тонкость, на которой легко споткнуться: в Node открытую версию нужно импортировать из mem0ai/oss.

Когда память нужна не одной функции, а нескольким сервисам

Если к памяти обращается несколько приложений, удобнее поднять отдельный REST-сервис - в репозитории для этого есть Docker-стек с API и дашбордом. Быстрый путь из README:

Или обычный запуск контейнеров:

По актуальной документации эталонная установка использует порт 8888 для API и 3000 для дашборда, а сам сервер включает аутентификацию, персональные API-ключи и журнал запросов. Здесь же прячется грабля, которая стоит дорого: переменная AUTH_DISABLED=true предназначена только для локальной разработки. Память часто содержит пользовательские данные, поэтому открытый endpoint без аутентификации на публичном сервере превращается в прямую утечку.

Отдельный вопрос - можно ли замкнуть всё внутри своей инфраструктуры. Да: открытая версия позволяет заменить внешнюю модель и embedder на локальные, например через Ollama, а векторное хранилище держать на своей машине - тогда backend не отправляет память в облако, факты извлекаются локально, embeddings строятся локально, а Qdrant или pgvector хранят векторы у вас.

Но "self-hosted Mem0" и "всё локально" - не одно и то же, и на этом легко себя обмануть. Если вы поднимаете библиотеку у себя, но используете OpenAI для извлечения и embeddings, соответствующие данные всё равно уходят внешнему провайдеру моделей. Чтобы действительно ничего не покидало вашу инфраструктуру, локализовать нужно и модели, и хранилище.

Командная строка и регистрация агента

У проекта есть официальный CLI, и ставится он двумя способами на выбор - через npm или через pip, оба дают одну и ту же команду mem0 с одинаковым поведением. Одну вещь про него нужно понимать сразу: CLI работает с API управляемой платформы, а не с открытым движком памяти, который мы разбирали выше.

Самое любопытное в нём - сценарий регистрации агента. Ключ выпускается без почты, без панели управления и без одноразовых кодов, весь путь укладывается в четыре команды:

Набор команд закрывает обычный жизненный цикл памяти: настройка, добавление, поиск, список, чтение по идентификатору, изменение, удаление, массовый импорт из JSON, работа с сущностями и просмотр фоновых событий вроде массового удаления. Отдельно есть mem0 status для проверки связи и текущего проекта.

Но интереснее другое - режим, сделанный не для человека. Глобальный флаг --agent (он же --json) переводит любую команду в структурированный ответ одинаковой формы: статус, имя команды, длительность, область видимости, количество и данные, очищенные до полей, которые агенту действительно нужны. Спиннеры, цвета и баннеры при этом подавляются полностью, а ошибки уходят в тот же поток вывода тоже как JSON и с ненулевым кодом возврата.

Вторая команда отдаёт всё дерево команд в JSON - чтобы агент мог сам выяснить, что ему доступно, а не полагаться на зашитое в промпт описание. Это редкий случай, когда инструмент проектировался с расчётом, что вызывать его будет программа, а не человек за клавиатурой.

OSS или Platform, и сколько это стоит

Одну деталь из README стоит держать в голове при сравнении цифр: опубликованные результаты бенчмарков управляемой платформы используют проприетарные оптимизации, которых нет в открытом SDK. Переносить эти числа один в один на свою локальную установку нельзя.

С деньгами и данными есть три честных оговорки. Открытый исходный код не означает, что бесплатно всё: сама библиотека открыта, но модели, embeddings, reranker и инфраструктура могут стоить денег, а конфигурация по умолчанию обращается к внешним моделям OpenAI - значит, появляются платные вызовы. Дальше, извлечённая память чувствительнее обычного лога: она специально концентрирует важные факты о человеке, поэтому обращаться с ней нужно как с персональными данными - разделять пользователей, контролировать доступ, обеспечивать удаление, не логировать секреты, продумывать срок хранения. И наконец, self-hosted не гарантирует нулевой внешний трафик: проверяйте всю цепочку - модель для извлечения, embeddings, reranker и саму базу, потому что достаточно одного облачного компонента, чтобы часть данных ушла наружу.

Когда Mem0 нужен, а когда лишний

Хороший сценарий для отдельного слоя памяти - личный ассистент, который должен помнить предпочтения месяцами; бот поддержки, которому нужен контекст прошлых обращений; агент, работающий над проектом в нескольких сессиях; приложение с персональными рекомендациями; наконец, несколько агентов, которым нужен управляемый общий слой долгосрочного контекста.

И наоборот, Mem0 будет лишним в одноразовом чате на несколько сообщений; в обычной CRUD-системе, где данные уже структурированы и достаются SQL-запросом; в задаче, где нужно дословное архивирование переписки, а не извлечение фактов; в простом RAG по статической документации, если персональная и меняющаяся память не нужна.

Здесь же полезно различать две вещи, которые часто путают. RAG отвечает на вопрос "какие внешние знания относятся к запросу?", а слой памяти - на вопрос "что этот агент уже знает о пользователе, прошлых действиях и предыдущих сессиях?". В одном продукте обе системы спокойно живут рядом.

Шесть ошибок первого знакомства

Передавать всю память всем пользователям. Если память персональная, ограничивайте поиск как минимум правильным user_id.

Считать add() обычным INSERT. При включённом извлечении это конвейер с участием модели, и результат может оказаться компактнее и формальнее исходного текста.

Смешивать документацию OSS и Platform. Смысл у продуктов общий, а возможности и классы разные: Memory относится к открытой версии, MemoryClient - к Mem0 Platform.

Брать старые примеры API. После миграции 2026 года изменилась часть параметров и значений по умолчанию - особенно заметно в search(), get_all(), фильтрах сущностей, top_k, threshold и поведении извлечения.

Считать, что больше памяти автоматически лучше. Цель поиска не в том, чтобы вернуть как можно больше текста, а в том, чтобы дать достаточно полезного контекста и не утопить модель в нерелевантных воспоминаниях.

Не предусмотреть удаление. У любой долгоживущей пользовательской памяти должен быть понятный жизненный цикл: как обновить факт, как удалить одну запись, как удалить память человека целиком и что делать с временными данными.

Если свести всё к одной формуле, она будет такой: смысл Mem0 не в том, чтобы запихнуть весь прошлый чат в базу, а в том, чтобы превратить прошлые взаимодействия в управляемые факты и возвращать модели только тот маленький набор прошлого, который помогает ответить сейчас.

Источники

Статья сверена с репозиторием и официальной документацией Mem0 9 августа 2026 года. Дополнена 14 августа 2026 года: перепроверены значения по умолчанию и сигнатуры по свежему клону, уточнён разбор поиска по сущностям, исправлен ключ фильтра в примере на TypeScript, добавлен раздел про командную строку. Проект активно развивается, поэтому перед переносом кода в новый проект стоит заново сверить migration guide и quickstart установленной версии.

• GitHub: mem0ai/mem0
• Командная строка mem0
• Регистрация агента
• How Mem0 Works
• Memory Types
• Add Memory
• Search Memory
• Open Source Python Quickstart
• Open Source Node.js Quickstart
• Configure the OSS Stack
• Self-Hosted Setup
• OSS v2 - v3 migration
• Platform vs Open Source