RAG没有死：2026年检索增强生成的进化路线图

2026 年初，一场关于 RAG 的争论在技术圈炸开了锅。导火索是斯坦福一个团队的研究——他们发现，用合成数据微调的小模型，在垂直领域的问答准确率上反超了 RAG 方案，而且成本更低。一时间，“RAG 神话破灭”"检索增强已死"的标题铺满了公众号。

但在另一边，企业级 AI 应用的落地现实却是另一幅图景：Dify 的 RAG 流水线被嵌入了成千上万的生产系统，Microsoft 的 GraphRAG 在 GitHub 上收获了数万 Star，Agentic RAG 成为 2026 年 AI Agent 技术栈中最热门的关键词之一。

这两种叙事之间的矛盾，说明了一件事：喊"RAG 死了"的人，和正在用 RAG 赚钱的人，讨论的不是同一种 RAG。 前者脑子里是 2023 年的那套"切块-嵌入-检索-拼接-生成"的标准流程。后者在实践中发现，那套东西确实有天花板——所以他们改进了它、重构了它、甚至重新发明了它。

这篇文章想做的，就是把这套"改进-重构-重新发明"的进化路线画清楚：每一代 RAG 到底改了什么、为什么必须改、以及改完之后又引入了什么新问题。

01 "RAG 死了"的论调，到底在说什么

先理清批评者的核心论点，否则后面的进化论就变成了空中楼阁。

批评 RAG 的声音主要有三个层面：

第一层：检索质量的不可靠性。 这是最老也最真实的问题。你把文档切成固定大小的块，用通用 Embedding 模型编码成向量，然后做语义相似度检索——这个流水线里每一步都可能导致信息丢失或错配。关键段落被切断了，查询的语义和文档的语义不在同一个空间里，最重要的段落因为向量相似度算法的一点点偏差被排到了第二页。

第二层：上下文窗口的浪费。 即使检索到的内容确实是相关的，你一股脑把所有检索结果拼进 Prompt，效果往往不如精心挑选少数几段。因为模型不是越多的上下文就表现越好——过多的信息会导致注意力分散，关键信息被淹没在噪音里。这就是所谓的"Lost in the Middle"效应。

第三层：缺乏推理能力。 基础 RAG 的本质是"找到相关信息，交给模型直接回答"。但很多真实问题不是"找到信息就能回答"的——它们需要多步推理。"A 公司和 B 公司过去三年的营收差距变化趋势是怎样的？"这个问题需要先分别找到两家公司每年的营收数据，然后计算差值，然后分析趋势。基础 RAG 做不了这个，因为它只有一次检索、一次生成。

这三个批评都是真实的。但它们批评的是一个特定版本的 RAG——2023 年版的 Naive RAG。而产业界在过去两年里做的事情，恰好就是逐一解决这三个问题。

02 三代进化：从 Naive 到 Advanced 到 Agentic

RAG 技术的进化不是线性的替代关系，而是一层一层地叠加。每一代在前一代的基础上增加新的能力维度，同时也增加新的复杂度。

