What problem does LlamaIndex's `RouterQueryEngine` solve that a single `QueryEngine` cannot?

A `QueryEngine` in LlamaIndex retrieves and synthesizes over one Index. Typically a vector index, sometimes a summary or SQL index. It is great when every query needs the same kind of retrieval. Real workloads do not always look like that. Some questions need a summary of a whole document. Some need a lookup over structured data. Some need semantic search over chunks. One Index cannot serve all three well. A vector index is bad at summarisation, a summary index is bad at lookup, a SQL index does not handle free-form semantic queries. `RouterQueryEngine` solves this by wrapping multiple QueryEngines (one per shape of question) plus a Selector. For each incoming query, the Selector picks the sub-engine best suited to answer it and forwards the query. The user sees one entrypoint; behind it, three completely different retrieval strategies run depending on what the question needs. The other three options describe optimisations to a single retrieval path, batching, caching, re-ranking, that are handled by different LlamaIndex primitives (ingestion config, retriever wrappers, NodePostprocessors), not by RouterQueryEngine.

**RouterQueryEngine is a multi-index dispatch primitive.** It wraps a list of QueryEngines, each backed by an index suited to a different question shape (summary, vector, SQL, keyword), plus a Selector that picks one of them per query. **Why it exists.** A single Index has a sweet spot. A vector index over chunks is great for 'what does the author say about X' semantic search but bad for 'summarise this document' (chunks lose document structure) and bad for 'how many rows match X' (no structured query surface). A summary index is great for whole-document questions but loses fine-grained retrieval. A SQL index handles structured queries but cannot do free-form semantic search. RouterQueryEngine lets one application surface three or four Indexes behind one entrypoint and dispatch correctly. **How the Selector works.** Two common implementations: LLM-based (the classifier reads the query and picks an engine by name, often with a chain-of-thought rationale) and embedding-based (the query is embedded and compared to descriptions of each sub-engine). LLM-based is more flexible and more expensive; embedding-based is faster and cheaper but less nuanced. **Why the distractors are wrong.** Batching identical queries is an ingestion or caching concern; LlamaIndex handles it via the underlying vector client. Caching retrieved Nodes is a NodePostprocessor or wrapper concern. Cross-encoder re-ranking is a NodePostprocessor (`SentenceTransformerRerank`, `CohereRerank`). All three are optimisations on a single retrieval path; only the correct option describes choosing among paths.