GraphRAG 论文笔记

GraphRAG 论文笔记

From Local to Global: A Graph RAG Approach to Query-Focused Summarization

一种从文本构建并增强知识图的方法，来解决 Baseline RAG 系统在全局理解上的缺陷，例如：

• Baseline RAG 系统在面对需要从多源信息中抽取并综合分析的情况时，会遭遇显著的障碍。具体来说，当回答一个复杂问题涉及到通过识别和利用不同信息片段之间的共享属性，来构建新的、综合性见解时，Baseline RAG 无法有效连接这些“点”，导致 信息整合上的不足。
• 在要求 Baseline RAG 对大规模的数据集合或是单篇幅巨大的文档进行全面而深入的理解时，它的表现会显得较为逊色。这通常是因为它在处理大量数据时，难以有效地捕捉和理解那些被浓缩于其中的关键语义概念，从而影响了整体的理解质量。

Graph RAG Approach & Pipeline

Source Documents -> Text Chunks

将源文件中提取出来的输入文本分割成适合处理的小块，每个小块都会传送给一系列LLM来获取图索引里的各种元素。

抽取过程都须同时考虑到召回率和精确性之间的平衡关系：

• 较长的文本块对会用到比较少的LLM调用次数
• 较长的上下文窗口会导致召回能力降低： 对样本单次提取（即无额外搜集）时，使用 600 tokens 的块的提取4次，比直接使用2400 tokens 的块提取1次，所提取的实体数量前者比后者多出一倍。

Text Chunks -> Element Instances

识别并从每个源文本块中抽取图节点和边的实例。

两种类型的元素实例均以分隔的元组形式输出在一个单独的列表中。

• 实体（entities），

  • 名称（name）
  • 类型（type）
  • 描述（description），

• 相关实体之间的所有关系（relationships）：

  • 源实体（source）
  • 目标实体（target）
  • 关系描述（a description of their relationship）。

• 主张（Claims） ：主张通常指的是关于实体及其关系的陈述，它包含了 一个或多个实体和关系的信息。包括主题、对象、类型、描述、源文本范围以及开始和结束日期等

实体

(entity)<|><entity_name><|><entity_type><|><entity_description>)

关系

(relation)<|><source_entity><|><target_entity><|><relationship_description>|<relationship_strength>)

---

【提取方式】

多轮"收集（gleanings）"操作，指定的最大轮数，激励LLM去发现其之前抽取过程中可能错过的额外实体。

• 令LLM评估是否已经成功地提取出了所有的实体，并且通过设置 logit 偏置值为100来迫使它作出"yes"/"no"的选择。

• 如果LLM回答说有一些实体没有被正确识别出来，那么接着让它给出一些提示，比如 "在上一次抽取中有许多实体未被发现" 这样的话可以让LLM去找到那些丢失的实体。

  这样做的好处是可以让我们在不人为加入噪音或者不损害数据质量的前提下更多地去提取实体元素。

Element Instances -> Element Summaries

不同的 TextUnit 可能包含了关于同一实体的不同描述。因此一个实体可能存在多个不同的描述。这种情况下，我们不仅需要识别和提取实体，还要整合关于同一实体的多方面信息，确保我们的实体描述尽可能完整和准确。

在 Element Summarization 过程中，LLM 将对某一实体的描述列表转化为一个简短的摘要，并确保每个实体和关系都有且仅有一段简洁的的描述信息。

【潜在问题】

LLM 可能会从文本中提取到对同一个实体不一致引用，这会导致 entities 出现重复，进而使得实体图中的节点也发生重复。

不过，由于所有密切相关的实体 “社群（communities）”都将在下一步中被检测和总结，并且考虑到 LLM 可以理解多个名称变体背后的共同实体，因此只要所有变体都与密切相关的实体共享集有足够的连接性，我们的整体方法就能应对此类变体。

Element Summaries -> Graph Communities