#mermaid-svg-YzXhnzYhXtQM7Kaq{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-YzXhnzYhXtQM7Kaq .error-icon{fill:#552222;}#mermaid-svg-YzXhnzYhXtQM7Kaq .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-YzXhnzYhXtQM7Kaq .marker{fill:#333333;stroke:#333333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .marker.cross{stroke:#333333;}#mermaid-svg-YzXhnzYhXtQM7Kaq svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-YzXhnzYhXtQM7Kaq p{margin:0;}#mermaid-svg-YzXhnzYhXtQM7Kaq .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster-label text{fill:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster-label span{color:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster-label span p{background-color:transparent;}#mermaid-svg-YzXhnzYhXtQM7Kaq .label text,#mermaid-svg-YzXhnzYhXtQM7Kaq span{fill:#333;color:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .node rect,#mermaid-svg-YzXhnzYhXtQM7Kaq .node circle,#mermaid-svg-YzXhnzYhXtQM7Kaq .node ellipse,#mermaid-svg-YzXhnzYhXtQM7Kaq .node polygon,#mermaid-svg-YzXhnzYhXtQM7Kaq .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .rough-node .label text,#mermaid-svg-YzXhnzYhXtQM7Kaq .node .label text,#mermaid-svg-YzXhnzYhXtQM7Kaq .image-shape .label,#mermaid-svg-YzXhnzYhXtQM7Kaq .icon-shape .label{text-anchor:middle;}#mermaid-svg-YzXhnzYhXtQM7Kaq .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .rough-node .label,#mermaid-svg-YzXhnzYhXtQM7Kaq .node .label,#mermaid-svg-YzXhnzYhXtQM7Kaq .image-shape .label,#mermaid-svg-YzXhnzYhXtQM7Kaq .icon-shape .label{text-align:center;}#mermaid-svg-YzXhnzYhXtQM7Kaq .node.clickable{cursor:pointer;}#mermaid-svg-YzXhnzYhXtQM7Kaq .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .arrowheadPath{fill:#333333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-YzXhnzYhXtQM7Kaq .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-YzXhnzYhXtQM7Kaq .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-YzXhnzYhXtQM7Kaq .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster text{fill:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq .cluster span{color:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-YzXhnzYhXtQM7Kaq .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-YzXhnzYhXtQM7Kaq rect.text{fill:none;stroke-width:0;}#mermaid-svg-YzXhnzYhXtQM7Kaq .icon-shape,#mermaid-svg-YzXhnzYhXtQM7Kaq .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-YzXhnzYhXtQM7Kaq .icon-shape p,#mermaid-svg-YzXhnzYhXtQM7Kaq .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-YzXhnzYhXtQM7Kaq .icon-shape .label rect,#mermaid-svg-YzXhnzYhXtQM7Kaq .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-YzXhnzYhXtQM7Kaq .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-YzXhnzYhXtQM7Kaq .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-YzXhnzYhXtQM7Kaq :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

+ 分块优化+ 检索策略+ 重排序+ 上下文压缩

+ 自主决策+ 多轮迭代+ 工具调用

Naive RAG2023检索 + 拼接

Advanced RAG2024工程化补丁

Agentic RAG2025-2026推理 + 行动

2.1 Naive RAG：一个朴素但脆弱的起点

Naive RAG 的流程可以概括为五个字：切、存、搜、拼、答。

文档 → 固定大小切块 → Embedding → 存入向量库
查询 → Embedding → 向量相似度检索 → 取 Top-K → 拼接进 Prompt → LLM 生成回答

这套流程的优点是一句话说清楚的——任何人都能在半小时内架起来。缺点是它也就能跑半小时的水平——一旦你开始用真实数据、真实查询、真实用户去考验它，每个环节都会出问题。

切块阶段的问题： 固定分块（比如每 500 个 token 一刀切下去）对叙事性较强的文档（技术博客、产品文档）还行，但对结构化数据（API 文档、法律条文、财报表格）则是灾难。一个函数的定义可能被切成两块，上半截在 chunk 7，下半截在 chunk 8，搜到 chunk 7 的检索结果完全不可用。

搜索阶段的问题： 通用 Embedding 模型（比如 text-embedding-ada-002 或者早期的 BGE）是在通用语料上训练的。它们在"这段文本大概在讲什么"的层面做得不错，但在"这段文本精确回答了用户的哪个问题"的层面经常翻车。用户的查询是"怎么解决数据库连接池耗尽"，模型找到的是"数据库连接池的配置参数详解"——语义相关，但不是答案。

拼接阶段的问题： Top-K 搜索结果一个接一个地拼进 Prompt，不做任何排序、过滤或压缩。结果就是前面提到的"Lost in the Middle"——模型对 Prompt 开头和结尾的内容关注度高，对中间的内容关注度低，而刚好你需要的那段信息被排在第三位。

2.2 Advanced RAG：一套不断膨胀的工程补丁

