RAG 工程： GraphRAG 中的 DeepResearch ? 解读 GRAPHSEARCH 设计

这篇工作是一个工程化的设计思路，基本上和算法没关系。可以理解为是 GraphRAG 检索环节的一种 Agentic 检索设计。感觉类似 GraphRAG 中的 “Deep Research”

是否有参考价值，如果我们能确定现有检索场景下的 BADCASE 的具体原因，可以引入此工程思路，看是否能解决。

传统的 RAG，说白了就是个“文本搜索”，丢个问题，搜一堆相似的文本片段，然后让 LLM 去总结。这在处理简单问题时还行，一旦问题复杂点，需要把好几个零散的知识点串起来才能回答，传统 RAG 就拉了胯了。

为了解决这个问题，社区里的大佬们搞出了 GraphRAG。思路很直接：别光把知识存成一堆散装文本了，把它整理成知识图谱（Graph KB）吧！用节点（实体）和边（关系）把知识结构化地串联起来，这样在检索的时候，不仅能看到信息本身，还能看到信息之间的联系。

现实是，很多 GraphRAG 的方案还是没能发挥出图谱的真正威力。它们往往面临两个致命的瓶颈，导致在复杂问题面前，表现得像个“半吊子”侦探。

一、现有 GraphRAG 的两大“软肋”

1.1 软肋一：浅层检索（Shallow Retrieval）

第一个问题，也是最致命的，就是浅层检索。

大多数 GraphRAG 的工作流程非常简单粗暴：一次性检索，一次性生成。就像一个新手侦探，接到案子后，冲到案发现场扫了一眼，拿了点表面证据，就回去写结案报告了。如果案情简单，可能瞎猫碰上死耗子。但如果案情复杂，需要多个线索环环相扣，这种“一锤子买卖”的调查方式，大概率会漏掉关键证据，导致推理失败。

论文里给了一个绝佳的例子，咱们来看看。假设你问这样一个问题：

“WIZE 公司获得许可的小镇，是在沃德镇（Ward Township）所在州的哪个首府城市？” (原文: "When did the town WIZE is licensed in become capital of the state where Ward Township is located?") （Warren 注：原文是问时间，但为了聚焦检索问题，我们简化为问地点）

这个问题有点绕，是个典型的“多跳（multi-hop）”问题，我们拆解一下它的逻辑链：

1. 找到 "沃德镇 (Ward Township)" 在哪个县。 -> 伦道夫县 (Randolph County)
2. 找到 "伦道夫县" 在哪个州。 -> 印第安纳州 (Indiana)
3. 找到 "WIZE 公司" 在哪个小镇获得了许可。 -> 印第安纳波利斯 (Indianapolis)
4. 确认 "印第安纳波利斯" 是不是 "印第安纳州" 的首府。 -> 是的

所以，最终答案是 "印第安纳波利斯"。你看，要回答这个问题，你需要至少四个关键信息点，并且它们之间是层层递进的关系。

传统的 GraphRAG 是怎么处理的？它会把整个复杂问题作为关键词，去知识图谱里进行一次语义搜索。结果很可能是，它找到了“沃德镇”、“WIZE 公司”和“印第安纳波利斯”这些直接相关的实体，但唯独漏掉了中间的桥梁——“伦道夫县”。

这就是浅层检索的致命缺陷：一次性的、基于表面相似度的检索，无法深入挖掘和串联复杂查询所需的完整证据链。

1.2 软肋二：图结构利用不充分

第二个问题，其实是第一个问题的直接后果：对辛辛苦苦构建的图结构数据，利用效率极低。

我们为什么要费劲巴拉地构建知识图谱？不就是为了利用它那明晰的“实体-关系-实体”结构，来进行精准、可靠的多步推理吗？

但是，在浅层检索的模式下，由于一次性检索无法保证召回足够多的相关节点和边，你拿到的往往是一个支离破碎的、稀疏的子图。在这个残缺的图上，很多重要的路径和关系都丢失了。LLM 看着这个残缺不全的“地图”，想做路径规划（逻辑推理）也无从下手。

