Retrieval
Query transformation
Rewrite, split, expand or hypothesise a search query before retrieval, so messy questions still hit the right chunks.
Users ask vague, compound or conversational questions. "What about the enterprise plan?" means nothing to an index without the earlier turns. Transforming the query before retrieval often helps more than swapping embedders.
Concept
Before you start: hybrid search finds chunks for a query. A query transform writes a better query first, then search runs as usual.
The big idea
The index stores documents. It cannot guess that "it" means last month's outage. You either rewrite the question into a standalone search string, or you search more than once.
| Technique | Idea | Use when |
|---|---|---|
| Rewriting | A model turns chat context into one search query | Multi-turn "what about the enterprise plan?" |
| Decomposition | Split a multi-hop question into sub-queries | "Compare X and Y on price and SLA" |
| Multi-query | Generate 3 to 5 phrasings; retrieve the union or fuse with RRF | Ambiguous wording; you need higher recall |
| HyDE | The model drafts a hypothetical answer; you embed that | Short questions, long expository documents |
| Step-back | Ask a broader question first | You need abstract context before specifics |
REWRITE = """Given the chat, write a single search query that
finds documents to answer the latest user message.
Return only the query text.
Chat:
{chat}
"""This is a prompt sketch, not a full client. The output is ordinary query text. Feed it to the same hybrid plus rerank path you already have.
HyDE (Hypothetical Document Embeddings) writes a plausible answer paragraph and embeds that paragraph instead of the raw question. It helps when questions are short and documents are long. The risk is a hallucinated hypothetical that retrieves the wrong neighborhood. Measure it.
Warning
Every rewrite is an extra model call: latency, cost and a new failure mode. A bad rewrite yields empty retrieval. Gate each transform with evals. Do not enable five of them by default.
Walking through a chat turn
Chat: "We use the Pro plan." then "What about the enterprise plan?"
A rewrite becomes enterprise plan pricing features SLA. Search now has nouns an index can match. Without the rewrite, the second turn is three words and a lot of pronouns.
For "Compare Acme and Beta on price and SLA," decomposition issues two queries, retrieves two small piles, and the generator writes the comparison. One blended query often misses one of the two vendors.
Common mistakes
- Turning on every transform at once. You cannot tell which one moved the metric, and you pay for all of them.
- Trusting HyDE without an eval. A fluent fake answer retrieves fluent fake neighbors.
- Rewriting when the question is already a good search string. You add latency for no gain.
Check yourself
- The user says "what about the enterprise plan?" after talking about Pro. What should you search? A standalone query such as "enterprise plan pricing features SLA," not the raw three words.
- Why can HyDE retrieve the wrong neighborhood? The hypothetical answer can be fluent and false, so its embedding points at the wrong documents.
Key takeaways
- Rewrite chat into a standalone query. Split comparisons. Expand ambiguous wording.
- HyDE embeds a drafted answer, not the question. Measure before you keep it.
- Each transform is an extra model call. Enable one at a time against a labeled set.
Further learning
When chunks themselves are orphaned from their document, fix ingestion with contextual retrieval.
Related
Advanced RAG
Hybrid search, reranking, query rewriting, contextual retrieval and measuring retrieval quality.
Hybrid search
Run BM25 for exact tokens and dense vectors for paraphrases, then fuse the two ranked lists with reciprocal rank fusion.
Retrieval metrics
Recall@k, MRR and nDCG tell you whether the right chunk was found, before you blame the prompt or the model.