上一步中创建的索引可以被看作是一个同质无向加权图，在这个图中，实体节点通过关系边相连，并且边的权重代表了relationship的归一化值。有了这样的图，我们可以应用多种社群检测算法来把这张图划分成一些子群组，这些子群组内的节点彼此之间相比其他节点有更紧密的联系。

Leiden算法能有效地处理大型网络数据集的层级社群结构。这种层级结构里的每一层都会给出一个社群划分，该划分以一种互斥且完备的方式覆盖图中的所有节点，从而实现了“分而治之”的全局总结策略。

Graph Communities -> Community Summaries

利用一种用于处理大规模数据集的方法来生成Leiden层级体系中每一个社群的报告式总结。这些摘要本身作为理解数据集的全局结构和语义的方法是非常有用的，并且它们本身可以用于在没有问题的情况下理解语料库。

例如，用户可以在一个级别上浏览社群摘要，寻找感兴趣的一般主题，然后通过链接进入较低层次的报告，了解每个子主题的更多详细信息。然而，在这里，现在我们优先关注其作为回答全局查询问题的索引的这一部分的功能。

社群报告的生成方式：

• 叶级社群。叶级社群的元素摘要（节点、边、协变量）会被优先排序，然后迭代添加到 LLM 上下文窗口中，直到达到token限制。

  优先级排序如下：对每一条社群边，按照其源节点和目标节点的度（所连边的数量）之和递减排序，以此为基础依次为其添加相应的源节点、目标节点、关联协变量和边本身的描述。

• 高级社群。如果所有元素摘要都在上下文窗口的token限制范围内，则按照叶级社群的方法，对社群内的所有元素摘要进行拼接汇总。否则，就按照元素摘要tokens的数量来对子社群进行排序，并用较短的子社群摘要替换其所在的父社群的较长元素摘要，直到符合上下文窗口的要求。

Community Summaries -> Community Answers -> Global Answer

给定一个用户查询，在上一步中生成的社群摘要可以用于在一个多阶段过程中生成最终答案。社群结构的分层性质还意味着可以使用来自不同级别的社群摘要来回答问题，这就提出了这样一个问题：即对于一般意义理解的问题来说，分层社群结构中的特定层级提供的回答是否最佳平衡了摘要细节和范围？

给定社群层级，对任意用户查询生成global答案流程如下：

• 准备社群摘要。社群摘要按照预设的tokens数量划分成若干部分并被随机打乱顺序。这样可以保证相关的信息分散到各个部分中去，而不会集中在某一部分（甚至可能会丢失）。
• 映射社群答案。并行生成每个部分的中间答案。LLM还需要生成一个 0 ~ 100 之间的分数，表示生成的答案在回答目标问题时的帮助程度。分数为 0 的答案将被过滤掉。
• 还原为全局答案。中间社群答案根据有用性得分降序排序，并在新的上下文窗口中迭代地添加，直到达到令牌限制为止。最终的上下文将用于生成返回给用户的全局答案。

Evaluation

Datasets

2个百万词量级的数据集，每个相当于是十本小说的文字内容，并且能够很好地反映出用户在实际工作中可能会接触到的一些语料库。

• Podcast transcripts：

  • Kevin Scott和其他科技领袖之间的播客对话记录（Behind the Tech, Scott, 2024）。

  • size：$1669 \times 600 (文本块 \times \text{tokens})$，每个文本块之间有 $100$ tokens的重叠（大约 100万 tokens）。

• News articles:

  • 包含自2013年9月至2023年12月期间发布的一系列类别的新闻文章的基准数据集，其中包括娱乐、商业、体育、科技、健康和科学
  • size: $3197 \times 600 (文本块 \times \text{tokens})$，每个文本块之间有 $100$ tokens的重叠（大约 170万 tokens）。

Queries

采用了一种以活动为中心的方式来自动地生成此类问题：给定一个简短的数据集描述，

