Практика внедрения · 8 минут на чтение

RAG для бизнеса: как ИИ-ассистент отвечает по документам компании

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

RAG связывает генерацию ответа с источником

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

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

Один ответ проходит несколько контролируемых этапов

1. Определение запроса. Система очищает вопрос от технического шума, учитывает роль пользователя и при необходимости уточняет формулировку.
2. Поиск. Запрос сопоставляется не с именами файлов, а со смыслом фрагментов. Фильтры ограничивают отдел, продукт, дату, статус документа и права доступа.
3. Отбор контекста. В модель передаются несколько наиболее подходящих частей, а не десятки полных файлов. Так проще удержать фокус и показать источник.
4. Генерация. Инструкция задаёт границы: отвечать только по найденным материалам, не додумывать отсутствующие факты и сообщать о нехватке данных.
5. Проверка и действие. Ответ может сопровождаться ссылками, уровнем уверенности или передачей человеку. Изменение записи в рабочей системе — отдельный шаг с собственными правилами.

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

Для базы знаний важнее качество, чем объём

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

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

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

Права доступа должны действовать до генерации

Недостаточно попросить модель «не показывать секретные данные». Документы, к которым у пользователя нет доступа, не должны попадать в результаты поиска и контекст вообще. Разрешения связывают с ролью, подразделением или конкретным источником, а чувствительные поля маскируют до отправки в модель, если они не нужны для ответа.

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

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

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

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

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

Начать лучше с узкого набора вопросов

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

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