В RAG-системе модель отвечает не только на основе своих знаний, но и на основе найденных фрагментов: инструкций, договоров, регламентов, тикетов, страниц базы знаний. Если retriever достал неправильный источник, модель может ошибиться. Если достал документ, к которому пользователь не имеет доступа, появляется риск утечки данных. Поэтому поиск тоже нуждается в guardrails.
Retrieval guardrails могут проверять права доступа, тип документа, дату актуальности, источник, уровень конфиденциальности, язык, tenant, отдел, статус публикации и качество совпадения. Например, сотрудник поддержки не должен получить HR-документ, клиент не должен увидеть внутреннюю инструкцию, а агент не должен отвечать по черновику, который еще не утвержден.
Хорошие retrieval guardrails не заменяют безопасность на уровне базы данных, но добавляют слой контроля в AI-пайплайне. Они помогают отвечать только по разрешенным источникам, добавлять цитаты, блокировать сомнительный контекст, логировать найденные chunks и передавать вопрос человеку, если надежного источника нет.
Примеры
- Пользователь спрашивает про зарплаты, но у него нет доступа к HR-документам. Retrieval guardrails отфильтровывают эти chunks до передачи в LLM.
- В базе есть старая инструкция 2023 года и новая инструкция 2026 года. Guardrail запрещает использовать устаревшие документы, если есть актуальная версия.
- Клиентский чат-бот может отвечать только по публичной базе знаний, а внутренние runbooks и заметки поддержки не попадают в контекст.
- Если top-k вернул фрагменты с низкой похожестью, система не заставляет модель гадать, а просит уточнить вопрос или передает его оператору.
- Каждый найденный chunk логируется вместе с пользователем, запросом и ответом, чтобы можно было проверить, почему агент сослался на конкретный источник.
Где используется
- Защищать документы с разными уровнями доступа в RAG-системе.
- Не передавать модели черновики, архивные документы и непроверенные источники.
- Ограничивать поиск по tenant, отделу, роли, проекту или клиенту.
- Фильтровать найденные chunks по дате актуальности и статусу публикации.
- Блокировать ответы, если retriever не нашел надежный источник.
- Добавлять обязательные цитаты и ссылки на использованные документы.
- Логировать retrieval trace для аудита и разбора ошибок.
- Снижать риск утечки персональных, коммерческих и внутренних данных.
- Тестировать RAG через evals: находят ли guardrails правильные источники и блокируют ли запрещенные.
Связанные термины
Частые вопросы
Чем retrieval guardrails отличаются от обычных guardrails?
Обычные guardrails часто проверяют ввод, вывод или действия агента. Retrieval guardrails работают на этапе поиска: они контролируют, какие документы можно достать и передать модели.
Зачем нужны retrieval guardrails, если есть ACL?
ACL задает права доступа, но RAG-пайплайн должен применять эти права при поиске. Retrieval guardrails помогают не забыть фильтры, проверить источник, актуальность и качество найденного контекста.
Какие фильтры самые важные?
Обычно важны роль пользователя, tenant или клиент, уровень конфиденциальности, статус документа, дата актуальности, тип источника и минимальный порог релевантности.
Что делать, если подходящих источников нет?
Лучше не заставлять модель отвечать наугад. Система может попросить уточнение, показать, что источник не найден, или передать вопрос человеку.
Как проверить качество retrieval guardrails?
Нужны тестовые запросы: разрешенные, запрещенные, пограничные и провокационные. Для каждого проверяют, какие chunks найдены, какие отфильтрованы и был ли ответ заблокирован.
