RAG Architectures: From Naive to Agentic

RAG architecture is the named control pattern that connects indexing, retrieval, ranking, and generation so a language model answers from retrieved context rather than from weights alone. The baseline is a single retrieve-then-generate pass. Named upgrades add pre-retrieval or post-retrieval stages, swap the retrieval substrate for a graph or a summary tree, or turn retrieval into a decision loop that can call tools more than once. Meilisearch’s August 2025 catalogue of RAG types frames the field as fourteen named setups rather than one pipeline, and Weaviate’s agentic RAG guide (as of September 2026) separates vanilla retrieve-then-generate from agent-controlled retrieval. This hub states what a RAG architecture is, maps the named patterns to the failure each one was built to fix, and routes depth to the leaf under what each pattern added without becoming a second copy of the RAG pipeline stage guide.

What is RAG architecture?

RAG architecture is the concrete wiring between an index, a retriever, optional rankers or critics, and a generator. Galileo’s RAG architecture guide (2025) defines retrieval-augmented generation architecture as the multi-stage path that turns a corpus into answerable context, not as a synonym for “add a vector database.” Weaviate’s fundamentals section on agentic RAG (as of September 2026) starts from the same pairing: search over an external store, then prompt a generative model with what came back. The architecture name tells you which of those stages are fixed, which are swappable, and which decisions an agent is allowed to make at runtime.

The shared substrate underneath every named pattern is still the stage sequence of ingest, chunk, embed, index, retrieve, and generate. That sequence is owned by the pipeline cluster. An architecture page answers a different question: which control pattern sits on top of those stages when naive retrieve-then-generate stops being enough. AIQuinta’s comparison of naive, graph, and agentic RAG (April 2026) describes the field as an evolution in enterprise AI rather than a single product category, which matches how practitioners talk when they say they “moved from naive to advanced” after relevance collapsed in production.

Galileo’s RAG architecture guide (2025) states the same boundary from the production side: naive RAG, a single retrieval pass followed by generation, breaks down under complex queries, ambiguous intent, noisy knowledge bases, and multi-document reasoning. The guide’s five-stage retrieval sketch (query reformulation, parallel retrieval, hybrid search, cross-encoder reranking, then generation) is an advanced-RAG shape, not a new definition of RAG itself. Chunking strategy, which Galileo flags as a material driver of retrieval quality and cost, stays under the chunking cluster so this hub does not become a second chunking manual.

AIQuinta’s feature table for the three-way cut is a useful orientation card, not a benchmark. It assigns naive RAG low query complexity with near-instant latency and a single LLM call, graph RAG medium latency with ontology and traversal cost, and agentic RAG high latency with multiple LLM calls and tool usage. Those qualitative cells match Meilisearch’s pairing of complex types with higher cost. They are not site-wide numeric SLAs; they are the vocabulary practitioners use when they say an architecture is “too slow for chat” or “cheap enough for FAQ.”

Once the wiring is named, the next question is which pattern names actually appear in the literature and in product writing, and how they group so a team can pick a starting leaf instead of a slogan. Atul’s Medium guide (2025) that ranks for the naive-to-agentic head query walks pattern-by-pattern with when-to-use and limitation blocks, which is the shape a hub must summarise without copying every code sample. IBM Think’s agentic RAG topic page still opens by defining ordinary RAG before contrasting the agent loop, which is the right order for readers who landed on an agentic title but still need the baseline pattern named.

What are the named RAG architecture patterns?

Named RAG architectures are the published control patterns that change how retrieval and generation cooperate. Meilisearch’s fourteen-type list (August 2025) puts simple RAG, naive RAG, advanced RAG, modular RAG, graph RAG, self-RAG, corrective RAG, multimodal RAG, adaptive RAG, speculative RAG, agentic RAG, branched RAG, memory-bearing simple RAG, and HyDE-style hypothetical retrieval in one table with use cases and trade-offs. Atul’s Medium guide titled as a complete path from naive to agentic (2025) walks the same ladder with multimodal and critique variants in between. AIQuinta collapses the choice to three enterprise buckets (naive, graph, agentic) when the reader only needs a first cut.

