Память агента - это не RAG: что реально работает в пет-проекте, а что оказалось оверинжинирингом

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

Повод разобраться дал анонс воркшопа inite.ai (Михаил Савченко): bitemporal facts, lifecycle, retract/forget, provenance, scopes, SurrealDB, graph ML. Список на тридцать пунктов, и каждый по отдельности звучит разумно. Вопрос только один - что из этого нужно проекту, у которого фактов в памяти пара десятков, а не пара миллионов.

Чем память агента отличается от RAG?

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

Разница не косметическая. RAG достаёт чанки изолированно: он не знает, что "Даша" из вчерашнего разговора и "Даша", про которую я писал неделю назад, - один человек. По данным Letta и Vectorize (2025), у RAG нет разрешения сущностей и связей между ними, он тянет похожий текст и на этом всё. Память же хранит опыт и факты: кто ты, что мы решили в прошлый раз, какие грабли уже собрали. Поэтому "прикрутить векторный поиск к докам" и "сделать агенту память" - это не одна и та же задача, хотя внутри у обоих может лежать один и тот же эмбеддинг.

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

Нужна ли графовая база для памяти в маленьком проекте?

Нет. Графовая база и темпоральный граф знаний - это про энтерпрайз, где сотни сущностей и связей надо держать во времени. В петпроекте на десяток-другой фактов граф - оверинжиниринг: возни на неделю, а пользы на пшик. Инструменты вроде Zep решают реальную боль, просто не мою.

Zep (arXiv, январь 2026) строит темпоральный граф знаний через движок Graphiti: факты с периодами валидности, обновление без потерь, история отношений. Цифры у него хорошие - 94.8% против 93.4% у MemGPT на бенчмарке DMR и до +18.5% на LongMemEval при задержке ниже на 90%. Но обратите внимание, за счёт чего этот выигрыш: за счёт того, что сущностей и их связей реально много и они меняются во времени. У меня в проекте "сущностей" - я, пара проектов и список того, что агент не должен ломать. Граф на этом - как экскаватор, чтоб выкопать лунку под редиску.

Забавно, что сам факт "память лучше, чем тащить всё в контекст" никто не отменял. Просто планка, с которой она окупается, гораздо ниже графа.

Как устроен жизненный цикл факта: забыть, отозвать, перезаписать?

Жизненный цикл факта - это правила, по которым память меняется: факт можно добавить, перезаписать при обновлении, отозвать как устаревший и удалить совсем. В энтерпрайзе для этого держат bitemporal-модель: две оси времени (когда факт стал верен и когда мы про это узнали), provenance, decision log. В петпроекте я свёл это к трём операциям над обычными файлами.

Перезаписать - отредактировать файл с фактом. Забыть - удалить файл. Отозвать устаревшее - при обращении проверить, что факт ещё в силе, и если решение автора поменялось, поправить. Даты я просто пишу текстом внутри факта ("решение от 2026-07-10: длинные тире не используем"), и этого хватает, чтобы агент не тащил протухшую установку. Никакого bitemporal, потому что мне не надо реконструировать, что я думал о проекте на прошлой неделе, - мне надо, чтобы он делал правильно сейчас.

Единственное, что я оставил из "взрослого" списка, - это провенанс в лайт-версии: у каждого факта помечен тип (кто я, обратная связь, контекст проекта, ссылка на внешний ресурс). Это дёшево и реально помогает агенту решать, чему верить.

Что реально работает: файлы вместо векторной базы

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

Звучит примитивно? Ну да. Зато я вижу глазами всю память агента, могу поправить факт в редакторе и откатить через git, если агент запомнил дичь. Для сравнения, "взрослые" системы памяти делают ставку на структуру: MemGPT (2023) вообще подаёт это как операционную систему для LLM - иерархия памяти, виртуальный контекст, пейджинг между контекстным окном и внешним хранилищем. Красиво и по делу, когда у тебя безлимитный диалог на тысячи сообщений. У меня диалоги короче, а фактов мало, поэтому вся эта машинерия схлопывается в папку с текстовиками.

При этом сам тезис "память экономит" подтверждается железно. По данным Mem0 (ECAI 2025), память держит запрос под 7000 токенов против 25000+ у полного контекста - это около 90% экономии токенов, а p95-задержка падает с 17 секунд до 1.44 - минус 91%. Точность при этом не проседает: 66.9% против 52.9% у памяти OpenAI на бенчмарке LOCOMO. Вывод простой: память заводить стоит, просто необязательно в тяжёлой версии.

Где промпт-инжиниринг решает больше, чем инфраструктура

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

Правила выходят до обидного приземлённые. Один факт - один файл, не сваливать три мысли в кучу. Перед тем как советовать по памяти, проверь, что упомянутый файл или флаг ещё существует. Не плоди дубли - сначала поищи, нет ли уже факта про это. Помечай тип и дату. Всё. Эти пять строк дают больше, чем любой векторный поиск, потому что чинят главную беду агентской памяти - не "как найти факт", а "как не запомнить мусор и не поверить в устаревшее".

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

Нужен ли MCP-сервер для памяти агента?

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

Я поймал себя на желании завернуть память в MCP просто потому, что "так более по-взрослому". Остановил ровно тот же вопрос, что и с графом: какую мою боль это лечит? Если агент и так читает и пишет файлы в своей папке, протокол поверх этого - лишний слой, который может отвалиться в самый неудобный момент (а в headless-запусках оно так и норовит). MCP - штука полезная, когда память общая на парк агентов или живёт в отдельном сервисе. Появится у меня такой сценарий - заведу. Пока нет - забей.

Что из этого оказалось оверинжинирингом

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

А реально работает скучное: markdown-файлы (один факт - один файл), индекс, пометки типа и даты, пять правил в промпте и git как бэкап и откат. Плюс само понимание, что память агента - это не RAG и не поиск, а место, где живут решения и грабли. Цифры Mem0 и Zep говорят, что тяжёлая память окупается на масштабе, но окупается она там, где масштаб есть. В петпроекте выигрывает тот, кто вовремя не начал строить космолёт.

Такие дела. Пойду допишу пару фактов агенту - руками, в файлике.