Корпоративный AI Agent: RAG или Memory в 2026?

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

Эта статья предназначена для вас, если вы подключаете корпоративную базу знаний к AI Agent, проектируете помощника для клиентов или хотите сохранять контекст между сессиями. Она также полезна руководителям платформ, которых беспокоят загрязнение памяти, нарушение прав доступа и невозможность объяснить, откуда взялось решение.

Сначала разделите знания, опыт и состояние

Главная ошибка в проектировании корпоративного AI Agent — считать любую полезную информацию «памятью» и складывать её в одно хранилище. На практике у данных разные владельцы, срок жизни, требования к проверке и последствия ошибки.

RAG — это не просто поиск по векторной базе. В рабочей архитектуре он включает подготовку документов, разбиение на фрагменты, индексацию, фильтрацию по правам, поиск, выбор источников, передачу контекста модели и фиксацию происхождения ответа. Исходная работа по Retrieval-Augmented Generation описывает сочетание параметрической памяти модели с внешней непараметрической памятью, что позволяет обновлять знания без полного переобучения модели и связывать ответ с извлечёнными материалами. Описание оригинального исследования RAG (arxiv.org)

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

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

Без этого разделения возникают как минимум четыре ограничения:

• Знания быстро устаревают. Если новая редакция политики попадает в Memory как случайное обобщение диалога, вы теряете связь с официальным документом и не знаете, какую версию считать действующей.
• Права доступа становятся неочевидными. Один пользовательский факт может оказаться доступным другому сотруднику, если память индексируется отдельно от корпоративной идентичности и групповых разрешений.
• Ошибки начинают самовоспроизводиться. Неверный ответ, записанный как «предпочтение» или «опыт», будет влиять на следующие сессии даже после исправления исходной причины.
• Аудит усложняется. Для ответа из RAG можно показать документ и фрагмент, а для Memory нужно дополнительно объяснить, кто записал факт, на каком основании он был обобщён и почему система решила его использовать.

Именно поэтому вопрос «RAG или Agent Memory — в чём разница?» следует заменять более точным: какая ответственность возложена на каждый тип данных и что произойдёт при его ошибке?

Первый сценарий: корпоративный помощник начинается с RAG

Если вы строите помощника по внутренним политикам, продуктовой документации, инструкциям или договорам, начните с RAG и не добавляйте долгосрочную Memory без отдельного обоснования.

Для такого помощника важны:

• источник и ссылка на оригинальный документ;
• версия или дата вступления в силу;
• владелец материала;
• область действия;
• уровень конфиденциальности;
• правила удаления устаревших фрагментов;
• фильтр доступа для пользователя и его групп.

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

Современные поисковые платформы поддерживают несколько способов документного контроля доступа: фильтры безопасности, ACL- и RBAC-метаданные, а также политики конфиденциальности, применяемые во время запроса. Это показывает важный принцип: разрешение нужно проверять не только при индексации, но и в момент выдачи результата. Документация о контроле доступа на уровне документа (learn.microsoft.com)

Нужно ли сохранять вопросы пользователя в Agent Memory? Только если сохранённая информация меняет будущий рабочий контекст и пользователь понимает, что именно будет записано. Сам вопрос «какая политика действует?» не является памятью. Если же пользователь постоянно просит объяснять инструкции с учётом конкретного подразделения, это может стать отдельным предпочтением — при условии, что оно не подменяет официальный документ.

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

1. Определите список источников, которым разрешено считаться нормативными.
2. Назначьте владельца и жизненный цикл каждого типа документа.
3. Добавьте в индекс версию, дату действия, владельца и права доступа.
4. Настройте поиск с обязательной фильтрацией по идентичности пользователя.
5. Возвращайте в ответе ссылки или идентификаторы использованных источников.
6. Проверьте поведение на отозванном документе и на документе, доступном только одной группе.

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

Второй сценарий: клиентский сервису нужна ограниченная Memory

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

Разделите записи минимум на три категории:

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

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

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

Куда помещать пользовательские предпочтения — в векторную базу или в систему памяти? Если предпочтение влияет на формат будущего взаимодействия, храните его в управляемом слое Memory или в обычной профильной записи, а не только в векторном индексе. Векторный поиск полезен для нахождения похожих эпизодов, но плохо подходит как единственный механизм для точного значения «пользователь предпочитает получать счета в таком формате».

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

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

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

Третий сценарий: для автоматизации процессов нужен слой состояния

Процессный AI Agent работает не только с текстом. Он вызывает инструменты, создаёт заявки, ждёт подтверждения, повторяет операции после временного сбоя и передаёт задачу человеку. В этом сценарии главная проблема — не отсутствие «памяти», а потеря состояния.

Пример: агент оформляет возврат товара. В системе должны отдельно существовать:

• идентификатор обращения;
• текущий этап процесса;
• результат проверки условий;
• выполненные действия;
• причина последней ошибки;
• ожидающее подтверждение;
• ссылка на запись во внешней системе;
• версия правил, по которой принято решение.

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

