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


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

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

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

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

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

# 一、为什么是 Graph？

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/1.webp)

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/2.webp)

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

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/3.webp)

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/4.webp)

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

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

因此，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 则进一步关注相关性：这个问题涉及哪些实体？这些实体之间有什么关系？沿着这些关系还能找到什么？

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/5.webp)

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/6.webp)

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/7.webp)

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

# 四、 GraphRAG 并非终点

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

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

**![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/8.webp)**

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/9.webp)

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

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

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

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/10.webp)

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

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/11.webp)

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/12.webp)

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

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

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

## （一）制造

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/13.webp)

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

## （二）金融

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

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

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

## （三）运维

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/14.webp)

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

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

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

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/15.webp)

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/16.webp)

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

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

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

# 八、超越超越的超越： Ontology

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

GraphRAG 可以让 AI 找到知识。

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/17.webp)

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

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

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

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

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/fusion-graphrag-introduction/18.webp)

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

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

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

> 1. 存关系——关系型数据库查询、计算海量数据太慢，用图数据把数据以点、边形式存下来。
> 2. 读数据——大模型不懂私有数据，用 RAG 做检索增强。
> 3. 理解关系——向量无法深度理解数据关系，用 GraphRAG 把知识抽成图。
> 4. 用好知识——图有了，还要多路索引、图计算、增量更新、融合结构化与非结构化数据，于是 Fusion GraphRAG 诞生了。
> 5. 执行业务——企业真正需要的，是能理解业务对象、知道怎么行动的 AI。走到这步，AI 才从「回答问题」走向「执行业务」。

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

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

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

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

> 感谢你看到这里～如果对 NebulaGraph 和 Fusion GraphRAG 感兴趣，可通过[咨询问卷](https://wj.qq.com/s2/15344088/w7ei/)，获得 1v1 企业版支持。



以“超越”作为一条递进主线：Graph→RAG→GraphRAG →Fusion GraphRAG→Ontology, 从这样的技术演变历程，与大家共同探讨：我们真正想让 AI 学会什么？我们到底需要怎样的 AI？

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

近年来，GraphRAG 已成为企业 AI 落地的重要技术方向。相比传统 RAG，GraphRAG 通过知识图谱组织实体与关系，为大模型提供更加完整的上下文和推理能力，在复杂问答、多跳推理、企业知识管理等场景展现出显著优势。

近日， LightRAG 合并了社区 PR #3536，正式新增 NebulaGraph 作为官方支持的图数据库存储后端。这意味着开发者可以直接使用 NebulaGraph 构建 LightRAG 的知识图谱存储与查询能力，为 GraphRAG 应用提供更高性能、更大规模的图数据支撑。

> 目前 NebulaGraph 开源版的最新版本为 v3.8.0，v5.x 为企业版，其核心特性之一是原生支持 GQL（Graph Query Language）国际标准。因此，本次集成主要面向部署了企业版 v5.0 的用户，帮助他们充分发挥 LightRAG 与企业版新特性结合的能力。

![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/lightgraph/light-pr.png)

# 为什么是 NebulaGraph？

LightRAG 的核心思想，是利用知识图谱增强传统向量检索，通过实体、关系以及图结构组织知识，实现局部（Low-Level）与全局（High-Level）双层检索，从而提升复杂问题的回答质量。

随着企业知识规模不断增长，GraphRAG 对底层图数据库提出了更高要求：

* 海量节点与关系的存储能力
* 高并发、多跳关联查询性能
* 在线增量更新能力
* 面向生产环境的分布式架构

NebulaGraph 正是为这些企业级场景而设计。作为分布式图数据库，NebulaGraph 能够支持超大规模关系数据管理，并在复杂图遍历、多跳查询和实时图计算场景中保持稳定性能，因此成为越来越多企业构建知识图谱和 GraphRAG 系统的重要基础设施。

# 为 LightRAG 提供企业级图能力

LightRAG 是一套强调“轻、快、可组合”的 GraphRAG 系统，通过引入知识图谱来增强大语言模型对复杂关联知识的检索与生成能力。

此前，LightRAG 已支持 Neo4j、Memgraph 等多种图数据库。此次集成，将 NebulaGraph 的强大数据处理能力与 LightRAG 的智能检索框架相结合，为处理千亿级节点和边的知识图谱 RAG 应用提供了坚实底座。

这对构建企业 AI 应用而言，这意味着开发者既可以依托 NebulaGraph 获得生产级图数据管理能力，也可以享受 LightRAG 在知识抽取与双层检索方面的能力。

# 特别致谢

**在此，我们特别感谢此次集成的代码贡献者 @xlshao2021**。正是 ta 敏锐地捕捉到了广大用户对 NebulaGraph 支持的真实需求，并投入时间和精力，从代码实现到测试，完整地完成了这一关键开发工作。

这一贡献不仅直接丰富了 LightRAG 的存储后端生态，也展现了一个优秀开源社区应有的活力——用户提出需求，贡献者付诸行动，核心维护者以建设性的方式响应。

我们期待 @xlshao2021 和所有对 `dev-nebula-graph `分支感兴趣的开发者，能继续维护和更新这一集成，共同推动它在更多企业级场景中落地生根。

---
如果你正在构建企业知识库、GraphRAG 或 AI Agent 应用，现在可以使用 NebulaGraph 作为 LightRAG 的图数据库后端，体验图原生架构带来的性能与扩展能力。

欢迎加入 NebulaGraph 社区，与更多开发者一起探索 GraphRAG、Ontology 与 Agent 的下一代企业 AI 架构。
``

 LightRAG 合并了社区 PR #3536，正式新增 NebulaGraph 作为官方支持的图数据库存储后端。

LightRAG 现已支持 NebulaGraph，推动 GraphRAG 生态发展

过去几月，我们围绕 Ontology（本体论）展开了一系列讨论：Ontology 如何为企业级 AI 建立统一的语义基础，以及 NebulaGraph 如何通过高性能图数据库，让这些语义真正进入业务系统并规模化运行。

从金融风控、推荐系统到供应链智能，不同场景背后都有一条共同的技术主线：**Ontology 负责定义业务世界中的实体、属性与关系，让数据具备明确的业务语义；图数据库则负责承载、连接和计算这些关系，让 Ontology 从静态的语义定义走向可查询、可计算、可推理的生产系统。**

随着 AI 模型能力不断提升，它们所依赖的数据基础也需要变得更加丰富、灵活，并能够被 AI 更高效地访问和使用。

这正是 NebulaGraph Enterprise v5.3 的核心升级方向。**围绕数据建模、AI 能力集成以及企业级性能与可靠性，NebulaGraph Enterprise v5.3 进一步打通了从 Ontology 建模到 AI 应用执行的完整链路，让企业能够更高效地构建、部署和扩展 Ontology 驱动的 AI 应用。**


![](https://vesoft-cdn.nebula-graph.com.cn/nebula-website-5.0/share/nebulagraph-v5.3.jpg)
NebulaGraph Enterprise v5.3 整体产品架构

# 更丰富的数据建模：承载 Ontology 之外的动态 AI 上下文

Ontology 通过定义实体类型、属性和关系，为 AI-ready Knowledge Graph 建立稳定的语义基础。但真实的 AI 应用并不只依赖固定的 Ontology. 随着 LLM、AI Agent 等应用不断演进，图中还需要承载大量动态、多值以及与具体上下文相关的信息。

NebulaGraph Enterprise v5.3 新增 SET 和 MAP 等数据类型，让企业既可以保持核心业务语义的一致性，又能够适应 LLM、AI Agent 等智能应用不断变化的数据需求。

## 1. SET：更自然地表达多值属性

SET 数据类型适合表示用户兴趣、商品标签、知识分类、风险标签等多值属性。

过去，这类信息可能需要被建模为独立的点或边。现在，对于大量由 AI 生成或动态更新的特征，可以直接将其作为属性存储在对应实体上。

例如，一个用户实体可以同时拥有多个兴趣标签，一个商品可以属于多个分类，一个账户也可以关联多个风险标签。这使企业能够在不显著增加图模型复杂度的情况下，为 Ontology 定义的实体补充更加丰富的语义上下文，并直接服务于推荐、检索和推理等 AI 任务。

## 2. MAP：灵活承载不断变化的上下文

MAP 数据类型通过灵活的键值结构，适合存储随应用持续变化的信息，例如 Prompt 元数据、Agent 状态、配置参数以及特定业务上下文。

AI 应用的数据结构往往处于持续变化之中。如果每增加一种上下文信息都需要修改 Schema，将显著增加系统维护成本。通过 MAP，AI 系统可以将动态信息直接关联到 Ontology 定义的实体上，而无需随着工作负载变化频繁调整 Schema.

# 更强的图智能能力

存储数据只是第一步。真正的价值在于如何让 AI 能够访问和利用这些数据，从复杂的关系网络中发现模式、生成洞察，并回答需要多跳关联分析的问题。

NebulaGraph Enterprise v5.3 进一步增强图算法、聚合计算和子图提取能力，让 NebulaGraph 从图数据存储与查询引擎进一步成为面向 AI 的图数据基础设施。

## 1. 内置图算法：从关系检索走向关系发现

* NebulaGraph Enterprise v5.3 大幅扩展了内置图算法能力：
* Centrality（中心性）
* Path Finding（路径查找）
* Community Detection（社区发现）
* Similarity（相似度计算）
* Node Embedding（节点嵌入）
* Topological Link Prediction（拓扑链接预测）

这些内置图算法意味着，AI 不再只能查询图中已经存在的事实，还能够进一步从关系结构中发现潜在模式。

例如，在金融风控场景中，可以通过社区发现识别潜在欺诈团伙；在推荐场景中，可以通过相似度计算发现新的用户群体和兴趣关联；在供应链场景中，可以结合链接预测识别潜在的供应链风险。

Ontology 提供语义框架，图算法则进一步释放关系网络中的结构智能。二者结合，让 AI 不仅能够理解“数据是什么”，还能够进一步发现“数据之间可能存在什么关系”。

## 2. Aggregation + SubGraph：构建 GraphRAG 的基础能力

NebulaGraph Enterprise v5.3 新增更完整的横向聚合函数以及 SubGraph 函数，为 GraphRAG 应用提供更加直接的图计算与图检索能力。

### 2.1 Aggregation：直接在图中构建多维特征

聚合函数支持直接在图查询过程中完成计数、求和、平均值、分布统计等计算。

这意味着 AI 应用无需频繁将图数据导出到外部分析平台，即可直接基于最新的关系数据构建统计指标和模型特征。减少数据搬运的同时，也能够保证 AI 获取的特征始终基于最新的数据状态。

### 2.2 SubGraph：为 LLM 提取真正相关的局部知识网络

SubGraph 函数支持围绕目标实体快速提取局部知识网络。

当 LLM 需要回答一个与特定实体相关的问题时，系统可以根据当前任务提取目标实体、相关邻居以及关键关系，而不是将大量无关图数据全部交给模型。这能够减少检索干扰，让 LLM 将注意力集中在与当前问题真正相关的关系网络上，从而提升 GraphRAG 的检索质量和结果可解释性。

Aggregation 与 SubGraph 结合，使 AI 能够一方面基于图数据构建多维统计特征，另一方面获取更加精准的局部知识上下文，为 GraphRAG、Agent 推理和复杂关系分析提供更直接的数据基础。

# 更快、更稳定、更可控的企业级 AI 基础设施

生产级 AI 应用不仅需要更强的数据和计算能力，也对性能、可靠性和成本提出了更高要求，因此，NebulaGraph Enterprise v5.3 围绕查询执行、高可用、多租户和资源管理进行了系统性增强。

## 1. 全面性能优化：图计算平均提升 2.2 倍

NebulaGraph Enterprise v5.3 引入多项性能优化，包括：

* 动态查询计划选择
* 查询解释器优化
* Late Materialization（延迟物化）
* Vertex-Centric Index（点中心索引）

综合优化后，**图计算性能平均提升 2.2 倍，图查询性能平均提升 1.87 倍。**

更快的图遍历意味着更低的实时 AI 应用响应延迟、更高效的模型特征提取，以及更快的 GraphRAG 检索。当 AI Agent 需要执行复杂的多跳关系查询时，底层图查询与计算性能将直接决定 Agent 的响应速度。v5.3 的性能提升，为更加实时、交互式的 AI 应用提供了更强的基础支撑。

## 2. 高可用 + 多租户：面向生产环境的 AI 基础设施

NebulaGraph Enterprise v5.3 支持更加完整的高可用部署架构，包括：

* 同城主备容灾
* 同城双活
* 两地三中心
* 三地五中心

集群间支持近实时同步，为关键业务提供更高等级的数据可靠性和业务连续性保障。与此同时，v5.3 进一步完善多租户与 Quota 管理能力，使企业能够针对不同 AI Agent、团队和应用进行资源隔离与配额控制。

在大型企业环境中，多个 AI Agent 和业务应用可能同时访问同一个图数据基础设施。多租户和资源配额机制可以避免单一工作负载过度占用资源，降低不同应用之间的相互影响。这意味着 NebulaGraph 可以作为统一的图数据底座，在保障 AI 服务持续可用的同时，对不同业务负载进行更加精细的资源治理。

## 3. 动态副本调整 + Dry Run：从 PoC 到生产更加平滑

### 3.1 动态副本调整

NebulaGraph Enterprise v5.3 支持在线动态调整副本数量，无需中断服务。

在 AI 项目的早期开发、测试或 PoC 阶段，业务对高可用的要求通常较低，可以采用单副本部署以降低基础设施成本。随着应用逐步进入生产环境，对可靠性和容错能力的要求提高，企业可以在线增加副本数量，而无需停止服务。这种能力让 AI 项目能够根据生命周期灵活调整基础设施配置，从成本更低的开发环境平滑演进到高可用的生产部署。

### 3.2 新增 Dry Run 模式

Dry Run 可以在不实际执行查询的情况下，对查询语法、执行计划以及潜在的数据影响范围进行验证。

随着 AI Agent 开始通过 GQL Skills 等方式自动生成图查询，查询语法错误、不合理的执行计划以及潜在的资源消耗都可能成为生产环境中的新风险。通过 Dry Run，开发者和 AI Agent 可以在真正执行查询之前发现这些问题，从而减少调试成本，降低意外资源消耗的风险，并提升 AI 应用从开发到生产的整体效率。

# 从 Ontology 到 AI，打通语义与执行的完整链路

NebulaGraph Enterprise v5.3 打通了语义与执行的完整链路，让 Ontology 赋能 AI：

* **更丰富的数据建模。** SET 和 MAP 数据类型支持多值属性与动态上下文，让稳定的 Ontology 能够更好地承载持续变化的 AI 数据。
* **更强的图智能能力。** 内置图算法、Aggregation 和 SubGraph，让 AI 能够直接利用图中的结构信息，提升分析、检索与推理结果的完整性和可解释性。
* **更快、更可靠、更可控的基础设施。** 图计算性能平均提升 2.2 倍、图查询性能平均提升 1.87 倍，并通过企业级高可用、多租户、动态副本调整和 Dry Run，为生产级 AI 应用提供性能、稳定性与成本控制能力。

无论是构建金融风控系统、推荐引擎、供应链智能平台，还是新一代 AI Agent，NebulaGraph Enterprise v5.3 都在进一步缩短从语义建模、图数据管理到 AI 执行之间的距离。

**在 Ontology 驱动的 AI 时代，NebulaGraph 让语义真正可计算，让关系真正成为智能。**



NebulaGraph Enterprise v5.3 进一步打通了从 Ontology 建模到 AI 应用执行的完整链路，让企业能够更高效地构建、部署和扩展 Ontology 驱动的 AI 应用。

NebulaGraph Enterprise v5.3 ：面向 Ontology 驱动的 AI 时代，释放图原生智能

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/tip.png)

你有没有过这样的经历？刚下载一个社交 App，它就给你推荐了多年未见的老同学，或是隔壁部门可能有过一面之缘的同事。你心里不禁犯嘀咕：“它怎么知道的？”

其实，这背后很可能是**图数据库**在默默工作。它把整个社交平台制造成一张巨大的**关系网**，通过分析这张网里错综复杂的连接，来做出更懂你的推荐。

今天，NebulaGraph 就通过一个简单的 Demo，带你一窥这位“关系大师”是怎么工作的。

> Demo 链接
> https://www.nebula-graph.com.cn/demo
> 欢迎在 NebulaGraph 官网体验多场景 Demo，亲自动手验证图数据库的能力～

## 一、图模型设计

> 💡在实际使用中，可对 Schema 进行相应修改与管理，为便于在线体验，本 Demo 暂不支持。
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/1.png)

