A vector index supports post-filtering: for a query with a metadata filter such as department = 'legal', it first runs an approximate nearest-neighbor search to find the top-k candidates by similarity alone, and only afterward discards any of those candidates whose metadata does not match the filter. For a query whose filter matches only a tiny fraction of the total documents, this approach can return far fewer than k results even though plenty of matching documents exist elsewhere in the index. What causes this shortfall, and what is the general alternative that avoids it?
- The approximate nearest-neighbor search itself is broken, so the fix is to replace it with an exact, brute-force search that still applies the filter only after retrieving its top-k results
- The vector embeddings are miscalibrated for filtered fields, so the fix is to embed each document's metadata directly into the same vector used for its semantic content
- This is expected behavior with no available fix, so applications should only ever use filters broad enough to match at least half of the index
- Because the similarity search collects only a fixed-size pool of top-k candidates before any filtering happens, a filter that matches only a sparse subset of the index causes most of that fixed pool to be discarded, leaving too few results; pre-filtering avoids this by restricting the candidate set to metadata-matching vectors before or during the similarity search itself, so the search only ever ranks documents that could pass the filter in the first place
Why D? And why not the others?
Correct answer: D. Because the similarity search collects only a fixed-size pool of top-k candidates before any filtering happens, a filter that matches only a sparse subset of the index causes most of that fixed pool to be discarded, leaving too few results; pre-filtering avoids this by restricting the candidate set to metadata-matching vectors before or during the similarity search itself, so the search only ever ranks documents that could pass the filter in the first place
The shortfall comes from the order of operations: post-filtering first fixes the candidate pool at a small, constant size (the top-k by similarity) and only afterward removes candidates that fail the metadata filter, so when the matching subset is a sparse fraction of the whole index, most of that fixed-size pool gets thrown away, leaving too few results even though many matching documents exist elsewhere; pre-filtering fixes this by narrowing the set of vectors the similarity search is allowed to consider, either before the similarity search runs or woven directly into the search's own traversal, so every candidate the search finds already satisfies the filter. The option proposing an exact brute-force search is wrong because switching from approximate to exact search does not change the fact that only a fixed-size top-k pool is retrieved before filtering is applied; the same shortfall would recur. The option proposing embedding metadata directly into the semantic vector is wrong because mixing a categorical field into the same continuous space used for meaning would distort the semantic similarity the embedding is meant to capture, rather than fixing how filtering interacts with candidate pool size. The option declaring the situation unfixable is wrong because a real alternative, pre-filtering, exists, and pushing the burden onto applications to only ever write broad filters is both inaccurate and impractical for real use cases that genuinely need narrow ones.
Source: Pinecone, 'The Missing WHERE Clause in Vector Search,' https://www.pinecone.io/learn/vector-search-filtering/