最后，LLM 只能退而求其次，把这些图结构信息当成普通的文本来处理，主要还是依赖从文本块（text chunks）中检索到的语义信息。这下好了，绕了一大圈，又回到了传统 RAG 的老路子上。知识图谱的结构优势，基本上被浪费了。

论文用一个实验数据图清晰地揭示了这一尴尬局面。

这个结果简直是在打 GraphRAG 的脸。它说明，在现有浅层检索机制下，图谱数据的贡献非常有限，甚至可以说是可有可无。 这也解释了为什么很多团队投入巨大精力构建了知识图谱，却发现对下游任务的提升并不明显。问题不出在图谱本身，而出在“使用图谱的方式”上。

好了，病根找到了。总结一下就是：一次性的浅层检索导致证据链不完整，进而使得图结构的优势无法发挥。 那么，GRAPHSEARCH 是如何对症下药的呢？

二、GRAPHSEARCH 的核心解法：一个会“思考”的****智能体

面对上述两个顽疾，GRAPHSEARCH 开出的药方可以总结为两个核心思想：

1. 用“Agentic Workflow”，替代“一锤子买卖”的检索。
2. 用“双通道检索”，精细化地分工利用文本和图谱。

我们先来看第一个，也是最核心的——Agentic Workflow。

GRAPHSEARCH 不再把检索看作一个单一的动作，而是设计成一个由 LLM 驱动的、可以多轮交互、迭代思考、自我反思的智能代理。这个代理就像一个经验丰富的老侦探，它懂得如何将一个复杂的大案子，拆解成一系列的小任务，然后一步步地调查、取证、验证，直到形成完整的证据链。

我们来看一下 GRAPHSEARCH 的整体框架图，感受一下这个“侦探”的工作流程。

这个工作流被巧妙地设计成了一个包含六个模块的流水线。这六个模块又可以分为两大阶段：迭代式检索（Iterative Retrieval） 和 反思式路由（Reflection Routing）。

2.1 第一阶段：迭代式检索（Iterative Retrieval）

这个阶段的目标是把复杂问题“化整为零”，然后逐个击破，并且把每一步的结果作为下一步的输入，实现信息的滚动累积。它包含三个核心模块。

模块一：查询分解 (Query Decomposition, QD)

这是整个流程的起点。当代理拿到一个复杂的、包含多个逻辑跳跃的问题时，它做的第一件事不是去搜索，而是**“分解问题”**。

它会调用 LLM，使用一个特定的提示（Prompt），将原始问题 Q 分解成一个有序的、原子化的子问题序列 {q1, q2, ..., qm}。每个子问题都只关注一个单一的事实点，比如一个实体、一个关系或者一个属性。

举个例子，对于前面那个复杂问题：

“WIZE 公司获得许可的小镇，是在沃德镇（Ward Township）所在州的哪个首府城市？”

QD 模块可能会把它分解成这样几个子问题：

• q1: "沃德镇 (Ward Township) 位于哪个县？"
• q2: "q1 的答案所在的县，位于哪个州？"
• q3: "WIZE 公司在哪里获得了许可？"
• q4: "q3 的答案，是不是 q2 答案所在州的首府？"

你看，通过分解，原本一团乱麻的问题，瞬间变得条理清晰。这种分解操作，极大地降低了后续每一个检索步骤的难度，让检索器可以更精准地命中目标。

分解完成后，代理会拿着第一个子问题 q1，去知识库（Graph KB）里进行第一次检索，得到相关的上下文 C_q1。

模块二：上下文精炼 (Context Refinement, CR)

检索器从知识库里捞回来的原始信息 C_q1，可能包含了很多噪音和不相关的内容。就像你用搜索引擎，前几个结果也未必都是你想要的。

CR 模块的作用就是**“去粗取精”**。它会再次调用 LLM，让 LLM 扮演一个“信息筛选员”的角色，根据子问题 q1 的意图，从原始的上下文 C_q1 中，筛选出最核心、最相关的实体、关系和文本证据，生成一个干净、精炼的上下文 C'_q1。

这一步确保了后续的推理和生成，都是基于高质量的、高信噪比的证据，避免被无关信息干扰。

