How do you implement multi-index RAG where different qu...

Rather than one shared index for every kind of content, multi-index RAG splits the knowledge base by domain — products, policy, finance, engineering, news — because each has different needs: different optimal chunking and embedding choices, different update cadences, and often different audiences. A router in front of retrieval, whether an LLM classifier, a keyword rule set, or an embedding-similarity match against index descriptions, decides which index or combination of indices a given query should hit, and for queries that genuinely span domains it can fan out to multiple indices and merge the reranked results before generation.

The detail worth highlighting is that this router doubles as an access-control mechanism. Because routing decisions happen at query time rather than only at ingestion time, the same architecture that improves retrieval quality also enforces who’s allowed to see what — a query can be scoped to only the indices its user has permission to access, checked live rather than relying on documents simply not being uploaded in the first place.