Types of RAG: A Comprehensive Taxonomy of Retrieval-Augmented Generation

Introduction

Retrieval-Augmented Generation has evolved far beyond its original formulation. In 2020, Lewis et al. defined RAG as a simple sequence: retrieve a document, then generate an answer conditioned on that document. Today, the term covers a family of architectures that differ in how they retrieve, when they retrieve, how many times they retrieve, and what they do with the retrieved information.

This taxonomy is based on the comprehensive RAG survey by Gao et al. (2023), extended with architectures that have emerged since: agentic RAG, graph RAG, corrective RAG, and structured RAG. We organise the approaches into three generations — naive, advanced, and modular — and then examine specialised variants that make different trade-offs between accuracy, latency, cost, and complexity.

If you are new to RAG fundamentals, start with our post on best RAG practices before diving into the taxonomy.

Naive RAG: The Simplest Pattern

Naive RAG is the original architecture: index documents, retrieve the top-K most similar chunks at query time, and concatenate them into the prompt for generation. It is the baseline against which all other approaches are measured.

The pattern is seductively simple. A weekend project yields a working demo. But naive RAG has known failure modes:

• Retrieval failure: The embedding model fails to match the query to relevant documents, so the LLM receives irrelevant context and produces a wrong or hallucinated answer.
• Context overload: Too many chunks are stuffed into the context window, diluting the relevant signal and confusing the LLM.
• Missing integration: The retrieved chunks are concatenated without reasoning about which information is relevant, redundant, or contradictory.

# Naive RAG — simplest form
def naive_rag(query, chunks, llm):
    # 1. Embed query
    q_emb = embed(query)
    # 2. Retrieve top-K chunks
    results = cosine_similarity(q_emb, [c.emb for c in chunks])
    top_k = [chunks[i] for i in results.argsort()[-3:]]
    # 3. Generate with context
    context = "\n".join(top_k)
    return llm.generate(f"Context: {context}\nQ: {query}")

Despite its limitations, naive RAG is the right starting point for 80% of use cases. It is easy to implement, easy to debug, and it establishes a baseline. Only when you measure a specific failure (low recall, low faithfulness, high latency) should you consider a more complex architecture.

Advanced RAG: Pre-Retrieval, Retrieval, Post-Retrieval

Advanced RAG introduces optimisations at each of the three pipeline stages without changing the fundamental architecture.

Pre-Retrieval Optimisation

Before the query touches the vector database, we can improve its quality. Query rewriting (expanding abbreviations, resolving pronouns), query decomposition (breaking a complex question into sub-questions), and query expansion (generating synonyms and related terms) all increase the chance of matching the right documents. These techniques are covered in depth in our best practices guide.

Retrieval Optimisation

At retrieval time, the most impactful optimisation is hybrid search — combining dense embeddings with sparse keyword retrieval (BM25) through reciprocal rank fusion. Hybrid search consistently recovers relevant results that pure semantic search misses, particularly for exact phrase matches and rare terms.

Multi-representation indexing (introduced by Chen et al., 2024) is another important technique. Instead of storing a single embedding per chunk, store multiple embeddings for different aspects of the chunk (e.g., a summary, key entities, important claims). The query matches the aspect representation that aligns with its intent.

Post-Retrieval Optimisation

After retrieval, re-ranking with a cross-encoder is the standard optimisation. Retrieve top 20 with an efficient ANN search, re-rank to top 3-5 with a more expensive but more accurate model. Cross-encoders like Cohere Rerank and BGE-Reranker-v2 consistently improve precision by 10-20% over the initial retrieval.

Prompt compression (LLMLingua, Selective Context) reduces the number of tokens passed to the LLM while preserving the most important information, reducing both cost and latency.

Modular RAG: Pluggable Components

Modular RAG treats each pipeline stage as an independent, swappable module. The architecture is defined by a configuration rather than hard-coded logic. This design — popularised by LangChain and LlamaIndex — allows teams to experiment with different strategies without rewriting the pipeline.

In a modular RAG system, you can:

• Swap the embedding model without changing the retrieval logic
• Replace the vector database by changing a connection string
• Add a re-ranking step by inserting a module between retrieval and generation
• Enable or disable query transformation per request

LangChain's expression language (LCEL) is the most mature framework for modular RAG. At Syntave, we take modularity one step further: each component is abstracted behind a unified API that works across providers, so you can switch from LangChain to LlamaIndex to a custom implementation without touching your application code. See how we abstract the RAG pipeline.

Corrective RAG (CRAG): Retrieval Result Correction

CRAG, introduced by Yan et al. in 2024, adds a retrieval evaluator that scores the relevance of each retrieved document. If the scores fall below a threshold, the system triggers corrective action — typically a web search to supplement the knowledge base retrieval.

The CRAG architecture has three branches:

