Advanced RAG Patterns: Agentic RAG, Graph RAG, and Production Strategies [2026]

Basic RAG — chunk documents, embed them, retrieve the top-k, pass them to an LLM — solves the knowledge grounding problem for simple question-answering. In production, it breaks in ways that are well-documented and predictable: the "lost in the middle" phenomenon degrades attention on retrieved chunks that appear mid-context; semantic similarity retrieval returns structurally similar but contextually irrelevant passages; multi-hop queries requiring synthesis across multiple documents produce incomplete or hallucinated answers; and the system has no mechanism to recognize when its retrieved context is insufficient to answer the question.

Advanced RAG patterns address these failure modes systematically. This guide covers the techniques that have demonstrated production value: query transformation, hierarchical retrieval, re-ranking, contextual compression, agentic RAG, Graph RAG, Self-RAG, and CRAG. Each pattern targets a specific failure mode of basic RAG, and the right combination depends on the use case.

Advanced RAG Patterns: Query Transformation Techniques

The most common RAG failure is that user queries are poorly matched to the indexed document text. Users ask questions in natural language; documents contain answers in different terminology, at different levels of abstraction. Query transformation addresses this mismatch before retrieval happens.

HyDE (Hypothetical Document Embedding)

Instead of embedding the user's query and searching for similar documents, HyDE prompts an LLM to generate a hypothetical answer to the query, then embeds that hypothetical answer. The intuition: a generated answer about "how Kubernetes pod scheduling works" uses the same vocabulary as actual documentation on that topic, producing better embedding alignment than the brief question itself.

HyDE works well when: the domain has technical terminology, the query is brief and abstract, and the model has sufficient base knowledge to generate a plausible hypothetical. It degrades when the model's hypothetical contains hallucinated technical details that lead retrieval toward incorrectly aligned documents. For domains where the LLM has limited base knowledge, step-back prompting is typically safer.

Step-Back Prompting

Step-back prompting generates a more general version of a narrow query to broaden retrieval scope. "What is the difference between select_related and prefetch_related in Django ORM?" becomes "What are Django ORM query optimization techniques?" — a query likely to retrieve documentation covering both methods and their trade-offs, rather than only the specific comparison.

This is particularly useful for technical documentation retrieval where users ask highly specific questions but the relevant explanation appears in broader context. The retrieved broad context then allows the LLM to answer the specific question using the surrounding material.

Multi-Query Expansion

Multi-query expansion generates multiple alternative phrasings or decompositions of the original query, runs retrieval for each, and merges results. "React performance optimization" becomes "React rendering optimization techniques", "React memo and useMemo use cases", and "React virtual DOM performance" — three queries that collectively cover more of the relevant documentation than any single query.

Results are merged using Reciprocal Rank Fusion (RRF), which combines ranked lists from multiple queries into a single ranked list weighted by position. The primary risk is increased retrieval latency — three retrieval operations versus one. In practice, parallelizing the sub-queries keeps latency manageable; the quality improvement typically justifies the overhead.

Hierarchical Retrieval

Basic RAG treats all document chunks as equivalent. Hierarchical retrieval exploits document structure to improve both precision and context quality.

Sentence Window Retrieval

Documents are indexed at sentence granularity — each sentence is a retrieval unit with its own embedding. When a sentence is retrieved as relevant, the returned context includes that sentence plus its immediate neighbors (typically two sentences before and after). This preserves fine-grained retrieval precision while providing enough surrounding context for the LLM to produce coherent answers.

The tradeoff: smaller chunks produce better retrieval precision at the cost of less inherent context per chunk. Window size is a tunable parameter; typical production configurations use 2-5 sentence windows. For technical documentation where individual sentences contain specific facts, this approach often outperforms larger fixed-size chunking.

Auto-Merging Retrieval (Parent-Child)

Documents are indexed hierarchically: large "parent" chunks and smaller "child" chunks derived from them. Retrieval operates on child chunks for precision; when multiple child chunks from the same parent are retrieved, the parent chunk replaces them in the context. This mechanism provides full-document context when the query is broadly relevant to a document section, rather than fragments from multiple locations within the same section.

The merge threshold is configurable: typically, when more than 50% of a parent chunk's children are retrieved, the parent replaces all child chunks in the context. This prevents the common failure mode where three adjacent sentences from the same paragraph are retrieved as separate context fragments, forcing the LLM to reconstruct their relationship.

Re-Ranking

The first stage of retrieval (vector similarity search) is optimized for speed, not accuracy. A bi-encoder model produces embeddings offline and serves retrieval at millisecond latency, but the independence of query and document encoding means it cannot model fine-grained query-document interaction. Re-ranking adds a second stage that scores retrieved candidates with higher accuracy.

