RAG-система для корпоративной базы знаний

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

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

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

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

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

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

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

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

Отдельно согласуем хранение запросов, резервные копии и доступ администратора. Локальное размещение не отменяет этих задач. Обновление модели, изменение поиска или загрузка нового корпуса способны повлиять на качество, поэтому проходят проверку. Общие требования к инфраструктуре приведены на странице локального ИИ.

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

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

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

Первичная диагностика бесплатна. Пилот на одном процессе стоит $3–5 тыс. и засчитывается в стоимость внедрения. Его техническая часть занимает 2–4 недели; подготовка корпуса и согласование доступа могут увеличить общий срок. Полная система под ключ — от $30 000, подписка на развитие — $2,5–5 тыс. в месяц.

На объём работ влияют качество документов, число источников, сложность прав доступа и требования к рабочему интерфейсу. Очистка архива или восстановление структуры плохих сканов могут потребовать больше усилий, чем выбор модели. Поэтому оценку даём после проверки примеров. Состав поставки, оборудование и интеграции фиксируются отдельно в договоре.

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