在正式推理开始前，我们得先知道上文提到的关系网是怎么搭起来的。

你可以把这张网想象成三个简单的部分：

* **人（节点）**：代表每个用户。
* **关系（边）**：“好友”、“关注”、“点赞”、“评论”这些让每个用户之间，产生关系的互动行为。
* **内容/社群/Tag（节点）**：比如一篇“旅游攻略”，或者一个“篮球爱好者群”。

> 💡在真实的业务里， 社群通常可以作为用户的一个属性来存储。但在我们这个演示里，特意将其单独建模成了一个节点。这是为了让你更直观地看清“用户 – 社群 – 内容”这条完整链条，感受图数据库在多跳关系查询上的优势。实际生产环境里，完全可以根据业务需求灵活调整模型。

图数据库要做的，就是把它们之间千丝万缕的联系，全部存进去，并且让这些关系可以被随时查询和分析。

节点类型包括下表：

| 节点类型 | 标签 | 核心属性 |
| :--- | :--- | :--- |
| 用户（自然人） | `Person` | `person_id` (唯一标识), `name` (昵称/姓名), `city` (所在城市), `register_time` (注册时间) |
| 社区/圈子 | `Community` | `community_id` (唯一标识), `name` (社区名称), `topic` (主题分类), `created_time` (创建时间) |
| 内容/帖子 | `Content` | `content_id` (唯一标识), `title` (标题), `category` (内容分类), `publish_time` (发布时间) |
| 用户兴趣标签 | `UserTag` | `tag_name` (标签名，如“AI”、“旅行”) |

边类型包括下表：

| 边类型 | 起始节点 → 目标节点 | 说明 |
| :--- | :--- | :--- |
| `Friend` | `Person` → `Person` | 好友关系（双向社交） |
| `FollowKOL` | `Person` → `Person` | 关注 KOL/大V（单向社交） |
| `MemberOf` | `Person` → `Community` | 加入社区/群组 |
| `Forward` | `Person` → `Content` | 转发/分享内容 |
| `Like` | `Person` → `Content` | 点赞/喜欢内容 |
| `Comment` | `Person` → `Content` | 评论内容 |
| `HasInterest` | `Person` → `UserTag` | 用户兴趣标签 |
| `Cites` | `Content` → `Content` | 内容引用/关联 |

了解完图数据库要做什么后，我们首先要在图数据库中，把基本规则创建起来。

首先，创建图类型与图空间，并执行以下语句定义节点、边结构及属性：


```
CREATE GRAPH TYPE IF NOT EXISTS `social_recommendation` AS {
NODE TYPE `Person` (LABEL `Person`{`person_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `city` STRING DEFAULT NULL, `register_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`person_id`)}),
NODE TYPE `Community` (LABEL `Community`{`community_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `topic` STRING DEFAULT NULL, `created_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`community_id`)}),
NODE TYPE `Content` (LABEL `Content`{`content_id` STRING NOT NULL, `title` STRING DEFAULT NULL, `category` STRING DEFAULT NULL, `publish_time` ZONED DATETIME DEFAULT NULL, PRIMARY KEY (`content_id`)}),
NODE TYPE `UserTag` (LABEL `UserTag`{`tag_name` STRING NOT NULL, PRIMARY KEY (`tag_name`)}),
EDGE TYPE `Friend` (`Person`)-[LABEL `Friend`{`since_time` ZONED DATETIME NOT NULL, `closeness` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`since_time`)}]->(`Person`),
EDGE TYPE `MemberOf` (`Person`)-[LABEL `MemberOf`{`join_time` ZONED DATETIME NOT NULL, `role_name` STRING DEFAULT NULL, MULTIEDGE KEY(`join_time`)}]->(`Community`),
EDGE TYPE `Forward` (`Person`)-[LABEL `Forward`{`forward_time` ZONED DATETIME NOT NULL, `action_weight` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`forward_time`)}]->(`Content`),
EDGE TYPE `Like` (`Person`)-[LABEL `Like`{`like_time` ZONED DATETIME NOT NULL, `score` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`like_time`)}]->(`Content`),
EDGE TYPE `Comment` (`Person`)-[LABEL `Comment`{`comment_time` ZONED DATETIME NOT NULL, `content_text` STRING DEFAULT NULL, MULTIEDGE KEY(`comment_time`)}]->(`Content`),
EDGE TYPE `FollowKOL` (`Person`)-[LABEL `FollowKOL`{`follow_time` ZONED DATETIME NOT NULL, `interaction_level` DOUBLE DEFAULT NULL, MULTIEDGE KEY(`follow_time`)}]->(`Person`),
EDGE TYPE `HasInterest` (`Person`)-[LABEL `HasInterest`{`weight` DOUBLE DEFAULT NULL}]->(`UserTag`),
EDGE TYPE `Cites` (`Content`)-[LABEL `Cites`{`cite_time` ZONED DATETIME DEFAULT NULL}]->(`Content`)
};
CREATE GRAPH `social_recommendation` :: `social_recommendation`;
```

## 二、数据导入

> 💡本 Demo 仅预置 30 名用户及数千条社交关系，实际导入时，数据量可达千亿级甚至更多。

定义完“规则”，我们执行以下语句，导入数据。


```
-- 导入用户节点
TABLE `person_data` { `person_id`, `name`, `city`, `register_time` } =
("p001", "Alice", "Beijing", "2024-01-05T09:00:00 +0800"), ("p002", "Bob", "Beijing", "2024-01-06T10:30:00 +0800"), ("p003", "Charlie", "Beijing", "2024-01-07T11:00:00 +0800"), ("p004", "David", "Beijing", "2024-01-08T14:20:00 +0800"), ("p005", "Evan", "Beijing", "2024-01-09T15:00:00 +0800"), ("p006", "Fiona", "Beijing", "2024-01-10T16:45:00 +0800"), ("p007", "George", "Beijing", "2024-01-11T09:15:00 +0800"), ("p008", "Hannah", "Beijing", "2024-01-12T10:30:00 +0800"), ("p009", "Ivan", "Beijing", "2024-01-13T11:45:00 +0800"), ("p010", "Julia", "Beijing", "2024-01-14T13:00:00 +0800"),
("p011", "Kevin", "Shanghai", "2024-01-15T09:00:00 +0800"), ("p012", "Linda", "Shanghai", "2024-01-16T10:30:00 +0800"), ("p013", "Mike", "Shanghai", "2024-01-17T11:00:00 +0800"), ("p014", "Nancy", "Shanghai", "2024-01-18T14:20:00 +0800"), ("p015", "Oscar", "Shanghai", "2024-01-19T15:00:00 +0800"), ("p016", "Paula", "Shanghai", "2024-01-20T16:45:00 +0800"), ("p017", "Quinn", "Shanghai", "2024-01-21T09:15:00 +0800"), ("p018", "Rachel", "Shanghai", "2024-01-22T10:30:00 +0800"), ("p019", "Steve", "Shanghai", "2024-01-23T11:45:00 +0800"), ("p020", "Tina", "Shanghai", "2024-01-24T13:00:00 +0800"),
("p021", "Uma", "Hangzhou", "2024-01-25T09:00:00 +0800"), ("p022", "Victor", "Hangzhou", "2024-01-26T10:30:00 +0800"), ("p023", "Wendy", "Hangzhou", "2024-01-27T11:00:00 +0800"), ("p024", "Xavier", "Hangzhou", "2024-01-28T14:20:00 +0800"), ("p025", "Yvonne", "Hangzhou", "2024-01-29T15:00:00 +0800"), ("p026", "Zack", "Hangzhou", "2024-01-30T16:45:00 +0800"), ("p027", "Amy", "Hangzhou", "2024-01-31T09:15:00 +0800"), ("p028", "Brian", "Hangzhou", "2024-02-01T10:30:00 +0800"), ("p029", "Cathy", "Hangzhou", "2024-02-02T11:45:00 +0800"), ("p030", "Derek", "Hangzhou", "2024-02-03T13:00:00 +0800")
USE `social_recommendation`
FOR re IN `person_data`
INSERT (@`Person` {`person_id`: re.`person_id`, `name`: re.`name`, `city`: re.`city`, `register_time`: CAST(re.`register_time` AS ZONED DATETIME)})
-- 导入社群节点
TABLE `community_data` { `community_id`, `name`, `topic`, `created_time` } =
("c001", "AI与大模型研究", "Technology", "2023-12-01T08:00:00 +0800"), ("c002", "电商运营交流", "Business", "2023-12-05T09:00:00 +0800"), ("c003", "硬核数码科技", "Hardware", "2023-12-10T10:00:00 +0800"), ("c004", "城市慢生活", "Lifestyle", "2023-12-15T11:00:00 +0800")
USE `social_recommendation`
FOR re IN `community_data`
INSERT (@`Community` {`community_id`: re.`community_id`, `name`: re.`name`, `topic`: re.`topic`, `created_time`: CAST(re.`created_time` AS ZONED DATETIME)})
-- 导入内容节点
TABLE `content_data` { `content_id`, `title`, `category`, `publish_time` } =
("ct001", "图数据库在AI时代的机遇", "Tech", "2024-03-01T08:00:00 +0800"), ("ct002", "2024电商新风向标", "Business", "2024-03-02T09:00:00 +0800"), ("ct003", "深度解析PageRank算法", "Tech", "2024-03-03T10:00:00 +0800"), ("ct004", "我的极简桌面搭配", "Life", "2024-03-04T11:00:00 +0800"), ("ct005", "机械键盘轴体科普", "Hardware", "2024-03-05T12:00:00 +0800"),
("ct006", "LLM微调实战指南", "Tech", "2024-03-06T13:00:00 +0800"), ("ct007", "直播带货的底层逻辑", "Business", "2024-03-07T14:00:00 +0800"), ("ct008", "周末探店：魔都咖啡", "Life", "2024-03-08T15:00:00 +0800"), ("ct009", "显卡选购避坑指南", "Hardware", "2024-03-09T16:00:00 +0800"), ("ct010", "如何高效管理时间", "Life", "2024-03-10T17:00:00 +0800")
USE `social_recommendation`
FOR re IN `content_data`
INSERT (@`Content` {`content_id`: re.`content_id`, `title`: re.`title`, `category`: re.`category`, `publish_time`: CAST(re.`publish_time` AS ZONED DATETIME)})
```

数据导入完成后，社交数据在图数据库里就变成了这样一张图（Graph）。
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/2.png)

## 三、关键查询示例

在 NebulaGraph Demo 的 console 界面中，输入图数据库查询语句，点击 run 按钮，系统就会执行一段查询指令，并把结果以**可视化关系图**的形式呈现出来。

比如每个用户是一个小圆点，关系是连接圆点的线条。你可以拖拽、缩放这张图，直观地看到人与人之间的连接路径，让推荐结果看得见、摸得着。

在这里，我们用四类查询语句和对应的可视化页面，进一步让你了解图数据库是如何让社交软件，精准推荐「你可能认识的人」。

> 💡在 Demo 中，已经完成了 schema 设计和数据导入，大家可以在 console 页面，任意探索社交场景的不同语句、玩法。

### 1. 查找某人的 1-3 度好友

**目的：**全面掌握目标用户的社交网络范围，发现潜在的兴趣传播路径和社群影响力范围。


```
USE `social_recommendation`
MATCH p=(src@`Person` {`person_id`: "p001"})-[:`Friend`]-{1,3}(friend)
RETURN p
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/3.png)

**基于图的解释**：该图展示了从用户 p001 出发，经过 1 到 3 跳好友关系能到达的所有用户节点及路径。

### 2. 熟人好友推荐

**目的**：基于“朋友的朋友是朋友”的社交理论，通过共同好友数量为用户推荐可能认识的人。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p001"})-[:`Friend`]-(mutual_friend)-[:`Friend`]-(candidate)
WHERE candidate.`person_id` <> "p001" // 排除自己
AND NOT EXISTS((src)-[:`Friend`]-(candidate)) // 排除已经是好友的人
RETURN candidate.`person_id` AS recommended_friend,
candidate.`name` AS name,
count(mutual_friend) AS mutual_friends_count
ORDER BY mutual_friends_count DESC
LIMIT 10
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/4.png)

**基于表格的解释**：为用户 p001 推荐共同好友最多的前 10 位潜在朋友。`mutual_friends_count `越高，推荐的理由越充分，用户接受推荐的概率越大。

### 3. 兴趣社群推荐 (基于朋友圈子)

**目的**：通过分析用户好友的社群加入行为，推测用户可能也感兴趣的社群，实现社群推荐。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p001"})-[:`Friend`]-(friend)-[:`MemberOf`]-(community)
WHERE NOT EXISTS((src)-[:`MemberOf`]-(community))
RETURN community.`name` AS community_name,
community.`topic` AS topic,
count(friend) AS friends_joined_count
ORDER BY friends_joined_count DESC
LIMIT 5
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/5.png)

**基于表格的解释**：为用户 p001 推荐其好友们最常加入的 5 个社群。`friends_joined_count `越高，说明该社群在当前用户的社交圈子中越流行，推荐价值越高。

### 4. 基于相似行为的内容推荐

**目的**：找到与目标用户有相同转发行为的相似用户，然后将这些相似用户点赞过的其他内容推荐给目标用户，实现协同过滤推荐。


```
USE `social_recommendation`
MATCH (src@`Person` {`person_id`: "p002"})-[:`Forward`]->(common_content)<-[:`Forward`]-(similar_user)-[:`Like`]->(recommended_content)
WHERE NOT EXISTS((src)-[:`Like`]->(recommended_content))
AND NOT EXISTS((src)-[:`Forward`]->(recommended_content))
RETURN recommended_content.`title` AS content_title,
similar_user.`name` AS liked_by_user,
count(common_content) AS similarity_score
ORDER BY similarity_score DESC
LIMIT 10
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/demo-social-recommendation/6.png)