• Correct: Retrieved documents are relevant. Proceed with standard generation.
• Incorrect: Retrieved documents are not relevant. Trigger web search or alternate retrieval source.
• Ambiguous: Some documents are relevant, some are not. Split the set, use the relevant ones, and supplement with web search for the rest.

CRAG is particularly valuable when your knowledge base is incomplete. If a user asks about a topic that was added to the documentation yesterday but your index was last updated last week, CRAG falls back to the web and still produces a correct answer. We recommend CRAG as an enhancement layer on top of any production RAG system.

Self-RAG: Reflection Tokens and Self-Critique

Self-RAG (Asai et al., 2023) trains the model itself to control retrieval and critique its own outputs. Rather than an external evaluator, Self-RAG fine-tunes the LLM to generate special reflection tokens:

• Retrieve token: Should the model retrieve external information for this query? If yes, retrieve and condition the generation on the retrieved passages.
• Relevance token: Are the retrieved passages relevant to the query? If not, ignore them or retrieve again.
• Support token: Is the generated response supported by the retrieved passages? If not, revise the response.
• Utility token: Overall, how useful is this response for the user? Used for ranking multiple candidate responses.

Self-RAG has been shown to outperform standard RAG on factual accuracy benchmarks by 10-20%, while also reducing unnecessary retrievals by 30-50%. The trade-off is complexity: Self-RAG requires fine-tuning the base model with special training data that includes reflection token annotations. It is best suited for teams that already have a fine-tuning pipeline and want to push RAG accuracy to the frontier.

Adaptive RAG: Dynamic Query Routing

