RAG-система нужна, когда сотрудник должен быстро найти ответ во внутренних документах и увидеть, откуда он взят. Например, проверить условие договора, порядок согласования, правило обслуживания или требование к проекту.
Первый пилот лучше ограничить одной базой знаний и одной группой пользователей. Так проще проверить документы, права и качество ответов. Если сразу подключить все папки компании, причину ошибки будет трудно найти.
Что такое RAG-система
RAG расшифровывается как Retrieval-Augmented Generation. Система дополняет запрос языковой модели информацией, найденной во внешнем источнике.
Упрощенная схема выглядит так:
- Компания выбирает документы для базы знаний.
- Система разбивает их на фрагменты и создает поисковый индекс.
- Пользователь задает вопрос обычным языком.
- Поиск находит подходящие фрагменты.
- Модель готовит ответ по найденному контексту.
- Пользователь открывает источник и проверяет вывод.
OpenAI File Search использует векторные хранилища, поиск по файлам, фильтрацию по метаданным и ранжирование результатов. В Yandex Foundation Models файлы также загружаются в поисковый индекс, а в ответе можно получить подтверждения источников.
Конкретный стек может быть другим. Для бизнеса важнее четыре свойства: система находит нужный документ, показывает источник, соблюдает права и отказывается отвечать, когда подтверждения нет.
Где RAG может быть полезен
RAG подходит для вопросов, ответ на которые уже содержится в документах, но поиск занимает много времени.
Поддержка клиентов
Сотрудник ищет порядок возврата, условия обслуживания, описание тарифа или инструкцию по типовой проблеме. В ответе должна быть ссылка на действующий документ.
Продажи сложного продукта
Менеджеру нужно быстро проверить ограничения, комплектацию, условия поставки или требования к подключению. Источником служат утвержденные материалы, а не старая переписка коллег.
Внутренние регламенты
Сотрудник уточняет порядок согласования счета, оформления командировки или передачи проекта. RAG сокращает время поиска, если документы поддерживаются в актуальном состоянии.
Проектная документация
Руководитель или участник проекта ищет принятое решение, требование, ограничение или ответственность. Для такого сценария особенно важны версия документа и доступ только к своему проекту.
Адаптация новых сотрудников
Новый сотрудник задает вопросы по продукту и внутренним правилам. Система помогает найти материал, но не заменяет владельца процесса и обучение.
Когда RAG не решит задачу
RAG работает с тем, что записано в источниках. Он не восстановит договоренность, которая осталась в личном чате, и не определит актуальное правило среди нескольких противоречивых файлов.
Не стоит начинать с RAG, если:
- документы давно не обновлялись;
- у файлов нет владельцев;
- одинаковая инструкция хранится в нескольких версиях;
- права доступа существуют только на словах;
- ответ требует текущего статуса сделки, оплаты или задачи;
- после ответа нужно выполнить действие в рабочей системе;
- у компании нет примеров вопросов, которые должны решаться поиском.
Текущий статус сделки лучше получать из CRM через контролируемую интеграцию. Действия в CRM требуют отдельной автоматизации или агента с ограниченными правами. Разница между этими механизмами разобрана в статье про AI-агента и обычную автоматизацию.
С какого набора документов начать
Для первого пилота выберите одну тему. Хороший набор можно описать одним предложением: «инструкции первой линии поддержки» или «регламенты согласования договоров».
Составьте список документов для пилота.
Таблица прокручивается по горизонтали
| Что зафиксировать | Зачем это нужно |
|---|---|
| Название документа | Понять, на что ссылается ответ |
| Владелец | Определить, кто подтверждает актуальность |
| Дата или версия | Не смешивать действующие и старые правила |
| Группа доступа | Не показывать закрытую информацию |
| Формат файла | Заранее найти проблемы с распознаванием |
| Период обновления | Понять, когда перестраивать индекс |
| Статус | Отделить действующие документы от архива |
В пилот не нужно включать весь файловый сервер. Небольшой, но полный по выбранной теме набор дает больше информации о качестве решения.
Как подготовить документы
Уберите явные дубли
Если одинаковое правило описано в трех файлах, система может найти старую версию. Оставьте актуальный файл, а старые версии пометьте как архивные или уберите из поиска.
Проверьте структуру
Заголовки, списки, таблицы и разделы помогают отделить одну мысль от другой. Скан без текстового слоя сначала нужно распознать и проверить. Сложная таблица может потребовать отдельной подготовки.
Добавьте метаданные
Минимальный набор: тип документа, подраздел, версия, дата действия и группа доступа. Метаданные помогают фильтровать поиск до передачи фрагментов модели.
Отделите справку от рабочих данных
Инструкция отвечает на вопрос «как нужно работать». CRM, учетная система и сервис задач отвечают на вопрос «что происходит сейчас». Для этих источников нужны разные способы подключения и проверки.
Назначьте владельца обновления
Пилот быстро потеряет ценность, если новый регламент появился, а индекс продолжает использовать старый. Должно быть понятно, кто добавляет новую версию и когда старая перестает участвовать в поиске.
Как настроить права
Доступ к базе знаний нельзя выдавать одной общей учетной записью без разделения пользователей. Поиск должен учитывать, какие документы разрешены конкретному сотруднику.
Например, специалист поддержки может видеть инструкции и описания продукта. Руководитель дополнительно получает внутренние регламенты. Финансовые документы и персональные данные остаются в отдельных группах.
OpenAI Company Knowledge использует существующие разрешения подключенных приложений: пользователь получает доступ только к тем материалам, которые ему уже разрешены. Для собственной RAG-системы такую же границу нужно спроектировать и проверить отдельно.
До пилота зафиксируйте:
- как пользователь входит в систему;
- откуда берется его роль;
- где хранится связь роли и документов;
- попадает ли запрос в журнал;
- кто видит историю запросов;
- как закрыть доступ уволенному сотруднику;
- что произойдет при ошибке проверки прав.
Как собрать контрольные вопросы
Проверять только простые вопросы недостаточно. Система может хорошо отвечать на очевидные запросы и ошибаться в важных исключениях.
Соберите несколько типов вопросов.
Прямой ответ
Информация находится в одном документе и сформулирована явно. Такой вопрос проверяет базовый поиск.
Ответ из нескольких фрагментов
Для ответа нужно сопоставить два раздела или два документа. Здесь проверяется полнота и отсутствие противоречий.
Запрос к старой версии
В архиве есть другое правило. Система должна использовать действующий документ или явно показать дату источника.
Вопрос без ответа
Нужной информации в базе нет. Правильное поведение - сообщить об отсутствии подтверждения, а не дополнять ответ догадкой.
Запрос к закрытому документу
Пользователь знает название файла, но не имеет доступа. Система не должна показывать содержимое, фрагменты или пересказ.
Неоднозначный вопрос
Формулировка подходит к нескольким продуктам или подразделениям. Система должна уточнить контекст.
Для каждого вопроса запишите ожидаемый источник, обязательные факты, допустимую форму ответа и критическую ошибку.
По каким критериям принимать пилот
Убедительный ответ еще не доказывает, что поиск работает правильно. Проверяйте каждый тест по таблице.
Таблица прокручивается по горизонтали
| Критерий | Что проверять |
|---|---|
| Источник | Ссылка ведет на документ, который подтверждает ответ |
| Актуальность | Использована действующая версия |
| Полнота | Не потеряны важные условия и исключения |
| Отказ | При отсутствии данных система не придумывает ответ |
| Права | Пользователь не получает закрытый материал |
| Повторяемость | При повторной проверке смысл ответа не меняется без причины |
| Обратная связь | Ошибку можно отметить и передать владельцу базы |
| Обновление | Новая версия документа попадает в поиск по понятному правилу |
| Журнал | Можно восстановить запрос, найденные источники и результат |
Критические ошибки считайте отдельно. Один показ закрытого документа или уверенный ответ без источника нельзя спрятать внутри хорошего среднего результата.
Как встроить RAG в работу
Пилот должен отвечать на рабочий вопрос, а не просто демонстрировать чат.
Опишите сценарий:
- Где у сотрудника возникает вопрос.
- В каком интерфейсе он обращается к базе знаний.
- Какие данные можно передать вместе с вопросом.
- Как выглядит ответ и ссылка на источник.
- Что делает сотрудник, если ответа нет.
- Куда отправляется замечание об ошибке.
- Кто обновляет документ.
- Как руководитель оценивает использование системы.
На первом этапе достаточно поиска и ответа. Запись данных в CRM, создание задач и отправку сообщений лучше добавлять после проверки документов и прав.
От чего зависит объем работ
На оценку RAG-пилота влияют:
- количество и формат документов;
- качество сканов и таблиц;
- число групп доступа;
- частота обновления источников;
- место хранения файлов;
- требования к журналу запросов;
- выбранная AI-платформа и инфраструктура;
- интеграция с CRM, порталом или сайтом;
- состав контрольных вопросов;
- требования к поддержке после запуска.
Поэтому для оценки сначала нужно увидеть документы, список пользователей и способ проверки результата. Название модели само по себе не определяет объем проекта.
Чек-лист перед стартом
- Выбрана одна задача и одна группа пользователей.
- Составлен реестр документов.
- Назначены владельцы источников.
- Отделены действующие версии от архива.
- Проверено распознавание сканов и таблиц.
- Описаны группы доступа.
- Подготовлены вопросы с ожидаемыми источниками.
- Добавлены вопросы без ответа и запросы к закрытым данным.
- Зафиксированы критические ошибки.
- Определен порядок обновления индекса.
- Есть журнал запросов и найденных источников.
- Понятно, кто принимает пилот.
Материалы о подготовке данных, правах и AI-сценариях собраны в разделе AI для бизнеса. Если пилот должен использовать данные CRM, сначала стоит проверить гигиену клиентских данных.
