RAG и память ИИ-агента часто смешивают, но это разные вещи. RAG помогает агенту найти внешние знания в документах и базах. Память помогает агенту сохранить состояние, предпочтения, прошлые решения и рабочий контекст между шагами или сессиями.
Если сказать совсем коротко: RAG отвечает на вопрос “где взять факты”, а память отвечает на вопрос “что агент должен помнить”. В реальном проекте нужны оба слоя, но хранить все подряд в памяти опасно, а искать все через RAG неудобно.
Коротко: для надежного агента RAG должен давать проверяемые знания из документов, а память должна хранить только то, что действительно нужно для продолжения работы. Документы не надо превращать в память, а временные выводы агента не надо превращать в факты.
Чем RAG отличается от памяти
RAG - это retrieval augmented generation. Агент получает вопрос, ищет релевантные фрагменты в базе знаний, добавляет их в контекст модели и отвечает с опорой на найденные материалы.
Память - это сохраненное состояние агента. Она может помнить, что пользователь работает в отделе продаж, что проект называется ezGPT, что в прошлой сессии агент уже подготовил план, что текущая задача находится на шаге “проверка”, а не “сбор данных”.
Разница принципиальная:
- RAG хранит знания и документы;
- память хранит состояние и устойчивые факты;
- RAG чаще обновляется через ingestion pipeline;
- память чаще обновляется во время работы агента;
- RAG должен ссылаться на источники;
- память должна иметь правила записи и удаления.
Если агенту нужна инструкция из регламента, это RAG. Если агенту нужно помнить, что пользователь предпочитает короткие ответы, это память. Если агент написал черновик отчета, это скорее рабочий артефакт, а не память.
Как работает RAG
Классический RAG pipeline выглядит так:
- собрать документы;
- очистить и нормализовать текст;
- разбить текст на chunks;
- добавить метаданные;
- создать embeddings;
- сохранить embeddings и текст в векторную базу;
- принять вопрос пользователя;
- найти похожие фрагменты через retriever;
- при необходимости применить reranker;
- добавить лучшие фрагменты в контекст;
- попросить модель ответить с учетом найденных данных;
- проверить groundedness и качество ответа.
На демо это выглядит просто. В продакшене сложность обычно не в “подключить vector database”, а в качестве данных, chunking, фильтрах доступа, обновлениях, метаданных и оценке retrieval.
Документы и ingestion
RAG начинается не с модели, а с документов. Если база знаний грязная, устаревшая или противоречивая, агент будет уверенно выдавать плохие ответы.
Перед индексацией важно решить:
- какие источники попадают в базу;
- кто отвечает за актуальность;
- как удаляются устаревшие документы;
- как обрабатываются PDF и таблицы;
- как сохраняются заголовки и структура;
- как помечаются версии;
- какие документы доступны каким пользователям;
- как часто обновляется индекс.
Один и тот же документ может быть полезным или бесполезным в зависимости от обработки. Например, если разрезать инструкцию так, что заголовок остался в одном chunk, а условие применения в другом, retrieval может найти неправильный фрагмент.
Chunking
Chunking - это разбиение документов на фрагменты. От него зависит, что агент реально увидит в контексте.
Слишком маленькие chunks теряют смысл. Слишком большие chunks несут много лишнего текста. Хороший chunk содержит законченную мысль, но не превращается в целую главу.
Практичные правила:
- сохранять заголовки рядом с текстом;
- учитывать структуру документа;
- добавлять overlap между соседними фрагментами;
- не резать таблицы вслепую;
- отдельно обрабатывать FAQ и списки;
- хранить ссылку на исходный документ;
- добавлять дату и версию;
- тестировать retrieval на реальных вопросах.
Для юридических документов и регламентов chunks обычно нужны крупнее и с хорошими метаданными. Для FAQ и коротких инструкций можно делать более компактные фрагменты.
Embeddings и векторная база
Embeddings превращают текст в числовой вектор. По этим векторам можно искать фрагменты, близкие по смыслу, даже если в вопросе используются другие слова.
Векторная база хранит embeddings, текстовые фрагменты и метаданные. Популярные варианты: Qdrant, Weaviate, Pinecone, Chroma, Redis Vector Search, pgvector.
Выбор базы важен, но не стоит начинать с него. Для большинства первых RAG-систем качество зависит больше от документов, chunking, embedding model, metadata filtering и evals, чем от конкретной базы.
Векторная база должна уметь:
- быстро искать похожие фрагменты;
- фильтровать по метаданным;
- разделять данные пользователей;
- обновлять и удалять документы;
- хранить ссылку на источник;
- масштабироваться под объем базы;
- поддерживать резервное копирование;
- давать понятные логи запросов.
Если у вас multi-tenant продукт, фильтры доступа должны быть на уровне retrieval, а не только в промпте.
Retriever
Retriever отвечает за поиск кандидатов. Он получает вопрос и возвращает фрагменты, которые, вероятно, помогут ответить.
Retrieval бывает разным:
- semantic search по embeddings;
- keyword search по словам;
- hybrid search через комбинацию подходов;
- metadata filtering;
- multi-query retrieval;
- parent document retrieval;
- graph retrieval;
- agentic retrieval, где агент уточняет поиск несколькими шагами.
Для многих задач hybrid search надежнее чистого vector search. Если пользователь ищет точный артикул, номер договора или название функции, ключевые слова могут быть важнее семантической близости.
Reranker
Reranker пересортировывает найденные фрагменты. Retriever может быстро выбрать 20-50 кандидатов, а reranker точнее определяет, какие 3-8 фрагментов действительно стоит положить в контекст.
Reranking полезен, когда:
- документов много;
- запросы сложные;
- похожих фрагментов слишком много;
- важна точность;
- база содержит длинные инструкции;
- первый retrieval часто приносит шум.
Минус простой: reranker добавляет стоимость и задержку. Поэтому его стоит включать там, где ошибка retrieval дороже, чем лишние миллисекунды.
Ответ с опорой на знания
RAG должен не просто добавлять фрагменты в prompt, а заставлять модель отвечать на основе найденного.
Полезные правила для ответа:
- если в найденных документах нет ответа, сказать об этом;
- не подменять документ знаниями модели;
- показывать использованные фрагменты или ссылки;
- отделять факт от вывода;
- не делать действие на основе непроверенного retrieval;
- не смешивать документы разных пользователей;
- учитывать дату и версию источника.
Фраза “я не нашел этого в базе знаний” для RAG-агента часто лучше, чем красивый уверенный ответ без опоры.
Что такое память агента
Память агента - это не свалка всех сообщений. Это управляемое хранилище состояния и фактов, которые нужны агенту для будущей работы.
Есть несколько уровней памяти.
- Short-term memory: история текущего диалога или запуска.
- Working memory: активный план, промежуточные результаты и текущий шаг.
- Long-term memory: устойчивые факты о пользователе, проекте или настройках.
- Episodic memory: прошлые задачи, решения и события.
- Semantic memory: знания, которые можно искать по смыслу.
- Artifact memory: документы, отчеты, черновики и файлы, созданные агентом.
Эти слои лучше не смешивать. История чата, база знаний и созданный отчет - разные сущности с разными правилами хранения.
Short-term memory
Short-term memory нужна, чтобы агент понимал текущий диалог или workflow. Она хранит последние сообщения, результаты инструментов, состояние графа и промежуточные решения.
В LangGraph похожую роль играют checkpointers и persistence: состояние можно сохранять по шагам, чтобы продолжать поток и видеть историю выполнения.
Short-term memory полезна для:
- продолжения диалога;
- многошаговых задач;
- восстановления после ошибки;
- отладки;
- передачи контекста между шагами;
- ожидания подтверждения человека.
Главный риск - перегрузить контекст всей историей. Часто лучше хранить полную историю отдельно, а в модель передавать сжатое состояние и последние важные события.
Long-term memory
Long-term memory хранит то, что агент должен помнить между сессиями. Например: язык пользователя, формат отчета, роль в компании, название проекта, стабильные предпочтения, важные правила.
Но долгосрочная память должна быть консервативной. Нельзя сохранять каждую догадку модели как факт.
Хорошие правила записи:
- сохранять только устойчивые факты;
- отличать предпочтение от разового запроса;
- давать пользователю возможность исправить память;
- хранить дату обновления;
- удалять устаревшие факты;
- не сохранять чувствительные данные без необходимости;
- помечать источник памяти.
Например, “пользователь сегодня попросил ответить кратко” не всегда значит “пользователь всегда любит краткие ответы”. Это разные уровни памяти.
Artifact memory
Рабочие артефакты лучше хранить не как “память модели”, а как документы: черновики, отчеты, планы, файлы, таблицы, решения, протоколы.
Почему это важно:
- документ можно версионировать;
- документ можно открыть и проверить;
- документ можно передать человеку;
- документ можно удалить;
- документ можно использовать как источник для RAG;
- документ не теряется в истории чата.
Для сложных агентов artifact memory часто важнее, чем разговорная память. Агент должен не просто помнить, что он что-то сделал, а иметь доступ к результату работы.
Что не надо хранить в памяти
Память легко испортить. Не стоит сохранять:
- временные рассуждения модели;
- непроверенные выводы;
- одноразовые команды;
- устаревшие данные;
- секреты и ключи;
- персональные данные без цели;
- результаты retrieval как постоянные факты;
- ошибки пользователя;
- шум из длинного диалога;
- все сообщения подряд.
Если сомневаетесь, лучше не сохранять. Агент может спросить заново или найти документ через RAG. Плохая память хуже отсутствия памяти, потому что она незаметно отравляет будущие ответы.
Как связать RAG и память
Рабочая схема выглядит так:
- RAG хранит документы и знания;
- memory хранит состояние и устойчивые факты;
- artifacts хранят результаты работы;
- logs хранят события и действия;
- evals проверяют качество retrieval и ответов;
- access control решает, кто что может видеть.
Пример: агент поддержки отвечает клиенту. RAG ищет инструкцию по тарифу. Память хранит, что клиент уже подтвердил email. Artifact хранит черновик ответа. Audit log хранит вызов CRM и просмотр документа. Это разные слои, хотя пользователь видит один диалог.
RAG для ИИ-агента отличается от RAG для чатбота
Чатботу часто достаточно найти фрагменты и ответить. Агенту нужно больше: он может решить, какой retrieval выполнить, уточнить вопрос, вызвать инструмент, проверить документ, сделать действие и сохранить состояние.
Для агента важны:
- несколько поисковых запросов;
- поиск по разным источникам;
- проверка конфликтующих документов;
- metadata filtering по правам доступа;
- decision log;
- повторный retrieval после действия;
- запрет действия при слабом контексте;
- передача человеку при низкой уверенности.
Агентный RAG должен быть осторожнее, чем обычный поиск по базе знаний, потому что результат retrieval может привести к действию.
Метаданные и права доступа
Метаданные - это то, что превращает RAG из игрушки в систему.
Полезные метаданные:
- источник;
- автор;
- дата;
- версия;
- отдел;
- язык;
- продукт;
- клиент;
- уровень доступа;
- тип документа;
- срок актуальности;
- ссылка на оригинал.
Если у вас есть разные пользователи, клиенты или отделы, metadata filtering обязателен. Нельзя надеяться, что модель “не покажет лишнее”. Лишнее не должно попасть в retrieval.
Оценка качества RAG
RAG нужно тестировать отдельно от модели. Иначе непонятно, кто виноват: retrieval не нашел документ или модель плохо ответила.
Минимальные метрики:
- нашел ли retriever правильный документ;
- попал ли правильный chunk в top-k;
- хватает ли фрагментов для ответа;
- есть ли лишний шум;
- ответ опирается на найденное или фантазирует;
- указывает ли агент, что данных нет;
- сколько стоит один ответ;
- сколько времени занимает retrieval.
Соберите набор реальных вопросов и правильных источников. Это будет ваш regression test для RAG. После изменения chunking, embeddings или векторной базы прогоняйте тест снова.
Типичные ошибки
Самые частые ошибки RAG и памяти:
- загрузили документы без очистки;
- выбрали chunk size случайно;
- не сохранили структуру документа;
- не добавили metadata filtering;
- использовали только vector search для точных идентификаторов;
- не проверили top-k на реальных вопросах;
- хранят всю историю как память;
- сохраняют галлюцинации в long-term memory;
- не удаляют устаревшие факты;
- не разделяют память пользователей;
- не логируют retrieval;
- не тестируют groundedness.
Если агент отвечает плохо, не спешите менять модель. Сначала посмотрите, что именно он получил в контекст.
Минимальная архитектура
Для первого нормального RAG + memory агента достаточно такой схемы:
- база документов;
- ingestion pipeline;
- chunking с метаданными;
- embeddings;
- векторная база;
- hybrid retriever;
- короткая память диалога;
- отдельное хранилище устойчивых фактов;
- artifact storage для результатов;
- guardrails для доступа;
- логи retrieval и tools;
- evals на реальных вопросах.
Это не выглядит так эффектно, как “агент сам все помнит”, зато работает стабильнее.
Что выбрать из инструментов
Для RAG-слоя можно смотреть:
- LlamaIndex для data-heavy RAG и агентов над документами;
- LangGraph и LangChain для stateful agent workflow;
- Qdrant для self-hosted vector search;
- Weaviate для vector database с RAG-возможностями;
- Pinecone для managed vector database;
- Chroma для локальных и прототипных сценариев;
- Redis Vector Search если Redis уже есть в инфраструктуре;
- pgvector если хочется держать retrieval рядом с PostgreSQL.
Для первого проекта важнее не идеальная база, а правильный pipeline и тесты. Можно начать проще, но сразу заложить метаданные, версионирование документов и evals.
Итог
RAG и память - две разные опоры ИИ-агента. RAG дает агенту доступ к проверяемым знаниям. Память помогает продолжать работу и учитывать устойчивый контекст. Если смешать их в одну корзину, агент начнет помнить временные ошибки и искать то, что должен был сохранить как состояние.
Надежная схема проста: документы идут в RAG, состояние идет в memory, результаты работы идут в artifacts, действия идут в audit log, качество проверяется evals, доступ ограничивается guardrails.
Такой агент может отвечать не только красиво, но и проверяемо: откуда взял факт, почему выбрал действие, что запомнил и что не стал сохранять.
Частые вопросы
Коротко: о чем эта статья?
Разбираем RAG и память ИИ-агента: документы embeddings векторная база retriever reranker краткосрочная память долгосрочная память и проверки качества.
Кому полезен этот материал?
Материал полезен тем, кто разбирается в теме "Архитектура AI-агентов" и хочет перейти от терминов к практическим решениям.
С чего начать на практике?
Начните с одной конкретной задачи, опишите ожидаемый результат, проверьте ограничения и только после теста расширяйте решение.
Нужно ли сразу внедрять это в работу?
Нет. Сначала проверьте идею на небольшом примере, оцените качество ответа, риски и пользу для процесса.
