Click any words you think contain an error. Click again to unmark.
Mark at least one word to submit.
The bug is the order of operations. The code asks the index for the global top-k most similar chunks first, then filters that small list down to the ones belonging to this tenant. By the time the filter runs, k is already fixed.
Walk through what happens for a small tenant. The top-k is chosen across the entire corpus, so most of those slots get taken by other tenants' chunks that happen to be similar to the query. The filter then deletes them, and the caller is left with a handful — sometimes zero — even though the tenant has plenty of relevant chunks ranked just below the cutoff.
The fix is to pre-filter. Instead of filtering after the search, pass the tenant condition into the search itself. The vector store then ranks only chunks that belong to this tenant and can return a full k of valid, relevant results.
The principle: apply the eligibility predicate during ranking, not after it.
The error is post-filtering: the code retrieves the global top-k by similarity, then filters those k hits down to the matching tenant. Because k is fixed before the tenant check runs, the filter can only shrink the result, never refill it.
The failure is worst exactly where it matters most — a small tenant. If a tenant owns a thin slice of the corpus, the unconstrained top-k is dominated by other tenants' chunks that are semantically close to the query. The list comprehension drops all of those, so the caller receives far fewer than k results, often zero. Genuinely relevant in-tenant chunks sit just past the cutoff and never get a chance to rank.
The fix is to pre-filter: push the tenant predicate into the search so the index ranks only eligible documents. Modern vector stores support a filter argument for exactly this — index.search(vec, top_k=k, filter={'tenant_id': tenant_id}). Now the top-k is selected from within the tenant's own chunks, so it returns a full k of valid results.
This is also a correctness and isolation concern, not just a recall one. Post-filtering means the search engine briefly ranks across tenants; pre-filtering keeps the query scoped to the tenant's data from the start, which is the right posture for multi-tenant isolation.
Quick reference
TL;DR
The code fetches the global top-k then filters by tenant, so most hits are dropped and the caller gets fewer than k; push the tenant predicate into the search as a pre-filter.
Imagine asking a librarian for the five books most relevant to your question, but you only have a library card for the children's section. The librarian grabs the five best books from the entire building, then checks your card and hands back only the ones from the children's section — maybe one, maybe none. You're left short, even though the children's section is full of great books that would have answered you. The smarter move is to tell the librarian up front: 'only search the children's section.' Then every one of the five they pick is one you're allowed to read. This code makes the librarian's first mistake. It picks the best matches from everyone's data, then throws away the ones that don't belong to your tenant, instead of restricting the search to your tenant from the start.
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.
Each tenant owns a large majority of a small shared corpus Post-filtering rarely starves the result because most top-k hits already belong to the tenant; the bug may not surface, though it's still risky.
The filter predicate is extremely selective on a single shared HNSW index A naive in-query filter can wander ineligible nodes and hurt recall/latency; a per-tenant namespace or filterable index is the better structure.
Strong compliance isolation between tenants is required A metadata predicate on a shared index is weaker than physical separation; prefer per-tenant collections so cross-tenant data is never co-ranked.
The store has no efficient in-query filtering support Without filterable indexes you may be forced to overfetch or partition; just confirm the chosen approach still returns a reliable k.
Quick scan · 2–4 min
Everything important, quickly.
3-4 min: why post-filtering caps a small tenant below k, the operation-order walkthrough, the pre-filter fix, and the HNSW/namespace subtleties behind 'just add a filter'.
Real-world examples
Real products, models, and research that use this idea.
1A multi-tenant support assistant returning empty answers for small customers because metadata filtering ran after the top-k; moving the predicate into the query fixed it.
2Pinecone, Qdrant, Weaviate, and pgvector all expose in-query metadata filters precisely so eligibility is applied during ranking, not after.
3Large-tenant SaaS RAG using per-tenant namespaces/collections to both guarantee a full k and harden the isolation boundary.
Interviewer follow-ups
What an interviewer would ask next. Try answering before peeking at the approach.
QWhy isn't 'just set top_k very high and then filter' a real fix?
Sign in or go Pro to see the approach for this follow-up.
QHow does a metadata filter interact with an HNSW graph traversal?
Sign in or go Pro to see the approach for this follow-up.
QWhen would you choose per-tenant namespaces over a single filtered index?
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
Filtering metadata after the top-k search instead of inside it; the ranking is decided over the whole corpus, so a small tenant loses most of its k slots before the filter even runs.