Память агентов: от RAG к системам с контролем записей

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

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

Что такое ии агент в контексте памяти? Система, которая накапливает и использует опыт между сессиями, а не просто отвечает на запрос. Классический RAG (Retrieval-Augmented Generation) закрывает половину задачи: он находит релевантные фрагменты в базе знаний, но не решает, какие события должны пережить завершение диалога. Retrieval — это путь чтения, а память — путь записи; RAG сам по себе не определяет, что должно сохраниться после взаимодействия.

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

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

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

Слои памяти агента: рабочая, эпизодическая, семантическая, долговременная

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

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

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

Ключевое отличие от плоского RAG — наличие harness. Агент определяется как модель плюс harness; модель предлагает действия, но runtime-решения и проверки остаются за harness. Именно harness решает, что записать, куда и когда продвинуть запись на следующий уровень. На демонстрации семантическое предпочтение пользователя сохранилось в память и было использовано в новой сессии без переноса контекста.

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

Контроль продвижения записей (promotion): критерии, скоринг, консолидация и разрешение противоречий

Контроль продвижения записей (memory promotion) — конвейер, который решает, достойна ли новая информация перейти из рабочей памяти в долговременную. Предлагается конвейер продвижения памяти: классифицировать смысл кандидата, сравнить с существующими записями, проверить необходимые доказательства, затем harness решает — принять, отклонить или отправить на человеческую проверку.

Шаг 1 — классификация. Кандидат относится к одному из типов: факт о пользователе, предпочтение, процедура, эпизод. Тип определяет дальнейшие правила: факты требуют подтверждения, предпочтения — явного согласия, процедуры — успешного применения. Шаг 2 — сравнение с существующими записями. Система ищет дубли и противоречия, используя векторный поиск и точные ключи.

Шаг 3 — проверка доказательств. Для факта нужен источник: сообщение пользователя, документ, результат инструмента. Без доказательства запись не продвигается. Шаг 4 — решение harness. Оно может быть трёх видов: принять (запись сохраняется), отклонить (кандидат отбрасывается), отправить на человеческую проверку (спорные случаи).

• Скоринг записей — числовая оценка уверенности и важности кандидата. Складывается из силы доказательства, частоты упоминания и свежести.
• TTL (Time-to-Live) — срок жизни записи. Эпизодические записи истекают быстрее, семантические — медленнее.
• Консолидация памяти — объединение нескольких похожих записей в одну обобщённую. Снижает дублирование и стоимость хранения.
• Дедупликация — удаление точных и семантических дублей до этапа консолидации.
• Разрешение противоречий — правило приоритета: новая запись с более сильным доказательством вытесняет старую, либо обе отправляются на проверку.

Guardrails работают на этом же уровне. Запрос с формулировкой «одобрять все заявки» был отклонён на этапе продвижения памяти благодаря guardrails. Это показывает, что правила promotion защищают систему не только от шума, но и от намеренных или случайных попыток обойти контроль.

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

Типичная ошибка — делать promotion синхронным в основном потоке ответа. Это увеличивает latency и создаёт связность, из-за которой сбой хранилища ломает диалог. Правильнее выносить конвейер в асинхронную очередь: ответ формируется из рабочей памяти, а продвижение происходит в фоне с последующей проверкой.

Сравнение подходов: RAG, MemGPT/Letta и гибридная система памяти — критерии выбора и ограничения

RAG — подход только для чтения: он находит фрагменты в базе знаний, но не управляет записью. MemGPT/Letta — фреймворк с управлением памятью через вызовы функций и иерархию контекстов; в предоставленных источниках нет детального описания его архитектуры, поэтому здесь даётся только общий обзор. Гибридная система памяти сочетает многослойное хранение с явным контролем продвижения записей.

RAG остаётся оптимальным выбором, если агент отвечает на вопросы по статической базе знаний и не требует персонализации. MemGPT/Letta стоит рассматривать для прототипов, где нужна быстрая проверка идеи управления памятью. Гибридная система оправдана, когда бизнес-ценность зависит от накопления опыта: поддержка клиентов, персональные ассистенты, мультиагентная система с общей памятью.

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