**基于表格的解释**：为用户 p002 推荐由与其转发行为最相似的 10 位用户所喜欢的内容。`similarity_score `代表推荐内容与用户兴趣的相似度权重，`liked_by_user `字段提供了推荐理由。

## 四、总结

综上所述，图数据库的核心理念其实并不复杂，其实就是将“人与人”、“人与内容”之间的关系作为一等公民进行存储与计算。然而，正是这一思路的转变，为推荐系统带来了质的变化。

回顾前文所述的所有查询示例，可以清晰地看到，借助 NebulaGraph 构建的社交兴趣关联网络，推荐系统在以下四个维度上实现了显著提升：

**1. 发现多层社交路径**：突破传统推荐系统局限于个体历史行为的视野，图数据库可沿好友、关注等链路穿透至三度、四度关系，挖掘深层社交联系与影响力传导路径。

**2. 提供可量化指标**：基于共同好友数、相似行为频次等结构化数据，为每条推荐提供可量化的信任度依据，如“你们有8位共同好友”，让推荐结果有据可循。

**3. 统一查询模式**：熟人推荐、社群推荐、协同过滤等多样化策略，均可通过图数据库的统一查询语言实现，无需为每种逻辑单独搭建技术栈，显著降低开发复杂度。

**4. 天然路径回溯**：图数据库可清晰展示推荐结果的完整产生链路（如“A的好友B点赞了C，故推荐C给A”），为策略优化与用户沟通提供透明化支撑。

总而言之，图数据库以一种更贴近人类认知直觉的方式，将世界视作一张相互连接的网络，正是这一视角的转换，使社交推荐从“猜你喜欢”进化为“基于关系的精准匹配”。如果您的产品正面临社交推荐的效率瓶颈，不妨从绘制一张关系图谱开始探索新的可能。

> 💡本 Demo 展示了基础查询，仅作为简单场景下的 NebulaGraph 使用参考。在实际生产环境中，还可结合 PageRank、标签传播、连通分量等图算法，实现更智能的社区发现与兴趣扩散。

✦

如果你觉得 NebulaGraph 能帮到你，或者你只是单纯支持开源精神，可以在 GitHub 上为 NebulaGraph 点个 Star！

每一个 Star 都是对我们的支持和鼓励✨

**GitHub：https://github.com/vesoft-inc/nebula**

官网：https://www.nebula-graph.com.cn/

论坛：https://discuss.nebula-graph.com.cn/

✦

图数据库在社交推荐的应用教程

Demo｜图数据库如何让社交软件精准推荐「你可能认识的人」？

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

在过去的十年里，图数据库（Graph Database）经历了从理论探索到工业级爆发的数轮技术浪潮。

2012 年谷歌知识图谱（Knowledge Graph）掀起了关系资产化的序幕；2018 年前后，金融风控与反欺诈将多跳关联分析推向工业刚需；而到了 2025 年，随着 LLM、AI Agent 的大爆发，图数据库市场迎来了新一轮增长高峰。

与图数据库关联的关键词变成了：GraphRAG、本体论（Ontology）、Agent Memory，很多人认为这又是 AI 圈催生出的概念泡沫，但本质上，AI 只是撕开了数字世界的表象，让整个行业深刻意识到：**现实世界是什么样，数据就该是什么样。而图数据库，正是最接近现实世界组织方式的数据系统。**

#  一、看得懂世界：图数据库的直觉建模

要理解图数据库的价值，需要先看看传统数据库在面对现实世界时，遇到了怎样的认知鸿沟。

## （一）表格里的现实：被强行拆解的关系

在传统的关系型数据库中，现实世界被强行平铺进一张张二维表格里。数据之间的关系，被隐式地埋藏在外键和复杂的索引中。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/1.jpg)

（关系型数据库中，维护客户关系数据，往往会创建三张表，分别代表三个不同的角色）

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/2.jpg)

（再使用外键或者维护一张关系表来做关系的对应）

当业务需要查询多层关联时，例如：探寻账户 A 是否通过多层中间人向风险账户 X 转账，系统必须执行多次极其高昂的 `JOIN` 操作。

这就像在好几个巨大的档案柜里来回翻找关联索引，随着关联层级（跳数）的加深，计算量呈几何级数爆炸，传统数据库的性能会迅速崩溃。

## （二）图的直觉建模：像人类一样理解世界

图数据库采取了完全不同的思维方式：**系统不需要在查询时临时拼接世界，而是在数据写入的那一刻，就把世界构造成网络。**

图数据库用最符合人类直觉的方式，将世界抽象为两个核心元素：

* **节点（Vertex）**：代表现实中的实体（如一个用户、一部手机、一个 IP、一家公司）。
* **边（Edge）** ：代表实体间的关系（如持有、登录、转账、持股）。

在这种架构下，关系的查询变成了顺藤摸瓜，你想看一个人背后连接着怎样的设备、交易和风险社区，系统只需顺着「边」一路走下去。

如在 Web3 风控中，查询用户链上转出后的直接关联用户。GQL（国际标准图查询语言）如下：


```
USE `web3_risk_graph`
MATCH path=(u@`user`{`user_id`:"450055199805200521"})-[@`user_crypto_address`]->(src@`crypto_address`)-[@`transfer`]->(dst@`crypto_address`)<-[@`user_crypto_address`]-(peer@`user`)
RETURN path
```

对应的可视化页面如下：

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/3.jpg)

通过可视化界面，可以直观看到从用户 `450055199805200521` 出发的完整资金流转路径：该用户持有的加密地址向另一个地址发起转账，而该接收地址又被其他用户所持有，从而形成了用户之间的间接资金关联。

总结而言，传统数据库优化的是数据本身的存储与检索，而图数据库优化的是认知方式。它让机器第一次具备了接近人类的直觉能力——快速看懂事物之间的来龙去脉。

# 二、装得下数据、跑得赢变局： 千亿点万亿边的毫秒级解决方案

真实世界的关系网络呈指数级膨胀。 全球金融交易网络、跨境供应链、企业级知识库，这些场景对应的往往是千亿级节点和万亿级边的海量数据。

**如何做到装得下整个世界的同时，还能快得赢瞬息万变**？这正是原生分布式图数据库的硬核价值所在。

以国内排名第一的图数据库代表 **NebulaGraph** 为例，通过云原生分布式架构，实现了在海量数据下的高并发与毫秒级响应：

* **存算分离，装得下数据**：计算层负责解析和优化查询；存储层专为图结构设计，负责点边数据的分布式存储。这种架构允许两边独立扩展，系统能够海纳百川地吞吐万亿级的点边数据。
* **多模态融合，查得全数据：在 NebulaGraph AI 应用平台中，将向量索引、图索引、全文索引、融合图索引相结合，根据查询要求，自动选择最快的查询方式与路径，可在一个系统里同时处理 PDF、图片、Excel、PPT 等多模态数据的文档结构、实体关系、语义相似性。
* **动态演进，跑得赢变局**：NebulaGraph 支持灵活的 Schema 动态演进，无需迁移即可秒级扩展新的实体类型、关系边以及属性。这种设计天然适配本体（Ontology）的持续演化，满足语义网中的开放世界假设（Open World Assumption, OWA）——即系统承认知识是不完整的、动态新增的，AI 可以在不中断生产业务的前提下，随时将新发现的商业网络或知识关联插入图中。**

# 三、2026 年图数据库场景全景

## （一）经典通用场景

在 AI 爆发之前，图数据库就已经是解决大规模、高并发复杂关联问题的绝对刚需。几乎所有涉及复杂系统的行业，最终其业务都会演化为一张图。

**1. Web3 风控**

**将区块链地址、智能合约等建模为节点，资金转移或合约调用建模为边，构建完整的链上交易图谱。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/4.jpg)

BlockSec 基于 NebulaGraph 构建了加密风控系统，通过给地址打标签，结合启发式算法量化风险。当检测到与制裁地址或黑客地址存在资金往来时，系统可在毫秒级内完成多跳路径追溯，即使资金经过混币器或多层跨链转移，也能还原完整的资金流转脉络。

**2. 互联网金融反欺诈**

在互联网金融信贷业务中，欺诈行为往往呈现团伙化、隐蔽化的特点。传统的基于规则或单一维度的风控系统难以发现隐藏在复杂关联中的风险。图数据库能够将用户、设备、证件、账户等实体以及它们之间的绑定关系构建为一张关联网络，并通过图算法和关联分析挖掘潜在欺诈团伙、识别风险传导路径。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/5.jpg)


EasyCash 使用 NebulaGraph 企业版后，实现欺诈拦截率提升 240%，审核压力下降 70% 的业务收益。

**3. 电商实时推荐引擎**

**将用户、商品、属性等实体作为异构图中的节点，购买、浏览、收藏等行为作为边，通过多跳路径查询找出与当前用户行为模式相似的其他用户所关联的商品。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/6.jpg)

阿里妈妈基于 NebulaGraph 构建了百亿级实时营销推荐系统，在同款异常点检测场景中，通过 1 跳和 2 跳子图查询提取商品邻接信息，将离群点检测的 AB 实验效果提升了 2 个百分点。

## （二）AI 时代催生的四大关键场景

图数据库凭借看得懂世界、装得下数据、跑得赢变局的核心优势，在 AI 时代不仅没有淡出，反而因为与大模型的深度互补，成为了企业构建 AI 基础设施的刚需。

### 1. GraphRAG：知识图谱与检索增强的融合

GraphRAG 是前两年图数据库最受关注的应用方向之一。

传统的 Vector RAG（向量检索增强生成）仅仅依赖文本片段的向量相似度匹配，切碎的文本块丢失了实体间的逻辑网络。在面临“请分析 A 公司的主要竞争对手在过去三年的供应链风险变化”这类需要跨文档、多实体联合推理的复杂长文本问题时，传统 RAG 极易给出拼凑的、似是而非的幻觉答案。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/7.jpg)

**NebulaGraph 率先提出的 GraphRAG（图检索增强生成）** 实现了结构化知识图谱与非结构化向量的完美融合：

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/8.jpg)

* **提取期**：利用大模型异步从海量企业文档中提取出实体、关系及属性，写入图数据库，沉淀为高质量的企业知识图谱。
* **检索期**：采用混合检索（Hybrid Search）。首先通过向量召回相关上下文，再沿图数据库的拓扑结构进行多跳关系拓扑扩散，将完整的知识网络、上下游实体链作为精确的 Prompt 上下文喂给大模型。

### 2. Fusion GraphRAG：给大模型装上智能导航

面对多模态数据时代的新变化，NebulaGraph 在知识图谱之上，创新地增加了一层 **Fusion Graph Index（融合图索引）**，将非结构化文档解析为层次化目录树结构，实现了文档物理结构与网状实体关系的深度统一：

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/9.jpg)

* **构建期**：利用大模型将复杂的非结构化多模态文档（PDF、Excel、PPT 等）直接解析为层次化的目录树网络，并与底层图数据库的实体关系无缝交织。
* **推理期**：采用动态结构推理。这层树状网络作为上下文内索引直接置于大模型的推理视野中，大模型得以像人类专家一样，根据用户意图智能导航，动态决定用何种检索方式、沿哪条章节脉络进行深度检索，彻底摆脱幻觉式召回。

### 3. Ontology：AI 理解业务世界的语义骨架

大模型虽然具备强大的通用理解力，但在面对特定企业复杂的内部运行机制（如：复杂的组织架构、交叉持股、特定工业设备的级联故障定义）时，依然缺乏常识。

Palantir 让 Ontology 从哲学概念走入 AI 工程。它通过对企业中对象–关系–行为的抽象建模，让数据与业务之间建立可操作、可推理的连接。基于本体的 Agent 模型能根据领域本体精准生成应用，而不是按照简单 prompt 做通用回应。有了 Ontology 这个骨架，基于本体的 Agent 模型就能精准、合规地生成特定领域的应用代码或业务决策。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/guide-for-graph-database-2026/10.jpg)
### 4. AI Agent 与长期记忆系统

2025 年是 AI Agent 走向全面工程化的分水岭。大模型在架构上天然缺乏长期记忆能力，频繁重传历史信息不仅推高了 Token 损耗，且无法沉淀出真正的可演进型智能体。

图结构是人类记忆网络的最佳数字孪生。通过图数据库构建 Agent 记忆系统，不仅能记录离散的事件（节点），更能编码时间戳、语义含义以及事件之间的因果与逻辑连接（边）。如 PolarDB PostgreSQL 版在探索 AI 长期记忆的方案中，就采用了向量数据库+图数据库的架构设计，以适配长期个性化服务的场景，如企业知识库、金融风控动态规则库等。

# 四、图数据选型之不完全指南

全球图数据库市场正在经历一轮爆发式的增长，2025 年全球图数据库市场规模为 28.5 亿美元，预计未来将从 2026 年的 36 亿美元增长到 2034 年的 202.9 亿美元，根据 ZDNet 及 Gartner 的联合报告，图数据库已成为整个数据库市场中增长最快的细分领域。

在 2026 年的工业语境下，企业想选型一款优秀的图数据库，建议深度参考以下指标：

## 1. 规模上限

是否具备原生分布式扩展能力？随着业务演进，图数据会呈指数级膨胀。选型时不能仅看 Demo 阶段的性能，必须考核系统在千亿节点、万亿条边的超大规模下，能否通过存算分离架构进行横向弹性扩展。

 ## 2. 检索维度

