Frontend · Backend · Artificial Intelligence

RAG Didn't Get Complicated Overnight — It Evolved to Fix Real Failures

By 董员外 · Jul 30, 2026

Read original on juejin.cn ↗ Google Translate ↗ Alt translation

Teams get stuck because they adopt RAG techniques as a checklist instead of diagnosing which retrieval failure they actually have. This evolutionary map gives engineers a diagnostic framework: identify the specific breakage, then apply the matching fix, rather than bolting on complexity that adds latency and cost without solving the real problem.

Summary

A working RAG demo takes a dozen lines of code, but real-world data breaks it fast: answers go missing, models hallucinate with confidence, and product codes never surface. The sprawling RAG landscape — BM25, Hybrid Search, Rerankers, GraphRAG, Agentic RAG — is a direct response to these concrete failures, not an architecture designed upfront. Each stage in the evolution adds a capability that compensates for a proven weakness in the prior stage. Naive RAG treats semantic similarity as relevance, so Advanced RAG adds keyword retrieval and reranking. When a single pipeline can't handle diverse query types, Modular RAG introduces routing. When retrieved evidence is still wrong, Corrective RAG and Self-RAG add verification loops. GraphRAG tackles multi-hop relationships that vector search misses; Multimodal RAG recovers knowledge locked in tables and images; Agentic RAG lets the system plan multi-step investigations. The final stages — evaluation and operations — close the loop so teams stop tuning by feel and start running RAG as a governed, observable service.

Takeaways

— Naive RAG equates semantic similarity with answerability, which fails when documents contain precise codes, model numbers, or when the knowledge base lacks the answer entirely.

— Advanced RAG layers BM25 keyword search, metadata filtering, and reranking onto vector retrieval to close the precision gap that pure embeddings leave open.

— Modular RAG replaces a single fixed pipeline with a router that dispatches questions to different retrieval paths — vector search, SQL, APIs, or web search — based on query type.

— Corrective RAG and Self-RAG add evaluation loops that judge evidence relevance and sufficiency, rewriting queries or refusing to answer when retrieval quality is low.

— GraphRAG extracts entities and relationships into a knowledge graph, enabling multi-hop and global-summary queries that flat vector search cannot handle.

— Multimodal RAG parses tables, images, and document layouts so that knowledge locked in non-text formats enters the retrieval index instead of being discarded.

— Agentic RAG lets the model plan, select tools, and iterate over multiple retrieval steps, turning a single lookup into a multi-step research task with a stop condition.

— Evaluation metrics (Recall@K, faithfulness, citation accuracy) and observability tooling (traces, datasets, experiments) replace gut-feel tuning with measurable improvement.

— Operational RAG closes the loop with data governance, access control, cost budgets, canary releases, and feedback-driven dataset updates so the system can run safely in production.

Conclusions

The RAG ecosystem is often presented as a feature buffet, but the underlying logic is strictly reactive: every major technique exists because a simpler system demonstrably failed on real data.

Calling something 'Agentic RAG' is less about a new architecture and more about shifting control flow from a developer-written script to model-determined tool selection and planning — a trade that improves flexibility while sacrificing predictability and cost control.

The jump from Advanced to Modular RAG highlights a design tension that repeats across the stack: a single optimized pipeline eventually becomes a bottleneck because it cannot discriminate between query types that need fundamentally different treatment.

GraphRAG and vector search are not competitors; they solve orthogonal retrieval problems. Vector search finds similar text; graph traversal finds related entities. Conflating them leads teams to adopt GraphRAG for simple fact lookup, where it adds cost without benefit.

The final 'operational' stage is where most RAG projects stall — not because the retrieval is broken, but because there is no mechanism to update knowledge, manage permissions, or measure whether a prompt change actually helped.

Concepts & terms

Naive RAG

The simplest retrieval-augmented generation loop: chunk documents, embed them into a vector store, retrieve the top-K most similar chunks for a query, and feed them into an LLM's context window.

Hybrid Search

Combining sparse keyword retrieval (like BM25) with dense vector retrieval, then fusing results — often via Reciprocal Rank Fusion (RRF) — to capture both exact term matches and semantic similarity.

Modular RAG

An architecture where a router classifies the incoming query and dispatches it to different retrieval paths (vector DB, SQL database, web search, APIs) instead of forcing all queries through one pipeline.

Corrective RAG / Self-RAG

Patterns where the system evaluates the quality of retrieved evidence — checking relevance and sufficiency — and can rewrite the query, re-retrieve, fall back to web search, or refuse to answer before generation.

GraphRAG

A RAG variant that builds a knowledge graph from documents by extracting entities and relationships, then answers queries via graph traversal and community summarization, targeting multi-hop and global questions that vector search misses.

Agentic RAG

A RAG pattern where an LLM acts as a planner: it decomposes a goal into sub-tasks, selects tools, iterates on retrieval results, and decides when to stop, rather than following a pre-scripted retrieval path.

Source: juejin.cn ↗ Google Translate ↗ Backup ↗