Без фильтров RAG может найти текст, который семантически похож на запрос, но не подходит по контексту. Внутренний документ может попасть в ответ клиенту, старый регламент может перебить новый, данные одного tenant могут смешаться с другим, а черновик может быть использован как официальная инструкция.
Retrieval filter обычно работает по metadata: document_type, source, department, tenant_id, user_role, access_level, language, created_at, updated_at, status, product, region, version. Сначала документы правильно индексируют и сохраняют эти поля, потом при каждом запросе фильтр ограничивает область поиска.
Для ИИ-агента retrieval filters — это практический способ сделать RAG безопаснее и точнее. Агент не просто "ищет по базе знаний", а ищет в правильной части базы: с учетом прав доступа, задачи, канала, клиента и свежести информации.
Примеры
- Клиентский чат-бот ищет только в документах со статусом published и access_level=public, чтобы не показать внутренние инструкции.
- Сотрудник отдела продаж спрашивает про тариф. Фильтр ограничивает поиск по product, region и актуальной версии документа.
- В мультиарендной системе tenant_id не дает агенту достать документы другой компании.
- RAG для юристов ищет только договоры конкретного проекта и исключает архивные версии.
- Если запрос идет из поддержки, filter source=knowledge_base убирает черновики, заметки разработчиков и приватные документы.
Где используется
- Ограничивать RAG-поиск по правам пользователя и роли.
- Разделять документы разных клиентов, проектов или tenant.
- Исключать черновики, архивы и устаревшие версии документов.
- Фильтровать источники по типу: FAQ, регламент, договор, тикет, база знаний.
- Искать только в нужном языке, регионе, продукте или отделе.
- Снижать риск утечки внутренних данных в клиентский ответ.
- Улучшать точность retrieval за счет меньшей и более релевантной области поиска.
- Поддерживать цитирование только по проверенным источникам.
- Тестировать RAG через evals: правильно ли фильтр пропускает и блокирует документы.
Связанные термины
Частые вопросы
Чем retrieval filter отличается от retrieval guardrails?
Retrieval filter — это конкретное условие поиска, например status=published или tenant_id=123. Retrieval guardrails шире: это набор правил, проверок и fallback-сценариев вокруг всего retrieval-этапа.
Какие метаданные нужны для retrieval filters?
Минимально полезны источник, тип документа, статус, дата обновления, владелец, уровень доступа, tenant или клиент, язык, продукт и версия документа.
Можно ли добавить фильтры после индексации документов?
Иногда можно, но часто приходится переиндексировать документы, чтобы добавить недостающие metadata. Лучше проектировать схему метаданных до загрузки базы знаний.
Может ли фильтр ухудшить ответы?
Да, если он слишком строгий. Тогда retriever не найдет нужные источники. Поэтому фильтры нужно тестировать на реальных вопросах и проверять случаи, где источник должен быть найден.
Где применяются retrieval filters?
Они применяются в RAG, внутреннем поиске, агентах поддержки, корпоративных базах знаний, юридическом поиске, multi-tenant SaaS и системах с разными уровнями доступа.