是否支持“图+向量+全文+融合图”的多维检索方式？ 2026年的前沿智能化应用（如 Fusion GraphRAG、Agent 长期记忆），涵盖多模态数据，优秀的图数据库必须在一个系统中实现多模态智能检索，且具备动态推理能力。

## 3. 时效演进

是否支持动态 Schema？AI 时代的企业本体（Ontology）和业务场景日新月异，选型必须考察系统是否支持 Schema 的灵活动态演进。当需要新增一种实体类型或关系边时，系统必须做到秒级扩展，无需锁表，更无需进行痛苦的数据迁移。

## 4. 智能化图算法

是否具备可自定义图算法、支持 Text2GQL 的能力？当关系规模进入万亿时代，智能化、业务化的计算才是核心问题。需在算得快的基础上，进一步考察是否支持自定义图算法、能否实现输入自然语言自动转换为可运行的图算法。只有将业务人员从提交需求中解放出来，直接聚焦业务逻辑，才能大幅缩短开发周期，让业务真正贴近真实场景。

# 五、 热点会变，但现实的关系不会消失

从知识图谱、GraphRAG、本体论、AI Agent 长期记忆系统，到未来的图智能，技术的名词或许会随着周期的更迭而不断翻新，**但这些概念的底层逻辑始终如一：它们都是现实世界图结构在不同 AI 演进阶段的具体工程化表现。**

热点会变，但人类社会与商业运行中的错综关系永远不会消失。对于试图在 AI 时代构建长期技术护城河的企业而言，理解图、掌握图、布局原生分布式图基础设施，不是一个关于未来的选择，而是一个决定当下的必答题。

> 如果您的企业正面临万亿级深层风控穿透瓶颈，或正在重构基于多模态文档的 Fusion GraphRAG 架构，欢迎点击下方链接填写技术咨询问卷。
> https://wj.qq.com/s2/15344088/w7ei/

---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)


图数据库经典使用场景与 AI 时代的业务价值

2026 图数据库指南｜图数据库经典使用场景与 AI 时代的业务价值

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

很多技术团队都走过同样的路：先选一个大模型，然后把公司里的文档、手册、报告塞进向量数据库，再搭一个 RAG 问答系统。原型跑起来那天的感觉特别好，问什么答什么，反应快，看起来像模像样。

但系统真正投入业务之后，问题就来了。

一旦问题变得复杂，系统就开始答非所问。有时候它给出的答案看起来头头是道，但细查来源，发现推理过程根本站不住脚。

团队换过更贵的模型，效果有改善，但一到复杂问题就崩的现象，始终没有根除。

后来大家慢慢意识到：问题可能不在模型本身，而在于知识被喂给模型之前的那一步——检索。

# 一、传统 RAG 正在把企业知识切碎

RAG（检索增强生成）是目前企业用大模型的普遍做法。用户提问，系统先从知识库找出相关文字，连问题一起丢给大模型，让模型根据这些文字回答。

传统 RAG 依赖向量检索，做法是：

* 把每篇文档切成文本块（chunk），比如每块 500 字
* 把每个块转化成高维向量
* 用户提问时，把问题也转化成向量，去库里找语义最相似的块

对一般场景中的简单问答，这个方法有效。

但企业里的真实问题，极少是这种点对点查询。因为企业知识的核心是关系。

* 归因关系：如设备故障手册里的故障现象和根本原因
* 传导关系：如产业链分析报告的上游价格和下游需求
* 前后依赖关系：如 SOP 流程文档的不同步骤
* 层级关系：如产品手册的零部件和子系统

**而传统 RAG 的第一步：切文本块，恰恰把这些关系切断了。**

> “客户 A 为什么被判定为高风险？”

背后可能涉及：用户 → 设备 → IP → 联系人 → 黑名单账户 → 历史交易 → 欺诈团伙，这不是一个文本块能回答的问题。

> “某设备关联过哪些异常账号，这些账号之间有没有共同联系人？”

这里需要的是关系推理、多跳遍历、结构化关联，而不是语义相似。

使用传统 RAG，非常可能出现以下几大问题[1]。

## （一）关系缺失

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/1.webp)

文档之间天然存在引用、衍生、对立等复杂关系，向量数据库将文档切分为孤立的片段后，数据的关联随之减弱。

一个因果链条可能跨越三个段落，被切成三个独立文本块后，关系被破坏。一个产品特性可能分散在不同章节，被切碎后，模型再也看不到完整画像。

## （二）语义鸿沟

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/2.webp)

语义相似度 ≠ 上下文相关性 。举个相似但不相关的例子，保温杯与保温大棚，两者在转换成 Embedding 后的向量相似性很高，因为它们在很大比例上共享“保温”这一语义特征。但在一些场景下，想要了解保温杯却召回了保温大棚的信息。一个是喝水的，一个是用于农业种植的，完全不相关。

RAG 在索引阶段即使设置了比较高置信度，也很可能因为其相似性而得到不相关的信息。

## （三）全局推理乏力

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/3.webp)

"所有文档的核心观点是什么？"、"政策中最重要的五点信息是什么？"。这类需要跨文档综合分析、提炼的全局性、社区级问题，恰恰是向量检索的局限之处。

# 二、企业知识天然就是一张图

有没有一种方式，能**完整保留知识之间的关联**？

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/4.webp)

**答案是图数据库（Graph Database）。图数据库由节点和边构成。节点代表事物，边代表关系，每个节点和边都可以定义其属性。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/5.webp)

事实上，NebulaGraph 在微软之前就率先提出了 GraphRAG[2]，而且微软在论文中也引用了我们的 GraphRAG 相关工作[3]。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/6.webp)

NebulaGraph 是分布式开源图数据库，主要面向大规模、高性能的应用场景，支持千亿点、万亿边的超大规模数据集。目前，在 DB-Engines 的图数据库排行榜上，我们排名全球第二[4]。

**企业知识本质上就是一张巨大的图**，只是平时藏在文档、表格、邮件里，没有被显式表达出来。

产业研报，变成图：

节点：上游企业、中游厂商、下游需求、价格指标、产能数据
边：上游→中游（供应关系）、中游→下游（需求关系）、价格→产能（影响关系）

设备维护手册，变成图：

节点：设备型号、故障现象、可能原因、检测方法、解决措施
边：现象→可能原因、原因→检测方法、方法→解决措施

这些关系一旦被显式构建出来，企业知识就不再是散乱的文本，而是一个**可以被系统遍历和推理的网络**。这就是 GraphRAG 最简单的出发点。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/7.webp)

GraphRAG 不是简单地给 RAG 加一个图数据库。它的本质是抽取文档中的实体和它们之间的关系，让大模型在关系网络上做路径探索和逻辑推理，而不是在碎片里做相似匹配。

# 三、GraphRAG：从“找相似的”到“找相关的”

图技术如何解决传统 RAG 的三大挑战？

## （一）解决文档切分难题

向量数据库的第一步是切文本块。

图模型提供了完全不同的思路。文档、章节、段落可以作为具有丰富属性的节点存在，并通过边明确表达其间的层级关系和引用关系。语义被结构性地保留下来，不需要靠“切”来牺牲完整性。

## （二）重建上下文关联

一个多级部门文档体系，在向量数据库中，这些文档被切成文本块后是“平权”的——一级和三级的内容混在一起，无法保留层级、来源和引用关系。

在图数据库中，可以清晰地建模“发布”“引用”“归属”等关系。一篇三级报告引用了一级纲领的某条原则，这个关系可以被显式记录下来。当用户问“这份报告的合规依据是什么”，系统可以沿着引用边一路回溯到纲领原文，形成可追溯、可解释的知识链条。

## （三）解锁复杂推理能力

对于关联类问题。图数据库可以通过子图搜索、路径查询轻松找出两个节点之间的连接路径，即使这条路径跨越了多个中间节点。

对于总结推理类问题，图数据库可以利用社区发现、中心性分析等图算法，识别出知识网络中最关键、最聚合的信息群，而不是像向量检索那样简单返回相似度最高的几个段落。

##  （四）小结

保留结构、重建关联、支持推理，这三大核心能力正是 GraphRAG 区别于传统 RAG 的本质所在。并且结果更精确，更重要的是每一步推理路径都可以完整展示给用户。

# 四、Fusion GraphRAG：**NebulaGraph 的自我超越**

## （一）Fusion Graph Index（融合图索引）

技术不会止步。随着企业数据越来越复杂——PDF、Excel、PPT、图片、时序数据混在一起，GraphRAG 遇到了新挑战：**如何在一个系统里同时处理文档结构、实体关系、语义相似性？**

**为此，NebulaGraph 提出了原创的 Fusion GraphRAG 架构。**

Fusion GraphRAG 在知识图谱之上，创新地增加了一层 **Fusion Graph Index（融合图索引）**，将非结构化文档解析为层次化目录树结构：文档 → 章节 → 段落 → 文本块 → 图表。

这种树状结构直接置于 LLM 的推理上下文中，成为它可以主动遍历和推理的上下文内索引。

也就是说，Fusion GraphRAG 让文档的层次化结构本身即可作为可推理的索引，让 LLM 根据问题意图动态决定“去哪里找”，而非静态匹配“什么看起来像”，给 LLM 装上了智能导航。

这种能力的本质，是**让检索从静态匹配，开始进入动态结构推理阶段。**

## （二）四大索引能力

因此，在 Fusion GraphRAG 中，实际上**存在四类核心索引能力：**

* 图索引负责实体关系与多跳路径推理；
* 向量索引负责语义相似召回；
* 全文索引负责关键词精准匹配；
* 融合图索引则负责文档结构导航与上下文推理。

四种索引能力各司其职，又动态协同。

* 简单 FAQ 场景下，向量检索可以快速返回结果；
* 复杂关系分析则更多依赖图路径推理；
* 专业术语与法规查询适合全文检索；
* 长文档、多章节、跨引用场景，则由融合图索引主导结构导航。

这一设计带来了显著的效率提升：

* 相比使用大模型抽取知识图谱，索引构建速度提升约 10 倍；
* 在与微软 GraphRAG 的对比中，索引阶段更是快了近 20 倍，同时问答准确率更高。

# 五、NebulaGraph AI 应用平台

Fusion GraphRAG 是技术方案。企业需要的是**可以直接用的产品**。

NebulaGraph AI 应用平台正是基于 Fusion GraphRAG、以 NebulaGraph 图数据库为引擎的完整产品。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/8.webp)

## （一）核心能力

* **零代码搭建智能助手**：通过可视化界面导入知识资产、配置检索策略，不用写代码
* **自然语言直接转换图查询语言**：业务人员能够自主构建算法，无需依赖研发团队，快速将业务规则落地图分析中
* **多类型索引统一存储**：将向量、全文、图和融合图索引建立在一个平台内，系统自动选择最优索引策略
* **多模态解析**：PPT、Word、Excel、PDF、图片可快速解析。
* **企业级权限隔离**：不同部门知识集相互隔离，可按区域、产品线做二级隔离
* **模型无关**：底层大模型可随时更换，支持 GPT、通义、 DeepSeek、 GLM 等大模型。

## （二）生态完整

我们构建了完整的 AI 应用开发生态：

* **Nebula AI Application SDK**：为开发者提供灵活调用的工具包。
* **Nebula AI 应用平台**：零代码开箱即用的端到端平台，用户只需选择知识库，即可创建专属 AI 应用。


# #（三）场景多元

**目前，NebulaGraph AI 应用平台已在以下场景中通过实际业务检验。**

* 金融与数据分析：财报分析与跨文档校对、历史交易文档查询对比、产业链AI研究（如黑色系）；
* 工业与智能制造：故障树处理与排故引导、工业决策辅助；
* 法律合规与合规：法律法规条款查询、合同合规性审核；
* 企业通用智能助手：钉钉/企微机器人问答、网站 AI 搜索、业务流程入库与图查询、新零售企业内部智能助手（员工培训/文档查找/销售数据分析/多国法务合规等）。

## （四）正确率显著提高

在开源 KG-RAG 评测集（专门测试多跳推理，问题平均需要2-4跳）上，**召回率和回答正确率比 SOTA 高出 10% 以上。**

在金融类法律法规的真实企业场景中，人工评分正确率达 95%。

# 六、用户案例

## （一）中国船舶集团第七O八研究所：故障树处理与引导排故

**1. 挑战**

客户有大量的非结构化文档， 文档内有故障树描述（树状描述， 或者文字描述）、

引导排查故障的方法（维修记录等），且涉及高端船舶制造，产品设计及排障流程复杂。

**2. 成效**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/9.webp)

故障平均排查时间大幅缩短。同时，每次成功排故后，工程师的查询路径被系统记录下来，数千个故障场景的推理路径沉淀为企业可复用的数字资产。新工程师遇到类似问题时，系统可以直接推荐历史成功路径。

这是行业首个船舶生成式人工智能驱动的实际应用场景通过实现图驱动的检索增强智能体，优化了信息检索的准确性和速度，提高了系统的灵活性和适应性。

## （二）某期货企业：产业链 AI 研究助手

**1. 挑战**

某期货企业的研究员每天要跟踪黑色系产业链。上游焦煤、焦炭、铁矿石的价格和库存，影响中游钢厂的产能决策，再传导到下游建筑、制造、出口的需求。研究员同时盯着十几个数据源，外加大量历史研报和实时资讯，导致一份日报需要耗时 4-6h。

**2. 成效**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-application-platform-introduction/10.png)

显著减少人工分析时间，单份日评制作时间降低至 30min 以内，自动化生成专业、及时、准确的黑色系期货日评报告。

# 七、重新定义 AI 如何理解知识

回到开头的困惑，为什么接了模型、建了向量库，复杂问题还是答不好？答案已经清晰了。

你给大模型看的，是被切碎的、断了关系的文字碎片，却指望它能理解那些依赖复杂关系才能回答的问题。

传统 RAG、GraphRAG 与 Fusion GraphRAG 代表了检索增强生成技术从简单语义匹配，到全局结构理解，再到动态推理导航的演进路径。

在这条路上，NebulaGraph 从未缺席。从率先提出 GraphRAG 方案，到推出原创的 Fusion GraphRAG 架构，再到今天的 NebulaGraph AI 应用平台，我们一直在做同一件事：**重新定义 AI 如何理解知识。**