• 让LLM找出 $N$ 个可能的用户，每个用户给定 $N$ 项任务
• 针对每个 $(用户、任务)$ 组合，要求 LLM 生成 $N$ 个需要理解整个语料库的问题。

当 $N=5$ 时，得到 $125$ 道测试题/数据集。

Conditions

分析中比较了六种不同的情况，包括使用四级图社群（$\mathbf {C0}$、$\mathbf {C1}$、$\mathbf {C2}$、$\mathbf {C3}$）、直接把 map-reduce 方法应用于源文本的文本摘要方法（$\mathbf {TS}$），以及 “语义搜索 ”的朴素RAG 方法 ($\mathbf {SS}$)

• $\mathbf {C0}$. 使用根级社群摘要（数量最少）回答用户查询。
• $\mathbf {C1}$. 使用高级社群摘要回答查询。如果存在的话，即为 $\mathbf {C0}$ 的子社群，否则为 $\mathbf {C0}$ 社群往下投射得到的结果。
• $\mathbf {C2}$. 使用中级社群摘要回答查询。如果存在的话，即为 $\mathbf {C1}$ 的子社群，否则为 $\mathbf {C1}$ 社群往下投射得到的结果。
• $\mathbf {C3}$. 使用低级社群摘要（数量最多）回答查询。如果存在的话，即为 $\mathbf {C2}$ 的子社群，否则为 $\mathbf {C2}$ 社群往下投射得到的结果。
• $\mathbf {TS}$. 只是源文本（而非社群摘要）,在 map-reduce 摘要阶段会被洗牌和分块。
• $\mathbf {SS}$. 朴素RAG 的实现，其中文本块被检索并添加到可用的上下文窗口，直到达到指定的标记限制。

所有六种条件（除了为了匹配所使用的context信息类型而对引用样式做的小修改之外），生成答案时所用到的窗口大小以及提示词都一致。区别仅在于上下文窗口的内容创建。

支持图索引的方法 $\mathbf {C0}- \mathbf {C3}$ 使用通用提示方法创建，仅为了提取entity和relationship，以及根据领域数据定制的entity类型和少量示例。图索引过程使用了 $600$ 个tokens的上下文窗口大小，其中 Podcast transcripts数据集的收集1次，News articles 数据集没有进行任何收集。

Metrics

• 体现感知活动中的质量

  • 全面性（Comprehensiveness）。答案提供了多少细节以涵盖问题的所有方面和细节？

  • 多样性（Diversity）。答案在提供有关问题的不同观点和见解方面的多样性和丰富程度如何？

  • 有效性（Empowerment）。答案在多大程度上帮助读者理解题目并做出明智的判断？

• 有效性指标的控制度量

  • 直接性（Directness）。答案如何具体、清晰地回答问题？

在评估中，向 LLM 提供了问题、目标指标和一对答案，并要求它根据指标评估哪个答案更好，以及为什么。

如果存在获胜者，则返回获胜者答案；否则，如果没有明显区别或者相似得无法分辨那就判定为平手。考虑到 LLM 的随机性，将每次比较运行$5$ 次，并使用平均分数进行评判。

• 行方法）相对于（列方法）的 Head to head胜利率百分比。
• 包括 $2$ 个数据集，$4$ 种度量标准以及 $125$ 个问题(每个重复 $5$ 次并取平均值)
• 自胜率未计算，显示为预期的 $50\%$ 作为参考

Configuration

上下文窗口

由于上下文窗口大小对某个特定任务的效果不明确，因此以 $\mathbf {SS}$ 为 baseline 测试了8k、16k、32k 和 64k 四种上下文窗口大小。

• 全面性（comprehensiveness）上 8k 表现最好
• 多样性（平均胜率 = 52.4%）和有效性（平均胜率 = 51.3%）方面的 8k 表现与较大的上下文大小相当。

因此在最终评估中使用了 8k 标记的固定上下文窗口大小

Results

	Podcast dataset	News dataset
nodes	8564	15754
edges	20691	19520

Reference