Метаданные - это структурированные поля вокруг документа или chunk: источник, тип документа, дата обновления, автор, владелец, отдел, язык, продукт, регион, версия, статус, теги, уровень доступа, customer_id, project_id, valid_from и valid_until. Сам текст отвечает на вопрос "о чем документ", а метаданные отвечают на вопрос "какой это документ и можно ли его использовать".
В RAG metadata filtering обычно работает вместе с vector search, keyword search или гибридным поиском. Система сначала сужает область поиска фильтрами, затем ищет похожие фрагменты, либо наоборот: ищет кандидатов и отбрасывает неподходящие. Для прав доступа, клиентских данных и устаревших документов безопаснее применять фильтр до того, как текст попадет в контекст модели.
Это не замена semantic search. Semantic search ищет близкий смысл, а metadata filtering накладывает жесткие условия: дата больше 2026-01-01, doc_type = contract, status = approved, language = ru, access_level = internal. В хорошей системе используются оба подхода: смысловой поиск находит нужное, а фильтры не дают подмешать лишнее.
Главные риски - плохие метаданные и слишком жесткие правила. Если документ неправильно размечен, агент его не найдет. Если фильтров мало, в ответ может попасть старый, чужой или закрытый документ. Поэтому фильтры нужно логировать, проверять на evals и регулярно пересматривать вместе со схемой индекса.
Примеры
- AI-ассистент поддержки ищет ответ только в опубликованных статьях базы знаний по продукту CRM и региону RU.
- Юридический агент выбирает только документы с doc_type = contract, status = approved и access_level = legal.
- Внутренний поиск исключает регламенты, у которых valid_until уже прошел или updated_at старше заданной даты.
- Клиентский чат-бот фильтрует фрагменты по customer_id, чтобы данные одного клиента не попали в ответ другому.
- Workflow в n8n получает входящий документ, определяет отдел и ищет похожие инструкции только в разделе закупок на русском языке.
Где используется
- RAG по базе знаний компании
- внутренний поиск по документам
- контроль прав доступа к источникам
- разделение данных по продуктам, регионам и клиентам
- исключение устаревших документов из ответов
- поиск по типу документа: договор, регламент, отчет, ТЗ
- мультиарендные AI-приложения с tenant_id или customer_id
- снижение шума в retrieval
- ускорение поиска за счет меньшего набора кандидатов
- диагностика качества RAG и анализ неудачных ответов
Связанные термины
Частые вопросы
Чем metadata filtering отличается от semantic search?
Semantic search ищет фрагменты по смысловой близости к вопросу. Metadata filtering отбирает документы по структурированным полям: дате, источнику, статусу, правам, продукту, языку или клиенту. В RAG они обычно работают вместе.
Какие метаданные стоит хранить для RAG?
Минимальный набор: source, doc_type, title, owner, department, product, language, updated_at, status, access_level, tags и ссылка на оригинал. Для клиентских систем часто добавляют tenant_id, customer_id, project_id и срок действия документа.
Фильтровать нужно до или после векторного поиска?
Для прав доступа, клиентских данных и актуальности лучше фильтровать до поиска, чтобы закрытый текст не попал в кандидаты. Пост-фильтрация тоже бывает полезна для ранжирования, но она не должна быть единственной защитой.
Может ли metadata filtering ухудшить ответы?
Да. Слишком строгие фильтры или неверная разметка могут скрыть нужный документ. Поэтому нужно логировать примененные фильтры, смотреть случаи "ничего не найдено" и проверять качество на тестовых вопросах.
Как metadata filtering помогает с устаревшими документами?
В индекс добавляют поля status, updated_at, valid_from и valid_until. Затем агент ищет только в актуальных документах или явно предупреждает, что найденный источник устарел и требует проверки владельцем знания.
