Updated September 2026 · Practical architecture guide

RAG patterns: choose the smallest architecture that fixes the real failure

Retrieval-Augmented Generation is no longer one pattern. Production systems combine lexical and semantic retrieval, metadata, rerankers, context-preserving indexing, graphs, corrective loops, and agents. The right design depends on what your baseline gets wrong.

Offline knowledge preparation
Load & parse
→
Chunk & enrich
→
Embed / index
Online answer path
Route / rewrite
→
Retrieve + rerank
→
Generate + cite
Add graph, corrective, or agentic behavior only when evaluation shows that a fixed retrieval path cannot handle the query class reliably.
Start here

RAG is a system design choice, not a checkbox

A strong 2026 RAG design starts by proving that retrieval is needed, then separating retrieval quality from generation quality. Public recipes are useful starting points; your own query set should decide which pattern survives.

1. Test a long-context baseline

If the relevant corpus fits comfortably in context and cost/latency are acceptable, full-context prompting can be simpler than building retrieval infrastructure.

2. Fix recall before reasoning

If the correct evidence never enters the candidate set, a larger generator or more elaborate prompt will not reliably repair the system.

3. Keep retrieval explainable

Preserve document IDs, permissions, chunk lineage, scores, reranker outputs, and citations so failures can be diagnosed and reproduced.

4. Earn complexity with evals

Graphs, corrective loops, and agents add indexing or runtime cost. Introduce them for a measured failure mode, not because they sound more advanced.

Foundational architecture

Two pipelines: knowledge preparation and query-time reasoning

The original page correctly separated ingestion from inference. The updated version makes the control points explicit: permissions, context enrichment, multiple retrieval channels, reranking, citations, and evaluation.

Offline / asynchronous knowledge preparation

Build the evidence layer
Load & parseFiles, databases, APIs, web pages, tables, images and metadata.
Normalize & governPermissions, document IDs, timestamps, tenancy, provenance and PII rules.
Chunk & enrichChunk boundaries, parent IDs, titles, contextual headers, summaries or graph entities.
RepresentDense embeddings, sparse/lexical representation, multi-vector or graph structures.
IndexVector, lexical, structured, graph or multimodal indexes with update strategy.

Online / query-time answer path

Find, select, answer
Classify / routeDecide whether retrieval is needed and which corpus or tool should answer.
Transform queryRewrite, decompose, expand or generate multiple retrieval queries when useful.
Retrieve candidatesDense, sparse, metadata, graph, SQL, web or multimodal retrieval.
Fuse & rerankDeduplicate, rank-fuse and rerank a larger candidate set into final evidence.
Generate & verifyAnswer from selected evidence, cite sources, evaluate confidence and trigger fallback.
Architecture selection map

Escalate by failure mode, not by fashion

This replaces the old numeric bubble chart. The map is intentionally qualitative: it shows what kind of problem each family addresses without pretending that “complexity 8/10” is an objective measurement.

RAG pattern decision map
Move right only when the pattern to the left fails a defined evaluation target.

1. Establish the baseline

Prove whether retrieval is needed and whether simple dense retrieval is adequate.

Long-context baselineFlat vector RAGMetadata filters

2. Improve retrieval quality

Use when correct evidence exists but phrasing, exact terms, or ranking create misses.

Hybrid searchQuery transformationRerankingMulti-vector / late interaction

3. Preserve or add structure

Use when chunks lose document context or answers depend on hierarchy and relationships.

Contextual retrievalParent-childRAPTOR / hierarchicalGraphRAGMultimodal RAG

4. Add adaptive control

Use when the system must decide whether/how to retrieve, recover from weak evidence, or select tools dynamically.

Corrective RAGSelf-reflective RAGAgentic retrieval
Important: GraphRAG, corrective RAG and agentic RAG are not automatically “better.” They trade simplicity for broader query coverage, recovery or reasoning. Benchmark them against a simpler baseline.
Pattern library

Fourteen practical RAG patterns and when to use them

Filter by where the pattern acts. Each card explains the failure it addresses, the main trade-off, and the evidence you should collect before adopting it.

Long-context baseline

Baseline

Provide the relevant corpus directly when it fits the model context and latency/cost remain acceptable.

Best when
Small or bounded knowledge sets, high need for simplicity, few permission boundaries.
Watch for
Distracting context, repeated token cost, stale snapshots and weak corpus-level access controls.
What to measure

Task success, citation quality, latency and cost versus a retrieval baseline. Do not assume a bigger context window makes retrieval unnecessary.

Flat vector RAG

Baseline

