从碎片到图谱：Graph RAG如何用知识网络颠覆传统搜索？

推荐语

Graph RAG通过知识图谱解决传统搜索的碎片化问题，实现更精准的信息检索。

核心内容：
1. 传统RAG的局限性：全局与局部信息匹配度低
2. 知识图谱的优势：保留语义结构同时捕捉细节
3. Graph RAG的实现原理：利用大模型简化图谱构建

杨芳贤

53AI创始人/腾讯云(TVP)最具价值专家

在传统的RAG中，我们先会把文章切成一块一块的文字片段，然后把每一块都通过embedding转化成向量存到向量数据库里。不了解传统RAG的小伙伴，我们来举一个简单的例子说明一下。

如果我们按句子来分块存到向量数据库中后，那么当用户问“老王喜欢吃什么”时，系统就很容易找到“老王喜欢吃西瓜”和“老王也喜欢吃桃子”。如果他们的主题相关度很高，但是如果你问“这篇文章里一共提到了几次西瓜”，那就有点麻烦了。虽然西瓜出现在很多的句子之中，但它被分散在不同的片段里，没有哪一句能够单独回答这个问题。于是RAG就很可能检索错了或者漏了一部分。

为什么会这样呢？我们来看第一句，“老王喜欢吃西瓜”，这里面包含了三层信息：老王、喜欢吃和西瓜。在传统的RAG中，我们是按照整段来计算相关度的。如果问题只是“文章中提到了几次西瓜”，那他和“老王”和“喜欢吃”都没有关系。所以说整体的相关度不够高，查询的时候就可能会把“老王喜欢吃西瓜”漏掉。这就是传统RAG的第一个问题：全局问题和局部片段之间的匹配度太低。

于是你可能会想，那我就把片段切的更小一些，比如说按照词来分，这样每一个“西瓜”都能被命中，这当然能解决统计西瓜次数的问题。但是反过来说，如果我们再问一句“老王喜欢吃什么”的时候，这时候RAG又处理不了了，因为信息之间的关系已经被打断了。所以说矛盾来了：你切的太大，容易漏掉细节，而切的太小又容易失去语义之间的联系。这个矛盾就是传统RAG不准确的根源之一。

那有没有一种方法既不漏掉细节，又能保留语义的结构呢？还真有，那就是知识图谱（Knowledge Graph）。Graph RAG就是用知识图谱来解决传统RAG问题的。还是我们刚才的例子，“老王爱吃西瓜”，如果把它转化成知识图谱的形式就是这样的。这里的老王和西瓜叫做实体（Entity），它们之间的边是一个关系，叫做relationship。这些关系不只是连线，还可以加属性。比如说“爱吃”实体也可以带属性，比如说老王是一个人，西瓜是一个水果。这种既有实体又有关系，而且还可以加属性的图结构叫做LPG（Labeled Property Graph）。

在大语言模型出现之前，构建知识图谱是一个非常非常复杂的过程，算法绘色效果也不怎么样，我们这里就不展开说了。但是现在大模型的出现大大的简化了这个过程。比如说在Graph RAG中生成知识图谱的prompt是这个样子的（有点长）。我们来用一个简化版演示一下思路。假设我们要从“老王爱吃西瓜”这句话生成一个LPG，我们就可以这样写prompt：“目标：生成‘老王喜欢吃西瓜’的LPG。”然后我们再给出核心的流程：

首先是识别类型，也就是这个句子中的老王和西瓜，我们可以这样写：“步骤一，识别实体类型，包括人、物体和味道。”这里的实体类型是需要我们根据文本内容人工设定的。在Graph RAG中默认使用的实体类型包括团体、人、位置和事件。第二步是识别实体中的关系。这两个步骤在专业术语中都有正式的名字，第一步叫做命名实体识别（Named Entity Recognition），第二步叫做关系抽取（Relation Extraction）。过去这俩任务都有非常复杂的模型算法，现在我们只要用一句prompt就可以搞定了。

