Production RAG, including the multi-tenant kind.
Chunking, hybrid dense and sparse retrieval, reranking — and, where the product is multi-tenant, isolation enforced in the query layer rather than trusted to application code.
Retrieval is a systems problem
Most RAG that underperforms is not failing because the model is weak. It is failing because chunking destroyed the unit of meaning, because dense retrieval alone misses exact identifiers and rare terms, or because nothing reranks what came back. Hybrid retrieval plus a reranking pass fixes a surprising share of “the AI gives bad answers” complaints.
The corpus decides the strategy. Chunking that works for prose destroys tabular data and code. There is no default worth trusting without looking at what you actually have.
Multi-tenant isolation, done properly
If your product is multi-tenant, the retrieval layer is a data-boundary control, and it should be built like one. The tenant filter belongs in the query path as a non-optional constraint — driven by a verified claim such as a signed token, not by a parameter the calling code chooses to pass. Isolation that depends on every caller remembering to scope its query is not isolation; it is a convention waiting to be broken.
Where the data lives in Postgres, a disciplined tenant identifier on every row with row-level security as a backstop gives genuine separation without operating a database per customer. Where a vector store is in play, per-tenant namespaces plus tenant metadata as a mandatory filter does the equivalent job. Silo, pool and bridge are all defensible patterns; which one you need is a regulatory and operational question before it is a technical one.
One position I will state plainly: using the model itself for access control is an anti-pattern. Permissions are mirrored into retrieval metadata at ingestion and enforced as a hard filter at query time. A model asked to be discreet is not a security boundary.
Evaluating retrieval when you have no labels
Most teams do not have a golden set, and waiting to build a perfect one means never measuring anything. You can bootstrap: sample real queries, capture what was retrieved, and judge relevance on that sample to establish a baseline. Once a baseline exists, changes become comparable, which is the entire point.
Each with written acceptance criteria.
- Retrieval architecture: chunking, indexing, hybrid search, reranking
- Tenant-isolation design with enforcement in the query layer
- Retrieval evaluation harness and an established baseline
- Ingestion pipeline including permission mirroring where applicable
- Written acceptance criteria for each deliverable