Advanced RAG 不是一个新的架构范式，而是针对 Naive RAG 每个环节的问题打上的一系列补丁。这些补丁各自独立但相互配合，把 RAG 从一个"玩具级方案"提升到"能用的方案"。

补丁一：智能分块。

固定分块被语义感知分块取代。不再是按 token 数一刀切，而是根据文档的自然边界——段落、章节、代码块、表格——来切。理想情况下，每个 chunk 是一个完整的语义单元。

# Naive 分块：按固定窗口，不管语义边界
chunks = [doc[i:i+500] for i in range(0, len(doc), 500)]

# 语义分块：按段落/章节边界
chunks = []
current_chunk = ""
for paragraph in doc.paragraphs:
if len(current_chunk) + len(paragraph) > max_chunk_size:
chunks.append(current_chunk)
current_chunk = paragraph
else:
current_chunk += "\\n" + paragraph

更进一步的做法是递归分块——先用大的语义单元（章节）切，如果某个单元太大，再递归地用小的单元（段落、句子）切。还有滑动窗口分块——相邻 chunk 之间有重叠，确保边界附近的上下文不会丢失。

补丁二：查询重写。

原始用户的查询可能很短、很模糊、或者用词和文档不一致。查询重写在检索之前先"优化"查询，缩小查询和文档之间的语义鸿沟。

• HyDE（假设性文档嵌入）：先让 LLM 根据查询生成一个假想的答案文档，再用这个假想文档的向量去检索。原理是：假想答案和真实相关文档的语义空间更接近，比直接用原始查询检索效果好。
• 多查询生成：让 LLM 把用户的一个查询拆成多个不同角度的子查询，对每个子查询分别检索，合并结果。比如"如何优化 RAG 系统"变成"RAG 分块策略优化"“RAG 检索精度提升”“RAG 上下文压缩方案”。
• 退一步提示（Step-back Prompting）：把具体问题抽象成更宽泛的"背景问题"来检索。用户问"2024 年 Q3 特斯拉毛利率为什么下降"，退一步检索"影响汽车行业毛利率的关键因素"。

补丁三：混合检索与重排序。

单一检索策略的可靠性在一些论文中被证明不足 60%。混合检索把多种策略的结果合并：稠密检索（向量语义相似度，擅长大意匹配）+ 稀疏检索（BM25 关键词匹配，擅长精确术语查找）。两者各有所长，结合起来覆盖面更广。

检索结果的最后一步是重排序（Re-ranking）。用比 Embedding 模型更精确（但也更慢）的排序模型（如 cross-encoder），对 Top-K 候选段落做精细化的相关性打分，把无关结果踢掉，把最相关的结果排到前面。

# 混合检索 + 重排序的简化示意
dense_results = vector_db.search(query_embedding, top_k=50)
sparse_results = bm25_index.search(query_text, top_k=50)
merged = merge_and_deduplicate(dense_results, sparse_results)
reranked = cross_encoder.rerank(query, merged)[:top_k]

补丁四：上下文压缩与重排。

即使检索结果都是相关的，直接拼接也浪费 token。LLMLingua 这类压缩技术可以在保留关键信息的前提下把检索结果压缩 2-5 倍。更简单的做法是"选择性注入"——不是把所有段落都塞进 Prompt，而是根据相关性分数只取最 Top 的几条，把省下的 token 留给模型的推理。

Advanced RAG 的这四层补丁解决了很多问题，但它们带来的新问题是系统复杂度非线性膨胀。你本来只想搭一个简单的问答系统，现在你需要管理分块策略、Embedding 模型的版本、BM25 索引、重排序模型、查询重写的 Prompt 模板、压缩算法的参数——每加一层补丁，系统的维护负担就加一份。而且，即使加了这么多补丁，它仍然解决不了第三层批评：缺乏推理能力。

这就是 Agentic RAG 登场的背景。

2.3 Agentic RAG：让检索具备思考和行动能力