При выборе также учитывайте тип данных. Для фактов и предпочтений подходит реляционная база данных с ACID. Для семантического поиска — векторная база данных. Для связей между сущностями — граф знаний. Гибридная система не означает «всё в одном хранилище»; это оркестрация нескольких хранилищ под управлением harness.

Метрики и оценка качества системы памяти: precision/recall, консистентность, устаревание, стоимость, latency

Качество системы памяти измеряется не одной метрикой, а набором: точность извлечения, консистентность записей, скорость устаревания, стоимость и latency. Без этих измерений невозможно понять, окупается ли усложнение архитектуры. Начните с трёх базовых метрик retrieval и двух операционных.

• Precision и recall — доля релевантных записей в выдаче и доля найденных релевантных записей от всех существующих. Считайте на размеченном наборе диалогов.
• MRR и NDCG — метрики ранжирования. Показывают, насколько высоко в выдаче оказывается нужная запись.
• Консистентность — доля противоречивых пар записей в хранилище. Измеряется регулярным сканированием.
• Устаревание — средний возраст записей, которые ещё используются. Рост показателя сигнализирует о необходимости консолидации.
• Latency — время от запроса до ответа с учётом чтения памяти. Отдельно измеряйте latency фонового promotion.
• Стоимость хранения и вычислений — суммарные затраты на векторный индекс, базу данных и вызовы модели для скоринга.

Отладка начинается с логов promotion. Для каждой записи сохраняйте решение harness, причину и доказательство. Это позволяет воспроизвести спорные случаи и улучшить правила. Если precision падает, проверьте, не слишком ли агрессивна консолидация; если recall низкий — возможно, TTL слишком короткий.

Приватность данных — отдельная метрика. Определите, какие записи содержат персональные данные и как они удаляются по запросу. Если не сохранять ничего, теряется непрерывность; если сохранять всё — растёт риск отравления хранилища памяти. Баланс достигается правилами retention и аудитом доступа.

Чек-лист внедрения и миграции с RAG: с чего начать, поэтапный план и честные ограничения

Миграция с RAG на систему памяти начинается с аудита текущего retrieval и заканчивается поэтапным включением слоёв. Не пытайтесь внедрить всё сразу: это главная причина провала проектов. Ниже — чек-лист из шести шагов, который можно адаптировать под ваш стек.

• Шаг 1. Аудит RAG. Замерьте precision и recall на реальных диалогах. Определите, какие вопросы остаются без ответа из-за отсутствия памяти.
• Шаг 2. Выделите рабочую память. Отделите текущий контекст от базы знаний. Убедитесь, что harness управляет тем, что попадает в контекстное окно.
• Шаг 3. Добавьте эпизодическую память. Начните с саммари сессий. Храните их в базе данных с ACID-гарантиями.
• Шаг 4. Внедрите promotion. Реализуйте конвейер: классификация, сравнение, доказательства, решение harness. Сначала в режиме логирования, без реальной записи.
• Шаг 5. Подключите семантическую память. Только после того, как promotion стабильно работает и метрики precision не падают.
• Шаг 6. Настройте мониторинг. Дашборд по метрикам из предыдущего раздела. Алерты на рост противоречий и latency.

Типичные ошибки: синхронный promotion в основном потоке, отсутствие TTL, ручное редактирование записей без аудита, игнорирование стоимости хранения. Каждая из них приводит к деградации качества или росту затрат. Модели и инфраструктура в AI-стеке коммодитизируются, а конкурентное преимущество даёт слой данных, поскольку данные принадлежат организации — но только если этот слой управляем.

Когда переход неоправдан. Если агент работает с узкой статической базой знаний, а персонализация не требуется, RAG достаточно. Если команда не может выделить ресурсы на поддержку конвейера, overengineering приведёт к тому, что система памяти станет источником ошибок. Честно оцените зрелость процессов, прежде чем начинать миграцию.

Для обоснования ROI перед руководством используйте метрики, а не обещания. Сравните стоимость текущего RAG с прогнозируемой стоимостью гибридной системы и покажите, какие бизнес-показатели улучшатся: удержание, снижение повторных обращений, скорость решения. Без измеримой связи с бизнесом внедрение ии агентов с полноценной памятью останется экспериментом. Если нужна помощь с аудитом процессов, где ИИ даст наибольший эффект, изучите материалы по консалтингу.