Multi-query versus decomposition: how do these query transforms raise recall on hard questions?

Both techniques exist because a single embedding of the user's question can miss the right chunks. If the phrasing is awkward or the question asks for several things, the one query vector lands in the wrong neighborhood and the relevant chunk falls just outside the top-k. Multi-query attacks phrasing risk. You ask an LLM to rewrite the question several different ways, retrieve for each rewrite, and combine all the hit lists into one pool. If any phrasing matches the right chunk, it makes it into the pool. This is for a single information need expressed in different words. Decomposition attacks multi-part questions. You split a question like "compare X and Y" into separate sub-questions, retrieve for each one independently, and gather the results. Each distinct fact gets its own targeted search instead of competing inside one blurred query. Use multi-query when the question is one need but the wording is risky. Use decomposition when the question genuinely bundles several needs. Both cost extra retrieval calls and latency, and both produce overlapping results, so you have to deduplicate before the chunks reach the LLM.

Both transforms exist to fix the same weakness: a single query embedding is brittle. Phrasing, vocabulary mismatch, or a many-part question can push the relevant chunks just outside the top-k. The shared fix is to issue more than one retrieval and merge. **Multi-query** generates several paraphrases of one question, retrieves for each, and unions or fuses the hit lists. A chunk that matches any phrasing makes the pool, so it widens recall for a single information need expressed in different words. It does nothing to separate distinct facts — every rewrite is still asking the same thing. Decomposition is the opposite move. It splits a genuinely multi-part question into sub-questions and retrieves for each separately, so each distinct fact gets its own targeted search rather than competing inside one blurred query vector. A comparison or a multi-hop chain is the canonical case. The selection rule follows from the failure they address. Use multi-query when the question is one need but vocabulary or phrasing is the risk. Use decomposition when the question bundles several needs that one query cannot cover. Both raise recall at the cost of extra retrieval calls and latency, and both produce overlapping hit lists, so you must deduplicate before the chunks reach the LLM. Reciprocal rank fusion is the usual way to merge multiple ranked lists into one.