RAG Types and When to Use Them

The cleanest way to read RAG types is to ask what changes between query and answer. Does the system retrieve once? Does it keep conversation state? Does it plan multiple retrieval steps? Does it traverse relationships? Does it rewrite the query, branch candidates, critique answers, or work over images and audio?

That means naive, simple, and advanced are maturity labels; Graph RAG, Agentic RAG, and Multimodal RAG are architecture choices; HyDE, Self-RAG, Corrective RAG, Branched RAG, Speculative RAG, and Adaptive RAG are techniques you may combine with those architectures. Flattening them into one ranked list makes design reviews harder.

Naive RAG is the smallest loop: retrieve chunks and generate a response with little or no refinement. It is fine for prototypes and low-risk internal Q&A, but it fails quietly when chunks are stale, filters are missing, or the retrieved context does not support the answer. Simple RAG is the same core idea with more deliberate chunking, metadata filters, citation rules, and refusal behavior.

Simple RAG with memory adds selected state from earlier turns. For customer C-104, memory might preserve the current case id and renewal date while retrieval fetches policy text and contract clauses. The memory should not be a dump of the full chat transcript; it needs typed fields, source, timestamp, expiry, and visibility. Otherwise the assistant may remember a stale exception and override fresher evidence.

Agentic RAG adds a control loop. The system can decide what to retrieve, inspect results, call tools, re-query, ask a human, or stop. For C-104, an agent might retrieve policy, call CRM for account tier, retrieve the signed renewal contract, compare dates, then ask a manager before granting an exception. This is powerful, but it introduces loop limits, tool permissions, trace logging, and cost controls.

Graph RAG changes the retrieval substrate. Instead of only asking Which chunks are similar to this query?, it asks Which entities and relationships connect to this question? That matters for contracts, organizations, dependencies, claims, citations, supply chains, and narrative corpora where the answer depends on relationships across many documents. Microsoft’s GraphRAG work, for example, uses LLM-derived knowledge graphs and community summaries for global questions over private narrative datasets.

Some RAG patterns do not change the whole architecture; they change how the query is transformed or explored. HyDE generates a hypothetical answer-like document first, embeds that document, and uses it to retrieve real neighbors. The key warning from the original HyDE idea is that the hypothetical document can contain false details, so the final answer still must be grounded in retrieved real documents, not the imagined text.

Branched RAG explores multiple retrieval or answer paths and then selects the best-supported one. Speculative RAG tries to reduce latency by predicting likely retrieval needs or candidate context early. Adaptive RAG routes different query types through different retrieval depth: cheap one-shot retrieval for easy questions, deeper search for ambiguous or high-risk questions, and refusal or human review when evidence is thin.

Self-RAG is a research pattern where the model learns to retrieve on demand and critique retrieved passages and its own generation using special reflection tokens. In practical systems, teams often approximate the idea with separate evaluator prompts or model calls, but the original mechanism is more specific than the model checks itself.

Corrective RAG, often abbreviated CRAG, adds a retrieval evaluator that judges whether the retrieved documents are good enough. If retrieval is weak, the system can decompose documents, filter irrelevant content, search outside the static corpus, or ask for human review. The production lesson is simple: correction must sit before the final answer is trusted. A polished final paragraph is not evidence.

Multimodal RAG retrieves and reasons over formats beyond plain text: images, tables, audio, video, screenshots, PDFs, or diagrams. The hard part is not just using a multimodal model. It is preserving source coordinates, page numbers, timestamps, OCR confidence, captions, and modality-specific evidence so the answer can cite what it used.

Modular RAG is an engineering shape: retrievers, rankers, generators, filters, memory, graph traversal, and evaluators are replaceable modules behind stable contracts. Advanced RAG is better treated as a maturity label for a system that combines several proven techniques with evals, monitoring, permissions, and rollback. It is not a separate algorithm by itself.

Trigger. The support assistant uses HyDE for a vague renewal question, retrieves a plausible but old contract clause, then an agentic loop calls CRM and drafts a confident discount decision. Symptom. The answer cites a stale clause and grants the wrong discount. Root mechanism. The team added advanced routing and tools before adding an evidence gate for contract version, retrieval score, and citation support.

Recovery: fail closed when the retrieved contract version does not match CRM, rerun retrieval with metadata filters, and route the case to human review if confidence stays low. Prevention: choose the simplest RAG route that passes the eval set, then add HyDE, graph traversal, branching, or critique only for named failures.