How do you scope retrieval with metadata filtering and multi-tenancy?
323 views
48 of 83
1
The problem
Question presented to candidate:
"We are turning our RAG assistant into a B2B product: many customer companies, and inside each one, documents only some employees may see. How do you make sure retrieval only ever returns chunks the current user is allowed to see, and stays fast for both our biggest and our smallest customers?"
What a strong answer should cover:
Store tenant ID, access groups and useful attributes (document type, language, date) as metadata on every chunk, and apply them as a filter inside the retrieval query; the model can only leak what retrieval puts in its context, so the prompt is never the security boundary
Post-filtering an approximate nearest-neighbour result (fetch top k, then drop rows) can return few or zero results for a small tenant; pre-filtering, filter-aware index search or an iterative scan (pgvector 0.8.0 added hnsw.iterative_scan) fix it, and very small filtered sets can simply be scanned exactly
Isolation models and their trade-offs: one shared index with a tenant filter, a partition or namespace per tenant, or a separate index or database per tenant; isolation strength, operations overhead, noisy neighbours, offboarding deletes and cross-tenant queries
The filter is built on the server from the authenticated session, never from request fields or model output; missing permission metadata means deny; permission changes must reach the index, ideally checked again against the source of truth before use
Everything downstream inherits the scope: caches keyed per tenant, rerankers and logs receiving only filtered text, and tests that try to read another tenant's data
Clarifying questions expected:
How many tenants, and how uneven are they in size?
Is per-document access control needed inside a tenant, or only tenant-level separation?
Are there contractual or regulatory isolation requirements, such as data residency or separate encryption keys per customer?
Code / implementation expected: Optional โ a filtered vector query (SQL with a tenant predicate, or a vector DB filter) built from the session, plus an explanation of post- versus pre-filtering.
metadata-filtering
multi-tenancy
security
rag
2
Try it yourself
Sketch your approach before you read the solution. That is what the interview tests.
Stuck? Get a hint.
A short nudge toward the approach. It will not give the answer away.
3
Solution
Target Audience: Engineers putting RAG into a multi-customer (B2B) product, or into a company where not every employee may read every document.
Difficulty: Medium
Verified with: Node 22.22.0 and Python 3.12.3 (the filtered-search and authorization simulation below). Vector database behaviour is cited from vendor documentation with the date checked (October 2026); the SQL snippets are labelled "not run here".
How to read this doc: Every idea is explained in plain language first, then tagged with ๐ Interview term: so you also learn the words an interviewer expects. All program output shown was produced by actually running the example; the Verified section quotes it in full.
1. Why This Even Matters โ A Story First
A shared office building has one mail room for forty companies. The clerk is fast and helpful: ask for "the latest contract" and you get it in seco
The solution is hidden so you can try first
16 min read ยท 12 sections
4
Read the code
Post-filter vs pre-filter vs iterative scan, and a filter built from the session