admin管理员组

文章数量:1130349

💡 文章信息

TitleFrom Local to Global: A Graph RAG Approach to Query-Focused Summarization
Journalhttp://arxiv/abs/2404.16130
AuthorsDarren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Jonathan Larson
Pub.date2024-04-24

📕 研究动机

        传统RAG方法在回答全局性问题（如从整个文本语料中提炼主题）时表现不佳，因为此类问题更适合以查询为中心的摘要生成（QFS）。尽管已有QFS方法，但它们通常难以扩展到典型RAG系统索引的大规模文本量。因此，提出Graph RAG方法，希望结合RAG和QFS的优势，在全局性问题和大规模文本处理方面提供更好的解法。

📊 研究方法

1. 实验模型

1) 源文档 → 文本块

  • 较长的文本块需要较少的LLM调用，但会因较长的LLM上下文窗口而导致回忆效果下降

  • 在一个样本数据集中，使用600个token的块大小提取的实体引用几乎是使用2400个token块大小的两倍

2) 文本块 → 元素实例

  • 通过一个多部分LLM prompt，首先识别文本中的所有实体，包括它们的名称、类型和描述，然后识别明确相关的实体之间的所有关系，包括源实体和目标实体以及它们关系的描述。所有元素实例都以分隔的元组列表形式输出。

  • 支持次要提取prompt，用于提取希望与节点实例关联的其他协变量。默认协变量prompt旨在提取与检测到的实体相关的声明，包括主语、宾语、类型、描述、源文本范围及其起止日期。

  • 系统采用多轮“gleanings”，直到达到指定的最大次数，以鼓励LLM检测前几轮提取中可能遗漏的其他实体。

3) 元素实例 → 元素总结

  • 将所有这些实例级别的总结转换为每个图元素（如实体节点、关系边和声明协变量）的单个描述性文本块，需要进一步通过LLM对匹配的实例组进行总结。

4) 元素总结 → 图社区

  • 上一步中创建的索引可以建模为一个同质无向加权图，其中实体节点通过关系边连接，边权重表示检测到的关系实例的归一化计数。

  • 使用Leiden算法将图划分为节点之间的层次社区结构。

5) 图社区 → 社区总结

  • 叶层社区：最底层社区，包含最细粒度的信息

    • 按照优先级（社区内边的源节点和目标节点的度数）处理叶层社区的元素总结。

    • 元素包括节点、边，以及与它们关联的协变量（如属性、标签等）。

    • 将这些信息逐步添加到 LLM 的上下文窗口中

  • 高层社区：较高层次的社区，包含更抽象、更综合的信息

    • 未超过token限制

      • 按顺序汇总高层社区内的所有元素总结，逐步加入上下文

    • 超过token限制

      • 按元素总结的 token 长度递减对子社区排序（优先处理简短的总结）

      • 用子社区的较短总结替换对应的 长元素总结，逐步减少 token 占用，直到符合限制

6) 社区总结 → 社区答案 → 全局答案

  • 准备社区总结

    • 将社区总结随机打乱并分成预先指定大小的块。这确保了相关信息分散在各个块中，而不是集中在单个上下文窗口内，从而避免信息丢失。

  • 映射社区答案

    • 并行生成每个块的中间答案。同时要求LLM对生成的答案进行0到100的评分，表示其在回答目标问题时的帮助程度。得分为0的答案将被剔除。

  • 归并至全局答案

    • 将中间社区答案按帮助评分从高到低排序，并逐步添加到新的上下文窗口中，直到达到token限制。然后利用这个最终上下文生成返回给用户的全局答案。

2. 实验细节

1) 数据集

选择两个约一百万token的数据集，每个数据集相当于大约10本小说的文本，代表用户在实际活动中可能遇到的语料库类型。

  • 播客转录：整理了微软CTO Kevin Scott与其他技术领导者之间播客对话的转录。规模：1669个600-token的文本块，每个块之间有100-token的重叠（约100万token）。

  • 新闻文章：基准数据集，包括从2013年9月到2023年12月发布的各类新闻文章，涵盖娱乐、商业、体育、技术、健康和科学等类别。规模：3197个600-token的文本块，每个块之间有100-token的重叠（约170万token）。