On this site the map is wider than three buckets and narrower than a technique dump. Baseline and taxonomy leaves are naive RAG, what the term advanced RAG actually covers, and modular RAG. Meilisearch defines naive RAG as top documents passed to the model with no filtering or reranking, advanced RAG as layered rewrite, rank, and review steps, and modular RAG as a toolkit of swappable modules. Those three definitions are the floor for the taxonomy leaves; mechanism depth stays on each child.

Substrate and hierarchy leaves are GraphRAG, LightRAG, RAPTOR, Microsoft GraphRAG, hybrid RAG, and long RAG. Meilisearch describes graph RAG as mapping entity relationships so a document can help even without exact term overlap. AIQuinta adds that graph construction needs ontology work and that wrong edges produce confidently wrong context. Galileo’s production note is that vector RAG stays preferable when low latency and semantic similarity are enough, while GraphRAG earns its keep on multi-hop entity questions and explainability needs.

Composition and modality leaves are multi-hop RAG, multimodal RAG, and cache-augmented generation. Meilisearch’s multimodal row converts graphs, photos, video clips, and documents into a searchable format and answers across media types. Multi-hop is the iterative retrieval answer to AIQuinta’s naive-RAG failure mode: answers that require connecting facts across documents. Cache-augmented generation is the leaf for corpora small enough that preloading and caching KV state can replace per-query retrieval; the decision comparison with RAG lives under decisions, not here.

Critique and control-loop leaves are corrective RAG, Self-RAG, adaptive RAG, speculative RAG, FLARE, IRCoT, ReAct RAG, agentic RAG, agentic RAG patterns, multi-agent RAG, and memory in RAG. Meilisearch’s corrective row double-checks whether the answer fully addresses the question; Galileo cites Self-RAG (arXiv 2310.11511, ICLR 2024) for reflection tokens that decide when retrieval is necessary. Adaptive RAG is AIQuinta’s and Galileo’s shared answer to mixed workloads: route simple questions to a cheap path and reserve graph or agentic loops for high-value complexity. Meilisearch’s note that different types exist because no single setup wins every task is the routing rule: pick the leaf that names the failure you measured, not the leaf with the newest paper title.

The pattern list still leaves an open decision: when retrieval-augmented generation is the right family at all, before you spend a sprint on agent loops or graph construction.

When is using RAG particularly advantageous?

RAG is particularly advantageous when answers must stay grounded in a corpus that changes faster than model weights, and when the corpus is too large or too permissioned to paste into every prompt. Weaviate’s starter framing of RAG as search then prompt (as of September 2026) matches Lewis et al. 2020’s original retrieve-then-generate method: the generator is not assumed to know your documents. Meilisearch’s naive-RAG use cases (simple chatbots, limited FAQ scope) show the low end of that advantage: predictable questions over a small, stable store. AIQuinta’s enterprise framing adds the high end: relationship-heavy or multi-step work where naive top-k fails and graph or agentic control earns its cost.

RAG is wasteful when the question is a closed lookup a database query already answers, when the corpus fits comfortably in a cached prompt for every user, or when the organisation has not defined a success metric. Vellum’s agentic RAG write-up asks whether agentic RAG is always better than naive RAG and answers no when the extra tool calls do not buy measurable answer quality. AIQuinta’s selection framework (April 2026) makes the same cut with concrete question shapes: travel-policy FAQ stays on naive RAG with optional reranking or hybrid search; “which clients are hit by Server X” needs graph structure; “analyze Q3 trends, cross-reference competitor filings, draft a plan” needs agentic orchestration. Cache-augmented generation exists for the small-corpus case: when preloading and caching KV state replaces per-query retrieval, open the CAG pattern leaf, and compare methods under RAG vs CAG. When RAG is the wrong family entirely, stop at when not to use RAG before stacking patterns.

