Когда становится ясно, что ассистенту нужна память, первый импульс — не писать её самому, а взять готовую библиотеку. Их несколько, они решают разные части задачи, и разница между ними — не в качестве, а в том, какую модель хранения они вам навязывают. Выбрав библиотеку, вы выбрали архитектуру памяти, и поменять её потом будет стоить переноса данных.
Сведения о сторонних проектах проверялись 26.08.2026 и относятся к быстро меняющимся продуктам; конкретные возможности, API и лицензии проверяйте на момент чтения.
#Три подхода, а не три продукта
Полезнее сравнивать не названия, а модели хранения, потому что именно они определяют, что вы сможете и чего не сможете.
Память как операционная система (наследие MemGPT, развитие — Letta). Идея: языковая модель работает как процесс с ограниченной оперативной памятью и внешним хранилищем, а специальные инструменты позволяют ей самой перекладывать данные между уровнями. Ассистент решает, что вытащить и что убрать, вызывая функции памяти в ходе рассуждения.
Память как слой извлечённых фактов (Mem0). Идея: из диалога вытаскиваются короткие устойчивые утверждения, и над ними выполняется решение — добавить, обновить, удалить или ничего не делать, — чтобы новый факт не сосуществовал со старым противоречащим.
Память как темпоральный граф (Zep/Graphiti и родственные). Идея: сущности и связи между ними с отметками валидности во времени; ответ на вопрос собирается обходом графа, а устаревшая связь не удаляется, а помечается недействительной.
Четвёртый вариант — не брать библиотеку вовсе и хранить факты в своей базе — обычно даже не рассматривают, хотя для персонального масштаба он часто оказывается самым дешёвым.
#Сравнение по свойствам
| Свойство | ОС-подход | Слой фактов | Темпоральный граф |
|---|---|---|---|
| Единица хранения | блок памяти | короткое утверждение | сущность и связь |
| Кто решает, что помнить | модель на ходу | модель после обмена | правила извлечения |
| Разрешение противоречий | не встроено | ключевая функция | по времени валидности |
| Многошаговые вопросы | слабо | слабо | сильно |
| Задержка ответа | растёт заметно | почти не растёт | зависит от обхода |
| Требования к модели | высокие | средние | средние-высокие |
Строка про задержку часто решает выбор на практике. ОС-подход означает, что модель в процессе ответа вызывает инструменты памяти — иногда несколько раз. На сильной облачной модели это приемлемо; на небольшой локальной, да ещё через сетевой туннель, каждый вызов складывается в ожидание, и ассистент становится медленным на всех запросах, включая те, где память не нужна.
Строка про разрешение противоречий — вторая по важности. Без неё в памяти накапливаются взаимоисключающие утверждения, и ответ определяется тем, какое из них ближе к формулировке вопроса.
#Что каждый подход делает хорошо
ОС-подход силён в длинных рабочих сессиях, где ассистент действительно должен управлять своим вниманием: вытащить нужный документ, поработать, убрать. Он даёт наиболее «агентное» поведение и лучше всего смотрится там, где модель мощная и задержка не критична.
Слой фактов силён компактностью и предсказуемостью. Итог его работы — короткий читаемый список, который можно показать человеку и дать ему поправить. Это единственный из трёх подходов, где память по построению обозрима.
Темпоральный граф силён на вопросах о связях и об изменениях: «кто из моих контактов пересекается с этим проектом», «когда это перестало быть верным». Ни один из двух других на них не отвечает — разбор границы между графом и поиском есть в сравнении графа знаний и векторного поиска.
#Слабые стороны, о которых стоит знать заранее
Раздел не короче предыдущего, потому что выбирают обычно по слабостям.
ОС-подход требует сильной модели. Многошаговое самоуправление памятью — это надёжное следование инструментам и планирование. Небольшие локальные модели на этом ломаются: вызывают не те инструменты, зацикливаются, теряют нить. Практическое следствие: подход, который в демонстрации на топовой модели выглядит магией, на модели, помещающейся в вашу видеопамять, работает заметно хуже.
Слой фактов зависит от качества извлечения. Всё держится на том, что модель верно определила устойчивый факт и верно решила, что с ним делать. Ошибка на этом шаге не видна: в памяти просто появляется утверждение, которого вы не говорили. Кроме того, подбор похожих фактов для сравнения обычно грубый — по пересечению слов, — и если старый факт сформулирован иначе, противоречие не обнаружится вовсе.
Граф требует сопровождения. Дубли сущностей, мусорные узлы, разные написания одного отношения. Это работа, которая не заканчивается, и на слабой модели извлечения она превышает пользу.
Все три добавляют зависимость. Библиотека памяти — это внешний компонент в самом чувствительном месте системы. Обновление, смена лицензии, изменение формата хранения затрагивают ваши личные данные, а не абстрактный кэш.
#Общий незакрытый вопрос: откуда взялся факт
Все три подхода решают, где хранить и как обновлять. Ни один из них по умолчанию не решает, на каком основании запись появилась.
Практически это выглядит так. В памяти лежит утверждение «пользователь предпочитает утренние встречи». Вопросы, на которые обычно нет ответа:
- из какого именно сообщения это выведено;
- сказал ли это сам пользователь или кто-то в общем чате;
- сколько независимых подтверждений было;
- когда это перестало проверяться.
Пока ответов нет, ошибка извлечения превращается в вашу историю: неверный факт подмешивается в промпт, модель на него опирается, ответ уходит в переписку — и при следующем извлечении подтверждается уже сам собой. Минимальные требования к записи факта, которые разрывают этот цикл, разобраны в тексте про провенанс памяти.
Библиотеки не запрещают вести провенанс — они просто не делают этого за вас, и в типовых примерах использования его нет. Если вы берёте готовое решение, закладывайте этот слой сами: минимально — ссылку на сообщение-источник и признак, кому принадлежит высказывание.
#Как это сделано в Persona и почему без библиотеки
Здесь используется подход «слой фактов» в стиле Mem0, но написанный поверх своей базы, без внешней библиотеки памяти. Причины, по которым так вышло, стоит назвать — они же аргументы за и против готового решения.
За своё: факты живут в той же базе SQLite, что и переписка, поэтому выгрузка данных пользователя и удаление аккаунта затрагивают память той же транзакцией, без синхронизации между хранилищами. Версионирование — два столбца на таблице, а не отдельная подсистема.
Против своего: всё, что библиотека дала бы из коробки, написано вручную и сопровождается вручную. Разрешение противоречий требует локальной модели с поддержкой ответа по строгой схеме; с облачным провайдером этот шаг тихо пропускается, и новый факт просто ложится рядом со старым.
Чего нет: самоуправления памятью в стиле ОС-подхода. Решение сознательное — многошаговые вызовы инструментов на пути ответа делают медленной каждую реплику, а модель у пользователя может быть небольшой.
Что достроено сверху: уровень выводов, которые формируются фоново, ночью, и не исполняются моделью напрямую — предложения проходят отдельную детерминированную проверку. Как устроены уровни памяти целиком, разобрано в материале про иерархическую память, а общий механизм — в статье о том, как работает память у ИИ.
Прямое сопоставление с Mem0 по конкретным свойствам — в сравнении Persona и Mem0.
#Лицензии и ограничения
Общее предупреждение, которое важнее конкретных названий: лицензия библиотеки памяти касается ваших личных данных, и её стоит прочитать целиком, а не по бейджу в описании. Проверять надо три вещи.
Тип лицензии кода. Разрешительная и копилефт-лицензии накладывают разные обязательства, если вы встраиваете компонент в свой продукт. У части проектов в этой нише лицензия менялась по ходу развития.
Есть ли облачная составляющая. Часть библиотек памяти предлагает управляемый сервис, и в примерах из документации нередко используется именно он. Проверьте, куда по умолчанию идут ваши тексты.
Что требуется сверх самой библиотеки. Отдельная векторная база, отдельная графовая база, платный ключ к модели-эмбеддеру — эти требования проявляются не сразу и меняют оценку стоимости решения.
Конкретные лицензии и условия здесь не приводятся намеренно: они меняются, и любое утверждение о них устареет раньше, чем вы это прочитаете.
#Частые вопросы
#Что выбрать для личного ассистента на локальной модели?
Слой извлечённых фактов: он наименее требователен к модели, даёт обозримый результат и почти не добавляет задержки. ОС-подход на небольшой локальной модели работает ненадёжно, граф требует сопровождения.
#Нужна ли библиотека вообще?
Для персонального масштаба — часто нет. Таблица фактов с версионированием, полнотекстовый индекс и один короткий вызов модели после обмена репликами закрывают большую часть задачи, а зависимости не добавляют. Библиотека окупается, когда вам нужны сразу несколько моделей хранения и вы не готовы писать их сами.
#Чем Letta отличается от MemGPT?
MemGPT — исследовательская работа и её первая реализация, Letta — продолжающий её проект. Практически это один подход: память как уровни, которыми модель управляет через инструменты. Текущее состояние проекта требует проверки на дату чтения.
#Можно ли перенести память из одной библиотеки в другую?
Технически да, если у вас есть выгрузка в структурированном виде: факты — это текст с метаданными. Практически перенос теряет то, что специфично для модели хранения: связи графа не превращаются в плоские факты без потерь, и наоборот.
#Как проверить качество библиотеки памяти до внедрения?
Прогоните на своих данных двадцать реальных вопросов и посмотрите не на ответы, а на содержимое памяти: сколько записей верны, сколько дублируются, сколько вы не говорили. Качество памяти видно в списке фактов, а не в качестве ответов, где ошибки маскируются.
#Вывод
Выбирайте не библиотеку, а модель хранения: слой фактов, если нужна обозримая память на скромной модели; граф, если у вас много вопросов о связях и есть силы его чистить; ОС-подход, если модель сильная и задержка не критична. И независимо от выбора закладывайте провенанс сами — ни один из трёх подходов не даст его из коробки, а без него любая ошибка извлечения тихо становится частью вашей истории.