Nebula古思为：GraphRAG NebulaGraph Team 的探索与实战

分享：NebulaGraph Developer Advocat 古思为
整理：墨天轮

导读

在人工智能与大数据的浪潮中，如何更有效地管理和利用复杂的数据关系成为一大难题。图数据库（Graph Database）与RAG检索增强生成（Retrieval-Augmented Generatio）技术的结合，能否为信息检索带来新的突破？

【墨天轮数据库沙龙】邀请到 NebulaGraph 的首席布道师 古思为，为大家带来《GenAI 新范式：GraphRAG NebulaGraph Team 的探索与实战》的主题分享，以下为演讲实录。

古思为
NebulaGraph Developer Advocate

图Graph 是什么

在数据库领域，图的概念对许多人来说应该并不陌生。它起源于100多年前欧洲的一个著名问题——七桥问题。这个问题描述了一个城市中有两条河流和七座桥，探索是否存在一条路径可以不重复地遍历所有桥梁。这个问题最初被称为“七桥问题”，最终通过一篇论文公开解决，并证明了这是不可能的。

这个证明过程实际上是对问题的一个合理抽象，它催生了一个新的数学分支——图论。在图论中，我们将陆地和桥梁分别抽象为点和连接点的直线，即边。研究这些点和边的问题，就是图论的研究内容。

为什么需要Graph

为什么我们需要图论？这个问题看起来可能很抽象，但它是如何与我们的真实世界，尤其是计算机系统联系起来的？对于学过相关专业背景的同学来说，可能已经接触过图论。这里我将快速介绍几个与我们生活息息相关的例子。

首先是知识图谱，这是由Google提出的一个概念，它基于之前的语义网络，并以网状的方式组织知识条目。知识条目之间存在关联，这些关联被称为实体和关系。例如，在Google搜索中，当我们搜索“姚明妻子的年龄”时，会发现这种答案用传统的倒排索引方式是无法检索到的。因此，Google构建了知识图谱来辅助完成这样的查询。

另一个例子是推荐系统。在这里，图论被用来实现一个从给定用户出发，找到他所评分的电影，然后通过反向的边找到具有类似兴趣的人。这些具有类似兴趣的人所高评分的电影，尤其是你尚未观看过的，就会成为推荐给你的可能感兴趣的内容。

社交网络也是一个典型的图论应用场景。例如，微信团队在早期就使用了图论来推荐用户的二度或三度好友。这些好友在图上是没有直接连接的，但与你有共同好友的连接点，从而构成了社交网络中的社交图。在GitHub上，我们可以将项目中的所有组件放在一张图上，从而得到很多有意义的洞察，帮助你识别可能的环节。

最后，图论在欺诈识别场景中也发挥着重要作用。无论是构建电商平台、网络游戏还是内容网站，都可能存在欺诈行为。如果我们在这方面没有作为服务商建立防范措施，最终可能导致不良行为驱逐正当行为。

在这个例子中，我们探讨了如何利用图的模式实现实时在线反欺诈和反洗钱。例如，面对一个群控设备，用户可能使用多张银行卡、多个手机或IP地址、MAC地址访问我们的系统。我们的目标是在图上实时识别出这种模式。这是一个非常典型的图论应用场景。

想象一下，一个供应链管理系统，其中包含了汽车的各个组件和功能供应商。在一张图上，我们可以很容易地可视化这些内部联系。然而，在我们的系统中，这可能是以编程的方式快速利用这些信息。

结合图的大模型场景，这是我们在一年前首次提出GraphRAG时给出的一个例子。这是一个基于Graph的产品的例子。可以看到，右侧是基于图的检索，它获取了很多点和边的文本化信息。左侧是基于图的可视化，这是一个数字营销场景，我们结合了图和地理位置信息，实现了为特定用户推荐的场景。如果大家感兴趣，可以在我的演示中查看，这里就不详细介绍了。

GraphRAG

相信大家对RAG（检索增强生成 Retrieval-Augmented Generation）这项技术已有所了解。在过去一两年间，大型模型为整个计算机系统领域带来了革命性的变化。RAG是一种让大型模型在回答问题时更加精准的技术。在面对复杂问题或特定领域的查询时，模型的预训练知识可能不足以提供满意的答案。这时，RAG通过搜索增强，允许模型访问外部信息源，以补充和丰富其回答。

RAG的工作原理可以这样理解：当模型遇到一个难题，它会自动进行搜索，就像我们在Google上搜索信息一样。这个搜索可能涉及到公开的网络资源，或者我们自己的数据库和知识库。无论是通过SQL查询数据库，还是通过搜索引擎检索非结构化数据，RAG都能帮助模型找到所需的上下文信息。一旦模型获取了相关信息，它就能够结合这些新信息来生成更加全面和准确的答案。这个过程类似于一个学生在开卷考试中查阅资料，RAG让模型在回答问题时有了更多的参考。