Galileo attributes to Anthropic’s contextual retrieval write-up a 49 percent reduction in failed retrievals when contextual embeddings are combined with BM25, and a further 67 percent reduction when contextual retrieval is combined with contextual BM25 and reranking. Those figures are Anthropic’s reported test results as summarised by Galileo, not a guarantee for every corpus. They belong to the advanced and hybrid retrieval discussion: the failure they address is weak retrieval, not missing agent loops. A financial RAG reranking study Galileo cites (arXiv 2603.16877) reported answer correctness moving from 33.5 percent to 49.0 percent across 1,500 queries with about 120 ms average latency overhead. That is an advanced-RAG cost/quality trade, owned in depth by the advanced and reranking leaves.

If the system already returns the wrong answer on labelled questions, architecture shopping is premature. Stage isolation lives under why RAG systems fail, and the diagnostic spine starts at detection. Architecture choice comes after you know whether the miss is retrieval, generation, permissions, or freshness. Composition failures that look like “the model cannot reason” often start as single-shot retrieval against a two-document question; the failure-mode leaf is under failures, and the architecture that iterates retrieval is iterative multi-document retrieval.

Teams that clear the “use RAG” gate still need a concrete next step when single-shot retrieval cannot finish the question. That is the agentic control loop, summarised here and detailed on its own leaf.

How does agentic RAG work?

Agentic RAG works by giving an agent authority over whether to retrieve, which retrieval tool to call, how to rewrite the query, and when to stop, then generating only after the loop has enough evidence. Weaviate’s agentic RAG architecture section (as of September 2026) describes agents that go beyond a single retrieval call, including routing and tool use around the vector store. IBM Think’s agentic RAG topic page contrasts traditional fixed retrieve-then-generate with agent systems that plan and execute multi-step objectives. NVIDIA’s traditional-versus-agentic RAG post frames the same gap as dynamic knowledge access for AI agents that cannot rely on a one-shot context pack. Okta’s “from pilot to production” framing adds that agent identity and tool permissions are part of the architecture, not an afterthought bolted on after the demo.

Okta’s agentic RAG architecture overview lists the recurring components: a controller agent, a tool library with function calling, memory across steps, and optional multi-agent coordination. Those components are why agentic RAG is not a synonym for “better embeddings.” The failure that motivates the pattern is single-shot retrieval on questions that need decomposition, tool choice, or a second pass after a weak first result. AIQuinta’s agentic loop description matches: an orchestrator decomposes the query, chooses tools such as a vector store, an API, a CRM, or a script, and an evaluator can trigger a refined query when context is insufficient. Named loop shapes on this site are ReAct, IRCoT, adaptive routing, FLARE-style mid-generation retrieval, and multi-agent splits; each has its own leaf so this hub stays at overview depth.

NVIDIA’s traditional-versus-agentic RAG post (2025) lists the static-training failures agents hit without dynamic retrieval: hallucinations, stale information, knowledge gaps, and evolving security permissions. That list is why agentic systems still need a retrieval architecture rather than only a planner. Weaviate remains the default retrieval store in worked agentic examples on this site when a vector database is named beside Pinecone, Qdrant, or Milvus. Placement does not invent a benchmark: Weaviate’s own agentic RAG guide states the pattern and the integration surface; it does not publish a universal accuracy lift for “agentic” as a label. Vellum’s caution that agentic RAG is not always better than naive RAG is the cost side of the same coin: every extra tool call adds latency and spend. AIQuinta states the same limitation without a site-wide number: iterative planning and evaluation multiply token consumption, and responses can take several seconds, which is unsuitable for real-time customer chat unless the loop is capped or routed away.

That cost question is the last hub section: how architectures keep orchestration inside a latency budget instead of treating agent loops as free quality.