> **填写[咨询问卷](https://wj.qq.com/s2/15344088/w7ei/)，与我们取得联系**

---

✨💡 NebulaGraph AI 应用平台为企业版产品

引用

[1]RAPTOR- RECURSIVE ABSTRACTIVE PROCESSING FOR TREE-ORGANIZED RETRIEVAL， arXiv:2401.18059

[2][Graph RAG: 知识图谱结合 LLM 的检索增强.](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515631&idx=1&sn=5215688c309d84c428b6b770e7c0dfc1&scene=21#wechat_redirect)

[3]From Local to Global: A Graph RAG Approach to Query-Focused Summarization, arXiv:2404.16130

[4][NebulaGraph 全球图数据库排名第二.](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515915&idx=1&sn=4f53647870a1c02566c17504fac516fc&scene=21#wechat_redirect)

NebulaGraph 如何用 Fusion GraphRAG 重新定义企业知识检索

NebulaGraph AI 应用平台：四种索引融合，重新定义 AI 如何理解知识

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---
> ‌Easycash‌ 是面向印度尼西亚市场的数字金融科技平台，由‌瓴岳科技‌（Fintopia）推出，主要提供消费贷款服务。用户只需填写真实身份信息并完成简单手续，即可在 3 分钟内提交贷款申请，并在 24 小时内完成审核，资金快速到账。月活跃用户超 ‌**200万**‌，在印尼借贷类 App 中位居第一‌‌。

印尼头部金融科技平台 EasyCash 面向中小企业与个人用户提供数字金融服务，通过 AI、大数据风控模型以及核心信贷系统，支撑线上贷款业务持续增长。截至 2025 年，公司已服务全球超 114 家金融机构，拥有逾 1.81 亿注册用户，累计交易额突破 5400 亿元。

随着业务规模扩大，传统风控架构开始暴露明显瓶颈。EasyCash 使用 NebulaGraph 企业版后，实现欺诈拦截率提升 240%，审核压力下降 70% 的业务收益。

# 一、从规则风控到关系风控

在互联网信贷场景中，欺诈行为往往并不是孤立存在的。黑产会通过设备共享、身份复用、联系人关联、团伙协作等方式构建复杂关系网络。

例如：

* 一个设备对应多个账号

* 一个身份证关联多个借款人

* 多个申请人共享紧急联系人

* 欺诈资金在不同账户之间循环流转

这些问题的核心是数据关系复杂，如何识别这些关系后的幕后黑手，对黑产团伙进行溯源，成为重中之重。

EasyCash 早期主要依赖传统关系型数据库与静态规则引擎完成风险识别，但随着并发规模提升，系统逐渐无法满足实时风控需求。

在高并发场景下，关键风控查询响应时间超过 3 秒，导致高风险申请存在约 30% 的漏判率。

与此同时，原有离线数据架构生成图特征需要超过 8 小时，严重影响 AI 风控模型的实时性。

因此，EasyCash 开始重新思考风控系统底层的数据组织方式。

# 二、为什么图数据库更适合实时风控

## （一）图数据库

传统数据库擅长存储结构化记录，但在多跳关系分析场景中，复杂 JOIN 会带来极高的查询成本。

而风控系统真正关心的问题，本质上是关系计算。

例如：

* 某申请人 3 跳范围内是否存在黑名单联系人

* 同一设备是否关联超过 5 个身份

* 某资金流路径是否与历史欺诈团伙重叠

* 某用户是否处于高风险社区网络中

这些问题天然适合通过图结构建模。

## （二）NebulaGraph

此外，对于实时风控场景，EasyCash 更关注的是系统在生产环境中的稳定性与扩展能力。

NebulaGraph 的三大核心能力，正与其业务需求高度契合。

**1. 分布式架构**

NebulaGraph 采用分布式设计，支持在线横向扩展，能够持续承载不断增长的关系数据规模。对于金融业务而言，这意味着风险图谱无需频繁重构即可持续扩容。

**2. 高并发低延迟**

风控系统需要在大量请求同时到来时依然保持稳定响应。NebulaGraph 能够在高吞吐场景下保持毫秒级查询能力，适用于实时授信、反欺诈、关系分析等场景。

**3. 与大数据生态深度集成**

EasyCash 同时使用 Spark、Flink、Kafka 等数据基础设施。NebulaGraph 提供了完善的数据连接能力，使实时数据流、图计算以及机器学习流程能够形成统一架构。

基于这一思路，EasyCash 引入 NebulaGraph 以构建实时风控图谱系统。

# 三、构建百亿级实时风险关系图

EasyCash 基于 NebulaGraph 搭建了一套实时风险图谱，覆盖用户、设备、手机号、联系人、借贷关系等多种实体与关系，整个风险图规模超 10 亿个节点，190 亿条边。

* 用户、设备、手机号、银行卡，可以被建模为不同类型的点（Vertex）

* 登录、绑定、借款、联系人关系，则被建模为边（Edge）

* 每个点和边都可以携带属性，例如设备型号、手机号归属地、借款时间、交易金额等信息

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/%20financial%E2%80%8C-risk-%20management-easycash/1.png)

用 Graph 来建模⬆️

在这种图结构中，系统可以直接沿关系链路进行多跳关联分析，例如快速识别“一个设备关联多个身份”或“某用户与黑名单存在间接关系”等复杂风险模式。

> 查询用户 3 跳内所有关联路径

```
use financial_risk_graph match p=(n@user{user_id:"u067"})-[]-{1,3}(e) return p
```

NebulaGraph 5.x 图查询⬆️

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/%20financial%E2%80%8C-risk-%20management-easycash/2.png)

对应的 Graph⬆️

系统还能通过实时更新机制持续写入最新行为数据，使风控模型能够动态感知风险变化。

同时，NebulaGraph 的分布式架构，使 EasyCash 可以在横向扩展过程中持续提升图存储与查询能力，同时保证高可用与低延迟，实现金融风控的实时极速查询。

> 欢迎体验 NebulaGraph 5.x 金融风控 Demo⬇️
> https://www.nebula-graph.com.cn/posts/financial-risk-management

# （一）授信阶段：毫秒级风险决策

在用户提交贷款申请时，风控系统会实时查询申请人的 1 到 3 跳关系网络。

系统重点检测：

* 紧急联系人是否存在黑名单关联

* 当前设备是否绑定多个身份

* 关联网络中是否存在异常聚集行为

* 是否命中历史欺诈路径

* ……

基于动态图规则与关系计算，系统能够在单次查询 8ms 内完成风险评分，即使在 300+ 高并发请求场景下，依然保持稳定响应。

这意味着风险判断已经从传统的事后审核，前移到实时决策。高风险用户可以在授信阶段被直接识别，从源头降低坏账与欺诈损失。

#（二）放款阶段：识别隐藏团伙网络

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/%20financial%E2%80%8C-risk-%20management-easycash/3.png)

相比单点规则，真正复杂的金融欺诈往往具有明显的团伙化特征。

在放款阶段，EasyCash 将 NebulaGraph 生成的实时图特征，与机器学习模型进一步结合，包括：

* 社区风险密度

* 资金流路径

* 关系传播特征

* 子图结构 embedding

通过系统曾通过子图分析识别出一个由 20 台设备，100 个手机号构成的蜘蛛网式欺诈网络。从而精准拦截贷款欺诈行为。

# 四、拦截率提升 240%，审核压力下降 70%

基于 NebulaGraph 重构风控体系后，EasyCash 获得了明显的业务收益。

* 60% 的高风险申请在授信阶段即被拦截

* 人工审核工作量下降 70%

* 整体欺诈拦截率提升 240%

* 用户通过率反而提升 15%

这意味着风控能力提升，并没有以牺牲用户体验为代价。

与此同时，自动审批系统将传统融资门槛降低约 40%，平均贷款处理时间缩短至 8 分钟以内，更好地满足了印尼市场对普惠金融与高效数字服务的需求。

# 五、图数据库正在成为新一代风控基础设施

金融风控的核心问题，正在从数据是否足够，转向关系是否可计算。

当黑产行为越来越网络化、组织化，传统规则系统已经难以应对复杂关系风险。而图数据库能够将用户、设备、身份、联系人、资金流等信息连接成完整关系网络，并在实时计算中持续发现隐藏风险。

对于 EasyCash 而言，使用 NebulaGraph 不只是一次数据库升级，更是整个风控体系从离线规则模式向实时关系智能的转变。

> 填写咨询问卷，与我们取得联系⬇️
> https://wj.qq.com/s2/15344088/w7ei/

---

💡风控案例

[每月风控止损超百万元：携程酒店业务基于 NebulaGraph 的风控实践](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516504&idx=1&sn=ff450f9d2479e8218df632b198307008&scene=21#wechat_redirect)

[基于知识图谱的 Web3 风控：普适智能一站式知识中台](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515978&idx=1&sn=079d22d3bf3f06b5d13e70598a081dd4&scene=21#wechat_redirect)

[风控利器：BlockSec 用图+标签破解 Crypto 合规难题](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516261&idx=1&sn=f3e91388b2a0e796801bea67bd6f9517&scene=21#wechat_redirect)

[NebulaGraph 在 Airwallex 跨境金融风控的应用](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247515804&idx=1&sn=82973a9f946708468e9fddfd52243ebd&scene=21#wechat_redirect)

✦

EasyCash 使用 NebulaGraph 企业版后，实现欺诈拦截率提升 240%，审核压力下降 70% 的业务收益。

欺诈拦截率提升 240%：EasyCash 基于 NebulaGraph 构建金融智能风控系统

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

> 远景智能（Envision）是专注于智能风电、智慧储能系统及绿氢解决方案的能源系统公司。远景全球风电装机突破 100GW，订单量连续四年全球第一，全球业务布局覆盖中国、欧洲、美国、南美、东南亚等地，在丹麦建立了中国风电企业最大规模的研发机构。

新能源的快速发展，风电、储能、分布式能源以及负荷侧的高度动态化，使电力系统向跨空间、跨时间、多主体耦合的动态复杂网络演变。

作为全球领先的能源技术企业，远景智能业务横跨智能风电、储能系统以及 AIoT 操作系统，管理着规模庞大、结构复杂的全球能源资产网络。

当系统复杂度跨越临界点，问题不再是数据够不够，而是**如何理解这些数据之间的关系，并在实时条件下做出决策。**

这正是 NebulaGraph 在远景智能技术体系中的核心价值所在。

#  一、业务挑战：传统架构面临的三大挑战

随着新能源比例提升，电网运行呈现出更强的不确定性与动态性，原有系统开始暴露出结构性问题，主要集中在三个方面。

## 1. 关系复杂度爆炸，传统架构失效

电网本质是一个高度拓扑化的系统：

* 设备之间存在多层级连接关系
* 电气关系与物理连接并不完全一致
* 影响传播具有多跳特性

在传统关系型数据库中，这类问题通常依赖多表 JOIN 实现。例如：

> 从某个变电站故障出发，计算影响范围内的线路与用户

随着网络规模扩大，JOIN 数量指数级增长，查询性能迅速退化，无法支撑实时分析。

##  2. 实时性要求从分钟级跃迁到秒级

传统电网分析系统普遍运行在分钟级，但在新能源占比不断提升后，系统状态变化速度显著加快：

* 风电、光伏具备强波动性
* 负荷侧更加动态
* 调度窗口被压缩

新一代电网要求核心分析能力，能与 SCADA（数据采集与监视控制系统）秒级数据刷新频率保持同步，这对底层数据平台提出了更高要求：

* 高吞吐写入
* 低延迟查询
* 计算与存储协同

## 3. 多源数据割裂，难以形成全局认知

电网数据天然分散在多个系统中：

* SCADA（实时数据）
* 资产管理系统（静态模型）
* 气象系统（外部环境）
* 调度系统

同时，配电网存在可观测性不足的问题，如实时测量点稀疏，数据粒度不一致。

这导致一个关键瓶颈——无法构建完整、统一的全网运行视图，进而限制了输配协同优化、风险预测、动态调度等高级能力。

# 二、技术选型：为什么是 NebulaGraph

远景智能最终选择 NebulaGraph，核心原因并不只是性能，而是其与电网问题形态的匹配度。

电网本身就是典型的图结构系统。设备之间通过物理连接和电气关系构成网络，用图模型表达可以直接还原其真实结构。相比之下，关系型模型需要通过拆分与重组才能间接表达，复杂度更高。

NebulaGraph 在这一基础上提供了几个关键能力：

* 分布式架构，支持横向扩展
* 存储与计算协同，降低数据搬移成本
* 原生图存储，支持大规模复杂关系建模
* 高效的多跳遍历查询，适用于拓扑分析场景

这些能力使其不仅能存关系，还能在关系之上完成高性能计算、分析。

# 三、方案落地：构建全图数据体系
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/power-grid%E2%80%8C-envision/envision-1.png)

基于 NebulaGraph，远景智能构建了覆盖“源-网-荷-储”的一体化图模型，将原本分散的数据整合为一个可计算的整体。

* **源（Source）**：发电侧——电从哪里来（火电、风电、光伏等）
* **网（Grid）**：电网——电怎么走（输电、变电、配电）
* **荷（Load）**：用电侧——电被谁用（企业、家庭、设备等）
* **储（Storage）**：储能——电如何调节（储能用于削峰填谷、平衡波动）

## 1. 图建模：让电网结构自然表达

在 NebulaGraph 中：

* 顶点（Vertex），表示设备与实体
* 母线、变压器、开关
* 用户、组织单元
* 边（Edge），表示关系
* 电气连接
* 拓扑关系
* 归属关系

## 2. 多源数据融合：构建统一数据底座

远景智能将多类数据整合进同一张图中：

* SCADA 实时数据
* CIM/E 静态模型
* 气象数据
* 运行状态数据

最终形成一个，跨时间 + 跨空间的统一的全图电网，以关系为核心将数据进行有序组织。

## 3. 自动拓扑构建机制

为保证模型可持续更新，远景智能构建了自动化转换机制：

* 将传统关系型模型自动转化为图模型
* 实现拓扑的动态更新
* 保证数据一致性

# 四、关键能力：

NebulaGraph Analytics 更快更灵活

在图结构之上，计算方式发生了明显变化。NebulaGraph 的存算一体架构，使计算尽可能在数据本地完成，减少 I/O 开销。同时，图遍历具备天然的并行性，可以在多节点环境中高效执行。

此外，NebulaGraph Analytics 图分析平台相较于 Apache Spark GraphX，资源消耗降低至约 20%，计算性能提升约 5–10 倍。

在更快的基础上，还支持在超大规模图上灵活自定义复杂算法，远景智能不仅可以调整参数适配数据特征，更能基于业务需求编写专属算法。

针对电网中的典型问题，如潮流传播路径、故障影响范围、连通性分析等，基于 GQL 的自定义算法能力，可直接定义计算逻辑，业务人员能够自主构建算法，无需依赖研发与产品团队，将业务规则更智能、更贴合实际地落地到图分析中。

# 五、应用成效：从分钟级到毫秒级

图架构带来的变化，最终体现在核心业务指标上。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/power-grid%E2%80%8C-envision/envision-2.png)

更重要的是，这种提升改变了系统的工作方式。电网分析可以与实时数据同步运行，支撑动态调度与风险预判。

远景智能基于 NebulaGraph 图计算，还创新性地打造了时空演化图（Temporal Evolution and Spatial Evolution Graph）加速机制，通过对历史结果的复用，减少重复计算开销，实现：

* 实时分析速度提升 15–20 倍
* N-1 分析提升 10 倍以上

# 六、总结：从数据管理走向关系计算

这一实践的关键，并不只是引入了一套新数据库，而是完成了一次建模方式的转变。这种架构不仅适用于电力系统，也适用于所有复杂关系网络场景：

* 风控关系网络
* 知识图谱
* 实时推荐系统
* 供应链网络
* ……

当系统复杂度不断上升时，如何表达关系、如何在关系之上计算，决定了系统的上限。

NebulaGraph 提供的能力，使电网从数据驱动走向关系驱动，也为实时感知和智能决策提供了基础。

如果你正在构建类似复杂系统，欢迎深入了解 NebulaGraph，探索如何构建属于你的智能关系网络。

> 填写咨询问卷，与我们取得联系⬇️
> https://wj.qq.com/s2/15344088/w7ei/


---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)

远景智能使用 NebulaGraph 打造新电网系统，性能提升15-20倍

新电网毫秒级解决方案：远景智能基于 NebulaGraph 的应用

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

> 本文根据 NebulaGraph@方扬，在社区 AI+Data MeetUp 上的演讲整理。文末附 PPT 下载链接、直播回放。

✨推荐阅读

[别再卷大模型了：Palantir 告诉我们，AI 的进阶是“本体论”](https://mp.weixin.qq.com/s?__biz=MzE5ODg1MDA1NQ==&mid=2247516548&idx=1&sn=a87f2f9a1336ec2050d17feb7509e973&scene=21#wechat_redirect)

---

从去年 DeepSeek 发布到现在，基本上每天我们都能接收到新东西——**AI的发展实在是太快了**。作为一家数据库厂商，说实话我们自己也很焦虑。我们一直在想：在AI时代，我们应该做什么样的事情，才不至于落后？

---

## 01 图技术驱动 AI 理解世界

前几天我跟社区沟通时，发现了一个很神奇的事情：最近有非常多的大厂主动来找我们。我们一开始还以为，是我们的市场和运营突然做得特别好了。

后来一分析，原因很简单——**这半年多，美国的 Palantir 太火了**。

这家公司最开始火，是因为帮助抓住了本拉登。而现在，它的市值已经达到了 **3500 亿美金**， 2025 年的营收大概是 40 多亿美金。

**就是 Palantir 的爆火，带动了一大批SaaS公司都在向它靠齐。**

那 Palantir 最核心的东西是什么呢？**本体论。**

所以我今天带来的话题就是：以本体论重构数据，通过图技术驱动 AI 理解世界。

---

## 02 数据才是企业真正的护城河

AI 领域现在无外乎几块：算力、模型、数据，还有一个最近很火的 Harness.

> Harness‌ 直译为“马具”，在 AI 领域指包裹在大模型外围的一整套‌**全链路执行与治理系统**‌。

算力，基本上是一个资本问题——有钱就能用到很好的算力。模型，迭代非常快。对大多数企业来说，更多的是去用它，而不是自己去做它。

**那对于企业来说，真正核心的是什么？是它的私有化数据。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/1.png)

为什么私有化数据这么重要？因为它有三个独特的特点：

* **独占性**：不可复制，每个行业的数据都不一样。
* **累积性**：越积越多，越积越好。
* **反馈性**：越用越好，可以不断完善。

**所以，拥有好的数据，就能帮助企业持续领先。**

---

## **03 AI 在生产制造环节的渗透率只有 24%**

我们现在用AI，基本上是在两端：

* 研发端：写代码非常爽
* 营销端：写推文、写营销文案

但是到了生产制造环节，问题就来了——**不确定性、幻觉问题、概率性问题、实时性问题**。

生产制造要求的是：**高确定性、可重复、稳定、实时**。

前几天我参加了一个会议，华为分享了他们在AI领域的经验：**AI目前主要应用在研发和销售两端，生产制造的比例只有24%**。这个比例非常低。

为什么？核心原因我们认为还是**数据的问题**。

---

## 04 拥有数据 ≠ 数据被组织好了

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/2.png)


