RAG Taxonomy: Classification and Architecture Mapping

All 52 RAG architectures mapped by mechanism, data source, retrieval control, and production fit.

Classification Axes

Every RAG system can be classified along four independent dimensions. Understanding these axes helps you systematically answer "How does X RAG work?" and "When do you choose Y over Z?"

1. Retrieval Control

• Static: Same retrieval strategy for all queries (naive, advanced RAG)
• Dynamic: Strategy adapts based on query characteristics (adaptive RAG)
• Agent-Driven: An LLM orchestrates retrieval decisions (agentic RAG)

2. Data Modality

• Text-Only: Documents are plain text (naive through modular RAG)
• Structured: Tables, schemas, SQL-queryable (structured RAG)
• Graph: Knowledge graph as retrieval source (graph RAG)
• Multimodal: Images, tables, text combined (multimodal RAG)

3. Feedback Loop

• None: No loop; retrieve once, generate once (naive, advanced, modular RAG)
• Self-Critique: LLM validates its own output, re-retrieves if needed (corrective, self-RAG)
• External Signal: User feedback or evaluation signal drives re-retrieval (self-RAG with fine-tuning)

4. Retrieval Scope

• Single-Hop: One retrieval call per query (naive, advanced RAG)
• Multi-Hop: Multiple retrieval calls chained together (agentic, adaptive RAG)
• Iterative: Retrieval continues until a stopping criterion (FLARE, self-RAG)

Each axis maps to a different set of failure modes and trade-offs. Mastering these axes makes every RAG interview question answerable.

The Full Taxonomy: All 52 Architectures

* Query-time latency is low; HippoRAG and CAG pay a large up-front (index-build / KV-cache) cost instead. LongRAG, LazyGraphRAG, and Auto-RAG/DeepRAG vary with routing/expansion/step-count decisions made per query. CoRAG's latency also scales with the chosen chain length (a test-time compute knob). ‡ DPR is also a training-time architecture but is listed separately as the foundational bi-encoder retrieval model rather than a full RAG pipeline. † Training-time / parametric architectures: retrieval is integrated into pre-training or the model architecture (and the retriever/reader is trained), rather than bolted on at inference. They form a distinct branch from the inference-time architectures above.

Taxonomy Tree Diagram

Here's how the core architectures relate (the tree shows the original 12 base types; the 17 newer architectures in the table above are specializations or compositions of these — e.g. HippoRAG, LightRAG, KAG, GraphReader and GNN-RAG extend the Graph branch; FLARE and Iterative RAG extend the iterative-scope branch; HyDE is a query-transformation layer over any static retriever; and REALM/RETRO/Atlas/FiD form a separate training-time / parametric branch where retrieval is baked into pre-training or architecture rather than added at inference). Every path from root to leaf is a valid RAG system.

                          RAG
                          │
        ┌─────────────────┼──────────────────┐
        │                 │                  │
    Text-Only         Specialized        Context-Aware
        │           (Data Modality)      (Scope)
        │                 │                  │
   ┌────┼────┐        ┌───┼───┐         ┌───┴────┐
   │    │    │        │   │   │         │        │
Static Dyn  Agent   Graph Struct Multi  Long-  Spec
        │    │        │   │   │      Context  ulative
   ┌────┘    │    ┌───┘   │   │         │        │
   │         │    │       │   │         │        │
Naive    Adaptive Agentic GraphRAG Struct Multi   │
RAG      RAG      RAG     RAG     RAG    RAG   Long-Context
   │         │             │       │          │
Advanced  Modular      (multi-hop)         (single-hop,
RAG       RAG                            context
   │         │                           window)
Corrective  (self-critique)
RAG         Self-RAG
   │          │
(validation) (fine-tune)

How New RAG Architectures Get Created

The field produces new architectures by combining these three generative patterns:

Pattern 1: Add a New Retrieval Source

• Example: Graph RAG adds knowledge graph to the retrieval set alongside text
• Example: Structured RAG routes queries to SQL tables instead of (or alongside) semantic search
• Result: Same orchestration logic as Advanced RAG, but the retrieve step branches based on query type
• Pseudocode:

  def retrieve(query: str, use_graph: bool = True):
      if use_graph and is_entity_query(query):
          return retrieve_from_graph(query)
      else:
          return retrieve_from_text_index(query)
  