Adaptive RAG (Shao et al., 2024) recognises that not all queries need the same RAG treatment. A simple factual question (“What is the capital of France?”) can be answered directly by the LLM with no retrieval. A moderately complex question (“What are Syntave's data residency options?”) needs a single retrieval pass. A complex multi-hop question (“How does Syntave handle data residency for EU customers using the Qdrant integration?”) may require iterative retrieval with intermediate reasoning.

Adaptive RAG uses a lightweight classifier — typically a small transformer or even a set of heuristics — to route each query to the appropriate pipeline. The routing decision can be based on query length, domain, presence of entities, or the output of a small classifier model.

# Adaptive RAG — query routing
def adaptive_rag(query, llm):
    complexity = classify_query_complexity(query)
    if complexity == "simple":
        return llm.generate(query)  # No retrieval
    elif complexity == "medium":
        return standard_rag(query)  # Single retrieval
    elif complexity == "complex":
        return iterative_rag(query) # Multi-step retrieval + reasoning
    else:
        return web_search_rag(query)# Fallback to web

The practical benefit is significant cost and latency reduction. In our production deployments at Syntave, Adaptive RAG routes approximately 30% of queries to the “no retrieval” path (latency 300ms, cost $0.0002), 50% to standard RAG (latency 1.2s, cost $0.002), and 20% to complex iterative RAG (latency 3s, cost $0.01). Compared to applying the most expensive pipeline to every query, this saves roughly 50% on total inference cost.

Agentic RAG: Agents as Retrievers and Reasoners

Agentic RAG replaces the fixed retrieval pipeline with an autonomous agent that decides which tools to call, in what order, and how to integrate the results. The agent has access to multiple tools: vector database search, web search, code execution, SQL queries, and the LLM itself.

A typical agentic RAG workflow for a complex question might look like:

1. The agent decomposes the query into sub-questions
2. It queries the vector DB for each sub-question
3. It finds contradictory information in the retrieved chunks
4. It decides to run a SQL query against the production database to resolve the contradiction
5. It synthesises the results into a coherent answer with citations

Agentic RAG is the most flexible but also the most unpredictable architecture. The agent may take too many steps, call the wrong tool, or get stuck in a loop. Production deployments require guardrails: maximum step limits, timeout enforcement, and human-in-the-loop approval for destructive actions.

For a deep dive into agent architectures and frameworks, see our post on agentic AI architecture.

Graph RAG: Knowledge Graphs + RAG

Graph RAG, pioneered by Microsoft Research in 2024, combines structured knowledge graph traversal with unstructured document retrieval. Instead of treating documents as independent chunks, Graph RAG builds a knowledge graph that captures entities, relationships, and the documents where they appear.

The retrieval process has two phases. First, entities mentioned in the query are used to traverse the graph and gather related entities and relationships. Second, documents linked to those entities are retrieved from the vector database. The combination of graph context (relationships) and document context (detailed explanations) provides richer grounding than either alone.

# Graph RAG: traverse entities then retrieve
def graph_rag(query, kg, vector_db, llm):
    # Step 1: Extract entities from query
    entities = llm.extract_entities(query)
    # Step 2: Traverse knowledge graph for relationships
    related = kg.traverse(entities, depth=2)
    # Step 3: Retrieve documents linked to entities
    doc_ids = [e.doc_id for e in related if e.doc_id]
    docs = vector_db.fetch(doc_ids)
    # Step 4: Generate with both graph context and documents
    context = format_context(related, docs)
    return llm.generate(f"Context: {context}\nQ: {query}")

Graph RAG excels at multi-hop reasoning questions (“Which customers use the same vector database as Acme Corp?”) that require following chains of relationships. It also reduces hallucinations for entity-centric questions, since the graph provides a structured, verifiable representation of facts. The trade-off is significant indexing complexity: building and maintaining the knowledge graph requires entity extraction, relation extraction, and entity resolution pipelines.

Multi-Modal RAG: Text + Images + Tables

Modern documents are rarely pure text. They contain images, diagrams, tables, charts, and code blocks. Multi-modal RAG extends the retrieval pipeline to handle multiple modalities.

The standard approach uses a multi-modal embedding model (like CLIP or SigLIP) that embeds images and text into a shared embedding space. At query time, a text query can retrieve both text chunks and relevant images. A multi-modal LLM (like GPT-4o or Claude 3.5 Sonnet) then generates answers that can reference both the text and image evidence.

For tables, a common pattern is to serialise them as structured text (Markdown or JSON) before embedding, and to use a table-aware LLM to reason about them. Some systems also generate natural language summaries of tables — “captioning” — and embed those summaries alongside the raw data.

Multi-modal RAG is essential for domains like medical imaging (X-ray + radiology reports), legal (contract text + signature scans), and engineering (code + architecture diagrams). It adds complexity to the indexing pipeline but dramatically expands the range of questions the system can answer.

Hybrid RAG: Multiple Retrieval Strategies Combined

Hybrid RAG combines retrieval from multiple sources and strategies, fusing the results into a single ranked list. This is distinct from hybrid search (which combines dense and sparse retrieval) — hybrid RAG combines entirely different retrieval pipelines.

A typical hybrid RAG system might combine:

• Vector search: Semantic similarity from embeddings
• Keyword search: BM25 / Elasticsearch for exact phrase matching
• SQL query: Structured data from a relational database
• Graph traversal: Entity-relationship paths from a knowledge graph

The results from each strategy are normalised (rank-based rather than score-based), merged using reciprocal rank fusion, and presented to the LLM as a unified context block. The LLM does not know — or need to know — which strategy produced which result.

Hybrid RAG is the most robust approach for heterogeneous knowledge bases. A document corpus might contain policies (best served by semantic search), product codes (keyword search), customer records (SQL), and compliance relationships (graph). No single retrieval strategy works for all four. At Syntave, our unified API supports hybrid RAG out of the box — see our documentation for configuration details.

Structured RAG: Extracting Structured Data Before Generation

Structured RAG inverts the usual flow: instead of retrieving raw text and letting the LLM extract information, it extracts structured data from the documents first and stores it in a queryable format (JSON, knowledge graph triples, or database rows). Retrieval operates on the structured representation, and generation consumes either the structured data or a natural language rendering of it.

For example, a document about a product might be indexed as:

{"name": "Syntave Core", "version": "2.1", "features": ["RAG API", "Multi-tenant", "SSO"], "pricing": {"starter": "$0.01/query", "enterprise": "custom"}}

A query like “What version supports SSO?” retrieves this JSON structure, and the LLM reads the structured data to answer. This approach eliminates the need for the LLM to parse and extract from noisy text at inference time, reducing hallucinations and improving latency.

Structured RAG is ideal for use cases where documents have well-defined schemas: product catalogs, compliance documents, API documentation, and employee handbooks. It requires upfront investment in schema design and extraction pipelines, but the payoff in retrieval precision and answer faithfulness is substantial.

Comparison Table and When to Use Each

The table below summarises the key characteristics of each RAG type across the dimensions that matter most in production.

How to Choose Your RAG Architecture

With so many options, the natural question is: which one should I use? Our recommendation, based on dozens of production deployments, is a progression:

1. Start with Advanced RAG. Good chunking, a solid embedding model, hybrid search, and re-ranking handle 90% of use cases. Do not over-engineer from day one.
2. Add Corrective RAG when you see retrieval failures. If the evaluation shows that the system cannot answer questions about topics in the knowledge base, CRAG provides a safety net.
3. Add Adaptive RAG when your query distribution is bimodal. If some queries are trivially answered by the model and others require deep retrieval, routing saves cost and latency.
4. Add Graph RAG or Agentic RAG only when you need multi-hop reasoning. These are powerful but operationally expensive. Make sure the use case justifies the complexity.

The through-line is measurement. Every architecture decision should be validated against your evaluation set. If Self-RAG improves faithfulness by 2% but adds two weeks to your deployment cycle, is it worth it? Only your data can answer that.

For a deeper look at the chunking decisions that underpin every RAG variant, see chunking strategies for RAG. And if you are choosing between RAG and fine-tuning, our decision framework will help you decide.