Beyond the basic retrieve-then-generate pattern, several techniques improve RAG quality further — most involve adding an extra reasoning or refinement step, trading some latency/cost for better answers.
Query Transformation
Original user query: "Does it work with my setup?"
Problem: too vague/context-dependent to embed and retrieve
well on its own.
Query transformation: use an LLM call to rewrite the query
into something more retrievable, using conversation history:
"Does [product X] support [operating system Y]?"Rewriting a vague or context-dependent query into a clearer, more retrievable form before searching is a common, effective refinement.
Multi-Query Retrieval
Instead of one retrieval pass, generate several variations of
the query and retrieve for each, then combine/deduplicate results:
"What's your return policy?" →
"What's your return policy?"
"How do I return an item?"
"Can I get a refund?"
→ Broader coverage than relying on a single phrasing's
embedding to find everything relevant.Iterative / Agentic Retrieval
Rather than a single fixed retrieve-then-generate pass, an agentic approach lets the system evaluate whether initial retrieval was sufficient, and search again with a refined query if not — see RAG Agents for the full agentic version of this pattern, which is a natural evolution beyond "basic" RAG.
Self-Correction / Verification Loops
1. Generate an initial answer from retrieved context.
2. Check whether the answer is actually faithful to the context
(see Faithfulness).
3. If not faithful, either regenerate with adjusted instructions
or flag for review — rather than returning an unfaithful
answer as-is.When Advanced Techniques Are Worth the Added Complexity
| Signal | Consider Advanced RAG |
|---|---|
| Basic RAG evaluation shows retrieval-quality problems for certain query types | Yes — query transformation or multi-query retrieval often help |
| High-stakes domain where faithfulness matters significantly | Yes — self-correction/verification loops add real value |
| Basic RAG is already performing well against your evaluation set | Added complexity may not be justified yet |
Common Mistakes
- Adopting advanced techniques preemptively, before establishing (via evaluation) that basic RAG has a specific, measurable shortfall these techniques would address
- Not accounting for the added latency and cost of extra LLM calls (query transformation, multi-query, verification loops) in production planning
Interview Relevance
"How would you improve a RAG system that performs poorly on vague, context-dependent user queries?" — query transformation/rewriting using conversation history is a strong, specific, directly-applicable answer.
Practice Question
A user asks a vague follow-up question like "what about the other one?" in a multi-turn RAG chat. Propose an advanced RAG technique to handle this well.
