Бизнес-словарь
RAG
RAG — это архитектурный подход, при котором большая языковая модель перед ответом находит сведения во внешних источниках и использует их как контекст.
Аббревиатура RAG расшифровывается как Retrieval-Augmented Generation — от англ.:
В русском языке закрепились формулировки «генерация с дополненным поиском» и «генерация с дополнительной выборкой».
Главное преимущество подхода в том, что знания не требуется каждый раз встраивать в саму модель. Компания обновляет регламент, инструкцию или карточку продукта — и после переиндексации система может учитывать новую версию документа. При этом пользователь получает не перечень ссылок, как в традиционном поиске, а сформулированный ответ, который можно сопроводить указанием первоисточников.
Проще всего представить RAG как корпоративного аналитика с доступом к внутренней библиотеке. Обычная модель отвечает по памяти, сформированной во время обучения. Модель с RAG сначала находит нужные документы, отбирает фрагменты, а затем готовит вывод. Такой механизм снижает риск вымышленных фактов, но не устраняет его полностью: ошибиться могут источник, поисковый модуль и сама языковая модель.
Спрос на такие решения быстро растёт. По оценке аналитической компании MarketsandMarkets, объём мирового рынка RAG в 2025 году составляет 1,94 млрд долларов, а к 2030 году может достичь 9,86 млрд долларов. Это соответствует среднегодовому темпу роста 38,4% в 2025–2030 годах. И хотя прогнозы исследовательских агентств могут различаться из-за методики и границ рынка, однако общий вектор совпадает: компании всё активнее инвестируют в технологии, которые позволяют генеративному ИИ работать с актуальными корпоративными данными.
Объем мирового рынка RAG, млрд долларов (2025-2030 гг.)
Содержание:
Что такое RAG и какую проблему больших языковых моделей он решает
Большая языковая модель, или LLM (от англ. large language model, большая языковая модель), анализирует контекст, обобщает информацию и формирует связные ответы на запросы пользователя. Но она не является регулярно обновляемым справочником компании. Модель может не знать о вчерашнем изменении тарифов, новой редакции договора или внутреннем распоряжении, доступном только сотрудникам. Именно здесь возникает потребность в RAG.
Что же такое RAG для LLM? Это не новая разновидность языковой модели и не отдельная нейросеть, а способ организовать её работу с внешними знаниями. RAG-подход добавляет между вопросом пользователя и генерацией ответа поисковый этап.
Например, сотрудник банка спрашивает корпоративного помощника, какие документы нужны юридическому лицу для изменения данных о бенефициаре. Без доступа к внутренним правилам модель может предложить общий или устаревший порядок. С RAG система сначала найдёт актуальную инструкцию, проверит дату и категорию клиента, а затем сформирует ответ со ссылкой на документ.
RAG подключает языковую модель к знаниям, которые не были заложены в неё во время обучения.
Поэтому формулировка RAG в ИИ — это «поиск перед генерацией» верна по смыслу, хотя несколько упрощает механизм. В промышленном решении требуется не только найти текст, но и определить права доступа, выбрать релевантную редакцию, убрать дубли, оценить качество источника и правильно передать материалы модели.
Как работает RAG-система
У RAG есть два рабочих контура:
Каждый из контуров включает в себя дополнительные этапы.
Этапы работы RAG-системы
Этап 1. Индексация: как документы превращаются в базу знаний
На этапе индексации документы преобразуются в набор фрагментов, пригодных для быстрого поиска.
Источниками могут быть файловые хранилища, корпоративные порталы, базы знаний, CRM (от англ. customer relationship management, управление взаимоотношениями с клиентами) и другие внутренние системы. Материалы очищают от дублей и служебной разметки, а затем добавляют метаданные: тип документа, подразделение, дату действия, версию и уровень доступа.
После этого текст проходит чанкинг (от англ. chunking, разбиение на фрагменты) — разбивку всего массива данных на чанки, небольшие смысловые части документа. Например, регламент на 200 страниц не передают модели целиком: система делит его на фрагменты и затем ищет только те, которые относятся к вопросу.
Размер чанка влияет на качество ответа. Слишком короткий фрагмент может потерять важное условие, слишком длинный — добавить лишний контекст. Поэтому параметры разбиения подбирают под тип документов и пользовательские сценарии.
Далее эмбеддинг-модель (от англ. embedding, векторное представление) преобразует каждый чанк в числовой вектор. Эмбеддинг кодирует смысл текста: близкие по содержанию фрагменты получают близкие координаты в многомерном пространстве. Векторы, исходный текст и метаданные сохраняются в поисковом индексе или векторной базе данных.
Этап 2. Поиск: как система находит нужные чанки
Запрос сотрудника также преобразуется в вектор. Затем ретривер (от англ. retriever, модуль извлечения) сравнивает его с векторами документов и выбирает наиболее близкие по смыслу чанки.
Обычно система возвращает несколько лучших кандидатов — выборку top-k, где k означает заданное число результатов. Если взять слишком мало фрагментов, можно пропустить важное исключение. Если слишком много — в контекст попадут лишние или противоречивые сведения.
Одного векторного поиска в корпоративной среде часто недостаточно. Он хорошо понимает смысл, но может хуже работать с номерами договоров, кодами ошибок, артикулами и сокращениями. Поэтому часто применяют гибридный поиск: он сочетает семантическое сопоставление с точным поиском по словам и реквизитам.
Например, инженер спрашивает: «Каков порядок допуска подрядчика к ремонту линии № 3?» Векторный поиск найдёт документы о допуске внешних исполнителей, даже если в них используется другая формулировка. Лексический поиск дополнительно учтёт номер линии и площадки.
Одновременно система проверяет метаданные и права доступа. Она должна исключить устаревшие редакции, документы другой организации и материалы, недоступные конкретному сотруднику.
Этап 3. Переранжирование: как уточняется выдача
Первичный поиск быстро формирует набор “кандидатов”. Затем модуль переранжирования, или reranker (от англ. reranking, повторное ранжирование), более точно сопоставляет запрос с каждым чанком и меняет их порядок.
Переранжирование ставит выше те фрагменты, которые лучше всего отвечают на конкретный вопрос.
Возвращаюсь к примеру с запросом инженера, общее описание допуска подрядчиков может уступить место фрагменту с правилами именно для ремонта производственной линии. Переранжирование повышает точность, но требует дополнительных вычислений, поэтому его настраивают с учётом стоимости и допустимого времени ответа.
Этап 4. Формирование контекста и запроса (промпта)
Лучшие чанки объединяются с вопросом пользователя и системной инструкцией в итоговый промпт (от англ. prompt, инструкция или запрос для модели). В нём можно задать правила: отвечать только по найденному контексту, отмечать противоречия, не придумывать отсутствующие сведения и приводить ссылки на источники.
Объём данных ограничен контекстным окном — количеством информации, которое модель способна обработать за один запрос. Задача RAG в том, чтобы выбрать минимальный набор достаточных фактов.
В языковую модель передаётся не вся база знаний, а компактный набор наиболее полезных фрагментов.
В примере с подрядчиком контекст может включать требования охраны труда, порядок проверки полномочий и перечень документов для конкретной площадки. Модель собирает из этих частей связный ответ, но не должна добавлять условия, которых нет в источниках.
Этап 5. Генерация, ссылки и контроль
Большая языковая модель обобщает переданный контекст и формирует текст в удобном для сотрудника виде. При корректной настройке она указывает названия документов, версии и ссылки на использованные фрагменты.
Всем процессом управляет оркестратор — компонент, который последовательно запускает проверку доступа, поиск, переранжирование, модель и контроль качества. Он также может вести журнал операций, повторять поиск при слабом контексте и передавать запрос специалисту, если надёжного ответа нет.
LLM формулирует ответ, а качество RAG зависит от того, насколько этот ответ подтверждается документами.
Главный риск возникает не только на этапе генерации. Если ретривер выбрал инструкцию для другой площадки или устаревшую редакцию, даже сильная модель сформирует убедительный, но неверный ответ. Поэтому поиск и генерацию оценивают отдельно: сначала проверяют, попали ли правильные чанки в top-k, затем — соответствует ли ответ найденным источникам.
Таблица 1. Что происходит внутри RAG-системы
Параметры чанкинга, эмбеддинг-модель, стратегию поиска, значение top-k и переранжирование настраивают на реальных вопросах пользователей. Для технических инструкций, договоров и продуктовых карточек оптимальные параметры будут разными. Поэтому качество RAG определяется не только общей схемой «извлечение — генерация», но и точностью каждого шага внутри поискового контура.
Из каких компонентов состоит архитектура RAG
В демонстрационном решении достаточно загрузить несколько файлов и подключить LLM. В крупной компании этого мало: документы находятся в разных системах, имеют владельцев, версии, сроки действия и уровни конфиденциальности. Поэтому промышленная RAG-система строится как набор взаимосвязанных компонентов.
Типовая RAG-архитектура включает:
Виды RAG
RAG-системы корректнее классифицировать не одним списком, а по нескольким признакам: способу поиска, представлению знаний, логике работы и модели развёртывания.
Одна и та же система может одновременно быть гибридной по способу поиска, графовой по представлению знаний, агентной по логике работы и локальной по способу размещения. Поэтому сравнивать, например, векторный RAG и локальный RAG как равнозначные виды некорректно: первый описывает механизм поиска, второй — инфраструктуру.
По способу поиска
Способ поиска определяет, как система выбирает фрагменты для передачи языковой модели:
По способу представления знаний
Здесь различие определяется тем, в каком виде система хранит и связывает корпоративную информацию.
Например, при анализе нового нормативного требования обычный RAG найдёт релевантные документы. Графовый подход дополнительно покажет, какие договоры, подразделения, процессы и информационные системы связаны с этим требованием.
По логике обработки запроса
Архитектуры различаются по тому, сколько шагов система выполняет перед подготовкой ответа.
По модели развёртывания
Этот признак описывает не способ поиска, а место обработки данных и уровень инфраструктурного контроля.
Локальное размещение само по себе не делает систему безопасной. В любом варианте нужны разграничение доступа, защита индекса, журналирование и управление версиями документов.
Одна и та же система может одновременно быть гибридной по способу поиска, графовой по представлению знаний, агентной по логике работы и локальной по способу размещения. Поэтому сравнивать, например, векторный RAG и локальный RAG как равнозначные виды некорректно: первый описывает механизм поиска, второй — инфраструктуру.
Зачем RAG бизнесу
Главная ценность RAG для бизнеса состоит в том, что технология меняет способ доступа к внутренней информации: сотруднику не нужно угадывать название документа, открывать несколько систем и вручную сопоставлять редакции.
Для крупной компании особенно важны четыре эффекта.
Связка RAG и генеративного ИИ особенно полезна там, где недостаточно показать документ. Пользователю нужен итог: сравнить условия, собрать краткое резюме, объяснить порядок действий или сформировать черновик на основе найденных фактов.
Где бизнес применяет RAG
Наибольший эффект RAG даёт в процессах с большим объёмом текстов, повторяющимися вопросами и дорогим ручным поиском.
В клиентском сервисе применение RAG помогает оператору быстро находить условия продуктов и внутренние сценарии. Система может подготовить проект ответа, но решение о его автоматической отправке зависит от риска: справочную информацию допустимо выдавать без участия человека, а спорные финансовые вопросы лучше передавать специалисту.
Во внутрикорпоративных сервисах RAG становится единым входом к регламентам. Например, руководитель проекта спрашивает: «Какие согласования нужны для договора с новым поставщиком программного обеспечения?» Помощник находит положение о закупках, требования информационной безопасности и актуальную матрицу полномочий.
В промышленности систему можно подключить к технической документации, ремонтным журналам и инструкциям. Инженер описывает симптом оборудования обычными словами, а помощник находит релевантные разделы руководства и похожие случаи. Это не заменяет диагностику, но сокращает время первичного поиска.
В юридической функции RAG помогает сопоставлять внутренние документы с нормативными требованиями, находить условия в договорах и готовить справки. При этом модель не должна самостоятельно делать юридически значимые выводы без проверки специалистом.
В продажах система формирует ответы по продуктовому каталогу, ограничениям, совместимости и типовым возражениям. Здесь особенно важно подключать только утверждённые материалы: устаревшая презентация может привести к обещанию несуществующей функции.
Если требуется понять, как использовать RAG в конкретном подразделении, полезно начать с наблюдения за работой сотрудников. Подходящий процесс обычно имеет три признака:
Таблица 2. Корпоративные сценарии RAG
Больше примеров применения RAG в компаниях — в статье «Библиотекарь для нейросети: как генерация с дополненным поиском повышает точность ИИ»
Чем RAG отличается от других решений
Технология RAG не является универсальным ответом на все задачи корпоративного ИИ.
Дообучение, или fine-tuning (от англ. fine-tuning, тонкая настройка), полезно, когда модель должна стабильно работать в заданном стиле, соблюдать особый формат или лучше выполнять узкую операцию. Но оно не превращает модель в автоматически обновляемую энциклопедию внутренних правил.
Модели с длинным контекстом позволяют передать сразу большой документ или набор документов. Это удобно для разовой работы, например анализа конкретного договора. Но загрузка всего архива в каждый запрос увеличивает вычислительные затраты и добавляет информационный шум. Модели с длинным контекстом могут давать высокое качество, однако их работа чувствительна к информации и обходится дороже.
Обычный корпоративный поиск возвращает список документов или страниц. Он дешевле и предсказуемее, но сотрудник сам открывает результаты, сравнивает редакции и формулирует вывод.
RAG располагается между этими подходами: отбирает нужные фрагменты и поручает модели собрать ответ. Поэтому корректнее воспринимать его не как замену поиска, а как надстройку над поисковой инфраструктурой.
Об отличиях RAG от LLM читайте в статье «RAG: как использовать технологию с базами и графами знаний»
Когда RAG не подходит бизнесу
Однако RAG не идеален. Он не исправляет плохие данные и не гарантирует результат там, где требуется безошибочное решение или анализ всей совокупности связей. Среди ограничений применения технологии:
Как подготовить корпоративные данные для RAG
Перед проектом необходимо определить, какие RAG-данные считаются доверенными. У каждого источника должны быть владелец, дата актуализации, область применения и правила доступа. Иначе в поисковом индексе окажутся презентация трёхлетней давности, рабочий черновик и утверждённый регламент — без возможности понять, какой документ приоритетнее.
Особое значение имеет разбиение текста. Слишком маленький фрагмент хорошо совпадает с отдельными словами, но теряет условия и исключения. Слишком большой приносит много лишнего контекста. Универсального размера нет: инструкция, таблица тарифов и договор требуют разных правил.
Метаданные часто важнее векторной близости. Филиал, продукт, дата действия, тип клиента и уровень конфиденциальности помогают сначала сузить область поиска, а уже затем выбрать фрагменты по смыслу.
Нужен и процесс удаления документов. Если отменённая инструкция остаётся в индексе, система продолжит на неё ссылаться. Поэтому создание RAG следует рассматривать как постоянную работу с жизненным циклом знаний, а не как разовую загрузку архива.
Как внедрить RAG-систему в компании
Успешное RAG-внедрение начинается с узкого процесса, измеримой проблемы и набора реальных вопросов пользователей.
На первом этапе бизнес-владелец формулирует не технологическую, а операционную задачу. Не «создать помощника на базе LLM», а, например, «сократить время поиска инструкций второй линией поддержки и снизить число эскалаций экспертам».
Затем собирается контрольный набор вопросов. В него должны входить простые случаи, редкие формулировки, неоднозначные запросы, вопросы без ответа и попытки получить закрытые данные. Для каждого вопроса фиксируются правильные источники и допустимый ответ.
После этого команда проводит аудит документов, собирает опытный образец и проверяет поиск отдельно от генерации. Если система не находит нужный фрагмент, настройка запроса (промпта) не решит проблему.
Только после технической проверки проводится пилот с ограниченной группой пользователей. Команда анализирует, какие вопросы задают сотрудники, где они не доверяют ответам, какие ссылки открывают и в каких случаях обращаются к человеку.
В проекте участвуют не только разработчики. Владелец процесса определяет результат, предметные эксперты подтверждают знания, специалисты по данным готовят источники, информационная безопасность задаёт ограничения, ИТ-команда отвечает за интеграцию и эксплуатацию. Без владельцев документов RAG-система быстро теряет актуальность.
Путь RAG от пилота к промышленной эксплуатации
Проекты российских компаний по внедрению технологий: от ИИ-агентов и генеративных моделей до отраслевых решений — в разделе «Кейсы».
Как оценивать качество и экономическую эффективность RAG
RAG необходимо оценивать на трёх уровнях: качество поиска, качество ответа и влияние на бизнес-процесс.
Техническая команда часто начинает с субъективного впечатления: ответ звучит убедительно и хорошо написан. Для промышленной эксплуатации этого недостаточно.
На поисковом уровне измеряется, нашла ли система правильные документы и фрагменты. Базовые RAG-метрики включают:
На уровне генерации проверяются:
Отдельно оценивается правильность ссылок: модель может сформулировать верный тезис, но сослаться не на тот документ.
На уровне бизнеса рассматривают:
Для контакт-центра важна длительность обработки обращения; для инженеров — время поиска инструкции; для юридической службы — скорость подготовки первичной справки.
Проверочный набор должен включать десятки или сотни характерных вопросов и обновляться вместе с системой. Тестировать нужно не только финальный текст, но и качество найденных фрагментов.
Экономику проекта стоит считать относительно базового процесса. Если сотрудник тратил на поиск десять минут, а после внедрения — две, необходимо определить стоимость высвобождённого времени, число операций и долю ответов, которые всё равно требуют проверки. Красивый интерфейс сам по себе не доказывает окупаемость.
Риски применения RAG
RAG снижает часть рисков генеративного ИИ, но создаёт новый контур доступа к корпоративным знаниям, который необходимо защищать.
Главная опасность — ложное доверие. Ответ, собранный из внутренних документов, выглядит авторитетнее обычной генерации. Но источник может оказаться устаревшим, поиск — неполным, а вывод модели — ошибочным.
Второй риск связан с правами доступа. Индекс не должен становиться способом обойти ограничения исходной системы. Если сотруднику недоступен финансовый отчёт, помощник не должен пересказывать его содержание только потому, что документ попал в общую базу.
Третий риск — вредоносные инструкции внутри документов. Внешний файл или пользовательский текст может содержать указание игнорировать правила системы, раскрыть данные или выполнить нежелательное действие. Поэтому документы требуют проверки, а инструкции модели и найденный контент необходимо разделять на уровне архитектуры.
Четвёртый риск — утечка через внешнюю модель или журналы запросов. Даже когда документы не используются для дообучения, текст может передаваться поставщику для обработки. Компании необходимо проверить условия хранения, географию размещения, режим журналирования и порядок удаления данных.
Наконец, нужен механизм отказа. Если надёжного ответа нет, корректная система должна сообщить об этом или передать запрос специалисту, а не заполнять пробелы правдоподобным текстом. Референсные материалы также подчёркивают, что RAG не устраняет галлюцинации полностью, а качество результата зависит от поиска и источников.
Перспективы RAG
Сейчас RAG развивается как часть корпоративных систем генеративного ИИ — более контекстных, мультимодальных и встроенных в рабочие процессы.
Спрос бизнеса уже выходит за рамки простых помощников по базе знаний. По оценке «Яков и Партнёры», в 2025 году генеративный ИИ хотя бы в одной функции применяли 71% опрошенных российских компаний, а его потенциальный вклад в ВВП России к 2030 году может составить 1,6–2,7 трлн рублей.
Основные направления развития RAG — работа с контекстом диалога, адаптивный поиск, мультимодальность и агентная логика. Система может учитывать предыдущие вопросы, роль сотрудника и уже найденные документы, выбирать между векторным, лексическим и гибридным поиском, а также работать не только с текстами, но и с таблицами, изображениями, аудио и видео.
Следующий этап — агентный RAG. В такой архитектуре система не ограничивается одним поиском, а разбивает задачу на шаги, обращается к нескольким источникам, проверяет промежуточные результаты и формирует итоговый вывод. В более сложных сценариях несколько специализированных агентов могут распределять между собой поиск документов, анализ показателей и проверку соответствия регламентам.
Для бизнеса это означает переход от универсальных чат-ботов к специализированным решениям, встроенным в конкретные процессы. Однако чем выше автономность, тем важнее контроль доступа, журналирование, проверка источников и подтверждение критичных действий человеком. Поэтому RAG целесообразно развивать поэтапно: от поиска и ответов по документам — к работе с несколькими форматами и системами, а затем к рекомендациям и ограниченному выполнению действий.
Главное о RAG
RAG полезен там, где языковой модели нужны актуальные, проверяемые и закрытые знания компании.
Иными словами, RAG для бизнеса — это инфраструктура управляемого доступа ИИ к корпоративным знаниям. Её зрелость определяется не выразительностью ответов, а тем, насколько надёжно система находит источники, соблюдает ограничения и помогает принимать рабочие решения.
Частые вопросы
RAG — это способ дать языковой модели доступ к внешним документам перед подготовкой ответа. Система сначала находит нужную информацию, затем передаёт её модели, а та формулирует итог для пользователя.
Обычный чат-бот может отвечать на основе заранее заданных сценариев или общих знаний модели. RAG-помощник ищет сведения в подключённых корпоративных источниках и способен прикладывать ссылки на использованные документы.
Не обязательно. Для работы RAG достаточно подключить языковую модель к подготовленному поисковому индексу. Дообучение может дополнительно потребоваться, если нужно изменить стиль, формат или специализированное поведение модели.
Нет. Найденный контекст уменьшает вероятность вымышленных фактов, но модель всё равно может неверно интерпретировать источник или дополнить ответ неподтверждённым выводом. Поэтому критичные ответы проверяют, а к фактам прикладывают ссылки.
Начать следует с одного процесса, где сотрудники регулярно ищут сведения в документах и результат можно измерить. Затем собирают контрольные вопросы, проверяют качество источников, создают опытный образец и сравнивают время, точность и стоимость с исходным процессом.