很多企业存在这些问题：

* **碎片化**：数据分散在不同系统，缺少统一视图。
* **弱语义**：字段含义需要人工解释，机器不理解。
* **歧义性**：同一个字段在不同系统中口径不一样。举个例子，我司常开玩笑说“我们的目标是 Be Rich”，但每个人对“富裕”的定义都不一样——我觉得 1000 万就富裕了，老板觉得得至少得有一个亿。
* **随意性**：同一个信息在不同系统里名字不一样。我们看过中国移动的系统，同一个客户 ID，有的地方叫 customer_id，有的叫 user_id，有的就叫 id.
* **不显性**：业务经过翻译和映射，难以直接关联。

**所以，对企业来说，最难的不是有没有数据，而是数据有没有被组织成稳定的、含有业务语义的结构。**

---

## **05 本体论到底是什么？**

Siri 联合创始人 Tom Gruber 给出的定义：**本体论是对某一领域共享概念模型的形式化、明确化描述。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/3.png)


左边是一堆数据——账户表、订单表、交易记录。右边通过本体论重新组织后，你看到的是：客户是什么样的、商品是什么样的、用户行为是什么样的。它把数据组织成了**知识**。

以前你看到的是表，是系统中心的物理视角。现在你看到的是业务视角——工厂、人员、设备……它描述的是**事理**，而不只是事实。

---

## 06 本体论不新鲜，为什么现在突然火了？

本体论这个概念已经几十年了。金融行业的朋友可能知道，IBM 以前推过 FSDM，还有 FIBO——这些都是企业里数据组织的良好定义。

那为什么现在 AI 时代，本体论变得如此重要？

**因为这是我们第一次进入了一个“必须让机器理解世界”的时代。**

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/4.png)


过去，语义被藏在了人脑里、藏在报表里、藏在流程里。搞不定的，我们可以靠人肉翻译、口口相传。

但现在完全不够了。我们不再需要机器只是计算，我们需要机器去**理解**。我们需要的不再是信息系统，而是**认知系统**——理解、推理、决策。

诉求变成了：从数据驱动到语义驱动，从能理解到机器理解，从预定义系统推理到开放、变化的系统推理。

---

## 07 Palantir 的操作本体论实践

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/5.png)


Palantir 的核心架构分三层：

* 底层：数据层
* 中间层：Foundry——本体论的管理和抽象
* 上层：AIP——AI应用的构建

它的核心思想是：**让业务用户和系统以统一的「对象语言」操作数据，不需要理解底层数据库结构。**

几个关键概念：

* **对象类型**：把数据表映射成“客户”“订单”“资产”，屏蔽技术细节
* **关系链接**：定义对象之间的关系，跨数据源自动关联
* **操作动作**：把业务操作绑定到本体对象，触发下游系统更新
* **AI 接入层**：让大模型通过本体理解语义，Agent 用自然语言查询和操作知识图谱

Palantir 的 CEO 说：**本体论是我们一切的核心，不可破坏。**它的核心价值就是两个词：**理解**和**操作**。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/6.png)


* **理解**：统一语言、全景视图，打破部门壁垒，形成 360 度视图
* **操作**：不仅仅是查询，还允许回写（Write-Back）、决策编排、模拟仿真

---

## 08 透过现象看本质：本体就是图模型

我们做图的，看到这些东西非常兴奋。为什么？

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/7.png)


**本体论打通了业务模型与数学模型之间的语义鸿沟。图技术打通了数学模型与物理存储之间的实现鸿沟。**

你看，哲学本体论里的实体、关系，对应到工程实践里的对象、链接，再对应到图数据库里的节点、边——**完全是一一映射的。**

所以，虽然很多人讲本体论下面不一定是图模型，但我认为：**图的存储，是最好的能够承接本体论工程实践的存储系统。**

---

## 09 图技术让本体可计算、可推理、可进化

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/8.png)


那图数据库能做什么呢？以 NebulaGraph 为例：

* **原生图存储**：基于属性图模型，支持文本、时间、空间、向量等多种数据类型，天然承载本体中的类、实例和属性。
* **多跳关系遍历**：高效实现本体中的继承、传递等关系推导。
* **动态 Schema**：支持灵活演进，业务变了，Schema 跟着变，不需要迁移数据。
* **推理集成**：支持相似度计算、关系预测、标签传播，在本体之上实现隐式关系发现和知识补全。
* **GQL 模式查询**：用`(a)-[r]-(b)`这种直觉化的方式查询，接近人类认知。
* **实时更新**：支持本体实例和关系的实时增量更新，保证推理和决策中的数据一致性。

---

## 10 哪些企业最迫切需要本体论破局？

不是所有企业都需要一股脑往上冲。但如果你在以下五项里命中三项以上，建议现在就开始考虑：

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/9.png)


1. **平台型企业**：用户、商家、内容、行为在多个触点重复出现。
2. **强监管行业**：不仅要给结论，还必须解释对象关系、决策路径和责任边界。
3. **复杂运营网络**：上下游、事件流、规则层持续耦合，字段视角不够用了。
4. **高异构系统**：结构化数据、事件、文档、规则同时存在。
5. **高推理成本**：人能理解，但系统一直在拼写档案。

---

## 11 本体论的整体架构

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/10.png)


这是一个简单的本体论整体架构图：最底层是数据源，上面通过抽取和映射进入原生图存储，再上面是本体层，接着是 API 接口，供给 AI、BI、决策引擎等使用。

---

## 12 企业本体论转型的四个阶段

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-practice-graphdatabse/11.png)


**第一阶段：业务本质建模**梳理企业核心实体与承诺逻辑，建立初步的词汇一致性，补齐语义技术短板。关键是聚焦高价值业务域，做局部概念建模试点，消除多义词和同义词。

**第二阶段：打破数据孤岛**建立标准化知识工程流程，构建覆盖全企业的本体数据，建立数据映射，让数据流动起来。

**第三阶段：知识迭代**通过深度关联查询、链路预测、标签推导，自动化补全知识图谱，实现知识体系的持续更新。

**第四阶段：智能化驱动**对接大模型，支持可解释的企业级智能问答；配置推理规则引擎，实现全企业的隐形风险自动预警；建立闭环反馈机制，让 AI 生成的新知识沉淀回本体底座。

---

## 13 最后

我们最近还在探索基于本体的自动特征发现，结合大模型在做一些事情。随着本体论的不断演进，知识会越来越丰富，质量会越来越好，基于知识的业务决策也会越来越准、越来越高效。

**祝愿大家的公司都能像 Palantir 一样，做到 3500 亿甚至更大的市值。**

谢谢大家！

---

## ✨Q&A 精选

> Q：图数据库跟关系型数据库、国产数据库相比，区别和好处是什么？

## A：我认为，图数据库最核心的优势是，**它是最贴近人的自然理解的**。

从哲学（研究世界本质）到工程实践，再到物理存储，图是一一映射的。这意味着你在解决业务问题时，不需要把业务逻辑拆解成各种表、各种 join，直接用“它是什么”来定义就好了。

另外，现在很多数据库都在往多模方向发展，PG 最新版本也在往图的方向走。这本身是对图的一个认可。但我们是图原生的分布式数据库，查询效率和分布式能力会比 PG 更强。

> Q：除了风控、营销，有没有一些小众的场景？

A：我们看到的场景其实挺多的。金融领域做营销推荐和风控，互联网电商也是营销推荐，电信运营商做设备管理和数据血缘。

还有一个很有意思的能源行业。电网里有一个非常重要的计算叫潮流计算，用来解决电的调度问题。电越来越重要，建议大家以后买股票可以多看看能源方向。（仅为方老师推荐，本星云仔如实记录，不承担任何风险责任( ﾟ∀ ﾟ)o彡ﾟ）

---

PPT下载💡

https://discuss.nebula-graph.com.cn/t/topic/17457

商务咨询☎️

[联系我们 - 腾讯问卷](https://wj.qq.com/s2/15344088/w7ei/)

---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)

本体论落地最佳工具——图数据库 NebulaGraph

Palantir 本体论爆火，图数据库成为工程实践的最佳技术

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---
随着加密货币和 DeFi 的快速发展，链上资产转移与洗钱、欺诈等非法活动日益频繁。

图数据库能够将链上地址、交易、以及链下身份信息（如设备、IP、邮箱）关联起来，形成完整的风险图谱，帮助监管机构或安全团队识别黑名单地址、追踪资金链路、发现隐蔽团伙。

本 Demo 以 Web3 场景为例，建立包含用户、加密地址、转账关系以及链下信息的图模型，并通过多个查询示例展示如何追踪资金流向、发现与黑名单地址的关联。

