RAG: как ИИ отвечает по документам компании

Документы перед ответом

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

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

Что происходит внутри

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

1. Убрать дубли, устаревшие версии и рекламные обещания без правил.
2. Сохранить название документа, дату и права доступа.
3. Разделить текст так, чтобы условие не оторвалось от исключения.
4. Проверить поиск на настоящих вопросах сотрудников.
5. Настроить ответ с указанием источника и передачу спорных вопросов человеку.

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

Поиск и ответ проверяют отдельно

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

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

Когда хватает более простой схемы

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

Задача	Подход
Найти пункт в большом архиве	Поиск по документам и ответ с источником
Посчитать стоимость по формуле	Проверяемый расчёт
Узнать текущий статус заявки	Запрос к рабочей системе
Написать черновик общего письма	Модель с кратким контекстом задачи

Обновления и доступы

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

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

Практическая проверка базы

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

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