[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"glossary-metadata-filtering::ru":3,"gloss-cluster-metadata-filtering::ru":20,"gloss-next-metadata-filtering::ru":9},{"slug":4,"category":5,"name":6,"definition":7,"meta_desc":8,"faq":9,"schema_markup":9,"related":10},"metadata-filtering","data-infra","Фильтрация по метаданным (Metadata Filtering)","Фильтрация по метаданным — это практика прикрепления структурированных атрибутов (метаданных) — таких как дата, категория, ID пользователя, флаг статуса, цена — к каждому вектору, хранящемуся в векторной базе данных, и последующего ограничения поиска по сходству так, чтобы учитывались только векторы, чьи метаданные соответствуют заданным условиям фильтра, наряду с самим ранжированием по семантическому сходству. Она отвечает на паттерн запроса, с которым чистый поиск по векторному сходству справиться не может: «найди фрагменты, наиболее похожие на этот вопрос, но только из документов, опубликованных после 2025 года и помеченных `product: enterprise`». Почему это важно для разработчиков AI\u002FSaaS: почти каждая реальная функция RAG или семантического поиска в этом нуждается. AI службы поддержки не должен показывать устаревшую статью, которая была заменена; многотенантное приложение никогда не должно возвращать данные другого клиента, независимо от того, насколько семантически похожими они кажутся; поиск на маркетплейсе должен сочетать «найти похожие товары» с «показать только те, что есть в наличии и дешевле $50». Векторное сходство само по себе не осведомлено ни об одном из этих ограничений бизнес-логики — оно знает только о смысле, а не о контроле доступа, актуальности или состоянии запасов, — поэтому фильтрация по метаданным является механизмом, который заново соединяет семантический поиск с реальными, структурированными ограничениями, которые действительно есть у каждого промышленного приложения. Как это работает: во время вставки\u002Fupsert каждый вектор хранится вместе с объектом метаданных (обычно JSON: `{\"category\": \"billing\", \"published\": true, \"date\": \"2026-03-14\", \"tenant_id\": \"t_88\"}`). Во время запроса приложение передаёт и вектор запроса, и выражение фильтра (синтаксис варьируется в зависимости от векторной базы данных — Pinecone использует синтаксис операторов в стиле Mongo, например `{\"tenant_id\": {\"$eq\": \"t_88\"}, \"date\": {\"$gte\": \"2026-01-01\"}}`; pgvector, будучи обычным Postgres, использует стандартные условия SQL `WHERE` наряду с `ORDER BY embedding \u003C=> $1`). Некоторые векторные базы данных применяют фильтр до ANN-поиска (предварительная фильтрация, которая может быть медленнее, если фильтр очень избирателен и индексу приходится искать усерднее, чтобы найти достаточно совпадений в узком подмножестве), в то время как другие применяют его после (постфильтрация, которая может вернуть меньше результатов, чем `top_k`, если слишком много лучших совпадений отфильтровывается) — этот компромисс зависит от конкретной реализации и стоит проверить в документации конкретной базы данных, когда точность важна. Практический пример: AI-поиск кандидатов на SaaS-платформе для вакансий встраивает резюме и позволяет рекрутерам искать на естественном языке («старший бэкенд-инженер с опытом Kubernetes»), но рекрутер должен видеть только кандидатов, согласившихся быть доступными для поиска и находящихся в его регионе найма. Запрос сочетает векторное сходство с фильтром: `{\"opted_in\": true, \"region\": {\"$in\": [\"EU\", \"UK\"]}, \"years_experience\": {\"$gte\": 5}}` — гарантируя, что возвращаемые семантически лучшие совпадения также являются единственными, которых рекрутер юридически и по контракту имеет право видеть.","Фильтрация по метаданным сужает векторный поиск до векторов с заданными атрибутами, сочетая семантическое сходство со структурированными фильтрами.",null,[11,14,17],{"slug":12,"name":13},"hybrid-search","Гибридный поиск (Hybrid Search)",{"slug":15,"name":16},"namespace","Пространство имён (Namespace)",{"slug":18,"name":19},"vector-store","Векторное хранилище (Vector Store)",[21,25,28,31,34,38,41,44,47,50,54,57],{"slug":22,"category":5,"name":23,"updated_at":24},"acid","ACID","2026-08-24T02:46:37+00:00",{"slug":26,"category":5,"name":27,"updated_at":24},"ann-search","ANN-поиск (приближённый поиск ближайших соседей)",{"slug":29,"category":5,"name":30,"updated_at":24},"backpressure","Обратное давление (backpressure)",{"slug":32,"category":5,"name":33,"updated_at":24},"batch-processing","Пакетная обработка (Batch Processing)",{"slug":35,"category":5,"name":36,"updated_at":37},"bm25","BM25","2026-08-24T02:46:38+00:00",{"slug":39,"category":5,"name":40,"updated_at":24},"cache","Кэш (Cache)",{"slug":42,"category":5,"name":43,"updated_at":24},"cap-theorem","Теорема CAP (CAP theorem)",{"slug":45,"category":5,"name":46,"updated_at":24},"change-data-capture","Захват изменений данных (CDC)",{"slug":48,"category":5,"name":49,"updated_at":24},"chroma","Chroma",{"slug":51,"category":5,"name":52,"updated_at":53},"chunk-overlap","Перекрытие фрагментов","2026-08-24T03:30:02+00:00",{"slug":55,"category":5,"name":56,"updated_at":24},"columnar-storage","Колоночное хранение",{"slug":58,"category":5,"name":59,"updated_at":24},"connection-pooling","Пулинг соединений (Connection Pooling)"]