Agentic RAG 的核心思想是：RAG 不应该是一个"检索一次、生成一次"的单向流水线，而应该是一个"检索-评估-决策-再检索"的自主循环。

一个 Agentic RAG 系统在面对用户查询时，不会立刻做一次检索然后生成答案，而是先做一个简短的"检索计划"——这个问题需要从哪些角度获取信息？优先查什么？如果第一次检索不够怎么办？

LLM判断模块检索器RAG Agent用户查询LLM判断模块检索器RAG Agent用户查询#mermaid-svg-XF3BVyJAJUnPftjY{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-XF3BVyJAJUnPftjY .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-XF3BVyJAJUnPftjY .error-icon{fill:#552222;}#mermaid-svg-XF3BVyJAJUnPftjY .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-XF3BVyJAJUnPftjY .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-XF3BVyJAJUnPftjY .marker{fill:#333333;stroke:#333333;}#mermaid-svg-XF3BVyJAJUnPftjY .marker.cross{stroke:#333333;}#mermaid-svg-XF3BVyJAJUnPftjY svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-XF3BVyJAJUnPftjY p{margin:0;}#mermaid-svg-XF3BVyJAJUnPftjY .actor{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-XF3BVyJAJUnPftjY text.actor>tspan{fill:black;stroke:none;}#mermaid-svg-XF3BVyJAJUnPftjY .actor-line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-XF3BVyJAJUnPftjY .innerArc{stroke-width:1.5;stroke-dasharray:none;}#mermaid-svg-XF3BVyJAJUnPftjY .messageLine0{stroke-width:1.5;stroke-dasharray:none;stroke:#333;}#mermaid-svg-XF3BVyJAJUnPftjY .messageLine1{stroke-width:1.5;stroke-dasharray:2,2;stroke:#333;}#mermaid-svg-XF3BVyJAJUnPftjY #arrowhead path{fill:#333;stroke:#333;}#mermaid-svg-XF3BVyJAJUnPftjY .sequenceNumber{fill:white;}#mermaid-svg-XF3BVyJAJUnPftjY #sequencenumber{fill:#333;}#mermaid-svg-XF3BVyJAJUnPftjY #crosshead path{fill:#333;stroke:#333;}#mermaid-svg-XF3BVyJAJUnPftjY .messageText{fill:#333;stroke:none;}#mermaid-svg-XF3BVyJAJUnPftjY .labelBox{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-XF3BVyJAJUnPftjY .labelText,#mermaid-svg-XF3BVyJAJUnPftjY .labelText>tspan{fill:black;stroke:none;}#mermaid-svg-XF3BVyJAJUnPftjY .loopText,#mermaid-svg-XF3BVyJAJUnPftjY .loopText>tspan{fill:black;stroke:none;}#mermaid-svg-XF3BVyJAJUnPftjY .loopLine{stroke-width:2px;stroke-dasharray:2,2;stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);}#mermaid-svg-XF3BVyJAJUnPftjY .note{stroke:#aaaa33;fill:#fff5ad;}#mermaid-svg-XF3BVyJAJUnPftjY .noteText,#mermaid-svg-XF3BVyJAJUnPftjY .noteText>tspan{fill:black;stroke:none;}#mermaid-svg-XF3BVyJAJUnPftjY .activation0{fill:#f4f4f4;stroke:#666;}#mermaid-svg-XF3BVyJAJUnPftjY .activation1{fill:#f4f4f4;stroke:#666;}#mermaid-svg-XF3BVyJAJUnPftjY .activation2{fill:#f4f4f4;stroke:#666;}#mermaid-svg-XF3BVyJAJUnPftjY .actorPopupMenu{position:absolute;}#mermaid-svg-XF3BVyJAJUnPftjY .actorPopupMenuPanel{position:absolute;fill:#ECECFF;box-shadow:0px 8px 16px 0px rgba(0,0,0,0.2);filter:drop-shadow(3px 5px 2px rgb(0 0 0 / 0.4));}#mermaid-svg-XF3BVyJAJUnPftjY .actor-man line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;}#mermaid-svg-XF3BVyJAJUnPftjY .actor-man circle,#mermaid-svg-XF3BVyJAJUnPftjY line{stroke:hsl(259.6261682243, 59.7765363128%, 87.9019607843%);fill:#ECECFF;stroke-width:2px;}#mermaid-svg-XF3BVyJAJUnPftjY :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}"A和B两家公司过去三年营收对比"制定检索计划：分两个子问题子问题1："A公司2024-2026年营收数据"[检索结果1]子问题2："B公司2024-2026年营收数据"[检索结果2]评估：检索到的数据是否完整、来源是否可靠？数据足够，可以开始分析将两次检索的结构化数据 + 分析指令 一起交给模型对比分析结果（含计算过程）最终回答

