Types of RAG: from basic retrieval to GraphRAG and AI agents
RAG gives a language model material from documents, databases or the web before it answers. A simple version handles an internal FAQ, but more complex questions may need query rewriting, multiple sources, quality checks or several rounds of search. That is why different types and patterns of RAG exist today — and not all of them solve the same problem.
Three things worth knowing
- 1Naive, Advanced and Modular RAG describe the evolution of the whole architecture from a fixed pipeline to a flexible workflow.
- 2GraphRAG, Self‑RAG, CRAG or multimodal RAG are specific patterns that can be combined inside a modular architecture.
- 3The best RAG is not the most complex one. Start simple and add the next layer only based on a measured error.
What RAG is and why it came about at all
The abbreviation RAG stands for Retrieval‑Augmented Generation. The model doesn’t have to rely only on knowledge stored in its weights. It first retrieves relevant material and only then composes an answer from it. Thanks to this it can work with company documents, new information and sources it never saw during training.
RAG by itself, however, doesn’t guarantee truth. If the retriever brings an old or unrelated document, the model can produce a convincing-sounding error from it — good material reduces the risk of hallucinations but doesn’t eliminate it. Modern variants therefore improve not only generation but mainly the work before it: preparing documents, formulating the query, choosing the source, ranking results and checking evidence.
Three main paradigms: Naive, Advanced and Modular RAG
Research surveys often describe the evolution of RAG in three stages. These are not product editions or sharp boundaries. They are useful names for how much control and feedback we add around the basic retrieve → answer pipeline.
Naive RAG
The query is converted into an embedding once, a few nearest chunks are retrieved and the model answers from them. It is fast, cheap and excellent as a first measurable version.
Advanced RAG
Improves individual phases: contextual document splitting, metadata, query rewriting, hybrid search, reranking, context compression and answer verification.
Modular RAG
Composes retrieval, routers, memory, tools and control steps into a flexible graph. The system can skip some steps, branch or repeat the search.
1. Naive RAG: the best starting point
You split documents into chunks, create their embeddings and store them in an index. The user query goes through the same embedding model, the system takes, say, the five most similar chunks and adds them to the prompt. This is often enough for a product manual, internal guidelines or a knowledge base with well-written questions.
The weakness shows with vague phrasing, exact product codes, long documents and questions combining several facts. One query, one ranking of results and one generation give the system no room to correct a bad first step.
2. Advanced RAG: quality in every phase
Advanced RAG can still be linear, but it thinks through each part of the pipeline separately. Before searching, it adds context to chunks, filters by metadata or rewrites the question into a form better suited to the retriever. During search it combines semantic similarity with exact keywords. After search it re-ranks a broader set of candidates and lets only the best evidence into the model.
This is usually where the biggest practical benefit lies. A wrong answer is often caused not by a “weak model” but by a missing correct chunk. In Anthropic’s Contextual Retrieval tests, the combination of contextual embeddings and BM25 reduced the number of failed retrievals in their sets by 49% compared with baseline RAG; with reranking by 67%. It is not a universal guarantee, but a good example of why it makes sense to measure retrieval separately from generation.
3. Modular RAG: components and decisions
Modular RAG abandons the idea of a single fixed pipeline. A router can send the query to documents, a relational database or the web. A control module can reject the result, rewrite the query and search again. Memory adds the conversation context and a citation tool links sentences of the answer to specific sources.
Modularity makes it easier to combine the patterns that follow. The same system can use hybrid search for exact terms, GraphRAG for relationships and an agentic loop only for complex questions. The price is more components, more complex tuning and more room for errors in control.
Eight advanced types and patterns of RAG
The following names are not one flat taxonomy. They describe different properties: the retrieval method, the knowledge source, the control mechanism or the orchestration. In a production solution they commonly overlap.
Hybrid RAG
Combines semantic search via embeddings with lexical search, for example BM25. Embeddings understand meaning, while keywords precisely capture numbers, names, abbreviations and identifiers.
Suited to: technical documentation, catalogues, legal texts and anywhere both meaning and exact notation matter.
RAG‑Fusion
The model creates several semantically different versions of the question. Each is searched separately and the resulting rankings are merged, often using Reciprocal Rank Fusion. This reduces dependence on the user’s single phrasing.
Suited to: short, ambiguous or multi-layered queries where the first phrasing misses the vocabulary of the documents.
Adaptive RAG
First estimates the complexity of the question. A simple one it can answer without searching, a medium one it sends to a single retrieval step and a complex one it solves iteratively. It saves work where the full workflow isn’t needed.
Suited to: assistants with very diverse queries where you need to balance accuracy, latency and cost — similarly to reasoning models, which also think longer only on harder briefs.
Corrective RAG (CRAG)
An evaluator checks the relevance of the retrieved documents. On a weak result the system adjusts the query, cleans up the material or reaches for a fallback source, for example the web. This is not the benchmark of the same name, CRAG, but a corrective architecture.
Suited to: knowledge bases of variable quality and scenarios where it is better to repeat the search than to guess confidently.
Self‑RAG
The original Self‑RAG trains the model with special reflection tokens. The model learns to decide whether to search, whether a passage is relevant and whether the answer is supported and useful. It is not just a generic “check your answer” prompt.
Suited to: research or specialised deployments where it makes sense to modify the model and control retrieval directly during generation.
GraphRAG
Builds a graph of entities, relationships and often community summaries on top of the documents. It can search the local neighbourhood of a specific entity as well as answer global questions about topics across the whole corpus, which ordinary top‑k chunks easily miss.
Suited to: connected events, organisations, people, dependencies and summary questions over a large collection. More in the article on graph databases.
Agentic RAG
An AI agent treats retrieval as one of its tools. It decomposes the task, chooses the source, searches, compares the intermediate result and continues as needed. Its tools can be connected in a standard way via MCP, so it combines documents, SQL, web APIs and computations.
Suited to: open-ended analytical tasks and multi-source research. But it brings higher cost, latency and the need for limits and observability. We explain the principle of the agent loop in the article What is an AI agent.
Multimodal RAG
Retrieves and passes to the model not only text but also images, tables, charts, audio or video. For visually rich PDFs it can index a page directly as an image, so the meaning of the layout isn’t lost when converting to plain text.
Suited to: presentations, scanned contracts, technical drawings, tabular reports and image documentation.
Is “vector RAG” another type?
It rather denotes the retriever used than a whole paradigm. Similarly we can talk about SQL RAG, web RAG or knowledge‑graph RAG by source. Each of them can be simple, advanced, modular or part of an agentic workflow.
Three steps of RAG in code
The difference between RAG types is best seen in code. The following examples are simplified — functions like hledej or rerank stand in for your implementation — but they show exactly the place where the individual patterns add extra work.
Naive RAG has a twenty-line core
The whole baseline is nearest-neighbour search plus one prompt. You need neither a framework nor a vector database; for a few thousand chunks an in-memory array is enough. Build exactly this version first and measure it before you start adding layers.
from openai import OpenAI
import numpy as np
client = OpenAI()
chunks = nacti_uryvky("dokumentace/") # seznam textovych uryvku
def embed(texty):
odpoved = client.embeddings.create(
model="text-embedding-3-small", input=texty
)
return np.array([polozka.embedding for polozka in odpoved.data])
index = embed(chunks) # tvar (pocet_uryvku, dimenze)
def odpovez(dotaz, k=5):
# embeddingy OpenAI maji jednotkovou delku, skalarni soucin = kosinova podobnost
skore = index @ embed([dotaz])[0]
podklady = [chunks[i] for i in skore.argsort()[-k:][::-1]]
instrukce = (
"Odpovidej vyhradne z dodanych podkladu. "
"Kdyz odpoved v podkladech neni, rekni to.\n\n"
+ "\n---\n".join(podklady)
)
return client.responses.create(
model="gpt-4.1-mini",
input=[
{"role": "system", "content": instrukce},
{"role": "user", "content": dotaz},
],
).output_text
Note the system instruction. Even in the simplest version, RAG includes an explicit instruction to answer only from the material and to admit when information is missing.
Hybrid search and RAG‑Fusion add rankings
Hybrid RAG and RAG‑Fusion do essentially the same thing: run several searches and merge the results. Reciprocal Rank Fusion doesn’t need to compare scores from different systems, which is its main advantage — it works only with rank. The constant k (usually 60) dampens the influence of the top positions, so one overconfident retriever doesn’t overpower the others.
def rrf(zebricky, k=60):
"""Reciprocal Rank Fusion: slouci vic serazenych seznamu do jednoho."""
skore = {}
for zebricek in zebricky:
for poradi, doc_id in enumerate(zebricek, start=1):
skore[doc_id] = skore.get(doc_id, 0.0) + 1 / (k + poradi)
return sorted(skore, key=skore.get, reverse=True)
kandidati = rrf([
vektorove_hledani(dotaz, k=20), # semanticka podobnost
bm25_hledani(dotaz, k=20), # presna klicova slova, kody, nazvy
vektorove_hledani(prepis(dotaz), k=20), # RAG-Fusion: druha formulace
])
podklady = rerank(dotaz, kandidati[:20])[:5] # cross-encoder vybere finalni petici
Broad retrieval followed by reranking is the most common Advanced RAG recipe: search for twenty candidates, but let the five best into the model.
The corrective loop is just one more condition
CRAG, Adaptive and Agentic RAG rest on the same idea — insert a decision between search and answer. The simplest form is a single relevance check and at most one more round.
def odpovez_s_kontrolou(dotaz, max_pokusu=2):
for pokus in range(max_pokusu):
podklady = hledej(dotaz)
hodnoceni = ohodnot_relevanci(dotaz, podklady) # LLM nebo maly klasifikator
if hodnoceni.relevantni:
return generuj(dotaz, podklady)
if pokus + 1 == max_pokusu:
break
dotaz = preformuluj(dotaz, hodnoceni.duvod) # druhe kolo s lepsim dotazem
# Cesta "nevim" je soucast navrhu, ne selhani.
return "V dostupnych podkladech jsem odpoved nenasel."
The attempt limit belongs there from the start. Without it the loop easily becomes an expensive infinite cycle, and that is the most common way agentic RAG gets expensive.
Comparison of RAG types in practice
| Type or pattern | What it adds | Main benefit | Complexity |
|---|---|---|---|
| Naive RAG | One search and one generation | Fast and cheap baseline | Low |
| Advanced RAG | Better index, query, retrieval and reranking | Higher relevance of material | Medium |
| Modular RAG | Routers, loops, memory and swappable modules | Flexibility and flow control | Medium to high |
| Hybrid / Fusion | Multiple search methods or phrasings | Higher recall and robustness to vocabulary | Medium |
| Adaptive / CRAG | Decision-making and a corrective step | Less wasted work and fewer blind answers | Medium to high |
| Self‑RAG | Learned self-reflection inside the model | Control of retrieval and answer support | High |
| GraphRAG | Entities, relationships and hierarchical summaries | Multi‑hop and global questions | High |
| Agentic RAG | Planning and repeated use of tools | Complex multi-source tasks | High |
| Multimodal RAG | Retrieval of text and other modalities | Working with visually rich sources | Medium to high |
RAG, fine‑tuning, or long context?
Before you start choosing a RAG type, check that RAG is the right tool at all. Three approaches solve three different problems and in practice they are often combined.
RAG
Content changes, you need citations, access control and the ability to pull a document out of circulation immediately. An update means reindexing, not retraining.
Fine‑tuning
Teaches the model how to answer: format, style, domain language, consistent output structure. For frequently changing facts it is expensive and sources are hard to trace.
Long context
When all the material fits into one prompt, you don’t need retrieval. But cost and latency grow with length and models tend to lose information in the middle of the input.
Practical rule: handle knowledge with retrieval, behaviour with fine‑tuning, and treat long context as a supplement for a few dozen pages per query. Even with a model that handles a million tokens, it pays to select relevant passages first — a shorter and cleaner context tends to be cheaper and more accurate than stuffing the whole archive into the prompt.
How to choose the right type of RAG
Start with the nature of the questions and errors, not the name of a framework. A practical router can look like this:
For regulated or critical answers, regardless of the chosen type, add permissions, citations, freshness checks, the ability to refuse an answer and human approval where an error can cause harm. More complex RAG is no substitute for data governance or security.
What to build RAG with
Specific tools change faster than principles, so treat them as a starting signpost. For orientation it helps to divide them by role in the system:
When choosing, ask four things: does it handle hybrid search, filtering by metadata and permissions, returning citations and connecting to evaluation? The rest is mostly a matter of operational preference.
What to measure before adding another layer
Evaluating only the final text is not enough. Separate whether the system found the right evidence, whether the model used it and how much the whole process costs. Otherwise you may change the generator because of an error in the index.
Start with a set of real user questions including vague, unanswerable and permission-restricted cases. Only when you find, for example, that the system doesn’t find exact designations, add BM25. When it fails on relationships across multiple documents, consider a graph or iterative retrieval. The architecture thus grows from data, not from fashionable names.
Common mistakes when building RAG
- Chunks too large or too small. The first bring noise, the second lose meaning. Test the splitting by document and question type.
- More context at any cost. Dozens of average passages can drown the right evidence. Broader retrieval followed by reranking and a smaller top‑k helps.
- No metadata and permissions. Customer separation, document validity, language and access rights belong in the filter before generation.
- One metric for the whole system. Without separate evaluation of retrieval you won’t know whether the search, the prompt or the model is failing.
- Missing “I don’t know” path. RAG must be able to admit that it found no evidence instead of filling in the missing information from a guess.
- An agent in the very first version. Loops and tools multiply cost and possible failures. First build a simple baseline, logging and an evaluation set.
- Ignoring updates. Track the origin, version and date of documents, delete invalid embeddings and test that new content is actually findable.
Key takeaways
Naive, Advanced and Modular RAG describe the growing flexibility of the whole architecture. Hybrid search, RAG‑Fusion, Adaptive RAG, CRAG, Self‑RAG, GraphRAG, Agentic RAG and multimodal RAG are specific ways to address different weaknesses or data sources. They can be composed, but every layer must have a measurable reason.
For most teams the best path is incremental: quality documents, simple retrieval, citations and an evaluation set; then hybrid search and reranking. Add a router, graph or agent only when the baseline demonstrably isn’t enough.
Want to build RAG and AI agents hands-on?
In the AI Agent Developer course we connect language models, vector databases, RAG, tools and agentic workflows in Python. We don’t stop at diagrams: you design, program and measure the individual components on a real project.
Sources and further reading
- Retrieval‑Augmented Generation for Knowledge‑Intensive NLP Tasks — the original paper that introduced the term RAG
- Retrieval‑Augmented Generation for Large Language Models: A Survey — survey of Naive, Advanced and Modular RAG
- Anthropic: Introducing Contextual Retrieval — contextual embeddings, BM25 and reranking
- Self‑RAG — the original paper on retrieval and reflection tokens
- Corrective Retrieval Augmented Generation — the original CRAG paper
- Adaptive‑RAG — choosing the strategy by question complexity
- RAG‑Fusion: A New Take on Retrieval‑Augmented Generation — multiple query phrasings and merging of results
- Reciprocal Rank Fusion — the original rank-merging method (Cormack et al., SIGIR 2009)
- Microsoft GraphRAG — official documentation for local, global and DRIFT search
- ColPali — visual retrieval of document pages for multimodal RAG
- Ragas — a library of metrics for RAG evaluation
