The answer is **post-filtering**, and the reason is the order of operations.
Metadata filtering means restricting retrieval by structured fields, like 'only documents from 2024' or 'only files this user can access.' There are two ways to combine that with vector similarity.
**Pre-filtering** applies the metadata predicate first, narrowing the search to eligible documents, and only then ranks those by similarity. Because it ranks inside the allowed set, it can return a full k of valid matches.
**Post-filtering** does the opposite. It ranks the top-k by similarity first, then deletes any of those that fail the predicate. If the filter is selective, most of the top-k can get deleted, leaving you with fewer than k — sometimes zero, even when plenty of matching documents exist further down the ranking.
That is why option A is correct. Options B and C describe pre-filtering but swap the steps, so they are wrong. Option D claims both always return exactly k, which is exactly the failure mode post-filtering does not avoid.
**Post-filtering** is the approach that can leave you with fewer than k results.
The two strategies differ only in order. **Pre-filtering** narrows the candidate set by the metadata predicate first, then runs similarity ranking over only the eligible documents. Since ranking happens inside the allowed set, it returns a full k of valid matches.
Post-filtering retrieves and ranks the top-k by similarity first, then strips out the rows that fail the predicate. When the filter is selective relative to that top-k slice, most rows get removed and you are left with fewer than k, sometimes zero. Matching documents may exist deeper in the ranking, but the top-k slice never looked there.
That is the trap in option A and the reason D is false: results are not guaranteed to equal k. Options B and C describe pre-filtering but reverse its steps, claiming pre-filtering shrinks results or discards high-similarity matches; neither is how it works.
The practical nuance is that pre-filtering is correct on result count but can be harder to make fast. Filtering before an approximate nearest neighbor search can break the index's assumptions unless the engine supports filtered ANN. So the real engineering choice trades post-filtering's count risk against pre-filtering's index-integration cost.
Quick reference
TL;DR
Post-filtering ranks the top-k first then drops non-matching rows, so a selective filter can leave fewer than k results; pre-filtering ranks within the eligible set and returns a full k.
Imagine looking for the 10 closest restaurants to you, but you only want ones open right now. Pre-filtering is like telling the map 'show only open places, then pick the 10 nearest.' You always get 10. Post-filtering is like asking for the 10 nearest of anything, then crossing out the closed ones. If 8 of your 10 happen to be closed, you are left with just 2. Same idea with metadata in a search system: filter before you count, and you keep a full basket; filter after you count, and a strict rule can empty most of it.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example. Click to expand.
Everything you need to truly understand this topic: intuition, mechanics, step by step explanation, code, formulas, and worked example.
Post-filtering on a hard access-control predicate in multi-tenant retrieval. A selective tenant or permission filter can leave a user with near-zero results while their eligible corpus is large; this needs pre-filtering or filtered ANN, not post-filtering.
Pure pre-filtering on a naive HNSW index with a moderately selective filter. Removing nodes before traversal can disconnect the graph and silently drop recall; you need an engine with filtered-ANN support instead.
Any filtering strategy when the metadata is not indexed at all. Without an index on the metadata column the predicate forces a full scan per query, so latency collapses at corpus scale regardless of filter order.
Quick scan · 2–4 min
Everything important, quickly.
State the order of operations for each strategy and why post-filtering under-returns when the predicate is selective. Give the per-tenant example. Then lift to the production nuance: pre-filtering is correct on count but interacts with ANN indexes, and filtered ANN is the modern resolution. Close by framing it as a three-way trade rather than a binary.
Real-world examples
Real products, models, and research that use this idea.
1Pinecone, Weaviate, and Qdrant all ship metadata-filtered ANN search precisely so a selective filter does not under-return like naive post-filtering.
2pgvector with a B-tree index on a metadata column supports pre-filtered similarity search inside Postgres for hybrid app stacks.
3Per-tenant access control in multi-tenant RAG is the canonical case where post-filtering silently under-returns and pre-filtering is mandatory.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy can naive pre-filtering hurt recall on an HNSW index, and how is that resolved?
Sign in or go Pro to see the approach for this follow-up.
QHow would you decide between pre-filtering and a full scan when a filter is extremely selective?
Sign in or go Pro to see the approach for this follow-up.
Don't say this
Red flags and common mistakes that signal junior thinking. Click to expand.
Most common mistake
Assuming you always get k results back. Post-filtering can return fewer than k — even zero — whenever the metadata predicate is selective relative to the top-k similarity slice.