从 RAG 到 Fusion GraphRAG，我们究竟想让 AI 学会什么？

NebulaGraph SA 牛天星曾带来精彩分享《超越 GraphRAG：Fusion GraphRAG 及其在多场景落地实践》，并将其中一节分享名为《超越超越的超越》。本文在分享的基础上，以“超越”作为一条递进主线：Graph→RAG→GraphRAG →Fusion GraphRAG→Ontology, 从这样的技术演变历程，与大家共同探讨：我们真正想让 AI 学会什么？我们到底需要怎样的 AI？

近年来，数据，尤其是私有化数据，已成为 AI 时代企业的护城河。

因为模型可以不断更换，数据却具有独占性、累积性和反馈性。一个企业真正积累下来的行业知识、业务经验、客户信息、生产数据以及长期沉淀的流程与规则，才是很难被别人直接拿走的东西，

但是，当我们把企业的数据交给大模型时，大模型真的“理解”了这些数据吗？这也是大家把注意力从传统 RAG，逐渐转向 GraphRAG 的原因。

但其实，GraphRAG 可能也只是一个中间阶段。真正值得讨论的问题，并不是“GraphRAG 能不能比 RAG 做得更好”，而是：我们究竟希望 AI 从企业知识中得到什么？

是找到一个答案，还是理解知识之间的关系？是理解关系，还是能够基于这些关系进行推理？再进一步，是推理之后能够参与决策，甚至执行动作？

一、为什么是 Graph？

图数据库（Graph Database）并非新生事物，其发展远早于大模型时代。在 AI 浪潮下，数据已成为企业的核心资产，图数据库的重要性也随之被重新审视。

背后的原因其实很简单：现实世界中的大量信息，本质上是关系型的，而非孤立存在的：

一个人认识另一个人；
一笔交易连接两个账户；
一台设备属于某个系统；
一个故障会影响上下游多个部件。

而图数据库，即为存储、计算、推理关系的最佳方式。

如果把这些对象看成顶点（Vertex），把对象之间的关系看成边（Edge），我们就得到了一张图（Graph）。

这种表达方式看起来简单，却改变了我们理解数据的方式。

关系型数据库更擅长记录“发生了什么”：某个人转了多少钱、某家公司有哪些订单、某台机器什么时候发生过告警。而图数据库更关注另一件事情：这些事情之间到底有什么关系？

比如，要回答两个人之间是否存在一条复杂的关系链，在关系型数据库中往往需要不断 JOIN, 随着关联层级增加，计算复杂度也会快速上升。图数据库则直接把关系作为数据的一部分保存下来。查询不再需要一次次重新计算关系，而是可以沿着已经存在的边去探索。

所以，图数据库真正擅长的，是对关系本身进行读取、探索和计算。这也是后来 GraphRAG 能够进入大模型领域的基础。

二、RAG 的问题，不只是不够准

如何让让大模型理解私有化数据？RAG 可能是性价比最高的方案。

把企业文档切成 Chunk，进行向量化，再根据用户问题找到语义上最相似的文本片段，把这些片段交给大模型生成答案。这套方法足够简单，也足够实用，所以直到今天仍然是企业落地大模型最常见的技术路线之一。

但当问题开始变复杂，RAG 的一些结构性问题也慢慢暴露出来。

例如，“保温杯”和“保温大棚”在某些语义空间里可能具有很高的相似度，但它们显然不是同一件事情。又比如，一份文档被切得太小，原本完整的知识可能被拆散；切得太大，又可能导致真正有用的信息被淹没。

更麻烦的是，文本本身的逻辑关系也可能随着切分而消失。一个章节可能引用另一个章节，一份报告可能和另一份报告存在上下文关系，一个事实可能必须结合另一个事实才能成立。但当这些内容被切成一个个独立的向量之后，这些关系并不会天然保留下来。

因此，RAG 很擅长回答：

“答案在哪？”

却不一定擅长回答：

“这些答案之间是什么关系？”

更不用说一些需要全局理解的问题：

“这个知识库整体上说明了什么？”

“过去几年这个行业发生了什么变化？” “A 和 B 没有直接关系，但为什么它们最终产生了相同的结果？”

这些问题，本质上已经不是简单的相似性检索，而是关联、推理和概括。

三、超越 RAG 的 GraphRAG

因此，NebulaGraph 率先提出了 GraphRAG 的方法, 并于 2023 年 8 月与 LlamaIndex 联合发布 GraphRAG. 大家熟知的微软研究院 2024 年发表的《From Local to Global: A GraphRAG Approach to Query-Focused Summarization》，里面也引用了我们所做 GraphRAG 工作。

