The query isn't the retrieval signal
Here's something most developers get wrong when they first build a RAG system: they assume the query the user types is the best query to send to the retrieval system. It isn't. And fixing that assumption is one of the highest-leverage improvements you can make.
Think about how you'd search for information yourself. If someone asks you "why did my API call return a 500 error," you don't search for that exact phrase. You probably search for the specific error message, or the service name, or you go straight to the documentation for that endpoint. You transform the question into something more likely to find an answer.
Query transformation patterns do exactly that — they modify the incoming query before it ever touches your index. There are five main patterns, and by the end of this lesson you'll know when to reach for each one.
Hypothetical Document Embeddings
The first pattern is called HyDE — Hypothetical Document Embeddings — and it's counterintuitive when you first hear it.
Instead of embedding the user's question, you ask an LLM to write a fake answer first. Then you embed that fake answer and search for documents that are similar to it.
Why does this work? Because queries and documents live in different parts of the embedding space. The sentence "what's the capital of France" doesn't look much like the sentence "Paris is the capital of France" to an embedding model — even though they're semantically equivalent. But a fake answer that says "The capital of France is Paris, located in the north of the country" looks a lot like the real documents you want to find.
You're converting the question into the shape of an answer before searching.
The catch: If the LLM's fake answer is confidently wrong, you'll retrieve confidently wrong documents. HyDE works best in bounded domains — your own documentation, a codebase, a knowledge base — and less well in open-domain settings where the model might hallucinate the content entirely.
Generalize before you retrieve
The second pattern asks a different question: what if the problem isn't the phrasing, but the specificity?
Step-back prompting takes a very specific question and asks the LLM to generalize it first. "Why did Einstein's specific paper on the photoelectric effect matter?" becomes "What are the foundational contributions of quantum mechanics?" You retrieve for the generalized version, then bring both contexts together when constructing the answer.
This is especially powerful for deep technical questions where the real answer requires background context the user didn't think to ask for — and might not even know they need.
The pattern is simple to implement: one extra LLM call to generalize the query, then you run retrieval twice, once for each version, and pass both result sets to the generation step.
Stop looking for the perfect query
Multi-query generation takes a brute-force approach: instead of finding the perfect query, generate several.
You prompt the LLM to rephrase the question three to five different ways, run all of them through retrieval in parallel, and fuse the results together using Reciprocal Rank Fusion — which we'll cover in detail in the fusion patterns lesson.
Why does this work? Different phrasings hit different parts of the embedding space. One version might match on synonyms. Another might nail a specific keyword. A third might phrase the concept in a way that aligns with how your documents are written. The union of all those results has dramatically higher recall than any single query.
The tradeoff: You're doing N times as many retrieval calls. In practice, returns diminish past about four queries. A weak LLM will generate near-identical rephrasing that doesn't actually add diversity, so the quality of the model doing the rephrasing matters.
One question might actually be many
Query decomposition handles a different problem entirely: the compound question.
When a user asks "compare how Python and Rust handle memory management," that's actually two questions bundled together: how does Python do it, and how does Rust do it? Retrieval systems aren't great at compound questions — they'll either split the difference and find mediocre results for both, or they'll latch onto one part and miss the other entirely.
The fix is to decompose. You have the LLM break the question into atomic sub-questions, retrieve for each independently, and then synthesize all the results in the generation step.
This becomes essential for multi-hop questions — where the answer to the first sub-question determines what you need to ask next. We'll explore that more deeply when we get to the agentic retrieval patterns lesson.
When exact vocabulary matters
Query expansion is the classic IR technique: add synonyms, acronym expansions, or domain-specific related terms to the query before retrieval. Modern LLM-assisted variants use a language model to suggest the related terms automatically.
Honest caveat: pure query expansion has largely been superseded by learned sparse methods like SPLADE — which we'll cover in the retrieval architectures lesson. SPLADE learns implicit expansion during training, so you get the benefit automatically without the extra pipeline step.
Query expansion still earns its place in narrow domains with controlled vocabulary. Medical and legal systems often have precise terminology mismatches — a user who types "heart attack" needs to also match documents about "myocardial infarction." A small, curated expansion dictionary handles this reliably and transparently.
The raw query is a starting point
What all five of these patterns share is the same core insight: the query the user types is a starting point, not a final retrieval signal. Transforming it — whether by generating a fake answer, generalizing it, rephrasing it, or decomposing it — almost always improves results.
The patterns you'll reach for most often are multi-query generation for general recall improvement, and HyDE when you're working in a bounded, well-defined domain where hallucination risk is low.
In the next lesson, we'll move from transforming queries to transforming how documents themselves are represented — starting with the leap from BM25 to learned sparse retrieval with SPLADE.