2) 查询

  • HotPotQA、MultiHop-RAG、MT-bench等现有开放领域问答数据集是为了事实检索，而不是为了总结摘要。

  • 采用了一种以活动为中心的方法来自动生成这些问题：给定一个数据集的简短描述，要求LLM识别N个潜在用户及每个用户的N个任务，然后对于每个（用户，任务）组合，要求LLM生成N个需要理解整个语料库的问题。设置N=5。

3) 条件

  • C0：使用根层社区总结（数量最少）回答用户查询。

  • C1：使用高层社区总结回答查询。这些是C0的子社区（如果存在），否则是C0社区的投影下层。

  • C2：使用中层社区总结回答查询。这些是C1的子社区（如果存在），否则是C1社区的投影下层。

  • C3：使用低层社区总结（数量最多）回答查询。这些是C2的子社区（如果存在），否则是C2社区的投影下层。

  • TS：与第2.6节中的方法相同，只不过源文本（而不是社区总结）被打乱和分块以进行map-reduce总结阶段。

  • SS：一种基础RAG实现，检索文本块并将其添加到可用的上下文窗口中，直到达到指定的token限制。

上下文窗口的大小和用于答案生成的prompts在所有六种条件下都是相同的（除了对参考样式的微小修改以匹配所用的上下文信息类型）。条件的不同之处仅在于如何创建上下文窗口内容。支持C0-C3条件的图索引仅使用通用prompts进行实体和关系提取，实体类型和少样本示例根据数据领域进行了定制。图索引过程使用600个token的上下文窗口，Podcast数据集使用1次gleaning，News数据集使用0次gleaning。

4) 指标

        利用LLM从四个方面进行评估：

  • 全面性：答案提供了多少细节来覆盖问题的各个方面和细节？

  • 多样性：答案在提供不同观点和见解方面有多丰富和多样？

  • 实用性：答案在帮助读者理解和做出明智判断方面的效果如何？

  • 直接性：答案在多大程度上具体且清晰地回答了问题？

其中，直接性与全面性、多样性相悖，因此，不可能在四项指标上都优越。

5) 配置

  • 上下文窗口：通过测试8k、16k、32k和64k，8k在全面性上表现最佳。在多样性和实用性方面表现与较大窗口相当，因此，选用8k作为上下文窗口大小。

3. 实验结果

  • 索引过程为Podcast数据集生成了一个包含8564个节点和20691条边的图，而为News数据集生成了一个包含15754个节点和19520条边的更大图。

  • 全局方法与基础RAG的比较

🚩 研究结论

1. 全局方法在全面性和多样性指标上均显著优于基础RAG（SS）方法。

  • 全局方法在博客转录数据集中的全面性胜率为72-83%，多样性胜率为75-82%。

  • 在新闻文章数据集中的胜率为72-80%，多样性胜率为和62-71%。

2. 基础RAG在所有比较中产生了最直接的响应。

3. 社区总结优于源文本（TS）

  • 除根层总结外，社区总结在全面性和多样性上均表现出一致的改进

    • Podcast数据集中，中层社区总结的全面性和多样性胜率均为57%。

    • 新闻数据集中，低层社区总结的全面性胜率为64%，多样性胜率为60%。

  • 效率优势

    • 低层社区总结（C3）比源文本总结减少了26-33%的上下文token使用量。

    • 根层社区总结（C0）减少了97%的token使用量。

4. GraphRAG在帮助用户理解上的表现有所局限，具体示例和引文的缺乏可能影响用户的信任度和认知支持。

📌 思考体会

1. 创新点

  • 利用社区检测算法划分层次结构，可以使用不同层次的社区总结来回答问题

  • 根据问题，选择在细节和范围方面最佳平衡的层次

2. 不足之处

  • 分层次总结汇总，响应速度较慢

  • 帮助用户理解表现具有局限性

💡 文章信息

TitleFrom Local to Global: A Graph RAG Approach to Query-Focused Summarization
Journalhttp://arxiv/abs/2404.16130
AuthorsDarren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Jonathan Larson
Pub.date2024-04-24