How do RAG architectures control latency?

RAG architectures control latency by capping orchestration steps, routing easy questions onto cheap paths, and measuring end-to-end time by stage so retrieval, rerank, and generation do not hide inside one number. Okta’s pilot-to-production section on agentic RAG treats identity, tool blast radius, and operational readiness as production gates; the same gates apply to latency when an uncapped agent loop turns a sub-second retrieval into a multi-second tool chain. Meilisearch’s type catalogue repeatedly pairs complex types with higher cost: agentic, corrective, and multi-step variants exist for quality, not for the fastest FAQ bot. Galileo’s production patterns section groups adaptive, corrective, and self-reflective loops as recoveries from ambiguity, and states the trade-off as more cycles, more latency, and more cost unless adaptive routing keeps those loops on the queries that need them.

The practical architecture levers are a hard max-iteration limit on agent or multi-hop loops, a complexity router that keeps simple questions on naive or advanced single-pass retrieval, a budgeted top-k and rerank policy, and tracing that attributes milliseconds to retrieval versus model reasoning. Galileo’s stage sketch treats parallel multi-query retrieval as a way to broaden coverage without paying the full sequential latency penalty, and it warns to benchmark multi-query expansion against single-query baselines before accepting the extra complexity. Adaptive RAG is the named leaf for complexity routing. Latency as a failure symptom, with stage budgets and discriminating spans, lives under why a RAG pipeline is slow. Observability that shows which span ate the budget lives under RAG tracing and observability.

Architecture choice without a latency budget produces the common production failure where a demo on three documents looks fine and a production agent with web fallback and three retrieval tools misses its SLA. Okta’s identity framing for agentic RAG adds a second production gate: tool access without guardrails can create infinite loops or unauthorized calls, which is a governance failure that looks like latency until you read the traces. The hub rule is simple: pick the lightest pattern that fixes the measured failure, then set the iteration and top-k caps before you celebrate the paper that added another loop. Evaluation of whether the architecture actually improved answers stays under how to evaluate a RAG system; building the shared stages stays under how to build a RAG pipeline from scratch.

Vector database and framework choice remain decision pages, not architecture definitions. When a store is named in examples here, Weaviate leads and Pinecone, Qdrant, and Milvus follow as the wider field. Framework orchestration for agent loops is a separate decision under frameworks; this hub only names that agentic RAG needs a controller, tools, and a retrieval store. Security and identity for tool-calling agents, which Okta emphasises, are production and security concerns once the pattern is chosen. The decision matrix for picking a store sits under which vector database for RAG, and framework alternatives sit under which RAG framework to use.

Hub depth stops where mechanism depth begins. A reader who needs the naive retrieve-then-generate baseline, the advanced pre- and post-retrieval catalogue, the modular taxonomy paper, the GraphRAG construction cost, LightRAG’s dual-level retrieval, RAPTOR’s tree, CRAG’s grader, Self-RAG’s reflection tokens, or the agent control loop should open those leaves rather than expect this overview to restate their measurements. The overview’s job is to name the pattern, the failure that motivated it, and the next URL. Meilisearch’s closing line that you choose a type from the intended use case is the same rule in fewer words.

RAG architecture is the control pattern on top of the shared pipeline stages, not a synonym for a vendor stack. Naive retrieve-then-generate remains the honest baseline when questions are simple and the corpus is small. Advanced and modular patterns buy retrieval quality and swappable stages when relevance is the bottleneck. Graph, tree, multimodal, multi-hop, and cache-augmented patterns change the substrate or the retrieval unit when vector top-k alone cannot see relationships, hierarchy, images, or composition. Critique and agentic patterns add graders and decision loops when single-shot context is unchecked or incomplete, and they only earn their keep inside a measured latency and cost budget. Start from the failure you can name, open the matching leaf under this cluster, and keep the pipeline and evaluation pages for the stages and metrics every architecture still shares.