模块三：查询落地 (Query Grounding, QG)

这是实现“迭代”的关键一步。还记得我们分解出的子问题序列吗？它们之间是有逻辑依赖的，比如 q2 的执行依赖于 q1 的答案。

QG 模块的作用就是**“承上启下”**。它首先会利用上一步精炼后的上下文 C'_q1，让 LLM 生成 q1 的中间答案 â_q1。

例如，对于 q1: "沃德镇位于哪个县？"，LLM 结合上下文 C'_q1 可能会生成答案 â_q1: "伦道夫县"。

然后，最关键的操作来了：代理会将这个新鲜出炉的答案 â_q1，**“填空”**到下一个子问题 q2 中。

原本的 q2 是："q1 的答案所在的县，位于哪个州？" 经过 QG 模块处理后，它就变成了一个全新的、完全具体的“落地”查询 ~q2：

~q2**: "伦道夫县位于哪个州？"

看到了吗？通过这个“生成答案 -> 填入下个问题”的循环，原本抽象的、相互依赖的子问题链，变成了一个个具体的、可以独立执行的查询。 代理拿着这个具体的 ~q2 去检索，自然比拿着模糊的 q2 要精准得多。

这个 分解 -> 检索 -> 精炼 -> 回答 -> 填空 的过程会不断循环，直到所有分解出的子问题都被处理完毕。至此，代理手上就积累了一系列的“子问题-上下文-中间答案”三元组 {~qi, C'~qi, âi}。

2.2 第二阶段：反思式路由（Reflection Routing）

当第一阶段的迭代检索完成后，代理已经收集了一堆“证据碎片”。但这些碎片是否足够拼成完整的“破案拼图”？逻辑上有没有矛盾？这就是第二阶段“反思式路由”要解决的问题。这个阶段引入了类似人类思考时的“反思”和“纠错”机制，是 GRAPHSEARCH 智能化的集中体现。它也包含三个模块。

模块四：逻辑起草 (Logic Drafting, LD)

在这一步，代理会扮演一个“书记员”的角色。它会把前面收集到的所有“子问题-上下文-中间答案”三元组，整合起来，并尝试构建一个初步的推理草稿（Logic Draft） L。

这个草稿会清晰地展示出，为了回答原始的复杂问题 Q，代理都走了哪些推理步骤，每一步都找到了什么证据。

例如，草稿 L 可能会是这样的：

1. 步骤 1 (基于 q1): 确认“沃德镇”位于“伦道夫县”。【证据：...】
2. 步骤 2 (基于 q2): 确认“伦道夫县”位于“印第安纳州”。【证据：...】
3. 步骤 3 (基于 q3): 确认“WIZE 公司”的许可地是“印第安纳波利斯”。【证据：...】
4. 步骤 4 (基于 q4): 比较“印第安纳波利斯”与“印第安纳州的首府”。【证据：...】

这个起草过程，不仅是整理证据，更重要的是“暴露问题”。 如果在构建这个逻辑链时，发现某一步的证据缺失（比如，压根没找到“伦道夫县”在哪），或者不同步骤的答案之间存在逻辑矛盾，这些问题都会在草稿 L 中明确地暴露出来。

模块五：证据校验 (Evidence Verification, EV)

有了推理草稿 L，代理就进入了“自我审视”模式。EV 模块会像一个严苛的法官一样，审查这份草稿。

它会问自己几个关键问题：

• 充分性： 当前收集到的所有证据，是否足以完整地回答最初的复杂问题 Q？有没有哪个环节还缺证据？
• 一致性： 不同步骤的中间答案之间，是否存在逻辑矛盾？
• 真实性： 每个中间答案，是否都能在它对应的上下文中找到坚实的支撑？

经过审查，EV 模块会给出一个裁决：Accept（接受）或 Reject（拒绝）。

• 如果裁决是 Accept，说明证据链完整且可靠，代理就可以进入最终的答案生成环节，功成身退。
• 如果裁决是 Reject，说明当前的证据还不够，或者有硬伤。这时，流程就不会终止，而是进入下一个、也是最体现“深度搜索”精髓的模块。

模块六：查询扩展 (Query Expansion, QE)

当 EV 模块说“不行，证据不足”时，QE 模块就该上场了。它扮演的是“问题分析专家”的角色。

它会仔细分析被“拒绝”的逻辑草稿 L，定位到具体是哪个环节出了问题，是哪个知识点缺失了。然后，它会针对性地生成一个或多个全新的、补充性的子查询 {q+j}。

回到我们最初的例子，假设在第一轮迭代检索中，代理没能找到“伦道夫县”的位置。逻辑草稿 L 在第二步就会卡住，EV 模块会判定 Reject。

这时，QE 模块就会分析出问题在于“伦道夫县和州的关系未知”，于是它可能会生成一个新的扩展查询 q+1：

q+1**: "‘伦道夫县’是美国哪个州的一部分？"

然后，代理会拿着这个新的、目标极其明确的查询 q+1，重新启动一轮检索循环，去知识库里“深挖”这个缺失的关键证据。新找到的证据会被补充到证据池中，然后代理会再次进行逻辑起草（LD）和证据校验（EV）。

这个 起草 -> 校验 -> 拒绝 -> 扩展查询 -> 再检索 的闭环，就是 GRAPHSEARCH 实现“深度搜索”的秘密所在。 它不是一次性的浅层搜索，而是一个不达目的不罢休的、持续深挖的过程。只要证据链不完整，它就会不断地自我反思、提出新问题、寻找新证据，直到拼凑出完整的逻辑拼图。

通过这个由六个模块组成的、可循环的智能代理工作流，GRAPHSEARCH 成功地解决了“浅层检索”的顽疾，把检索过程从一个简单的动作，升维成了一个动态的、智能的、不断接近真相的调查过程。

三、另一大杀器：双通道检索

如果说“Agentic Workflow”是 GRAPHSEARCH 的“大脑”和“神经系统”，解决了“怎么搜”的问题，那么“双通道检索”就是它的“专业工具箱”，解决了“用什么工具搜”的问题。

前面我们提到，GraphRAG 的一个痛点是图结构利用不充分。GRAPHSEARCH 认为，这很大程度上是因为没有“因材施教”——用同样的方式去对待两种完全不同的数据类型：非结构化的文本块（Text Chunks） 和 结构化的图数据（Graph Data）。

GRAPHSEARCH 的做法是，为这两种数据类型，设计两条专门的检索通道：语义通道（Semantic Channel） 和 关系通道（Relational Channel）。在查询分解（QD）阶段，原始问题会被同时分解成两种不同风格的子问题，分别交给这两个通道去执行。

这就好比一个侦探团队里，有两类专家：

• 一位是审讯专家（语义通道）： 他擅长和人（文本）打交道，能从目击者的长篇大论中，捕捉到关键的描述性细节。
• 一位是数据分析专家（关系通道）： 他擅长分析电话记录、社交网络（图谱），能从海量结构化数据中，快速找出人和人之间的关联路径。

这两位专家各司其职，最后把信息汇总，才能高效破案。

3.1 语义通道：在“文本海洋”中捞取描述性事实

语义通道专门负责处理基于文本的检索。它会将原始问题分解成一系列自然的、描述性的子问题。

举个例子，对于一个查询：

"创作了《维纳斯的崇拜》这幅画的艺术家，在他去世的地方，瘟疫发生了多少次？"

语义通道会将其分解为：

• q1(s): "谁是《维纳斯的崇拜》的创作者？"
• q2(s): "这位创作者在哪里去世的？"
• q3(s): "在那个地方，关于瘟疫的记录有哪些？"

这些子问题会被发送到文本索引（比如基于向量的文本数据库）中进行搜索。它的目标是从原始的文本块中，找到包含丰富描述、上下文和细节的证据。比如艺术家的生平介绍、某地的历史事件记录等。

语义通道的优势在于，它能捕捉到那些难以被结构化的、细致入微的知识。

3.2 关系通道：在“知识图谱”上追踪结构化路径

关系通道则完全是另一套玩法。它专门负责处理基于图结构的检索。它会将同样的问题，分解成一系列结构化的、类似 Cypher 或 SPARQL 查询的“三元组”式子问题。

对于同样的问题，关系通道可能会这样分解：

• q1(r): (主体: 《维纳斯的崇拜》, 关系: 'has_creator', 对象: ?Entity1)
• q2(r): (主体: ?Entity1, 关系: 'died_in', 对象: ?Entity2)
• q3(r): (主体: ?Entity2, 关系: 'had_event', 对象: ?Event)，其中 ?Event 的类型是“瘟疫”。

这些子问题会被发送到图数据库中进行查询。它的目标是利用图谱的结构，精准地沿着实体之间的关系路径进行“跳转”（hop）。从“画作”节点，跳到“创作者”节点，再跳到“地点”节点，最后筛选出该地点的“瘟疫事件”节点。

关系通道的优势在于，它能非常高效和可靠地执行多步逻辑推理，确保推理路径的连贯性和正确性。

3.3 双剑合璧，威力倍增

GRAPHSEARCH 的聪明之处在于，它同时运行这两个通道，让它们并行工作，最后将两个通道检索到的信息（文本块和子图）汇总起来，共同作为 LLM 生成答案的上下文。

这样做的好处是显而易见的：

• 优势互补： 语义通道提供了丰富的背景和细节描述，而关系通道提供了清晰、可靠的逻辑骨架。两者结合，既有血肉，又有筋骨。
• 信息冗余与交叉验证： 两个通道可能会从不同角度找到相同的证据，这可以作为一种交叉验证，提高证据的可靠性。
• 更全面的证据覆盖： 有些知识可能只存在于文本中，有些则更适合用图结构表示。双通道确保了两种类型的知识都不会被遗漏。

论文中的实验也证明了这种双通道设计的有效性。

四、是骡子是马？拉出来遛遛！

GRAPHSEARCH 的效果到底怎么样？论文进行了一系列详尽的实验，咱们挑几个最关键的来看看。

4.1 全面超越基线，效果显著

首先是和现有的一系列 RAG 及 GraphRAG 方法的正面硬刚。实验在包括 HotpotQA、MuSiQue 等六个主流的多跳问答数据集上进行。

Table 1: 跨六个多跳问答基准的实验结果 (Warren 注：这里我不贴原表格，而是提炼核心信息进行解读)

数据集	方法	SubEM (答案命中率)	A-Score (答案质量)
MuSiQue	LightRAG (基线)	35	6.5
	GRAPHSEARCH + LightRAG	51	7.72
	PathRAG (基线)	46.33	7.26
	GRAPHSEARCH + PathRAG	55.33	7.83
Legal (法律领域)	HyperGraphRAG (基线)	66.6	8.18
	GRAPHSEARCH + HyperGraphRAG	78.52	8.76

从表格中我们可以提炼出几个关键信息：

1. GRAPHSEARCH 稳定碾压所有基线： 在所有六个数据集上，无论是在答案的精确匹配率（SubEM）还是由 LLM 评判的答案质量（A-Score）和证据质量（E-Score）上，GRAPHSEARCH 都取得了最好的成绩。
2. 强大的“即插即用”能力： 这点非常牛。GRAPHSEARCH 并非要完全取代现有的 GraphRAG 方法，而是可以作为一个“增强插件”，应用在它们之上。从表格中可以看到，无论是 LightRAG、PathRAG 还是 HyperGraphRAG，当它们各自的检索器被集成到 GRAPHSEARCH 的工作流中后，性能都得到了巨幅提升。
   1. 例如，在 MuSiQue 数据集上，LightRAG 单独使用时 SubEM 只有 35.00，接入 GRAPHSEARCH 后飙升至 51.00，提升了超过 45%！
   2. 在专业的法律领域数据集上，最先进的 HyperGraphRAG 接入 GRAPHSEARCH 后，SubEM 也从 66.60 提升到 78.52。

这充分证明了 GRAPHSEARCH 的 agentic 工作流和双通道检索策略，是一种普适且高效的“元框架”，能够赋能各种不同的图谱检索底层。

4.2 拆解分析：每个模块都在发光发热

为了证明框架里每个模块都不是“吃干饭”的，论文做了一系列烧钱的消融实验。简单说，就是把 GRAPHSEARCH 的模块一个个去掉，看看性能会下降多少。

实验以 GRAPHSEARCH + HyperGraphRAG 为例，逐步添加模块：

1. 基线 (HyperGraphRAG): 在 Legal 数据集上，SubEM 为 66.60。

• 查询分解 (QD) & 上下文精炼 (CR): 性能提升至 73.98。这说明，仅仅是把问题拆开、把上下文弄干净，就已经有巨大好处。
• 查询落地 (QG): 性能进一步提升至 77.31。这证明了“迭代式”地用上一步答案更新下一步问题的做法，是打通逻辑链的关键。
• 全套反思模块 (LD, EV, QE): 性能最终达到 78.52。这最后的提升，归功于“反思-纠错-扩展”这个深度搜索循环，它能弥补前序步骤中可能出现的证据缺口。

结论非常清晰：GRAPHSEARCH 的六个模块，环环相扣，缺一不可，共同构成了其强大的深度搜索能力。

4.3 预算有限？依然坚挺！

在真实业务场景中，我们往往会面临计算资源和时间的限制，不可能无限制地去检索。那么，如果在检索预算（比如，每次检索返回的文档数量 Top-K）很低的情况下，GRAPHSEARCH 的表现如何呢？

可以看到，当 Top-K 从 50 降到 10 时：

• Naive RAG 和 LightRAG 的性能（蓝色和橙色线）出现了断崖式下跌。这很符合直觉，因为它们是“一锤子买卖”，检索预算一砍，拿到关键证据的概率就急剧降低。
• GRAPHSEARCH (绿色线) 的性能虽然也有所下降，但下降得非常平缓，并且在低预算下依然大幅领先于其他方法。

这个结果意义重大。它说明 GRAPHSEARCH 的智能代理工作流，能够通过多次、小范围、高精度的“点射”，来弥补单次“扫射”范围不足的缺陷。 即使每次只能拿到少量信息，它也能通过迭代和反思，逐步拼凑出完整的证据链。这种特性在资源受限的生产环境中，具有极高的实用价值。

4.4 深入肌理：看看它到底是怎么“深”的

最后，我们通过一个可视化的例子，来直观感受一下 GRAPHSEARCH 的“深度搜索”过程。论文通过计算每一步检索到的 Golden Evidence 的召回率，来量化检索质量的提升过程。

• 在 Step 1，也就是初始的查询分解和检索阶段，召回率其实并不高。这是因为子问题非常聚焦，只会检索到部分证据。
• 但随着交互的进行（Step 2, 3...），Agent 不断地进行查询落地（QG）、反思（EV）和扩展查询（QE），两个通道的召回率都在稳步攀升。
• 到了最后的 Self-reflection 阶段，也就是经过了完整的“反思-纠错”循环后，召回率达到了顶峰。

这张图完美地诠释了什么叫“深度搜索”：它不是一步到位，而是一个知识不断积累、证据不断完善的动态过程。 这也从根本上解释了为什么 GRAPHSEARCH 能够解决“浅层检索”的问题。

五、Warren's Take：我的几点看法

1. Agentic RAG 是大势所趋。 从简单的“检索-生成”到 GRAPHSEARCH 这种具备“分解-行动-反思”能力的智能体，是 RAG 发展的必然方向。这标志着我们正在从“让 LLM 使用工具”，走向“让 LLM 学会如何思考并自主地使用工具组合”。对于我们开发者来说，未来的挑战可能不再是实现单个的检索功能，而是如何设计和编排这些复杂的 Agentic 工作流。
2. 模块化和“即插即用”是走向实用的关键。 GRAPHSEARCH 最让我欣赏的一点，是它的框架设计。它没有试图推倒重来，搞一个完全封闭的体系，而是设计成一个可以兼容并增强现有检索器的“元框架”。这种“开放”和“可插拔”的设计，极大地降低了落地门槛，使得团队可以在不抛弃现有技术栈（比如已经建好的向量数据库或图数据库）的基础上，渐进式地引入这套更先进的工作流。这对于企业级应用来说，吸引力是巨大的。