Why does my search miss documents that obviously answer the question?
Because the user wrote one thing and the document says another. Someone asks "why is my bill so high" and the document is titled "Understanding overage charges", sharing not a single content word. Lexical search scores that at zero. Dense embeddings do better because they match meaning, and they still degrade when the query is short, vague, full of pronouns, or written in a register the corpus never uses.
Query preprocessing fixes this before retrieval runs, by changing the query rather than the index. Four techniques dominate, and they trade latency for recall in different amounts: rewriting cleans the query up, expansion adds terms to it, HyDE replaces it with a hypothetical answer, and multi-query fans it into several searches at once. None of them improve a corpus that simply lacks the answer.
Which technique should I use?
| Technique | What it does | Cost | Best when |
| Rewriting | Rewrites the query into a standalone, well-formed one | 1 LLM call | Conversational search, pronouns, follow-ups |
| Expansion | Adds synonyms and related terms to the original | 0 to 1 call | Lexical or hybrid search, jargon-heavy corpora |
| HyDE | Generates a fake answer and embeds that instead | 1 LLM call | Dense search where queries and documents differ in register |
| Multi-query | Fans out into several queries, fuses the results | N searches | High-recall needs, ambiguous questions |
| None | Search the query as written | 0 | Short-tail queries that already work |
What is query rewriting?
Rewriting turns a query into one a retriever can use standalone. The dominant case is conversational: a user asks "what about for video?" and the retriever receives four words with no subject. A rewriter reads the conversation and emits "what are the pricing tiers for video processing", which retrieves.
It also handles the unglamorous work that matters more than it sounds: expanding "config" to "configuration", fixing typos, dropping filler like "can you tell me", and separating a compound question into the part that needs retrieval.
The failure mode is over-rewriting. A rewriter that is too eager invents specificity the user never supplied, and then retrieves confidently for a question nobody asked. Keeping the original query alongside the rewrite, and searching both, is the usual guard.
What is query expansion?
Expansion keeps the query and adds terms to it. It exists because lexical retrieval matches tokens, so a document saying "automobile" is invisible to a query saying "car".
The classical form is pseudo-relevance feedback: run the search, take the top documents, harvest their most distinctive terms, add those to the query, and search again. RM3 is the standard implementation. It needs no model and it has a sharp failure mode called query drift, where the first search returns something off-topic and expansion pulls the second search further toward the wrong subject.
The modern form asks a language model for related terms directly, which is cheaper to reason about and adds a call. Either way, expansion helps sparse retrieval far more than dense: an embedding model already places "car" and "automobile" near each other, so adding synonyms to a dense query buys little and occasionally blurs it.
What is HyDE, and when does it beat searching the query directly?
HyDE stands for Hypothetical Document Embeddings. Rather than embedding the question, you ask a language model to write a plausible answer, then embed that and search with it. The generated answer can be factually wrong and still work, which is the counterintuitive part: you are not using it as an answer, you are using it as a better-shaped query. It looks like a document, so it lands nearer real documents in the vector space than a question does.
That is the whole mechanism. Questions and documents are written differently, and a question sits in a slightly different region of the embedding space than the passage that answers it. HyDE closes that gap by making the query look like the thing you are searching for.
It works best where the register gap is widest: a short question against long technical prose, or a domain where documents use vocabulary users do not have. It works worst on queries seeking a specific entity, where the model invents plausible details that pull retrieval away from the real record. Searching for an order number is not improved by hallucinating an order.
Introduced in Precise Zero-Shot Dense Retrieval without Relevance Labels.
What is multi-query retrieval?
One question becomes several, each phrased differently, and the result lists are fused. It is the brute-force option: instead of guessing which phrasing retrieves well, you try a handful and combine what comes back.
Fusion is usually reciprocal rank fusion, which scores a document by where it ranks in each list rather than by raw scores, so lists from different retrievers or query variants can be combined without normalising anything. That property is why the same technique underpins hybrid search.
The cost is real and linear: five query variants is five retrievals per user question, and it is the technique most likely to be quietly disabled later when someone reads the bill. RAG-Fusion describes the pattern.
A related trick is step-back prompting, which generates a deliberately more general version of the question and retrieves background context alongside the specific result. Useful when answering needs the concept as well as the detail. See Take a Step Back.
How do these apply to video, images and audio?
The vocabulary gap is wider here, not narrower, because the "document" was never written by anyone.
A video scene has no text of its own. What it has is whatever your pipeline produced: a caption from a vision-language model, a transcript, on-screen text, detected objects. So the register mismatch is between how a user describes what they want and how a captioning model describes what it saw. A user asks for "the part where she looks nervous"; the caption reads "woman standing near a window". HyDE helps here for the same reason it helps on text, by rewriting the query into caption-shaped language.
Two adjustments matter. Expansion with visual synonyms works better than textual ones, because captions use a narrow generated vocabulary rather than the whole language. And a rewriter needs to know which modality it is targeting, since the phrasing that retrieves well against transcripts is not the phrasing that retrieves well against captions. Running the rewrite per modality and fusing afterwards keeps that separable, which also lets you tell which modality caused a miss.
What does this cost, and when is it not worth it?
Every technique here runs on every query, and helps only some of them.
Rewriting and HyDE each add one LLM call to the critical path, typically a few hundred milliseconds, and that lands on every search including the ones that were already working. Multi-query multiplies retrieval cost by the number of variants. Expansion is the cheapest and the least effective on dense retrieval.
The honest sequence: measure retrieval quality without any of it, find the queries that fail, and read them. If they fail because the corpus lacks the answer, no preprocessing helps and you need content. If they fail because the query was underspecified, rewriting helps. If they fail because the wording differs from the documents, HyDE or expansion helps. If they fail because the question has several valid readings, multi-query helps.
Caching matters more than the choice between them. Rewrites and hypothetical documents are deterministic enough to cache by normalised query, and popular queries repeat far more than most teams expect.
Frequently Asked Questions
Does HyDE work if the generated answer is factually wrong?
Usually yes, which is the part that surprises people. The generated text is never shown to anyone and never used as an answer; it is used as a query vector. What matters is that it resembles the KIND of document you are searching, in structure and vocabulary, so it lands near the real ones in the embedding space. A hypothetical answer that gets a date wrong still uses the right terminology and the right register. Where it does break down is queries about specific entities, because invented specifics actively pull retrieval toward documents that do not exist.
Should I use query expansion with dense embeddings?
Usually not, and it is the most common wasted addition. An embedding model already places synonyms near each other, so bolting terms onto a dense query buys little and can blur the intent by averaging the vector across several directions. Expansion earns its place in lexical and hybrid retrieval, where the sparse half genuinely matches tokens and a missing synonym is a hard zero. If you run hybrid search, consider expanding only the sparse side of the query.
How do I stop query rewriting from making retrieval worse?
Search both, and keep the original. A rewriter that invents specificity retrieves confidently for a question nobody asked, and because the results look coherent nothing about the output flags it. Running the original and the rewrite as a two-variant multi-query, then fusing, means a bad rewrite is diluted rather than decisive. Log the pairs and read them: the rewrites that go wrong are obvious to a human in seconds and invisible to any automated metric you are likely to have.
Can I combine these techniques?
Yes, and the combinations that pay are the ones addressing different failures. Rewriting followed by HyDE is coherent, since one resolves conversational context and the other closes the register gap. Rewriting plus multi-query is the common production shape. Stacking expansion on top of HyDE is usually redundant, because both are trying to widen the same lexical net. Every addition multiplies latency, so add them one at a time with a measurement between.
Where in the pipeline does this run?
Before retrieval, which is what separates it from reranking. Preprocessing changes what you search FOR; reranking changes the order of what came BACK. They are complementary and fix different failures: preprocessing raises recall by finding candidates that would otherwise be missed entirely, and reranking raises precision by reordering candidates you already have. A reranker cannot recover a document retrieval never returned, which is why preprocessing comes first when recall is the problem.
Do these help when the corpus simply does not contain the answer?
No, and this is the failure mode most worth ruling out before building any of it. Every technique here changes the query, and none adds documents. If retrieval is failing because nothing in the index answers the question, preprocessing makes the system slower and more expensive while returning the same wrong results, now with more confidence. Read a sample of failing queries before choosing a technique: the split between missing content and mismatched wording decides whether you need a retrieval change or a content change.
Key Takeaways
Where to go next
The rest of the retrieval pipeline: hybrid search: BM25 and vector fusion · cross-encoder reranking · multi-stage retrieval · cross-lingual retrieval
Models and tooling: best rerankers · best multimodal embedding models
Mixpeek indexes unstructured files in object storage at the token level, so a video becomes scenes, frames, a transcript and any attached documents, each embedded and separately searchable. That separation is what makes per-modality query rewriting possible: the phrasing that retrieves well against a transcript is not the phrasing that retrieves well against a caption, and keeping them apart is also how you find out which modality caused a miss. See the vector store or pricing.