• 背景
• 一、引言
• 1.1 GraphRAG 是什么
• 1.2 GraphRAG 能做什么
• 1.3 GraphRAG 预期用途
• 1.4 GraphRAG 示例效果
• 二、技术原理
• 2.1. 索引第一步：拆分文本块
• 2.2. 索引第二步：解析出元素实例
• 2.3. 索引第三步：总结元素摘要
• 2.4. 索引第四步：检测出图社区（community）
• 2.5. 索引第五步：总结社区摘要
• 2.6.1 索引查询：全局搜索
• 2.6.2 索引查询：本地搜索

点关注不迷路

背景

• RAG在处理针对整个语料库的全局性问题时有局限性，尤其是对于需要生成摘要的查询。
• RAG与QFS的区别：RAG擅长局部性问题的回答，而QFS(查询聚焦摘要)更适合生成全局性摘要。尤其是抽象的QFS方法能够生成自然语言的摘要，而不仅仅是提取现有文本片段。
• 现代LLM的简化作用：现代LLMs通过上下文学习，能够在一定程度上简化摘要任务，但对于大规模语料库的全局摘要仍然存在局限性，因为大规模文本可能会大大超出LLM的上下文窗口限制
• 预索引的潜力：文章提出通过预索引的方式，可能会发展出一种新的RAG方法，更好地处理全局性摘要任务。

一、引言

1.1 GraphRAG 是什么

GraphRAG 是在 7 月 2 日由微软开源的一种结构化、分层的 RAG 方法。通过构建实体知识图和预生成社区摘要(community summary)的方式，能够更好地处理和回答全局性的问题。

1.2 GraphRAG 能做什么

GraphRAG 能够连接大量信息中的信息，并使用这些连接来回答使用关键字和基于向量的搜索机制难以或无法回答的问题。在上一个问题的基础上，提供关于系统如何为各种用途提供功能的半技术性、高级信息。这使得系统可以使用 GraphRAG 来回答问题，其中答案涵盖许多文档以及主题问题，例如：此数据集中的顶级主题是什么？

1.3 GraphRAG 预期用途

• GraphRAG 旨在支持关键信息发现和分析用例，在这些用例中，获得有用见解所需的信息跨越许多文档、嘈杂、混杂着虚假信息，或者当用户旨在回答的问题比底层数据可以直接回答的问题更抽象或主题化时。
  
• GraphRAG 设计用于用户已经接受过负责任的分析方法培训并期望进行批判性推理的环境。GraphRAG 能够提供对复杂信息主题的高度洞察力，但是需要领域专家对答案进行人工分析，以验证和增强 GraphRAG 生成的响应。
  
• GraphRAG 旨在与特定领域的文本数据语料库一起部署和使用。GraphRAG 本身不收集用户数据，但鼓励用户验证内部所选LLM的数据隐私政策。
  
• GraphRAG 适用于对大规模语料库的全面性和多样性总结需求。
  

1.4 GraphRAG 示例效果

经过在大规模数据集上的测试，在全面性、多样性、赋权性方面，GraphRAG 都优于传统 RAG（70~80%胜率）。

• GraphRAG 的示例效果：微软使用了俄罗斯和乌克兰双方新闻来源在 2023 年 6 月中的上千篇新闻报道，该数据集复杂且存在相左的意见和不完整的信息，是一个现实世界中杂乱的测试示例，又因其出现时间过于近期，所以并未被纳入 LLM 基础模型的训练中，且数据集过大无法放入 LLM 上下文的窗口。使用朴素 RAG 和 GraphRAG 两种方法的测试结果对比：
  
  

• 

二、技术原理

• 本文提出了一种基于图的RAG方法，通过构建实体知识图和预生成社区摘要(community summary)的方式，能够更好地处理和回答全局性的问题。

• 步骤

• 1.从源文档中推导出实体知识图
• 2.将图分割成模块化社区