然后我们再定义一下输出格式，比如实体和类型用冒号分割，实体间的关系用箭头等等。除此之外，Graph RAG还会要求大语言模型生成每个实体和关系的简要文字描述。然后Graph RAG会把这一大堆的prompt全都发送给大语言模型。如果AI模型足够强大，它就会根据要求返回类似这样的格式：它会识别出“老王”和“西瓜”两个实体，以及“老王爱吃瓜”这样一个关系。

注意一下，这些内容都是AI自动生成的，不一定和原文一字不差，甚至AI还可能编故事。所以，我们通常还要在prompt中加一句警告，让AI不要编造信息。就这样，Graph RAG通过解析AI返回的结构化文本，就像开玩笑一样，“老王爱吃瓜”这句话的知识图谱就被解析出来了。听起来是不是挺不靠谱的？但令人意外的是，效果其实还是不错的。

知识图谱本身是一个非常古老的概念。早在大模型之前，它就在很多的公开语料里面被频繁的使用。事实证明，大模型还是处理的很好的。在Graph RAG中，这里还有一个特别有意思的小设计：在AI生成完一个知识图谱之后，Graph RAG会把这个知识图谱连同原文再发给AI一次，问他“你是不是还有什么遗漏的东西，要不要再补充一点什么？”如果AI说有，那就再补一轮，然后再问再补。这个过程会一直循环，直到AI亲口承认“我已经没有任何要补充的东西了”。这下，程序员们终于找到了自己也能欺负的对象了。这个反复盘问榨干信息的过程，有一个专有的名词叫做“data cleaning”。我暂时也没有找到它的中文翻译，不如就叫它“大模型PUA”吧。

于是，Graph RAG会对文章中的每一段文字都单独生成这么一个知识图谱。“老王喜欢吃瓜”这么进行完成后，后两句其实也差不多。我们这里注意一下最后这句话，其中的“味道甜”也被识别为一个实体。这是因为“味道”在我们的提示词中被定义为了实体。等所有的片段都处理完之后，Graph RAG会把名字相同的实体自动进行合并。比如说合并所有的“老王”，合并所有的“西瓜”等等，最后会拼成一个完整的文章级的知识图谱。这个过程并不需要AI参与，是由程序自动完成的。

但是在合并的过程中，原本分散在不同节点或边上的描述信息也会被一并整合起来。我们这个例子比较简单，只有结点的描述信息被合并了。但是在实际的使用中，边的描述同样也会参与合并。然后这个时候Graph RAG会把每个被合并的描述信息交给大语言模型，请他根据这些描述，生成一段更加完整、更加通顺的总结性描述，并且用它来当做合并后的最终描述。这样一来，我们最终拿到的不只是结构清晰的图谱，还带了一段由AI整理过的自然语言的描述。

有一个细节值得特别的说一下：Graph RAG一直在维护着知识图谱和原文之间的对应关系。比如图谱里的实体“老王”，Graph RAG知道这些信息是由哪几段原文生成出来的。反过来也一样，给你一段原文，他也能告诉你这段话在知识图谱里面对应了哪些实体，哪些关系。这一点在后面的查询时候会用到。

现在，我们已经得到了文章对应的知识图谱。但是如果文章很长，这张图就会变得非常庞大，非常复杂。查询起来其实也没那么方便。于是Graph RAG又多做了一个处理：它会用一种叫做“莱顿社区检测”的方法，把图中边比较密集的节点合并成一个整体。比如我法，请大家自己研究，这里，我们只看结果。但我们这个图实在是太简单了，所以这里也只能意思一下。假如左边的四个节点相互之间的边比较多，就可以合成一个整体，而右边的“味道”可以单独成为一个整体。

