RAG простыми словами: как ИИ отвечает по базе знаний со ссылками

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

RAG (Retrieval-Augmented Generation, «генерация с опорой на поиск») — это схема, в которой языковая модель сначала находит нужные фрагменты в базе знаний, а потом пишет ответ только на их основе. Модель не вспоминает факты «из головы», а работает как сотрудник, который перед ответом открыл регламент и процитировал нужный пункт.

Термин появился в научной работе группы исследователей во главе с Патриком Льюисом: статья «Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks» опубликована на arXiv в мае 2020 года и вошла в сборник конференции NeurIPS 2020. Авторы описали два вида памяти:

• параметрическая — знания, «зашитые» в веса модели при обучении;
• непараметрическая — внешний индекс документов, к которому модель обращается через поисковый модуль.

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

Почему обычный чат-бот выдумывает

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

Национальный институт стандартов и технологий США (NIST) в профиле рисков генеративного ИИ NIST AI 600-1 (июль 2024) называет это явление «конфабуляцией» — генерацией уверенно поданного, но ошибочного или ложного содержания, которое в обиходе называют «галлюцинациями». NIST отмечает три вещи, важные для бизнеса:

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

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

Как RAG работает: четыре шага

RAG-система состоит из базы знаний, поиска по ней и модели, которая пишет ответ по найденному. В описании AWS процесс выглядит так:

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

Главное отличие от дообучения модели: чтобы система узнала новый регламент, его не нужно «вшивать» в модель — достаточно добавить документ в базу. AWS называет это дешевле, чем переобучение базовой модели.

Почему ссылки на источники снижают риск ошибки

Ссылка превращает ответ ИИ из утверждения, которому надо верить, в утверждение, которое можно проверить за секунды. AWS прямо называет это преимуществом RAG: ответ может содержать ссылки на источники, и пользователь откроет оригинал.

Но, как предупреждает NIST, модель способна выдумать и ссылку. Поэтому важно не само наличие сносок, а то, куда они ведут. В корректной RAG-системе ссылка — это не текст, сгенерированный моделью, а указатель на фрагмент, который реально вернул поиск. Если сотрудник кликает и видит нужный пункт — ответ подтверждён. Если не видит — ошибка заметна сразу.

В Company Brain это заложено в продукт: под каждым утверждением — нумерованная ссылка на первоисточник, а каждый запрос и источник логируются. Если уверенность ниже порога, система отвечает «не знаю» и передаёт вопрос человеку. Это честнее и дешевле, чем правдоподобная ошибка, на основе которой кто-то примет решение.

Права доступа: почему фильтр должен стоять до генерации

В RAG всё, что нашёл поиск, попадает в контекст модели, поэтому проверять права нужно на этапе поиска, а не в готовом ответе. Если зарплатная ведомость или договор с ключевым клиентом попал в контекст, модель может пересказать его сотруднику, которому это видеть не положено.

В документации Microsoft Azure AI Search этот подход называется контролем доступа на уровне документов. Каждый документ в индексе хранит метаданные о правах, а при запросе система возвращает только то, что разрешено конкретному пользователю. Microsoft отдельно отмечает, что изменения прав в исходной системе начинают действовать после синхронизации метаданных с индексом — это стоит учитывать при проектировании.

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

Где RAG всё равно может ошибиться

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

Типовые причины ошибок и что с ними делают:

• Устаревшие документы. Нужен регулярный пересчёт индекса и правило, какая версия документа действующая.
• Неудачное разбиение текста. Таблица или пункт договора, разрезанные посередине, теряют смысл — фрагменты подбирают под тип документа.
• Вопрос шире базы знаний. Если ответа в документах нет, система должна сказать об этом, а не дополнять ответ общими знаниями модели.
• Права, не синхронизированные с источником. Если сотрудника перевели в другой отдел, его доступы в индексе должны обновиться.

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

Как Company Brain применяет этот подход

Company Brain подключает документы, переписку, встречи, CRM и 1С, индексирует их вместе с правами доступа и отвечает со ссылками — на русском, узбекском или английском. На странице продукта процесс описан в четыре шага: собирает, структурирует, отвечает, действует. Первые три соответствуют классической схеме RAG, четвёртый — навыки, которые готовят отчёты, черновики документов и задачи.

Что зафиксировано на сайте:

• коннекторы: Telegram, Google Drive, Gmail, Bitrix24, amoCRM, 1С;
• каналы: Telegram-бот и веб-интерфейс;
• прототип на ваших данных — через 2 недели после старта, пилот — 2–4 недели, промышленный запуск — через 6–10 недель;
• приёмка пилота: 50 реальных вопросов сотрудников и порог 85% приемлемых ответов; приемлемый ответ верен по сути, ссылается на источник и не содержит ничего из документов вне прав доступа спросившего; ниже порога W2W дорабатывает за свой счёт;
• стоимость: облачный формат Business — внедрение от $5 000 и $500–1 500 в месяц; Enterprise в контуре клиента — внедрение от $15 000 и $1 500–5 000 в месяц.

Зачем это бизнесу? Исследование McKinsey Global Institute (2012) показало, что офисные сотрудники тратят почти 20% рабочего времени на поиск внутренней информации или коллег, которые могут помочь. RAG-ассистент сокращает этот поиск до одного вопроса — при условии, что ответ можно проверить. Подробнее о процессе внедрения — на странице «Как проходит внедрение».

С чего начать

Начните с 20–50 вопросов, которые сотрудники реально задают друг другу каждую неделю, и с перечня систем, где лежат ответы. Этого достаточно, чтобы оценить объём базы знаний, нужные интеграции и требования к правам доступа.

Практичный порядок:

1. Соберите вопросы из чатов, почты и обращений к руководителям.
2. Отметьте, где живут ответы: регламенты, 1С, CRM, Google Drive, Telegram.
3. Определите, кому какие данные можно видеть — это станет основой модели прав.
4. Решите, где должны храниться данные: облако или собственный контур.
5. Договоритесь о метрике приёмки до старта пилота.

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