# Day 22: Why one user question may need many searches

Users do not ask questions the way documents answer them.

Someone types "is this tool actually worth it?" Your knowledge base holds a pricing table, a feature comparison, and three case studies. Not one of them resembles that sentence, semantically or lexically, and a single retrieval pass returns something disappointing.

Multi-query retrieval attacks that mismatch directly: take the one vague question, generate several sharper ones ("pricing tiers," "feature comparison versus alternatives," "customer outcomes") search each independently, then merge and deduplicate.

## The component you just added

Here is the part that gets skipped in the architecture diagram: **you now have a rewriter, and the rewriter is a model making silent judgement calls about what your user meant.**

When retrieval mysteriously fails on questions that should have worked, the cause is frequently a rewrite nobody ever looked at. Too narrow, so the good documents fell outside all four variants. Too clever, so it answered a more interesting question than the one asked. Or subtly off-intent in a way that is obvious the moment you read it and invisible if you never do.

So the first operating rule is unglamorous: **log every generated variant alongside the original query.** Rewrites you cannot inspect are failures you cannot diagnose, and they will present as "retrieval is flaky."

## Controlling the fan-out

The cost of this pattern hides well. It does not appear as an architecture problem; it appears as a slow, expensive answer, which teams tend to attribute to the model.

Multiply it out: four variants, each retrieving twenty candidates, each reranked. That is one user question consuming four retrieval calls, eighty candidate evaluations, and a merge, versus one call for a simple lookup.

Three controls worth having from the start:

- **Cap the variants.** Four good rewrites beat ten mediocre ones, and the tail adds cost without adding coverage.
- **Route by need.** Specific questions with clear terms should skip expansion entirely. Fanning out "what is our office address" is pure waste.
- **Attribute the win.** Track which variant produced the evidence that ended up cited. If variant four never contributes across a thousand queries, stop generating it.

## The test worth running

Take a deliberately broad question and watch the whole fan-out: the variants generated, what each returned, and what actually reached the final answer.

You are checking one thing, did the extra searches find evidence the single search would have missed, or did they find the same documents four times and bill you for the privilege?

Both outcomes are common. Only one justifies the pattern.

## Closing thought

One question can genuinely need many searches. It can also just need one good one. Multi-query retrieval is a real fix for vocabulary mismatch and a real way to quadruple your retrieval bill for nothing, and which you have built is an empirical question, not a design preference.

*Day 22 of 60 Days of Production AI Systems.*

---

**Previous:** [Day 21: Why RAG needs both broad context and precise evidence](https://blog.vamsiannamreddy.com/day-21-why-rag-needs-both-broad-context-and-precise-evidence)  
**Next:** [Day 23: Why complex AI questions need decomposition](https://blog.vamsiannamreddy.com/day-23-why-complex-ai-questions-need-decomposition)  

*Day 22 of 60 · Evidence-Driven RAG Patterns (chapter 4 of 10)*