RAG-агент: что такое Retrieval-Augmented Generation и как работает RAG в ИИ

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

Retrieval-Augmented Generation, или RAG, дополняет ответ модели сведениями из внешнего источника. Сначала приложение ищет подходящие документы и передает их фрагменты вместе с вопросом. Затем модель формулирует ответ, опираясь на этот контекст, а не только на информацию, полученную при обучении.

Название описывает два этапа: retrieval извлекает подходящие сведения, generation формирует связный ответ. В исходной работе RAG этот подход представлен как сочетание параметрической памяти модели и внешней непараметрической памяти (Lewis и соавторы, NeurIPS 2020). Современная прикладная система может быть устроена иначе, но идея та же: подключить при генерации информацию, которой нет или не должно быть в параметрах модели.

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

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

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

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

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

Подход может помочь:

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

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

Выбор зависит от задачи. Для ответа по документам с возможностью сослаться на источник подходит RAG. Если нужно найти точную фразу, может хватить полнотекстового поиска. Для изменения данных или расчета нужны API и проверяемое бизнес-правило. Теперь проследим, как вопрос проходит через RAG-систему.

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

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

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

Эмбеддинг преобразует текст в числовой вектор. Система сравнивает вектор вопроса с векторами фрагментов и отбирает смыслово близкие варианты. Поэтому запрос «как вернуть оплату» может найти инструкцию с формулировкой «порядок оформления возврата».

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

Перед поиском система может исправить опечатку, переформулировать вопрос или разделить его на несколько запросов. Ретривер отбирает подходящие фрагменты, а реранкер уточняет их порядок. Затем приложение удаляет дубликаты, проверяет даты и права доступа и ограничивает объем контекста. Гибридный поиск, query rewriting и reranking описаны в руководстве Microsoft Azure по этапу information retrieval.

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

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

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

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

Источниками могут служить документы, wiki, CRM, тикеты, сайты, базы данных и API. Для каждого стоит определить владельца, частоту обновления, актуальную версию и правила доступа. База знаний требует управления материалами: их публикуют, обновляют, архивируют и удаляют.

Векторное хранилище может связывать эмбеддинги с исходным текстом и метаданными; конкретная схема зависит от приложения. Такое хранилище помогает искать по смыслу, но векторная база нужна не каждому RAG-проекту. Небольшой набор документов можно искать полнотекстово, через SQL или API. Векторный поиск чаще раскрывает свои преимущества в сочетании с фильтрами, гибридным режимом и контролем доступа.

Ретривер делает первичный отбор, реранкер переставляет кандидатов по релевантности, а LLM интерпретирует контекст и формирует текст. Оркестратор связывает вызовы. Слой наблюдаемости записывает запрос, источники, задержку, ошибки и стоимость. Проверку прав доступа нужно проводить до передачи найденных данных модели, а не после генерации; этот принцип изложен в рекомендациях Microsoft по безопасному multitenant RAG. Если не записывать ход работы системы, разобраться, где именно возник сбой, будет непросто. Когда одного поиска мало, можно добавить агентный цикл.

В обычной RAG-системе вопрос проходит по заранее заданной цепочке: поиск, затем генерация ответа. Если первых результатов не хватает, система с фиксированным маршрутом не обязательно сможет выбрать следующий шаг. Агентная архитектура позволяет организовать такой выбор: разбить вопрос, обратиться к другому источнику, повторить поиск или оценить промежуточный результат. В архитектурных рекомендациях Microsoft по Agentic RAG retrieval описан как инструмент, который агент вызывает по необходимости.

Агентный слой полезен не для каждого запроса. Если вопрос простой, дополнительное планирование лишь увеличит время ответа и стоимость. Он уместнее там, где системе действительно нужно выполнить несколько шагов.

Чтобы ответить на вопрос о трех регионах, например, может потребоваться найти отдельные документы, сопоставить их даты и проверить исключения. Агент выбирает последовательность действий, а RAG на каждом шаге поставляет контекст. Результату поиска нужны не только фрагменты текста, но и идентификатор документа, дата, статус и данные о правах доступа.

Для работы агенту задают инструменты и схемы входных данных, ограничивают число итераций и время выполнения, определяют условия передачи задачи человеку. Если агенту доступна CRM или ERP, разрешения на запись и подтверждения стоит выбирать с учетом риска и принятой архитектуры контроля (Microsoft о безопасной архитектуре RAG). Больше автономности означает и больше вариантов сбоя: агент может зациклиться, выбрать неподходящий инструмент или раскрыть лишний контекст.

Если поиск пропускает важные фрагменты, сначала нужно понять, какой именно слой не справляется. Термины ниже обозначают разные подходы, а не единую обязательную классификацию. Naive и Advanced условно описывают базовую и расширенную конфигурации; Graph RAG — способ представить связи между данными; hybrid search — сочетание поисковых механизмов.

Базовый маршрут прост: документы разбивают на чанки, строят эмбеддинги, находят близкие фрагменты и передают их LLM. Здесь назовем такую конфигурацию Naive RAG; это рабочее обозначение простой цепочки, а не название стандарта. Ее ограничений может не хватить, если важны версии документов, точные термины, права доступа или последовательный поиск в нескольких источниках.

