Хороший ответ ещё не означает безопасный ответ
Корпоративный RAG может убедительно пересказать документ и всё равно провалить приёмку: сотрудник не имел права читать этот документ либо ответ пропустил важное исключение. Поэтому полезно разделять две задачи: допустимость найденных данных и качество вывода. Общая архитектура разобрана в материале о RAG для базы знаний; здесь сосредоточимся на проверках перед рабочим запуском.
Начните не с выбора модели, а с таблицы доступа. Для каждого типа документа укажите владельца, организацию, разрешённые группы, срок актуальности и источник прав. Затем определите, какой ответ допустим при отсутствии сведений или недоступности проверки полномочий. Такая таблица превращает расплывчатое требование «не показывать лишнее» в набор конкретных тестов.
Права должны проверяться до передачи контекста модели
Разбиение документа на фрагменты не отменяет его ограничения. Метаданные доступа должны сопровождать производные фрагменты, а разрешения проверяться при поиске. В руководстве OWASP по безопасности RAG отдельно описаны наследование прав, изоляция организаций и удаление производных данных. Поручать модели скрывать уже полученный секрет вместо серверной проверки нельзя.
В прикладной реализации удобно выделить один обязательный путь получения контекста. Он принимает подтверждённую сервером личность, определяет область поиска и возвращает только разрешённые фрагменты. Этим путём должны пользоваться обычный чат, экспорт ответа и повторная генерация. Отдельный «временный» маршрут без проверки быстро превращается в обход основной защиты.
Не доверяйте присланным браузером идентификаторам организации и групп. В документации Azure AI Search о security filters подчёркнуто, что строка с идентификатором в фильтре сама по себе не выполняет аутентификацию. Формирование доверенного фильтра является обязанностью приложения. Это важное различие между удобным механизмом поиска и полноценной системой авторизации.
Проверьте жизненный цикл доступа
Рассмотрим учебный сценарий: специалист временно получил доступ к договору, а затем перешёл в другой отдел. Новый запрос уже должен учитывать изменённые полномочия. Но старый фрагмент может остаться в истории диалога, кэше ответа или промежуточной подборке. Поэтому в плане испытаний нужна смена роли во время активной сессии, а не только вход разными пользователями с чистого браузера.
Для такого сценария заранее определите правила: как обновляются группы, когда инвалидируется кэш и можно ли продолжать диалог со старым контекстом. При необходимости начинайте новый контекст без отозванных материалов. Ранее увиденное человеком невозможно «забыть» технически, но система не должна повторно выдавать закрытые сведения. Журналы и трассировки тоже требуют ограниченного доступа.
Отдельно проверьте ссылку на первоисточник. Красивое название документа в ответе не гарантирует, что ссылка открывает правильную версию и повторно проверяет права. Пользователю без доступа нельзя раскрывать закрытый заголовок через подсказку, предварительный просмотр или сообщение об ошибке. Зафиксируйте допустимые формулировки отказа с владельцем информации.
Качество измеряется несколькими проверками
Документация Microsoft по оценке RAG разделяет качество извлечения контекста и качество итогового ответа. Соответствие источнику, релевантность вопросу и полнота не тождественны. Ответ может точно цитировать найденный фрагмент, но не отвечать на вопрос, или давать верное общее правило без существенного исключения.
Соберите собственный набор вопросов вместе с предметным специалистом. Для каждого запишите роль пользователя, разрешённые документы, нужные факты и недопустимые утверждения. Добавьте вопросы без ответа в базе, противоречащие версии инструкций, сокращения, опечатки и уточнения в середине диалога. Часть набора оставьте неизменной, чтобы сравнивать версии системы, а новые ошибки добавляйте отдельной группой.
Для оценки поиска отмечайте, попал ли необходимый разрешённый фрагмент в первые выбранные результаты. Для ответа проверяйте каждый значимый факт и его ссылку. Отдельно считайте ложные отказы: система не должна становиться «безопасной» за счёт отказа на любые вопросы. Автоматическую оценку другой моделью используйте как вспомогательный сигнал; спорные и чувствительные ответы должен проверять человек.
Чек-лист испытаний
- Задайте одинаковый вопрос сотрудникам разных отделов и организаций. Сравните не только текст, но и идентификаторы извлечённых фрагментов.
- Отзовите доступ между двумя сообщениями диалога. Проверьте новый ответ, повторную генерацию, кэш, историю и открытие источника.
- Замените инструкцию новой версией. Убедитесь, что система различает действующее правило и архив, а не выбирает удобную формулировку.
- Поместите в тестовый документ постороннюю инструкцию для ассистента. Проверьте, что она не меняет полномочия и не запускает внешние действия.
- Отключите поиск и сервис проверки прав по отдельности. Ожидайте понятный отказ или обозначенную недоступность, а не уверенную догадку.
- Проверьте состав служебных журналов. Для диагностики обычно полезнее идентификаторы, версии и причины решений, чем бесконтрольные копии закрытых документов.
Типичные ошибки и критерии приёмки
Типичные ошибки: тестировать только от имени администратора, оценивать всё одной средней цифрой и считать наличие ссылки доказательством ответа. Ещё одна ловушка: улучшить поиск за счёт ослабления фильтра доступа. Полезность и безопасность нужно улучшать вместе, а результаты показывать отдельно по ролям и классам вопросов.
Критерий доступа для согласованного тестового набора: ни один запрещённый фрагмент не передан модели или пользователю. Это необходимая проверка, но не математическое доказательство отсутствия всех утечек. Для качества установите пороги по классам риска, зафиксируйте ошибки и владельца повторной проверки. В проекте ИИ-ассистента такой протокол должен сопровождать обновления модели, индекса и правил доступа.
Короткий FAQ
Достаточно ли запрета в системном промпте?
Нет. Запрет помогает задавать поведение, но не заменяет проверку полномочий на сервере до получения закрытого контекста.
Какой процент правильных ответов считать хорошим?
Единого числа нет. Ошибку в навигационной подсказке и выдачу закрытого договора нельзя усреднять как равноценные события.
Когда повторять испытания?
После изменений модели, поиска, разбиения документов, схемы прав и кэширования. Дополнительно проверяйте новые типы документов и инциденты, обнаруженные пользователями.