RAG Retrieval Routing: Which Evidence Path to Choose
RAG retrieval routing should choose the evidence path most likely to answer the specific question accurately, using the least unnecessary retrieval work. In practice, route by evidence needs: use structured data for exact records and numbers, keyword search for precise terms, semantic search for paraphrases, and a combination when the question needs both.
What retrieval routing means
Retrieval-augmented generation (RAG) systems retrieve relevant information and provide it to a language model as evidence for a response. Retrieval routing is the decision about where and how to search before that response is generated. A route might select a document collection, a search method, a metadata filter, or a sequence of retrieval steps.
Routing is not the same as choosing the final answer. It selects a way to find evidence. A sound system also checks whether the returned material is relevant, sufficient, and current enough for the question. If it is not, the system should search another path, ask for clarification, or say it cannot substantiate an answer.
Match the path to the evidence
Different questions call for different kinds of evidence. The most useful route depends on what the answer must establish, not merely on the wording or length of the query.
- Structured lookup: Choose a database, API, or other structured source for exact values, statuses, and records. “How many open tickets are assigned to team A?” is a query for current records, not a paragraph that happens to mention a count.
- Keyword or lexical search: Use it when exact terms matter, such as a product code, clause number, error message, or distinctive name. Lexical methods such as BM25 rank documents partly by matching query terms.
- Semantic search: Use embeddings and vector similarity when relevant material may express the same idea in different words. A query about “ending a subscription” may match a passage titled “cancel your plan.”
- Hybrid search: Combine lexical and semantic results when both exact identifiers and conceptual relevance matter. The system can merge or rerank candidates, but should not assume either list is complete.
- Specialized evidence path: Route to a source designed for the task, such as a policy collection, documentation set, or approved calculation service, when its authority and data model fit the question.
For example, “What does clause 8.2 require?” favors exact-term search in the relevant policy version. “What is the process for closing an account?” may favor semantic search across help documents. “What is the account’s current status?” needs a live record lookup if one is available and authorized.
How a router makes the choice
A retrieval router can use simple rules, a trained classifier, a language model, or a combination. The choice need not be elaborate: a small set of reliable routes with clear conditions can outperform a complicated router that is difficult to evaluate.
- Identify the task and evidence type. Distinguish questions about a specific record, a definition, a procedure, a comparison, or a current fact.
- Apply access and source constraints. Exclude collections the user is not allowed to access, and prefer sources with the appropriate authority or freshness.
- Search the likely path. Use exact lookup, lexical search, semantic search, or a hybrid according to the evidence need.
- Check retrieval quality. Examine whether the results actually address the question, cover all requested parts, and come from suitable sources.
- Escalate or stop. Try another route when evidence is weak; stop and communicate uncertainty when no route provides adequate support.
Some systems make this decision once. Others use staged retrieval: a broad first search, followed by a targeted search for missing details. The latter can help multi-part questions, but extra rounds cost time and can introduce irrelevant material if they are not controlled.
Choosing a routing strategy
Start with the simplest strategy that meets the application’s accuracy, latency, and maintenance needs. A fixed route is appropriate when the question type and source are predictable. Rules are useful for reliable signals such as a known identifier or a request for a current status. A classifier or model-based router may help when queries vary widely, but its decisions need evaluation and a safe fallback.
- Use explicit rules for stable, high-confidence distinctions: a ticket number goes to the ticket store; a quoted error string goes to exact search.
- Use classification when there are several recurring intents and labeled examples can represent them.
- Use confidence-aware routing when a wrong path is costly. Low confidence can trigger a second search or a clarification question.
- Use parallel search selectively when missing evidence is riskier than the added latency and compute. Limit and rerank the candidates rather than sending every result to generation.
Evaluate routes on representative questions, including paraphrases, ambiguous queries, rare identifiers, and questions whose answers are absent from the corpus. Measure retrieval quality separately from answer quality. Useful checks include whether relevant passages appear near the top, whether the chosen source is appropriate, and whether the final response is supported by retrieved evidence. A system that retrieves a plausible but outdated document may score well on relevance while still failing the task.
Common routing failures
A frequent mistake is treating semantic similarity as proof of relevance. Similar wording does not guarantee that a passage answers the question, and vector search can miss exact codes or numbers. Conversely, keyword search can fail when a document uses different phrasing. Hybrid retrieval helps with this tension but still needs ranking and evidence checks.
Other problems include routing to stale or incomplete indexes, searching the wrong tenant or document collection, applying filters too narrowly, and sending too many weak passages to the generator. Filters should reflect the user’s actual scope, and data freshness should be visible where it affects the answer. Retrieval cannot recover evidence that was never indexed or that the user cannot access.
Do not route solely on surface cues such as query length. A short question can require broad research, while a long question may contain one exact identifier. Nor should a router quietly fall back to an unrelated source when the preferred collection is unavailable. It should report the limitation or use a documented alternative.
Trade-offs and practical safeguards
More search paths can improve coverage, but they add complexity, latency, and opportunities for conflicting evidence. Structured lookups are precise when the schema and data are correct, but they do not answer open-ended questions by themselves. Semantic search handles varied wording, but similarity scores are not calibrated guarantees. Hybrid approaches broaden recall, while reranking can improve ordering at additional processing cost.
Keep routing observable: log the selected path, filters, retrieval outcome, and fallback reason while respecting privacy and access controls. Test changes against a fixed evaluation set, and review failures by category rather than tuning to a single aggregate score. If a question depends on current or authoritative information, make source freshness and provenance part of the route and the response.
Frequently Asked Questions
Should a RAG system always use hybrid search?
No. Hybrid search is useful when exact terms and paraphrases both matter, but adds components to configure and evaluate. A focused lexical, semantic, or structured route may be better for a clearly defined task.
When should retrieval routing use a database instead of a vector store?
Use a database or API when the answer depends on exact structured fields, filters, aggregation, or current records. Use a vector store for finding conceptually related text. Some applications need both.
Can an LLM decide which retrieval path to use?
It can classify a query or choose from supplied tools, but the choice should be constrained, logged, and tested. For predictable cases, explicit rules may be simpler and more reliable.
What should the system do when no route finds good evidence?
It should not invent an answer. It can try a permitted alternative route, ask a focused clarifying question, or state that the available evidence is insufficient.
How can I tell whether routing is working?
Test representative queries and inspect both the selected route and retrieved evidence. Track whether relevant, authoritative passages are found and whether answers are supported, including cases with missing or conflicting evidence.
Related
Method: the standard formula for this calculation, rounded as each result states. See how the calculators work or report an error.