Как RAG-система отвечает по документам компании и как проверить качество ответов
RAG-система для бизнеса помогает найти действующее правило среди инструкций, регламентов и описаний продуктов. Когда документы расходятся, а ответ нельзя подтвердить, сотруднику нужен понятный сигнал о нехватке данных. Качество такого помощника проверяют на вопросах компании и конкретных источниках.
Что такое RAG-система для бизнеса
RAG-система для бизнеса находит сведения в документах компании и передаёт их языковой модели вместе с вопросом. Модель формулирует ответ на основе найденных фрагментов. Сотрудник получает объяснение и ссылки, по которым может проверить исходное правило.
Аббревиатура RAG раскрывается как Retrieval-Augmented Generation — генерация с дополнением из поиска. Общая последовательность описана в документации Google Cloud. Для руководителя смысл практический: корпоративная база знаний становится доступной через вопросы обычным языком. При изменении регламента обновляют документы и поисковый индекс; переобучение модели для каждого изменения обычно не требуется.
Ответ ограничивают разрешёнными источниками. Если подтверждения нет, система должна сообщить об этом, запросить уточнение или направить вопрос ответственному сотруднику. Наличие RAG само по себе не исключает выдуманные утверждения: это проверяют при приёмке и во время эксплуатации.
Какие задачи решает поиск по документам компании
Начинать удобно с повторяющегося вопроса, на который уже существует согласованный ответ. Например, специалист поддержки ищет порядок обработки обращения, менеджер уточняет условия услуги, а новый сотрудник разбирается во внутренних инструкциях.
- Внутренняя поддержка. Ассистент объясняет порядок заявки и показывает нужную инструкцию.
- Подготовка ответа клиенту. Сотрудник получает черновик по утверждённым материалам и проверяет его перед отправкой.
- Работа с продуктом. Менеджер сопоставляет вопрос с техническими описаниями, ограничениями и условиями обслуживания.
- Обучение сотрудников. Новичок находит правила по своей роли, а владелец базы видит вопросы, на которые документация не отвечает.
Выбор первого сценария
Зафиксируйте аудиторию, тип вопросов и границы ответственности. Формулировка «помощник для операторов по действующим инструкциям» позволяет собрать проверочный набор. Формулировка «знает всё о компании» оставляет неопределёнными и источники, и критерии успеха. Такой анализ можно включить в бизнес-аналитику проекта.
Данные из действующих систем
Статус конкретного заказа и текущий остаток товара запрашивают у учётной системы через программный интерфейс. Копия вчерашнего отчёта в базе знаний может устареть. В одном ассистенте можно объединить поиск по инструкциям и запросы в действующие системы, но для каждого ответа нужно понимать его происхождение.
Как работает RAG: от вопроса до ответа
У решения есть два процесса: подготовка базы и обработка запроса. Первый поддерживает документы в доступном для поиска виде. Второй выбирает разрешённые сведения и формирует ответ. Это разделение помогает установить причину ошибки.
- Вход сотрудника. Сервер определяет пользователя и его права.
- Поиск. В разрешённых документах выбираются подходящие фрагменты.
- Отбор контекста. Система проверяет актуальность и порядок найденных материалов.
- Генерация. Модель получает вопрос, фрагменты и правила ответа.
- Проверка и выдача. Пользователь видит ответ, источники или сообщение о недостатке данных.
Поиск по словам и по смыслу
Поиск по словам полезен для артикулов, сокращений и точных названий. Векторный поиск использует числовые представления текста, чтобы находить близкие по смыслу фрагменты. Гибридный поиск объединяет оба подхода; такой механизм описан в документации Microsoft. Для конкретной базы сравнивают варианты на одинаковых вопросах.
Повторная оценка найденных фрагментов
Дополнительное ранжирование меняет порядок результатов по их соответствию вопросу. Например, среди похожих инструкций выше оказывается документ для нужного подразделения. Google Cloud описывает этот этап отдельно от первоначального поиска. Он добавляет вычисления, поэтому его пользу сопоставляют с задержкой и расходами.
Как подготовить документы для базы знаний
Качество базы начинается с владельца документа и его статуса. Рабочая инструкция, отменённый приказ и личная заметка могут описывать один процесс по-разному. Команда должна определить, какие материалы разрешены для ответов и кто разрешает противоречия.
Сохранить смысл при извлечении текста
Из файлов извлекают текст, а сканы распознают. Затем проверяют таблицы, заголовки, примечания и ссылки: потерянное условие в соседней ячейке способно изменить правило. Документы делят на смысловые фрагменты с достаточным контекстом. Универсальный размер фрагмента для любых файлов задавать преждевременно: его подбирают по результатам поиска.
Записать версию и источник
- Происхождение. Ссылка на документ, раздел или страницу, где находится правило.
- Актуальность. Версия, дата действия и признак отмены.
- Ответственность. Владелец материала и подразделение, к которому он относится.
- Доступ. Группы пользователей, которым разрешено читать документ и его фрагменты.
При обновлении нужно заменить прежние фрагменты, а при удалении документа — убрать их из индекса и связанных копий. Отдельно проверяют отзыв прав и очистку сохранённых ответов. Реестр источников и правила обновления стоит закрепить в техническом задании. Методический подход к подготовке данных и выбору разбиения приведён в руководстве Microsoft по проектированию RAG.
Как ограничить доступ к документам и ответам
Полномочия сотрудника должны ограничивать набор фрагментов до их передачи модели. Запрет в тексте инструкции для модели не заменяет серверную проверку. Подходы с фильтрацией документов по пользователям и группам разобраны в документации Microsoft по доступу на уровне документов.
Проверить все места хранения
Разграничение нужно для поисковой выдачи, истории диалогов, временных копий ответов и журналов. Пользователь не должен получать закрытый фрагмент через цитату, название документа или ответ, ранее сформированный для другой роли. При недоступности проверки прав обработку запроса безопаснее остановить.
Отделить содержимое документа от команды
В загруженном файле может оказаться указание изменить правила ответа или раскрыть закрытую информацию. Это внедрение инструкций через данные; OWASP описывает соответствующий риск. Документ следует обрабатывать как источник сведений. Возможности модели ограничивают на сервере, а попытки обхода включают в испытания. Для ассистента с действиями согласования и права на эти действия проектируют отдельно.
Пример ответа по документам компании
Рассмотрим учебный сценарий внутренней поддержки. Вымышленная компания хранит утверждённую инструкцию: заявку на доступ подают через сервис обращений, руководитель согласует её, затем администратор назначает права. Пример показывает формат проверки; это не описание внедрения у клиента FITTIN.
Вопрос сотрудника: «Как получить доступ к системе учёта?»
Подтверждённый ответ: «Создайте заявку в сервисе обращений и укажите нужную роль. После согласования руководителем администратор назначит доступ. Основание: инструкция „Доступ к системам“, раздел „Порядок заявки“, действующая версия».
Граница ответа: если инструкция не содержит срока, ассистент не должен добавлять обещание «доступ выдадут сегодня».
Проверяемая ссылка на источник
В рабочем интерфейсе рядом с утверждением показывают переход к конкретному разделу, название и версию документа. Ссылка должна открываться с обычной проверкой прав пользователя. Проверяющий сопоставляет текст ответа с фрагментом: само наличие ссылки ещё не доказывает, что вывод из неё следует.
Нехватка сведений и конфликт источников
На вопрос «можно ли выдать доступ подрядчику без согласования?» инструкция может не отвечать. Тогда полезный ответ фиксирует пробел и предлагает обратиться к владельцу процесса. При двух противоречащих действующих документах система должна показать конфликт, а не молча выбрать удобный вариант. Эти случаи включают в проверку наряду с обычными вопросами.
Как проверять качество RAG-системы
Проверка должна отвечать на разные вопросы: нашёлся ли нужный источник, подтверждены ли выводы и решена ли задача пользователя. Microsoft разделяет оценку поиска и итогового ответа. Одно среднее значение «точности» скрывает причину сбоя.
Подготовить контрольные вопросы
Владелец процесса размечает вопросы, ожидаемые сведения, допустимые источники и ситуации для отказа. Набор должен покрывать обычные запросы, опечатки, внутренние сокращения, устаревшие версии, закрытые материалы и отсутствующие ответы. Часть вопросов используют для настройки, другую сохраняют для независимой приёмки. Иначе команда рискует подогнать решение под знакомые примеры.
| Уровень | Что измерять | Как проверить |
|---|---|---|
| Поиск | Доля нужных фрагментов, попавших в первые k результатов — полнота поиска, Recall@k | Сопоставить выдачу с размеченными источниками; заранее зафиксировать k |
| Обоснованность | Подтверждение существенных утверждений источниками | Проверить каждое утверждение и соответствующий фрагмент |
| Полезность | Полнота ответа на вопрос и соблюдение условий | Сравнить с ожидаемыми сведениями, проверить экспертом |
| Отказ | Корректная реакция при отсутствии данных или конфликте | Отдельно считать обоснованные отказы и отказы там, где ответ существует |
| Доступ | Выдача сведений только разрешённым ролям | Повторить запрос под разными пользователями и после отзыва прав |
| Эксплуатация | Время ответа и стоимость обработки запроса | Измерять полную обработку под ожидаемой нагрузкой |
Читать результаты по категориям
Учебный расчёт: в наборе из 100 вопросов 80 имеют ответ в базе, 20 требуют отказа. Нужный источник найден для 72 из 80 вопросов с ответом. Доля таких вопросов равна 72 / 80 = 90%; это успех поиска хотя бы одного нужного источника, а не точность системы целиком. Для остальных вопросов отдельно проверяют поведение при отсутствии данных.
Автоматическая оценка другой моделью помогает разбирать большой набор, но её заключения также проверяют по экспертной разметке. Порог приёмки зависит от последствий ошибки. Результаты по закрытым данным и критическим инструкциям рассматривают отдельно, чтобы высокий средний балл не скрывал недопустимый ответ.
Типичные ошибки и способы их найти
Разбор ошибки начинается с исходного вопроса, найденных фрагментов и сформированного ответа. Если команда сохраняет версии компонентов и результаты проверок, она может воспроизвести сбой и проверить исправление. Состав журналов и доступ к ним согласуют с учётом чувствительности документов.
| Симптом | Что проверить | Что изменить |
|---|---|---|
| Нужный документ существует, но ответ не найден | Извлечение текста, разбиение, сокращения и фильтры доступа | Исправить подготовку данных или поиск, повторить контрольный набор |
| Ответ ссылается на отменённое правило | Версии, дату действия, удаление прежних фрагментов | Настроить жизненный цикл документов и очистку копий |
| Источник верный, вывод содержит лишнее условие | Соответствие каждого утверждения найденному контексту | Уточнить формат ответа и проверку подтверждений |
| Система отказывает почти на всё | Доступность источников и чрезмерные ограничения поиска | Разобрать ошибочные отказы отдельно от корректных |
| Документ одной роли видит другая | Серверные права, историю, сохранённые ответы | Закрыть ошибочный путь выдачи и повторить проверки доступов |
Замена языковой модели имеет смысл после установления причины. Если правило потерялось при распознавании таблицы, увеличение модели не восстановит отсутствующие данные. Проверку отказов и ролевых сценариев включают в план испытаний при заказной разработке программного решения.
Чек-лист внедрения и сопровождения
Пилот стоит ограничить одним процессом, сохранив полноценную проверку документов и доступов. Его результатом становятся протокол испытаний и решение о расширении, доработке или остановке сценария.
- Ответственный назначен. Владелец процесса утверждает источники и ожидаемые ответы.
- База подготовлена. Проверены извлечение текста, версии, исключения и отменённые документы.
- Доступы испытаны. Пройдены проверки разных ролей, отзыва разрешений и сохранённых ответов.
- Приёмка независима. Контрольные вопросы отделены от примеров для настройки.
- Передача сотруднику работает. Пользователь понимает следующий шаг при отказе или конфликте.
- Изменения контролируются. После обновления модели, поиска или базы повторяются согласованные испытания.
Из чего складывается стоимость
В первоначальную работу входят анализ сценария, подготовка источников, поисковый индекс, интерфейс, интеграции и испытания. Эксплуатация включает вычисления, обращения к модели, обновление документов и разбор ошибок. Оценку запрашивают под согласованный объём: количество страниц без учёта форматов, ролей и частоты изменений не определяет бюджет.
Для планирования сравнивайте стоимость полезного результата и прежнего процесса. Сокращённое время поиска становится денежной экономией только при изменении затрат или использовании освободившегося времени для других задач. Расходы на экспертную проверку и сопровождение также входят в расчёт.
Итог: как начать проект RAG для компании
Обоснованный старт RAG-проекта — один процесс, согласованные документы и проверяемые критерии приёмки. Такой формат позволяет оценить полезность ответа, обнаружить пробелы базы и рассчитать расширение на фактических результатах. Дальнейшее внедрение ИИ в бизнес-процессы планируют с учётом этих проверок.
FITTIN разрабатывает чат-ботов с ИИ для бизнеса и ассистентов для сотрудников. Состав источников, требования к обработке данных и интеграции определяются под задачу. Для процесса с действиями можно рассмотреть разработку ИИ-агента; поиск по документам будет одной из его функций.
Часто задаваемые вопросы
Чем RAG отличается от обучения модели на документах компании?
RAG ищет нужные фрагменты во внешней базе и добавляет их к запросу во время ответа. Дообучение меняет параметры модели и может применяться для формата или специфического поведения. Для обновляемых инструкций поиск позволяет менять документы без переобучения при каждом изменении. При этом оба подхода требуют проверки: наличие документа в базе ещё не означает, что система найдёт его и правильно использует.
Можно ли подключить PDF, Word и таблицы к RAG-системе?
Можно, если для форматов настроено корректное извлечение содержимого. Сканированные страницы требуют распознавания, таблицы — сохранения связей между строками, столбцами и примечаниями. Проверяют результат на реальных файлах компании, включая сложные страницы. Кроме текста нужны ссылки на источник, версии и права доступа. До запуска полезно испытать вопросы, ответ на которые зависит от сноски, заголовка или соседней ячейки таблицы.
Как проверить, что ИИ отвечает по документам, а не выдумывает?
Подготовьте вопросы с ожидаемыми сведениями и допустимыми источниками. Проверяйте найденные фрагменты, существенные утверждения ответа и ссылки на документы. Отдельно задавайте вопросы, на которые база не отвечает: система должна признавать нехватку информации. Автоматическая оценка помогает обработать набор, но спорные и критические ответы проверяет эксперт. Наличие ссылки без проверки её содержания не подтверждает достоверность вывода, даже если формулировка звучит уверенно.
Как закрыть доступ к документам других отделов?
Система должна определять пользователя и применять его права при поиске, до передачи фрагментов модели. Ограничения распространяются на цитаты, историю диалогов, сохранённые ответы и журналы. Проверки проводят под разными ролями, после смены группы и после отзыва разрешений. Текстовая просьба к модели не раскрывать документы недостаточна. Конкретный механизм зависит от корпоративной системы учётных записей и структуры прав на исходные материалы.
Что делать, если в базе знаний нет ответа или документы противоречат?
Заранее задайте порядок обработки таких ситуаций. Если подтверждения нет, ассистент сообщает об этом, предлагает уточнить запрос или обратиться к ответственному сотруднику. При конфликте действующих документов он должен показать расхождение, не придумывая общее правило. Владелец процесса исправляет первоисточники, после чего обновляется индекс. Эти сценарии проверяют отдельно, чтобы уменьшение числа ошибочных ответов не достигалось за счёт отказа на любые вопросы.
Сколько стоит внедрение RAG для компании?
Бюджет зависит от сценариев, форматов документов, прав доступа, интеграций, нагрузки и требований к проверке качества. Отдельно оценивают подготовку системы и эксплуатацию: вычисления, обращения к модели, обновление базы и экспертный разбор ошибок. Для расчёта нужны примеры файлов и вопросов, роли пользователей и критерии приёмки. Пилот на одном процессе помогает уточнить объём и дальнейшие расходы; универсальной цены по количеству документов недостаточно.
Источники и методика
Технические материалы проверены 16 октября 2026 года. Они объясняют устройство RAG; выбор конкретного облака или модели требует отдельной оценки требований проекта. Сценарий заявки и расчёт на 100 вопросах в статье учебные.
- Google Cloud: устройство RAG и подготовка данных.
- Microsoft: проектирование и последовательная оценка RAG.
- Microsoft: гибридный поиск.
- Google Cloud: повторное ранжирование результатов.
- Microsoft: доступ к отдельным документам.
- Microsoft: оценка поиска и ответов.
- OWASP: внедрение инструкций через входные данные.
Материал носит информационно-аналитический характер, отражает оценку команды FITTIN на дату публикации. Показатели учебного примера не являются результатами клиентского проекта или обещанием качества внедрения.
