8 RAG Architectures: A Decision Map
A taxonomy of 8 RAG architectures — Naive, Multimodal, HyDE, Corrective, Graph, Hybrid, Adaptive, and Agentic — with a decision framework for picking the right one.
Semantic paragraph chunking
PDF textbooks are parsed and split into chunks with 100-character overlaps to keep semantic continuity.
8 RAG Architectures — A Decision Map
Start at Naive RAG as your baseline — move right only when you hit a documented failure mode a specific architecture solves.
| Mechanism | Best-fit use case | |
|---|---|---|
| Naive RAG | Vector similarity search only | Simple fact queries |
| Multimodal RAG | Cross-modal embedding & retrieval | Text + image/audio queries |
| HyDE | Hypothetical-document query expansion | Semantically-distant query/answer pairs |
| Corrective RAG | Retrieval validation + web fallback | Freshness / accuracy-critical queries |
| Graph RAG | Knowledge-graph traversal | Relationship / multi-entity reasoning |
| Hybrid RAG | Dense + graph retrieval combined | Mixed structured/unstructured needs |
| Adaptive RAG | Dynamic simple-vs-multistep routing | Variable query complexity |
| Agentic RAG | Agent-orchestrated multi-source retrieval | Complex, tool-using workflows |
▶📚 Prerequisites(1)
🎓 Learning objectives
- •Name and describe all 8 RAG architectures and the specific problem each solves
- •Distinguish Naive RAG's failure modes from what Corrective, Graph, and Adaptive RAG each fix
- •Explain when Multimodal or Hybrid RAG are needed versus text-only architectures
- •Use the 8-architecture taxonomy as a decision map for a new RAG system
What is it?
This is a taxonomy mapping the 8 major RAG architectural patterns used in production AI systems, functioning as a decision map for choosing the right architecture for a given use case. The 8 are: Naive RAG (the baseline: pure vector similarity retrieval), Multimodal RAG (retrieval across text, images, audio), HyDE (hypothetical-document query expansion), Corrective RAG (validates retrieved results against trusted sources), Graph RAG (knowledge-graph-structured retrieval), Hybrid RAG (combines dense vector + graph retrieval), Adaptive RAG (dynamically decides simple vs. multi-step retrieval), and Agentic RAG (agent-orchestrated retrieval across multiple sources with reasoning and memory).
Why it exists
Once 'Prompting vs. RAG vs. Fine-tuning' has already pointed you toward RAG, the next decision is which RAG architecture actually fits your use case — and 'just do naive RAG' is often wrong for anything beyond the simplest fact-lookup queries. This taxonomy exists to lay out the full menu of architectural options at once, so architecture selection becomes a matter of matching your specific failure mode or requirement (need cross-modal retrieval? need multi-hop reasoning? need up-to-date validation?) to the corresponding named architecture, rather than discovering each pattern's existence only after hitting its specific problem in production.
Problem it solves
Naive RAG (pure vector similarity) works for simple, fact-based queries but fails in predictable, named ways that each have a corresponding architectural fix: it can't handle non-text data (solved by Multimodal RAG), it retrieves based on raw query-to-document similarity even when queries and answers aren't semantically similar (solved by HyDE), it can't detect or correct stale/wrong retrieved content (solved by Corrective RAG), it can't reason over relationships between entities across documents (solved by Graph RAG), it can't combine structured relational data with unstructured text in one pipeline (solved by Hybrid RAG), it always does the same fixed retrieval regardless of query complexity (solved by Adaptive RAG), and it can't orchestrate multi-step, tool-using, multi-source retrieval workflows (solved by Agentic RAG). This taxonomy solves the 'which failure am I hitting, and which architecture fixes it' diagnostic problem.
Intuition
Think of the 8 architectures as a toolbox where Naive RAG is your basic screwdriver — fine for straightforward jobs, useless the moment you hit a stripped screw (Corrective RAG's validation), a bolt instead of a screw (Multimodal RAG's cross-type handling), a screw buried in a wall you need X-ray vision to locate structurally (Graph RAG's relationship-aware retrieval), or a job requiring you to first figure out what tool you even need before starting (Adaptive/Agentic RAG's dynamic decision-making). You don't reach for every tool on every job — you diagnose the specific problem, then reach for the architecture built to solve exactly that problem.
Analogy
It's like choosing a research method for answering a question. Naive RAG is like Ctrl+F-ing a single document for keywords. Multimodal RAG is like also being able to search the document's photos and diagrams, not just its text. HyDE is like first drafting a plausible-sounding answer yourself, then searching for documents that resemble your draft rather than your original question. Corrective RAG is like fact-checking your search results against a second, trusted source before trusting them. Graph RAG is like consulting a relationship map of how entities connect, not just individual paragraphs. Hybrid RAG is like combining that relationship map with regular document search. Adaptive RAG is like deciding, before you even start, whether this question needs a quick lookup or a multi-step investigation. Agentic RAG is like hiring a full research assistant who plans, searches multiple archives, checks their own work, and iterates until satisfied.
Technical explanation
(1) Naive RAG retrieves documents purely based on vector similarity between the query embedding and stored embeddings — works best for simple, fact-based queries where direct semantic matching suffices, and is the baseline every other architecture improves on for a specific failure mode. (2) Multimodal RAG handles multiple data types (text, images, audio, etc.) by embedding and retrieving across modalities, ideal for cross-modal retrieval tasks like answering a text query using both text and image context. (3) HyDE generates a hypothetical answer document from the query before retrieval, then uses that generated document's embedding to find more relevant real documents — addressing the fact that queries and their answers are often not semantically similar to each other. (4) Corrective RAG validates retrieved results by comparing them against trusted sources (e.g., web search), ensuring up-to-date and accurate information by filtering or correcting retrieved content before it reaches the LLM. (5) Graph RAG converts retrieved content into a knowledge graph to capture relationships and entities, enhancing reasoning by providing structured context alongside raw text. (6) Hybrid RAG combines dense vector retrieval with graph-based retrieval in a single pipeline, useful when a task requires both unstructured text and structured relational data for richer answers. (7) Adaptive RAG dynamically decides whether a query requires simple direct retrieval or a multi-step reasoning chain, breaking complex queries into smaller sub-queries for better coverage and accuracy when needed. (8) Agentic RAG uses AI agents with planning, reasoning (ReAct, CoT), and memory to orchestrate retrieval from multiple sources, best suited for complex workflows requiring tool use, external APIs, or a combination of multiple RAG techniques from this same list.
Architecture
The 8 architectures aren't mutually exclusive alternatives so much as composable layers — a production system might use Hybrid RAG's dense+graph retrieval AND Corrective RAG's validation AND be orchestrated by an Agentic RAG loop that decides, Adaptive-RAG-style, when multi-step reasoning is needed. The taxonomy is best understood as: Naive RAG is the substrate every other architecture modifies; Multimodal, HyDE, Corrective, and Graph RAG are each targeted fixes for one specific failure mode; Hybrid RAG composes two retrieval mechanisms; and Adaptive and Agentic RAG are orchestration-layer patterns that can wrap around any of the retrieval-layer architectures beneath them.
Workflow
- Start with Naive RAG as your baseline implementation and identify whether it actually fails for your real query distribution — don't add architectural complexity preemptively.
- If queries and their answers are semantically distant (common in Q&A over conversational or informal source text), add HyDE.
- If your corpus includes non-text data your queries need to reference, add Multimodal RAG.
- If answer freshness/accuracy is critical and stale or wrong retrieved content is a real risk, add Corrective RAG's validation step.
- If your queries require reasoning about relationships between entities across documents (not just isolated fact lookup), add Graph RAG, or Hybrid RAG if you also need unstructured text alongside the graph.
- If query complexity varies significantly — some simple, some requiring multi-hop reasoning — add Adaptive RAG's dynamic routing rather than always paying the cost of the most complex path.
- If your workflow needs genuine multi-step, tool-using, multi-source orchestration (not just retrieval-then-generate), move to Agentic RAG, which can incorporate any of the other 7 architectures as tools within its own loop.
Example
def select_rag_architecture(query: str, corpus_metadata: dict) -> str: '''Illustrative router mapping query characteristics to an architecture.''' if corpus_metadata.get('has_images_or_audio') and query_references_media(query): return 'multimodal_rag' if requires_multi_hop_reasoning(query): return 'agentic_rag' if requires_relationship_reasoning(query): return 'graph_rag' if not corpus_metadata.get('has_unstructured_text') else 'hybrid_rag' if freshness_critical(query): return 'corrective_rag' if query_answer_semantic_gap_likely(query): return 'hyde' if query_complexity_variable(corpus_metadata): return 'adaptive_rag' return 'naive_rag' # default baseline
Real-world usage
Perplexity's core product is essentially Corrective RAG at scale — validating and grounding retrieved web content in real time rather than trusting a static index. Microsoft's GraphRAG (open-source) is used for legal and biomedical document analysis specifically because those domains require the relationship-aware reasoning Graph RAG provides over isolated chunk retrieval. Multimodal RAG underpins products that let users query a mix of screenshots, PDFs, and text (e.g., visual search tools, some customer support platforms handling image attachments). Adaptive RAG's dynamic complexity routing is used by cost-conscious production systems to avoid paying multi-step-reasoning latency/cost on the (often majority of) queries that are actually simple lookups. Agentic RAG is the architecture underlying most modern 'research assistant' style products that need to combine multiple of the other 7 architectures dynamically per query.
Trade-offs
Each architecture beyond Naive RAG adds implementation complexity and latency/cost in exchange for solving a specific failure mode — HyDE adds an extra LLM call before retrieval; Corrective RAG adds a validation step and possible web-search fallback; Graph RAG requires building and maintaining a knowledge graph at index time; Adaptive and Agentic RAG add orchestration overhead and non-determinism. The right approach is almost never 'implement all 8' — it's diagnosing which specific failure mode(s) your actual queries hit and adding only the architectural components that address those, keeping Naive RAG's simplicity everywhere it still suffices.
Visual explanation
An 8-box comparison grid, each box showing: the architecture name, a one-line mechanism description, and its best-fit use case. Naive RAG: [vector similarity only] → simple fact queries. Multimodal RAG: [cross-modal embedding/retrieval] → text+image/audio queries. HyDE: [hypothetical-doc query expansion] → semantically-distant query/answer pairs. Corrective RAG: [retrieval validation + web fallback] → freshness/accuracy-critical queries. Graph RAG: [knowledge-graph traversal] → relationship/multi-entity reasoning. Hybrid RAG: [dense + graph combined] → mixed structured/unstructured needs. Adaptive RAG: [dynamic simple-vs-multistep routing] → variable query complexity. Agentic RAG: [agent-orchestrated multi-source retrieval] → complex, tool-using workflows.
An arrow below the grid reads: 'Start at Naive RAG as your baseline — move right only when you hit a documented failure mode a specific architecture solves.'
Advantages
- —
Provides a complete decision map covering text, multimodal, relationship-aware, freshness-critical, and multi-step-reasoning RAG needs in one taxonomy
- —
Each architecture targets one specific, well-understood failure mode of Naive RAG, making diagnosis-to-solution mapping straightforward
- —
The architectures compose — production systems commonly combine several (e.g., Hybrid + Corrective + Agentic orchestration) rather than picking exactly one
- —
Starting from Naive RAG as a baseline avoids premature architectural complexity for queries that don't actually need it
Disadvantages
- —
Implementing multiple architectures together (as production systems often do) compounds the complexity, latency, and cost of each individual one
- —
The taxonomy alone doesn't tell you which architecture(s) your specific queries need — that still requires empirical diagnosis against real query patterns
- —
Some architectures (Graph RAG, Hybrid RAG) require substantial index-time infrastructure investment (building and maintaining a knowledge graph) before any query-time benefit is realized
- —
Agentic RAG's orchestration flexibility comes with non-determinism and debugging difficulty compared to simpler, more predictable architectures
Common mistakes
- —
Jumping straight to Agentic RAG or Graph RAG for a use case Naive RAG would have handled fine, adding unnecessary complexity and cost
- —
Treating the 8 architectures as mutually exclusive choices rather than composable layers that production systems often combine
- —
Building Graph RAG's knowledge graph infrastructure without validating that queries actually need relationship-aware reasoning, wasting significant index-time investment
- —
Not diagnosing which specific failure mode is occurring before picking an architecture — e.g., adding Corrective RAG when the actual problem is semantic query-answer mismatch (which HyDE solves instead)
- —
Ignoring Adaptive RAG's dynamic routing and paying the latency/cost of the most complex architecture on every single query, even the simple majority that didn't need it
📂 Subtopics
Naive RAG: Basic Retrieve-Then-Generate
The baseline RAG architecture: embed the query, retrieve by vector similarity, stuff the results into the prompt, generate once. Simple, fast, and the right starting point before reaching for anything fancier.
~10 min
HyDE: Hypothetical Document Embeddings
Questions aren't semantically similar to their answers, which hurts naive retrieval. HyDE fixes this by having the LLM generate a hypothetical answer first, then embedding THAT to search — even though the hypothetical answer may contain hallucinated details.
~15 min
Corrective RAG (CRAG): Self-Evaluating Retrieval
Corrective RAG adds a validation step after retrieval: check retrieved results against trusted sources before trusting them, and fall back to a web search when the vector store's results aren't good enough.
~12 min
Agentic RAG: Letting the LLM Decide When and What to Retrieve
Agentic RAG uses AI agents with planning, reasoning, and memory to orchestrate retrieval — deciding IF retrieval is needed, WHICH source to query, and validating the results, with a retry loop back to the start when the answer isn't good enough.
~15 min
Graph RAG: Knowledge-Graph-Based Retrieval
Graph RAG converts retrieved content into a knowledge graph capturing entities and their relationships, giving the LLM structured relational context alongside raw text — well suited to questions that span multiple connected entities.
~12 min