Транзакционные базы данных специально предназначены для согласованных изменений и контроля конкурентного доступа. В документации PostgreSQL описаны четыре стандартных уровня изоляции транзакций, а режим Serializable должен обеспечивать эффект, эквивалентный последовательному выполнению транзакций. Документация об уровнях изоляции транзакций (postgresql.org)

Практическая схема для процессного агента выглядит так:

1. Бизнес-система хранит официальное состояние заявки или заказа.
2. Оркестратор хранит шаги выполнения, повторы и тайм-ауты.
3. Memory сохраняет обобщённый опыт, если он действительно полезен в следующих задачах.
4. RAG предоставляет инструкции и нормативные правила.
5. Журнал аудита фиксирует вызовы инструментов, решения и ошибки.

Так вы не заставляете Memory отвечать за то, для чего нужна транзакционная гарантия, и не превращаете RAG в журнал исполнения.

Четвёртый сценарий: объединяйте слои через права и происхождение

На платформе для нескольких команд RAG, Memory и бизнес-данные должны соединяться не прямыми вызовами «откуда угодно куда угодно», а через единый слой идентичности, политик и наблюдаемости.

Минимальная цепочка запроса должна отвечать на пять вопросов:

1. Кто инициировал запрос?
2. Какие источники были доступны этому пользователю?
3. Какие фрагменты RAG были извлечены?
4. Какие записи Memory были добавлены в контекст?
5. На основании каких данных агент вызвал инструмент или сформировал ответ?

Источники следует маркировать раздельно. Например, knowledge_source описывает документ RAG, memory_id — использованную запись Memory, workflow_state_id — состояние процесса, а decision_id — итоговое решение. Не смешивайте эти поля в одном массиве «контекст», иначе при разборе ошибки будет трудно понять, что именно повлияло на ответ.

Для журналов удобно использовать общие поля времени, идентификатора трассировки, операции, субъекта и результата. Модель журналов OpenTelemetry предусматривает временные метки, TraceId, SpanId, уровень важности, тело записи и дополнительные атрибуты, что подходит для связывания поиска, вызова Memory и действия инструмента в одну трассу. Официальная модель журналов и атрибутов (opentelemetry.io)

Обязательно ли корпоративному AI Agent одновременно использовать RAG и Memory? Нет. Если агент отвечает только по небольшой, редко меняющейся коллекции документов и не ведёт длительные взаимодействия, начните с RAG. Если агент управляет персональным рабочим контекстом без нормативной базы, может хватить Memory и структурированного профиля. Комбинация оправдана тогда, когда у системы одновременно есть проверяемые знания и повторяющийся пользовательский или процессный контекст.

Пятый сценарий: регулируемые команды сначала проектируют аудит

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

• кто имеет право создавать запись;
• кто может её читать;
• сколько времени она хранится;
• как подтверждается исправление или удаление.

Дополнительно нужно фиксировать факт использования: какая запись была подставлена в контекст, каким агентом, в какой сессии и повлияла ли она на действие. Запись «Memory использована» недостаточна без идентификатора конкретного объекта и политики доступа.

NIST AI RMF разделяет работу с рисками на четыре функции: Govern, Map, Measure и Manage. В рекомендациях отдельно подчёркиваются тестирование до запуска, регулярный контроль в эксплуатации, документирование метрик, обработка ошибок и ведение историй или журналов аудита. Материалы NIST по управлению рисками AI (airc.nist.gov)

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

Проверьте архитектуру перед производственным запуском

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

• Если данные являются официальными фактами, должны иметь владельца, версию и ссылку на источник — выбирайте RAG.
• Если данные описывают предпочтение пользователя и меняют будущий формат взаимодействия — выбирайте Memory или профильную запись с контролем пользователя.
• Если данные описывают текущий шаг, статус, блокировку или результат операции — возвращайте их в систему состояния или бизнес-базу.
• Если данные являются опытом выполнения, который можно безопасно обобщить — добавляйте Memory только после проверки и нормализации.
• Если данные временные и нужны лишь внутри одной задачи — не сохраняйте их надолго.
• Если есть строгие требования к аудиту, удалению или разделению арендаторов, но механизмов контроля ещё нет — временно откажитесь от постоянной Memory.
• Если агент одновременно работает с нормативными знаниями и персональным контекстом — используйте комбинацию RAG + Memory, но с разными хранилищами и журналами.

Перед выпуском добавьте в приёмочные тесты не только обычные вопросы, но и негативные сценарии:

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

Итоговая карта распределения данных

Для большинства корпоративных команд правильный первый релиз выглядит так: RAG для проверяемых знаний, отдельный слой состояния для процессов, ограниченная Memory для нескольких явно определённых пользовательских фактов. Не начинайте с автоматического запоминания всей истории — сначала измерьте, какие записи действительно уменьшают повторную работу и не создают новых рисков.

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

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