这个流程中有两个关键的新组件：规划模块（决定怎么检索）和判断模块（评估检索质量、决定是否需要再检索）。

规划模块本质上是一个轻量级的 LLM 调用，输入用户的原始问题，输出一个检索计划——包含拆解后的子问题、每个子问题的检索策略（向量检索、关键词检索还是查数据库）、以及子问题之间的依赖关系。

判断模块则做两件事：充分性检查——"目前收集到的信息是否足以回答用户的问题？"以及准确性校验——"不同来源的信息是否一致？有没有明显的矛盾？“如果判断结果为"不充分"或"有矛盾”，Agent 会触发新一轮检索，可能调整检索策略（换关键词、放宽范围、切换数据源）。

Agentic RAG 的进化不在检索算法本身，而在于给检索加了一个"大脑"——让系统自己决定搜什么、搜到的东西够不够用、不够用该怎么办。

Agentic RAG 还天然地可以与工具调用结合。检索不只是向量搜索——可以是 SQL 查询（查结构化数据库）、API 调用（查实时数据）、网页抓取（查公开信息）。这种"多工具 RAG"的思路和 MCP 协议的设计不谋而合——每个数据源作为一个 MCP Server，RAG Agent 通过标准协议调用，检索策略由 Agent 自主决策。

03 分支路线：GraphRAG 与多模态 RAG

在 Naive → Advanced → Agentic 这条主线上，还有两条重要的分支路线值得单独讨论。它们解决的问题和主线不同，但最终会和主线融合。

3.1 GraphRAG：用知识图谱对抗碎片化

Microsoft 在 2024 年开源的 GraphRAG，解决的是一个 Naive RAG 几乎完全忽略的问题：文档之间的结构和关系。

Naive RAG 把知识库当作一堆独立碎片的集合。“A 公司收购了 B 公司"和"B 公司之前是 C 公司的子公司"这两条信息可能分布在不同的 chunk 里，RAG 检索可能两条都找不到——因为用户的查询是"A 公司和 C 公司有什么关系”。

GraphRAG 的做法是在检索之前，先用 LLM 从文档中抽取实体和关系，构建一张知识图谱。然后，用社区发现算法（如 Leiden 算法）把图谱中的实体分组，为每个"社区"生成一份摘要。当用户查询时，系统不只是做向量检索，还从图谱中找到相关的实体和社区摘要，一并提供给 LLM。

GraphRAG 擅长的不是"找出包含答案的那段文字"，而是**“理解多个信息点之间的全局关系和整体模式”**。它在以下场景中优势明显：总结一个主题的整体论述（“这份财报的核心主题是什么”）、发现跨文档的模式和趋势（“行业里哪些公司在裁员”）、以及多跳推理（“影响 X 事件的间接因素有哪些”）。

但 GraphRAG 的代价也很明确：构建成本高。 实体抽取和关系构建需要大量的 LLM 调用，对大型文档库来说，这个成本可能是向量索引的 10-50 倍。而且图谱需要维护——文档更新了，图也得更新，否则信息会过时。

