RAG 技术升级录：从 GraphRAG 到 Fusion GraphRAG

本文整理自 NebulaGraph 高级解决方案架构师@邵晓凌，在杭州 AWS UG 上的分享《超越 GraphRAG: Fusion GraphRAG 与 AI Memory 的落地实践》。
如果您的企业正在重构基于多模态文档的 Fusion GraphRAG 架构，欢迎通过下方链接填写技术咨询问卷。
https://wj.qq.com/s2/15344088/w7ei/

当前企业在落地大模型应用时，检索增强生成（RAG）因其较高的投入产出比，成为大多数场景下的首选方案。

当然，微调、强化学习这些技术大家也都有所了解，但从投入产出的角度来说，RAG 确实用得比较多。我相信在座的搞研发的同事应该都尝试过，今天也有不少业务侧的朋友，所以我稍微再展开介绍一下。

RAG 的技术流程可以概括为三个核心环节。

1. 索引：把企业内部的文档或者从网上获取的信息，以一种高效的形式组织起来。

2. 查询：用户来了一个问题，系统要确定去哪里找。

3. 生成：把找到的信息交给大模型去做分析，让它来生成回答。

一开始大家用向量检索的方式来实现这三步，效率比较高，实现的逻辑也比较简单。

然而，随着实践深入，基于向量检索的 RAG 方案暴露出若干系统性的问题。

1. 细粒度知识检索能力不足

比如说你拿一个 2025 年的信息去查，它可能给你返回一个 2015 年的东西。这背后的原因是什么呢？

文本分块本身存在两难。切短了，一个反问句可能从中间被截断，语义完全反了；切长了，关键信息又被冗余内容稀释，导致检索精度下降。

2. 向量相似性与语义相关性存在偏差

向量检索本质上是在算余弦相似度，但相似的向量不一定代表语义相关。PPT 上举了一个很典型的例子：两个句子都出现了"苹果"这个词，上面说的是水果苹果，下面说的是手机苹果。

向量表示可能非常接近，但语义完全不是一回事。这就导致了检索结果跟用户的真实需求对不上。

从技术原理上分析，这种错配的根源在于向量嵌入模型对上下文信息的压缩方式。当同一词汇出现在不同语义环境中时，嵌入模型往往无法仅凭局部上下文进行有效区分，尤其是在词汇本身具有多重语义的情况下。这种表征学习的局限性直接传导至检索层，表现为高相似度分数但低相关性的召回结果。

3. 上下文关联能力的缺失

在企业文档体系里，一级部门、二级部门、三级部门的文件之间有明确的引用关系。下级文件往往是引用或落实上级政策。

但向量检索把这些文档碎片化之后，完全丢失了文档之间的层级关系。你只是把它们顺序地扔进向量库里，它们之间的关联就全部消失了。

4. 全局性问题的回答能力不足

比如说你给它一份五万字的政府工作报告，你问"这里面最重要的五个要点是什么"，它可能就回答不出来。如果你想把每一段都抓取出来再做总结，成本又非常高。

有了这些局限性，大家自然会去想，我们还有什么其他的手段？因为我们本身是做图数据库的，所以首先想到的就是，能不能用"图"（Graph）这个概念来弥补传统 RAG 的不足。

这里说的"图"不是图片，学过离散数学的朋友应该知道，图论里面的图，是把世界万物抽象成点和边的关系。人和人之间、公司和交易之间，各种各样的东西都可以用图来表达。

大家最初接触到 GraphRAG，可能是通过微软研究院 2024 年发表的那篇《From Local to Global: A GraphRAG Approach to Query-Focused Summarization》。

这篇文章系统地阐述了 GraphRAG 的理论基础和实践结论。

但事实上，NebulaGraph 在微软那篇文章发布之前半年就已经开始了这方面的探索。如果大家去看微软那篇论文，会发现里面引用了我们的技术博客。所以我们在 GraphRAG 方向上做得还是比较早的。

GraphRAG 跟向量 RAG 最根本的区别在哪里呢？

向量 RAG 是把文章切成一块一块的文本块，而 GraphRAG 不做机械切分。它是在文本块里面抽取有用的实体以及实体之间的关系，然后把最主要的信息以图的形式保留下来。这样就从机制上规避了文本分块带来的问题。

在语义消歧方面，图谱的优势也很明显。不同的"苹果"在图谱里是不同的节点，各有各的上下文和属性，不会因为向量接近就混为一谈。

在上下文关联方面，我举个例子。假设你在最上级部门的文档里抽出了一个实体叫"反洗钱"，你把它放在图里，建立一条从"反洗钱"到"一级政策部门文档"的关系。等你分析下级部门细则的时候，又发现了一个"反洗钱"实体，你又建立一条从"反洗钱"到"三级部门细则"的关系。

通过这两个文档共同拥有的实体，所有相关的信息就在图上打通了。用户再来问那种多跳的问题，系统就比较容易解答。

从图论的角度来看，这实际上是在构建一个异构图谱，其中包含文档节点、实体节点以及它们之间的多种关系边。当用户提出多跳问题时，系统通过在图上执行路径查询或子图匹配，能够保留完整的推理链路，这比向量检索的隐式语义匹配在可解释性和准确性上都有明显优势。

全局性问题也是微软那篇文章重点提到的。图的方式怎么处理呢？

在建索引的过程中，我们已经把文章里所有重要的实体都放到了图里。

NebulaGraph 本身有一些内置的算法，可以对图进行社区发现。比如你有 200 万个实体，运行一次社区发现算法，可能把它们聚成 300 个社区。然后你对每个社区用大模型生成一个概要。在这 300 个社区之上，再运行一次社区发现，可能又聚成 20 个第二层级的社区，再做一次总结。

