Graph RAG论文阅读笔记
说明：
- 首次发表日期：2024-07-11
- 论文原文见：https://arxiv.org/abs/2404.16130
- 使用KIMI机翻，然后人工润色
- 如有错误，敬请指出
摘要 (Abstract)
利用检索增强生成（RAG）从外部知识源检索相关信息，使得大型语言模型（LLMs）能够针对私有的或之前未见过（即不在训练集中）的文档集回答问题。然而，RAG在针对整个文本语料库的全局性问题上会失败，例如问题："数据集中的主要主题是什么？"。因为这本质上是一个查询聚焦的汇总（query-focused summarization, QFS）任务，而不是一个明确的检索任务。同时，以前的QFS方法（译注：所能处理的文本量较小），无法扩展到通常RAG所能处理的文本数量级。为了结合这些存在显著差别的方法的优势，我们提出了一种Graph RAG方法来回答关于私有文本语料库的问题，该方法既能回答用户提出的各种各样的问题（普遍性），也能够随着要索引的源文本量扩展。
我们的方法使用LLM构建一个基于图的文本索引，分为两个阶段：
- 首先从源文档提取出一个实体知识图谱（entity knowledge graph）
- 然后为所有密切相关实体组，预生成社群摘要（community summary）
给定一个问题，使用每个社群摘要生成一个不完整的部分回复（partial response），然后将所有不完整的部分响应汇总，得到给用户的最终回复。对于在大约100万个token的一个认知构建问题（sensemaking question）的 数据集上，我们展示了Graph RAG在生成答案的全面性和多样性方面相比于一个简单的RAG基线有显著的改进。一个开源Python的Graph RAG实现（包含global search和local search方法）：https://aka.ms/graphrag
1 引言 （Introduction）
本文中，我们提出了一种Graph RAG方法，其基于对大模型提取的知识图谱进行全局汇总（global summarization）。与一些利用了知识图谱索引在结构化检索和遍历的可用性的相关研究工作不同，我们聚焦于之前没有探讨的知识图谱特性：它们内在的模块性（modularity）（译注：模块性是指，由分开的不同部分构成，当组合以后会形成一个整体）和社群检测算法将图谱划分为由紧密关联的节点构成的不同社群（modular communities）的能力。
为了评估此方法，我们使用LLM从两个具有代表性的真实世界数据集的简短描述中生成了一系列以活动为中心的认知构建（sensemaking）问题，这连个数据集分别包含播客文字稿和新闻文章。我们定义了comprehensiveness、diversity和empowerment这些目标质量（target qualities），这些质量有助于理解广泛的问题和主题；我们既探索了不同层次登记的社群摘要（varying hierarchical level of community summaries）对用于回答问题的影响，也与naive RAG和对源文本的全局性map-reduce摘要（global map-reduce summarization）进行了比较。我们展示了所有Graph RAG的global search方法在comprehensiveness和diversity方面都优于naive RAG；而且相比于源文本摘要（source text summarization），使用中层社群摘要或者低层社群摘要的Graph RAG在这些相同的指标上表现更好，同时消耗的token更少。
2 Graph RAG方法和流水线管道（Graph RAG Approach & Pipeline）
我们现在详细说明Graph RAG方法（图1）pipeline的高级数据流，并描述每个步骤的关键设计参数、技术和实现细节。
2.1 源文档 → 文本切块 （Source Documents → Text Chunks）
一个基础的设计决策是源文档提取的输入文本应该采用什么样的粒度来进行文档切块处理。 在接下来的步骤中，每一个切块都会被传给一组提示词，这些提示词设计上是用于提取各种知识图谱索引中的元素。较长的文本块需要较少的LLM调用来进行这种提取，但会受到较长LLM上下文窗口的召回率降低的影响。可以从图2中单轮提取（即zero gleanings）看到这种表现：在一个样本数据集上（HotPotQA），使用切块尺寸600提取到的实体引用数量是使用切块尺寸2400的差不多两倍。虽然引用通常越多越好，任何提取过程都必须平衡召回和精度。
2.2 文本块 → 元素示例 （Text Chunks → Element Instances）
这一步骤的基线要求是识别并提取每个来自源文本的文本块中的图节点和边的实例。我们使用LLM提示分多步来完成这项工作，首先识别文本中的所有实体，包括它们的名称、类型和描述，然后识别明确相关的实体之间的所有关系，包括源实体和目标实体以及它们关系的描述。这两种元素实例都由一个由分隔的元组构成的列表的形式输出。
可以调整提示词使其适应文档语料的领域，主要需要调整的提示词中提供给大模型的少量示例（few-shot examples），大模型使用这个例子进行上下文学习（In-context learning）。
例如，虽然我们默认的提示提取广泛的"命名实体"类别，如人、地点和组织，通常适用，但具有专门知识的领域（例如，科学、医学、法律）将从专门针对这些领域的少量示例中受益。我们还支持一个次级提取提示，用于我们希望与提取的节点实例关联的任何额外的协变量。我们的默认协变量提示旨在提取与检测到的实体相关的主张，包括主体、对象、类型、描述、源文本跨度以及开始和结束日期。
为了平衡效率和质量的需求，我们使用多达指定最大值的多轮"收集"（gleanings），以鼓励LLM检测它可能在先前的提取轮次中错过的任何额外实体。这是一个多阶段过程，我们首先要求LLM评估是否提取了所有实体，使用logit bias为100来强制进行是/否决策。如果LLM回应说错过了实体，那么接下来表示"在最后一次提取中错过了许多实体"（MANY entities were missed in the last extraction）来鼓励LLM收集这些错过的实体。这种方法允许我们在不降低质量的情况下使用较大的文本块大小（图2），或者被迫引入噪声。
2.3 元素实例 → 元素摘要（Element Instances → Element Summaries）
使用LLM"提取"源文本中表示的实体、关系和主张的描述已经是抽象摘要的一种形式，依赖于LLM来对概念创建独立有意义的摘要，这些概念可能被文本本身暗示但没有明确说明（例如，隐含关系的存在）。将所有这样的实例级摘要转换为每个图元素（即，实体节点、关系边和主张协变量）的单一描述性文本块，需要再一轮的LLM对匹配的实例组进行摘要总结。
在这个阶段的一个潜在问题可能是，LLM可能不会一致地以相同的文本形式提取对同一实体的引用，导致重复的实体元素，从而在实体图中产生重复的节点。然而，由于所有密切相关的"社群"的实体将在后面被检测和总结，并且鉴于LLMs可以理解多个名称变体背后的共同实体，我们的整体方法是对这种变体具有弹性的，前提是从所有变体到一组密切相关的实体有足够的连通性。
总的来说，我们使用丰富的描述性文本为潜在的噪声图结构中的同质节点，既符合LLMs的能力，也符合全局、查询聚焦的摘要（QFS）的需要。这些特性也使我们的图索引不同于典型的知识图，后者依赖于简洁一致的知识三元组（主体、谓语、宾语）来进行下游推理任务。
2.4 元素摘要 → 图社群（Element Summaries → Graph Communities）
在前一步骤中创建的索引可以被建模为一个同质的无向加权图，其中实体节点通过关系边连接，边权重代表检测到的关系实例的归一化计数。给定这样一个图，可以使用多种社群检测算法将图划分为节点之间相互连接比与其他节点更强的社群。在我们的流程中，我们使用Leiden，因为它能够高效地恢复大规模图的层次社群结构（图3）。这个层次结构的每一层都提供了一个社群划分，以互斥、集体完备的方式覆盖图中的节点，使得全局摘要可以通过分而治之（divide-and-conquer）的方式进行。
2.5 图社群 → 社群社群（Graph Communities → Community Summaries）
下一步是创建每个Leiden层次结构中社群的报告式摘要，使用一种旨在扩展到非常大的数据集的方法。这些摘要本身是有用的，作为理解数据集的全局结构和语义的一种方式，并且可能在没有疑问的情况下用来理解语料库。例如，用户可能会浏览一个层次结构级别的社群摘要，寻找感兴趣的一般主题，然后跟随链接到提供每个子主题更详细报告的下级层次结构的报告。然而，在这里，我们专注于它们作为用于回答全局查询的基于图的索引的一部分的效用。
社群摘要的生成方式如下：
- 叶级社群。叶级社群的元素摘要（节点、边、协变量）按优先级排序，然后迭代地添加到LLM上下文窗口中，直到达到token限制。优先级如下：对于每个社群边（community edge），按源节点和目标节点的度数之和（即，总体突出性）降序排列，添加源节点、目标节点、链接的协变量和边本身的描述。
- 高层次的社群。如果所有元素摘要都适合上下文窗口的token限制，就像叶级社群一样进行，并在社群内总结所有元素摘要。否则，按元素摘要token数量降序排列子社群，并迭代地用较短的子社群摘要（较短）替代它们关联的元素摘要（较长），直到在上下文窗口中实现适合为止。
2.6 社群摘要 → 社群答案 → 全局答案 （社群摘要 → 社群答案 → 全局答案）
给定用户查询，前一步骤中生成的社群摘要可以用来在一个多阶段过程中生成最终答案。社群结构的层次性质也意味着可以使用不同层次的社群摘要来回答问题，这引发了一个问题，即层次社群结构中的特定层次是否为一般认知构建（sensemaking）问题提供了最佳的摘要细节和范围平衡。
对于给定的社群层次，任何用户查询的全局答案都是这样生成的：
- 准备社群摘要。社群摘要被随机打乱顺序（randomly shuffled）并分成预先指定的token大小的块。这确保了相关信息分布在块中，而不是集中在（可能丢失的）单个上下文窗口中。
- 映射社群答案。并行生成中间答案，每个块一个。LLM还被要求生成一个0-100的分数，表明生成的答案在回答目标问题方面的有用性（how helpful）。得分为0的答案被过滤掉。
- 归纳到全局答案。中间社群答案按有用性得分降序排序，并迭代地添加到新的上下文窗口中，直到达到token限制。这个最终上下文被用来生成返回给用户全局答案。