[戳此开始探索～](https://www.nebula-graph.com.cn/demo)


> 💡本 Demo 演示了从用户到地址、再到交易流转的核心查询，仅作为简单场景下的 NebulaGraph 使用参考，实际应用中可结合图算法（如 PageRank、社区发现）进一步自动化风险挖掘。


> 🥳 特别感谢@Neil、@Phoenix 的支持～


# Why NebulaGraph
## 1. 原生关系建模，精准刻画关系密集型风险
黑客盗币、洗钱、批量注册等行为都隐藏在复杂的地址、设备、IP、交易路径中。传统关系型数据库难以处理多维关联与深度链路查询，而 NebulaGraph 以「点」和「边」形式天然建模实体与关系，能将链上地址、交易记录、KYC 信息、设备指纹等异构数据融合为统一图模型，让隐匿的关联团伙和资金网络无处遁形。

## 2. 毫秒级多跳穿透，实时阻断链上资金链路
稳定币和加密资产的风控要求毫秒级响应，尤其是追踪 5 层以上的转账路径或识别跨链混币行为。NebulaGraph 支持秒级多跳查询，精准还原黑客从盗币、转移、混币到提币的完整行为链。

> ✅在某头部交易所反作弊场景中，50 毫秒完成 3 跳查询，实时拦截批量注册与套利，将风险拦截在交易完成前。

## 3. 融合链上链下全域数据，打破数据孤岛

合规风控不仅需要链上交易，还需关联用户 KYC、支付渠道、设备指纹等链下信息。NebulaGraph 支持千亿点万亿边的统一图模型，轻松整合 Crypto Address、Blockchain TX、ID/Phone/Email、 等多源数据，构建从匿名地址到真实身份的完整画像，满足 FATF 旅行规则、MiCA 等监管对穿透式 KYC/AML 的要求。

## 4. 百亿级规模化部署，支撑交易所级实时合规

头部交易所日交易量超百亿美元，风控系统需在海量数据中保持高性能。NebulaGraph 已在真实生产环境支撑 40 亿点、400 亿边的风控图谱，实现秒级交易穿透、自动化合规报告，同时相比 GraphX 等方案算法性能提升 10-100 倍、内存开销降低 5 倍，大幅优化存储与算力成本（存储减 40%，算力省 60%），真正满足 Web3 高并发、低延迟、强扩展的严苛需求。

# 图模型设计

> 💡实际使用场景中，可对 Schema 进行相应修改与管理，为便于在线体验，本 Demo 暂不支持。


首先创建图类型与图空间，并执行以下语句以定义节点、边结构及属性：


```
CREATE GRAPH TYPE IF NOT EXISTS `web3_risk_type` AS {
  NODE TYPE `user` (LABEL `user`{`user_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `age` INT64 DEFAULT NULL, `education` STRING DEFAULT NULL, `gender` STRING DEFAULT NULL, `occupation` STRING DEFAULT NULL, `occupation_status` STRING DEFAULT NULL, `is_black_node` BOOL DEFAULT NULL, `zhangli` STRING DEFAULT NULL, `marital_status` STRING DEFAULT NULL, PRIMARY KEY (`user_id`)}),
  NODE TYPE `address` (LABEL `address`{`address` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`address`)}),
  NODE TYPE `card` (LABEL `card`{`card` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`card`)}),
  NODE TYPE `crypto_address` (LABEL `crypto_address`{`crypto_address` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`crypto_address`)}),
  NODE TYPE `email` (LABEL `email`{`email` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`email`)}),
  NODE TYPE `device` (LABEL `device`{`device` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`device`)}),
  NODE TYPE `id_no` (LABEL `id_no`{`id_no` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`id_no`)}),
  NODE TYPE `ip` (LABEL `ip`{`ip` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`ip`)}),
  NODE TYPE `phone` (LABEL `phone`{`phone` STRING NOT NULL, `is_black_node` BOOL DEFAULT NULL, PRIMARY KEY (`phone`)}),
  EDGE TYPE `transfer` (`crypto_address`)-[LABEL `transfer`{}]->(`crypto_address`),
  EDGE TYPE `user_address` (`user`)-[LABEL `user_address`{}]->(`address`),
  EDGE TYPE `user_card` (`user`)-[LABEL `user_card`{}]->(`card`),
  EDGE TYPE `user_crypto_address` (`user`)-[LABEL `user_crypto_address`{}]->(`crypto_address`),
  EDGE TYPE `user_device` (`user`)-[LABEL `user_device`{}]->(`device`),
  EDGE TYPE `user_ip` (`user`)-[LABEL `user_ip`{}]->(`ip`)
}

CREATE GRAPH `web3_risk_graph` :: `web3_risk_type`
```


## 1 . 节点

| 节点类型       | 标签               | 核心属性                                                                                   |
| :------------- | :----------------- | :----------------------------------------------------------------------------------------- |
| 用户           | `user`             | `user_id`, `name`, `age`, `education`, `gender`, `occupation`, `is_black_node`             |
| 加密地址       | `crypto_address`   | `crypto_address`, `is_black_node`                                                          |
| IP 地址        | `ip`               | `ip`, `is_black_node`                                                                      |
| 设备           | `device`           | `device`, `is_black_node`                                                                  |
| 邮箱           | `email`            | `email`, `is_black_node`                                                                   |
| 银行卡         | `card`             | `card`, `is_black_node`                                                                    |
| 身份证         | `id_no`            | `id_no`, `is_black_node`                                                                   |
| 地址（物理）   | `address`          | `address`, `is_black_node`                                                                 |
| 手机号         | `phone`            | `phone`, `is_black_node`                                                                   |

## 2.边
| 边类型                 | 起始节点 → 目标节点                     | 说明                                           |
| :--------------------- | :-------------------------------------- | :--------------------------------------------- |
| `transfer`             | `crypto_address` → `crypto_address`       | 链上转账关系（资金流向）                       |
| `user_crypto_address`   | `user` → `crypto_address`                 | 用户持有加密地址                               |
| `user_ip`              | `user` → `ip`                            | 用户关联 IP                                    |
| `user_device`          | `user` → `device`                        | 用户使用设备                                   |
| `user_email`           | `user` → `email`                         | 用户绑定邮箱（本 Demo 未使用，但可扩展）       |
| `user_card`            | `user` → `card`                          | 用户绑定银行卡                                 |
| `user_id_no`           | `user` → `id_no`                         | 用户绑定身份证（本 Demo 未使用，但可扩展）     |
| `user_address`         | `user` → `address`                       | 用户关联物理地址                               |


# 数据导入


> 💡💡本 Demo 仅预置约百名用户及数千条关联关系用于体验，实际应用中，数据量可达亿级、百亿级甚至更多，具体可按需配置。


使用 `INSERT` 语句分别导入用户、加密地址、转账关系等数据。

以下为部分示例：


```
-- 导入用户节点
TABLE `t_user` { `is_black_node`,`user_id`,`name`,`age`,`education`,`zhangli`,`marital_status`,`gender`,`occupation`,`occupation_status` } = 
(false,"370049199707080851","张忠岚",18,"小学","12","未知","女","产品经理","自由职业"),
(false,"430026199806220831","欧阳玢瑾",15,"初中","27","未知","女","其他","其他"),
...
(false,"410111197709112345","王路",30,"博士","30","未婚","男","医生","在职")
USE `web3_risk_graph`
FOR re IN `t_user`
INSERT (@`user` {`user_id`: re.`user_id`, `name`: re.`name`, `age`: CAST(re.`age` AS INT64), `education`: re.`education`, `gender`: re.`gender`, `occupation`: re.`occupation`, `occupation_status`: re.`occupation_status`, `is_black_node`: CAST(re.`is_black_node` AS BOOLEAN),`zhangli`: re.`zhangli`,`marital_status`:re.`marital_status`})

-- 导入加密地址节点
TABLE `t_crypto_address` { `crypto_address`, `is_black_node` } = 
("0xaad0bfba1a0db3b31ab5dadf3a1d4441deeed4c4",false),
("0xe4fc4c48bd2e9b34520ff7886d42aad4bcabba51",false),
...
("0xd07aad9a3544aa5e02a2f0fce200ecd9fbffbcfb",true)
USE `web3_risk_graph`
FOR re IN `t_crypto_address`
INSERT (@`crypto_address` {`crypto_address`: re.`crypto_address`, `is_black_node`: CAST(re.`is_black_node` AS BOOLEAN)})
```

# 关键查询示例

## 1. 查询用户链上转出后的直接关联用户

**目的**：给定一个用户，找出其持有的加密地址转出的资金最终流向了哪些其他用户，识别资金上下游关系，关联越紧密则风险等级越高。


```
USE `web3_risk_graph`
MATCH path=(u@`user`{`user_id`:"450055199805200521"})-[@`user_crypto_address`]->(src@`crypto_address`)-[@`transfer`]->(dst@`crypto_address`)<-[@`user_crypto_address`]-(peer@`user`)
RETURN path
```
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-management/query-1.jpg)
**基于图的解释**：

* 这张图展示了从用户 `450055199805200521` 出发的完整资金流转路径：该用户持有的加密地址向另一个地址发起转账，而该接收地址又被其他用户所持有，从而形成了用户之间的间接资金关联。
* 存在同一接收地址被多个用户持有、多个来源地址向同一目标地址转账的路径，揭示了潜在的团伙共用地址、资金归集或洗钱风险。
* 如果路径中的任何地址或用户带有黑名单标记（is_black_node: true），则整条链的风险等级将显著升高，需重点排查。

## 2. 查询与黑名单用户共享 IP 的关联用户

**目的**：找出所有与某个黑名单用户共用 IP的其他用户，挖掘潜在关联账号。


```
USE `web3_risk_graph`
MATCH path=(blk@`user`{`user_id`:"220069199106190627"})-[@`user_ip`]->(ipnode@`ip`)<-[@`user_ip`]-(peer@`user`)
RETURN path
```
![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-management/query-2.jpg)

**基于图的解释**：黑名单用户 `220069199106190627` 与另外两个用户共同使用 15.731.65.74 IP ，可能为同一人/团伙作案，下一步需叠加更多维度以判断团伙风险。

## 3. 查询用户关联地址在 1-2 跳内触达的黑名单链上地址

**目的**：检测用户的加密地址是否通过多层转账与已知黑名单地址产生关联。


```
USE `web3_risk_graph`
MATCH path=(u@`user`{`user_id`:"450055199805200521"})-[@`user_crypto_address`]->(src@`crypto_address`)-[@`transfer`]->{1,2}(risk@`crypto_address`{`is_black_node`:true})
RETURN path
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-management/query-3.jpg)

**基于图的解释**：用户 `450055199805200521` 的链上地址与黑名单地址存在直接资金往来（1 跳关系），属于高风险关联用户。

## 4. 追踪用户链上资金多跳流向（1-3 跳）

目的：全面追踪用户资金的流转路径，识别最终汇聚地址或分散模式。


```
MATCH path=(a@`user`{`user_id`:"450055199805200521"})-[@`user_crypto_address`]->(src@`crypto_address`)-[@`transfer`]->{1,3}(dest@`crypto_address`)
RETURN path
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-management/query-4.jpg)

**基于图的解释**： 该资金流向拓扑图直观展示了 用户 `450055199805200521`（蓝色节点）名下的资产如何穿过复杂的链上网络进行扩散，绿色节点（关联地址）与黑色直线（转账）代表资金在 1 到 3 跳过程中的扩散与演变轨迹。
* 密集区域（图中上部）： 显示资金在第 1-2 跳时非常活跃，可能存在多地址归集或频繁的分散转账。
* 稀疏区域（图中下部）： 代表资金流向的末端（第 3 跳），这些地址可能是最终的提现点或冷钱包。

## 5. 链上地址多跳路径追踪


> 💡建议在 Demo 中，仅查询 5 跳内的路径


**目的**：针对一个可疑的链上地址，追踪其 5 跳内的资金流转路径。


```
USE `web3_risk_graph`
MATCH path=(src@`crypto_address`{`crypto_address`:"0xfdf3a4bfdacc3ac7e5ae831a9eb0feeb4b749fbf"})-[@`transfer`]->{5}(dest@`crypto_address`)
RETURN path LIMIT 10
```

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/web3-risk-management/query-5.jpg)

**基于图的解释**：对资金流向进行长程穿透追踪，展示连续经过 5 次转账移动到深层地址，用于排查那些试图通过多次转账掩盖资金来源的洗钱长链。

图之所以显得疏朗，是因为代码中设置了` LIMIT 10`，代表从该地址发起的成千上万条路径中，系统只随机或按顺序抽取了10 条典型的长程链路进行展示，避免了视觉过载，便于审计人员逐一剖析。

# 总结

通过图数据库将链上交易与链下身份信息融合，Web3 风险分析可以实现：

* 追踪资金流向，发现黑名单地址的间接关联；
* 识别共用 IP、设备等行为的团伙；
* 量化地址的风险等级；
* 支持监管合规与反洗钱调查。
* .......

通过原生关系建模与毫秒级多跳查询能力，NebulaGraph 能够精准追踪多层嵌套的资金流向、发现与黑名单地址的间接关联、识别共用 IP/设备等团伙行为，并支持监管合规与反洗钱调查。

在真实生产环境中，NebulaGraph 已支撑百亿级节点边的风控图谱，实现存储与算力的大幅优化，为 Web3 风险防控提供了可扩展、高性能、可解释的基础设施。


---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)




本 Demo 以 Web3 场景为例，建立包含用户、加密地址、转账关系以及链下信息的图模型，并通过多个查询示例展示如何追踪资金流向、发现与黑名单地址的关联。

一个 Demo 看懂 Web3 风控新范式：图技术追踪链上资金

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

```
📅 时间：4 月 18 日（周六）14:00 - 17:00 

📍 地点：杭州市余杭区奥克斯写字楼 22 层 

🚇 交通：地铁 5 号线创景路站（ B3 口），未来科技城 Manner Coffee 对面

 🤝 联合主办：NebulaGraph x StarRocks x TiDB x FastGPT x AskTable 