然后就像之前合并同名实体的那样，Graph RAG会让AI使用每个子图中的点和边的描述信息，生成一个更高级的总结性描述。比如我们把左边子图中所有的点和边的描述拿出来，AI就能总结出“老王爱吃瓜和桃，小王爱吃瓜”。而且这个总结的过程不仅仅是简单的信息抽象，往往还能够推理出额外的信息。比如说“小王只爱吃瓜”，配合“老王爱吃瓜和桃”，就可以推理出“小王不爱吃桃子”。这句话在原文里面根本没有出现过。这就是知识图谱超越简单文本匹配，真正开始理解和思考的地方。

这样我们就得到了一个简化后的知识图谱，每个节点都代表了原图中的一个局部信息块。如果说这张图还不够简单，那就继续重复这个过程，再合并再总结，再往上抽象一层一层的向上，最终形成了一个知识图谱的层级结构。这个结构越往上，信息就越抽象，越精炼；越往下就越接近原文，越具体细节。

好了，现在我们已经有了这个知识丰富、层次分明的知识图谱了。最后一步就是要把它变成一个能够被快速检索的索引库。这又到了我们熟悉的操作：embedding。我们把知识图谱中的每个节点、每条边的实体信息和总结性描述，都当做一个文字片段进行embedding，然后存入向量数据库。再加上最开始原文里面的每一个片段也都存入向量数据库，这就是知识图谱的最终形态。

接下来的查询就变得非常简单了。和普通的RAG一样，我们把用户的问题（比如“老王喜欢吃什么”）做embedding转化成向量，然后就可以用它去跟原文或者知识图谱的embedding进行匹配。匹配的时候是比较灵活的：我们可以只查询知识图谱的某一层或者某几层，也可以只查询原文，甚至也可以全部都查询一遍。这个过程没有固定之规。

比如在Graph RAG里面就提供了一个叫做“local search”策略。它会先从最底层的知识图谱里面找出和问题最接近的实体。还记得我们之前说过，Graph RAG会维护图谱和原文之间的映射关系吗？一旦找到了相关的图谱点，Graph RAG就能反向的查出这些点和边是由哪些原文生成的，以及这些点和边出现在哪些上层的图谱结构里面，他们相邻的其他点和边都是什么？至于最下面这个“covariate”，相当于对原文片段的文字性总结，是一个实验性功能。

然后Graph RAG会把找到的所有的这些点和边的总结性描述，以及他们关联的原文片段，再加上用户提的问题“老王爱吃什么”，一起打包发给AI大模型。这样无论你问的是一个高层次的抽象问题，还是某段原文细节问题，相关信息都会被一并的带上。因为“local search”是从最底层的图谱开始查起的，所以他特别擅长处理细节丰富、定位准确的问题，这也是它为什么叫做“local search”的原因。

Graph RAG还有一种查询策略叫做“global search”。和“local search”相反，“global search”是从图谱的高层开始查起的，然后在一层一层的向下追溯。所以它的好处是它比“local search”更适合回答那种抽象一点、全局性更强的问题。比如说“这篇文章的核心观点是什么？”

总之，这就是Graph RAG的整体架构。从构建知识图谱、总结描述，几乎每一步都离不开大语言模型的参与。听上去确实有点不靠谱，但根据微软论文中的实验数据来看，效果其实还是挺不错的。于是也就不难理解，为什么大家都在吐槽Graph RAG太吃token了。因为它本质上就是一种让大语言模型渗透到整个流程的设计。你可以说他奢侈烧钱，但不能说他不认真。

Graph RAG的过程其实很像我们的学习之路。起初脑子里面装的是零散的知识点和孤立的笔记，就像那些未经整理的文本片段。随着不断的积累和思考，那些点慢慢形成了线，最终在脑海里面织出了一张属于自己的知识图谱，而我们的视野也在这个过程中被一点一点的拉高。但是我觉得其中最妙的是在这个过程中，我们竟然还能够发现一些原本不存在的连接。就像现在分享着Graph RAG的我和屏幕前的你，虽然素昧蒙面，但是却因为一份好奇心，心里生出了一丝默契。这也许就是属于求知者的浪漫吧。