#mermaid-svg-DJL09ZWwDNELoMyU{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#mermaid-svg-DJL09ZWwDNELoMyU .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#mermaid-svg-DJL09ZWwDNELoMyU .error-icon{fill:#552222;}#mermaid-svg-DJL09ZWwDNELoMyU .error-text{fill:#552222;stroke:#552222;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-thickness-normal{stroke-width:1px;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-thickness-thick{stroke-width:3.5px;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-pattern-solid{stroke-dasharray:0;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-thickness-invisible{stroke-width:0;fill:none;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-pattern-dashed{stroke-dasharray:3;}#mermaid-svg-DJL09ZWwDNELoMyU .edge-pattern-dotted{stroke-dasharray:2;}#mermaid-svg-DJL09ZWwDNELoMyU .marker{fill:#333333;stroke:#333333;}#mermaid-svg-DJL09ZWwDNELoMyU .marker.cross{stroke:#333333;}#mermaid-svg-DJL09ZWwDNELoMyU svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#mermaid-svg-DJL09ZWwDNELoMyU p{margin:0;}#mermaid-svg-DJL09ZWwDNELoMyU .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#mermaid-svg-DJL09ZWwDNELoMyU .cluster-label text{fill:#333;}#mermaid-svg-DJL09ZWwDNELoMyU .cluster-label span{color:#333;}#mermaid-svg-DJL09ZWwDNELoMyU .cluster-label span p{background-color:transparent;}#mermaid-svg-DJL09ZWwDNELoMyU .label text,#mermaid-svg-DJL09ZWwDNELoMyU span{fill:#333;color:#333;}#mermaid-svg-DJL09ZWwDNELoMyU .node rect,#mermaid-svg-DJL09ZWwDNELoMyU .node circle,#mermaid-svg-DJL09ZWwDNELoMyU .node ellipse,#mermaid-svg-DJL09ZWwDNELoMyU .node polygon,#mermaid-svg-DJL09ZWwDNELoMyU .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#mermaid-svg-DJL09ZWwDNELoMyU .rough-node .label text,#mermaid-svg-DJL09ZWwDNELoMyU .node .label text,#mermaid-svg-DJL09ZWwDNELoMyU .image-shape .label,#mermaid-svg-DJL09ZWwDNELoMyU .icon-shape .label{text-anchor:middle;}#mermaid-svg-DJL09ZWwDNELoMyU .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#mermaid-svg-DJL09ZWwDNELoMyU .rough-node .label,#mermaid-svg-DJL09ZWwDNELoMyU .node .label,#mermaid-svg-DJL09ZWwDNELoMyU .image-shape .label,#mermaid-svg-DJL09ZWwDNELoMyU .icon-shape .label{text-align:center;}#mermaid-svg-DJL09ZWwDNELoMyU .node.clickable{cursor:pointer;}#mermaid-svg-DJL09ZWwDNELoMyU .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#mermaid-svg-DJL09ZWwDNELoMyU .arrowheadPath{fill:#333333;}#mermaid-svg-DJL09ZWwDNELoMyU .edgePath .path{stroke:#333333;stroke-width:2.0px;}#mermaid-svg-DJL09ZWwDNELoMyU .flowchart-link{stroke:#333333;fill:none;}#mermaid-svg-DJL09ZWwDNELoMyU .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-DJL09ZWwDNELoMyU .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#mermaid-svg-DJL09ZWwDNELoMyU .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-DJL09ZWwDNELoMyU .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#mermaid-svg-DJL09ZWwDNELoMyU .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#mermaid-svg-DJL09ZWwDNELoMyU .cluster text{fill:#333;}#mermaid-svg-DJL09ZWwDNELoMyU .cluster span{color:#333;}#mermaid-svg-DJL09ZWwDNELoMyU div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#mermaid-svg-DJL09ZWwDNELoMyU .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#mermaid-svg-DJL09ZWwDNELoMyU rect.text{fill:none;stroke-width:0;}#mermaid-svg-DJL09ZWwDNELoMyU .icon-shape,#mermaid-svg-DJL09ZWwDNELoMyU .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#mermaid-svg-DJL09ZWwDNELoMyU .icon-shape p,#mermaid-svg-DJL09ZWwDNELoMyU .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#mermaid-svg-DJL09ZWwDNELoMyU .icon-shape .label rect,#mermaid-svg-DJL09ZWwDNELoMyU .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#mermaid-svg-DJL09ZWwDNELoMyU .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#mermaid-svg-DJL09ZWwDNELoMyU .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#mermaid-svg-DJL09ZWwDNELoMyU :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}

