What is query transformation in RAG and why does it help?

What the interviewer is testing

Whether you can explain common query transformations, connect them to retrieval recall, and evaluate their latency tradeoff.

Answer framework

• Query transformation rewrites the user's request before retrieval, bridging vocabulary differences between the question and indexed documents.
• Common rewrites resolve pronouns from chat history, expand acronyms, and split multi-part questions into separate subqueries.
• HyDE generates a hypothetical answer and embeds that answer to retrieve passages related to the expected response.
• Transformation helps when relevant documents use different wording than the user, so it can improve retrieval recall.
• Because transformation can add model calls and latency, compare retrieval recall and answer quality against a no-rewrite baseline.

Sample answer

I see query transformation as a query-rewrite step that runs before retrieval. The system takes the user's question and produces one or more search queries that are more likely to match the indexed text. This is useful because people and documents often describe the same concept in different language, so a semantically relevant document may not look close to the original wording.

Depending on the case, the rewrite can resolve pronouns from earlier chat turns, expand an acronym, or split a multi-part question into separate subqueries. For example, if someone asks what it supports after describing a company product, I would substitute the relevant product name before searching. Another technique is HyDE. I generate a hypothetical answer, embed that answer rather than the question, and use the resulting vector to find supporting passages. The important point is that each transformed query still retrieves evidence that I can inspect before answering.

Transformation is not automatically better, though. Model-based transformation can add calls and latency and may introduce errors. I would compare the transformed and original queries on a fixed retrieval set, looking at relevant-document recall and answer quality rather than assuming a gain. I would use it for ambiguous, conversational, or multi-part questions, and keep the original query as a fallback. That lets me pay the extra latency only when the measured recall improvement justifies it.

Likely follow-ups

When would I prefer HyDE over a normal query rewrite? I would consider HyDE when the relevant documents use language that differs from the question and generating a plausible answer may lead the retriever closer to that vocabulary.

How do I measure whether query transformation is helping? I would compare it with the original query on a fixed retrieval set, measuring relevant-document recall and downstream answer quality while also recording latency.

What can go wrong during query transformation? A rewrite can introduce an incorrect entity, drop part of the request, or produce queries that retrieve plausible but irrelevant passages, so I would inspect the transformed queries.

Common mistakes

• Treating query transformation as a guaranteed improvement in retrieval recall.
• Using a hypothetical answer as source evidence instead of treating it only as a retrieval proxy.
• Rewriting a multi-part question into one query rather than considering separate subqueries.
• Ignoring potential added model calls and latency when deciding whether transformation is worthwhile.

This article was prepared with AI assistance and reviewed before publishing. The original lives on the free question bank:

https://johnnnmai.github.io/ai-engineer-interview-questions/questions/what-is-query-transformation-in-rag/?utm_source=devto&utm_medium=community&utm_campaign=what-is-query-transformation-in-rag