在技术层面，RAG通常涉及将知识库中的信息进行向量化处理，以便在查询时能够快速检索到最相关的信息块。这种方法使得模型能够处理那些它原本未曾训练过的问题，从而大大扩展了模型的应用范围。这种常见的机器学习方法，通常称为“分割与嵌入”方法。这种方法的核心思想是通过将信息嵌入到向量空间中，实现快速的语义匹配。

在使用“分割与嵌入”方法时，虽然这种方法在处理语义匹配方面很有效，但它仍然面临许多挑战。其中一个主要的问题被比喻为“大海捞针”，即在庞大的数据中寻找特定信息的困难。

在应用这种方法时，通常会将知识分割成较小的块，并为每一块生成对应的向量嵌入，形成一个向量空间。当我们需要检索相关信息时，会在这个空间中找到最相似的几个向量（例如Top 3或Top 5），从而获取相应的上下文信息。然而，这种分割方法本身存在一定的局限性。如果我们希望获取非常细致的信息，比如查找乔布斯的相关知识，假设我们正在处理的是乔布斯的自传或与苹果公司相关的内容，书中可能有很多涉及苹果公司的片段和细节。在这种情况下，使用分割与嵌入的方法可能难以有效地检索到所有重要的信息。

除了“大海捞针”的问题之外，另一个挑战源自于嵌入模型本身的局限性。通常，在构建这种系统时，我们往往没有资源去定制一个专门的模型，因此大多数情况下只能依赖通用的预训练模型。然而，这些模型在处理一些复杂的领域知识时，可能会出现无法准确表达语义的问题。通用模型的训练通常依赖于广泛的语料库，更多关注字面意思和一般语境，而不一定深入到具体的领域知识。这种“相似但不相关”的现象是通用模型中常见的误差来源之一。

举个例子，假设我们有两篇文章，一篇关于保温杯，另一篇关于保温大棚。尽管“保温”这个词在两者中都出现了，但实际上它们所指的事物和背景是完全不同的。这种误差就是一个典型的“相似但不相关”的场景，也是“RAG”（Retrieve and Generate）全流程中可能产生幻觉的原因之一。

实际上，业内已经有许多方法可以应对之前提到的挑战，例如构建分层结构的索引和使用迭代式方法。这些处理方式能够有效帮助解决我们在使用嵌入模型时遇到的问题。

我们公司专注于图技术，已经从事了多年的开源分布式图数据库的研发。在RAG（Retrieve and Generate）技术还未被称为RAG、而是上下文学习方法的时候，我们就意识到以图的方式处理知识会对解决这些问题有很大帮助。因此，我们率先提出了GrapRAG的方法，并在去年发布了开源实现。其优势在于，图技术可以对数据进行更精细的分割，同时保持全局的上下文信息。例如，将一本书的每一章节中的重要知识点放入图中，保留知识点之间的关联关系。相比于传统的线性切割，这种方法能够更好地维护知识结构。

在使用向量检索时，模型依赖的上下文关联通常是概率性的，这种关联体现在语义理解模型中，但这些模型往往比较简单，智能化程度有限，可控性较低。而通过构建图谱，我们能够建立更确定且高质量的连接，大大减少了因嵌入模型引起的误差。此外，图谱还可以轻松构建全局上下文，从而进一步提升检索精度。

在查询阶段，GraphRAG最典型的检索策略是提取任务中相关的实体，并在图中通过向量语义找到相关实体。然后，根据需要对这些实体进行模式探索，可能是简单的子图，也可能是其他模式，以获取上下文信息。最后，将这些上下文与向量和其他上下文合并，形成最终的结果。这就是GraphRAG方法的基本流程。

GraphRAG 案例

一、GraphRAG 应用案例

接下来，我会为大家介绍一些我们在使用Graph RAG时遇到的实际例子。通过这些例子，你们可以看到GraphRAG的方法不仅局限于文本处理，还能够带来更多的应用价值。

第一个例子是我们之前讨论过的GraphRAG访问日志的应用。在这个案例中，GraphRAG带来了可解释性的提升。由于它是白盒模型，我们可以清楚地解释答案的来源。GraphRAG不仅能提供文本化的解释，还能将我们从Graph探索中获取的上下文信息进行可视化展示，有时这种可视化的呈现能够带来额外的收益。

第二个例子涉及我们前面提到的相似与相关性的问题。虽然我不会详细讨论这个挑战，但你们可以通过下面的链接访问到原始的Demo，进一步了解这一挑战的解决方式。

