Module 11
Advanced Patterns
Retrieval & Knowledge Retrieval-Augmented Generation (RAG)
Module 11 — Advanced Patterns
You now know the standard RAG pipeline end to end. This module is the “expert vocabulary” tour: the named techniques that go beyond the basics. The goal isn’t to use them all — it’s to recognize each, know what problem it solves, and know its cost, so you can reach for the right one (and resist the wrong one).
Golden rule for this whole module: every pattern below adds latency, cost, and a new way to fail. Add one only when your evaluation (Module 12) shows you need it — never because it sounds impressive.
We’ll group them by which part of the pipeline they improve.
1. Query-side patterns (improve the question before searching)
- Query rewriting / expansion — clean up or enrich the query (fix spelling, expand acronyms, add synonyms) for better matching. Solves: terse or sloppy queries.
- Multi-query — generate several paraphrases of the question, retrieve for each, and union the results. Solves: ambiguous wording that a single phrasing would miss. Cost: several searches per question.
- HyDE (Hypothetical Document Embeddings) — a clever trick: ask the model to write a hypothetical answer to the question, then embed that answer and search with it. Why it works: a fake answer often sits closer on the meaning-map (Module 08) to the real passages than the short question does. Solves: questions worded very differently from the source text. Cost: an extra model call.
- Query decomposition — break a complex, multi-part question into sub-questions, retrieve for each, then combine. Solves: “multi-hop” questions like “compare A and B across price and warranty” that no single passage answers.
- Routing — classify the question and send it to the right place: docs index vs a SQL tool vs a web search vs a different index. Solves: mixed systems (recall Module 05) where not everything is a RAG question.
2. Index-side patterns (improve how knowledge is stored)
- Parent-document / small-to-big (from Module 07) — match on small chunks, return the larger surrounding passage. Solves: “precise search but thin context.”
- Sentence-window retrieval — match a single sentence, then return a window of sentences around it for context. Solves: same tension, finer-grained.
- Hierarchical summarization / RAPTOR — build a tree of summaries over your corpus (summaries of chunks, summaries of those summaries, etc.), and retrieve at the right level. Solves: big-picture questions (“summarize everything we know about X”) that flat chunking can’t answer because the answer is spread across many chunks. Cost: building and maintaining the tree.
- GraphRAG — extract entities and their relationships from your documents into a knowledge graph (a network of “things” connected by “relationships”), then retrieve relevant sub-networks. Solves: multi-hop reasoning and “connect the dots across many documents” / global questions, where relationships matter more than individual passages. Cost: significant — building and maintaining the graph is real work; use it when relationship-reasoning is the core need.
- Multi-vector / ColBERT (late interaction) — store finer-grained (token-level) embeddings for sharper matching. Solves: precision-critical retrieval. Cost: more storage and complexity.
3. Control-flow patterns (let the system decide how to retrieve)
These make RAG less of a fixed assembly line and more of a reasoning loop.
- Agentic RAG — instead of always retrieving once, an agent (the model acting in a decide-act loop) chooses whether to retrieve, what to search for, and whether to search again based on what it found. It can run multiple searches, use tools, and iterate. Solves: complex questions needing several steps or tools. Cost: more model calls, harder to predict and debug.
- Self-RAG / Corrective RAG (CRAG) — the model critiques the retrieved chunks: are they actually relevant and sufficient? If not, it re-retrieves, reformulates, or falls back to another source (like web search). Solves: silently answering from poor context. Cost: extra evaluation steps.
- Adaptive RAG — route by difficulty: simple questions go straight to the model (no retrieval), complex ones get the full pipeline. Solves: wasting time and money retrieving for questions that don’t need it.
4. Modality patterns (beyond plain text)
- Multimodal RAG — retrieve over images, charts, tables, and scanned pages, not just text — e.g. embedding page images with a vision-capable model. Solves: knowledge bases full of slides, diagrams, scanned forms, and screenshots where the meaning is visual. Cost: vision models, more storage.
5. How to think about all of this as an architect
Picture a ladder. The bottom rungs (good parsing, sensible chunking, hybrid search, a reranker, grounded prompts) deliver most of the value for most systems. The patterns in this module are higher rungs — each solves a specific shortfall:
| If your problem is… | Consider… |
|---|---|
| Queries worded unlike the docs | HyDE, multi-query, query rewriting |
| Multi-part / compare questions | Query decomposition |
| ”Summarize the whole topic” questions | RAPTOR / hierarchical summaries |
| ”How are these things connected?” across many docs | GraphRAG |
| Mixed question types (some need SQL/web) | Routing, agentic RAG |
| Retrieved context is often poor and unnoticed | Corrective / Self-RAG |
| Wasting retrieval on easy questions | Adaptive RAG |
| Knowledge lives in images/diagrams/scans | Multimodal RAG |
The expert move is diagnose first, then pick the one matching pattern — not stack five of them and hope. Each rung you add should be justified by a measured gap.
Check yourself
- Explain HyDE in one sentence — what gets embedded and why it helps.
- What kind of question is GraphRAG uniquely good at, and what’s its main cost?
- How does agentic RAG differ from the fixed pipeline of Modules 06–10?
- What’s the difference between RAPTOR (hierarchical summaries) and query decomposition in terms of the problem each solves?
- Restate the “golden rule” for adding any advanced pattern.
Next: Module 12 — Evaluation →