GraphRAG 流程

原始文档

实体与关系抽取

构建知识图谱

社区检测与摘要

图谱 + 摘要存储

用户查询

向量检索 + 图遍历

LLM 综合生成

3.2 多模态 RAG：文档不只是文字

大多数企业的知识库不只是文字——PDF 里有图表、有表格、有流程图、有截图。传统的 RAG 流程在做 Embedding 时把这些非文字元素全部丢掉了。

多模态 RAG 试图解决这个问题。目前有两个主要的技术路线：

路线一：后期融合。 分别对文字和图片做 Embedding（文字用文本模型，图片用视觉模型如 CLIP 或 ColPali），检索时同时搜索两个向量空间，结果层做融合。这种方法实现简单，但融合策略（加权平均？交叉排序？）对结果质量影响很大，且缺乏统一的标准做法。

路线二：统一视觉语言 Embedding。 用 ColPali、ColQwen 这类模型，直接对文档页面的截图做 Embedding。不再区分"这段是文字"和"这张是图片"，而是把整个页面当作一个视觉整体来处理。这种方法在包含复杂排版的文档（学术论文、财报、技术手册）上效果更好，但 Embedding 模型的体量和推理成本也更大。

多模态 RAG 目前还处于比较早期的阶段，主要是工程复杂度远大于纯文本 RAG——你需要同时管理文本向量库和视觉向量库、处理不同模态之间的对齐问题、以及让 LLM 在生成回答时正确引用图片和表格中的信息。

04 生产级 RAG：一个可落地、可演进的架构设计

前面三章讨论了技术进化路线，这一章把它们串起来，给一个能直接参考的架构设计。

4.1 分层架构

一个生产级 RAG 系统应该分为四层，每一层独立演进、独立替换：

┌────────────────────────────────────────────────────────┐
│ 接入层（Routing Layer） │
│ ┌──────────┐ ┌──────────────┐ ┌──────────────────┐ │
│ │ 查询分类 │ │ 复杂度评估 │ │ 策略分配 │ │
│ │ 简单/复杂 │ │ 单跳/多跳 │ │ 用哪种 RAG 方案 │ │
│ └──────────┘ └──────────────┘ └──────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 检索层（Retrieval Layer） │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │
│ │ 向量检索 │ │ 关键词检索│ │ SQL查询 │ │ API调用 │ │
│ └──────────┘ └──────────┘ └──────────┘ └────────┘ │
├────────────────────────────────────────────────────────┤
│ 融合层（Fusion Layer） │
│ ┌──────────┐ ┌──────────┐ ┌──────────────────────┐ │
│ │ 去重合并 │ │ 重排序 │ │ 上下文压缩与结构化 │ │
│ └──────────┘ └──────────┘ └──────────────────────┘ │
├────────────────────────────────────────────────────────┤
│ 推理层（Reasoning Layer） │
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
│ │ 充分性判断 │ │ 多轮补全 │ │ 答案生成 │ │
│ └──────────────┘ └──────────────┘ └──────────────┘ │
└────────────────────────────────────────────────────────┘

接入层是系统的入口和调度器。它的核心职责是判断"这个问题应该走哪条检索路径"。一个简单的事实类问题——“公司去年的营收是多少”——走基础 RAG 就够了，不需要 GraphRAG 的多跳推理，也不需要 Agentic RAG 的多轮迭代。一个复杂的分析类问题——“分析公司营收下降的原因，结合行业趋势给出建议”——则需要启动 Agentic RAG，做多轮检索、交叉验证和结构化分析。

