本文是《From Local to Global: A Graph RAG Approach to Query-Focused Summarization》的笔记。
摘要
检索增强生成（RAG）用于从外部知识源中检索相关信息，使大型语言模型（LLMs）能够回答关于私有和/或以前未见过的文档集合的问题。然而，RAG 在回答针对整个文本语料库的全局问题时失败，例如“数据集中的主要主题是什么？”，因为这本质上是一个查询聚焦摘要（query-focused summarization, QFS）任务，而不是一个显式的检索任务。同时，以前的 QFS 方法无法扩展到典型 RAG 系统索引的文本数量量级。
为了结合这两种对比方法的优势，我们提出了一种 Graph RAG 方法，用于在私有文本语料库上进行问题回答，该方法可以根据用户问题的普遍性和需要索引的源文本数量进行扩展。我们的方法使用 LLM 分两个阶段构建基于图的文本索引：首先从源文档中推导出实体知识图，然后为所有紧密相关的实体组预生成社区摘要。给定一个问题，每个社区摘要用于生成部分响应，然后所有部分响应再次汇总为用户最终响应。对于在 100 万个 token 范围内对数据集进行全局感知问题的类别，我们展示了 Graph RAG 相对于朴素 RAG 基线在生成答案的全面性和多样性方面都有显著改进。
1 Introduction
检索增强生成（RAG, Lewis et al., 2020）是一种在完整数据集上回答用户问题的成熟方法，但它是为那些答案被包含在文本区域内的情况设计的，这些文本区域的检索为生成任务提供了足够的基础。相反，一个更合适的任务框架是查询聚焦摘要（query-focused summarization, QFS, Dang, 2006），特别是查询聚焦抽象摘要，它生成自然语言摘要，而不仅仅是拼接的摘录。然而，挑战仍然存在，即在整个语料库上进行查询聚焦抽象摘要(query-focused abstractive summarization)。如此大量的文本可能大大超过 LLM 上下文窗口的限制，而且信息可能会在较长的上下文中丢失。此外，尽管朴素的 RAG 中直接检索文本块可能不足以满足查询聚焦摘要任务的需求，但是通过一种替代形式的预索引，可能可以支持一种新的专门针对全局摘要任务的 RAG 方法。
图1：使用 LLM 推导的源文档文本图索引的图 RAG 流程。该索引涵盖了节点（例如实体）、边（例如关系）和协变量（例如声明），这些节点、边和协变量由针对数据集领域定制的 LLM 提示进行检测、提取和摘要。社区检测（例如 Leiden）用于将图索引划分为元素（节点、边、协变量）组，使 LLM 可以在索引和查询时并行地对这些组进行摘要。对于给定的查询，使用最后一轮查询聚焦摘要在所有与该查询相关的社区摘要上生成“全局答案”。
在本文中，我们提出了一种基于 LLM 派生的知识图谱的全局摘要的 GraphRAG 方法（见图1）。LLM 生成的社区描述的摘要提供了对底层图索引及其代表的输入文档的完整覆盖。然后使用 map-reduce 方法实现对整个语料库的查询聚焦摘要：首先使用每个社区摘要独立并行地回答查询，然后将所有相关的部分答案总结为最终的全局答案。
2 Graph Rag Approach & Pipeline
本章节将详细介绍 Graph RAG 方法（图 1）和流程的高层次数据流，描述每个步骤的关键设计参数、技术和实现细节。
2.1 源文档 → 文本块
一个基本的设计决策是应该以何种粒度将从源文件中提取的输入文本分割成用于处理的文本块。在接下来的步骤中，每个文本块将被传递给一组 LLM 提示，旨在提取图索引的各种元素。较长的文本块需要较少的 LLM 调用来进行此类提取，但会因较长的 LLM 上下文窗口而导致召回率下降。在一个样本数据集上，使用 600 个 token 的块大小提取的实体引用几乎是使用 2400 个 token 的块大小的两倍。虽然更多的引用通常更好，但任何提取过程都需要平衡召回率和精确度。
图2：在使用 gpt-4-turbo 进行通用实体提取提示时，HotPotQA 数据集中检测到的实体引用随着文本块大小和提取结果而变化。
2.2 文本块 → 元素实例
此步骤的基本要求是从每个源文本块中识别和提取图节点和边的实例。我们使用 multipart prompt 来完成这项工作，该提示首先识别文本中的所有实体，包括它们的名称、类型和描述，然后识别明显相关实体之间的关系，包括源实体和目标实体以及它们关系的描述。这两种类型的元素实例都以分隔的元组列表的形式输出。
提供几个示例给 LLM 进行上下文学习，就可以实现将提示定制到文档语料库领域。我们还支持一个次要提取提示，用于我们希望与提取的节点实例关联的任何附加协变量。我们的默认协变量提示旨在提取与检测到的实体相关联的声明，包括主题、对象、类型、描述、源文本范围以及开始和结束日期。
为了平衡效率和质量的需求，我们使用多轮“拾取（gleanings）”，最多达到指定的最大值，以鼓励 LLM 检测在之前的提取轮次中可能错过的任何其他实体。这是一个多阶段过程，我们首先要求 LLM 评估是否所有实体都被提取，使用 100 的 logit bias 来强制进行是/否决策（参考 Using logit bias to alter token probability with the OpenAI API。如果 LLM 响应说错过了实体，那么一个继续提示，表明“在上一次提取中错过了许多实体”，鼓励 LLM 拾取这些缺失的实体。这种方法允许我们使用更大的块大小而不会降低质量，也不会强制引入噪声。
2.3 元素实例 → 元素摘要
使用大型语言模型（LLM）“提取”源文本中表示的实体、关系和主张的描述本身就是一种抽象摘要的形式。抽象摘要不仅仅是简单地从源文本中提取和改写句子，依赖 LLM 创建可能由文本中隐含但未明确说明的概念（例如，隐含关系的存在）的独立有意义的摘要。要将所有这些实例级的摘要转换为每个图元素（即实体节点、关系边和主张协变量）的单个描述性文本块，需要对匹配的实例组进行进一步的 LLM 摘要。
LLM 可能无法始终以相同的文本格式提取到对同一实体的引用，导致实体元素的重复，从而在实体图中产生重复节点。但所有密切相关的“社区”实体将在下一步中被检测和汇总，并且 LLM 可以理解多个名称变体背后的共同实体。
总的来说，我们在潜在嘈杂的图结构中使用丰富的描述性文本来表示同质节点，这与 LLM 的能力以及全局、以查询为中心的摘要需求相一致。这些特性也使我们的图索引与典型的知识图谱区分开来，后者依赖于简洁且一致的知识三元组（主语、谓语、宾语）进行下游推理任务。
2.4 元素摘要 → 图社区
在前一步骤中创建的索引可以被建模为一个同质的、无向的、加权的图，其中实体节点通过关系边连接，边的权重为检测到的关系实例数归一化后的值。给定这样的图，可以使用各种社区检测算法将图划分为节点社区。在我们的流程中，我们使用 Leiden（Traag 等人，2019）算法，因为它能够有效地恢复大规模图的层次社区结构。这个层次的每一层都提供了一个社区划分，以互斥（mutually-exclusive）、集体穷尽（collective-exhaustive）的方式覆盖图的节点，以实现分而治之的全局摘要。
2.5 图社区 → 社区摘要
下一步是使用一种能够适用于非常大型数据集的方法，为 Leiden 层次结构中的每个社区创建类似报告的摘要。这些摘要本身就很有用，可以作为理解数据集的全局结构和语义的一种方式。例如，用户可以扫描某一层次的社区摘要以寻找感兴趣的一般主题，然后跟随链接到较低层次的详细报告以获取每个子主题的更多细节。然而，在这里我们将重点放在它们作为基于图的索引的一部分的实用性上，用于回答全局查询。
社区摘要的生成方式如下：
-
叶子级社区：首先对叶子级社区的元素摘要（节点、边、协变量）进行优先级排序，然后迭代地将其添加到 LLM 上下文窗口中，直到达到 token 限制。优先级排序如下：按照源节点和目标节点 degree 的总和（即总体重要性）降序排列社区边，然后依次添加源节点、目标节点、协变量和边的描述。
-
更高级别的社区：如果所有元素摘要都能适应上下文窗口的 token 限制，则像处理叶子级社区一样处理，并总结社区内的所有元素摘要。否则，按元素摘要 token 数量降序排列子社区，并迭代地用较短的子社区摘要替换其关联的较长元素摘要，直到适应上下文窗口为止。
2.6 社区总结 → 社区答案 → 全局答案
给定用户查询，上一步生成的社区总结可以用于在多阶段过程中生成最终答案。社区结构的层次性也意味着可以使用不同层次的社区总结来回答问题，这引发了一个问题，即层次社区结构中的特定层次是否提供了摘要细节和一般意义问题范围之间的最佳平衡。对于给定的社区层次，任何用户查询的全局答案都是按照以下方式生成的：
- Prepare community summaries：社区总结被随机打乱并分成预先指定 token 大小的块。这确保相关信息分布在各个块中，而不是集中在单个上下文窗口中。
- Map community answers：并行生成中间答案，每个块一个。LLM 还被要求生成一个介于 0 到 100 之间的分数，表示生成的答案在回答目标问题方面的有用程度。得分为 0 的答案将被过滤掉。
- Reduce to global answer：中间社区答案按照有用性评分的降序排序，并迭代地添加到一个新的上下文窗口中，直到达到令牌限制。这个最终的上下文用于生成返回给用户的全局答案。
3 评估
3.1 数据集
我们选择了两个数据集，每个数据集的文本量都在一百万个 token 范围内，相当于大约 10 本小说的文本量，代表了用户在实际活动中可能遇到的语料库类型：
-
播客转录：由微软 CTO Kevin Scott 与其他技术领袖之间的播客对话编译而成的转录文本（Behind the Tech, Scott, 2024）。大小：1669 × 600-token 文本块，块之间有 100-token 的重叠（约 100 万个 token）。
-
新闻文章：包括从 2013 年 9 月到 2023 年 12 月发布的各类新闻文章的基准数据集，涵盖娱乐、商业、体育、科技、健康和科学等多个类别（MultiHop-RAG; Tang and Yang, 2024）。大小：3197 × 600-token 文本块，块之间有 100-token 的重叠（约 170 万个 token）。
3.2 Queries
为了评估 RAG 系统在更全局感测任务中的有效性，我们需要只传达数据集内容的高层次理解，而不是特定文本细节的问题。我们采用了以 activity-centered 的方法来自动生成这样的问题：给定数据集的简短描述，我们要求 LLM 识别 N 个潜在用户和每个用户的 N 个任务，然后对于每个（用户，任务）组合，我们要求 LLM 生成 N 个需要理解整个语料库的问题。在我们的评估中，N = 5 的值导致每个数据集有 125 个测试问题。
3.3 条件分析
在本章节的分析中，我们比较了六种不同的条件，包括使用四个不同层次的图社区（C0, C1, C2, C3）的 Graph RAG 方法，一种直接对源文本应用 map-reduce 方法的文本摘要方法（TS），以及一种简单的“语义搜索” RAG 方法（SS）：
- C0：使用根级社区摘要（数量最少）回答用户查询。
- C1：使用高层社区摘要回答查询。
- C2：使用中间层社区摘要回答查询。
- C3：使用低层社区摘要（数量最多）回答查询。
- TS：与小节 2.6 中的方法相同，除了源文本（而不是社区摘要）被洗牌并分块用于 map-reduce 摘要阶段。
- SS：一种简单的 RAG 实现，其中文本块被检索并添加到可用的上下文窗口中，直到达到指定的 token 限制。
所有六种条件的上下文窗口大小和用于答案生成的提示基本上是相同的。
3.4 Metrics
由于我们的 Graph RAG 机制的多阶段性质，我们想要比较的多种条件，以及 activity-based 理解问题缺乏黄金标准答案，我们决定采用 LLM 评估器进行 head-to-head 比较的方法。我们选择了以下四个指标：
- Comprehensiveness（全面性）：答案提供了多少细节来涵盖问题的所有方面和细节？
- Diversity（多样性）：答案在提供问题的不同视角和见解方面有多丰富和多样？
- Empowerment（赋能性）：答案在帮助读者理解和对主题做出明智判断方面做得如何？
- Directness（直接性）：答案在具体和清晰地回答问题方面做得如何？
在我们的评估中，会提供给 LLM 问题、目标指标和一对答案，要求它评估哪个答案在指标上更好，以及为什么。它会返回胜者，如果它们在根本上相似则返回平局。为了考虑 LLM 的随机性，我们对每个比较运行五次，并使用平均分数。
3.5 配置
对于像 gpt-4-turbo 这样具有 128k token 大上下文大小的模型，上下文窗口大小对特定任务的影响尚不清楚。考虑到在较长上下文中信息存在“丢失在中间”的可能性，我们想探索不同上下文窗口大小对我们数据集、问题和指标组合的影响。特别是，我们的目标是确定基线条件（SS）的最佳上下文大小，然后将其统一用于所有查询时 LLM 使用。为此，我们测试了四种上下文窗口大小：8k、16k、32k 和 64k。令人惊讶的是，测试的最小上下文窗口大小（8k）在全面性方面普遍更好（平均胜率为 58.1%），而在多样性（平均胜率 = 52.4%）和赋能（平均胜率 = 51.3%）方面与较大的上下文大小表现相当。鉴于我们对更全面和多样化答案的偏好，因此我们在最终评估中使用了固定的 8k token上下文窗口大小。
3.6 结果
图4：所有的 Graph RAG 条件在全面性和多样性方面都优于naive RAG。C1-C3 条件在回答的全面性和多样性方面也相对于没有图索引的全局文本摘要（TS）有轻微的改进。
Graph RAG 的可扩展性优势：对于低级社区摘要（C3），Graph RAG 所需的上下文标记数减少了 26-33%，而对于根级社区摘要（C0），所需的标记数减少了超过 97%。与其他全局方法相比，根级 Graph RAG 在性能上略有下降，但在全面性（72%胜率）和多样性（62%胜率）方面仍保持优势，成为表征意义构建活动的迭代问答的高效方法。
4 相关工作
在使用大型语言模型（LLMs）时，RAG（检索增强生成）首先从外部数据源中检索相关信息，然后将这些信息与原始查询一起添加到 LLM 的上下文窗口中。朴素 RAG 方法通过将文档转换为文本，将文本拆分为块，并将这些块嵌入到一个向量空间中，其中相似的位置代表相似的语义来实现这一点。查询也被嵌入到相同的向量空间中，最近的 k 个向量的文本块被用作上下文。
高级 RAG 系统包括预检索、检索、后检索策略，旨在克服朴素 RAG 的缺点，而模块化 RAG（Modular RAG）系统包括用于迭代和动态循环的交错检索和生成的模式。我们对 Graph RAG 的实现结合了与其他系统相关的多个概念。例如，我们的社区摘要是一种用于生成增强检索的自记忆，而从这些摘要中并行生成社区答案是一种迭代或联合检索-生成策略。其他系统也结合了这些概念用于多文档摘要和多跳问答。我们使用的分层索引和摘要方法也与其他方法相似，例如通过对文本嵌入向量进行聚类生成文本块的分层索引，或者生成“澄清树（tree of clarifications）”来回答模糊问题的多种解释。
5 讨论
我们一致观察到 Graph RAG 在与其他方法的正面比较中取得了最佳结果，但在许多情况下，无图的源文本全局摘要方法表现也很有竞争力。
