Корпоративный RAG-поиск: архитектура, права доступа и качество ответов

Корпоративный RAG полезен не потому, что модель знает больше, а потому, что ответ опирается на разрешённые внутренние источники и показывает, откуда взят вывод. Без управления правами и качеством индекса такой поиск может быстро превратиться в удобный интерфейс к устаревшим или закрытым данным.

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

Сначала определите рабочий сценарий

Не начинайте с загрузки всего корпоративного диска. Выберите один процесс:

• поиск по эксплуатационным инструкциям;
• ответы службы поддержки;
• навигация по базе нормативных документов;
• поиск по технической документации;
• помощь сотрудникам по внутренним регламентам.

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

Источники и владельцы

Каждый набор документов должен иметь владельца. Он отвечает за актуальность, доступ и удаление устаревших версий.

Перед индексацией полезно зафиксировать:

• систему-источник;
• тип и классификацию данных;
• владельца;
• срок актуальности;
• правила доступа;
• период обновления;
• основание хранения;
• порядок удаления.

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

Права доступа должны дойти до поиска

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

Есть два распространённых подхода:

1. отдельные индексы для контуров доступа;
2. общий индекс с метаданными и фильтрацией ACL до передачи контекста модели.

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

Сервисная учётная запись индексатора не должна автоматически давать всем пользователям доступ ко всему, что она смогла прочитать.

Подготовка документов

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

При подготовке сохраняйте:

• заголовок и иерархию разделов;
• идентификатор документа;
• версию;
• дату действия;
• владельца;
• ACL;
• ссылку на исходный фрагмент;
• язык;
• тип содержимого.

Таблицы, схемы и сканы требуют отдельной обработки. Результат OCR необходимо проверять: ошибка в числе или отрицании способна изменить смысл ответа.

Поиск лучше строить гибридно

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

• полнотекстовый поиск;
• векторный поиск;
• фильтры по метаданным;
• повторное ранжирование;
• порог релевантности.

Если релевантных источников нет, система должна честно сообщить об этом. Генерация «на всякий случай» ухудшает доверие и затрудняет контроль качества.

Цитаты и проверяемость

Ответ должен содержать ссылки на конкретные фрагменты, а не только список документов внизу. Пользователь должен уметь:

• открыть источник;
• увидеть версию и дату;
• проверить цитируемый абзац;
• понять, какие данные использованы;
• сообщить об ошибке.

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

Защита от инструкций внутри документов

Документ может содержать текст, который модель воспримет как команду: раскрыть системный промпт, игнорировать правила или вызвать инструмент. Поэтому извлечённый контент нужно считать недоверенными данными.

Разделите:

• системные инструкции;
• запрос пользователя;
• найденные документы;
• результаты инструментов.

Не позволяйте тексту документа менять права, набор инструментов или политику выполнения действий. Эти меры продолжают подход из статьи о безопасной архитектуре ИИ-агентов.

Что журналировать

Для расследования и улучшения качества полезны:

• идентификатор запроса;
• пользователь и контур доступа;
• версии индекса и модели;
• найденные документы и оценки;
• применённые фильтры;
• итоговый ответ;
• отказ или fallback;
• оценка пользователя;
• время выполнения.

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

Как оценивать качество

Подготовьте набор реальных вопросов с ожидаемыми источниками и критериями ответа. Измеряйте:

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

Проверяйте не только лучшие примеры. В наборе должны быть неоднозначные вопросы, устаревшие документы, опечатки, одинаковые названия и запросы без ответа.

Эксплуатационный чек-лист

• Определён конкретный рабочий сценарий.
• У каждого источника есть владелец.
• Версии и сроки действия документов различимы.
• ACL применяется до передачи контекста модели.
• Пользователь видит источник и цитируемый фрагмент.
• При слабом поиске система отказывается от уверенного ответа.
• Документы считаются недоверенным содержимым.
• Есть тестовый набор и регрессия качества.
• Индекс обновляется и удаляет отозванные данные.
• Журналы не раскрывают лишнюю информацию.

Как можем помочь

«Лоджик Телеком» может помочь спроектировать контур загрузки данных, API-интеграции, права доступа и наблюдаемость корпоративного RAG. Начните с ограниченной базы документов, где известны владелец, пользователи и критерии правильного ответа.