{"componentChunkName":"component---src-templates-blog-post-js","path":"/blog/2026-09-01-metadata-filtering-rag-vector-search/","result":{"data":{"site":{"siteMetadata":{"title":"M.Hassan Ahmed","author":"Hassan11196"}},"markdownRemark":{"id":"6d99677f-e8e4-5f96-8abd-559f92d363f6","excerpt":"Most RAG bugs I have chased were not embedding-quality problems. They were filter problems. Someone asks the copilot about a transfer error at a specific site…","html":"

Most RAG bugs I have chased were not embedding-quality problems. They were filter problems. Someone asks the copilot about a transfer error at a specific site, and the answer quotes a fix from a different site two years earlier. Everyone concludes the retrieval is bad. It usually is not: the nearest vectors were fine. The system just failed to restrict the search to the rows that were actually relevant.

\n

This post is for engineers building retrieval on a vector store who need results scoped by structured attributes: a site, a date range, a document type, an access level. It covers:

\n\n

The running example is Archi, the retrieval copilot I worked on for CMS computing operations at CERN. There, “only entries from this site, this year” is part of almost every query.

\n

Why vector distance alone is not enough

\n

A vector index answers one question well: given this query vector, which stored vectors are closest? It knows nothing about where a chunk came from, such as a 2021 logbook for a different site. So once your data has structure (and operations data always does), you need to satisfy two constraints at once: close in embedding space and matches these attributes.

\n

The three strategies below differ only in when the engine applies the filter relative to the search. That ordering decides whether you get correct results, fast results, or neither.

\n

\"Three

\n

Strategy 1: post-filter, and why it fails quietly

\n

The tempting version, especially when you bolt a filter onto an existing search, is to run the vector query, take the top k, then throw away the rows that do not match. This is a post-filter, sometimes called filter-after-search. The query below is the kind that looks correct but behaves this way:

\n
-- pgvector: search first, filter the result set. Looks fine, isn't.\nSELECT id, body\nFROM chunks\nWHERE embedding <=> :query_vec < 1.0        -- distance, computed on ALL rows\n  AND site = 'T2_US_MIT' AND year >= 2024   -- filter applied to top-k output\nORDER BY embedding <=> :query_vec\nLIMIT 10;
\n

The failure mode is not an error. It is silent recall loss (recall being the share of truly relevant documents that come back). Here is how it happens:

\n
    \n
  1. Say site = 'T2_US_MIT' covers 3% of your corpus, and the query is generic enough that most of the closest vectors come from busier sites.
    2. \n
  2. The ANN search returns its ten nearest neighbors, and eight of them come from other sites.
    3. \n
  3. The filter removes those eight, leaving two rows.
    4. \n
  4. The genuinely relevant MIT document sat at rank fourteen. It was never fetched, so it never had a chance.
    5. \n
\n

You asked for LIMIT 10 and got two. Nobody sees a stack trace; you just see a worse answer.

\n

You can paper over this by over-fetching: request k = 200, filter down, and hope enough rows survive. But that is a guess, and the more selective the filter, the worse the guess gets. For a filter matching 0.1% of rows, you might fetch thousands and still come up short. Post-filtering is fine for a demo and a liability in production. Of the three options in the diagram, it is the one I would tell you never to ship.

\n

Strategy 2: exact pre-filter

\n

The opposite order is to filter first, then run an exact (brute-force) distance scan over whatever survives:

\n
-- Filter first, then score exactly on the subset.\nSELECT id, body\nFROM chunks\nWHERE site = 'T2_US_MIT' AND year >= 2024\nORDER BY embedding <=> :query_vec\nLIMIT 10;
\n

This is always correct. Every returned row matches the filter, and because the engine scores the whole subset exactly, you get the true nearest neighbors within it.

\n

The catch is cost. A brute-force scan is O(n) in the size of the filtered subset. If site = 'T2_US_MIT' AND year >= 2024 leaves a few thousand rows, scanning them is nothing, often faster than touching the ANN index at all. If your filter is loose and leaves several million rows, you compute millions of distances per query while the ANN index you built sits unused.

\n

So exact pre-filter is the right tool precisely when the filter is selective. Postgres knows this: with pgvector, if the planner estimates that the filtered set is small, it skips the vector index and does exactly this scan. The trouble starts in the middle ground, with filters that are neither tiny nor loose. That is where the third strategy earns its place.

\n

Strategy 3: filtered ANN, the one you actually want

\n

The strategy that scales pushes the filter into the ANN search itself, so the graph traversal only ever considers nodes that satisfy the predicate. The engine wastes no distance computations on rows it will discard, and it never brute-forces a huge subset.

\n

Why filtering an HNSW graph is hard

\n

This sounds obvious, and it is genuinely hard to implement well. HNSW is a navigable small-world graph: search works by greedily hopping to closer and closer neighbors. When you forbid most nodes, you tear holes in that graph.

\n

The path from the entry point to the best matching node may run through nodes that fail the filter. If the search cannot step on them, it cannot reach the destination. Recall collapses even though the matching node is in the index.

\n

The engines that do this well spend their effort on exactly this problem: staying connected while honoring the filter. Qdrant’s team wrote a good explanation of why filtered HNSW is not just “skip the bad nodes” and how they keep the graph traversable (filtrable HNSW). Research systems like ACORN attack the same problem by searching an expanded neighborhood, so the traversal can route around filtered-out nodes.

\n

How each engine exposes it

\n

The practical point: you do not implement this yourself. You use an engine that treats the filter as a first-class part of the query, and you verify its recall on your own data.

\n

pgvector (0.8+). Give the planner the filter alongside ORDER BY embedding <=> :query_vec. Iterative index scans then keep pulling from the HNSW index until enough rows pass the filter, instead of stopping at the first k (pgvector filtering docs). The query is the same as in Strategy 2; the SET line is what changes the behavior:

\n
-- pgvector 0.8+: iterative scan keeps reading the index until the\n-- filter is satisfied, rather than post-filtering a fixed k.\nSET hnsw.iterative_scan = 'relaxed_order';\nSELECT id, body\nFROM chunks\nWHERE site = 'T2_US_MIT' AND year >= 2024\nORDER BY embedding <=> :query_vec\nLIMIT 10;
\n

OpenSearch. The k-NN query takes a filter clause and applies it during the search rather than after. The engine decides between exact and approximate search based on how restrictive the filter is (efficient k-NN filtering). Archi’s retrieval runs on OpenSearch, which is why I keep coming back to it in these posts. The same index backs both the BM25 half of hybrid search and the metadata filters here. In the request below, notice that the filter sits inside the knn clause, not beside it:

\n
{\n  \"size\": 10,\n  \"query\": {\n    \"knn\": {\n      \"embedding\": {\n        \"vector\": [0.11, -0.04, \"...\"],\n        \"k\": 10,\n        \"filter\": {\n          \"bool\": {\n            \"must\": [\n              { \"term\": { \"site\": \"T2_US_MIT\" } },\n              { \"range\": { \"year\": { \"gte\": 2024 } } }\n            ]\n          }\n        }\n      }\n    }\n  }\n}
\n

Qdrant. The filter is a top-level part of the request. Usefully, Qdrant lets you build a payload index on the fields you filter by, so the predicate is cheap to evaluate during traversal (Qdrant filtering). The same site-and-year filter looks like this in the Python client:

\n
from qdrant_client import QdrantClient, models\n\nclient.query_points(\n    collection_name=\"chunks\",\n    query=query_vec,\n    query_filter=models.Filter(must=[\n        models.FieldCondition(key=\"site\", match=models.MatchValue(value=\"T2_US_MIT\")),\n        models.FieldCondition(key=\"year\", range=models.Range(gte=2024)),\n    ]),\n    limit=10,\n)
\n

Failure modes to know before they bite

\n

Selective filters quietly lower recall. Filtered ANN does not escape the connectivity problem. The more of the graph your filter removes, the more likely the traversal misses the true nearest matching node. When a filter gets extreme, matching well under 1% of rows, most engines fall back to exact search for that query, which is correct but slower. Know where your engine draws that line, because query latency will jump there.

\n

High-cardinality filters need their own index. Filtering on a field the engine must check candidate by candidate is slow. Build the field index so the predicate becomes a lookup, not a scan: a Qdrant payload index, an OpenSearch mapping with the field indexed, or a Postgres B-tree on site/year.

\n

Range filters on timestamps are the common trap. year >= 2024 is cheap. created_at BETWEEN two arbitrary instants across a huge table is not, unless the field is indexed and the engine can use it during traversal. In Archi, we filter on timestamps quantized to a year (and sometimes month) field instead of raw timestamps, and that made these queries predictable.

\n

Test recall; do not assume it. The only way to trust a filtered search is to measure it. Take a set of queries with known-relevant filtered documents and check how often they come back. That is the same retrieval-quality harness you would use for the unfiltered case, run with the filter on. If recall drops with the filter applied, suspect your engine’s filtered traversal, not your embeddings.

\n

What I would do differently

\n

Early on, I treated the metadata filter as a detail to add after the retrieval “worked.” That is backwards. On operations data, the filter is often the more important half of the query: an operator asking about their site does not want a semantically similar answer from someone else’s.

\n

If I were starting again, I would design the schema around the filters first:

\n
    \n
  1. Decide which fields get filtered.
    2. \n
  2. Index those fields.
    3. \n
  3. Quantize timestamps to something coarse and indexable.
    4. \n
  4. Only then tune the vector side.
    5. \n
\n

Getting the filter right removed more bad answers than any embedding-model swap I tried.

\n

If you are building retrieval for a system where scope matters (a specific tenant, site, product, or time window), reach for your engine’s filtered ANN path, index the fields you filter on, and measure recall with the filter applied. It is a small amount of plumbing that decides whether the copilot answers about the right thing. You can see how these pieces fit together in Archi and the rest of my AI and RAG work.

","frontmatter":{"title":"Metadata Filtering in RAG Vector Search","date":"2026-09-01T00:00:00.000Z","description":"Post-filtering vector search silently drops good results. Here is pre-filter vs filtered ANN for RAG, why filtered HNSW is hard, and how to choose.","thumbnail":{"childImageSharp":{"fluid":{"base64":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABQAAAALCAIAAADwazoUAAAACXBIWXMAAAsSAAALEgHS3X78AAAB30lEQVQoz02O666iMBRG+XMUW0oLlEuh5X4TFQV1xOPxGOPMZN7/iWaryWSSRfPt9lu0mlEPBGgGVPb+cKluf4qv38l0B2LgdE/Pj/q1CQFWsb/iagsKiBo2JYBIaFpJVozb4dZ2U92eVuvLcv3ZdFOznNbb66r/grHtzkm6o1aKydPSsB0TJ3OiJVcrJ1lZoiW8QHaC3Aw7GYaek8G4YDG2EygE7Z6JGiwYNUQl5bnIDkFxdI4XkR9lcQrzozNMbnMM4jHIDlxuqF9bfsPLHe9/ML+mXoWZesqIScOKMZOIJxDsoLb9ing5thQ0CFzCFNQwi007M1j8VF6AHGErhqcyr3LiFQ1q5leWX9mqs0QDGY4IzzBXBo9pWNAgx84zg6ghU8BtxC1d2cly5FEn0q1IelEMnloDpluZQUmLJuj3+fWeTle7WZO4fMoLUwCYiAUL55tRN8UMe3Pk6t1W9xIdefB3bEX0/El/Psj3t3m7sV8PUncLEmjwoRfYluk4RWEViSoMynA1hllHaQQFw5Fmt2G70T2d+OFI+x1J67fsv8E0VKIOo0apZSRbKSolW+rEOnYRCw1PmUHq5i1Pa8jYVaBouuH9Y4Zd4APxGXI/8JP5f6c69mYLDrwzrH8BI7BHFvWFfcIAAAAASUVORK5CYII=","aspectRatio":1.899441340782123,"src":"/static/1547a1eef22b6c181246160d46518c3d/40a76/hero.png","srcSet":"/static/1547a1eef22b6c181246160d46518c3d/c972b/hero.png 340w,\n/static/1547a1eef22b6c181246160d46518c3d/27625/hero.png 680w,\n/static/1547a1eef22b6c181246160d46518c3d/40a76/hero.png 1360w,\n/static/1547a1eef22b6c181246160d46518c3d/ed396/hero.png 2000w","sizes":"(max-width: 1360px) 100vw, 1360px"}}}}}},"pageContext":{"slug":"/2026-09-01-metadata-filtering-rag-vector-search/","previous":"blog/2026-08-29-circuit-breaker-llm-api-calls/","next":"blog/2026-08-31-continuous-batching-llm-serving/"}},"staticQueryHashes":["32046230"]}