![](https://pic1.zhimg.com/80/v2-b62ebd2301b9bc3d8cc24427f0a9be49_1440w.jpg?source=d16d100b)


# **RAG 的历史**

云风作为中国程序员圈的先驱，曾在一篇文章中写道：“**无论我们想学什么，都应该从学习它的历史开始**。”这篇文章的许多观点都对我影响深远。今天，我们就从 RAG 的历史开始聊起。

![](https://pic1.zhimg.com/80/v2-6c2b68cfc55015b2189dc7f77d767958_1440w.jpg?source=d16d100b)


在传统大模型中，就是一个 model: 我问一个问题，经过该大模型，给出一个回答。那 RAG 则是我的问题会经历一个向量数据库，根据检索到的信息给出答案。向量数据库的广泛使用已经很久了，淘宝搜索、以图搜图或者谷歌、百度搜索，背后都是它在发挥关键作用。

**具体而言，RAG（Retrieval Augmented Generation）是一种结合了检索和生成的范式。它通过检索相关参考材料，然后从检索到的信息中进行上下文学习，以生成回答**。它能够通过检索相关文档来增强生成模型的能力，从而在问答系统中提供更准确和丰富的回答。

![](https://pica.zhimg.com/80/v2-aa43fe534e564dc18bf83203bd0e429a_1440w.jpg?source=d16d100b)


RAG 的历史可以追溯到 2020 年，那时还没有 GPT-3.5，人们普遍认为 GPT 只是一个玩具，因为它非常昂贵。在这个时期，Facebook 的 AI Research 团队发表了一篇论文，标志着 RAG 的诞生。这篇论文使用的是 GPT-2 模型，研究人员发现，将大型语言模型与自然语言处理相结合，可以产生非常好的效果。

![](https://picx.zhimg.com/80/v2-1a7f1dd15b1152379758a5e643b496d8_1440w.jpg?source=d16d100b)


# **GraphRAG 的历史**

2022 年 3 月，OpenAI 公布了自己的 API, 这使得大家开始思考如何利用这个 API 来实现更多的功能，这时向量数据库的潜力被重新发现。大家意识到，通过向量数据库或者在传统数据库中加入向量类型，可以实现 RAG 的功能。

例如，我有一个文档，先靠 OpenAI 或者其他大模型，转换成向量，储存在向量数据库里。这时我提出问题，大模型将其转换为向量，在向量数据库中查找最匹配的段落，组织语言后生成最终答案。通过这样的方式，有效解决大模型在专业领域知识不足的问题。

随着向量数据库的兴起，图数据库公司也开始思考如何利用自己的技术来实现类似 RAG 的功能。**NebulaGraph GenAI Team Leader 古思为提出了将图数据库与 RAG 结合的想法，并向 LlamaIndex提了第一个PR，将 KG-RAG 转变为 GraphRAG**. 这个转变意味着人们开始探索使用图模型来增强 RAG 的功能，利用图数据库的搜索强度可能比传统的向量更好，能够起到一定的 RAG 作用。

![](https://picx.zhimg.com/80/v2-9610c8e2a3d959e880909a324b4aad0c_1440w.jpg?source=d16d100b)


微软在 2024 年 4 月份发布了 GraphRAG 的第一篇论文，市场上很多项目开始从 RAG 向 GraphRAG 迁移。这一转变的原因是 RAG 存在一些问题，而 GraphRAG 在某些领域存在突出优势。

![](https://pica.zhimg.com/80/v2-f434d9c8728c4683a253fad396ebc217_1440w.jpg?source=d16d100b)


# **RAG VS GraphRAG**

刚我们已经提到，在处理查询时，RAG 会利用大型语言模型，将查询转换为向量形式，然后在向量数据库中检索相关信息，并通过上下文学习生成回答。市场上对这一过程进行了多种优化，例如 rerank, 它使用大型语言模型对检索结果进行再次排序，以提高回答的相关性。

![](https://pic1.zhimg.com/80/v2-d24e2d428156bddb99738daf4d487935_1440w.jpg?source=d16d100b)


然而，RAG 在处理细粒度检索和全局上下文搜索时存在局限性，如知识碎片化和上下文丢失问题。**例如，在《红楼梦》中搜索林黛玉「哭泣」的原因可以找到结果，但搜索她「不笑」则无法找到答案，因为书中并没有提供相关信息**。这些问题限制了 RAG 在企业级应用中的准确性和可靠性，因为企业需要的是接近 100% 的准确率，而 RAG 往往只能达到 95% 的准确率，这在商业环境中是不够的。

![](https://pic1.zhimg.com/80/v2-12f1365629de7adc1e1bb838ce63ddf5_1440w.jpg?source=d16d100b)

相比之下，**GraphRAG 不依赖于向量数据库，而是利用图数据库来存储和检索信息**。它通过大型语言模型抽取文档中的主要关系和实体，并将它们转换为图结构存储在图数据库中。**这种方法不仅提高了检索的强度，还能够更好地处理全局上下文搜索和领域知识集成的问题**。

# **GraphRAG 的能力总结**

![](https://pica.zhimg.com/80/v2-e7ec9a2bd6d33b3e52c32bb326ba4a8a_1440w.jpg?source=d16d100b)


![](https://pica.zhimg.com/80/v2-bd9b3b5ec83f57d8bc884a9f0784778f_1440w.jpg?source=d16d100b)

GraphRAG 通过图索引、文本到查询的转换以及链式探索（Chain of Exploration）来增强模型的探索能力，类似于传统 RAG 中的思考量，但增加了探索量。**这种基于图的方法可以利用图数据库找到真正的重组关系，实现更复杂的 AI 编排工具，满足市场上对高精度和高可靠性的需求**。

# **何时使用GraphRAG**

何时推荐使用 GraphRAG呢？我们可以考虑以下几种情况。

![](https://pica.zhimg.com/80/v2-5dedae1e0d6129784ba62770d85d4e7e_1440w.jpg?source=d16d100b)


首先，当**面对高度离散的数据时**。例如，企业可能拥有大量分散的文档和多年的杂乱数据库，GraphRAG 能够帮助整合这些信息，构建起企业知识图谱，从而实现更深层次的数据理解和利用。

其次，当**需要对全局信息进行理解**时。以《红楼梦》为例，如果我们想要对书中的人物关系和情节有全面的理解，GraphRAG 能够提供全局的视角，帮助我们捕捉到更细微的联系和深层次的内涵。

此外，**领域知识的集成**是 GraphRAG 的另一个重要应用场景。在职业招聘领域，GraphRAG 可以帮助匹配求职者的技能、工作经验与职位要求，从而提高招聘效率；在医学领域，GraphRAG 能够通过分析个体的特定特征来预测疾病，这对于精准医疗和个性化治疗方案的制定具有重要意义。

# **GraphRAG 企业知识管理与应用构建平台**

NebulaGraph 已经在实际项目中应用了 GraphRAG.

![](https://picx.zhimg.com/80/v2-6ed4433c5045ad70bef8305752fca795_1440w.jpg?source=d16d100b)


NebulaGraph 利用 GraphRAG 做 index, 对企业内部文档进行问答集的构建，旨在为企业提供高效、智能且易用的知识解决方案。通过引入知识级概念和 Meta Agent 概念，该平台显著降低了员工的使用门槛，使他们能够通过聊天式交互轻松构建知识应用，实现低心智负担的操作。

# **GraphRAG 的缺点**

在探讨 GraphRAG 技术时，我们不得不提到它的一个主要缺点——成本。**GraphRAG 的高成本主要源于其初始化阶段**，特别是当使用像 GPT-4 这样的先进模型来构建索引并存储在图数据库中时。

**然而这种成本在技术发展的不同阶段有所变化**。正如我们刚开始提到的，GPT-3 曾因其高昂的价格而让许多用户望而却步，然而随着 GPT-3.5 的推出，成本有所下降。 GPT-4 问世后，人们只会在发布后的一段时间内觉得过于昂贵。随着时间的推移，成本将进一步降低，更多经济实惠甚至免费的模型会陆续出现。

![](https://picx.zhimg.com/80/v2-da3ba0351bf180d08187e3eba0cacc26_1440w.jpg?source=d16d100b)


**尽管 GraphRAG 的初期投入可能较大，但这种成本在很大程度上是一次性的：贵，但只贵一次**。对于拥有大量文档和数据的企业来说，一旦构建了 GraphRAG 模型并将其存储在数据库中，这些数据和模型就成为了企业的长期资产。随着时间的推移，这些资产可以被反复利用，从而分摊了初始成本。此外，GraphRAG 带来的效率提升和知识管理优势，使得这种投资在长期看来是合理的。

因此，尽管 GraphRAG 的启动成本较高，但它为企业提供了一种强大的工具，以实现更智能的数据管理和决策支持，这在当今的数据驱动型经济中至关重要。


——————————分割线——————————————————————

🙋活动推荐

诚邀您参加【NebulaGraph x Airwallex 图数据库与风控】上海站，一场聚焦于图数据库与 GraphRAG 在风控领域创新应用的 nMeetup，[点此报名](https://9753492656408.huodongxing.com/event/3799122350000)

![](https://picx.zhimg.com/80/v2-515cae27af412c84eb52414701bd91e8_1440w.jpg?source=d16d100b)



🔍相关阅读

[首个提出 GraphRAG 的团队在做什么？](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516100&idx=1&sn=aaacb7b5fcb68acdb4a12d1a98af4cfb&scene=21#wechat_redirect)

[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)

[NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)

[GraphRAG vs DeepSearch？GraphRAG 提出者给你答案](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515612&idx=1&sn=e5b3f13debc62fcf53119e55ce2b6b71&scene=21#wechat_redirect)

[NebulaGraph 的 GraphRAG 进展、实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247514593&idx=1&sn=bed17f080e374d9cb957d14f17a01062&scene=21#wechat_redirect)

[VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect)

[基于 NebulaGraph ，构建属于你的 Graph RAG](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511536&idx=1&sn=f73ada9ea4c97d23acaed65c60a06034&scene=21#wechat_redirect)

有哪些炙手可热的场景需要 GraphRAG 实现？

> “NebulaGraph 作为一款云原生图数据库，属于传统 Infra, 但我们逐渐意识到，AI 的发展将彻底改变数据库的应用场景和技术架构。于是，我们团队开始探索图数据库在 AI 领域的价值。”本文整理自 NebulaGraph @PsiACE 在 KCD Beijing 上的演讲， 与大家分享 NebulaGraph GenAI Team 的工作与进展。

![](https://picx.zhimg.com/80/v2-c00d5a1549bde4fe3e2a1730e391ceaa_1440w.jpg?source=d16d100b)



> 本文首发于[「NebulaGraph 技术社区」](https://mp.weixin.qq.com/s/346RoWfDa9zfKO8jmtGEgg)

# **Part 1 背景趋势**

## **01 传统 RAG 方法的痛点**

![](https://picx.zhimg.com/80/v2-3a5ff55238d81ca779830cda0714ce1b_1440w.jpg?source=d16d100b)



传统 RAG 方法在实际应用中面临诸多挑战：

* **细粒度知识检索能力不足**：举个例子，做 chunk 分块是一个很强的对信息浓度的假设，无论是用语义的方式还是固定大小来分块，一旦确定了这个分块，其实对知识被召回的数据的信息浓度做了一个很强的假设，有的时候就存在一些重要而细粒度的分散的信息没办法进行召回，质量就会有些损失。

* **全局上下文关联缺失**：索引的知识块中，核心知识点和其他知识点的关联，有些知识有局部性，例如 A 和 B 在一个块关联，B 和 C 在一个块关联，C 和 D 在一个块关联，如果某些任务依赖于全局的上下文，但任务中又只提及 A 和 D，这中间的关联在做 chunk 的 RAG 索引一般是丢失的，无法获取全局上下文的关联。

* **向量相似性与相关性错配**：传统 RAG 的索引方法追求相似，但实际上相似并不等于相关。例如，检索保温杯与保温大棚相关文章，在向量数据库中大概率会变成两个非常相似的向量，从而使得生活场景与农业场景产生错配。

* **全局性问题及推理型问题回答能力不足**：传统 RAG 在处理全局宏观性问题和需要推理的问题时，往往只能给出片面的答案，缺乏深度分析和逻辑推理。如果将树比喻成知识，整片森林（所有的树）代表全部知识，如果问这个森林是什么形状的，很明显这是一个宏观的问题，当只召回到一部分的树是无法回答这个问题的。

# **02 GraphRAG 的优势**

NebulaGraph 专注于图技术，已进行了多年的开源分布式图数据库的研发。**在 RAG 技术还未被称为 RAG，而是上下文学习方法的时候，我们就意识到以图的方式处理知识会对解决这些问题有很大帮助。因此，NebulaGraph 率先提出了 GraphRAG 的方法，并于 2023 年 8 月与 LlamaIndex 联合发布 GraphRAG**.

GraphRAG 的优势显著：

![](https://picx.zhimg.com/80/v2-29bc1580eb8ccd4f71abfa9437037cd4_1440w.jpg?source=d16d100b)



* **细粒度的切分实体和关系**：通过知识图谱技术，将多模态文本中的实体和关系进行细粒度的拆分，保留高度凝练的知识细节。例如，在讨论“苹果”时，能够准确识别是指水果还是苹果手机，并明确它们之间的关系。

* **保留事物间的关联关系**：在知识图谱中明确事物之间的关联，提升可解释性。比如，在工业排障场景中，通过图数据库可以清晰地展示故障之间的关联关系，高效地追根溯源，帮助用户快速定位问题。

* **图查询和图算法得到相关上下文**：利用图查询和图算法，将边和实体对应的节点都提取出来，精准获取相关上下文信息，使回答更全面、更符合预期。

## **03 云原生图数据库 NebulaGraph 的价值**

* **完整的 Infra 基座**

![](https://picx.zhimg.com/80/v2-cf72e141be2f5fc8d94a1945ca861edf_1440w.jpg?source=d16d100b)


在过去几个月里，GraphRAG 技术作为 RAG 下 state of art 的范式，得到了充分的关注，可以看到包括微软、Meta、Google都做了一些不错的工作。不过大多数实现仅仅是借用图的形式表示而并没有建立在图数据库之上，**但可以预想，随着数据量的增大，图数据库的价值在 GenAI 时代将会更加重要。因为它是一个完整的 Infra 基座，对各种运行环境和云厂商具有良好的兼容性，能够与 K8S 等技术深度集成，原有日志、可视化等工具也可完整接入，无需额外定制化开发和运维保障，这使得企业可以充分利用现有的技术资源去使用 GraphRAG**.

* **大规模复杂场景检验**

![](https://pica.zhimg.com/80/v2-02bc652d3f3e912c8d448a54ae2f0b6f_1440w.jpg?source=d16d100b)


某知名海外社交平台的好友推荐、广告推荐等场景，充分证明了 NebulaGraph 在高实时性、高精度需求场景下的高性能。**该社交平台的用户关系超过 100 亿，单个最大规模图谱超过 400 亿点，1000 亿边，但仅需 2 个工程师就可以维护所有与 NebulaGraph 相关的产品，有效降低运维成本**。


# **Part 2 技术路线**

## **01 GraphRAG-Agentic Workflow**

以往大家 RAG 的理解是检索增强生成，但我们对 RAG 的理解分为以下三个部分：‍

![](https://pic1.zhimg.com/80/v2-956e63775ded66938b20926a11048091_1440w.jpg?source=d16d100b)


* Retrieval（检索）：检索大量数据，补充数据实时性，将多模态数据转化为可检索形式。

* Agent（智能体）：可定义工具集，调用各种方法和生态产品。比如，在处理复杂问题时，Agent 可以调用不同的工具和算法，进行多轮推理和分析。

* Ground Truth（真实情况）：Ground Truth 的建设是通过 "专家经验 Human in Loop + 机器智能" 的协同机制，构建可复用、可进化的知识体系，实现知识与真实世界的同构映射，确保不同业务场景、不同阶段的应用均可基于相应的事实基准开展工作。

## **02 GraphRAG-ParseCraft**

为什么不是完全依赖现有工具去做这个事情，而是需要自己去研发一些组件呢？因为在整个解析的流程中可能涉及到一些预处理和后处理的工作，而且对于特定的内容需要有足够的能力来干涉解析过程，确保生成符合预期的结果。比如在我们的场景中可能会涉及的部分包括：

![](https://picx.zhimg.com/80/v2-ac8ac40e373a3c11f21dd7975cbf57ef_1440w.jpg?source=d16d100b)


* 特定领域的内容的理解和表征：比如故障树分析，这个场景拿到的是一个图片，但是图片上的事件存在关联关系，我们需要把它转换到图上面，并标识这些关键路径和事件。

* 通用场景下的关键结构的转换：比如文章的段落、目录，天生就是具有结构化、和领域化的内容，比如一个章节内大概率是围绕相关主题展开的，在解析过程中需要留存；再比如布局之间的关联，可能影响上下文，如果要精细地做一些事情，可能不得不将这些信息保存下来。

ParseCraft 注重集成性和可定制性，作为接入层，除了定制基于视觉语言模型的解决方案外，还能融合文档解析、布局识别等方案，只需实现少数几个 API ，就可以获得格式转换和可观测性的能力增强。预计今年上半年开源。例如，在处理复杂的文档和表格时，ParseCraft 可以将其转化为大模型易于理解的格式，提高处理效率。

## **03 GraphRAG-Deep Seach**

![](https://pic1.zhimg.com/80/v2-45829c20e348f6b2bf678f8c4fc25ba9_1440w.jpg?source=d16d100b)


我们目前的 GraphRAG 实现本身也是符合 Agentic 范式的，结合推理模型，如 DeepSeek R1 / Qwen QwQ 等，可以对任务进行预先规划，并驱动在 Workflow 中进行多轮探索和评估，与 Deep Search 充分兼容，能够节约开销、增强效果。

## **04 GraphRAG-All in MCP**

![](https://pica.zhimg.com/80/v2-242c370a7b4678147c90e5abe4bf3126_1440w.jpg?source=d16d100b)


我们团队积极参与 MCP 相关工作，输出 LlamaIndex 社区第一个 MCP 工具支持方案，落地 Local MCP 范式，并且进入官方 repo 进行集成。此外，我们实现内部工具集定义落地了 Local MCP 范式，在复用 MCP 相关接口标准的同时，改用函数调用的模式，为内部工具调用和后续开放 MCP 服务能力提供基础。实现函数调用与接口复用。例如，在处理复杂的图查询时，MCP 可以提供强大的支持，提高查询效率和准确性。（MCP 集成至 LlamaIndex 完整教程，[详情请查看](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)🔍）

## **05 Graph Insight-Text to GQL**

![](https://picx.zhimg.com/80/v2-4ddcb4c2a9fb3fcbacec36eac802bdc6_1440w.jpg?source=d16d100b)


早期数据库领域和大模型结合的一个重要方向就是 Text2SQL ，对于图数据库，对应的就是 Text2Cypher，当然，随着 ISO GQL 标准的确立，现在 Text2GQL 也成为了关键的一环。NebulaGraph 在这个方向上也做了一些努力，沉淀出了一套 Graph Insight 的方法。

一方面，利用基础的 Text2GQL 方法，用户可以以问答形式在已有图谱上进行简单的图查询和图计算。另一方面，通过利用内置的一些算子模版，可以将复杂的图查询转化为填空题，降低大模型编写复杂查询语句和探索图的难度。通过提示词工程和 ReAct 等方式，Agent 可以利用上下文对生成的 GQL 语句进行自校准，帮助写出更加准确和符合业务目标的 GQL 语句。

当然，用户也可以在这个基础上将过去积累的图算法作为模版封装，充分利用过去业务场景积累的经验，释放图上的价值。

## **06 Graph Insight- Agentic & CoE**

![](https://picx.zhimg.com/80/v2-21f3b3e505539c5c3040a084f6bf955c_1440w.jpg?source=d16d100b)



Graph Insight 我们聚集 Agentic 范式图探索能力与 Chain of Exploration（CoE），构建了一套高效的图知识处理与分析体系。不仅能深度挖掘图谱内的知识，还能以自然融合的方式整合多源数据 —— 将图探索作为 Agent 调用的工具，无缝对接互联网知识等外部数据源，打破单一数据边界，实现知识的跨域协同。

## **07 Graph Insight - MCP**

![](https://picx.zhimg.com/80/v2-5e25407eb4e62a78892f18a3dc947e5e_1440w.jpg?source=d16d100b)


针对热门的 MCP方向，团队构建了 NebulaGraph MCP Server（已正式开源，[详情请查看](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)🔍）。该服务不仅为大模型提供查询接口，支持直接调用执行图数据查询，还预封装了实用的算子模板，包括邻居发现、路径发现等核心功能，简化图数据操作流程。

# **Part 3 应用案例**

## **01 产品 - 图 AI 工具链**

![](https://pica.zhimg.com/80/v2-1aec0efb7dfa7924fbcc195e8ad50b2b_1440w.jpg?source=d16d100b)


我们面向开发者提供了一套完整的工具链，包括对向量、全文索引等能力做了支持，方便企业自行开发 AI 应用，核心功能包括图谱构建、图谱推理、模型微调等。

## **02 产品 – 图 AI 应用平台**

![](https://pica.zhimg.com/80/v2-5c31c93871d81ef222752b9f21d4d321_1440w.jpg?source=d16d100b)



面向终端用户，开箱即用，帮助用户以对话方式快速构建 AI 应用，如智能客服机器人、故障排查助手、研报生成机器人等，具有智能文档处理、零代码、零工作流、零提示词设计等特点。用户可以通过简单的对话方式，快速构建一个智能客服机器人，提高客户服务效率。

## **03 工业解决方案‍**

![](https://pic1.zhimg.com/80/v2-7d5624c96495ed72fff5e8d1b7f8ba36_1440w.jpg?source=d16d100b)



NebulaGraph 与行业头部企业协作，构建面向工业协同研发系统的 Graph + AI 解决方案，落地行业首个生成式人工智能驱动的实际应用场景，基于知识图数据库及智能问答系统进行数据交互，荣获沙丘社区 2024 最佳案例 15 强。

此外，在复杂排障知识图谱的构建和探索上，我们也积累了一定经验，充分运用大模型赋能排障系统，在一些场景下拥有超过 40 万有效节点。

## **04 金融行业解决方案**

![](https://picx.zhimg.com/80/v2-f9dc87dec0dcc73ccc7f6981aa6817f1_1440w.jpg?source=d16d100b)



利用基于大模型的知识图谱自动抽取和构建技术，和在金融领域深耕积累的经验洞见，NebulaGraph 和合作伙伴共同构建和发布基于 GraphRAG 和 Agentic Workflow 的行业解决方案，共同推动 Graph + AI 技术在金融风控等领域的发展。

# **结语**

NebulaGraph 在 GenAI 领域的探索和实践，不仅解决了传统 RAG 方法的痛点，还通过云原生图数据库的价值，为各行业提供了强大的技术支持。未来，NebulaGraph 将继续深化技术路线，拓展应用领域，推动 GenAI 技术的不断发展和创新。







————————————分割线————————————————

🙋活动推荐

诚邀您参加【NebulaGraph x Airwallex 图数据库与风控】上海站，一场聚焦于图数据库与 GraphRAG 在风控领域创新应用的 nMeetup，[点此报名～](https://9753492656408.huodongxing.com/event/3799122350000)

🔍相关阅读

[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)

[NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247516029&idx=1&sn=144dbf68dd1cd770cf6bee531500ccad&scene=21#wechat_redirect)

[GraphRAG vs DeepSearch？GraphRAG 提出者给你答案](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515612&idx=1&sn=e5b3f13debc62fcf53119e55ce2b6b71&scene=21#wechat_redirect)

[NebulaGraph 的 GraphRAG 进展、实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247514593&idx=1&sn=bed17f080e374d9cb957d14f17a01062&scene=21#wechat_redirect)

[VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect)

[基于 NebulaGraph ，构建属于你的 Graph RAG](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511536&idx=1&sn=f73ada9ea4c97d23acaed65c60a06034&scene=21#wechat_redirect)

NebulaGraph GenAI Team 在 GraphRAG 上的工作与进展

首个提出 GraphRAG 的团队在做什么？

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/MCP/dac249151143b177336ead527966a939472621355.jpg)

> 本文首发于 NebulaGraph 技术社区 [https://mp.weixin.qq.com/s/YhtDxiPIVRR3VQAoVQxYjw](https://mp.weixin.qq.com/s/YhtDxiPIVRR3VQAoVQxYjw)

# ▌一、背景


过去几周，Model Context Protocol (MCP) 在技术社区中引发了广泛的讨论和关注。借此机会，我参与了几个相关的开源项目，包括为 **LlamaIndex 官方仓库贡献了 McpToolSpec 实现**，以及和 Xuanwo、FrostMing 合作开发了一版 **Model Context Protocol Server for Apache OpenDAL™**。

MCP 是目前唯一一个在生态上具有优势的标准。在这一背景下，我们**基于 NebulaGraph 3.x 实现了一个简单的 NebulaGraph MCP Server，作为 NebulaGraph X MCP 生态中的第一个基础组件，供大家探索 AI 与图数据库结合的可能性**，希望能够看到更多在这个模式下的有趣工作。


# ▌二、Model Context Protocol (MCP)


MCP 是由 Anthropic 团队推出的一项开放协议，旨在为 AI 系统提供统一的、高效的方式访问多种数据资源。通过采用客户端-服务器架构，MCP 将数据访问标准化，解决了传统 AI 系统在不同数据源之间的碎片化问题。

**MCP 核心特点**

1.  **标准化的通信方式**：通过 MCP，AI 助手能够有效地访问各种数据源，比如本地数据、远程服务和企业工具。
    
2.  **开放性与生态优势**：目前 MCP 社区中已有近 1000 个 MCP Server 实现，覆盖搜索、天气、数据库等多个领域，支持工具的快速接入。
    
3.  **灵活的架构**：通过定义客户端和服务端的交互协议，MCP 为开发者提供了构建可扩展、可复用系统的基础。
    

虽然目前在安全性和可靠性上仍有一些挑战，但随着协议规范的完善和成熟开发模式的引入，这些问题将逐步得到解决。


# ▌三、NebulaGraph MCP Server 功能


由于最近一段时间一直围绕 GraphRAG 和 Agentic Workflow 做一些工作，利用大模型和智能体进行图上数据的洞见和挖掘是一个非常重要的议题。为此，我快速开发了 NebulaGraph MCP Server，以支持 NebulaGraph 3.x 作为工具接入 MCP 生态，供语言模型（如 Claude、GPT 等）调用和使用。

目前 **NebulaGraph MCP Server 基于 FastMCP 实现，遵循 MCP 的核心规范，旨在提供高效、轻量的图数据库连接服务**。通过将 NebulaGraph 的功能暴露为标准化的工具接口，该 Server 能够让大模型轻松调用 NebulaGraph 数据，实现简单的图探索任务。

 **多种传输方式**：
    
-   支持 stdio 和 SSE 两种传输模式，满足不同开发和部署场景的需求。
    
  **基础图探索能力**：
    
-   图空间（Graph Space）列出：允许模型查询可用的图空间。
    
-   模式（Schema）查询：支持查询指定图空间的模式定义。
    
-   查询执行（Query Execution）：支持通过 MCP Server 执行 NebulaGraph 查询。
    
   **内置算子模板**：
    
-   实现了路径搜索和邻居发现等常用操作的模板，方便语言模型按需调用这些工具，快速获取图数据的初步洞察（Insight）。
    

为了展示它的效果，我基于 LlamaIndex 中的 McpToolSpec 和 ReActAgent 构建了一个简单的示例，下面是对应的截图：
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/MCP/3799122350000_wechat)


# ▌四、结语


**NebulaGraph MCP Server 是对 MCP 生态的一个初步尝试，旨在为语言模型和图数据库的结合提供一个起点**。随着协议的逐步成熟和生态的扩展，我们期待它能够在更多真实场景中发挥价值。如果您对这一方向感兴趣，欢迎一起探索、尝试！

**🔍相关阅读**：[首发完整版教程，MCP 集成至 LlamaIndex 的技术实践](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247515436&idx=1&sn=f4a428b25dcaecc5f4f9aa100695d15f&scene=21#wechat_redirect)‍‍

基于 NebulaGraph 3.x 实现了一个简单的 NebulaGraph MCP Server，作为 NebulaGraph X MCP 生态中的第一个基础组件，供大家探索 AI 与图数据库结合的可能性

NebulaGraph MCP Server 正式开源！探索 AI+图数据库无限可能


# ******▌********一、背景**


GraphRAG 是检索增强生成（RAG）技术的高级技术之一，旨在解决传统 RAG 的局限性。上周，[NebulaGraph 团队分享了关于 GraphRAG Indexing 模型蒸馏训练的工作](https://x.com/wey_gu/status/1892828461322162223) ，收获了诸多积极反馈。最近也收到些试图将 GraphRAG 和 DeepSearch 放在对立面混淆视听的信息。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/640-2.webp)

本文应朋友们建议整理而成，将分享 NebulaGraph 团队在 GraphRAG 领域的探索与实践历程，涵盖自 2023 年 6 月以来在 **GraphRAG** 基础研究上的进展，以及对**高级 RAG** 和 **Fusion GraphRAG** 的理解与实践。


# ******▌********二、RAG 与 GraphRAG 的缘起**



## RAG：检索增强生成


过去两年来，生成式 AI 和大语言模型的飞速发展堪称人类技术史上的重要里程碑。它们赋予计算机前所未有的上下文学习和推理能力，使得许多专属人类的复杂任务得以自动化甚至超越。然而，如何高效利用这些模型完成具体任务，成为技术落地的关键。

**RAG（Retrieval Augmented Generation，检索增强生成）作为一种基础范式应运而生。其核心在于通过“检索”（Retrieval）增强“生成”（Generation）：**

* 生成：将任务描述和领域知识（即提示词）输入大语言模型，生成相应的回答。

* 检索增强：利用检索技术为模型提供高度相关的上下文知识，从而提升生成质量。

在 RAG 中，检索环节至关重要。根据应用场景的不同，RAG 可分为两类：

* 面向公共检索系统：如 Google 或学术搜索引擎，依赖大模型调用外部 API，适用于通用知识获取。市面上的代表性产品包括 Perplexity Search 和 DeepSeek。
* 面向私有领域知识：如企业内部的研发文档或研究报告，需结合智能文档处理（IDP）、知识索引（Index）和知识管理系统。此类场景对检索技术的精准性和深度提出了更高要求。


###  朴素的 RAG

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/1.gif)


对于非结构化或半结构化知识，朴素 RAG 的典型流程包括：

* 将文档分割成块（Chunk）。

* 通过向量化嵌入（Embedding）构建语义索引，或结合 BM25 全文索引实现检索。

* 在任务执行时，基于任务需求直接检索或通过检索重写（如 HyDE）优化结果。

然而，这种方法在知识组织上的局限性使其难以满足企业级需求，具体挑战将在下文详述。

### RAG 的挑战


朴素 RAG 在实际应用中面临以下难题：

* 大海捞针：分块假设知识分布均匀，但某些关键信息可能被稀释在无关内容中，导致召回失败。

* 穿针引线：线性分割破坏了知识间的关联，难以还原全局上下文。

* 宏观问题：基于分片和关键词的索引无法有效应对全局性问题，如“哪些话题最具创新性”。

* 文档理解不足：缺乏智能文档处理时，公式、表格等复杂信息无法被正确解析和索引，影响回答质量。



# 高级 RAG



做好 RAG 并非一蹴而就，而是一个持续探索的过程。本质上，我们需要将对应用特点、RAG 技术特性以及知识本身的深刻理解，融入到 RAG 流水线的设计之中。

下图展示了一个近期发布的高级 RAG 总结性工作的简化图例：一个高级 RAG

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/2.webp)


**可见，在现代高级的 RAG 方法中，数据持久化层包含 "Graph DB"（即图数据库，一种以图结构——“节点”和“边”为中心的数据库），而图数据库也正是本文主题 GraphRAG 的重要基础设施。**

现代图数据库能够以高效、可扩展的方式驱动多租户、超大数据规模、高并发场景下复杂关联关系（图数据）的持久化、查询、访问和计算。它是高级 RAG 系统、智能体记忆系统（Agent Memory）的重要骨干基础设施，如下图所示。面向关联关系的图状结构，与我们梳理知识的脑图、甚至大脑中的神经元结构都非常相似。这种并非偶然的结构相似性，正是高级 RAG 知识索引解决朴素 RAG 方法挑战的关键。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/3.gif)


常见的高级 RAG 方法，在特别的索引结构上，包括树状索引（Tree-RAG）、分层检索（Raptor）和图状索引（GraphRAG），其中 GraphRAG 是我们文章的重点。


## ****高级 RAG****


**GraphRAG 这个方法最初是我们在 2023 年 8、9 月份开始，在 LlamaIndex 社区上持续做的一些工作和两次公开的 Webinar 上提出，并给出了开源的实现和可复现的效果比较试验。（** **[Graph RAG: 知识图谱结合 LLM 的检索增强](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247508410&idx=1&sn=a0432b3bbeac4e60a43c320f88201e81&scene=21#wechat_redirect)）**

在最初的 GraphRAG 参考实践中，我们给出了索引期基于大模型的同构图谱抽取的实现和查询区基于实体、关系语义的捞取与可配置的子图查询的知识召回，并比较了基于 Text-to-Query 方法的一些效果比较与结合方案的实现。现在，为了区隔之后 Graph-based RAG 方法的演进，我们把最初的 GraphRAG 叫做 **SubGraph RAG** 。

在当时的 VLDB workshop 上([VLDB 2024｜NebulaGraph RAG 正式官宣](https://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247511923&idx=1&sn=4d9a9b80cf528212b64ef96ec6a62fad&scene=21#wechat_redirect))，我们分享过的两个观点是

* 在与知识打交道的过程中，只用分片处理的方法、绕过 Graph（Knowledge Graph）一定是不够的，这也是我们做 GraphRAG 探索的初衷

* 这个 GraphRAG 的方法仅仅是一个开始，我们在不断探索更多在 Graph 之上的探索、推理的策略

随后，我们和 Researcher: Diego 一起讨论，**做了图索引之上 Chain of Exploration 的工作** ，并在 PyCon China 2024 上第一次给出了做了 Chain of Exploration 的分享。

之后，我们看到了非常多的 GraphRAG 相关工作被发表，比如 MIT 材料科学的两篇 利用我们的工作的 MechGPT、海马体 RAG 利用 pagerank 权重的工作 HippoRAG、LinkedIn 的利用 半结构化数据图建模的 RAG工作都非常有启发性。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/4.webp)


当然，最让我们兴奋的工作是微软的 GraphRAG: From Local to Global 工作，**他** **们充分探索了基于大模型抽取的知识图谱索引之上利用社区发现算法得到分级聚集结构下的全局性摘要**，这些摘要是没有偏见的保有原始知识中天然聚集性质、重要性质的脉络知识，在回答带有宏观全局性的问题中效果非常好。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/5.webp)


我们从这些后续的工作中受益匪浅，在与我们的客户 Graph based RAG 落地工作中，不断打磨、探索、累积了很多各个环节的优化、方法、策略。

最终形成了我们称为 **Fusion GraphRAG** 的方案。


# ******▌********三、Fusion GraphRAG**


Fusion GraphRAG 是我们团队在 GraphRAG 基础上的创新实践。它融合了高级 RAG 技术，通过图状结构存储文档层级、章节关系及特殊元素（如公式、表格），实现高效、灵活的检索。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/6.gif)


**Fusion GraphRAG 的本质在于 Sota 的高级 RAG 方法融合、充分连接的元知识索引、充分打磨调优的 GraphRAG**（可选索引）。

* Fusion GraphRAG 通过在一个联通图谱内的“元知识”索引，清晰地揭示海量知识文档的内在关联，呈现从文件夹、文档、章节到段落、图表、公式的完整脉络，此为知识图谱的“元知识频谱”。

* 在此基础上，用户可选择不同粒度的知识抽取方法（非必须），构建图谱结构的图索引，形成“增强图频谱”。

* 进一步，用户可以对图索引和元知识层进行诸如图摘要、权重分配、时序/状语信息补充等增强操作，以提升知识检索和利用的效率。


# *▌*四、Fusion GraphRAG 实现私域 Deep Research


**Fusion GraphRAG 融合了先进的 IDP 技术与 RAG 索引方法，并将提取的多模态知识有机地关联为图状结构，从而精确映射真实世界知识的内在逻辑。** 依托高性能、支持图语义与向量检索的现代图数据库作为持久化底层，Fusion GraphRAG 能在这一统一图谱上实现面向元知识层次与图谱增强的高级检索。

例如：

* 多层级知识检索：通过我们提出的 “Chain of Exploration” 检索器——一个能自主在图谱中探索并查找任务相关知识的智能 Agent，Fusion GraphRAG 可以在同时包含文件夹、文件层级以及章节（附摘要）结构信息的图谱上，既完成传统基于 Chunk 的检索任务，又能支持基于分层结构实现的脑图式 RAG 检索。（注：此方法不依赖昂贵的图谱抽取技术，后续将探讨如何进一步降低抽取成本。）
* 全局与局部深度分析：通过引入图抽取与图社区摘要等增强手段，“Chain of Exploration” 能够在图谱上按需执行全局搜索以解决宏观问题，同时进行针对多个知识点的精准局部检索，甚至对涉及复杂关联的深度问题（如关键知识间路径查找）进行分析。

* 多 Agent 协同：利用 Fusion GraphRAG 构建多 Agent 系统，可以将一整套算法与行为准则封装为一个专用的 Fusion GraphRAG Agent，此 Agent 可作为另一 RAG Agent 的召回计划生成器，在少而精的专业知识（know-how）构建的 Fusion Graph Index 指引下，自动规划出基于海量知识库的复杂查询方案。这为构建私有领域的自主学习 Deep Research/Action Agent 提供了有力支撑。

* 私有知识库内的深度研究：在 Fusion GraphRAG 之上，我们可以轻松实现针对私有知识库的 Deep Researcher。依托天然的知识连接与索引，再结合针对 “Chain of Exploration” Agent 的优化提示工程，以及类似 DeepSeek R1 的推理模型，就能实现类似 Deep Researcher 的 RAG 召回效果，为深度研究提供强大动力。


# ******▌********五、回到 GraphRAG 的时间线**


在我们的视角下，GraphRAG 正在不断演进，下面简要梳理这一发展历程：

* GraphRAG - 2023-08NebulaGraph 在 LlamaIndex 社区首次提出并实现了基本的 GraphRAG 模型。

* GraphRAG with Community Summary - 2024-04微软在论文中提出了基于社区发现算法实现全局摘要的 GraphRAG 方法，为图谱检索提供了新的思路。

* Fusion GraphRAG

  * 融合了文档层级、章节层级、以及文中各类特殊元素（如公式、表格、图表）的多频谱混合图状索引；

  * 支持可选的知识抽取与知识增强（包括社区摘要、时序增强等），构建混合层级结构查询、全局图召回、知识频谱图谱召回以及（可选） Chain of Exploration 检索；

  * 同时支持将公共知识图谱、现有知识图谱以及图状数据中的 Chain of Exploration 召回方法进行融合。

### **图抽取**

需要指出的是，在大模型时代，对原始知识进行类似知识图谱的抽取并非 Fusion GraphRAG 的必选项，因为并非所有 RAG 任务都需要细粒度的“知识预习”。图抽取的代价较高，目前多数公开方案成本也不低。

> 注：LazyGraphRAG 的相关工作同样值得关注，它提供了另一种优化思路。

> 附：Fusion GraphRAG 的索引及增强流程示意图

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/7.webp)


### **让图抽取成为默认策略**

高质量的 GraphRAG 索引虽然效果显著，但成本昂贵。我们的终极目标是让图抽取的成本降低到与 Embedding 类似的水平，实现大规模普及。

实际上，AI 技术社区（包括我们自身）已经在朝这一方向不断努力：利用 NER 模型、更小型（例如 Phi 系列）的 LLM 进行 SFT、小规模 LLM 的 few shot 方案、尽可能的可编程方法，甚至融合 NER 与 LLM 的多种方案，都是当前探索的方向。最近，我们也看到了一些令人振奋的曙光！

本质上，我们探索的基于 LLM 的抽取方法都采用了不同形式的 CoT（思维链）策略。近期，DeepSeek-MATH 论文中首次提出的 GRPO 方法在 DeepSeek R0 中用于冷启动获取 Think-aloud（思考过程）的深度 CoT 能力表现非常出色。同时，我们注意到基于 Qwen2.5（小尺寸 0.5b 模型）进行 GRPO 训练，在需要强推理能力的任务（例如数学问题）上，通过大约 200 步训练就能获得令人满意的效果。

结合这些观察，我们开展了如下探索：
* 数据收集与预处理：利用 DeepSeek R1，在挑选的最新原始知识数据（晚于模型 cut-off date）的基础上进行抽取任务，并开启 `<think>` 模式，收集高质量的 CoT 与图抽取的 Ground Truth，筛选掉质量不合格或思考过程过长的样本，作为训练数据。

* 奖励机制设计：基于开源社区中针对数学问题推理训练的 GRPO 奖励函数，我们设计了奖励高质量推理过程和高质量抽取结果的奖励函数。这两项奖励均依托高质量、低成本的指令大模型进行评估打分。

在一块 A100 显卡上经过约 200 步训练后，我们初步评估结果显示：基于 Qwen2.5-3b 的小尺寸抽取模型在引入 GRPO 训练后，其性能已经超越了 GPT-4o-mini。以下是各模型的对比结果：

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/8.webp)


正如当初推出首个 GraphRAG 开源实现时一样，这项工作仅仅是个起点。它证明了图抽取技术成本正在不断降低，未来我们有望大胆应用于更多场景，实现大规模的知识 GraphRAG。与此同时，这个方法也为特定领域范式数据抽取质量的提升提供了经济可行的方案。

> 训练数据、合成过程以及训练流程均已开源https://github.com/wey-gu/grpo-graph-extraction

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/9.webp)


### **RAG 应用落地的挑战**

众所周知，**RAG 更多的是一种技术和功能，而非一个完整的产品** 。在企业级应用中，产品形态本身所面临的挑战，往往远超技术或原理上的难题。

举个例子，Excel 电子表格软件凭借其公式计算和数据可视化功能，为会计和企业数据处理领域带来了颠覆性的变革。理论上，只需学习 Excel 中的各类公式和图表功能，就能获得大量实战经验，成为专业的数据分析师。但实际上，我们观察到，大多数企业员工仅仅熟悉 Excel 的基本操作，而许多昂贵且高级的 SaaS 产品，其功能实际上也不过是 Excel 部分能力的延伸。

如果基于 RAG 能力构建的企业产品，只是一个具备强大应用编排和知识库索引能力的“无代码”平台，那么这样的平台很可能只能在企业内部的少部分用户或团队中落地。大部分宝贵的领域知识仍停留在个人或小圈子中，无法以智能高效的方式被全面激活和利用。

为了解决这一问题，我们基于 FusionGraphRAG 与 Agentic RAG 技术，打造了一个全新的高级知识库与低门槛应用平台 —— NebulaGraph AI 应用平台（内部命名为 “Catalyst”，即催化剂）。该平台的核心设计理念包括：

* 无需构建复杂 Workflow：用户不需要自行搭建工作流。
* 无需编写繁琐 Prompt：用户无需学习复杂的指令语法。
* 简化知识定义：用户只需将对私有知识的理解转化为对不同“知识篮子”的定义。
* 智能对话交互：用户通过与我们的“元智能体”交流，传达解决问题的方法。

这种设计大幅降低了使用门槛，使得企业内部的知识能够被更高效、更智能地激活与应用，真正实现“插上翅膀”的飞跃。

### **AI 应用平台**

在这个平台中，企业用户可以将成百上千个文档轻松归入各自的知识“篮子”，并为每个篮子选择适合的“预学习”——即索引模式：
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/10.webp)


**知识探索**用户可以随时在各个知识篮子中进行探索，快速定位所需信息，直观理解知识集合内的知识分布、深浅、特种。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/11.webp)


**智能应用生成**用户无需亲手编写复杂的 prompt，只需通过对话的方式与平台互动，即可生成各种类型的智能应用、迭代沉淀应用的 prompt。例如：

* 平台内置了生成智能体应用的“元智能体”，让对话即成为开发工具。

* “帮我构建一个投研报告生成助手”

* “我要做一个 xx 申报助手”

* “基于我所有的周报知识，构建一个 yy 领域回答助手，我想放到钉钉签名上，免得别人来烦我关于 yy 的问题” ……

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/12.webp)


**问答搜索应用**平台支持构建问答型搜索应用，帮助用户快速获得精确答案。

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/3.4/13.webp)


**知识溯源**同时，针对问答应用，基于连接的知识溯源，追踪答案的来源，确保信息透明可靠。


# ******▌********六、总结**


GraphRAG 的发展代表了 RAG 技术从基础检索向高级知识管理的演进。通过解决传统 RAG 在知识稀释、关联丢失和宏观问题上的挑战，GraphRAG 为企业级应用提供了更高效、灵活的解决方案。我们团队开发的 **Fusion GraphRAG 融合了智能文档处理（IDP）、多层次知识索引和图状结构，将知识的内在关联映射到检索过程中，显著提升了复杂任务的处理能力。**

在实践中，我们通过优化图抽取成本（R1 知识蒸馏、 GRPO 方法、 Qwen2.5-3B 规模上的工作，并开源出来。），让 GraphRAG 技术更具经济可行性，使其能够广泛应用于企业知识管理和智能应用平台。

未来，我们相信 GraphRAG 将成为高级 RAG 和智能体记忆（Agent Memory）的核心基础设施，推动深层研究和智能决策的进一步发展。NebulaGraph AI 应用平台的推出，正是这一愿景的初步实现。

最后，对于 GraphRAG，这是 Sherman 和我们 NebulaGraph GenAI team 每一位同学共同相信的观点：

* **狭义的 “GraphRAG”、甚至 “SubGraph RAG”，在特定场景仍然有优势，我们可以按需应用这个技术组合**

* **Deep Research, Deep Search 的形态与 Graph-based RAG 方法，尤其是 Fusion GraphRAG 可以形成很好的互补**

* **Graph Infra 是高级 RAG/Agent Memory 中不可绕过的结构与方法（Graph is inevitable in Advanced RAG），是以向量为基础的 RAG 的重要演进与互补。**



分享 NebulaGraph 团队在 GraphRAG 领域的探索与实践历程，涵盖自 2023 年 6 月以来在 **GraphRAG** 基础研究上的进展，以及对高级 RAG 和 Fusion GraphRAG  的理解与实践。

GraphRAG vs DeepSearch？GraphRAG 提出者给你答案

# ****▌一、前言****

本文主要介绍了如何将 **MCP**（Model Context Protocol，模型上下文协议）工具转换为可以直接使用的 **LlamaIndex** 工具，使 **LlamaIndex** 用户能像使用 **Claude**, **Cursor** 等现代 AI 应用一样无缝集成这些服务。

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%B0%81%E9%9D%A2.png)

# ****▌二、技术背景****


## ****2.1 什么是 MCP 协议 ？****


**MCP**（模型上下文协议，[https://modelcontextprotocol.io](https://modelcontextprotocol.io)）是面向 AI 应用交互的服务构建协议。开发者可通过该协议构建具备数据资源（resources）、功能工具（tools）和提示模板（prompts）的服务端点。例如，我们可以定义获取 IP 详细信息的 `fetch_ipinfo` 工具：

```
@mcp.tool()
async def fetch_ipinfo(ip: str | None = None, **kwargs) -> IPDetails:
    """获取指定IP的详细信息
    
    参数:
        ip(str or None): 目标 IP 地址，格式如 192.168.1.1
        **kwargs: 传递给 IPInfo 处理器的附加参数
    
    返回:
        IPDetails: 包含城市、时区等信息的结构化数据
    """
    handler = ipinfo.getHandler(
        access_token=os.environ.get("IPINFO_API_TOKEN"),
        headers={"user-agent": "basic-mcp-server"},
        **kwargs,
    )
    details = handler.getDetails(ip_address=ip)
    return IPDetails(**details.all)
```


## ****2.2 **LlamaIndex 框架特征******


LlamaIndex（[https://github.com/run-llama/llama_index）是构建知识索引系统的核心框架，](https://github.com/run-llama/llama_index%EF%BC%89%E6%98%AF%E6%9E%84%E5%BB%BA%E7%9F%A5%E8%AF%86%E7%B4%A2%E5%BC%95%E7%B3%BB%E7%BB%9F%E7%9A%84%E6%A0%B8%E5%BF%83%E6%A1%86%E6%9E%B6%EF%BC%8C)**其核心价值在于将外部信息结构化地接入大语言模型，实现高效的信息检索、智能问答和对话生成**。当需要集成动态数据源时，将 MCP 工具转换为 LlamaIndex 工具成为关键技术需求。

在 **LlamaIndex** 中，**NebulaGraph** 已经有两种方法实现 **GraphRAG**：

`KnowledgeGraphIndex` 用来对任何私有数据从零构建知识图谱（基于 LLM 或者其他语言模型），再 4 行代码进行 Graph RAG：

```
graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
storage_context = StorageContext.from_defaults(graph_store=graph_store)
# Build KG
kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
kg_query_engine = kg_index.as_query_engine()

```

 
`KnowledgeGraphRAGQueryEngine` 则可以在任何已经存在的知识图谱上进行 GraphRAG:

```
graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
storage_context = StorageContext.from_defaults(graph_store=graph_store)
graph_rag_query_engine = KnowledgeGraphRAGQueryEngine(
    storage_context=storage_context,
)
```


# ▌三、为什么需要将 MCP 集成至 LlamaIndex


在实际 AI 应用开发中，集成 MCP 工具主要解决以下需求：

-   **功能复用**：利用现有 MCP 生态（项目列表见https://github.com/AlexMili/Awesome-MCP）快速扩展系统能力
    
-   **流程统一**：建立标准化工具调用范式，简化大模型对外部 API 的调用复杂度
    
-   **自动化管理**：通过自动转换机制实现 MCP 工具到 `LlamaIndex FunctionTool` 对象的映射，便于 Agent 自动调度
    

该集成方案可以有效降低开发成本，同时发挥 LlamaIndex 在上下文管理和对话生成方面的优势。

# ****▌四、技术实现方案****

实现流程包含三个关键阶段：

-   **MCP 服务通信**：通过 MCPClient 类建立服务连接，支持工具发现（list\_tools）和调用执行（call\_tool）
    
-   **适配器构建**：定义 MCPToolAdapter 类，将 MCP 工具元数据转换为 LlamaIndex 的 FunctionTool 对象
    
-   **智能代理集成**：在 LlamaIndex Agent 中加载转换后的工具，实现自动化调用
    

# ********▌五、核心代码解析********

**协议转换适配器**

```
from llama_index.core.tools import FunctionTool
from pydantic import create_model, BaseModel

class MCPToolAdapter:
    def __init__(self, client):
        self.client = client

    async def list_tools(self):
        tools = await self.client.list_tools()
        return [
            FunctionTool.from_defaults(
                fn=self._create_tool_fn(tool.name),
                name=tool.name,
                description=tool.description,
                fn_schema=self._create_pydantic_model(tool.schema),
            ) for tool in tools
        ]
    
    def _create_pydantic_model(self, json_schema):
        # 实现JSON Schema到Pydantic模型的动态转换
        ...
```


**类型系统映射**

```
JSON_TYPE_MAPPING = {
    "string": str,
    "number": float,
    "integer": int,
    "boolean": bool,
    "object": dict,
    "array": list
}

def create_dynamic_model(schema):
    fields = {}
    for name, prop in schema["properties"].items():
        py_type = JSON_TYPE_MAPPING[prop["type"]]
        if name in schema.get("required", []):
            fields[name] = (py_type, Field(...))
        else:
            fields[name] = (Optional[py_type], Field(None))
    return create_model("DynamicModel", **fields)
```


**服务调用封装**

```
   async def fetch_ipinfo_wrapper(**kwargs):
    return await mcp_client.call_tool("fetch_ipinfo", kwargs)
```


**关键技术创新点**

-   **动态模式转换**：实现 JSON Schema 到 Pydantic 模型的运行时转换，保证参数校验的严格性
    
-   **异步调用管道**：基于 Python asyncio 构建非阻塞式服务调用，提升工具执行效率
    
-   **协议抽象层**：通过适配器模式解耦 MCP 协议与 LlamaIndex 框架，保证系统扩展性
    

> 将 MCP 工具的输入参数转换为 Pydantic 模型的原因在于：MCP 工具使用 JSON Schema 格式定义输入参数（在工具对象的 `inputSchema` 中，类型为 `Dict[str, Any]` ），而 `create_model_from_json_schema` 函数将其转换为 Pydantic 模型，该模型用作 LlamaIndex 中 FunctionTool 的 `fn_schema`。

# ******▌六、**LlamaIndex 中的 MCP 工具********

********调用实践********

以下代码来自 `llamaindex_mcp_example.py`，完整展示了 MCPToolAdapter 与 LlamaIndex 的集成方式：


```
import os
from llama_index.core.llms import ChatMessage
from llama_index.core.agent import ReActAgent, ReActChatFormatter
from llama_index.core.agent.react.prompts import REACT_CHAT_SYSTEM_HEADER
from llama_index.llms.azure_openai import AzureOpenAI

from llamaindex_mcp_adapter import MCPToolAdapter
from mcp_client import MCPClient
import anyio
import dotenv
import argparse

dotenv.load_dotenv()

# 系统级指令模板
SYSTEM_PROMPT = """\
您是一个智能法律助手

在回答用户问题前，必须通过IP信息确认用户所在司法管辖区
操作规则：
- 当涉及地理位置、时区等问题时，自动调用fetch_ipinfo工具
- 法律咨询类问题需结合IP所在国家/地区法律体系
"""

async def get_agent(adapter: MCPToolAdapter):
    """智能代理初始化函数"""
    tools = await adapter.list_tools()  # 获取MCP工具列表
    
    # 配置Azure OpenAI大语言模型
    llm = AzureOpenAI(
        model=os.environ.get("AZURE_OPENAI_MODEL", "gpt-4"),
        max_tokens=int(os.environ.get("AZURE_OPENAI_MAX_TOKENS", 4096)),
        azure_endpoint=os.environ.get("AZURE_OPENAI_ENDPOINT"),
        api_key=os.environ.get("AZURE_OPENAI_API_KEY"),
        api_version=os.environ.get("AZURE_OPENAI_API_VERSION"),
        engine=os.environ.get("AZURE_OPENAI_ENGINE")
    )
    
    # 构建ReAct智能代理
    agent = ReActAgent.from_tools(
        llm=llm,
        tools=list(tools),
        react_chat_formatter=ReActChatFormatter(
            system_header=SYSTEM_PROMPT + "\n" + REACT_CHAT_SYSTEM_HEADER,
        ),
        max_iterations=20,  # 限制最大推理步数
        verbose=True        # 启用详细日志
    )
    return agent

async def handle_user_message(message_content: str, agent: ReActAgent):
    """消息处理流水线"""
    user_message = ChatMessage.from_str(role="user", content=message_content)
    response = await agent.achat(message=user_message.content)
    print(f"[智能代理响应] {response.response}")

if __name__ == "__main__":
    async def main():
        # 命令行参数解析
        parser = argparse.ArgumentParser()
        parser.add_argument("--client_type", 
                          choices=["sse", "stdio"], 
                          default="stdio",
                          help="连接模式：sse(Server-Sent Events)或stdio(标准输入输出)")
        args = parser.parse_args()

        # MCP客户端初始化
        if args.client_type == "sse":
            client = MCPClient("http://0.0.0.0:8000/sse")  # SSE长连接模式
        else:
            client = MCPClient(                            # 子进程模式
                "./venv/bin/python", 
                ["mcp_server.py", "--server_type", "stdio"]
            )
        
        # 工具适配器初始化
        adapter = MCPToolAdapter(client)
        agent = await get_agent(adapter)

        # 执行测试用例
        await handle_user_message("我的IP所在城市是哪里？", agent)
        await handle_user_message("持有大麻在我国是否合法？", agent)

    anyio.run(main)  # 启动异步运行时
```


**关键实现解析**

-   工具获取机制：
    
-   通过 `adapter.list_tools()` 动态加载 MCP 服务端注册的工具列表
    
-   自动将每个 MCP 工具转换为 LlamaIndex 的 `FunctionTool` 对象
    
-   智能代理配置：
    
-   使用 Azure OpenAI 作为底层大语言模型引擎
    
-   集成 `ReAct` 推理框架，支持多步工具调用
    
-   设置 20 步的最大推理深度防止无限循环
    
-   消息处理流程：
    
-   将用户输入封装为标准化 ChatMessage
    
-   通过 `agent.achat()` 触发自动化工具调用链
    

# ******▌七、运行 Demo******


## ****7.1 标准输入输出模式****



```
python llamaindex_mcp_example.py --client_type stdio
```

执行输出示例

[DEBUG] 检测到ListToolsRequest协议请求
[工具调用] 步骤ID: ede14770-91c9-428b... | 输入: 我的IP所在城市是哪里？
[推理日志] 当前用户语言：中文，需调用工具获取数据
[动作触发] fetch_ipinfo | 参数: {}
[网络请求] 调用MCP工具耗时128ms
[观察结果] {"ip": "183.193.123.192", "city": "上海", "country": "CN"...}
[最终响应] 您的IP所在城市为上海

[法律咨询] 步骤ID: e728f5d0-6c0e-454a... | 输入: 持有大麻是否合法？
[推理日志] 已确认用户所在国家：中国
[知识库检索] 加载中国刑法第357条
[最终响应] 根据中国法律，持有大麻属违法行为，最高可判处有期徒刑


## ****7.2 SSE 服务模式****



```
# 终端1：启动SSE服务端
python mcp_server.py --server_type sse

# 终端2：运行客户端
python llamaindex_mcp_example.py --client_type sse
```


# ****▌八、技术方案总结****

通过以下三步实现深度集成：

**协议通信层**：

-   基于 `MCPClient` 实现服务发现与工具调用
    
-   支持 SSE/STDIO 双模连接，适应不同部署场景
    

**类型转换层**：

-   动态将 JSON Schema 转换为 Pydantic 模型
    
-   实现参数自动校验与类型提示
    


```
def create_dynamic_model(schema):
    # 自动生成带字段描述的Pydantic模型
    fields = {
        name: (map_type(prop), Field(..., description=prop["description"]))
        for name, prop in schema["properties"].items()
    }
    return create_model("DynamicModel", **fields)
```

**智能代理层**：

-   集成 ReAct 推理框架实现自动化工具调度
    
-   通过系统提示词约束工具使用规范
    


```
SYSTEM_PROMPT = """\
法律咨询必须遵循以下规则：
1. 首次响应前必须调用fetch_ipinfo确认用户辖区
2. 引用法律条文需标注具体条款编号
3. 不得对未覆盖地区提供法律建议"""
```


通过持续扩展 MCP 生态，开发者可快速构建具备专业领域能力的智能代理系统。欢迎访问 MCP 开发者社区获取更多工具资源。

查看源代码：[https://github.com/psiace/psiace/tree/main/demo/llamaindex-mcp-adapter](https://github.com/psiace/psiace/tree/main/demo/llamaindex-mcp-adapter)



本文主要介绍了如何将 MCP（Model Context Protocol，模型上下文协议）工具转换为可以直接使用的 LlamaIndex 工具，使 LlamaIndex 用户能像使用 Claude, Cursor 等现代 AI 应用一样无缝集成这些服务。

首发完整版教程，MCP 集成至 LlamaIndex 的技术实践


# ****一、前言****


“**东风夜放花千树，更吹落，星如雨**” —— 南宋词人辛弃疾笔下描绘的元宵盛景，穿越 800 年时空依然让我们心驰神往。这个起源于汉代太一神祭祀的古老节日，在历史长河中不断焕发新生：东汉时期与佛教燃灯习俗融合，唐代发展为全民狂欢的"上元节"，宋代市井中诞生猜灯谜等民俗...元宵节作为中华民族历史悠久、内涵丰富的重要传统节日，其意义早已超越了“节日”的单一范畴，而成为家庭团圆、祈福迎祥的象征。

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%85%83%E5%AE%B5%E8%8A%82/%E5%85%83%E5%AE%B5%E8%8A%82/4a5759cb1a25147e9fbef14c84254206.png)

在漫长的历史演进中不断融合和创新，形成了历史、传说、民俗、美食、诗词等多重文化。这些文化要素构成了一幅多层次、跨领域、互联互通的文化全景图。我们如何用现代科技来传承和弘扬这一古老节日的文化内涵？本文将带你走进元宵节的文化世界，通过 **NebulaGraph** 和 **DeepSeek** 构建直观易懂的**元宵节知识图谱**。


# ****二、元宵节的多重文化维度****


在构建元宵知识图谱之前，我们必须对元宵节文化进行系统性拆解，将其内涵细分为多个独立但又相互关联的知识域。从知识图谱建模的角度来看，每一个知识域都可以视为一个节点类别（Tag），而这些类别之间的关系则由边（Edge）来表示。下面我们详细介绍元宵节的四大文化维度。


```
-- 插入类别节点
INSERT VERTEX `Category` (name) VALUES "元宵节传说";
INSERT VERTEX `Category` (name) VALUES "关于元宵的诗";
INSERT VERTEX `Category` (name) VALUES "民俗活动";
INSERT VERTEX `Category` (name) VALUES "美食文化";
```



## **2.1 历史传说**


元宵节中流传着大量的传说和民间故事，这些传说不仅为节日增添了神秘色彩，同时也反映了古人对自然、神祇以及命运的理解。在图谱建模时，每一个传说故事都可以构建为一个节点，其属性包括传说名称、来源文献、相关朝代和地域。通过定义“传说关联”边，将不同传说故事与历史传承、民俗活动相互链接，形成完整的文化脉络。




```
# 历史传说（含时空维度）
CREATE TAG `HistoricalLegend` (
    name string NOT NULL,          # 传说名称
    era string,                    # 所属朝代
    region string DEFAULT "中国",  # 地域分布
    description string,            # 详细描述
    source string                  # 文献来源
) COMMENT = "历史传说实体";

```




## **2.2 民俗风情**


元宵节作为民间传统节日，其民俗活动丰富多彩，涵盖了赏花灯、猜灯谜、踩高跷、扭秧歌等多个方面。每一种民俗活动都深深植根于地方文化，并具有鲜明的地域特色。在知识图谱中，民俗活动作为一个独立的知识领域，其节点属性包括活动名称、起始年份、流行指数、地域分布及文化意义等，通过“民俗关联”边将其与历史、传说等领域关联起来。


```
# 民俗活动（带时空特征）
CREATE TAG `FolkActivity` (
    name string NOT NULL,          # 活动名称
    start_year int,                # 起始年份
    popularity double,             # 流行度指数
    spatial_scope string,          # 地域分布
    cultural_significance string   # 文化意义
) COMMENT = "民俗活动实体";

```


## **2.3 美食文化**


元宵节的美食是传统节日中不可或缺的一部分，每种食品都蕴含着独特的文化象征意义：

-   元宵/汤圆：象征团圆与和谐，寓意家庭和睦、生活甜蜜。
    
-   年糕：寓意年年高升、步步高升，是对美好未来的期盼。
    

在知识图谱中，美食文化节点需包含食品名称、热量、原料成分（以字符串形式存储多个原料）、及象征意义等属性。通过“美食关联”边，可以将美食与民俗活动、历史传承等关联起来，形成完整的文化生态链。


```
# 美食文化（含营养成分）
CREATE TAG `FoodCulture` (
    name string NOT NULL,          # 食物名称
    calories double,               # 热量(kcal)
    ingredients string,      # 原料成分
    symbolic_meaning string        # 象征意义
) COMMENT = "美食文化实体";
```



## **2.4 诗词雅韵**


元宵节在文人墨客笔下同样是一座灵感的宝库。历代文人以元宵为题，创作了大量优美诗词，这些诗词不仅反映了当时的社会风貌，更承载了深厚的情感与审美：经典作品：如辛弃疾的《青玉案·元夕》、欧阳修的《生查子·元夕》等，均成为千古绝唱。在知识图谱中，诗词作品节点包括标题、作者、创作朝代、韵律模式、情感分析值和完整内容等，通过“诗词关联”边将诗词与民俗活动、历史传承、传说故事等多维信息建立联系。


```
# 诗词作品（带文学特征）
CREATE TAG `Poetry` (
    title string NOT NULL,         # 诗词标题
    author string,                 # 作者
    dynasty string,                # 创作朝代
    rhyme_scheme string,           # 押韵模式
    sentiment_analysis double,     # 情感分析值
    content string                 # 完整内容
) COMMENT = "诗词作品实体";
```



# ****三、NebulaGraph + DeepSeek****


****构建元宵节知识图谱****


## **3.1 数据建模**


在构建元宵知识图谱过程中，我们首先需要对各个文化维度进行数据建模。基于前文介绍的四大维度，我们已经将数据分为以下四大节点类别：

HistoricalLegend（历史传说）属性：名称、朝代、地域、描述、文献来源。

FolkActivity（民俗活动）属性：活动名称、起始年份、流行指数、地域分布、文化意义。

FoodCulture（美食文化）属性：食品名称、热量、原料成分（字符串存储）、象征意义。

Poetry（诗词作品）属性：标题、作者、朝代、韵律模式、情感分析值、完整内容。

接下来，我们需要定义边类型来表达不同领域之间的关联：


```
# 定义多维关联边类型
# ================================================
# 时空关联边（带权重）
CREATE EDGE `HistoricalContinuity` (
    start_year int,                # 起始年份
    end_year int,                  # 终止年份
    influence_factor double        # 影响力系数
) COMMENT = "历史延续性关联";

# 文化传播边（带地理编码）
CREATE EDGE `CulturalDiffusion` (
    from_region string,            # 发源地
    to_region string,              # 传播地
    diffusion_path string          # 传播路径
) COMMENT = "文化传播路径";

# 语义关联边（带置信度）
CREATE EDGE `SemanticLink` (
    relation_type string,          # 关系类型
    confidence double,             # 置信度
    source string                  # 知识来源
) COMMENT = "语义关系关联";

# 创建边类型：RelatedTo
CREATE EDGE RelatedTo (
    description string,  # 关系描述
) COMMENT = "历史传说与民俗活动之间的关联关系";

# 创建边类型：AssociatedWith
CREATE EDGE AssociatedWith (
    description string,  # 关系描述
) COMMENT = "民俗活动与美食文化之间的关联关系";

# 创建边类型：WrittenFor
CREATE EDGE WrittenFor (
    description string,  # 关系描述
) COMMENT = "民俗活动与诗词作品之间的关联关系";
```


经过数轮和 DeepSeek 的沟通，得到了以下数据：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%85%83%E5%AE%B5%E8%8A%82/%E5%85%83%E5%AE%B5%E8%8A%82/1.png)

## **3.2 通过 DeepSeek 做元宵节文化知识抽取**


在构建元宵知识图谱过程中，需要大量非结构化的元宵节文化文本转换为结构化数据，再通过图谱表达各实体与关系。以下介绍如何利用 DeepSeek 对元宵节文化文本进行知识抽取，并将抽取结果以 nGQL 语句导入 NebulaGraph。这里给出两种方法：



### 方法一：直接与 DeepSeek 对话



构建提问策略 根据元宵节文化知识的需求，设计几个关键问题，例如：

-   “元宵节的起源和历史背景是什么？”
    
-   “元宵节有哪些传统民俗活动？”
    
-   “元宵节的代表美食有哪些？它们分别象征什么？”
    
-   “请解析《青玉案·元夕》中描绘的元宵盛景。”
    

通过 DeepSeek 的在线接口或对话系统，直接输入上述问题。DeepSeek 会返回结构化或半结构化的回答，其中可能包含实体及其属性、关系等信息。例如，返回的数据可能类似于：

实体：元宵节 属性：起源 → “汉代祭祀太一神”、历史记载 → “《史记》记载…”

实体：赏花灯 属性：地域 → “华北,江南”、文化意义 → “象征光明与希望”

实体：元宵 属性：美食寓意 → “象征团圆与美满”

实体：青玉案·元夕 属性：作者 → “辛弃疾”、朝代 → “宋代”

同时，还会返回诸如：

("元宵节", "hasTradition", "赏花灯")

("元宵节", "hasFood", "元宵")

("赏花灯", "describedIn", "青玉案·元夕")

根据 DeepSeek 返回的结构化知识，我们整理出各个节点及关系，然后生成 nGQL 语句。例如：


```
# 建立元宵节与赏花灯的关联（例如，历史传承到民俗活动） 
INSERT EDGE RelatedTo (description) VALUES "HL001" -> "FA001":("元宵节催生了赏花灯这一民俗活动"); 
# 建立赏花灯与元宵之间的关联（民俗活动与美食文化） 
INSERT EDGE AssociatedWith (description) VALUES "FA001" -> "FC001":("赏花灯与元宵相辅相成，共同构成节日风貌"); 
# 建立赏花灯与诗词作品之间的关联 INSERT EDGE WrittenFor (description) VALUES "FA001" -> "P001":("《青玉案·元夕》描绘了赏花灯的盛景");

```




### 方法二：本地部署 DeepSeek


对于大规模数据或需要对抽取过程进行精细控制的场景(事实是总是遇到“服务器繁忙，请稍后再试”)，可以选择在本地部署 DeepSeek。此方法适合批量处理、自动化知识库构建，步骤如下：

本机部署 DeepSeek-R1

i、下载安装 Ollama；

ii、运行：ollama run deepseek-r1；

iii、下载安装 ChatBox；

iV、在ChatBox 的设置中选择 "OllamaAPI" 并选择 DeepSeek-R1 模型

准备元宵节相关的海量语料，如历史文献、民间故事、网络文章、诗词资料等，并进行文本格式化处理。

文本预处理对语料进行清洗、分词,将预处理后的文本组织成适合 DeepSeek 模型输入的格式。

批量知识抽取运行本地部署的 DeepSeek 模型，对处理后的文本数据进行批量推理。模型会自动识别出文本中的关键实体、属性及其之间的关系，并生成结构化输出。

输出数据示例（JSON 格式）：


```
{
  "entity": "元宵节",
  "attributes": {
    "起源": "汉代祭祀",
    "传统": "赏花灯,猜灯谜",
    "美食": "元宵,汤圆",
    "诗词": "青玉案·元夕"
  },
  "relations": [
    {
      "subject": "元宵节",
      "predicate": "hasOrigin",
      "object": "汉代"
    },
    {
      "subject": "元宵节",
      "predicate": "hasTradition",
      "object": "赏花灯"
    },
    {
      "subject": "元宵节",
      "predicate": "hasFood",
      "object": "元宵"
    },
    {
      "subject": "赏花灯",
      "predicate": "describedIn",
      "object": "青玉案·元夕"
    }
  ]
}
```

数据转换与 nGQL 导入，如：


```
# 插入美食文化节点：元宵 
INSERT VERTEX FoodCulture(name, calories, ingredients, symbolic_meaning) VALUES "FC001":("元宵", 450, "糯米,芝麻,白糖", "象征团圆与美满");

# 插入诗词作品节点：青玉案·元夕 
INSERT VERTEX Poetry(title, author, dynasty, rhyme_scheme, sentiment_analysis, content) VALUES "P001":("青玉案·元夕", "辛弃疾", "宋代", "xyz", 0.85, "东风夜放花千树，更吹落、星如雨..."); 

```

持续更新与调优根据实际抽取效果，不断优化 DeepSeek 模型参数和抽取策略，提升实体和关系的准确性。


## **3.3 数据导入与知识图谱构建**


将 DeepSeek 提取的数据导入到 NebulaGraph 中，可以使用以下 nGQL：


```
# 1. 插入历史传说数据
INSERT VERTEX `HistoricalLegend` (
    name, era, region, description, source
) VALUES
"HL001":("元宵节起源", "汉代", "中国", 
    "源于汉代祭祀太一神的活动，《史记·乐书》记载：'汉家常以正月上辛祠太一甘泉'", 
    "《史记》"),
"HL002":("燃灯习俗起源", "东汉", "洛阳",
    "东汉明帝时期佛教传入，敕令正月十五燃灯表佛，《僧史略》载：'西域十二月三十日...汉明帝令烧灯，表佛法大明也'",
    "《洛阳伽蓝记》"),
"HL003":("舞龙舞狮起源", "唐代", "中原",
    "舞龙舞狮起源于唐代，最初是宫廷表演，后流传至民间，象征驱邪避灾、吉祥如意",
    "《唐书》"),
"HL004":("踩高跷起源", "北宋", "北方",
    "踩高跷起源于北宋时期，最初是民间表演艺术，后成为元宵节常见活动",
    "《宋史》"),
"HL005":("扭秧歌起源", "明代", "北方",
    "扭秧歌起源于明代，最初是农民庆祝丰收的舞蹈，后成为元宵节传统活动",
    "《明史》");
# ================================================

# 2. 插入民俗活动数据
INSERT VERTEX `FolkActivity` (
    name, start_year, popularity, spatial_scope, cultural_significance
) VALUES
"FA001":("赏花灯", 180, 0.95, ARRAY["华北","江南"], "象征光明与希望，促进社区凝聚力"),
"FA002":("猜灯谜", 960, 0.88, ARRAY["全国"], "智力活动与传统文化的结合体现"),
"FA003":("舞龙舞狮", 618, 0.92, ARRAY["中原","华南"], "寓意驱邪避灾、吉祥如意"),
"FA004":("踩高跷", 1046, 0.85, ARRAY["北方"], "传统表演艺术，增加节日欢乐气氛"),
"FA005":("扭秧歌", 1368, 0.90, ARRAY["北方"], "传统舞蹈，表达喜庆和丰收的喜悦");
# ================================================

# 3. 插入美食文化数据
INSERT VERTEX FoodCulture(name, calories, ingredients, symbolic_meaning)
VALUES
    "FC001":("元宵", 450, "糯米,芝麻,白糖", "象征团圆与美满"),
    "FC002":("汤圆", 350, "糯米,红豆,椰蓉", "寓意家庭和睦、生活甜蜜"),
    "FC003":("年糕", 320, "糯米,红枣,花生", "象征年年高升，生活步步高"),
    "FC004":("炸元宵", 500, "糯米,豆沙,植物油", "外酥里嫩，寓意生活红火"),
    "FC005":("饺子", 280, "面粉,猪肉,白菜", "象征团圆和财富");
# ================================================

# 4. 插入诗词作品数据
INSERT VERTEX `Poetry` (
    title, author, dynasty, rhyme_scheme, sentiment_analysis, content
) VALUES
"P001":("青玉案·元夕", "辛弃疾", "宋代", "xyz", 0.85, "东风夜放花千树，更吹落、星如雨。宝马雕车香满路。凤箫声动，玉壶光转，一夜鱼龙舞。蛾儿雪柳黄金缕，笑语盈盈暗香去。众里寻他千百度，蓦然回首，那人却在、灯火阑珊处。"),
"P002":("生查子·元夕", "欧阳修", "宋代", "abd", 0.78, "去年元夜时，花市灯如昼。月上柳梢头，人约黄昏后。今年元夜时，月与灯依旧。不见去年人，泪湿春衫袖。"),
"P003":("正月十五夜", "苏味道", "唐代", "abc", 0.80, "火树银花合，星桥铁锁开。暗尘随马去，明月逐人来。游伎皆秾李，行歌尽落梅。金吾不禁夜，玉漏莫相催。"),
"P004":("十五夜观灯", "卢照邻", "唐代", "aabb", 0.82, "锦里开芳宴，兰缸艳早年。缛彩遥分地，繁光远缀天。接汉疑星落，依楼似月悬。别有千金笑，来映九枝前。"),
"P005":("元夕无月", "丘逢甲", "清代", "aabb", 0.75, "三年此夕月无光，明月多应在故乡。欲向海天寻月去，五更飞梦渡鲲洋。"),
"P006":("京都元夕", "元好问", "金代", "aabb", 0.80, "袨服华妆着处逢，六街灯火闹儿童。长衫我亦何为者，也在游人笑语中。"),
"P007":("鹧鸪天·元夕有所梦", "姜夔", "宋代", "aabb", 0.78, "肥水东流无尽期，当初不合种相思。梦中未比丹青见，暗里忽惊山鸟啼。春未绿，鬓先丝，人间别久不成悲。谁教岁岁红莲夜，两处沉吟各自知。"),
"P008":("清平乐·上元月蚀", "纳兰性德", "清代", "aabb", 0.85, "瑶华映阙，烘散蓂墀雪。比拟寻常清景别，第一团圆时节。影蛾忽泛初弦，分辉借与宫莲。七宝修成合璧，重轮岁岁中天。"),
"P009":("元夕二首", "王守仁", "明代", "aabb", 0.75, "故园今夕是元宵，独向蛮村坐寂寥。赖有遗经堪作伴，喜无车马过相邀。"),
"P010":("元夕影永冰灯", "唐顺之", "明代", "aabb", 0.80, "正怜火树千春妍，忽见清辉映月阑。出海鲛珠犹带水，满堂罗袖欲生寒。烛花不碍空中影，晕气疑从月里看。为语东风暂相借，来宵还得尽余欢。");

```


![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%85%83%E5%AE%B5%E8%8A%82/%E5%85%83%E5%AE%B5%E8%8A%82/2.png)

在建立关联关系和创建索引后，执行到数据库中，让我们看看效果～

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%85%83%E5%AE%B5%E8%8A%82/%E5%85%83%E5%AE%B5%E8%8A%82/3.png)

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/%E5%85%83%E5%AE%B5%E8%8A%82/%E5%85%83%E5%AE%B5%E8%8A%82/4.png)

环形关系图彩蛋 🎉
祝大家元宵节团团圆圆



本文将带你走进元宵节的文化世界，通过 NebulaGraph 和 DeepSeek 构建直观易懂的元宵节知识图谱

用 NebulaGraph + DeepSeek 解锁元宵节文化知识图谱，你知道几个？

**摘要**

**知识图谱作为结构化知识的重要载体**，正逐渐成为各领域智能化应用的核心。春节期间，DeepSeek 的横空出世引发了广泛关注。**DeepSeek** 作为一款强大的语言模型，具备先进的自然语言处理能力，能够从文本中提取关键信息并生成知识图谱的结构。而 **NebulaGraph** 作为一款高性能的分布式图数据库，能够高效存储和管理大规模图数据。

作为一名图爱好者，让人忍不住想**试一试 DeepSeek 在构建知识图谱的能力**，并通过一系列实验验证其在知识提取、图谱融合以及无中生有构建图谱方面的表现。实验结果表明，DeepSeek 在知识图谱构建和融合方面表现出色，但也存在一些技术细节需要优化。

开测之前，我们先对整体思路做一个梳理，我们需要确定以下几个问题：

1\. 能否通过一篇文章，准确构建知识图谱

2\. 能否对不同来源的文章进行知识融合

3\. 如果不提供文章，只描述所建图谱的大概内容，能否快速构建图谱

在确定了思路之后，开整。

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d1.webp)

# ****▌一、顺手牵羊****

实验的第一步是通过单篇文章验证 DeepSeek 的知识提取能力。我们选择了一篇关于开源图数据库 NebulaGraph 的文章\[1\]，并要求 DeepSeek 从文章中提取关键要素，生成 nGQL 代码以构建知识图谱。

> 你能帮我生成一个知识图谱吗，等一下我会给你一篇文章，帮我从内容中提取关键要素，然后以 nGQL 代码的形式构建知识图谱

在跟 DeepSeek 打好招呼之后，从网上捞一篇文章，这里用的是：如何评价开源图数据库 Nebula Graph？内容直接往上贴，简单粗暴。

```
# Schema定义（TAG类型）
CREATE TAG IF NOT EXISTS product(name string, description string);
CREATE TAG IF NOT EXISTS company(name string);
CREATE TAG IF NOT EXISTS feature(name string);
CREATE TAG IF NOT EXISTS tool(name string);
CREATE TAG IF NOT EXISTS scenario(name string);
CREATE TAG IF NOT EXISTS language(name string);
CREATE TAG IF NOT EXISTS auth_service(name string);
CREATE TAG IF NOT EXISTS ecosystem(name string);

# Schema定义（EDGE类型）
CREATE EDGE IF NOT EXISTS has_feature();
CREATE EDGE IF NOT EXISTS used_by();
CREATE EDGE IF NOT EXISTS provides_tool();
CREATE EDGE IF NOT EXISTS supports_language();
CREATE EDGE IF NOT EXISTS applicable_scenario();
CREATE EDGE IF NOT EXISTS compatible_with();
CREATE EDGE IF NOT EXISTS supports_auth();
CREATE EDGE IF NOT EXISTS integrates_with();

# 数据插入 - 核心产品
INSERT VERTEX product(name, description) VALUES 
"NebulaGraph":("NebulaGraph", "开源的分布式图数据库，支持千亿点万亿边数据集");

# 数据插入 - 产品特性
INSERT VERTEX feature(name) VALUES
"high_performance":("高性能"),
"open_source":("开源"),
"scalability":("易扩展"),
"flexible_modeling":("灵活数据建模"),
"read_write_balance":("读写平衡"),
"compatibility":("查询语言兼容性");

/* ... 此处省略 n多数据 */

```

扫了一眼脚本语法上没什么问题，在相同表的写入中，还将多条数据合并到一条语句，效果很好。将得到的脚本执行到数据库中，效果如下：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d2.webp)

可以看到以 **NebulaGraph** 为中心，辐射出了各种紧密相关的事物。

# ****▌二、桃园结义****

为了验证 DeepSeek 在知识融合方面的能力，我们提供了另一篇关于 NebulaGraph 的文章，并要求其在现有图谱基础上进行融合。

> 接下来，我会给你另一篇文章。请尽可能使用现有的表结构，对图谱进行融合。如果涉及到表结构变更，请使用 ALTER 进行表结构的修改

只有一篇文章，看起来有些单调。于是从百度百科中，查了下【NebulaGraph】及图中节点【360】的词条，并将概述部分输入，得到以下回应：

### **NebulaGraph 词条**

```
-- 结构变更1：为product标签增加版本和时间属性
ALTER TAG product ADD (license string, current_version string, release_date string, last_updated string);

-- 结构变更2：新增开发关系类型
CREATE EDGE IF NOT EXISTS developed_by();

-- 数据更新 - 补充产品属性
INSERT VERTEX product(name, description, license, current_version, release_date, last_updated) VALUES 
"NebulaGraph":("NebulaGraph", "分布式图数据库", "Apache 2.0", "v3.3.0", "2019-05-15", "2022-11-14");

-- 新增开发公司（复用company标签）
INSERT VERTEX company(name) VALUES
"Yueshu":("杭州悦数科技有限公司");

-- 新增特性（复用feature标签）
INSERT VERTEX feature(name) VALUES
"acl_mechanism":("ACL机制"),
"linear_scaling":("线性扩容"),
"data_recovery":("数据恢复"),
"htap":("HTAP混合负载"),
"nGQL_language":("nGQL查询语言");

-- 关系建立（复用已有关系类型）
INSERT EDGE has_feature() VALUES
"NebulaGraph"->"acl_mechanism":(),
"NebulaGraph"->"linear_scaling":(),
"NebulaGraph"->"data_recovery":(),
"NebulaGraph"->"htap":(),
"NebulaGraph"->"nGQL_language":();

-- 新增开发关系
INSERT EDGE developed_by() VALUES
"NebulaGraph"->"Yueshu":();

```

**360 词条**

```
# 结构变更1：为company标签增加创始人、成立时间和收入属性
ALTER TAG company ADD (founder string, founded_date string, revenue double);

# 结构变更2：新增事件类型TAG
CREATE TAG IF NOT EXISTS event(type string, date string, amount double, details string);

# 数据更新 - 补充360公司信息
INSERT VERTEX company(name, founder, founded_date, revenue) VALUES 
"360":("奇虎360", "周鸿祎", "2005-09", 116.15);

# 数据插入 - 产品生态（复用product标签）
INSERT VERTEX product(name) VALUES
"360_Security_Guard":("360安全卫士"),
"360_Browser":("360安全浏览器"),
"360_Cloud":("360安全云");

# 数据插入 - 重大事件（使用新增event标签）
INSERT VERTEX event(type, date, amount, details) VALUES
"acquisition_360.com":("域名收购", "2015-02-04", 1700.0, "1.1亿人民币收购360.com"),
"privatization":("私有化", "2015-12", 9300.0, "93亿美元私有化交易");

# 关系建立 - 复用developed_by边连接产品
INSERT EDGE developed_by() VALUES
"360_Security_Guard"->"360":(),
"360_Browser"->"360":(),
"360_Cloud"->"360":();

# 新增事件关联（复用has_feature边表达事件关联）
INSERT EDGE has_feature() VALUES
"360"->"acquisition_360.com":(),
"360"->"privatization":();

# 复用used_by边表达合作伙伴关系
INSERT VERTEX company(name) VALUES
"Internet_Society_China":("中国互联网协会");

INSERT EDGE used_by() VALUES
"360"->"Internet_Society_China":();

```

从脚本上看，在当前步骤中，product 表、company 表的字段不够用，DeepSeek 也遵照了我们的指令，在原有基础上做了表结构的修改。有点缺陷的是注释符 -- 不符合语法结构，手动批量替换成 #。

同样执行到数据库中，效果如图：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d3.webp)

在以上两步的试验中，基本上确定了 DeepSeek 在图谱生成及知识融合方面已经能够做到很不错的效果。整体输出效率提高但也有花时间的点：服务太火爆，服务器无法响应的问题；另一个花时间的是，schema 是异步生效，两个层次的脚本执行之间，需要有一段等待。

# ****▌三、无中生有****

在没有具体文章的情况下，我们要求 DeepSeek 根据给定的主题（农业）生成知识图谱。此时新开了一个对话，也新开了一个图空间。当前任务主要是空手套白狼，啥文章都不给。生成的代码基本上都差不多就不贴了，一会儿直接看效果。

> 我想要构建一个农业相关的知识图谱。用的数据库是 NebulaGraph，请帮我生成 nGQL 脚本。表名用大驼峰，属性名用小驼峰。为了规避使用到关键字导致语法错误，schema 的名称需要使用``进行包裹。至少需要生成 3000 个节点。

这边碰到的问题是，一次生成 3000 个节点，他拒绝了我的请求，并丢给了我一段 python 导入 csv 的代码。其中这次依然产生了注释符出错的问题，于是单独把这个问题单独拎出来说，

> 注释需要使用 #，另外我不希望提供出 python 代码，现在也不要求 3000 个节点了。给我 50 个节点的全部 ngql 脚本

果然有问题不憋着，整个人都神清气爽。

```
#=======================================
# 创建图空间
#=======================================
CREATE SPACE `Agriculture` (vid_type = FIXED_STRING(32));
USE `Agriculture`;

#=======================================
# 定义标签 Schema（大驼峰命名）
#=======================================
CREATE TAG IF NOT EXISTS `Crop` (
  `cropId` int,
  `cropName` string,
  `growthPeriod` int,
  `suitableTemp` string,
  `yieldPerMu` float
);


/* 此处省略好多脚本 */

```

> 请对已经有的数据进行补充，尽可能使得现有数据之间的关联性更强

> 请帮我将【界门纲目科属种】这些分类组织成图谱

> 请对现有作物，找出一些轮种的禁忌跟有增益的农作物

> 请结合图谱中的作物出发组织数据，并按之前的形式，给我一些 nGQL 脚本

聊着聊着，DeepSeek 有点串台了，INSERT 语句使用了 MATCH WHERE INSERT 形式的 cypher 语法。

> 上述插入语句并不符合 nGQL 语法哦，请再改一改，并重新组织。DDL 放前面，DML 放后面

> 关于轮作的正负向数据再帮我多生成一些，重点罗列常见的经济作物。

> 关于轮作的正负向数据再帮我多生成一些，这次主要集中在家常菜

经过几轮用大白话的沟通之后，得到了以下数据量：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d4.webp)

随便展开了几个节点之后的效果：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d5.webp)

我们单以临期种植的增产组合为例，效果如下：

![图片](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/deepseek%202-8/d6.webp)

# ****▌四、总结与展望****

通过上述实验，我们验证了 DeepSeek 在知识图谱构建和融合方面的能力。实验结果表明：

**1\. 知识提取能力：**

-   DeepSeek 能够高效地从文本中提取关键信息，并生成符合要求的 nGQL 脚本。其语言理解能力较强，能够准确识别实体、关系和事件。

**2\. 知识融合能力：**

-   在多篇文章的知识融合方面，DeepSeek 表现出色。它能够根据新文章内容对现有图谱进行扩展和更新，确保图谱的完整性和准确性。

**3\. 无中生有构建图谱：**

-   在没有具体文章的情况下，DeepSeek 也能根据主题生成知识图谱。虽然在生成过程中存在一些语法问题，但经过调整后能够生成符合要求的脚本。

**4\. 技术细节：**

-   在实验过程中，我们发现 DeepSeek 生成的脚本存在一些语法问题，如注释符不符合 nGQL 规范等。此外，生成大量节点时可能会出现服务器响应延迟的问题。这些问题需要在实际应用中加以优化。


引用\[1\]:

[https://www.zhihu.com/question/361137050/answer/3186161914](https://www.zhihu.com/question/361137050/answer/3186161914)



DeepSeek 在构建知识图谱的能力，并通过一系列实验验证其在知识提取、图谱融合以及无中生有构建图谱方面的表现。

从 0 到 3000 节点: 我用 DeepSeek + NebulaGraph 构建农业知识图谱

**摘要**

在当前数据驱动的时代，图数据库与大语言模型（如GPT）正逐步融合，为复杂业务场景提供更为智能和灵活的解决方案。通过结合传统的图关系查询方法和新兴的 RAG、Agent 技术，应用平台不仅能够支持结构化数据的查询，还能在非结构化和半结构化数据的分析中发挥重要作用。尤其在风控领域，随着图数据库的规模化和大语言模型的推理能力的提升，系统能够实时响应复杂的风险场景，提供个性化的决策支持。未来，随着交互式查询和智能分析的进一步发展，图谱技术将在各种行业中大显身手，推动自动化和智能化的转型，提升数据分析和决策的效率和准确性。

1.在 NebulaGraph 上构建应用风控图谱的成熟实践

2.LLM 基于图可以做什么？

3.NebulaGraphRAG 应用平台和开发者 SDK

4.提问回答




# 一、在 NebulaGraph 上构建应用风控图谱的成熟实践


在当今数据驱动的世界中，图数据库作为一种强大的数据结构，凭借其高效的查询性能和灵活的关联分析能力，正日益成为金融、风控等领域的核心技术之一。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%871.png)


NebulaGraph 是一款开源的超大规模图数据库，支持毫秒级延迟，采用分布式架构，能够保证在大规模数据环境下的高效查询和高可用性。NebulaGraph 5.0 商业版目前尚未开源，是业界第一家原生支持 ISO GQL 的图数据库。

接下来分享 NebulaGraph 在风控领域的一些成熟实践。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%872.png)


在金融实时风控场景中，图数据库可以帮助实时监控和分析交易行为。以商户付款为例，当用户进行支付操作时，这个行为就形成了一个付款关系。在这种场景下，实时风控要求在用户付款的几秒钟内完成风险判定，并做出相应的处理决策。因此，对图数据库查询性能的要求极为高效，必须具备毫秒级响应能力。客户基于 NebulaGraph 构造了百亿级反欺诈图，以满足实时风控需求。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%873.png)


除了实时分析交易行为，还需要对已经落库的数据进行查询，图数据库可以实现实时查询与离线计算的融合。传统数据库中的数据通过 ETL 流程导入图数据库，进而可以执行更复杂的分析计算。例如，在进行社区检测等需要大量计算的任务时，图数据库能够高效处理异步操作和大规模数据计算。在图数据库中，我们可以执行更复杂的计算任务，如：

* 社区检测： 通过分析客户之间的关系网络，检测潜在的虚假账户群体。
* 路径分析： 通过分析用户行为路径，识别出不合规或异常行为模式。
* 行为模式识别： 通过对用户行为的深入分析，识别出潜在的欺诈行为或恶意攻击模式。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%874.png)


在欺诈分析中，图数据库提供了强大的图指标分析能力。例如，在发卡风控场景中，通过分析申请人的单位、家庭、设备等维度的关联，图数据库能够构建一个业务知识图谱。该知识图谱不仅能够识别欺诈行为，还能够揭示异常的申请人模式。例如，某些账号可能存在相似的行为模式，或不同账号之间的关联性异常，这些都可以通过图算法识别出来。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%875.png)
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%876.png)



平台分析模块中，提供了快速构建图谱规则和指标定义的能力，可以快速将各类业务逻辑进行转换，并基于规则对指标进行计算分析。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%877.png)



更进一步，图数据库还可以应用社区检测算法。通过客户关系、转账IP、设备号、联系电话等多个维度，将客户划分为多个社群，并计算各个社群之间的关联强度。通过这些社群指标，能够有效挖掘可疑个体，提升风控规则的覆盖率和准确性。


# 二、LLM基于图可以做什么？


随着人工智能技术的不断发展，大模型在多个领域的应用逐渐显现出强大的潜力。对于图数据库而言，如何将大模型与图数据库结合，成为进一步提升查询能力和决策支持的关键。

一方面，基于图数据库的图结构，可以作为输入提供给大模型，使大模型具备理解和操作图的能力。另一方面，利用大模型，可以在图数据库上执行更加智能的查询，并进行深度分析。


## 1.Text to GQL
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%878.png)



最直接的一个应用方式就是 Text to GQL. 目前，利用大模型的代码生成能力，已经有很多成熟的 Text to SQL 应用。过去图数据库查询没有统一的语言，现在有了 ISO GQL, 通过标准 GQL 数据的累积，可以训练大模型，使其能够提供 Text to GQL 的能力，从而实现直接使用自然语言进行图数据库查询。在当前 Text to GQL 能力不足的情况下，可以利用规则对代码进行校正，以提高准确率。


## 2.让 Agent 理解图谱
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%879.png)



进一步，大模型要能够理解从图数据库读取到的数据。读取到的点边关系，可以序列化为 text, 输入大模型，再加上一些 prompt 提示大模型其语义，以便大模型更好地理解数据。


## 3.Chain of Exploration 探索链

![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%8710.png)


结合查询和理解图的能力，就可以构成一个“探索链”（Chain of Exploration）。大模型可以通过制定探索计划，逐步执行查询任务，形成一个闭环。具体来说，首先，大模型会根据给定的任务，制定查询计划，确定查询的子图或路径；然后，大模型执行查询，获取结果，并进一步分析这些结果。基于这些分析，模型可以继续调整查询策略，直到达到预期目标。

这种方法不仅仅是单次查询的执行，更是一个持续优化和反馈的过程，形成了一个智能化的查询与决策链条。通过不断的迭代，图数据库能够与大模型结合，实现更高效、更智能的查询和数据分析。


## 4.从非结构化数据到半结构化知识图谱
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%8711.png)

除了结构化数据，对于非结构化数据（如文本、图片、音频等），也可以提取成知识图谱的形式，再利用结构化查询的能力进行查询。



通过文本抽取技术，可以将文本数据转化为三元组（如 "Harry Potter", "has parents", "James Potter"），这是最基本的知识图谱表示方式。这样的三元组可以通过图数据库进行存储和查询，以便提取出其中的关系和实体。

然而，对于一些复杂的场景，不仅是简单的三元组，还需要考虑节点和边的类型，以及附带的时间、位置等属性。这就产生了半结构化知识图谱的概念，即图谱中的数据虽然大部分还是来自于文本，但它已经包含了某些结构化的信息，例如时间戳、实体类型等。例如，“Harry Potter”可能有多个类型的关联（Person、Location、Book等），而这些关系和属性可以帮助在查询时进行过滤。

这种半结构化知识图谱不仅能够表示实体及其关系，还能通过带有时间、地点等属性的附加信息来进行更复杂的查询。例如，在风控场景下，我们可以根据时间区间或地点限制来查询某些特定行为是否发生过，从而提高查询精度。
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%8712.png)


构建图谱类型可以按两个维度划分为四个区间，如上图所示。一个维度是领域特定型或通用型，领域特定指的是有明确的点边类型，而通用则是无明确类型，介于两者之间也有一些半结构化的类型，比如带有类型和属性，但主要信息在文本中。另一个维度是分析型或知识型，分析型是利用大模型生成 GQL 查询语句，获得结构化的查询结果；而知识型更注重总结查询结果的能力，以自然语言的形式给出总结报告。


## 5.图谱的分层管理
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%8713.png)



在 NebulaGraph 中可以实现图谱的分层管理。如上图中所示，红色点为 Harry Potter 小说，黄色点是由小说切分出的 text 片段，绿色点是基于黄色点的片段中抽取出来的知识图谱，最后蓝色点是从知识图谱中获取的一些结构化的洞见。

这里得到蓝色点采用的方法是微软的 From Local to Global 的方法。该方法是在知识图谱上，通过社区检测划分出不同的社区，进行分层总结，从而在半结构化知识图谱中隐式地提取出图结构信息。

NebulaGraph 作为一款数据库，还需要提供数据库相关操作和管理的能力。在 NebulaGraph 上，可以实现元数据、原始数据、索引、知识图谱、知识报告的统一存储、统一管理。例如，黄色点这些文本 chunks 中带有 embedding 信息，可以进行向量检索，实现传统 RAG；在绿色点上，可以做 Text to GQL，实现知识图谱的查询；而在蓝色点上进行向量检索，则可以获得经过总结的具有全局视野的结果。

除了查询方面的能力，基于统一存储，还可以实现便捷的增删改操作。例如，如果需要删除某个节点，可以同时删除与之相关的边和子图，从而保证数据的一致性和完整性。


# 三、NebulaGraphRAG 应用平台和开发者 SDK


最后，介绍一下 NebulaGraphRAG  应用平台和开发者 SDK.
![](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/LLM/%E5%9B%BE%E7%89%8714.png)


NebulaGraphRAG 应用平台，是类似于传统 RAG 的基于图谱的问答系统。当然，我们也意识到问答形式的局限性，因此也在考虑扩展更多交互形式，提升系统的灵活性和用户体验。

图数据库与 RAG 结合的优势在于，不仅能够进行结构化的数据查询，还能够支持更复杂的全局性分析和推理。通过 GraphRAG 的支撑，能够为用户提供更加丰富的信息处理能力。

未来，系统会在已有的结构化图谱基础上，进一步扩展功能，使其能够支持智能分析。具体而言，利用 Agent 技术来调用规则库，可以自动化处理复杂的业务规则，并根据查询结果做出相应的推理和决策，从而进一步提升风控和其他业务分析的智能化水平。同时， Graph 与交互系统的深度集成将由开发者工具SDK提供全面支持，确保开发者可以在平台上高效构建自己的应用。


# 四、提问回答


**前端集成LLM和Agent功能**

**问题**：是否考虑将 LLM 或 Agent 功能集成到前端界面，如 explorer 工具中，以便提升用户体验。

**回答**：目前有可能实现这种集成，尤其是在 explorer 工具中，作为前端的一个载体，便于展示和使用 LLM 及 Agent 功能。

**GraphRAG 的成本和效益**

**问题**：GraphRAG 如何解决成本问题，特别是在与传统向量嵌入（Vector Embedding）方法的比较下，是否更具优势。

**回答**：GraphRAG 并不完全取代传统向量嵌入，而是作为一种增强手段，特别是在结构化查询能力和全局性问题的解决上有独特优势。通过构建知识图谱和社区报告（community report），GraphRAG 能够有效处理复杂的关系和全局性问题，其构建过程可能较为昂贵，但查询成本相对较低。此外，可以通过延迟构建和选择较小的模型来优化成本，平衡效果和性能。

**构建社区报告的成本优化**

**问题**：构建多个社区报告时，如何避免频繁的 API 调用和数据更新带来的高成本。

**回答**：为了减少成本，可以采用“懒加载”策略，在真正需要时才生成社区报告。此外，对于数据更新所需的整个图重建问题，可以通过量化数据失效的程度来降低重建频率。例如，当图中的数据失效程度低于一定阈值时，可以容忍其不重建，降低系统负担。



> 本文源自 DataFun Summit 2024 上@BeautyyuYanli的分享，由 DataFun 志愿者陈思永整理成文。





讨论在 NebulaGraph 上构建应用风控图谱的成熟实践、LLM 基于图可以做什么、NebulaGraphRAG 应用平台和开发者 SDK 三大问题

NebulaGraph + LLM 处理风控知识图谱的探索和实践

NebulaGraph GenAI Team Leader 古思为最先提出将图数据库与 RAG 结合的想法，并提了第一个PR，将KG-RAG转变为 GraphRAG.本文源自古思为 2024 年 11 月在 DataFun上的演讲

NebulaGraph 的 GraphRAG 进展、实践

**一、简介**

NebulaGraph 是一款开源的、分布式的、易扩展的原生图数据库，能够承载包含数千亿个点和数万亿条边的超大规模数据集，并且提供毫秒级查询。

图数据库在许多业务场景中扮演着重要角色，得益于其独特的数据模型和高效的查询性能。以下是一些常见的图数据库业务应用场景：

-   知识图谱：企业和组织需要从各种数据孤岛中构建领域知识图谱，支持智能问答和语义搜索。
    
-   社交网络分析：社交网络平台需要分析用户之间的关系、兴趣、互动等信息，以提供个性化推荐、广告定向投放。
    
-   金融风控：金融机构需要监测异常交易活动、识别潜在的欺诈行为、评估信用风险。
    
-   推荐系统：电子商务、媒体平台需要根据用户的浏览历史、购买记录等信息，提供个性化的商品或内容推荐。
    

NebulaGraph Cloud 是为 NebulaGraph 设计的全托管云服务，**本文将结合亚马逊云科技的产品，详细介绍如何实现降本增效。**


**二、NebulaGraph Cloud**

**平台架构**

![image|561x499](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/9da20f7acfd239dc38ee3ecc5f3bd1be4ceac701_2_561x499.jpeg)

NebulaGraph Cloud 基于 K8S 设计和构建 ，背后有以下因素：

-   K8S 的 Opertor 模式使得集群内部发生的一切可以被自动化，降低开发成本。
    
-   K8S 提供了一系列抽象能力，用于简化计算、存储和网络资源的管理，可以帮助用户避险厂商锁定，做到 100% Cloud agnostic。
    
-   K8S 内置的扩缩容、调度框架、资源监控、服务发现等能力，可以将各种管理操作变的更容易。
    

**服务组件**

NebulaGraph Cloud 由两部分构成：

**控制平面（Control Plane）**

提供用户控制台访问，包括组织管理、用户权限控制、数据库管理、网络安全设置、监控、告警等功能，帮助用户管理他们的 NebulaGraph 集群。

**数据平面（Data Plane）**

接收控制平面下发的指令，包括资源调度、配置、版本更新、水平扩缩容、规格调整、备份和恢复、可观测性、计量等功能。

**成本优化设计**

以数据库的配置示例来说明：


```
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: Database
metadata:
  name: db123456
  namespace: db123456
spec:
  provider: aws
  region: "us-east-2"
  k8sRef:
     name: "k8s-ml65nmjg"
     namespace: "k8s-ml65nmjg"
  tier: standard
  graphInstanceType: NG.C4.M32.D0
  graphNodes: 1
  StorageInstanceType: NG.C4.M32.D50
  StorageNodes: 1
  version: v3.8.2c
```


数据库实例使用 CRD Database 定义，它在数据平面的管理操作由控制器 database-controller 负责。

对于依赖的计算资源通过 CRD NodePool 定义，**NodePool 是对各个云厂商计算资源的抽象，在 Amazon EKS 中用于管理 NodeGroup。**

前文提到 NebulaGraph 是计算-存储分离的架构，所以一个数据库实例会对应两个 NodePool 对象。

```
# Graph 资源池
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: NodePool
metadata:
  name: gnp-7d0b156e
  namespace: db123456
spec:
  databaseRef:
    name: db123456
    namespace: db123456
  instanceCount: 1
  instanceType: x
  k8sRef:
    name: k8s-ml65nmjg
    namespace: k8s-ml65nmjg
  labels:
    platform.nebula-cloud.io/database-name: db123456
    platform.nebula-cloud.io/graph-pool: db123456-f24a
  provider: aws
  region: us-east-2
  zoneIndex: 0
  
# Storage 资源池
apiVersion: apps.nebula-cloud.io/v1alpha1
kind: NodePool
metadata:
  name: snp-59e9cc63
  namespace: db123456
spec:
  databaseRef:
    name: db123456
    namespace: db123456
  instanceCount: 1
  instanceType: x
  k8sRef:
    name: k8s-ml65nmjg
    namespace: k8s-ml65nmjg
  labels:
    platform.nebula-cloud.io/database-name: db123456
    platform.nebula-cloud.io/Storage-pool: db123456-un6g
  provider: aws
  region: us-east-2
  zoneIndex: 0
```

**规格调整**

选择合适的实例规格对用户和服务商都是一个比预期更具挑战性的任务。用户通常不清楚他们需要多大的实例，例如，当用户的数据从100 GB 逐渐增长到 1 TB 时，他们可能不清楚这些数据在每个阶段需要多少 CPU 核心或多大内存。这就需要用户和 SA 共同努力来找出答案。

在使用全托管云服务时，我们提供实例规格调整功能，支持对 Query 节点或者 Storage 节点单独调整，以满足用户在成本控制和性能达标方面的需求。用户可以根据监控面板的历史曲线判断是否达到单节点处理瓶颈，同时云平台也会发出站内告警。

![image|690x225](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/f5f5f6a57a63973e531106af4a1391e834c63d09_2_690x225.png)


**水平扩缩容**

水平扩缩容支持对 Query 节点或者 Storage 节点单独调整。**Query 节点可视为无状态服务，在处理查询流量波动时可通过扩缩容来解决。**

Storage 节点负责存储图数据并提供读写能力，每个 Storage 节点上都分布一定数量的数据分片。每次进行扩缩容都会涉及数据迁移及数据分片再均衡，因此需要谨慎操作。

节点扩容前需要准备相应的计算资源，控制器 database-controller 会将当前期望的节点数下发给 infra-controller 触发 Amazon EKS 的 NodeGroup 扩容，这里我们**没有启用 CA 或者 Karpenter 有以下原因：**

-   扩缩容决策依赖于特定的集群条件和资源请求，如果这些条件没有得到满足，它可能不会执行预期的扩缩容操作。
    
-   跨可用区场景下无法保证指定区域的扩缩容。
    
-   基于 Pending Pod 的模式跟我们的业务系统无法紧密集成。
    
![image|690x216](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/753847db27e05d64ab3f647df0523610bdbbb87c_2_690x216.png)


**自动弹性伸缩**

通过自动扩容/缩容支持不同的工作负载是我们的一个重要目标。由于计算和存储是分离的，我们可以根据每个服务节点的利用率来增加或减少 CPU 和内存资源。

弹性伸缩服务架构如下：

![image|690x278](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/c8ff42ffa7adc0f30c46e9d1618dd8a09d92748b_2_690x278.jpeg)


每隔 10 分钟，弹性伸缩服务就会根据监控数据的历史和当前值计算数据库实例应分配的资源量，最终确定是否应增加或缩减计算资源。

**它可以驱动水平扩缩容和垂直扩缩容（调整实例规格），确保业务高峰时能提前弹出来。** 我们在此基础上将继续不断改进，通过纳入更多指标和主动预测策略来缩短扩缩容的时间。

**三、效率提升设计**

**网络安全访问**

![image|690x228](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/b49d9f8193e3bde0f05041a65507764da8955fea_2_690x228.png)


**目前我们为用户提供两种网络连接方式：网络白名单和 Privatelink 私网连接。**

为了确保网络安全并简化配置步骤，我们在数据库实例与网络负载均衡（NLB）之间引入了代理服务 ngproxy，充分利用了 NLB 提供的功能。NLB 支持在通过的每个报文上设置 PPv2 header，ngproxy通过解析报文可以知晓用户端的 endpoint ID 与在控制台设置的 ID 是否一致，不匹配则会拒绝请求。同样的原理也适用于公网访问的白名单，只有当源地址与白名单中的地址匹配时，才会被允许通过。

**备份和恢复**

**数据备份是防止数据丢失的第一道防线。** 无论是因为硬件故障、软件错误、数据损坏还是人为操作失误，备份都可以确保数据的安全。

我们为用户提供手动备份和定时备份两种方式，将备份数据上传到亚马逊云科技的对象存储Amazon S3。我们没有采用基于云存储快照的备份恢复方案，因为基于 SST 的备份恢复速度比云存储快照更快，而且不需要依赖云厂商的基础服务。需要注意的是，在进行数据备份时 DDL 和 DML 语句将会被阻塞，因此建议在业务低峰期执行备份操作。

备份数据目录结构：

```
backup_root_url/
- BACKUP_2024_08_20_16_31_43
├── BACKUP_2024_08_20_16_31_43.meta
├── data
│   └── 10.0.0.12:9779
│       └── data0
│           └── 5
│               ├── data
│               │   ├── 000009.sst
│               │   ├── 000011.sst
│               │   ├── 000013.sst
│               │   ├── CURRENT
│               │   ├── MANIFEST-000004
│               │   └── OPTIONS-000007
│               └── wal
│                   ├── 1
│                   │   ├── 0000000000000000001.wal
│                   │   └── 0000000000000000005.wal
.....
│                   ├── 30
│                   │   ├── 0000000000000000001.wal
│                   │   ├── 0000000000000000004.wal
│                   │   └── 0000000000000000005.wal
└── meta
    ├── __disk_parts__.sst
    ├── __edges__.sst
    ├── __id__.sst
    ├── __indexes__.sst
    ├── __index__.sst
    ├── __last_update_time__.sst
    ├── __local_id__.sst
    ├── __parts__.sst
    ├── __roles__.sst
    ├── __spaces__.sst
    └── __tags__.sst
- BACKUP_2024_08_20_19_02_35
```

恢复数据时采用恢复至新实例的方案，这样可以充分利用云上资源弹性扩展的优势，在指定某个时间点的备份集后快速拉起一个新的数据库实例，用户在验证新的数据库实例工作正常后可以释放掉旧实例。

**高可用性**

针对那些对服务可靠性要求极高的用户，我们提供了跨可用区容灾解决方案。

在 NebulaGraph 中 Zone 是服务节点的集合，它将多个 Storage 节点划分成可管理的逻辑区域，实现资源隔离。同时，平台服务会控制 Query 节点访问指定的 Zone 内的副本数据，从而降低跨可用区通信产生的网络延时与流量成本。

管理有状态服务跨可用区的一个主要挑战是存储卷的区域亲和性问题。为了解决这个问题，我们采取了在每个可用区放置一个 NodeGroup 的方法。这样一来，就可以避免新扩容的 Node 可能被错误地安排在不正确的可用区中，从而导致 Pod 无法被调度的情况发生。

根据过往用户案例中的经验，我们还支持在某个可用区单独扩容的方案。云原生社区类似 HPA 的方案，只解决了扩容后的数量问题，但是无法扩容到指定区域。根据每个区域承载的业务流量进行扩展，可以有效地提高服务质量。如果某个区域观察到 QPS 突然激增，数据平面的弹性伸缩服务将允许在此区域缩放 Query 节点。

![image|690x309](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/ead9f0ff2d6e68afb9a05dbdc2ec418e60590178_2_690x309.png)


**四、云上实战**

在开通订阅后开始创建数据库，接下来演示访问数据库的几种方式：

**可视化工具**

从 Database 列表选中某个实例，进入 Data->Graph 图空间管理，点击 Explorer Graph 进入可视化应用。

![image|690x198](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/ce7ed2c9cfab7106e383bd3424e40c8237588324_2_690x198.png)


点击右上角的 Console 打开控制台便可以执行 GQL 语句的查询。

![image|690x359](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/b097fa13dfc3ad0490e89138ee5c00e68c4d585f_2_690x359.png)


**网络白名单**

在数据库实例的 Overview 页面点击 Connect，选中 Public 方式。

![image|644x499](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/90dc038f3a3e9714718599fc876fdfead128eb83_2_644x499.jpeg)


在没有配置网络白名单时，数据库实例无法直接从公网访问。

```
$ ./nebula-console -addr nebula-graph-ncqqo19eh0aus73e4un6g.aws.cloud.nebula-graph.io -port 9669 -u dbaas-test@vesoft.com -p $PASSWORD -enable_ssl

Welcome!

(dbaas-test@vesoft.com@nebula) [(none)]> show spaces;
+------------------------+
| Name                   |
+------------------------+
| "genshin"              |
| "hanxiaotest"          |
| "movie_recommendation" |
| "nba"                  |
+------------------------+
Got 4 rows (time spent 602µs/222.883326ms)

Mon, 02 Sep 2024 16:52:39 CST
```


**Privatelink 私网连接**

按照 Create Private Link Endpoint 的配置步骤，确定业务所在的 VPC ID 和 Subnet ID。

运行命令创建 Endpoint：
```
aws ec2 create-vpc-endpoint --vpc-id <YOUR-VPC-ID>  --region us-east-2 --service-name com.amazonaws.vpce.us-east-2.vpce-svc-04f25889c855f891b --vpc-endpoint-type Interface --subnet-ids  <YOUR-SUBNET-IDs>
```

登录亚马逊云科技控制台查看 Endpoint 状态：

![image|690x212](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/1fe27de7e96f4deb53862da71dbcbbe02a8f6afb_2_690x212.png)


在业务 VPC 内测试访问是否正常。

![image|690x146](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/cb5260250eb6c4b416f9578ffa1d4106d5be1291_2_690x146.png)


接下来大家可以按照自己的业务需求通过官方生态工具在云上进行数据维护。

**五、总结与展望**

本文介绍了基于云原生理念在亚马逊云科技上的服务落地 NebulaGraph 全托管云服务的架构细节，**着重阐述如何通过亚马逊云科技的产品为用户带来实质利益，为用户在云端使用 NebulaGraph 提供兼具成本和弹性优势的全新解决方案。**

在确保服务质量的同时，我们将继续探索各种可能性，降低用户成本并提高易用度。我们的目标是让用户只需为其使用的资源付费，将成本概念贯彻到每一个细节中。

**目前 NebulaGraph Cloud Beta 版本试用活动正在火热进行中，** 每月最高消费控制在1美元以内，大家可以通过以[下链接注册账号](ttps://aws.amazon.com/marketplace/pp/prodview-wctboqxrwqkjy?sr=0-1&ref_=beagle&applicationId=AWSMPContessa) 或[直接访问注册账号](https://cloud.nebula-graph.io)。

欢迎对 **NebulaGraph Cloud** 感兴趣的小伙伴添加小助手 NebulaGraphbot(wechat) 解锁更多 DBaaS 相关内容。

只要1$ 解锁 NebulaGraph on AWS，通通1$

全托管 NebulaGraph 试用活动进行中！解锁成本优化与效率提升的实践指南


自 2023 年 8 月 **NebulaGraph** 和 **LlamaIndex** 共同推出 [Graph RAG](http://mp.weixin.qq.com/s?__biz=Mzg4OTg0MzY0Mw==&mid=2247508410&idx=1&sn=a0432b3bbeac4e60a43c320f88201e81&chksm=cfe75b6ef890d278dedc9685b25459aa6bd7186ae06ea76f861f9c92964a4a0177cd1f818741&scene=21#wechat_redirect) 以来，凭借着 **LLM（大语言模型)**  和 **RAG（检索增强生成）** 的发展势头，在业界掀起了一场革命。通过本文，我们将向你介绍什么是 Graph RAG，为什么它具有革命性，以及如何构建你的Graph RAG，来利用数据的上下文与 NebulaGraph 回答复杂的多部分问题。

## 了解日益流行的 Graph RAG

Graph RAG 能够将知识图谱与大语言模型（LLM）结合使用，从而为搜索引擎提供更全面的上下文理解。由于其带来了更具成本效益、更智能且精确的搜索结果，这项技术已引起了广泛的关注。除了提供更准确的回答以建立用户信任外，Graph RAG 还克服了传统搜索增强技术的主要障碍：缺乏上下文理解和数据训练。因此，这些先进的检索增强技术有望扩展到各个行业，如医疗诊断辅助、内容创作和推荐、互动游戏以及知识图谱构建。

微软在由高级首席数据架构师 Jonathan Larson 和首席项目经理 Steven Truitt 撰写的博客文章《GraphRAG: Unlocking LLM Discovery on Narrative Private Data》中强调了 Graph RAG 的重要性。他们通过将 Graph RAG 与基线 RAG 系统进行对比，展示了 Graph RAG 的有效性，得出结论认为 Graph RAG 方法使LLM能够在图谱中找到支点，从而提供包含原始支持文本的更优答案。而基线 RAG 在处理需要跨数据集汇总信息以形成答案的查询时则显得力不从心。
**NebulaGraph 数据库已经集成了 LlamaIndex 和 LangChain 等大语言模型（LLM）框架** ；你只需专注于 LLM 编排逻辑和管道设计，无需担心复杂的实现。你可以通过简单的四个步骤进行试用，检查 Graph RAG 是否如传言般出色，然后再进一步将其集成到应用程序或其他场景中。

**注意：**

由于 LlamaIndex 的快速发展，最近的重构/重大变更导致一些 Graph RAG 教程无法运行。本文提供了更新后的 Graph RAG 教程，以便你可以无误地进行操作。

我们在上游发布之前已经探索了许多内部方法。我们相信 LlamaIndex 中Graph + RAG 的基本概念值得探索，因此我们将原始的工作坊和笔记本放在参考章节中。

**设置你的 NebulaGraph 集群**

* 通过 Google Colab 中的 NebulaGraph Lite 启动 NebulaGraph 集群
* 使用 Docker 扩展部署集群
* 实例化一个 NebulaGraphStore
## 使用 NebulaGrpah 构建你的 Graph RAG
~~~
import os
from llama_index.core import KnowledgeGraphIndex, SimpleDirectoryReader
from llama_index.core import StorageContext
from llama_index.graph_stores.nebula import NebulaGraphStore

os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"
os.environ["NEBULA_ADDRESS"] = "127.0.0.1:9669"


space_name = "paul_graham_essay"
edge_types, rel_prop_names = ["relationship"], ["relationship"]  # default, could be omit if create from an empty kg
tags = ["entity"]  # default, could be omit if create from an empty kg

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags)

storage_context = StorageContext.from_defaults(graph_store=graph_store)
~~~
现在，随着你的 NebulaGraph 集群的设置，可以动手进行知识图谱构建部分。**请确保在 Jupyter 环境中运行以下所有步骤。**

**依赖关系**

Graph RAG 的实现需要以下依赖项：
~~~
pip install llama-index
pip install llama-index-llms-ollama
pip install llama-index-graph-stores-nebula
pip install ipython-ngql
pip install llama-index-embeddings-huggingface
~~~
**创建 LlamaIndex 知识图谱索引**

KnowledgeGraphIndex 可从非结构化文本中自动构建知识图谱，也可基于实体的查询。在创建图 RAG 查询引擎之前，你需要设置 LlamaIndex 知识图谱索引。在这个示例中，我们将演示如何通过创建文档对象来从文本数据构建知识图谱，然后再创建索引。
~~~
from llama_index.core import (
    VectorStoreIndex,
    SimpleDirectoryReader,
    KnowledgeGraphIndex,
)

graph_store.query("SHOW HOSTS")

Settings.chunk_size = 512

documents = SimpleDirectoryReader(
    "data"
).load_data()
~~~
~~~
kg_index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    max_knowledge_sequence=15,
)
~~~
### 创建一个朴素图 RAG 检索器

最后一步是创建 Graph RAG 检索器，在其基础上构建查询引擎，以便您可以使用自然语言问题进行查询。
~~~
from llama_index.core.query_engine import RetrieverQueryEngine
from llama_index.core.retrievers import KnowledgeGraphRAGRetriever

graph_rag_retriever = KnowledgeGraphRAGRetriever(
    storage_context=storage_context,
    verbose=True,
)

query_engine = RetrieverQueryEngine.from_args(
    graph_rag_retriever,
)
response = query_engine.query("What's the relationship between Bob and Alice")
~~~
现在，您已经尝试了 Graph RAG，如果您想进一步了解如何通过 GraphStore 和 VectorStore 进行检索，您可以在此处找到更多演示示例：https://www.siwei.io/tutors/GraphRAG/101.html。

[欢迎加入社区官方 Slack 群](https://join.slack.com/t/nebulagraph/shared_invite/zt-2h51ct4t0-IlXFaU01mpb3t2WgQ8qqNA)。

参考：

* https://bit.ly/graph-rag-workshop
* https://siwei.io/graph-enabled-llama-index/kg_and_vector_RAG.html
* https://siwei.io/demo-dumps/graph-rag/GraphRAG.html

通过本文，我们将向你介绍什么是 Graph RAG，为什么它具有革命性，以及如何构建你的Graph RAG，来利用数据的上下文与 NebulaGraph 回答复杂的多部分问题。

基于 NebulaGraph ，构建属于你的 Graph RAG 

![图数据库和知识图谱](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-1.jpg)

图数据库和知识图谱是管理图结构数据（包括节点（实体）和边（关系））的两大主流方案。图数据库利用基于图的数据模型存储信息，支持通过专用的图查询语言实现对图数据的查询和遍历；知识图谱通过整合推理和派生新知识的机制，增强了图数据库的功能。这种增强的表达力不仅让你能进行更高级的数据分析，还能从图中相互连接的数据点中提取洞察力。

本文将简要介绍知识图谱，再探讨使用 llamaindex 和 NebulaGraph-lite 生成知识图谱。

## 知识图谱是什么

知识图谱是一种图形化的知识表示方法，它将相关联的概念、事物及其关系描绘成一个网络。它涵盖了现实世界中的实体，如物体、人物、地点和事件。知识图谱的核心通常依赖图数据库，图数据库专注于通过存储离散的信息片段及其之间的关联来管理数据。

知识图谱的核心组成部分包括：**实体**是现实世界中的事物或概念，包括人、地点、活动和思想总结。在图型表达中，这是一种可视化数据集之间关系的方式，实体在图中表示为节点。

实体的例子包括：
- 人物：巴拉克·奥巴马、塞雷娜·威廉姆斯
- 地点/位置：纽约市、金字塔
- 事件：第二次世界大战、2008 年经济危机
- 抽象/意识形态：民主、重力

**关系**描述了对象之间的相互作用或联系方式，且展示了它们是如何联系在一起的。在知识图谱中，关系通过边来表示，这些边连接相应的节点。而边的流动方向可以是单向，也可以是双向，这取决于实体关系的性质。

### 知识图谱的分类

知识图谱拥有以下能力：
- 有效管理和可视化异构信息：能够在统一的框架内处理不同系统的数据，实现清晰且深具洞察力的信息展示。
- 集成新的数据资源：知识图谱固有的灵活性，能很好地同新数据源融合，支持知识库的持续扩充。
- 理解并阐释任何存储信息中的关系：能够发现并展示不同信息库中实体之间的关系，从而全面理解潜在的关联关系。

图谱的主要类型：

- RDF（资源描述框架）三元组存储：专注于存储和处理基于 RDF 框架的信息，该框架通过三元组（主体、谓语、客体）来表示知识。
带标签的属性图：专门研究节点和边附带信息标签的图，提供了更为丰富和细致的数据表现。

### RDF（资源描述框架）图

RDF 图，全称资源描述框架图，是用来表示类似网络结构的网络信息的一种方式。基本上，它是一系列围绕主题、谓词和客体组成的声明。以“巴黎是法国的首都”这句话为例，在 RDF 图中，“巴黎”作为主题，“是……的首都”作为谓词，“法国”作为对象（客体）。而这三个元素共同构成了一个“三元组”，代表了一个事实。一个 RDF 图可以包含众多这样的三元组，从而构建成一个互连的信息网络。 

资源描述框架（RDF）三元组存储是一种标准化的知识表示数据模型。在这个模型中，每个元素都通过统一资源标识符（URI）被赋予一个独一无二的标识符。这种机制确保主题、谓词和客体的机器可读性。此外，RDF 三元组存储采用了一种名为 SPARQL 的标准化查询语言，该语言支持从存储中检索数据。得益于数据表示和查询的标准化，RDF 三元组存储能够与其他遵循 RDF 框架的知识图谱实现互操作。

![SPARQL](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-2.png)

上图展示了一个社交网络中的个体（圆形节点 Jack、Joe、Jane），和他们之间的友谊关系（有向连接线 knows）。此外，每个有深色边缘的节点都表示该个体有收入（有向连接线 hasIncome）。菱形节点显示了网络中可能存在的额外数据（三元组）。

RDF 图的优点：

- 互操作性：RDF 是 W3C 的标准，意味着不同的系统可以理解并交换存储在 RDF 图中的数据。这使得它非常适合跨平台和应用程序之间的数据共享。

- 标准化：由于其标准化的格式，RDF 图支持标准查询语言 SPARQL 来探索和分析图中存储的数据。

- 推理与推导：RDF 图能够利用本体（可以视为对概念的正式描述）来进行数据推理。这使系统能够推导出图中没有直接表述的新信息。

- 灵活：RDF 图能够表述多种数据类型和关系，适合模拟复杂的领域和整合不同来源的数据。

### RDF 图的缺点：

- 深度搜索复杂：在大型 RDF 图中进行深度搜索的计算成本可能很高，这可能拖慢需要探索多个连接的查询的速度。

- 结构严格：RDF 数据以“三元组”（主体、谓语、客体）的形式存储，这种结构可能不如其他图模型那样灵活，后者允许对实体或关系本身添加属性。

- 学习曲线陡峭：理解和使用 RDF 需要良好地掌握其基本概念及 SPARQL 查询语言，这对新用户来说可能是一个挑战。

### 带标签的属性图 (LPG)

带标签的属性图（LPG）是一种用于表现具有相互连接的服务及其关系的特殊图数据库模型。以下是其主要特点的详细解释：

- 节点：可表示现实中的男性或女性特征。每个节点都具有独特的描述，并可被赋予一个或多个标签以表明其类型或大小（例如，“人物”、“产品”）。

- 属性：节点可能拥有键值对，用以存储关于该实体的额外信息。这些属性允许对图中的元素进行基本描述。

- 边：表示节点之间的联系，并展示实体间的关系。边与节点类似，可以用多种方式标记（例如，“认识”、“购买”），同时也可以拥有自己的属性。

LPG 的主要特性：

- 丰富的数据结构：节点和边都能拥有属性，与其他模型如 RDF 相比，允许更密集和信息量更大的数据表现。

- 高效的存储与查询：LPG 结构通常能带来高效的存储方式和更快速的图内连接遍历，便于进行查询。

- 灵活：LPG 由于没有预定义的模式，具备很高的灵活性，允许模拟多种数据关系。

### RDF vs 属性图

![RDF vs 属性图](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-3.png)

### 属性图与 LLM 模型结合的智能问答

属性图和大型语言模型（LLM）是两个强大的工具，可以结合使用，从数据中挖掘出新线索。以下是它们如何协作的具体方式：

**数据增强：dou bao z**

- LLM 可用于生成属性图中点和边的文本描述，这样不仅可以丰富数据内容，还能帮助其他工具或用户更加容易地理解各项关系。

- LLM 还可以基于图中已有的数据生成新的点和边，这对于进行异常检测或预测欺诈行为等任务非常有用。

**查询与探索：**

- LLM 可以用来创建查询属性图的自然语言接口，允许用户以比传统的图查询语言更为直观的方式（例如自然语言）对数据进行提问。

- LLM 也能够汇总图查询结果，并为这些发现生成解释。

**推理和推断：**

LLM 可以用于执行属性图上的推理任务，这可能包括基于现有数据推断节点间新的关系，或识别图中存在的不一致。

![LLM](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-4.png)

示例演示：

以下展示了使用 Llamaindex KnowledgeGraphIndex 和 NebulaGraph Lite Reference 结合 Google Gemini LLM 和 Collab 分步实现知识图谱的过程。

### 为 Gemini 生成 API 密钥

前往 https://aistudio.google.com/app/prompts/new_chat 并生成一个新的 API 密钥。

### 加载 PDF 文档

```
! mkdir ad && cd ad
! curl https://arxiv.org/pdf/2106.07178.pdf --output AD1.pdf
! mv *.pdf ad/
! pip install -q transformers

%pip install llama_index pyvis Ipython langchain pypdf  llama-index-llms-huggingface  llama-index-embeddings-langchain llama-index-embeddings-huggingface
%pip install --upgrade --quiet llama-index-llms-gemini  google-generativeai
%pip install --upgrade --quiet llama-index-graph-stores-nebula nebulagraph-lite
```

### 导入谷歌 API 密钥

```
import os

from google.colab import userdata
GOOGLE_API_KEY = userdata.get('GOOGLE_API_KEY')
os.environ["GOOGLE_API_KEY"] = GOOGLE_API_KE

```

### 导入必要的模块和库

```
import logging
import sys

logging.basicConfig(stream=sys.stdout, level=logging.INFO)
logging.getLogger().addHandler(logging.StreamHandler(stream=sys.stdout))
from llama_index.core import (
                         ServiceContext,
                         KnowledgeGraphIndex)
from llama_index.core import SimpleDirectoryReader
from llama_index.core.storage.storage_context import StorageContext
from pyvis.network import Network

from llama_index.llms.huggingface import HuggingFaceLLM
检查支持的 Gemini 模型。本例中，我们将使用 Gemini 1.0 专业版。

import google.generativeai as genai

for m in genai.list_models():
    if "generateContent" in m.supported_generation_methods:
        print(m.name)
        print(m)

from llama_index.llms.gemini import Gemini

llm = Gemini(model="models/gemini-1.0-pro-latest")

```
### 导入 BGE 嵌入

```
from llama_index.embeddings.huggingface import HuggingFaceEmbedding
from llama_index.core import ServiceContext


embed_model = HuggingFaceEmbedding(model_name="BAAI/bge-small-en-v1.5")

```

### 加载广告目录内容

```

documents = SimpleDirectoryReader("/content/ad").load_data()
print(len(documents))

```
###  在本地启动 Nebula 图数据库精简版的 Docker 实例

```
from nebulagraph_lite import nebulagraph_let
n = nebulagraph_let(debug=False)
n.start()

```

### 在 Nebula 存储中设置名为“nebula_ad”的命名空间和节点

```
%ngql --address 127.0.0.1 --port 9669 --user root --password nebula

# If not, create it with the following commands from NebulaGraph's console:
%ngql CREATE SPACE nebula_ad(vid_type=FIXED_STRING(256), partition_num=1, replica_factor=1)

```


```
import time

print("Waiting...")

# Delay for 10 seconds
time.sleep(10)

%ngql --address 127.0.0.1 --port 9669 --user root --password nebula
%ngql USE nebula_ad;
%ngql CREATE TAG entity(name string);
%ngql CREATE EDGE relationship(relationship string);

```
### 将文档数据加载到图数据库中

```
import os
os.environ["NEBULA_USER"] = "root"
os.environ["NEBULA_PASSWORD"] = "nebula"  # default is "nebula"
os.environ[
    "NEBULA_ADDRESS"
] = "127.0.0.1:9669"  # assumed we have NebulaGraph installed locally

space_name = "nebula_ad"
edge_types, rel_prop_names = ["relationship"], [
    "relationship"
]  # default, could be omit if create from an empty kg
tags = ["entity"]  # default, could be omit if create from an empty kg

from llama_index.core import StorageContext
from llama_index.graph_stores.nebula import NebulaGraphStore

graph_store = NebulaGraphStore(
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
)
storage_context = StorageContext.from_defaults(graph_store=graph_store)

from llama_index.core import Settings

Settings.llm = llm
Settings.embed_model = embed_model
Settings.chunk_size = 512

```

### 更新图数据库中的节点数据


```

# NOTE: can take a while!
index = KnowledgeGraphIndex.from_documents(
    documents,
    storage_context=storage_context,
    max_triplets_per_chunk=10,
    space_name=space_name,
    edge_types=edge_types,
    rel_prop_names=rel_prop_names,
    tags=tags,
    include_embeddings=True
)

```

### 检查 Nebula 存储中已插入的图数据

```

# Query some random Relationships with Cypher
%ngql USE nebula_ad;
%ngql MATCH ()-[e]->() RETURN e LIMIT 10

```

### 数据查询与输出：

![v](https://nebula-website-cn.oss-cn-hangzhou.aliyuncs.com/nebula-website-5.0/share/2024-06-28-5.png)

### 现在开始查询索引数据

`query_engine = index.as_query_engine()`

```

from IPython.display import display, Markdown

response = query_engine.query(
    "Tell me about Anomaly?",
)
display(Markdown(f"<b>{response}</b>"))

```

**异常现象（Anomaly），在不同应用领域也可能被称作异常值、例外、特殊情况、稀有现象或新奇现象，它们指的是与常规、标准或预期显著不同的异常对象。**

```
from IPython.display import display, Markdown

response = query_engine.query(
    "What are graph anomolies?",
)
display(Markdown(f"<b>{response}</b>"))

```

图异常可以被定义为结构性异常。

## 小结

这些简单的知识图谱有效地捕捉了实体间的复杂关系，这种能力显著提高了查询和推理的精确性、多样性和复杂性。此外，这些知识图谱还可以扩展应用到基于 RDF 的复杂本体图。欢迎大家动手尝试～👏
参考：

[https://link.springer.com/chapter/10.1007/978-3-642-21295-6_13](https://link.springer.com/chapter/10.1007/978-3-642-21295-6_13)

[https://github.com/nebula-contrib/nebulagraph-lite](https://github.com/nebula-contrib/nebulagraph-lite)

[https://docs.llamaindex.ai/en/stable](https://docs.llamaindex.ai/en/stable)

本文由 Rajesh K 原文发布在 Medium

图数据库和知识图谱是管理图结构数据（包括节点（实体）和边（关系））的两大主流方案。图数据库利用基于图的数据模型存储信息，支持通过专用的图查询语言实现对图数据的查询和遍历；知识图谱通过整合推理和派生新知识的机制，增强了图数据库的功能。