第三个例子与第二个类似。我们在一个基于中文开源菜谱的项目中，构建了一个问答系统。系统中生成了一个并不存在的菜谱。传统的RAG方法容易在这种情况下产生幻觉，而通过GraphRAG，我们能够有效地消除这种幻觉。我们在去年首次发布GraphRAG方法时，在一个国际研讨会上展示了这个英文版的例子，它也是为了解决幻觉问题而设计的。如果你们有兴趣，可以通过链接查看我们当时的具体实现过程。

然后这个是我们说的“大海捞针”的例子，就是我们说的比较细腻度的知识的索引的一个场景，这里边我们就是骨干方式进行就能捞取到，用vector是捞不到的那些额外的细节，最后我们把它们合在一起的话，这个效果就会更好一些。

GraphRAG不仅能够在大量数据中“海底捞针”，还可以“穿针引线”，这在某些复杂的场景下尤其有用。例如，我们需要回答一个关于金融危机后对银行影响的问题。本质上，这个任务要求我们通过RAG捞取与全球经济危机和某银行信贷策略相关的上下文信息。在这种情况下，我们需要在构建的Graph Index中查找两者之间的所有可能路径，这涉及多跳的关联。如果没有Graph的“穿针引线”功能，传统的方法很难捕捉到这些全局关联的上下文，从而无法提供全面准确的回答。GraphRAG在这种多跳关联的复杂任务中显示出独特的优势，能够有效整合不同节点之间的复杂关系，提供更有深度和广度的答案。

接下来，我们来比较一下GraphRAG与传统的SQL在处理结构化和非结构化数据时的表现差异。我们知道，Graph不仅可以处理非结构化数据，还能应用于结构化数据的场景。在一些涉及复杂关联关系的召回任务中，GraphRAG和传统的文本SQL查询之间的优劣是非常明显的。

另一个有趣的GraphRAG应用场景借鉴了脑科学，特别是海马体（hippocampus）的功能。我们知道，海马体在大脑中负责处理记忆。在这个案例中，研究人员将海马体的结构与GraphRAG结合起来，创新性地构建了一个类似于GraphRAG的系统。

在这个Graph系统中，他们采用了图算法来配置节点的重要性，从而在图状知识索引中标注权重。通过这种方法，他们能够更有效地管理和优化知识的检索过程。标注节点的重要性后，系统在处理复杂的记忆和信息检索任务时显示出了一定的效果提升。这种方法不仅结合了脑科学的原理，还为图模型在知识管理领域的应用提供了新的思路。

二、GraphRAG 分类

三、GraphRAG 很贵？

我们在理解GraphRAG索引的过程中，往往会认为它的代价高昂。实际上，这个过程本质上是将解决全局性问题或需要图像化处理的场景中，原本需要在查询阶段逐一过滤所有上下文的任务提前进行了预处理或缓存。这种预处理使得在实际回答问题时，速度更快，或者能够在实时条件下回答原本无法实时解答的问题，因此收益非常明显。很多问题在没有Graph支持的情况下根本无法解决，或者需要将所有上下文投入到大模型中进行处理，而这在资源上是有限的。

其次，在我们的实践中，我们发现进行高效的GraphRAG实现实际上是完全可控的，并且有很大的优化空间。即便采用最复杂、最昂贵的方式，成本也不过是你初始数据量的20倍左右。此外，20倍只是一个上限，实际上我们可以通过使用更为经济的方式来实现这个目标。尽管我们调用了大模型的索引器，但你可以在任何时段选择更经济的处理方式，同时利用一些新兴的模型（如翻译模型等）来进一步优化成本。因此，我们认为GraphRAG不仅仅是一个昂贵的工具，而是一个可以按需使用的宝贵资源，它为我们提供了灵活应对复杂知识管理需求的能力，而不是一种负担。

四、我们的工作

由于时间有限，我只能简单介绍一下我们团队的工作。我们构建了一个类似于GPS的开箱即用的工具，其中应用了GraphRAG技术。这个工具不仅引用了传统的Raphael编码书，还结合了Graph的方法。如果大家感兴趣，欢迎随时联系我们了解更多。

最后，我想花一分钟时间为我们团队和项目做个简单的介绍。我们正在开发一个名为"Nebula Graph"的项目，它是一个开源的分布式图数据库，也是目前最流行的开源分布式图数据库之一。在图数据库领域，我们的排名非常靠前，在分布式数据库中更是位列第一。我们的社区非常活跃，国内外有很多用户，如字节跳动、美团、银联等都是我们的用户。我们也非常欢迎大家访问我们的GitHub和论坛，了解更多项目详情，并与我们进行技术交流。

此外，我个人的博客中也有许多关于GraphRAG和其他开源项目的有趣文章，大家可以通过我的Twitter进行关注。非常感谢大家的时间，欢迎加入我们的社区，与我们一起探索技术的更多可能性。

https://github.com/vesoft-inc/nebula
https://www.siwei.ioThanks.
https://x.com/wey_gu