Chunk documents, embed them, retrieve top-k nearest neighbors, then generate from the selected evidence.

Best when
Semantic Q&A over a moderately sized corpus with straightforward questions.
Watch for
Exact identifiers, chunk ambiguity, weak filters and noisy top-k context.
What to measure

Recall@k of answer-bearing chunks, context precision, answer groundedness, latency and cost.

Metadata filtering & routing

Retrieval

Constrain search by tenant, source, product, date, document type, geography or permissions before/alongside semantic retrieval.

Best when
The corpus is heterogeneous or access boundaries matter.
Watch for
Incorrect metadata extraction, over-filtering and inherited permissions.
What to measure

Filter accuracy, empty-result rate, recall within the filtered corpus and permission violations.

Hybrid retrieval

Retrieval

Fuse lexical retrieval such as BM25 with dense semantic retrieval so exact terms and conceptual similarity can both contribute.

Best when
Queries include names, IDs, acronyms, citations, SKUs or technical terms as well as natural-language concepts.
Watch for
Fusion weights and duplicate candidates; tune on real queries.
Current note

Hybrid lexical + semantic retrieval is now a mainstream production pattern. Anthropic’s contextual retrieval recipe explicitly combines BM25 and embeddings before reranking.

Query transformation

Retrieval

Rewrite, expand, decompose or generate multiple search queries before retrieval.

Best when
User language is ambiguous, conversational, multi-part or poorly aligned with corpus terminology.
Watch for
Query drift and extra model calls; preserve the user’s original intent.
Variants

Multi-query, decomposition, step-back questions and hypothetical-document-style query expansion are useful variants, but should be evaluated per query class.

Reranking

Retrieval

Retrieve a broader candidate set quickly, then use a stronger relevance model to reorder and trim evidence before generation.

Best when
First-stage recall is good but too many weak candidates pollute context.
Watch for
Added latency and cost, especially with many or long candidates.
Current note

Modern rerankers can score lexical, semantic and semi-structured candidates; keep first-stage retrieval broad enough that the reranker has the right document to promote.

Contextual retrieval

Indexing

Prepend chunk-specific context: such as document identity, section, time period or surrounding meaning: before building dense and lexical indexes.

Best when
Individual chunks are ambiguous once separated from the document.
Watch for
Additional indexing work and the risk of generated context introducing noise.
Evidence

Anthropic reported substantially fewer retrieval failures from contextual embeddings + contextual BM25, with further gains from reranking. Treat those results as vendor experiments and reproduce on your corpus.

Parent-child retrieval

Indexing

Index small child chunks for precise matching, then return a larger parent section or document window for generation.

Best when
Small chunks retrieve well but omit definitions, tables, qualifiers or surrounding narrative.
Watch for
Overly large parents can reintroduce context noise and token cost.
What to measure

Retrieval recall using children, answer quality using parent context, and context utilization rather than just token volume.

Hierarchical / RAPTOR-style retrieval

Indexing

Build multi-level representations: chunks, clusters and summaries: so retrieval can operate at different levels of abstraction.

Best when
Long documents or collections require both detail retrieval and higher-level synthesis.
Watch for
Index build cost, update complexity and summary drift in frequently changing corpora.
Research basis

RAPTOR recursively clusters and summarizes chunks into a tree. More recent work continues to explore lower-cost and more update-friendly hierarchical variants.

Multi-vector / late-interaction retrieval

Retrieval

Represent a document with multiple token- or region-level vectors rather than compressing all meaning into one vector.

Best when
Fine-grained matching matters and single-vector embeddings miss local evidence.
Watch for
Larger indexes and more specialized retrieval infrastructure.
Research basis

ColBERT-style late interaction separates efficient document encoding from fine-grained query-document matching; multimodal descendants apply similar ideas to visually rich documents.

GraphRAG

Structured

Extract entities, relationships and communities, then query graph structure plus source text for local or corpus-level reasoning.

Best when
Questions depend on relationships, multi-hop paths, communities, themes or “what connects these things?”
Watch for
Expensive indexing, entity/relationship extraction errors and graph maintenance.
Current Microsoft GraphRAG modes

The current project distinguishes Basic search, Local search for entity-centric questions, Global search over community reports, and DRIFT search that combines local exploration with broader community context.

Corrective RAG (CRAG)

Adaptive

Evaluate retrieved evidence and trigger corrective actions: such as alternate search, evidence refinement or fallback: when retrieval is weak.

Best when
Retrieval quality varies materially and the system can access alternate knowledge sources.
Watch for
Evaluator errors, extra latency and uncontrolled external retrieval.
Research basis