GraphRAG 的意义，在于它改变了检索知识的基本方式。

传统 RAG 更关注相似性：这个问题和哪些文本最像？GraphRAG 则进一步关注相关性：这个问题涉及哪些实体？这些实体之间有什么关系？沿着这些关系还能找到什么？

因此，在 GraphRAG 中，文本不再只是被切成一个个独立的 Chunk，而是尝试从文本中抽取实体、关系以及上下文结构，将这些信息组织成图。用户提出问题之后，大模型不只是拿回几个最相似的文本片段，而可以沿着图上的节点和路径进行探索。

这带来了一个非常重要的变化：知识从文本片段变成了结构。一旦知识有了结构，很多原本困难的问题就有了新的解法。

比如，可以沿着关系寻找两个实体之间的路径；可以利用图算法进行社区划分，对知识进行聚合；也可以通过图上的结构去解释一个结论为什么成立。

所以，GraphRAG 并不是要取代传统 RAG。更准确地说，它是在传统 RAG 之外增加了一种能力：让大模型不仅能够找到知识，还能够沿着知识之间的关系去理解知识。

这也是为什么今天很多实际系统并不是简单地在 RAG 和 GraphRAG 之间二选一，而是尝试把二者结合起来。

四、 GraphRAG 并非终点

如果 GraphRAG 解决的是「关系问题」，那么接下来会出现一个更现实的问题：知识有了关系之后，怎么把它真正用起来？

这几年 GraphRAG 本身也在快速演进，实际上都在回答同一个问题：如何让知识更容易被获取、组织、加工和利用？

从这个角度看，GraphRAG 的演进其实存在两条非常清晰的线索。

第一条，是如何把数据变成知识？

企业的数据从来不只存在于数据库里。文档、PDF、表格、图片、音频、视频，以及各种业务系统中的结构化数据，都在不断产生知识。真正困难的不是有没有数据，而是这些数据有没有被组织成稳定的、具备业务语义的知识结构。

第二条，是知识拿到之后怎么使用？

把数据组织成知识结构只是第一步。更重要的是，如何把用户的问题映射到图上的检索路径。比如找到一个知识实体后，可以进一步定位对应章节，沿着关系找到它在其他文档中的关联内容，从而获得更完整的答案。即如何让问题进入知识结构，并沿着关系找到正确的知识。

于是，NebulaGraph 在 2025 年提出了 Fusion GraphRAG ，探索的正是这两大方向。

五、Fusion GraphRAG：把知识重新组织起来

如果把传统 RAG 理解为「找到文本」，把 GraphRAG 理解为「找到关系」，那么 Fusion GraphRAG 更关注的是：如何把不同形态的知识组织到一起，并针对不同问题选择合适的方式使用它们。

这意味着，系统不应该只有一种索引。一份企业知识可能同时具有文档目录、章节、Chunk、图片、图表、实体、关系等多个层次；结构化业务数据本身又可能已经是一张图；此外，还有向量索引、全文索引，以及与用户交互过程中不断产生的 Memory.

这些信息没有必要被强行压缩成同一种形式。相反，可以让它们各自保留自己的特点，再通过图把这些知识连接起来。

于是，查询也不再是简单的向量召回。一个问题可能需要查询已有图谱，也可能需要全文检索；可能需要向量召回某个具体段落，也可能需要沿着图关系做多跳探索；有些问题需要 Chunk，有些问题需要实体和边，有些问题则需要一个经过图算法聚合之后的摘要。

检索从最开始的单一路径，变成多路协同。

而图，在这里承担的角色也发生了变化。它不再只是一个额外的知识库，而逐渐成为连接不同知识形态的一种组织方式。

这也是为什么 Fusion GraphRAG 更像一种全链路的方法，而不是某一个单独的检索算法。从数据进入系统开始，到知识抽取、结构组织、索引建立，再到查询、召回、图计算和大模型生成，每一个环节都可以利用图的结构重新思考。

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

六、当图开始进入真实业务

技术路线最终还是要回到业务，分享三类经典应用场景。

（一）制造

在制造业场景里，一个实际问题可能不是“告诉我维修手册里关于某个设备的内容”这样的简单问题，而是：

这台设备为什么出现故障？应该按照什么顺序排查？当前这个故障会影响哪些上下游部件？

这类问题天然带有路径和上下游关系。

在一个船舶的生成式 AI 应用中，系统面对的是大量包含故障树和文字描述的非结构化文档。将这些内容组织成图之后，工程师的问题可以映射到具体的故障节点，再沿着上下游关系进行探索。进一步结合实时工业数据、告警数据和运维手册，系统开始从知识问答向实时工业决策辅助延伸。

（二）金融

