RAG простыми словами: как работает RAG-система для бизнеса

Почему ИИ без данных компании отвечает мимо

Бизнес-вопросы часто связаны не с общими знаниями, а с информацией конкретной компании:

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

Без корпоративных источников модель может попытаться достроить ответ самостоятельно.

И сделать это вполне убедительно.

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

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

Что такое RAG простыми словами

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

Полная расшифровка — Retrieval-Augmented Generation. По-русски можно сказать так: генерация ответа, усиленная поиском информации.

Упрощённая схема:

вопрос → поиск → контекст → LLM → ответ

Обычная языковая модель отвечает в основном на основе знаний и закономерностей, полученных во время обучения.

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

Например, сотрудник спрашивает:

«Что делать, если клиент прислал неполный комплект документов?»

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

RAG — это не отдельная нейросеть и не конкретный чат-бот. Такой механизм можно встроить в сайт, CRM, внутренний портал, клиентский кабинет, поддержку или AI-ассистента.

И технически RAG — это не одна технология, а архитектура из нескольких компонентов.

Как проходит один запрос в RAG

Допустим, сотрудник спрашивает:

«Что делать, если клиент прислал неполные данные?»

Система ищет связанные материалы и находит:

• инструкцию для менеджеров;
• раздел базы знаний;
• чек-лист обработки заявки.

После этого выбираются наиболее релевантные фрагменты.

Модель получает вопрос сотрудника, найденный контекст и правила ответа.

Например:

«Если в заявке не хватает обязательных данных, запросите недостающую информацию по чек-листу и не переводите заявку на следующий этап до её получения.»

RAG не должен передавать модели всю корпоративную библиотеку.

Задача поискового слоя — найти небольшой объём информации, который действительно относится к вопросу.

Как документы попадают в RAG-систему

Подготовка данных происходит до того, как пользователь задаст вопрос. Этот процесс часто называют ingestion.

Общая последовательность:

источник → извлечение текста → очистка → структура → chunking → metadata → embeddings → индекс

Какие источники можно подключать

В зависимости от проекта это могут быть:

• PDF;
• DOCX;
• HTML;
• Wiki;
• база знаний;
• CRM;
• внутренний портал;
• облачное хранилище;
• API;
• базы данных.

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

Извлечение данных

Задача этого этапа — получить из исходного документа текст и структуру, пригодные для дальнейшего поиска.

Для обычного текстового документа это относительно просто.

Со сложными файлами появляются дополнительные задачи:

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

Например, значение из таблицы может быть понятно только вместе с названием колонки. Если просто извлечь строки без структуры, часть смысла потеряется.

Поэтому качественный ingestion — это не просто извлечение текста из PDF.

Что такое chunking и зачем документ делят на части

RAG обычно ищет не целые документы, а отдельные смысловые фрагменты.

Представим регламент на 40 страниц.

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

Поэтому документ делят на chunks.

Например:

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

Вместе с текстом можно сохранить metadata:

• название документа;
• раздел;
• дату;
• тип документа;
• версию;
• подразделение;
• права доступа.

Слишком большой chunk содержит лишний контекст.

Слишком маленький может потерять смысл.

Например, фраза:

«Срок составляет пять рабочих дней»

сама по себе мало полезна, если потерян заголовок, объясняющий, о каком сроке идёт речь.

Поэтому универсального размера chunk для всех проектов нет. При разбиении лучше учитывать структуру документа и смысловые границы.

Что такое embeddings и векторный поиск

Люди не всегда формулируют вопрос теми же словами, которые используются в документе.

Пользователь спрашивает:

«Как оформить возврат?»

А раздел инструкции называется:

«Порядок возврата товара клиентом».

Слова отличаются, но смысл один.

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

Упрощённо:

текст → embedding model → числовое представление → индекс

Запрос пользователя преобразуется аналогичным способом, после чего система ищет близкие по смыслу материалы.

Для хранения и поиска embeddings часто используют векторную базу или векторный индекс.

Но векторный поиск — не единственный возможный вариант retrieval.

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

Как RAG ищет нужную информацию

Для корпоративной системы одного семантического поиска обычно недостаточно.

На практике могут сочетаться несколько способов retrieval.

• Semantic search
  Ищет фрагменты, близкие к вопросу по смыслу.
  Полезен, когда пользователь и документ используют разные формулировки.