Cross-Encoder Re-Ranking

A cross-encoder takes the query and a candidate document as joint input, rather than encoding them independently. This allows the model to attend to query-document interactions at every token, producing more accurate relevance scores at the cost of significantly higher computation. The standard pattern: retrieve 20-50 candidates with the bi-encoder, re-rank with the cross-encoder, pass the top 3-5 to the LLM.

Cross-encoders are not suitable for first-stage retrieval because they cannot precompute document representations — every query requires running the model on all candidate query-document pairs. For a 50-candidate re-rank step, this is computationally tractable; for a million-document corpus, it is not.

Cohere Rerank

Cohere's Rerank API provides high-quality re-ranking through a single API call, without requiring model hosting or infrastructure. For teams without GPU infrastructure or the machine learning expertise to train and deploy custom re-rankers, Cohere Rerank provides production-quality re-ranking with straightforward integration. The primary trade-off is API cost and external dependency; for latency-sensitive applications, the round-trip API call adds constraint.

ColBERT provides an alternative through late-interaction: query and document token embeddings are computed independently (like a bi-encoder), but relevance scoring uses MaxSim operations over token-level interactions (like a cross-encoder). This achieves better accuracy than standard bi-encoders while maintaining precomputed document representations.

Agentic RAG

Agentic RAG transforms the retrieval process from a single-pass operation into an iterative loop driven by an agent that evaluates the quality of retrieved information and decides whether additional retrieval is needed.

Routing Agents

For systems with multiple knowledge sources — a structured database, a vector store of documents, a web search capability — routing agents analyze each query and direct it to the appropriate source. A technical question goes to the documentation vector store; a time-sensitive question about recent events goes to web search; a numerical query about business data goes to the SQL database.

Routing requires the agent to understand query type, expected answer format, and which sources are likely to contain relevant information. Fallback chains handle routing failures: if the primary source returns low-confidence results, the agent escalates to the next source in the fallback sequence.

Tool-Augmented Retrieval

An agentic RAG system with tool access can answer questions that require multiple information sources, computation, or external API calls. The agent decomposes a complex query into sub-tasks, calls the appropriate tools in sequence or in parallel, integrates the results, and produces a final response grounded in multiple retrieved sources.

For example, "Compare the Q4 2024 and Q4 2025 performance of our top 5 products and explain the trend" requires: SQL query for sales data (Q4 2024), SQL query for sales data (Q4 2025), semantic retrieval of any relevant market context or product notes, and synthesis of the combined information. A basic RAG system cannot execute this; an agentic RAG system with database and vector store tools can.

Iterative Retrieval with Reflection

The most powerful agentic RAG pattern adds self-evaluation to the retrieval loop. After each retrieval step, the agent evaluates whether the collected information is sufficient to answer the query: "Does this context answer the question? Is any critical information missing? Are there contradictions I need to resolve?" If the evaluation identifies gaps, the agent generates follow-up queries and retrieves additional information. This continues until the agent determines the context is sufficient or the maximum iteration count is reached.

The reflection mechanism substantially reduces hallucination on multi-hop queries — questions that require synthesizing information from multiple documents. Without reflection, basic RAG answers these with partial information confidently; with iterative reflection, the agent recognizes incompleteness and continues gathering information.

When Should You Use RAG vs Fine-Tuning?

This is one of the most frequently debated architectural questions in LLM application development. The answer depends primarily on what the system needs to know and how that knowledge changes over time.

Use RAG when:

• The knowledge base is large and changes frequently (documentation, product catalogs, news, internal reports)
• You need citation or source attribution — RAG systems can cite which documents informed each response
• The information exists in a document corpus that is not part of the LLM's training data
• You need to add new information without retraining
• The knowledge domain is specialized enough that a general LLM does not have adequate base knowledge

Use fine-tuning when:

• You need the model to follow a very specific response format or persona consistently
• The style, tone, or structure of outputs is as important as the content
• You want the model to internalize specific terminology or domain conventions at the instruction-following level
• Inference latency requirements cannot accommodate retrieval round-trips
• The knowledge is static and fits within training budget constraints

Use both when:

• A fine-tuned model provides consistent formatting and domain-adapted behavior
• RAG provides the specific factual knowledge the fine-tuned model needs to ground responses
• This combination — a domain-adapted model plus retrieval — is the state-of-the-art pattern for enterprise knowledge management systems

The common mistake is using fine-tuning as a substitute for retrieval. Fine-tuning on a document corpus teaches the model patterns from that corpus but does not give it reliable recall of specific facts. A model fine-tuned on product documentation does not reliably produce specific prices, availability, or policy details — for those, retrieval is necessary.

Graph RAG Implementation

Graph RAG combines knowledge graph construction with vector retrieval to capture structural relationships that semantic similarity search misses.

