РУКОВОДСТВО · ОБНОВЛЕНО 2026-10-21
Права доступа к документам в RAG: проверка до генерации
Порядок проверки доступа в базе знаний с несколькими пользователями, группами и организациями.
В RAG права доступа проверяют до того, как текст найденного документа попадёт в контекст модели. Просьба «не раскрывай чужие файлы» не заменяет авторизацию поиска. Сервер определяет пользователя и его группы, ограничивает доступную область, проверяет результаты и только затем собирает запрос. Такой порядок нужен и для документов, и для сохранённых ответов, цитат и общего кэша. Если проверить право не удалось, приложение должно прекратить выдачу этого источника, а не передать решение модели.
1. Свяжите документ с областью доступа
При загрузке сохраняйте организацию, владельца, группы или другой принятый в продукте способ авторизации. Свяжите каждый фрагмент с документом и его актуальной редакцией. Не превращайте текст документа в источник правил доступа: строка «разрешено всем» внутри файла не равна решению сервера. Для файлов из внешней системы определите, как обновляются права и что происходит при потере связи с источником. Отсутствие метаданных не должно автоматически означать публичный доступ.
2. Ограничьте поиск серверными условиями
Получайте идентификаторы пользователя и групп из проверенной сессии. Не принимайте список разрешённых организаций из свободного текста запроса. Поисковый сервис может поддерживать фильтры метаданных или отдельное применение ACL при чтении, но возможности конкретной конфигурации нужно подтвердить. Документация Azure AI Search описывает query-time enforcement как отдельный механизм с собственными условиями. Ваша архитектура должна понимать, на каком слое реально действует ограничение, а где хранится только описание права.
3. Проверьте кандидатов и дополнительные чтения
Перед сборкой контекста повторно проверьте актуальный доступ к найденным документам. Это помогает обработать отзыв разрешения после индексации или запоздалое обновление метаданных. Те же правила нужны при открытии полной страницы по цитате и при получении соседних фрагментов. Не отправляйте модели закрытый текст, рассчитывая позже удалить его из ответа. Даже краткий пересказ или подтверждение существования документа может содержать сведения, которые пользователь не должен получать.
4. Изолируйте кэш и проверьте отзыв прав
Кэш ответа должен учитывать область доступа или проходить повторную авторизацию перед выдачей. Совпадение вопроса двух пользователей не даёт права показать им один и тот же ответ с закрытыми источниками. Проверьте сценарии двух организаций, общего документа, исключения из группы, удаления файла и старой ссылки на цитату. Зафиксируйте время изменения прав и результат чтения после него. Для журналов также задайте правила: диагностический текст не должен превращаться в обход ограничений основной базы знаний.
Частые вопросы
Можно ли фильтровать только готовый ответ?
Этого недостаточно: закрытые данные уже окажутся в контексте модели. Авторизация должна ограничивать источники до генерации.
Нужен ли отдельный индекс каждой организации?
Это зависит от масштаба и хранилища. Изоляция может использовать разные механизмы, но выбранный способ нужно проверить на реальном чтении и обновлении прав.
Что делать при недоступной системе разрешений?
Не выдавать документы, право на которые не удалось подтвердить. Пользователю можно показать ошибку или ответ только по доступным источникам.
Чем это отличается от prompt injection?
Prompt injection пытается изменить поведение через содержимое. Авторизация определяет, какие данные вообще можно читать. Нужны обе независимые проверки.