The CRAG paper uses a retrieval evaluator to determine whether corrective retrieval actions should be triggered instead of blindly trusting top-k results.

Self-reflective RAG

Adaptive

Make retrieval conditional and critique evidence or generated output rather than retrieving a fixed number of passages for every question.

Best when
Some queries need retrieval, others do not, and evidence relevance varies.
Watch for
Reflection can add latency and may itself be wrong; it needs evaluation like any other component.
Research basis

Self-RAG formalized adaptive retrieval and self-reflection rather than indiscriminately adding a fixed top-k context to every generation.

Agentic & multimodal retrieval

Adaptive

Let a policy or agent choose among vector search, SQL, graph, web, document/image retrieval or tools, then iterate when evidence is insufficient.

Best when
Queries span heterogeneous systems or need different retrieval strategies and modalities.
Watch for
Tool permissions, loops, cost, observability, reproducibility and prompt-injection exposure.
Design rule

Agentic retrieval should be bounded by approved tools, budgets, maximum steps, evidence requirements and fallback behavior. “Agentic” is orchestration, not a substitute for good indexes.

Side-by-side comparison

Operational impact of common RAG patterns

These are qualitative design heuristics: not benchmark scores. Actual cost and latency depend on corpus size, models, indexes, hardware and query mix.

PatternPrimary failure addressedIndex-time impactQuery-time impactBest evidence to collect
Flat vector RAGNeed external/current knowledgeLowLowRecall@k, groundedness, latency
Hybrid retrievalExact-term + semantic missesModerateModerateRecall by query type, fusion sensitivity
RerankingNoisy candidate orderingLowModeratenDCG/MRR uplift vs latency
Contextual retrievalChunks lose document contextHighLowRetrieval failure rate, index cost
Parent-childPrecision vs context trade-offModerateLowContext precision + answer completeness
Hierarchical / RAPTORMulti-level / long-document reasoningHighModerateMulti-hop QA, update/rebuild cost
GraphRAGEntity, relationship and global-theme queriesHighHighQuery-class quality vs indexing/query spend
Corrective / self-reflectiveWeak evidence and recoveryLowHighRecovery rate, false correction, added calls
Agentic retrievalHeterogeneous tools and dynamic strategyVariableHighTask success, tool errors, steps, cost, safety
Evaluation

Evaluate retrieval, generation, system behavior and business outcome separately

A single “answer accuracy” score hides why RAG fails. Keep a versioned golden query set with known evidence and segment results by query type.

Retrieval

  • Recall@k / hit rate
  • MRR or nDCG
  • Context precision & recall
  • Filter / routing accuracy

Generation

  • Groundedness
  • Citation correctness
  • Answer completeness
  • Unsupported-claim rate

System

  • p50 / p95 latency
  • Cost per successful answer
  • Index freshness
  • Retry / fallback rate

Business

  • Task success
  • Escalation / override rate
  • User trust / adoption
  • Time-to-resolution
Frameworks such as RAGCHECKER emphasize fine-grained diagnosis across both retrieval and generation. Whatever tool you use, preserve component-level metrics so you know whether to tune the retriever, reranker, prompt, model or workflow.
DataKnobs fit

Turn RAG architecture choices into governed Knobs

A RAG system is full of choices that should be measurable instead of buried in code. DataKnobs can make those choices explicit across creation, control and experimentation.

KREATE

Build ingestion, parsing, chunking, embedding, indexing, retrieval, reranking and answer-generation workflows as reusable capabilities.

KONTROLS

Govern source permissions, PII handling, lineage, freshness, citations, approved tools, budgets, human review and production evidence.

KNOBS

Experiment with chunk size, embedding model, hybrid weights, filters, top-k, reranker, thresholds, graph mode, routing and agent autonomy.

FAQ

Common RAG architecture questions

What is the best RAG architecture?

There is no universal best architecture. Start with the simplest design that meets your target quality, latency, cost and governance requirements. Add patterns only for a measured failure mode.

When should I use hybrid search and reranking?

Hybrid search is especially useful when exact identifiers and semantic meaning both matter. Reranking is useful when first-stage retrieval finds the right evidence but ranks too many irrelevant candidates above it.

When is GraphRAG worth the extra cost?

Use it for query classes that depend on relationships, multi-hop paths, entity neighborhoods or corpus-wide themes. Compare its quality improvement against indexing and runtime cost on those specific query classes.

Should long-context models replace RAG?

Not automatically. Long context can be a strong baseline for bounded corpora, but retrieval remains valuable for larger or changing corpora, permissions, freshness, citations and cost control.