Building the Knowledge Graph

From the source document corpus, an LLM extracts entities and relationships: "Company X acquired Company Y in 2023", "Product A uses Component B", "Regulation C applies to Domain D". These entities become graph nodes; relationships become edges. The resulting knowledge graph captures structural information about the domain that is not accessible through vector similarity alone.

Entity normalization is critical for graph quality: "Microsoft", "MSFT", and "Microsoft Corporation" must be recognized as the same entity and merged. Inconsistent normalization fragments the graph and degrades retrieval quality.

Community Summaries and Global Queries

For broad, non-specific queries ("What are the main developments in AI safety research?"), neither vector search (which retrieves specific documents) nor a static prompt (which relies on LLM base knowledge) works well. Graph RAG addresses this by running community detection algorithms (Leiden, Louvain) on the knowledge graph, generating summaries of each community, and using those community summaries to answer broad queries.

Community summaries provide a structured, hierarchical view of the domain knowledge that supports both specific and general queries. Microsoft Research's GraphRAG implementation demonstrated substantially better performance on global queries compared to standard vector RAG on the same document corpus.

Hybrid Graph and Vector Search

In practice, the highest-quality RAG systems combine graph traversal with vector similarity retrieval. A query that asks about a specific entity and its relationships benefits from graph traversal; a query that asks about a concept across many documents benefits from vector similarity. Combining both sources — using the graph to identify relevant entities and relationships, then using vector search to retrieve the specific documents — produces context that is both structurally rich and semantically relevant.

Self-RAG and CRAG: Quality-Gated Retrieval

Self-RAG and CRAG both address the problem that basic RAG does not evaluate whether retrieved documents are actually relevant or whether the generated response is actually grounded in the retrieved content.

Self-RAG

Self-RAG trains special reflection tokens into the LLM that enable it to evaluate: whether retrieval is needed, whether retrieved documents are relevant, whether the generated response is supported by the retrieved content, and whether the response adequately addresses the query. These evaluations happen inline during generation, allowing the model to adaptively decide when to retrieve and to flag unsupported claims.

The Self-RAG paper (Asai et al., 2023) demonstrated that models trained with Self-RAG outperformed standard RAG on factuality benchmarks while producing more calibrated uncertainty. The limitation: it requires a model that has been specifically trained with reflection tokens — it is not a drop-in upgrade to an existing RAG system.

CRAG (Corrective RAG)

CRAG adds an evaluator module that classifies retrieved documents as "correct", "ambiguous", or "incorrect" relative to the query. If documents are classified as incorrect, CRAG discards them and triggers web search. If classified as ambiguous, it refines the retrieved content and supplements with web search. Only if documents are classified as correct does it proceed directly to generation.

This fallback mechanism is particularly valuable for domains where the internal knowledge base has incomplete coverage. Rather than generating a response grounded in an irrelevant retrieved document, CRAG recognizes the mismatch and falls back to broader search. The evaluator is typically a small trained classifier or a prompted LLM judge.

Production RAG: Evaluation and Monitoring

Production RAG systems require systematic evaluation to detect degradation and guide improvement.

RAGAS Framework

RAGAS (Retrieval Augmented Generation Assessment) provides four core metrics: Faithfulness (is the response grounded in the retrieved context?), Answer Relevancy (does the response address the query?), Context Recall (is the relevant information present in the retrieved context?), and Context Precision (are all retrieved documents necessary?).

These metrics can be computed automatically using an LLM judge, enabling continuous evaluation on production traffic samples without human annotation at every point. Low faithfulness indicates hallucination; low context recall indicates retrieval is missing relevant information; low context precision indicates retrieval is returning too much noise.

Caching and Infrastructure

Semantic caching reduces latency and cost by recognizing when an incoming query is sufficiently similar to a previously answered query. The cached response is returned without running full retrieval and generation. Cache validity and invalidation policies must align with how frequently the underlying knowledge base changes — a cache configured with a long TTL on a rapidly changing knowledge base will serve stale answers.

Streaming responses (sending tokens to the client as they are generated, rather than buffering the complete response) reduces perceived latency substantially on long responses. For complex agentic RAG queries that require multiple retrieval iterations, streaming reassures users that the system is working even when end-to-end latency is high.

---

Advanced RAG patterns are not premature optimization — they address real failure modes that manifest quickly in production. The most important patterns to adopt first are query transformation and re-ranking, which improve retrieval quality with minimal architectural complexity. Agentic and graph-based patterns are appropriate once basic retrieval quality is established and the use case requires multi-hop reasoning or structural knowledge. Smart Maple has applied these patterns in enterprise knowledge management projects where the combination of hybrid graph and vector retrieval substantially improved answer accuracy over baseline RAG.