这样几轮下来，即便一开始有 200 万个节点，最后可能就总结成两三个高层次的社区，对应的是对整个文档集的概括性摘要。用户来了全局性问题，你只需要在这两三个社区的概要里面去做检索，速度非常快。

这种层级化社区摘要的构建思路，本质上是一种面向查询的自上向下索引结构。与向量 RAG 需要在查询时实时聚合大量文本块不同，GraphRAG 将摘要计算前置到索引阶段，实现了查询时的高级别社区摘要访问，这是其在全局性问题场景下性能优势的根本来源。

刚才讲的 GraphRAG 相比向量 RAG 有很多优势，但我们也在实践中发现，GraphRAG 在某些场景下还是有一些不足，特别是对多版本文档的处理。

所以我们在 GraphRAG 的基础上提出了 Fusion GraphRAG.

核心思路就是在图谱的基础上叠加更丰富的信息——文档的元数据、章节结构等，帮助提升检索效果。

另外我们也发现，要回答用户各种各样的问题，把多种索引方式融合起来效果更好。每种索引方式各有各擅长的场景。所以我们把向量索引、全文索引、图索引统一存储在 NebulaGraph 里，由系统根据问题类型自动选择最优路径。

这种多索引融合的架构设计，在信息检索领域有着坚实的理论基础。不同索引结构对应着不同的检索模型。向量索引对应语义模型，全文索引对应布尔模型和BM25，图索引对应关系模型。每种模型在特定的信息需求和文档特征下各有优势。

Fusion GraphRAG 通过检索结果的多路融合与重排序，在系统层面实现了对不同检索模型的互补利用。

我们在开源数据集上做过对比，该数据集以多跳问题为主。我们的方案在召回率和回答准确率上都比目前已知的最佳方案高出了 10个百分点以上。在我们的一个金融客户的法律法规文档实测中，准确率达到了 95% 以上。

Fusion GraphRAG 这套方案目前在多个行业客户中已经落地了。

制造业智能排障

有些制造企业产品线很广，不是每个员工都了解所有产品，一出故障比较难定位。我们帮他们把运维手册、操作手册、设备日志这些非结构化文档利用起来，通过大模型和图技术，快速定位故障原因和解决办法。

还有一个做服装的客户，品类特别多，人员流动率也大，新员工培训是个大问题。以前客户问"夏天要选一款防汗的男式衬衣"，只能凭印象或者去数据库里自己找。现在用自然语言描述一下，系统就能帮你从知识库里精准匹配。

2. 财报分析

上市公司财报有个特点，表格特别多，而且不同表格之间相互引用、相互关联。数据有没有矛盾？企业经营状况怎么总结？这些都是挑战。利用我们的工具，可以比较好地解决这个问题。

3. 合同合规审查

假设你所在行业有 100 部国家法律法规，你跟客户签合同的时候，拿这套工具去这 100 部法规里查一查，看看有没有违反法律的风险，或者对企业有什么风险，这是一个很典型的应用场景。

4. 企业 AI 搜索和智能客服

以前谷歌、百度都做过企业内网搜索，基本都失败了。很大一部分原因是传统搜索引擎依赖点击数据来排序，企业内部文档哪来的点击量？没有点击数据，搜索引擎就很笨。有了大模型之后就不一样了，它能理解用户的问题，知道去哪里找答案。

钉钉群或者企业微信的客服场景也是如此，用户问题来了，如果每个都让手工回答，非常累。尤其在国内，大家要求几秒钟几分钟就要响应。我们的工具可以在两三个小时里帮你搭建一套客服系统，7×24 小时去响应，无论是内部员工的疑问还是外部用户的问题，都可以覆盖。

接下来简单看一下用户界面和产品功能。

平台支持所有最常用的文档格式，Word、Excel、PDF、PPT 都可以。我们通过一套工具把文档转化成模型能理解的格式。

另外，这套工具的一个优势是对大模型 token 的消耗比较低。在不建知识图谱的情况下，甚至可以做到零 token 消耗就把索引建好。当然问答环节肯定还是需要消耗 token 的，这个避免不了。

大模型方面，主流的 Qwen、GPT、GLM 都可以，只要兼容 OpenAI 接口格式就行。

在平台里，向量索引、全文索引、图索引都可以选。如果你觉得图索引消耗资源大，可以不用；如果觉得全文跟向量差不多，只选一种也行。比较灵活，用户可以自己决定。针对不同的问题类型，我们也有一些最佳实践可以一起探讨。

另外，如果用户已经有结构化数据存在图数据库里，我们还支持 Text2GQL。用户不需要自己手写 GQL 查询语言，用自然语言描述就行。

我想了解一下图搜索的效率控制。咱们是怎么做图的剪枝，或者控制多跳范围的？毕竟大模型上下文有限，怎么控制这个注意机制？

回答：图上的检索流程大概是这样的。用户问题来了之后，先对问题里的实体做提取。比如问题里提到了"反洗钱"和"银行"，你就根据这两个词到图里找对应的节点。找到之后，根据图算法去做路径发现或者邻居扩展，把相关的节点和路径信息找出来。你不一定只限于这两个节点之间的信息，也可以做拓展，比如从一个节点往外拓展一层或两层，然后把所有相关信息喂给大模型做生成。这就是一个基本的流程。

从技术实现上，我们会在检索阶段设置跳数限制和节点数量上限，防止子图过度膨胀。同时利用图谱的边权重和节点重要性评分对扩展方向进行剪枝，优先保留与查询实体关联度最高的路径。