反洗钱本身就是一个关系问题。一个可疑账户本身可能并不异常，但如果沿着交易关系继续向外扩展，就可能发现账户之间的团伙关系、异常资金链路以及其他关联主体。

因此，系统可以把团伙分析、资金链路分析、图指标、标签传播等图分析能力结合起来，再将分析结果与报告模板结合，自动生成可疑线索报告，最后交由专家修订。

这里，大模型承担的是理解和生成的一部分工作，而真正决定隐秘关系能不能被发现的，仍然是底层的数据结构和图计算。

（三）运维

一台机器可能没有任何明显故障，但它承担了过多关键服务。一旦宕机，影响的可能不是一个服务，而是一整条上下游链路。这时候，单点查询很难回答“它到底会影响什么”。

而图可以把机器、应用、服务、数据以及它们之间的依赖关系组织起来，再通过中心性、路径和血缘分析寻找潜在的单点风险。

所以很多时候，图真正提供的是一种从单点问题看到整个关系网络的能力。

七、甚至可以把“人”也变成图的一部分

还有一个很有意思的探索，是图模孪生和数字分身。

传统市场调研有一个非常现实的问题：大量访谈最终都会变成录音、文字和报告。项目结束之后，这些数据很难继续复用。下一次做类似项目，可能还是需要重新访谈。

如果把访谈内容中的人物、观点、偏好、经历以及他们之间的关系组织起来，那么过去的访谈就不再只是一次性的文本资料，而可以变成一个持续积累的知识网络。

在此基础上，可以针对某一个用户进行分析，也可以把具有相似特征的人聚合起来，形成群体画像。

数字分身真正有价值的地方在于让过去一次性的调研数据，开始具备了可复用、可分析、可迭代的能力。

新项目到来时，不一定要从零开始。过去积累的人群、观点和经验，可以再次被拿出来参与新的问题。

从这个意义上说，图让非结构化数据第一次真正开始沉淀。

八、超越超越的超越： Ontology

走到这里，其实还可以继续问一个问题。

GraphRAG 可以让 AI 找到知识。

Fusion GraphRAG 可以让 AI 更系统地组织、关联和利用知识。

那么，AI 能不能进一步基于这些知识做决策，甚至直接行动？

这可能就是今天为什么越来越多人开始讨论 Ontology. 如果说知识图谱解决的是“有什么、有什么关系”，那么本体更进一步定义了：这些对象在业务世界里到底意味着什么，它们之间允许发生什么，以及基于这些关系可以做什么。

例如，在企业数据里，一个表可能只是几行字段；但在业务语义层，它可能对应的是“客户”“订单”“资产”。对象之间不仅存在关系，还存在业务规则和约束。更进一步，业务动作也可以被绑定到这些对象上。

于是，AI 面对的就不再只是一个可以查询的知识库，而是一个能够被理解、被推理、甚至被操作的业务世界。

这也是 Palantir Ontology 所展示出的一个重要方向：本体作为企业的数据业务语义层，将对象、关系和动作组织在统一的语义框架中，让 AI 不需要直接面对底层数据库结构，而是面对业务世界本身。

从图技术的角度看，这件事情其实并没有那么神秘。

Entity 对应节点，Relation 对应边；业务上的关联探索，可以落到图查询；更复杂的认知与分析，则可以进一步利用图计算。

九、“超越”到底是什么？

“超越”到底是什么？回头看，是被问题推着走的：

存关系——关系型数据库查询、计算海量数据太慢，用图数据把数据以点、边形式存下来。

读数据——大模型不懂私有数据，用 RAG 做检索增强。

理解关系——向量无法深度理解数据关系，用 GraphRAG 把知识抽成图。

用好知识——图有了，还要多路索引、图计算、增量更新、融合结构化与非结构化数据，于是 Fusion GraphRAG 诞生了。

执行业务——企业真正需要的，是能理解业务对象、知道怎么行动的 AI。走到这步，AI 才从「回答问题」走向「执行业务」。

所以，所谓“超越 GraphRAG”，并不是说 GraphRAG 已经过时了。恰恰相反。GraphRAG 是这条路上非常重要的一步。

只是当我们把问题从如何让 AI 找到知识，不断追问到如何让 AI 理解知识、推理知识，并最终操作知识时，技术的边界也会不断向前移动。

从数据到知识，从知识到关系，从关系到推理，再从推理走向行动。这可能才是“超越”真正值得讨论的地方。

而图，或许只是这条路上最早被重新发现，也最值得应用的那一层基础设施。

感谢你看到这里～如果对 NebulaGraph 和 Fusion GraphRAG 感兴趣，可通过咨询问卷，获得 1v1 企业版支持。