🎟️ 形式：线下沙龙 + 线上直播
```


随着 AI Agent 走向应用前台，RAG 成为主流架构，作为支撑底层的数据基础设施，正在经历一场深刻的范式转移。

从 NebulaGraph 图技术对本体论的完美映射，到 StarRocks 从“赋能 AI 应用”到“利用 AI 反向重塑”的双向演进；从 TiDB 在 AI 原生应用中的快速增长，到 AskTable 与 FastGPT 在智能体落地中的工程实践——**数据不再是静止的存储行列，而是在流动与计算中，成为了支撑 AI 理解与决策的核心基石。**

4 月 18 日，杭州，五大技术社区悉数集结，共同探讨关于下一代数据基础设施的真实思考：

* 看图技术如何成为本体论的完美映射，支撑 AI 对复杂关系的理解。

* 分析数据系统如何支持 AI，以及 Agent 如何反向优化数据库架构。

* 在 Agent 应用爆发的当下，探讨如何构建具备规模化增长能力的数据底座。

* 复盘从 NL2SQL 到易用智能体开发过程中的技术权衡与演进。

---

在这个数字化程度极高的时代

回归线下交流显得尤为珍贵

尽管模型可以推演逻辑

代码可以自动补全

但技术背后那些关于解决问题的直觉、思考与经验

依然深藏于开发者之间的真实互动中

**[戳此立即报名](https://luma.com/i1uld2oo)，面对面交流 AI + Data～**


# 活动议程

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ai-and-data-meetup-hangzhou/agenda.png)

---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)

杭州 AI+Data MeetUp｜五大技术社区邀你解锁 AI 时代的数据基础设施

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

---

> 本文简要介绍本体论的起源及应用，NebulaGraph 将在 4.18 举办「Data+AI」MeetUp，由 NebulaGraph 产品专家@方扬，带来主题为「以本体论重构数据：图技术驱动 AI 理解世界」的 topic，将结合本体论对 NebulaGraph 的 AI 能力进行深度分享。**[戳此报名，](https://luma.com/i1uld2oo)在杭州 Office 与你共话AI～**

2月 28 日，美国和以色列对伊朗发动突袭。开战 24 小时内，美军通过 Maven Smart System 识别并打击了超过 1000 个伊朗目标。在 2003 年伊拉克战争中，达成同样的战果需要 2000 名顶级情报分析师通宵达旦地从如山的报告中找线索。

Maven 系统由科技公司 Palantir 耗费 13 亿美元打造，将卫星、无人机、雷达、信号情报全线打通，分类、排序、推荐打击方案由 AI 完成。其CTO Sankar 坦言，这个高精尖武器其实就是一个哲学概念的工程化应用：本体论（Ontology）。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/1.webp)

与此同时，越来越多的 AI 产品发布会上，本体论也变成了常客。

为何一个研究了 2000 多年的哲学概念，突然成了解决 AI 幻觉和构建万物互联世界的救命稻草？

# 一、什么是本体论？

##（一）哲学的终极追问

本体论一词源于希腊语 onto（存在）和 logia（学问）。在亚里士多德看来，这是“第一哲学”。它不关心具体的物理定律，而是关心：世界上到底存在什么？这些存在的东西，彼此之间有什么关系？

想象一个简单的场景：你的桌子上有一个苹果。

* 物理学关心它的质量、加速度。

* 生物学关心它的细胞、品种。

* 本体论则关心：这个“苹果”是一个实体（Entity），它属于“水果”这个类（type），它具有“红色”这个属性（Property）。如果我咬了一口，它还是原来的那个“实体”吗？

## （二）计算机科学的翻译官

到了 20 世纪 90 年代，人工智能专家 Tom Gruber 给出了一个著名的定义：本体是对概念化说明的显式规范。

翻译成通俗易懂的人话就是：本体论是给机器的一份世界说明书。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/2.webp)

机器不像人类，它天生没有常识。你告诉机器“苹果”，它可能认为是一串二进制代码。本体论的作用，就是构建一套结构化的知识框架，告诉机器：

* 对象（Objects）：定义“是什么”。可理解为说明书里的“名词大类”。它划定了世界由哪些基本对象组成。

> 例子：什么是“人”、什么是“公司”、什么是“城市”。

* 实体实例（Entity instance）：定义“哪一个”。这是大类下的具体对象。有了类型，机器才能识别出具体的个体。

> 例子：在“人”类型下，具体指“张三”；在“城市”类型下，具体指“杭州”。

* 属性（Property）：定义“长什么样”。这是每一个实体的特征描述，用来刻画细节。

> 例子：“张三”的年龄是 30 岁；“杭州”的人口是 1200 万；“公司”的注册资本是 1 亿元。

* 链接（Links）：定义“怎么关联”。明确实体之间的联系方式，如“属于”、“导致”、“包含”，它把孤立的点连成网。

> 例子：“张三”在“NebulaGraph”上班；“NebulaGraph”的总部位于“杭州”。

* 约束（Constraints）：定义“规则”。这是逻辑的边界，防止机器产生低级错误。

> 例子：一般情况下，一个人不能同时在两个互斥的地点上班（你不能同时出现在杭州 office ，又在美国 office）；或者“一家公司的成立日期必须早于它的注销日期”。

# 二、为什么本体论再次出圈？

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/3.webp)

本体论可以为语义异构、知识不可复用、无法自动推理、语义网络理解、领域知识建模等问题提供解决思路，在 AI 时代，其核心价值可概括为以下两点：

## （一）解决 AI 幻觉问题

比如，目前的生成式 AI（如 ChatGPT）本质上是概率预测机器。它通过上万亿个词汇的排列组合，猜出下一个字该说什么。

尴尬就在这里：概率不等于逻辑。它可能计算出“林黛玉倒拔垂杨柳”在统计学上是通顺的，但它不理解“林黛玉”这个实体的属性（柔弱）与“倒拔垂杨柳”这个动作（力量型）在本体论逻辑上是冲突的。

引入本体论后，AI 就有了一本逻辑指南。在回答问题前，它会先检索底层的知识图谱，确认实体之间的逻辑关系，从而极大地降低 AI 胡说八道的概率。

再如，传统 RAG 通过向量相似度，只做到了语义相关性检索，但本体论引入了一种确定性逻辑。

Palantir 的 Maven 系统敢应用于实战打击，是因为它在 AI 推荐方案后，会通过本体层进行逻辑验证，如：某个被标记的目标在物理规则上是否可能在 5 分钟内出现在两个地点？这种本体约束是 AI 走向高可靠性的必经之路。

## （二）解决数据巴别塔难题

在《圣经》中记载了这样一个故事：人类曾想联合起来修建一座通往天堂的巴别塔，但上帝让人类突然说起了不同的语言，彼此无法沟通，最终计划失败，人群四散。巴别塔的故事，形象地展现了因缺乏通用语言或标准而导致的系统无法整合的状态。‌

比如，在大型企业中，财务部门有一套数据库，销售部门有一套，研发部门又有一套。同样是“客户”这个词，财务看的是“纳税人识别号”，销售看的是“联系人电话”。

再比如，在图数据库领域，在 ISO-GQL（国际标准图查询语言）未发布之前，每家厂商有各自的图查询语言，Neo4j 是 Cypher，NebulaGraph 是 nGQL，Apache TinkerPop 框架下的图遍历语言则是 Gremlin ，导致用户的学习成本和迁移成本居高不下。

这些现象正是数据孤岛的体现。而本体论提供了一套共用语言，使不同来源的数据能够基于统一的逻辑模型实现互通与理解。

# 三、本体论的实战工具：NebulaGraph

理论再美，也需要强大的技术底座来实现。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/4.webp)

本体论强调的是“关系”，而图数据库（Graph Database）天生就是为了“关系”而生的，是本体论的完美物理映射，让本体可计算、可推理、可进化。

## （一）NebulaGraph 介绍

作为开源图数据库的领军者，NebulaGraph 的出现，真正让大规模本体模型的存储和实时查询成为了可能。

### 1. 天然契合本体结构


在 NebulaGraph 中，数据由点（Vertex）和边（Edge）组成。点对应本体论中的“实体”，边对应“关系”。这种结构与人类大脑思考问题的方式、与本体论的建模逻辑高度统一。

### 2. 动态 Schema

属性灵活，可为顶点动态添加属性，非破坏性更新完美适配知识图谱中“概念”的增量演进特性；类型即约束，虽设计灵活，但其强类型的边设计，确保了关系的语义严谨性，避免关系泛滥导致的本体论失真。

### 3. 逻辑一致性

NebulaGraph 5.x 是首个原生支持 ISO-GQL 的图数据库，这不仅是查询语言的统一，更是本体论中“关系语义”的标准化。

### 4. 极致的关联查询性能

利用 NebulaGraph，可以在毫秒级完成千亿数据集的多条查询（即“朋友的朋友的朋友...”）的查询，这是传统数据库无法企及的。

### 5. 赋能上下文图谱

NebulaGraph 基于本体论，通过构建企业级的上下文图谱（Context Graph），作为大模型的“外挂大脑”，让 AI 理解，“过去发生了什么”，以及“为什么允许发生”，真正解决传统向量 RAG 只做检索，无法形成关键认知的难题。

## （二）NebulaGraph 信贷反欺诈 Demo

以信贷反欺诈为场景，用 NebulaGraph 建立包含用户、身份证、手机号、设备、IP 等实体的风险关联网络，帮助风控人员快速评估金融信贷欺诈风险。

### 1. 设计图模型

在 NebulaGraph 中，点（Vertex）用来保存实体对象，边（Edge）用来连接点，表示两个点之间的关系或行为。这与本体论的基本逻辑完全一致。

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/5.webp)

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/6.webp)

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/7.webp)

### 2. 创建图空间并定义点、边

先创建图类型与图空间，并执行以下语句定义节点、边结构及属性：


```
CREATE GRAPH TYPE IF NOT EXISTS `financial_risk_type` AS {
  NODE TYPE `user` (LABEL `user`{`user_id` STRING NOT NULL, `name` STRING DEFAULT NULL, `is_blacklist` BOOL DEFAULT NULL, `is_overdue` BOOL DEFAULT NULL, `credit_limit_increase_times` INT64 DEFAULT NULL,  `is_credited` BOOL DEFAULT NULL, PRIMARY KEY (`user_id`)}),
  NODE TYPE `id_card` (LABEL `id_card`{`card_no` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`card_no`)}),
  NODE TYPE `phone` (LABEL `phone`{`phone_no` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`phone_no`)}),
  NODE TYPE `google_account` (LABEL `google_account`{`gaid` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`gaid`)}),
  NODE TYPE `email` (LABEL `email`{`email_addr` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`email_addr`)}),
  NODE TYPE `gps` (LABEL `gps`{`gps_coord` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`gps_coord`)}),
  NODE TYPE `device_id` (LABEL `device_id`{`device_no` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`device_no`)}),
  NODE TYPE `ewallet` (LABEL `ewallet`{`wallet_no` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`wallet_no`)}),
  NODE TYPE `bank_card` (LABEL `bank_card`{`bank_no` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`bank_no`)}),
  NODE TYPE `ip` (LABEL `ip`{`ip_addr` STRING NOT NULL, `is_black` BOOL DEFAULT NULL, PRIMARY KEY (`ip_addr`)}),
  EDGE TYPE `bind_idcard` (`user`)-[LABEL `bind_idcard`{}]->(`id_card`),
  EDGE TYPE `bind_phone` (`user`)-[LABEL `bind_phone`{}]->(`phone`),
  EDGE TYPE `bind_google` (`user`)-[LABEL `bind_google`{}]->(`google_account`),
  EDGE TYPE `bind_email` (`user`)-[LABEL `bind_email`{}]->(`email`),
  EDGE TYPE `bind_gps` (`user`)-[LABEL `bind_gps`{}]->(`gps`),
  EDGE TYPE `bind_device` (`user`)-[LABEL `bind_device`{}]->(`device_id`),
  EDGE TYPE `bind_ewallet` (`user`)-[LABEL `bind_ewallet`{}]->(`ewallet`),
  EDGE TYPE `bind_ip` (`user`)-[LABEL `bind_ewallet`{}]->(`ip`),
  EDGE TYPE `bind_bankcard` (`user`)-[LABEL `bind_bankcard`{}]->(`bank_card`)
}



"""
CREATE GRAPH `financial_risk_graph` :: `financial_risk_type`
"""
```


### 3. 导入数据

使用 INSERT 语句分别导入用户、证件、设备、账户等关联数据。


```
-- 导入用户节点
TABLE `t` { `user_id`, `name`, `is_blacklist`, `is_overdue`, `credit_limit_increase_times`, `is_credited` } =
("u001", "张x", "FALSE", "TRUE", "2", "TRUE"),
("u002", "李x", "TRUE", "TRUE", "5", "FALSE"),
...
("u100", "吴x", "FALSE", "TRUE", "2", "FALSE")
USE `financial_risk_graph`
FOR re IN `t`
INSERT (@`user` {`user_id`: re.`user_id`, `name`: re.`name`, `is_blacklist`: CAST(re.`is_blacklist` AS BOOLEAN), `is_overdue`: CAST(re.`is_overdue` AS BOOLEAN), `credit_limit_increase_times`: CAST(re.`credit_limit_increase_times` AS INT), `is_credited`: CAST(re.`is_credited` AS BOOLEAN)})

-- 导入身份证绑定关系
TABLE `t` { `user_id`, `card_no` } =
-- 前20个用户每人绑定1-3个身份证，制造关联
("u001", "110101xxxx01010xxx"),
("u002", "110101xxxx01020xxx"),
("u002", "110101xxxx01030xxx"), -- u002绑定2个身份证
...
("u014", "110101xxxx01050xxx") -- u014共享u004的第一个身份证
USE `financial_risk_graph`
FOR re IN `t`
MATCH (v1@`user`{`user_id`: re.`user_id`}), (v2@`id_card`{`card_no`: re.`card_no`})
INSERT (v1)-[@`bind_idcard` {}]->(v2)
"""
MATCH (u:user {user_id: 'u001'}), (c:id_card {card_no: '110101198001010011'})
INSERT (u)-[:bind_idcard {}]->(c);
```


![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/8.webp)

### 4. 进行查询

查询用户 3 跳内所有关联路径，以全面掌握目标用户的关联网络范围，发现潜在的风险传导路径。


```
use financial_risk_graph match p=(n@user{user_id:"u067"})-[]-{1,3}(e) return p
```


![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/ontology-and-graph/9.webp)

通过可视化界面，清晰展示出从用户 u067 出发，经过 1 到 3 跳能到达的所有节点及路径。

> 💡该 Demo 已在 NebulaGraph 官网上线，欢迎体验
> https://www.nebula-graph.com.cn/posts/financial-risk-management

# 四、本体论如何改变我们的未来？

## （一）Web3 链上分析：穿透匿名地址的马甲

在去中心化金融世界中，攻击者常通过多个看似独立的匿名地址进行洗钱或拉高出货。通过本体论建模，我们可以定义“同一实体操控”、“资金流向路径”等逻辑关系，将这些分散地址背后的真实关联网络一网打尽，让链上犯罪无所遁形。

##（二）工业 4.0：数字孪生的灵魂

在波音飞机的制造中，几百万个零件之间存在着复杂的逻辑依赖。本体论可以定义零件之间的父子关系、物料清单（BOM）关系。当一个螺丝的设计发生变更，系统能通过图数据库立刻推演出这会影响到哪些传感器，甚至哪个航线的安全性。

## （三）个性化医疗：精准到基因的关系网

每个人的基因、病史、用药、生活习惯都是碎片化的。通过本体论构建人体健康图谱，医生（或 AI 医生）可以发现：由于你带有某项基因特征，某种药物对你可能产生的副作用。这种深度的因果关联，只有基于本体论的图谱才能揭示。

# 五、结语：重构世界的秩序

本体论从两千年前的哲学辩论，演变成今天驱动 AI 的基石，说明了一个深刻的道理：世界的本质不在于孤立的数据，而在于数据之间的连接。

在这个信息爆炸、真假难辨的时代，谁能更清晰地梳理出“世界存在的方式”，谁就掌握了通往高阶智能的钥匙。

无论你是技术开发者、企业管理者，还是对世界充满好奇的观察者，拥抱本体论，其实就是拥抱一个更具逻辑、更加透明的未来。

---

交流图数据库技术？**加入 Nebula 交流群**请先填写下[「你的 Nebula 名片」](https://wj.qq.com/s2/8321168/8e2f/)，Nebula 小助手会拉你进群~~

![](https://www-cdn.nebula-graph.com.cn/nebula-website-5.0/share/qrcode-wechat.png)