• 通过社区检测算法, 也就是用于识别图中密切相关的节点群体的一种算法。常见的包括Louvain和Leiden算法。

• 3.利用社区的摘要来生成全局性的问题回答

• 给定一个问题，首先使用每个社区摘要独立并行地回答查询，然后将所有相关的部分答案总结成一个最终的全局答案。

最佳实践：基于文本《林黛玉初进荣国府》构建图谱，解析 Graph RAG 的技术原理。

2.1 构建索引第一步：拆分文本块（来源文档 → 文本块）

先把文档 token 化，按照 token 数进行切分。具体 chunk 规格可以自定义更改。

在处理源文档时，如何选择合适的文本块大小是一个关键设计决策。较长的文本块可以减少LLM调用次数，但会降低召回率。实践表明：较小的文本块（600个token）通常能提取更多的实体引用，但提取过程需要在召回率和精度之间找到平衡。

2.2 构建索引第二步：解析出元素实例（ENTITY、RELATIONSHIP）（文本块 → 元素实例）

• 依赖：LLM

从文本块中提取图节点和边的实例。使用一个多部分的LLM提示来识别实体及其关系，并通过提供少量示例来定制提示以适应特定领域。为提高提取质量，采用多轮“清理”来发现和提取遗漏的实体。这种方法可以在使用较大的文本块时保持高质量的提取结果。

• 输入：

黛玉便知这方是正经正内室，一条大甬路，直接出大门的。进入堂屋中，抬头迎面先看见一个赤金九龙青地大匾，匾上写着斗大的三个大字，是“荣禧堂”，后有一行小字：“某年月日书赐荣国公贾源”，又有“万几宸翰之宝”。
大紫檀雕螭案上，设着三尺来高青绿古铜鼎，悬着待漏随朝墨龙大画，一边是金蜼彝，一边是玻璃盒。地下两溜十六张楠木交椅。又有一副对联，乃是乌木联牌，镶着錾银的字迹，道是：\N\N 座上珠玑昭日月，堂前黼黻焕烟霞。\N\N 
下面一行小字，道是：“同乡世教弟勋袭东安郡王穆莳拜手书”。\N\N 
原来王夫人时常居坐宴息，亦不在这正室，只在这正室东边的三间耳房内。于是老嬷嬷引黛玉进东房门来。临窗大炕上猩红洋罽，正面设着大红金钱蟒靠背，石青金钱蟒引枕，秋香色金钱蟒大条褥。两边设一对梅花式洋漆小几。左边几上文王鼎、匙箸、香盒；右边几上汝窑美人觚-觚内插着时鲜花卉，并茗碗、痰盒等物。
地下面西一溜四张椅上，都搭着银红撒花椅搭，底下四副脚踏。椅之两边，也有一对高几，几上茗碗瓶花俱备。其余陈设，自不必细说。老嬷嬷们让黛玉炕上坐，炕沿上却也有两个锦褥对设。黛玉度其位次，便不上炕，只向东边椅子上坐了。本房内的丫鬟忙捧上茶来。
黛玉一面吃茶，一面打谅这些丫鬟们，妆饰衣裙，举止行动，果亦与别家不同。\N\N
茶未吃了，只见穿红绫袄、青缎掐牙背心的一个丫鬟走来笑，说道：“太太说，请姑娘到那边坐罢！”老嬷嬷听了，于是又引黛玉出来，到了东廊三间小正房内。
正面炕上横设一张炕桌，桌上磊着书籍茶具，靠东壁面西，设着半旧得青缎靠背引枕。王夫人却坐在西边下首，亦是半旧的青缎靠背坐褥。见黛玉来了，便往东让。
黛玉心中料定这是贾政之位。因见挨炕一溜三张椅子上，也搭着半旧的弹墨椅袱，黛玉便向椅上坐了。王夫人再四携她上炕，她方挨王夫人坐了。
王夫人因说：“你舅舅今日斋戒去了，再见罢。只是有一句话嘱咐你：你三个姊妹倒都极好，以后一处念书认字、学针线，或是偶一玩笑，都有尽让的。