Pattern 2: Add a Feedback Loop

• Example: Corrective RAG adds a validation step: "Is retrieved context sufficient?"
• Example: Self-RAG adds a confidence score and iterates if uncertain
• Result: Single retrieval call becomes a conditional chain
• Pseudocode:

  def retrieve_with_feedback(query: str):
      context = retrieve(query)
      if not is_sufficient(context):  # feedback
          context = retrieve_with_different_strategy(query)
      return context
  

Pattern 3: Add Orchestration / Control Logic

• Example: Agentic RAG adds an LLM agent that decides retrieve → generate → decide to re-retrieve
• Example: Adaptive RAG adds a classifier that picks which retrieval strategy to use
• Result: Retrieval decisions are no longer pre-determined; they're computed per query
• Pseudocode:

  def orchestrate(query: str):
      strategy = pick_strategy(query)  # "dense", "hybrid", "re-rank", etc.
      context = retrieve(query, strategy)
      if agent_wants_more_context():
          context += retrieve(query, different_strategy)
      return context
  

Most production systems combine two or more patterns. For example, a system that uses Adaptive RAG (pattern 3) to pick a strategy, then adds Self-RAG's feedback loop (pattern 2) is a valid hybrid.

Hybrid Systems in Practice

Most production RAG systems are not pure. They combine two or more of the 52 architectures.

Taxonomy Anti-patterns

Five common mistakes when classifying or choosing a RAG type:

1. Over-Engineering (Choosing Agentic when Naive Would Do)

• The mistake: "Our system is complex, so we need an agent"
• The reality: Naive RAG succeeds on 80% of retrieval benchmarks when done well (good chunks, good embeddings)
• The signal you've over-engineered: Latency increased, debuggability decreased, cost exploded, accuracy barely improved
• The fix: Measure NDCG@5 on a probe set before adding an agent. Agentic RAG is a forcing function, not a default

2. Under-Specifying (Calling Everything "Advanced RAG")

• The mistake: "We use advanced RAG with reranking and query expansion"
• The reality: Query expansion + reranking is just Advanced RAG. Calling it "advanced" is marketing, not architecture
• The signal: You can't distinguish your system from others in the 02_interview_bank taxonomy
• The fix: Classify along the four axes. Use the taxonomy table, not marketing words

3. Modality Mismatch (Using Text Embeddings on Structured Data)

• The mistake: "We embed SQL tables into vectors and search them"
• The reality: Text embeddings trained on prose poorly understand tabular semantics. Use Structured RAG instead
• The signal: Low retrieval recall on numeric comparisons and exact matches
• The fix: For structured data, use query-to-SQL + post-generation filtering (Structured RAG pattern)

4. Scope Creep Without Feedback (Multi-Hop Without Validation)

• The mistake: "We retrieve multiple times" without checking if the final answer is correct
• The reality: Multi-hop retrieval without validation leads to error accumulation ("hallucinations compounding")
• The signal: Longer answers contain more errors; deeper reasoning is worse than shallow
• The fix: Add feedback. Use Corrective RAG or Self-RAG to validate and re-retrieve if needed

5. Ignoring Latency Budget

• The mistake: "Agentic RAG is better, so we'll use it everywhere"
• The reality: Agentic RAG is ~5–10x slower than Naive RAG (multiple sequential calls). If latency budget is <500ms, Adaptive RAG is the better choice
• The signal: P95 latency is 5+ seconds; users see timeouts
• The fix: Measure latency distribution. Choose the simplest architecture that meets your SLA

Using the Taxonomy

1. To understand a new architecture: Find it in the table. Read the retrieval control, feedback loop, and scope. That tells you the mechanism.
2. To choose which one to implement: Start with the left side of the table (Static, Single-Hop, No Feedback). Move right only if you hit a forcing function (the roadmap covers these).
3. To explain the difference in an interview: Use the classification axes. "Self-RAG differs from Advanced RAG in three ways: agent-driven orchestration, iterative scope, and external feedback loop."
4. To spot opportunities for optimization: Check the "Latency Class" column. If you're at Medium or Slow, can you move left (simpler orchestration)?