这层可以用一个轻量级 LLM（成本低、延迟小）来做查询分类，也可以用规则引擎（关键词匹配 + 问题类型模板）实现。

检索层包含多种检索能力，每种能力对应一种数据源。向量检索对应非结构化文档，关键词检索对应精确匹配场景，SQL 查询对应结构化数据库，API 调用对应实时外部数据。这一层的关键设计原则是"每种数据源都有最适合它的检索方式，不要试图用一把锤子敲所有的钉子"。

融合层负责把来自不同检索路径的结果整合成"模型能理解、不浪费 token"的上下文。核心操作有三个：去重（不同检索路径可能返回相同的内容）、重排序（判断哪些结果更相关）、压缩与结构化（把结果整理成清晰的结构，而不是一锅乱炖）。

推理层是 Agentic RAG 的大脑。它判断检索结果是否充分（不够就触发补全）、做多轮迭代（回检索层再次检索）、以及最终生成回答。

4.2 什么时候用什么方案

不需要一口气把所有技术都堆进去。根据你的场景选择合适的层次：

4.3 评估：不要只看检索的分数

RAG 系统最容易被忽略的部分是评估。很多团队把优化方向放在检索准确率（Recall@K、MRR）上，但检索准确率提升并不总意味着端到端回答质量的提升。 有时候你把 Recall 从 85% 提到了 92%，但用户感受到的改善微乎其微——因为那 7% 的增量信息在 LLM 生成回答时被忽略掉了。

一个更务实的评估框架包含三个层次：

第一层：检索质量。 Recall@K、Precision@K、MRR。这些是必要条件，不是充分条件。如果检索质量很差，后面的环节再强也没用。但检索质量一旦超过某个阈值（通常在 80-85% 左右），继续优化的边际收益递减。

第二层：上下文利用率。 检索到的内容是否被模型在生成回答时有效使用了？可以通过"引用覆盖率"来衡量——模型的回答中有多少事实性陈述能找到对应的检索来源。这个指标比检索准确率更能反映端到端的质量。

第三层：回答质量。 正确性（回答的事实是否准确）、完整性（是否回答了问题的所有方面）、有用性（用户是否真的解决了问题）。这一层目前主要靠人工评估或 LLM-as-Judge，自动化程度有限，但它是最接近真实用户体验的一层。

05 总结

RAG 没有死。死的是那个不加改进、不修 bug、拿 2023 年的标准方案直接往生产环境里扔的幼稚做法。而活下来的，是经历了分块策略优化、检索策略升级、自主推理增强、知识图谱补充、多模态覆盖这一整套进化之后的新一代 RAG。

几个核心要点：

• RAG 的进化是补丁驱动的，不是架构重写。 从 Naive 到 Advanced 到 Agentic，每一层增量都是在解决前一层的具体痛点，而不是推倒重来。你现在搭建的 Advanced RAG 系统，未来升级到 Agentic 时不需要重构底层。
• GraphRAG 不是 RAG 的替代品，而是互补品。 它解决的是"全局关系理解"问题，RAG 解决的是"精确信息检索"问题。两者在产品中的角色不同，合并使用才是正确姿势。
• Agentic RAG 的核心价值不在"多轮检索"，而在"自主判断"。 让系统自己决定搜没搜够、搜得对不对——这个决策环才是质的飞跃。
• 评估问题是当前最大的工程空白。 检索质量、上下文利用率、端到端回答质量这三层指标体系远未成熟，大部分团队还停留在"拍脑袋觉得效果还行"的阶段。
• 生产级 RAG 需要分层演进。 不是所有查询都需要 Agentic RAG 的复杂度。接入层的路由能力——根据问题类型选择匹配的检索方案——是被普遍低估但性价比极高的优化点。

RAG 领域正在发生的事，和其他成熟技术的演进路径如出一辙：它从"一个 idea"变成"一套工程方案"，再从"一套工程方案"变成一个"生态"。当你听到有人说"RAG 死了"的时候，你听到的其实是一个人停下了脚步的声音——而路还在往前延伸。