Когда базовая цепочка не справляется, к ней можно добавить обработку запроса или результатов. Для такого варианта используют рабочее обозначение Advanced RAG. Дополнительные этапы могут включать query rewriting, гибридный поиск, реранкинг или фильтрацию. Единого обязательного набора нет, а каждый компонент стоит оценивать отдельно: усложнение иногда увеличивает задержку и добавляет нерелевантные результаты.

Если ответ зависит от связей между объектами, одной выдачи документов может быть недостаточно. Тогда рассматривают Graph RAG: он строит графовый индекс сущностей и отношений, а при поиске использует связанный контекст и другие графовые данные. Подход описан в исследовании From Local to Global: A Graph RAG Approach to Query-Focused Summarization, а также в документации Microsoft GraphRAG: Local Search и GraphRAG Indexing Overview. Конкретная схема поиска зависит от реализации.

Гибридный поиск сочетает семантический поиск с полнотекстовым, фильтрами и структурированными запросами. Он пригодится, если одни вопросы требуют смыслового сопоставления, а другие — точного поиска по кодам и названиям. Этот подход рассмотрен в руководстве Microsoft по information retrieval.

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

Когда retrieval уже работает, стоит решить, что именно требуется изменить: доступ модели к данным или ее поведение. Обычная LLM отвечает на основе параметров, сформированных при обучении. RAG ищет внешние сведения и добавляет их к запросу. Supervised fine-tuning на примерах помогает адаптировать поведение модели или формат ее ответов. Таким образом, RAG предоставляет контекст во время запроса, а дообучение настраивает ответы для конкретного сценария. Возможности supervised fine-tuning описаны, например, в документации OpenAI; retrieval-контекст — в обзоре Google Cloud RAG Engine.

Если меняются факты, начните с внешнего источника и retrieval. Если нужно стабилизировать стиль или формат ответа, оцените supervised fine-tuning. Когда нужны обе функции, их можно сочетать и тестировать отдельно. Технологию не нужно выбирать «на вырост»: она должна отвечать задаче. Теперь посмотрим, как эти варианты могут встроиться в рабочий процесс.

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

В операционной аналитике агент может выбирать между поиском документа, SQL-запросом и обращением к API. Если маршрут запроса каждый раз одинаковый, может хватить фиксированного RAG. Агент нужен, когда система должна сама выбирать инструменты и выполнять несколько шагов. В финансовых и юридических процессах поиск документов или подготовка черновика могут быть вспомогательными функциями; необходимость участия сотрудника зависит от риска и правил процесса. Определив задачу и допустимую ошибку, можно планировать пилот.

Пилот проверяет маршрут запроса до того, как по нему пойдут рабочие обращения. Сначала решите, нужен ли агент или достаточно фиксированной цепочки. Начните с одного сценария: зафиксируйте вопрос пользователя, источники, ожидаемый результат, допустимую ошибку и момент передачи задачи человеку. Эти условия покажут, нужен ли агент. Затем можно выбирать компоненты и настраивать проверку.

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

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

Меняйте параметры по одному и сравнивайте полноту выдачи, точность первых результатов и количество лишнего контекста. Права доступа проверяйте до того, как данные попадут в модель. Этот принцип особо отмечен в рекомендациях Microsoft по безопасному multitenant RAG.

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

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

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

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

Один хороший ответ на тестовый вопрос еще не показывает, где система ошибется в следующий раз. При оценке разделите retrieval и генерацию. Для поиска проверьте, нашелся ли нужный источник и насколько высоко он расположен (метрики retrieval в руководстве Microsoft). Для ответа оцените, опирается ли он на контекст, насколько он полон и уместен и корректны ли утверждения (руководство Microsoft по оценке RAG). Долю отказов при недостатке данных можно отслеживать как отдельную метрику проекта.

Соберите эталонный набор вопросов, добавьте примеры без ответа и пометьте типы ошибок. Во время эксплуатации отслеживайте оценки пользователей, эскалации, задержку, стоимость, пустую выдачу и ошибки доступа. Затем меняйте по одному компоненту и повторяйте тест. Если полнота низкая, проверьте индексацию, стратегию поиска и сами источники. Если ответ слабо обоснован, изучите найденный контекст, retrieval и генерацию; при ошибке доступа — настройки security trimming. Это направления диагностики, а не готовый диагноз. Так можно измерять изменения и понимать, какой вопрос задать следующим. Осталось разобрать частые вопросы перед пилотом.

Можно ли использовать RAG без векторной базы данных?

Да. Для небольшой коллекции подойдут полнотекстовый индекс, SQL, графовая база или API. Векторный поиск пригодится, когда важна смысловая близость. На практике его нередко сочетают с поиском по ключевым словам.

Можно ли запустить RAG-агента локально?

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

Чем RAG отличается от обычного поиска по документам?

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

Когда лучше использовать RAG, а когда обучение модели?

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

Подведем итог. Система RAG позволяет существенно ограничить ошибки и галлюцинации нейросети при работе над реальными задачами. Технология критична для использования ИИ в документообороте, в системах автоматизации бизнеса с помощью ИИ, а также для работы в чувствительных областях. Компания «Анарта» предлагает услуги автоматизации документооборота с помощью ИИ, если вашей организации требуется внедрение ИИ — обращайтесь.