• Keyword search
  Ищет точные слова, номера, названия, артикулы и обозначения.
  Например, для номера договора или модели оборудования точное совпадение может быть важнее смысловой близости.
• Hybrid search
  Объединяет несколько методов.
  Например, семантический и полнотекстовый поиск могут работать одновременно, после чего их результаты объединяются.
• Metadata filtering

Для бизнеса особенно важны дополнительные ограничения.

Пользователь спрашивает:

«Какой порядок согласования договора?»

Поиск может дополнительно учитывать:

• подразделение;
• тип договора;
• статус;
• актуальную версию;
• регион;
• права пользователя.

В результате одинаковый вопрос от двух сотрудников может возвращать разные разрешённые источники.

Поиск по смыслу сам по себе ещё не делает RAG корпоративной системой. Необходимы структура данных, metadata и правила доступа.

Что такое reranking

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

Например:

100 000 фрагментов → retrieval → 20 кандидатов → reranking → 5 лучших → LLM

Числа здесь только показывают принцип.

Reranker повторно оценивает найденные фрагменты относительно конкретного вопроса и помогает выбрать наиболее релевантные.

Это позволяет уменьшить:

• количество нерелевантных материалов;
• объём лишнего контекста;
• расход токенов;
• риск неправильного ответа.

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

Если retrieval принёс неправильные данные, даже хорошей модели будет сложно сформировать правильный ответ.

Как LLM формирует ответ

После retrieval и reranking начинается генеративная часть.

Модель обычно получает:

• system prompt;
• вопрос пользователя;
• найденный контекст;
• правила и ограничения.

Одно из правил может выглядеть так:

«Отвечай только на основе предоставленных источников. Если данных недостаточно — сообщи об этом.»

Также можно определить:

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

Если документов недостаточно, корректный ответ может быть таким:

«В доступных источниках нет информации для точного ответа. Уточните тип договора или обратитесь к специалисту.»

Даже при использовании RAG языковая модель остаётся генеративной.

Поэтому RAG снижает риск hallucinations, но не гарантирует их полного отсутствия.

Пример работы RAG по документам компании

Пользователь спрашивает:

«Какие документы нужны для запуска проекта?»

Обычная модель может ответить:

«Для запуска проекта понадобятся техническое задание, цели, сроки, бюджет и контактные данные ответственных лиц».

Это выглядит правдоподобно, но может не иметь отношения к реальному процессу компании.

RAG-система сначала обращается к подключённым источникам.

Например:

• в FAQ находит список данных от клиента;
• в карточке услуги — условия старта;
• во внутреннем чек-листе — требования для CRM-проекта;
• в регламенте — действия менеджера.

После этого модель может ответить:

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

Такой ответ уже опирается на порядок работы конкретной компании.

Если подходящей информации в источниках нет, система должна уметь сообщить об этом.

В реальном проекте поверх этого механизма нужно ещё спроектировать источники знаний, индексацию, права доступа, обновление данных, интерфейс и контроль качества ответов. Именно этот контур мы собираем при внедрении корпоративного AI-поиска и RAG.

С чем часто путают RAG

RAG часто смешивают с обычным чат-ботом, поиском или загрузкой документа в AI-чат.

• RAG и обычный чат-бот

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

RAG нужен, когда невозможно заранее подготовить ответ на каждую формулировку, а информацию приходится искать в большом объёме материалов.

• RAG и обычный поиск

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

RAG использует найденные материалы как контекст и формирует готовый ответ.

Поиск: «Вот подходящие документы».

RAG: «Вот ответ и источник, на котором он основан».

• RAG и загрузка PDF в чат

Разовая загрузка PDF удобна для анализа отдельного документа.

Корпоративная RAG-система должна дополнительно работать с большим количеством источников, контролировать права доступа, обновлять индекс, логировать ответы и обрабатывать ситуацию, когда данных недостаточно.

RAG или fine-tuning

RAG и fine-tuning решают разные задачи.

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

Fine-tuning может использоваться для изменения формата или поведения модели.

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

RAG и AI-агенты

RAG и AI-агенты тоже выполняют разные функции.

RAG получает знания.

AI-агент выполняет действия и управляет последовательностью операций.

Пользователь спрашивает:

«Можно ли согласовать этот договор?»

RAG может найти корпоративные правила и актуальный регламент.