📕 研究动机

        传统RAG方法在回答全局性问题（如从整个文本语料中提炼主题）时表现不佳，因为此类问题更适合以查询为中心的摘要生成（QFS）。尽管已有QFS方法，但它们通常难以扩展到典型RAG系统索引的大规模文本量。因此，提出Graph RAG方法，希望结合RAG和QFS的优势，在全局性问题和大规模文本处理方面提供更好的解法。

📊 研究方法

1. 实验模型

1) 源文档 → 文本块

  • 较长的文本块需要较少的LLM调用，但会因较长的LLM上下文窗口而导致回忆效果下降

  • 在一个样本数据集中，使用600个token的块大小提取的实体引用几乎是使用2400个token块大小的两倍

2) 文本块 → 元素实例

  • 通过一个多部分LLM prompt，首先识别文本中的所有实体，包括它们的名称、类型和描述，然后识别明确相关的实体之间的所有关系，包括源实体和目标实体以及它们关系的描述。所有元素实例都以分隔的元组列表形式输出。

  • 支持次要提取prompt，用于提取希望与节点实例关联的其他协变量。默认协变量prompt旨在提取与检测到的实体相关的声明，包括主语、宾语、类型、描述、源文本范围及其起止日期。

  • 系统采用多轮“gleanings”，直到达到指定的最大次数，以鼓励LLM检测前几轮提取中可能遗漏的其他实体。

3) 元素实例 → 元素总结

  • 将所有这些实例级别的总结转换为每个图元素（如实体节点、关系边和声明协变量）的单个描述性文本块，需要进一步通过LLM对匹配的实例组进行总结。

4) 元素总结 → 图社区

  • 上一步中创建的索引可以建模为一个同质无向加权图，其中实体节点通过关系边连接，边权重表示检测到的关系实例的归一化计数。

  • 使用Leiden算法将图划分为节点之间的层次社区结构。

5) 图社区 → 社区总结

  • 叶层社区：最底层社区，包含最细粒度的信息

    • 按照优先级（社区内边的源节点和目标节点的度数）处理叶层社区的元素总结。

    • 元素包括节点、边，以及与它们关联的协变量（如属性、标签等）。

    • 将这些信息逐步添加到 LLM 的上下文窗口中

  • 高层社区：较高层次的社区，包含更抽象、更综合的信息

    • 未超过token限制

      • 按顺序汇总高层社区内的所有元素总结，逐步加入上下文

    • 超过token限制

      • 按元素总结的 token 长度递减对子社区排序（优先处理简短的总结）

      • 用子社区的较短总结替换对应的 长元素总结，逐步减少 token 占用，直到符合限制

6) 社区总结 → 社区答案 → 全局答案

  • 准备社区总结

    • 将社区总结随机打乱并分成预先指定大小的块。这确保了相关信息分散在各个块中，而不是集中在单个上下文窗口内，从而避免信息丢失。

  • 映射社区答案

    • 并行生成每个块的中间答案。同时要求LLM对生成的答案进行0到100的评分，表示其在回答目标问题时的帮助程度。得分为0的答案将被剔除。

  • 归并至全局答案

    • 将中间社区答案按帮助评分从高到低排序，并逐步添加到新的上下文窗口中，直到达到token限制。然后利用这个最终上下文生成返回给用户的全局答案。

2. 实验细节

1) 数据集

选择两个约一百万token的数据集，每个数据集相当于大约10本小说的文本，代表用户在实际活动中可能遇到的语料库类型。

  • 播客转录：整理了微软CTO Kevin Scott与其他技术领导者之间播客对话的转录。规模：1669个600-token的文本块，每个块之间有100-token的重叠（约100万token）。

  • 新闻文章：基准数据集，包括从2013年9月到2023年12月发布的各类新闻文章，涵盖娱乐、商业、体育、技术、健康和科学等类别。规模：3197个600-token的文本块，每个块之间有100-token的重叠（约170万token）。

