RAG Architectures: From Naive to Agentic
The named patterns, what each one added, and the failure that motivated it. A router, not a survey.
A RAG architecture is the concrete pattern for how retrieval, ranking, and generation connect; it evolves from naive retrieve-then-generate pipelines to agentic decision loops. Use this hub to pick a starting pattern by intent, then jump to the leaf that explains the mechanism.
What is RAG architecture?
RAG architecture is the named control pattern that decides how indexing and retrieval feed generation so the model answers from retrieved context. The baseline looks like index → retrieve → generate, and every “modern” variant adds a deliberate upgrade step (before retrieval, during retrieval, or after retrieval) or changes the retrieval substrate.
The stage-by-stage workflow that every architecture sits on is the RAG pipeline; this hub names the pattern, then routes to the leaf that owns it.
What are RAG architectures?
RAG architectures are named patterns for how a system retrieves evidence and turns it into an answer. This router groups every `/architectures/*` child in one place so you can start from a pattern name instead of guessing at the pipeline stage.
When is using RAG particularly advantageous?
RAG is particularly advantageous when you need grounded, document-specific answers and you cannot treat knowledge as fixed inside the model weights. It can be wasteful for simple or stable lookups where classic retrieval or fine-tuning is a more direct solution than retrieval plus generation.
Quick choice
Start with Naive RAG for quick prototypes and simple questions, then move to Advanced RAG when retrieval quality is the bottleneck. Use Agentic RAG when the system must decide whether and how many retrieval steps to run (and you can afford the orchestration cost). For “when not to use RAG”, route to the decision page. If the system already returns the wrong answer, diagnose by stage on why RAG systems fail before stacking another architecture.
How does agentic RAG work?
Agentic RAG works by turning retrieval into a control loop: an agent decides whether to retrieve, runs retrieval actions, observes the results, and repeats until it has enough evidence to generate the answer. This improves multi-step and hard-to-decompose questions, but it adds extra tool calls and can increase end-to-end latency if the loop is not capped.
This is the default loop structure most agentic architectures follow:
- Plan the next retrieval action based on the question and any available context.
- Retrieve candidates and optionally expand the query or rerank them for the current step.
- Observe which evidence was found and whether it resolves the sub-goal.
- Repeat or stop with a fixed budget so the loop cannot run away.
- Generate the final answer from the accumulated retrieved context.
Routing by loop shape
If you want named control-loop variants, jump to ReAct RAG and IRCoT, then compare against the baseline at Naive RAG.
How to improve latency in RAG?
Latency improves when an architecture caps orchestration steps and routes simple questions onto cheaper retrieval paths. In practice this means setting explicit retrieval and reasoning budgets, limiting agent iterations, and measuring end-to-end latency by component so you can see whether the time is in retrieval, reranking, or reasoning.
Common latency levers you can apply at architecture level:
- Cap agent or multi-step retrieval iterations with a hard max-iteration limit.
- Route by query complexity so only hard questions trigger multi-hop or deep graph traversal.
- Budget top-k sizes and reranking frequency to keep retrieval work inside a target window.
- Measure end-to-end latency and break it down into retrieval time and model reasoning time.
Debug by attribution
When latency is the symptom, use RAG tracing and observability to pinpoint the stage that consumes the budget, then choose the pattern that removes that bottleneck.
What is RAG architecture?
A RAG architecture is the named control pattern that defines how indexing and retrieval feed generation. It answers from retrieved context instead of relying on weights alone, and each named architecture changes either retrieval quality, orchestration logic, or how many retrieval steps the system runs. Start with Naive RAG at /architectures/naive/ and then move to the upgraded pattern when you hit a specific limitation.
What are the main RAG architectures?
The main RAG architectures are named retrieval-and-generation patterns such as Naive RAG (retrieve-then-generate), Advanced RAG (pre/post retrieval upgrades), Modular RAG (swappable pipeline parts), GraphRAG variants (graph substrate retrieval), and Agentic RAG (retrieval as a decision loop). This hub collects every /architectures/* child so you can jump directly to the mechanism leaf for the pattern you want to apply.
When is using RAG particularly advantageous?
RAG is particularly advantageous when you need grounded, document-specific answers and you cannot treat knowledge as fixed inside the model weights. It can be a poor fit for simple or stable lookups where classic retrieval or fine-tuning is a more direct solution than retrieval plus generation. Use the /decisions/when-not-to-use-rag/ page to validate the choice.
How does agentic RAG work?
Agentic RAG works by turning retrieval into a control loop: the system decides whether to retrieve, runs retrieval actions, observes what it found, and repeats until it has enough evidence to generate the answer. This improves multi-step and hard-to-decompose questions, but it adds extra tool calls, so you should cap the loop to control cost and latency.
How do I improve latency in RAG?
You improve latency by limiting orchestration steps and routing easy queries onto cheaper retrieval paths. Architecturally, this means capping iterations, keeping retrieval and reranking budgets inside a target window, and measuring end-to-end latency by component so you know whether the time is in retrieval, reranking, or reasoning. Use /evaluation/tracing/ to attribute the bottleneck.
What is a RAG architecture?
A RAG architecture is the named control pattern that decides when to retrieve, how candidates are selected and refined, and how generation uses that context — Naive, Advanced, Modular, Agentic and the specialised patterns that hang off them. It is not the stage-by-stage pipeline diagram; that workflow lives on the pipeline hub. This architectures hub routes by the failure each pattern was built to fix.
What is the difference between naive and advanced RAG?
Naive RAG is a single retrieve-then-generate pass: embed the query, take top-k by similarity, generate. Advanced RAG keeps that shape but adds pre-retrieval, retrieval and post-retrieval upgrades — query rewriting, hybrid scoring, reranking, compression — so each stage fails less often. The Advanced hub maps those stage upgrades; Modular and Agentic change the control loop itself and are siblings, not synonyms.
What is agentic RAG?
Agentic RAG embeds an autonomous control loop into retrieval: an agent decides whether to retrieve, what to retrieve, and how often, using patterns such as reflection, planning, tool use and multi-agent coordination. Singh et al.’s Agentic RAG survey (arXiv:2501.09136) frames that shift from static retrieve-then-generate pipelines. Depth lives on the Agentic RAG page; recurring patterns and multi-agent coordination have their own leaves.
Which RAG architecture should I start with?
Start with Naive RAG for a demo or a small, stable corpus where latency matters more than precision. Leave Naive when you hit a named failure — irrelevant chunks, multi-hop composition, relationship questions, mid-query critique — and open the architecture that was built for that break. If you do not yet know which failure you have, diagnose on the failures hub first rather than stacking patterns.