AI-агент может использовать эти знания, проверить условия, запросить недостающие данные и вызвать нужный корпоративный сервис.

Схема:

AI-агент → RAG → корпоративные знания → решение → API / инструмент → действие

Таким образом, RAG может быть одним из инструментов агента.

Подробнее этот класс систем разбираем на странице AI-агенты для бизнеса.

Какие документы можно подключить

RAG может работать с разными типами корпоративных материалов.

• FAQ
  Частые вопросы, ограничения, этапы работы и условия услуг подходят для клиентских помощников и поддержки.
• Инструкции и регламенты
  Используются во внутренних ассистентах и базах знаний сотрудников.
• Карточки продуктов и услуг
  Позволяют отвечать по составу, условиям, ограничениям и срокам.
• Техническая документация
  Это могут быть спецификации, справочники, инструкции и другие профессиональные материалы.
  Для них особенно важна правильная обработка структуры и таблиц.
• Корпоративные базы знаний
  Внутренние Wiki, порталы и базы знаний часто становятся основным источником для корпоративного AI-поиска.
  Чем больше закрытой информации подключается к системе, тем важнее разграничение доступа.

RAG и права доступа к корпоративным данным

Если сотруднику нельзя открыть документ напрямую, AI-помощник также не должен выдавать содержащуюся в нём информацию.

Например:

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

Доступ должен учитываться до формирования ответа.

Корректная схема:

права пользователя → поиск среди разрешённых данных → контекст → LLM

Иначе AI-интерфейс может стать новым каналом получения информации, которая была закрыта в исходной системе.

Почему качество RAG зависит от базы знаний

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

Подробнее этот процесс разобран отдельно: как обновлять базу знаний для ИИ.

Как измерять качество RAG

Оценивать систему по принципу «вроде отвечает нормально» недостаточно.

Качество лучше проверять на нескольких уровнях.

Retrieval

Первый вопрос:

нашла ли система правильные источники?

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

Причиной могут быть chunking, embeddings, настройки поиска или metadata.

Generation

Следующий вопрос:

правильно ли модель использовала найденный контекст?

Иногда retrieval находит нужный документ, но модель пропускает важное условие или искажает его смысл.

Итоговый ответ

Наконец, ответ должен быть не только фактически правильным, но и полезным пользователю.

Для оценки можно отслеживать:

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

Тестовую выборку лучше строить на реальных вопросах сотрудников и клиентов.

Не только:

«Перечислите документы, необходимые для начала проекта».

Но и:

«Какие документы прислать?»

или:

«Я оплатил. Что дальше?»

Пользователи редко формулируют запрос так же аккуратно, как автор тестового сценария.

Где RAG используется в бизнесе

• AI-помощник на сайте
  Может отвечать по услугам, условиям, ограничениям и FAQ.
• Клиентская поддержка
  Помогает находить информацию в инструкциях и базе знаний.
• Внутренний ассистент
  Позволяет сотрудникам получать ответы по регламентам, инструкциям и внутренним документам.
• CRM и внутренние системы
  RAG может подсказывать менеджеру, какие данные запросить, какой документ использовать или что делать на следующем этапе.
• Личный кабинет
  Пользователь может получать пояснения по статусам, документам и дальнейшим действиям.

Когда компании действительно нужен RAG

RAG стоит рассматривать, если:

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

Хороший индикатор — ситуация, когда сотрудник знает, что ответ где-то существует, но регулярно тратит время на его поиск.

Если нужен полноценный поиск по документам компании, отдельно описали корпоративный AI-поиск и RAG.

Где RAG не поможет

RAG не решит задачу, если нормальных источников нет.

Он также не исправит автоматически:

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

RAG ускоряет работу с существующими знаниями, но не создаёт качественную базу знаний вместо компании.

Как снизить риск неправильных ответов

Для корпоративной RAG-системы полезно:

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

Главный принцип: система должна уметь не только отвечать, но и понимать, когда данных для ответа недостаточно.

Что подготовить перед внедрением RAG

Начинать лучше не с выбора LLM или векторной базы.

Сначала стоит:

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

Уже на этом этапе становится понятно, насколько компания готова к RAG.

Если документы разбросаны по десяткам папок, содержат противоречия и давно не обновлялись, первым этапом проекта станет не настройка embeddings, а работа с самими знаниями.