2) 查询

  • HotPotQA、MultiHop-RAG、MT-bench等现有开放领域问答数据集是为了事实检索，而不是为了总结摘要。

  • 采用了一种以活动为中心的方法来自动生成这些问题：给定一个数据集的简短描述，要求LLM识别N个潜在用户及每个用户的N个任务，然后对于每个（用户，任务）组合，要求LLM生成N个需要理解整个语料库的问题。设置N=5。

3) 条件

  • C0：使用根层社区总结（数量最少）回答用户查询。

  • C1：使用高层社区总结回答查询。这些是C0的子社区（如果存在），否则是C0社区的投影下层。

  • C2：使用中层社区总结回答查询。这些是C1的子社区（如果存在），否则是C1社区的投影下层。

  • C3：使用低层社区总结（数量最多）回答查询。这些是C2的子社区（如果存在），否则是C2社区的投影下层。

  • TS：与第2.6节中的方法相同，只不过源文本（而不是社区总结）被打乱和分块以进行map-reduce总结阶段。

  • SS：一种基础RAG实现，检索文本块并将其添加到可用的上下文窗口中，直到达到指定的token限制。

上下文窗口的大小和用于答案生成的prompts在所有六种条件下都是相同的（除了对参考样式的微小修改以匹配所用的上下文信息类型）。条件的不同之处仅在于如何创建上下文窗口内容。支持C0-C3条件的图索引仅使用通用prompts进行实体和关系提取，实体类型和少样本示例根据数据领域进行了定制。图索引过程使用600个token的上下文窗口，Podcast数据集使用1次gleaning，News数据集使用0次gleaning。

4) 指标

        利用LLM从四个方面进行评估：

  • 全面性：答案提供了多少细节来覆盖问题的各个方面和细节？

  • 多样性：答案在提供不同观点和见解方面有多丰富和多样？

  • 实用性：答案在帮助读者理解和做出明智判断方面的效果如何？

  • 直接性：答案在多大程度上具体且清晰地回答了问题？

其中，直接性与全面性、多样性相悖，因此，不可能在四项指标上都优越。

5) 配置

  • 上下文窗口：通过测试8k、16k、32k和64k，8k在全面性上表现最佳。在多样性和实用性方面表现与较大窗口相当，因此，选用8k作为上下文窗口大小。

3. 实验结果

  • 索引过程为Podcast数据集生成了一个包含8564个节点和20691条边的图，而为News数据集生成了一个包含15754个节点和19520条边的更大图。

  • 全局方法与基础RAG的比较

🚩 研究结论

1. 全局方法在全面性和多样性指标上均显著优于基础RAG（SS）方法。

  • 全局方法在博客转录数据集中的全面性胜率为72-83%，多样性胜率为75-82%。

  • 在新闻文章数据集中的胜率为72-80%，多样性胜率为和62-71%。

2. 基础RAG在所有比较中产生了最直接的响应。

3. 社区总结优于源文本（TS）

  • 除根层总结外，社区总结在全面性和多样性上均表现出一致的改进

    • Podcast数据集中，中层社区总结的全面性和多样性胜率均为57%。

    • 新闻数据集中，低层社区总结的全面性胜率为64%，多样性胜率为60%。

  • 效率优势

    • 低层社区总结（C3）比源文本总结减少了26-33%的上下文token使用量。

    • 根层社区总结（C0）减少了97%的token使用量。

4. GraphRAG在帮助用户理解上的表现有所局限，具体示例和引文的缺乏可能影响用户的信任度和认知支持。

📌 思考体会

1. 创新点

  • 利用社区检测算法划分层次结构，可以使用不同层次的社区总结来回答问题

  • 根据问题，选择在细节和范围方面最佳平衡的层次

2. 不足之处

  • 分层次总结汇总，响应速度较慢

  • 帮助用户理解表现具有局限性

本文标签： 学习笔记GlobalGraphRAGlocal

版权声明：本文标题：【学习笔记】From Local to Global: A Graph RAG Approach to Query-Focused Summarization 内容由热心网友自发贡献，该文观点仅代表作者本人， 转载请联系作者并注明出处：https://it.en369.cn/jiaocheng/1763630980a2949683.html， 本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，一经查实，本站将立刻删除。