Companion diagrams for the article
RAG Explained in 12 Minutes
Retrieval-Augmented Generation: what it is, how the architecture works, and ten patterns shaping 2026.
Channel: Aishwarya Srinivasan
Diagrams: 6
Article sections: 1 through 5
1. RAG at a Glance: Closed Book vs. Open Book
Illustrates Section 1, "What Is RAG?": the LLM alone is a closed-book student, while RAG adds a retrieval system so generation is grounded in your sources.
LLM alone — closed-book exam
1
User question
↓
2
Model answers from memoryOnly what was memorized during training
↓
3
Gaps and risksKnowledge cutoff, no access to your data, hallucination risk
RAG — open-book exam
1
User question
↓
2
Retrieval systemLooks up documents, databases, and the knowledge base
↓
3
Prompt with relevant chunksThe found material is added to the question
↓
4
Grounded answerGeneration system (the LLM) answers from the retrieved context
RAG is a partnership: a retrieval system that finds the right information and a generation system that uses it — the foundation of enterprise AI.
2. Context Stuffing vs. Retrieved Context: Cost, Latency, Accuracy
Maps the second misconception from Section 2, "Two Misconceptions That Persist": huge context windows do not remove the need for RAG.
User queryOne question, two paths
Option A — context stuffing
1
Million-token promptThe whole corpus rides along on every query
↓
2
CostAstronomically expensive at scale
3
LatencySlow calls
4
PerformanceAccuracy drops — signal buried in noise
Option B — RAG retrieval
1
Right information onlyRAG surfaces precisely the relevant chunks
↓
2
CostOnly relevant tokens are processed
3
LatencyFast
4
PerformanceHigher accuracy — less noise for the model
Well-built RAG consistently beats brute-force context stuffing on accuracy, cost, and speed.
3. The Indexing Pipeline: Chunking, Embedding, Storing
Follows the offline half of Section 3, "Inside the Architecture: How RAG Works" — the chunking strategies, embedding models, and vector database of Sections 3.1 through 3.3.
Source documentsPDFs, Markdown, code, internal databases
↓
Chunking strategy — how the document is broken up
Fixed-sizeUniform 500-token cuts — sentences break at boundaries
SemanticSplit where the topic shifts; embedding model detects boundaries
Document-awareRespect sections and headers of PDFs and Markdown
HierarchicalSmall precise chunk plus larger parent — small-to-big retrieval
↓
Embedding modelEach chunk becomes a numerical vector of meaning
↓
Vector databasePinecone, Weaviate, Qdrant, Milvus, Chroma DB — embeddings live here
Semantic and document-aware chunking beat fixed-size cuts; hierarchical chunking is one of the best production techniques.
4. Query Time: Hybrid Retrieval and Grounded Generation
Traces the online path through Sections 3.2 and 3.4 of "Inside the Architecture": embedding the query, hybrid search, and prompt assembly before the LLM writes.
User question
↓
Query embeddingThe question is embedded with the same model used for chunks
↓
Hybrid search — both lanes run, results merge
Vector searchNearest neighbors by meaning — semantic similarityLane fed from the vector database; metadata filters (date, source, category) apply before the search
Keyword searchExact-term matching — catches names and code the vectors miss
↓
Top-K chunksThe best matches are merged and ranked
↓
Prompt assemblyQuestion plus retrieved chunks, no noise
↓
Grounded answerThe LLM generates from the retrieved context
5. Ten RAG Patterns: The Evolution of an Architecture
Compresses all of Section 4, "Ten RAG Patterns to Know in 2026", into one progression — also the rebuttal to the "RAG is dead" myth from Section 2.1.
Foundations — patterns 1 and 2
1
Simple RAGRetrieve relevant chunks, stuff them into the prompt, generate
2
RAG with MemoryCarries earlier questions, answers, and retrievals between turns
↓
Smarter retrieval — patterns 3 through 5
3
Branch RAGLLM decomposes the question; parallel retrieval per sub-question; synthesis
4
HyDEHypothetical document embeddings — embed a draft answer, not the query
5
Adaptive RAGRouting layer decides: answer directly, simple retrieval, or multi-step
↓
Quality gates — patterns 6 and 7
6
Corrective RAGEvaluation step after retrieval; reformulate, retry, or fall back to web search
7
Self-RAGReflection tokens while writing: is retrieval needed? Is this relevant? Supported?
↓
The frontier — patterns 8 through 10
8
Agentic RAGLLM orchestrator loops over searches, APIs, and code until the answer is good enough
9
Multimodal RAGVision models describe images and tables; embeddings cover non-text content
10
Graph RAGKnowledge graph maps entities and relationships, not just similarity
The pattern list is evidence: RAG is not dying, it is maturing.
6. Agentic RAG: The Orchestrator Loop
Zooms into the pattern from Section 4.8: the LLM orchestrates retrieval, APIs, and code in a loop until it has enough context to answer.
User→Complex multi-step question
Agent loop — decide, act, observe, until the context is enough
LLM orchestrator decides what to do next
More information → search
Tool needed → API or code
Enough context → answer
Orchestrator→Retrieve from another source
Retriever→Relevant chunks
Orchestrator→Run code or call an API
Tools→Tool result
Orchestrator→Re-evaluate: is the answer good enough now?
Enough context — exit the loop
Orchestrator→Final grounded answer
Frameworks like LangChain and LlamaIndex workflows are built for exactly this pattern.