Память ИИ-агента — это не RAG: как разграничить память, извлечение, состояние и контекст
Память ИИ-агентов, генерацию с расширенным поиском (RAG), состояние во время выполнения (state) и контекст модели часто обсуждают так, будто они взаимозаменяемы. Но это не так. Сведение их к единому понятию затрудняет проектирование агентных систем, усложняет отладку и повышает риск использования устаревших или небезопасных данных.
Категориальная ошибка: считать памятью все, что сохраняет данные
Векторная база данных может хранить фрагменты диалогов. Объект сессии может содержать последние реплики. Строка в базе данных может хранить текущий статус рабочего процесса. Суммаризатор может сжимать результаты предыдущей работы. Ретривер может извлекать прошлые свидетельства. Все это может создавать впечатление, будто агент «помнит», но семантика у этих механизмов совершенно разная.
Это различие критически важно, поскольку к каждому компоненту предъявляются свои требования корректности. Текущее состояние должно быть авторитетным и актуальным. Памяти требуются правила жизненного цикла: записи, пересмотра, забывания и разрешения конфликтов. Поиску необходимы релевантность и качество отбора свидетельств. Контексту нужны дисциплина расхода токенов и защита от нерелевантных или противоречивых данных.
Четырехслойная архитектура: состояние, память, поиск, контекст
| Уровень | Ключевой вопрос | Типичные примеры | Основное требование корректности |
|---|---|---|---|
| Состояние (State) | Что истинно прямо сейчас? | Статус задачи, содержимое корзины, шаг рабочего процесса, активные права доступа, текущее состояние игры | Актуальность и авторитетность |
| Память (Memory) | Что из прошлого должно сохраниться? | Предпочтение пользователя, прошлое решение, усвоенное ограничение, устраненный сбой, неизменный факт о проекте | Жизненный цикл, пересмотр, происхождение данных, забывание |
| Поиск (Retrieval) | Какую информацию следует отобрать сейчас? | Векторный поиск, поиск по ключевым словам, обход графа, реранкинг, поиск по документам | Релевантность и отбор свидетельств |
| Контекст (Context) | Что видит модель при данном вызове? | Системные инструкции, текущий запрос, извлеченные фрагменты, результаты работы инструментов, сводки | Полезность на токен, порядок, согласованность, уровень шума |
1. Состояние: что истинно прямо сейчас
Состояние принадлежит работающей системе, а не воспоминаниям модели. Если заказ отменен, деплой приостановлен, пользователь лишен прав или задача перешла из статуса «в работе» в статус «одобрено», авторитетное значение должно поступать из системы, владеющей этим фактом.
Опасный паттерн проектирования — позволить старой сводке диалога подменять собой текущее состояние. Агент может безошибочно помнить, что вчера заказ был активен, но сегодня это утверждение уже неверно. Поэтому состоянию требуются явный владелец данных, версионирование или временные метки (где это применимо), а также механизм повторного чтения первоисточника перед выполнением критически важных действий.
2. Память: что из прошлого должно сохраниться
Память — это не просто «все, что мы можем сохранить». Полноценный слой памяти определяет, что заслуживает сохранения, в каком виде, на какой срок, с каким источником происхождения и при каких условиях эти данные должны быть пересмотрены или удалены.
В современных исследованиях памяти агентов хранение сырых логов диалогов все чаще признается недостаточным. Проект PlugMem от Microsoft ориентирован на преобразование необработанных историй взаимодействия в структурированные знания повторного использования. Memora отделяет детализированный хранимый контент от более легковесных абстракций и поисковых ориентиров, избавляя системы с длительным циклом работы от необходимости выбирать между детализацией и масштабируемым доступом.
3. Поиск: что следует отобрать сейчас
Поиск — это механизм отбора. Он может искать по внешним документам, внутренним базам знаний, сохраненной памяти, логам, графам, базам данных или смешанным источникам. RAG обычно находится именно здесь: извлечь свидетельства, поместить отобранные материалы в рабочий ввод модели и затем сгенерировать ответ.
Этот механизм не становится памятью только из-за того, что поисковый корпус содержит прошлые взаимодействия. Один и тот же ретривер может искать документы регламентов, с которыми агент никогда не сталкивался, данные о продуктах из сторонней системы или прошлые решения пользователя. Поиск описывает, как отбирается информация; память описывает, почему определенная информация сохраняется во времени и как управляется это хранение.
4. Контекст: что модель может реально использовать прямо сейчас
Контекст — это слой, обращенный непосредственно к модели. Anthropic описывает контекстную инженерию как определение такой конфигурации контекста, которая с наибольшей вероятностью приведет к желаемому поведению, где контекст — это токены, доступные модели в процессе генерации. В руководстве OpenAI по сессионной памяти обрезка и сжатие аналогичным образом рассматриваются как методы управления контекстом при длительных взаимодействиях с агентом.
Именно поэтому система может обладать превосходной памятью, но все равно давать сбой. Нужное воспоминание может существовать, но не быть извлеченным. Оно может быть извлечено, но помещено в контекст рядом с более убедительным противоречащим текстом. Оно может быть сжато настолько, что исчезнет ключевая деталь. Или же модель может получить такой объем данных, что полезные факты просто растворятся в шуме.
Как взаимодействуют слои
Один из возможных производственных процессов
Почему RAG — это не память
Самый простой тест таков: система RAG может извлечь информацию, которую агент никогда раньше не видел. Одно это доказывает, что поиск и память представляют собой разные абстракции.
RAG отвечает на вопрос: «Какие свидетельства мне следует получить?» Система памяти должна дополнительно отвечать на такие вопросы, как: «Должно ли это событие стать долговременным знанием?», «Заменяет ли эта новая информация более старое воспоминание?», «Можно ли по-прежнему доверять этому воспоминанию?», «Кому разрешено его читать?» и «Когда его следует забыть?»
Тест на разделение четырех слоев
Когда какую-либо функцию называют «памятью», задайте следующие четыре вопроса. Ответы на них обычно показывают, о каком слое идет речь на самом деле.
| Вопрос | Если да, то в первую очередь вы имеете дело с |
|---|---|
| Отражает ли это текущее авторитетное состояние задачи или среды? | Состоянием (State) |
| Должна ли эта информация пережить текущий запуск, поскольку она фиксирует полезный прошлый опыт, предпочтение или решение? | Памятью (Memory) |
| Заключается ли главная задача в определении того, какая сохраненная или внешняя информация актуальна для текущего запроса? | Поиском/извлечением (Retrieval) |
| Заключается ли главная задача в определении того, какую информацию поместить в текущий вызов модели? | Контекстом (Context) |
Один и тот же компонент может участвовать в работе более чем одного слоя. База данных может хранить как состояние, так и память. Векторный индекс может извлекать как внешние знания, так и воспоминания. Это разделение является семантическим, а не обязательно физическим.
Типичные сбои из-за смешения слоев
| Тип сбоя | Что произошло | Результат |
|---|---|---|
| Устаревшее состояние под видом памяти | Доверие оказывается старой сводке вместо повторного чтения данных из авторитетной системы | Агент действует на основе фактов, которые когда-то были правдой |
| Отношение к памяти как к непреложному факту | Прошлое предпочтение или решение сохраняется без правил пересмотра | Устаревшая информация продолжает влиять на последующие ответы |
| Результат поиска принимается за истину | Высокая степень схожести ошибочно принимается за фактическую достоверность | Правдоподобные, но некорректные свидетельства берут верх |
| Перегрузка контекста | В контекст передается слишком много найденных фрагментов, воспоминаний, логов и инструкций | Решающие свидетельства размываются или нейтрализуются противоречиями |
| Неконтролируемая запись в память | Сгенерированные моделью интерпретации автоматически сохраняются как долговременная память | Ошибки закрепляются и усиливают сами себя |
| Отсутствие отслеживания происхождения данных | Система не способна отличить утверждение пользователя от исходного факта, вывода модели или сгенерированной сводки | Последующее извлечение данных лишает информацию статуса доказательности |
Что следует помнить, извлекать, пересчитывать или перечитывать?
| Тип информации | Предпочтительный подход | Причина |
|---|---|---|
| Текущие права доступа, статус заказа, складские запасы, этап рабочего процесса | Повторно считывать авторитетное состояние | Свежесть важнее воспоминаний |
| Устойчивое предпочтение, явно указанное пользователем | Память с семантикой редактирования и удаления | Полезно между сессиями и принадлежит пользователю |
| Решение, принятое в ходе длительного проекта | Память с временной меткой, источником происхождения и правилами замещения | История имеет значение, но решения могут меняться |
| Спецификация продукта или общедоступный нормативный документ | Извлекать из источника | Внешние знания должны оставаться привязанными к своим подтверждающим источникам |
| Производная метрика, которую можно легко рассчитать заново | Пересчитывать | Позволяет избежать сохранения устаревших вычисленных значений |
| Длинный сырой вывод инструмента | Хранить во внешней системе; извлекать или суммаризировать по необходимости | Не расходует контекст на постоянной основе |
| Гипотеза модели или неопределенная интерпретация | Не переносить автоматически в долговременную память | Логический вывод не равнозначен факту |
Системе памяти необходима политика записи, а не только политика извлечения
Обсуждения архитектуры RAG часто сосредоточены на качестве поиска: чанкинге, эмбеддингах, переранжировании, гибридном поиске и заземлении (grounding). Долгосрочная память обнажает другую сторону проблемы: что вообще допустимо сохранять в постоянное хранилище?
Для долговременной памяти агента практичная политика записи должна классифицировать потенциальные воспоминания, сохранять сведения о происхождении данных (provenance), выявлять конфликты с существующими записями, отличать непосредственные наблюдения от умозаключений, определять уровень конфиденциальности и область доступа, а также решать, должна ли информация устаревать, обновляться или требовать подтверждения пользователя.
Происхождение данных — мост между памятью и достоверными доказательствами
Запись в памяти в идеале должна сохранять достаточно сведений о происхождении, чтобы ответить на вопросы: откуда это взялось, когда было зафиксировано, кто или что это утверждало, было ли это предоставлено пользователем или выведено моделью, какой источник это подтверждал и не появилось ли что-то, что это отменяет?
Без сведений о происхождении сжатое воспоминание может стать более авторитетным, чем породившие его свидетельства. Это особенно рискованно в долгоживущих агентах, где саммари и абстракции используются повторно снова и снова. Система может сохранить вывод, потеряв условия, при которых этот вывод был верен.
Больше памяти не означает больше контекста
Долгоживущий агент может накапливать гигабайты состояния, истории, документов и усвоенной информации. Модели не требуется — и обычно не следует передавать — все эти данные на каждом шаге. Цель поиска, обобщения, сжатия и структурированной памяти — преобразовать обширное постоянное информационное пространство в компактный, релевантный рабочий контекст.
Именно поэтому увеличение контекстного окна не устраняет необходимость в архитектуре памяти. Вместимость снижает часть ограничений, но не решает проблем актуальности, авторитетности, противоречивых свидетельств, разграничения доступа, качества записи, обновления данных или выбора того, что действительно заслуживает внимания.
Чек-лист для проектирования продакшен-систем
- Определите, какие системы владеют авторитетным состоянием во время выполнения.
- Определите, какая информация имеет право сохраняться в долговременную память.
- Сохраняйте четкое различие между фактами от пользователя, внешними свидетельствами и выводами модели.
- Прикрепляйте временные метки, сведения о происхождении, область видимости и семантику версионирования к важным воспоминаниям.
- Разделяйте релевантность при поиске и фактическую авторитетность.
- Формируйте контекст осмысленно, а не внедряйте все извлеченные материалы без разбора.
- Перечитывайте изменчивые факты вместо того, чтобы полагаться на старые воспоминания.
- Пересчитывайте простые производные значения заново, если цена их устаревания слишком высока.
- Тестируйте операции записи в память так же тщательно, как и операции чтения.
- Классифицируйте и измеряйте сбои раздельно: ошибки состояния, ошибки памяти, ошибки поиска, ошибки сборки контекста, ошибки рассуждения и ошибки действий.
Что могло бы изменить эти выводы?
Граница между этими слоями может смещаться по мере развития платформ для агентов. Провайдер может предложить управляемый сервис памяти, который берет на себя хранение, ревизию, поиск, обобщение и формирование контекста. Это может объединить компоненты реализации, но не снимает архитектурных вопросов. Вам по-прежнему необходимо понимать, является ли возвращенный элемент текущим состоянием, долговременной памятью, извлеченным свидетельством или просто текстом, помещенным в контекст.
Рекомендация также изменилась бы для систем без преемственности между сессиями, систем, где каждая задача начинается с чистого неизменяемого корпуса, или жестко ограниченных рабочих процессов, где все необходимое состояние гарантированно помещается в один вызов. В таких случаях выделенный уровень долгосрочной памяти может лишь усложнить систему, не принося достаточной пользы.
Ограничения
Терминология в сфере агентных систем все еще стремительно формируется. Некоторые фреймворки называют историю диалога «памятью», другие используют понятия «сессия», «чекпоинт», «хранилище», «контекст» или «состояние». Исследовательские системы также определяют память на разных уровнях — от персистентного поиска до обученной внутренней адаптации. Модель, описанная в этой статье, намеренно разделяет эксплуатационные обязанности, вместо того чтобы пытаться навязать единый универсальный словарь.
Заключение
Практичный вопрос звучит не как «Есть ли у этого агента память?». Он заключается в следующем: что такое состояние, что сохраняется из накопленного опыта, как извлекается нужная информация и что в конечном итоге поступает в модель в виде контекста?
Когда эти зоны ответственности разделены, проектные решения становится проще тестировать. Устаревшие факты можно свести к владению состоянием. Плохую полноту выборки (recall) можно отследить до жизненного цикла памяти или механизма извлечения данных. Перегруженные промпты — до этапа формирования контекста. Стойкие галлюцинации — до политики записи и происхождения данных (provenance). RAG остается важным инструментом, но это лишь одна из составляющих надежной архитектуры долгоживущих агентов.
Часто задаваемые вопросы (FAQ)
Память ИИ-агентов, RAG, состояние и контекст
Является ли RAG тем же самым, что и память ИИ-агента?
Является ли векторная база данных памятью агента?
Устраняет ли увеличенное окно контекста потребность в памяти?
Следует ли сохранять текущее состояние приложения как память?
Глоссарий
Ключевые термины
- Состояние (State)
- Текущее эталонное состояние задачи, приложения, пользователя, рабочего процесса или окружения.
- Память (Memory)
- Информация из предшествующего опыта или взаимодействия, которая сохраняется, поскольку может оказаться полезной в дальнейшем, и подчиняется правилам жизненного цикла.
- Извлечение (Retrieval)
- Механизм, используемый для выбора потенциально релевантной информации из памяти, внешних баз знаний, баз данных, графов или других хранилищ.
- Контекст (Context)
- Информация, фактически доступная языковой модели во время конкретного шага инференса или генерации.
- RAG
- Генерация, дополненная поиском (Retrieval-augmented generation): паттерн, при котором внешняя или сохраненная информация извлекается и передается генеративной модели для улучшения текущего ответа.
- Происхождение данных (Provenance)
- Метаданные, описывающие, откуда поступила информация, когда она была зафиксирована, кто или что ее утвердило и каким трансформациям она подверглась.
Первоисточники и материалы для дальнейшего чтения
OpenAI — Context Engineering: Short-Term Memory Management with SessionsРуководство OpenAI по обрезке и сжатию контекста для долгоживущих агентов.
OpenAI — Sandbox AgentsДокументация, демонстрирующая постоянную память как возможность с прогрессивным раскрытием и поведением чтения/записи.
Anthropic — Effective Context Engineering for AI AgentsИнженерное руководство по формированию ограниченного контекста модели для обеспечения надежного поведения агентов.
Microsoft Research — MemoraИсследование баланса между абстракцией и детализацией в долговременной памяти агентов.
Microsoft Research — PlugMemИсследование преобразования необработанной истории взаимодействий агента в структурированные знания многократного использования.
Microsoft Research — Agentic Context Engineering (ACE)Исследование эволюции контекста в виде структурированных сценариев вместо постоянного переписывания или сжатия всей информации.
Related Articles
Ollama — это не продукт: создание готовых к продакшену приложений на базе открытых LLM
Запустить локальную модель с Ollama просто. Создать готовое к продакшену Open-LLM-приложение сложнее: для этого требуются RAG, контроль доступа, абстракция провайдеров, оценка, логирование, дисциплина развертывания и контролируемый уровень приложения вокруг модели.
Что такое RAG? Самое простое объяснение того, как это работает
RAG звучит сложно, но идея проста: прежде чем ИИ ответит, он сначала находит полезную информацию из источника знаний и передаёт эту информацию языковой модели. В этом руководстве объясняются RAG, LLM, состояние, память и инструменты с помощью одной простой ментальной модели.
GPU — не продукт: перспективная архитектура приватного ИИ
Инфраструктура приватного ИИ не должна проектироваться вокруг одного GPU или одной модели. Более устойчивый подход объединяет быстрые GPU для инференса, ИИ-системы с большим объемом памяти, узлы физического ИИ и опциональные передовые облачные модели за уровнем маршрутизации, учитывающим возможности.
Фронтенд- и бэкенд-разработка
Фронтенд- и бэкенд-разработка является неотъемлемой частью веб-разработки и включает в себя создание веб-приложений и веб-сайтов. Фронтенд-разработка сосредоточена на пользовательском интерфейсе, в то время как бэкенд-разработка отвечает за программирование и управление серверной частью.
Освоение рабочего процесса SEO: Основные стратегии оптимизации для органического роста
Структурированный рабочий процесс SEO крайне важен для устойчивого органического роста. Изучите десять основополагающих стратегий, от исследования ключевых слов и технической оптимизации до качества контента и анализа производительности.
Почему больше контекста может ухудшить ответы ИИ
Большее контекстное окно не гарантирует более качественного ответа. В этой статье объясняется, как размывание сигнала, противоречивые данные, устаревшее состояние, чувствительность к позиции и сжатие с потерями могут снизить надежность ИИ — и предлагается практический стресс-тест контекста.
Граница достоверности ответа: недостающий слой между релевантностью и надёжными ответами ИИ
Источник может быть релевантным, авторитетным и при этом неверным для задаваемого вопроса. Недостающий слой — применимость: условия, при которых ответ остаётся в силе, и изменения, вынуждающие пересмотреть его. В этой статье вводится понятие «Граница действительности ответа» как паттерн проектирования источников для людей, ИИ-поиска и RAG-систем.
RAG не сработал — но какой именно слой на самом деле отказал? Метод диагностики
Когда ответ RAG неверен, обвинять поиск или модель — слишком расплывчато. Этот диагностический метод изолирует покрытие источников, построение запроса, поиск, ранжирование, сборку контекста, генерацию, атрибуцию доказательств и актуальность — так что фактический сбой можно воспроизвести и исправить.
Что ИИ-агент должен помнить, забывать, перевычислять или извлекать повторно?
Долгоживущие агенты не должны помнить всё. В этой статье представлена практическая модель жизненного цикла для определения того, что относится к долговременной памяти, что следует извлекать повторно, что безопаснее пересчитать, а что должно истечь по сроку действия или быть заменено.
MCP vs A2A vs UCP vs AP2 vs A2UI: разбор стека протоколов агентов
MCP, A2A, UCP, AP2 и A2UI часто представляют как конкурирующие агентские стандарты. В основном они решают разные проблемы интероперабельности. Это руководство сопоставляет каждый протокол с границей, которую он фактически стандартизирует,—и показывает, как они могут работать вместе в одной промышленной системе.