• 输出：

(\"ENTITY\"<|>黛玉<|>PERSON<|>黛玉是故事中的主要人物，她来到荣国府，观察府中的陈设和人物<|>)
(\"ENTITY\"<|>王夫人<|>PERSON<|>王夫人是荣国府的女主人，她接待了黛玉，并向她介绍了府中的情况<|>)
(\"ENTITY\"<|>荣国府<|>ORGANIZATION<|>荣国府是故事中的主要场景，是贾家的府邸，府中有许多房间和陈设<|>)
(\"ENTITY\"<|>荣禧堂<|>ORGANIZATION<|>荣禧堂是荣国府中的一个堂屋，堂屋中有一块大匾，匾上写着“荣禧堂”三个大字<|>)
(\"ENTITY\"<|>东安郡王穆莳<|>PERSON<|>东安郡王穆莳是故事中的一个次要人物，他是王夫人的同乡，曾为荣禧堂题写对联<|>)
(\"ENTITY\"<|>贾政<|>PERSON<|>贾政是故事中的一个次要人物，他是荣国府的主人之一，王夫人让黛玉坐在贾政的位置上<|>)
(\"RELATIONSHIP\"<|>黛玉<|>王夫人<|>黛玉是王夫人接待的客人，王夫人向黛玉介绍了荣国府的情况<|>5)
(\"RELATIONSHIP\"<|>黛玉<|>荣国府<|>黛玉是荣国府的客人，她观察了府中的陈设和人物<|>5)\
(\"RELATIONSHIP\"<|>王夫人<|>荣国府<|>王夫人是荣国府的女主人，她接待了黛玉，并向她介绍了府中的情况<|>5)
(\"RELATIONSHIP\"<|>东安郡王穆莳<|>荣禧堂<|>东安郡王穆莳为荣禧堂题写对联<|>3)
(\"RELATIONSHIP\"<|>贾政<|>荣国府<|>贾政是荣国府的主人之一，王夫人让黛玉坐在贾政的位置上<|>3)\N<|COMPLETE|>

2.3 构建索引第三步：总结元素摘要（元素实例 → 元素摘要）

• 依赖：LLM

将提取到的元素实例进一步总结为单一的描述性文本块。虽然在提取过程中可能会出现格式不一致的问题，但通过社区检测和LLM的理解能力，可以确保生成的图结构仍然可靠。此外，使用丰富的描述性文本适应了LLM的能力和全局性查询的需求，使得这种方法与传统的知识图谱不同。

• 输入： ["丫鬟是贾府中的人物，她们在贾府中侍候，执行各种家务任务。", "丫鬟是贾府中的女仆，负责传递消息和照顾府中的人。"]
• 输出：

在贾府中，丫鬟们作为女仆，扮演着至关重要的角色。她们不仅负责执行各种家务任务，确保府中的日常运作井然有序，还承担着传递消息和照顾府中人员的职责。在贾府这个大家族中，丫鬟们以其勤劳、细心和忠诚，为府中的人们提供了周到的服务。

从这一步中，可以看出 GraphRAG 对 LLM 上下文窗口的大小要求很高，因为每个prompt 都要由输入的描述列表和相关要求提示构成。实践表明：LLM 最少需要支持 32k 上下文长度。

2.4 构建索引第四步：检测出图社区（community）（元素摘要 → 图社区）

将前一步创建的图索引划分为社区。创建的图是一个同质无向加权图，节点通过关系边连接。通过使用社区检测算法（如Leiden算法），可以将图分为节点之间连接更强的社区。Leiden算法能够高效地恢复大规模图的层次化社区结构，使得可以实现分而治之的全局摘要。

社区检测算法(如Leiden 算法)，也就是用于识别图中密切相关的节点群体的一种算法，将图分割成模块化社区。

2.5 构建索引第五步：总结社区摘要（图社区 → 社区摘要）

为每个图社区生成摘要，以便在处理大规模数据集时保持高效。这些社区摘要不仅用于理解数据集的全局结构，也用于回答全局性查询。叶子级社区和高级社区的摘要生成方法有所不同，前者直接添加元素摘要，后者可能需要用子社区摘要替代较长的元素摘要，以适应上下文的token限制。

实现：通过 LLM 完成。输入：社区中的实体和对应的描述。输出：

{
	"title": "贾母家与重要家族成员",
	"summary": "社区以贾母家为中心，围绕着贾母家的成员和关系构建。贾琏，作为贾赦之子，与王熙凤结婚，是社区中的关键人物。王熙凤，被贾母称为“凤辣子”，是贾母家中的重要人物，与贾琏、王氏和贾母家有密切关系。王氏，作为王熙凤的姑母，也是社区的一部分。[数据：实体（27, 24, 23, 25, 22）；关系（16, 67, 69, 70, 68, 66）]",
	"rating": 7.5,
	"rating_explanation": "影响严重性评级较高，因为贾母家及其成员在社区中扮演着重要角色，他们的关系和动态可能对社区的稳定性和功能产生重大影响。",
	"findings": [{
		"summary": "贾母家作为社区中心",
		"explanation": "贾母家是社区的核心，与贾琏、王熙凤、王氏等关键家族成员有着密切的联系。贾母家的影响力和重要性在社区中是显而易见的。[数据：实体（27）；关系（69, 70）]"
	}, {
		"summary": "贾琏与王熙凤的婚姻关系",
		"explanation": "贾琏与王熙凤的婚姻是社区中的一个重要关系，这不仅将两个关键家族成员联系在一起，还加深了贾母家与王氏家族之间的联系。[数据：实体（24, 23）；关系（67）]"
	}, {
		"summary": "王熙凤在贾母家中的地位",
		"explanation": "王熙凤在贾母家中的地位非常重要，她不仅与贾琏结婚，还与贾母家有密切的联系。王熙凤被贾母称为“凤辣子”，这表明她在家族中的独特地位和影响力。[数据：实体（23）；关系（69）]"
	}, {
		"summary": "王氏与王熙凤的家族关系",
		"explanation": "王氏是王熙凤的姑母，这种家族关系在社区中具有重要意义，因为它不仅加强了王熙凤与贾母家的联系，还体现了家族内部的紧密联系。[数据：实体（25）；关系（68）]"
	}]
}

2.6.1 索引查询：全局搜索（社区摘要 → 社区答案 → 全局答案）

将社区摘要转化为回答用户查询的全局答案。该过程包括准备社区摘要、生成中间答案以及将最有帮助的答案整合成全局答案。社区摘要首先被随机打乱和分块，然后通过映射步骤生成中间答案，再通过归约步骤生成最终的全局答案。

向每个社区 community 提出问题，将这些问题汇总成总体摘要响应。

• 问题：故事中前三名最重要的人物都有谁？
• 答案：

• 在故事中，贾宝玉、林黛玉和王熙凤被确认为前三名最重要的人物。贾宝玉是故事中的关键人物之一，他是贾母的孙子，袭人的主人，性格乖僻，与黛玉有着前世今生的情感纠葛 [DATA: REPORTS (10, 3, 4, 5, 6, +MORE)]。林黛玉是故事中的另一重要人物，她前往外祖母家荣国府，与宝玉、袭人等有着密切的关系，性格温婉，与宝玉有着前世今生的情感纠葛 [DATA: REPORTS (10, 3, 4, 5, 6,+MORE)]。王熙凤是故事中的第三位重要人物，她是王夫人的侄女，贾琏的妻子，性格泼辣，在贾府中扮演着重要角色，与贾府其他核心人物有着密切的亲属和教育关系 [DATA:REPORTS (5, 3, 4, 6, 7, +MORE)]。

2.6.2 索引查询：本地搜索（社区摘要 → 社区答案 → 全局答案）

在索引阶段，系统会将所有实体的描述进行 embedding，也就是转换成向量存储。当执行本地搜索时，系统会将查询文本同样转换成向量表示。通过计算相似性，找到与查询最接近的实体。找到相关实体后，系统会通过图遍历来从这些实体出发，进一步获取相关的关系（如实体之间的连接）和社区。从而构建提示上下文（prompt context），为后续如回答问题或生成文本提供必要的信息背景。

由于这个差别，Global查询时只需要 LLM 开启即可，而Local查询时 LLM 和 embedding 必须都开启。

• 问题：故事中，贾母对黛玉的态度如何？
• 答案：

  "贾母对黛玉的态度充满了疼爱和关怀，这在故事中得到了充分的体现 [DATA: ENTITIES (15, 4, 89, 38); SOURCES (9)]。首先，贾母对黛玉的到来表示了极大的关心。当黛玉初到贾府时，贾母亲自接待了 她，安排她住在荣国府的碧纱橱里，这表明贾母对黛玉的居住环境给予了特别的考虑 [DATA: ENTITIES (15, 4); SOURCES (9)]。其次，贾母对黛玉的健康状况表示了深切的关心。当得知黛玉身体虚弱，有不足之症 时，贾母没有表现出任何嫌弃或不满，反而更加疼爱黛玉，这体现了贾母对黛玉的深 厚感情 [DATA: ENTITIES (15, 4); SOURCES (9)]。再者，贾母对黛玉的教育和成长表示了关心。当得知黛玉曾是雨村的女学生，身体刚 恢复，后随雨村一同前往京城时，贾母没有表现出任何不满或担忧，反而更加疼爱黛 玉，这体现了贾母对黛玉的教育和成长的关心 [DATA: ENTITIES (15, 4); SOURCES (9)]。最后，贾母对黛玉的家族地位表示了关心。当得知黛玉是林如海和林姑妈的女儿，贾 母的外孙女，贾宝玉的表妹时，贾母没有表现出任何嫌弃或不满，反而更加疼爱黛 玉，这体现了贾母对黛玉的家族地位的关心 [DATA: ENTITIES (15, 4); SOURCES (9)]。综上所述，贾母对黛玉的态度充满了疼爱和关怀，这在故事中得到了充分的体现。贾 母对黛玉的居住环境、健康状况、教育和成长、家族地位都表示了关心，这体现了贾 母对黛玉的深厚感情和家族责任感。"

三、GraphRAG的局限性

1. 计算资源需求高：处理大规模图数据需要大量的计算资源。特别是在训练过程中，需要存储和处理大量的节点特征以及它们之间的边信息，这可能导致内存和计算能力的瓶颈。

2. 长距离依赖问题：虽然注意力机制可以在一定程度上缓解这一问题，但是图中的长距离依赖关系仍然难以完全捕捉到，特别是对于那些跨越多个跳数（hop）的间接关系。

3. 过平滑（Over-smoothing）：随着图神经网络层数的增加，节点表示可能会变得越来越相似，导致难以区分邻近节点。这对于分类任务来说尤其不利，因为模型可能无法正确地将不同类别的节点区分开来。

4. 数据稀疏性：在一些实际场景中，图数据可能非常稀疏，尤其是在节点间连接较少的情况下。这种稀疏性会使得模型难以从数据中学习到有效的特征表示。

5. 缺乏解释性：深度学习模型通常被认为是“黑盒”模型，这意味着它们的决策过程很难被人类理解和解释。对于图神经网络来说，这一点同样适用，尤其是当涉及到复杂的图结构时。

6. 动态图更新：现实世界中的很多图结构是动态变化的，如何有效地更新模型以适应这些变化仍然是一个挑战。

了解这些局限性有助于我们在选择和应用GraphRAG时做出更加合理的判断，并采取适当的措施来克服这些局限。例如，可以通过优化算法设计、改进硬件设施或采用特定的数据预处理技术等方式来缓解上述问题。