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

MetaData

发表时间 2024.04.24
作者：Darren Edge, Ha Trinh, Newman Cheng, Joshua Bradley, Alex Chao, Apurva Mody, Steven Truitt, Jonathan Larson
论文链接：https://arxiv.org/abs/2404.16130
项目链接：https://github.com/microsoft/graphrag

摘要

使用检索增强生成(RAG)从外部知识源检索相关信息，使大型语言模型(LLM)能够回答有关私人和/或以前未见文档集合的问题。但是，RAG无法回答针对整个文本语料库的全局问题，例如“数据集的主要主题是什么？”，因为这本质上是一个查询集中摘要(query-focused summarization，QFS)任务，而不是一个显式检索任务。同时，先前的QFS方法无法扩展到典型RAG系统索引的文本数量。为了结合这些对比方法的优势，我们提出了一种图RAG方法来回答有关私人文本语料库的问题，该方法可随着用户问题的一般性和要索引的源文本数量而扩展。我们的方法使用LLM在两个阶段构建基于图的文本索引：首先从源文档中推导出实体知识图，然后为所有紧密相关的实体组预生成社区摘要。给定一个问题，每个社区摘要用于生成一个部分响应，然后所有部分响应再次在最终响应中汇总给用户。对于100万个词元范围内的数据集的全局意义问题，我们表明，对于生成答案的全面性和多样性，图RAG比传统的RAG基线方法有了显著的改进。全局和局部图RAG方法的开源Python实现即将在https://aka.ms/graphrag上发布。

1 引言

在各个领域，人类的努力都依赖于我们阅读和推理大量文档的能力，我们经常得出超出源文本本身的结论。随着大型语言模型(LLM)的出现，我们已经见证了人们试图在科学发现(Microsoft,2023)和情报分析(Ranade 和 Joshi,2023)等复杂领域中自动执行类似人类的意义建构，其中意义建构被定义为“为了预测轨迹并有效地采取行动，理解人、地点和事件之间联系的持续努力”(Klein 等人，2006)。然而，支持人类主导的针对整个文本语料库的意义建构，需要一种方法让人们能够通过提出全局性质的问题来应用和完善他们对数据的思维模型 (Klein 等人，2006b)。

检索增强生成(RAG，Lewis 等人，2020) 是一种成熟的方法，用于回答有关整个数据集的用户问题，但它适用于答案在文本区域内局部包含的情况，这些区域的检索为生成任务提供了足够的依据。相反，更合适的任务框架是查询集中摘要(QFS，Dang，2006)，尤其是查询集中的"抽象的"摘要，它生成自然语言摘要，而不仅仅是串联的摘录(Yao 等人，2017；Baumel 等人，2018；Laskar 等人， 2020)。近年来，摘要任务之间的区别，无论是抽象的还是提取的，通用的还是针对查询的，以及单文档的还是多文档的，都变得越来越不相关。虽然Transformer架构的早期应用在所有这些摘要任务中都显示出显著的改进(Liu and Lapata, 2019; Laskar et al., 2022; Goodwin et al., 2020)，但现在这些任务已经被现代LLM简化了，包括GPT(Brown et al., 2020; Achiam et al., 2023)、Llama (Touvron et al., 2023)和Gemini(Anil et al., 2023) 系列，所有这些模型都可以使用上下文学习来总结其上下文窗口中提供的任何内容。

然而，对整个语料库进行针对查询的抽象摘要仍然是一个挑战。如此大量的文本可能会远远超过LLM上下文窗口的限制，而扩展这些窗口可能也不足以解决信息可能在较长上下文中“丢失在中间”的问题(Liu et al., 2023; Kuratov et al., 2024)。此外，虽然在朴素的RAG中直接检索文本块可能不足以完成QFS任务，但有可能另一种形式的预索引可以支持一种新的RAG方法，专门针对全局摘要。

在本文中，我们提出了一种基于LLM生成的知识图的全局摘要的Graph RAG方法（图1）。与利用图索引的结构化检索和遍历功能的相关工作(见4.2)相反，我们关注在这个背景下图的先前未探索的质量：它们固有的模块化以及社区检测算法将图划分为密切相关的节点的模块化社区的能力。这些社区描述的LLM生成的摘要提供了对底层图索引及其表示的输入文档的完整覆盖。然后可以使用Map-Reduce方法实现对整个语料库的针对查询的摘要：首先使用每个社区摘要独立地并行地回答查询，然后将所有相关的部分答案总结成最终的全局答案。

图1: 使用LLM生成的源文档文本图索引的Graph RAG管道。该索引跨越节点（例如实体）、边（例如关系）和协变量（例如声明），这些节点、边和协变量已由针对数据集领域定制的LLM提示检测、提取和总结。社区检测用于将图索引划分为元素（节点、边、协变量）组，LLM可以在这两种索引时间和查询时间并行地对这些元素进行总结给定查询的“全局答案”是通过对所有报告与该查询相关的社区摘要进行最后一轮针对查询的摘要而产生的。

为了评估这种方法，我们使用 LLM从两个代表性的真实世界数据集的简短描述中生成了一组多样化的以活动为中心的意义建构问题，这些数据集分别包含播客记录和新闻文章。为了实现全面性、多样性和赋能（empowerment）的目标（在章节3.4中定义），这些目标能够促进对广泛议题和主题的理解，我们既探索了在不同层次的社区摘要中用于回答查询的影响，也将其与朴素的RAG和源文本的全局MapReduce摘要进行了比较。我们发现，所有全局方法在全面性和多样性方面都优于朴素的RAG，而具有中等和低级别社区摘要的Graph RAG在这些指标上表现优于源文本摘要，同时token成本更低。

2 Graph RAG 方法和流程

现在我们来细化Graph RAG方法(如图1)的高层数据流和流程，描述每个步骤的关键设计参数、技术和实现细节。

2.1 源文档->文本块(Source Documents->Text Chunks)

一个基本的设计决策是，从源文档中提取的输入文本应以何种粒度拆分为文本块进行处理。在接下来的步骤中，每个文本块将被传递到一组旨在提取图索引的各个元素的LLM提示。更长的文本块需要更少的LLM调用来进行提取，但会受到较长的LLM上下文窗口召回率下降的影响。这种行为在图2中单次提取回合（即没有gleanings）的情况下可以观察到：在一个样本数据集（HotPotQA）中，使用600个token的块大小提取的实体引用数量几乎是使用2400个token 的块大小的两倍。尽管通常情况下更多的引用更好，但任何提取过程都需要在召回率和精确度之间取得平衡，以适应目标活动。

图 2：HotPotQA数据集中检测到的实体引用如何随块大小和使用gpt-4-turbo的通用实体提取提示的收集而变化。

2.2 文本块->元素实例(Text Chunks->Element Instances)

此步骤的基本要求是从每个源文本块中识别和提取图节点和边的实例。我们使用一个多部分的LLM prompt，首先识别文本中所有实体，包括它们的名称、类型和描述，然后识别所有关系，包括源实体和目标实体以及它们关系的描述。两种类型的元素实例都输出在一个分隔符元组的列表中。

为此提示定制文档语料库领域的主要机会在于为LLM提供的用于上下文学习的少样本示例的选择。例如，虽然我们默认的提示提取“命名实体”的广泛类别，例如人员、地点和组织，通常适用，但具有专业知识的领域（例如，科学、医学、法律）将受益于针对这些领域专门的少样本示例。我们还支持一个次要提取提示，用于我们想要与提取的节点实例关联的任何其他协变量。我们默认的协变量提示旨在提取与检测到的实体相关的主张，包括主题、宾语、类型、描述、源文本跨度以及开始和结束日期。

为了平衡效率和质量的需求，我们使用多轮“gleanings”，最多达到指定的最大值，以鼓励LLM检测它可能在之前的提取轮次中错过的任何其他实体。这是一个多阶段过程，首先要求LLM评估是否提取了所有实体，使用100的logit偏差强制执行是/否决策。如果LLM回答说遗漏了实体，则继续指示“在上次提取中遗漏了MANY实体”会鼓励LLM收集这些遗漏的实体。这种方法允许我们使用更大的块大小，而不会降低质量或强制引入噪声。

2.3 元素实例->元素摘要（Element Instances->Element Summaries）

使用LLM来“提取”源文本中表示的实体、关系和主张的描述本身就是一种抽象摘要形式，它依赖于LLM来创建对可能隐含但未由文本本身陈述的概念（例如，隐含关系的存在）的独立有意义的摘要。要将所有这些实例级别的摘要转换为每个图元素（即实体节点、关系边和主张协变量）的单个描述性文本块，需要在匹配的实例组上进行LLM摘要的进一步轮次。

此阶段的潜在问题是LLM可能不会以相同的文本格式一致地提取对同一实体的引用，从而导致重复的实体元素，从而导致实体图中的重复节点。然而，由于所有紧密相关的实体“社区”将在后续步骤中被检测并总结，并且鉴于LLM可以理解多个名称变体背后的共同实体，因此我们的整体方法对这种变体具有弹性，前提是所有变体到一组共享的紧密相关实体的连通性足够。

总体而言，我们在潜在噪声图结构中对同构节点使用丰富的描述性文本，这与LLM的功能和全局、查询驱动的摘要的需求相一致。这些特性也使我们的图索引与典型的知识图谱有所区别，后者依赖于简洁一致的知识三元组（主体、谓词、宾语）来进行下游推理任务。

2.4 元素摘要->图社区（Element Summaries->Graph Communities）

上一步中创建的索引可以建模为同质无向加权图，其中实体节点由关系边连接，边权重表示检测到的关系实例的归一化计数。给定这样一个图，可以使用各种社区检测算法将图划分为节点社区，这些节点社区彼此之间的连接比图中其他节点更强。在我们的Pipeline中，我们使用Leiden，因为它能够有效地恢复大型图的层次社区结构(见图3)。此层次结构的每个级别都提供一个社区分区，以相互排斥（mutually-exclusive）、集体穷尽（collective-exhaustive）的方式覆盖图的节点，从而实现分而治之（divide-and-conquer）的全局摘要。

图3：使用Leiden算法在索引后的MultiHop-RAG数据集上检测到的图社区。圆圈代表实体节点，大小与节点度成正比。节点布局通过OpenORD和Force Atlas 2完成。节点颜色代表实体社区，以两种层次聚类级别显示：（a）级别0，对应于具有最大模块度的层次分区；（b）级别1，揭示了这些根级别社区内的内部结构。

2.5 图社区->社区摘要(Graph Communities->Community Summaries)

下一步是使用一种旨在扩展到超大型数据集的方法创建Leiden层次结构中每个社区的类似报告的摘要。这些摘要本身作为理解数据集的全局结构和语义的一种方式非常有用，并且它们本身可以用来在没有问题的情况下理解语料库。例如，用户可以扫描一个级别的社区摘要，寻找一般性的主题，然后跟踪到较低级别的报告的链接，这些报告提供了每个子主题的更多详细信息。但是，在这里，我们关注的是它们作为用于回答全局查询的基于图的索引的一部分的效用。

社区摘要以以下方式生成：

叶级社区(Leaf-level communities)：叶级社区的元素摘要（节点、边、协变量）被优先考虑，然后被迭代地添加到LLM上下文窗口中，直到达到符元限制。优先级如下：对于每个社区边，按源节点和目标节点度数的组合降序（即，整体突出性），添加源节点、目标节点、链接协变量和边本身的描述。
高级社区（Higher-level communities）：如果所有元素摘要都适合上下文窗口的符元限制，则与叶级社区一样进行，并汇总社区内的所有元素摘要。否则，按元素摘要符元的降序排列子社区，并迭代地用子社区摘要（较短）替换它们关联的元素摘要（较长），直到在上下文窗口内达到适合为止。

2.6 社区摘要->社区答案->全局答案(Community Summaries->Community Answers->Global Answer){#section2-6}

给定一个用户查询，之前步骤中生成的社区摘要可用于在多阶段过程中生成最终答案。社区结构的层次化性质也意味着可以使用不同层级的社区摘要来回答问题，这引发了这样的问题：层次化社区结构中的特定层级是否为一般意义上的问题提供了摘要细节和范围的最佳平衡（在第3章中进行评估）。

对于给定的社区级别，对任何用户查询的全局答案的生成方式如下：

准备社区摘要：社区摘要被随机洗牌并分成预先指定符元大小的块。这确保了相关信息分布在各个块中，而不是集中（并可能丢失）在一个上下文窗口中。
映射社区答案：并行生成中间答案，每个块一个。大语言模型也被要求生成一个0到100之间的分数，表明生成的答案在回答目标问题方面有多大帮助。分数为0的答案将被过滤掉。
简化为全局答案：中间社区答案按帮助分数降序排列，并迭代地添加到新的上下文窗口中，直到达到符元限制。最后，此上下文用于生成返回给用户的全局答案。

3 评估

3.1 数据集

我们选择了两个一百万符元范围内的数据集，每个数据集相当于大约10本文本小说，并代表了用户在现实世界活动中可能遇到的语料库类型：

播客文字记录：汇集了微软首席技术官Kevin Scott与其他技术领导人之间的播客对话的文字记录。大小：1669个×600符元文本块，块之间有100符元的重叠（∼100 万符元）。
新闻文章：基准数据集包含2013年9月至2023年12月期间发布的新闻文章，涵盖娱乐、商业、体育、科技、健康和科学等多个类别（MultiHop-RAG）。大小：3197个×600符元文本块，块之间有100符元的重叠（∼170万符元）。

3.2 查询

存在许多用于开放域问答的基准数据集，包括HotPotQA、MultiHop-RAG和MT-Bench。然而，相关的问答集针对的是显式事实检索，而不是为了数据理解目的的摘要，即人们在现实世界活动更广阔的范围内检查、参与和将数据置于上下文的过程。同样，从源文本中提取潜在摘要查询的方法也存在，但此类提取的问题可能针对的是暴露了对文本的先验知识的细节。

为了评估RAG系统在更全局的理解任务中的有效性，我们需要能够传达对数据集内容的仅限于高层理解的问题，而不是特定文本的细节。我们使用了一种以活动为中心的办法来自动生成此类问题：给定数据集的简短描述，我们要求LLM识别 $N$ 潜在用户和 $N$ 每个用户的任务，然后针对每个（用户、任务）组合，我们要求LLM生成 $N$ 需要理解整个语料库的问题。为了进行评估， $N=5$ 的值导致每个数据集有125个测试问题。表1显示了两个评估数据集中的每个数据集的示例问题。

表1：基于目标数据集的简短描述，LLM生成的潜在用户、任务和问题的示例。问题针对的是全局理解，而不是特定细节。

3.3 条件

在我们的分析中，我们比较了六种不同的条件，包括在Graph RAG中使用四种级别图社区 $(C0，C1，C2，C3)$ ，将我们的map-reduce方法直接应用于源文本的文本摘要方法 (Text Summarization,TS)，以及一种朴素的“语义搜索”RAG方法(Semantic Search,SS)：

C0：使用根级别社区摘要（数量最少）来回答用户查询。
C1：使用高层社区摘要来回答查询。如果存在，它们是C0的子社区，否则是C0社区的向下投影。
C2：使用中层社区摘要来回答查询。这些是C1的子社区，如果存在，否则是C1社区的向下投影。
C3：使用低级社区摘要（数量最多）来回答查询。这些是C2的子社区，如果存在，否则是C2社区向下投影。
TS：与2.6节中的方法相同，只是源文本（而不是社区摘要）被洗牌并分块以用于 Map-Reduce 摘要阶段。
SS：朴素RAG的一种实现，其中检索文本块并添加到可用的上下文窗口中，直到达到指定的令牌限制。

上下文窗口的大小和用于答案生成的提示在所有六种情况下都是相同的（除了对引用样式进行一些细微调整以匹配所使用上下文信息的类型）。条件仅在上下文窗口的内容创建方式上有所不同。

支持条件C0-C3的图索引是使用我们针对实体和关系提取的通用提示创建的，实体类型和少样本示例针对数据的领域定制。图索引过程使用了600个令牌的上下文窗口大小，针对Podcast数据集进行1次gleaning，针对News数据集进行0次gleaning。

3.4 指标

大语言模型（LLM）已被证明是自然语言生成良好的评估器，与人工判断相比，LLM在该领域取得了最先进的或具有竞争力的结果。然这种方法可以在已知金标准答案的情况下生成基于参考的指标，但它也能够以无参考的方式测量生成的文本的质量（例如，流畅度）以及在竞争性输出的正面比较中（LLM作为评判者）。LLM还展现出评估传统RAG系统性能的潜力，自动评估上下文相关性、忠实度和答案相关性等质量。

鉴于我们Graph RAG机制的多阶段性质，我们想要比较的多个条件以及对我们的基于活动的理解问题缺乏金标准答案，我们决定采用使用LLM评估器的正面比较方法。我们选择了三个目标指标，这些指标捕捉了理解活动所需的质量，以及一个用作有效性指标的控制指标（直接性 Directness）。由于直接性实际上与全面性和多样性相反，我们不希望任何方法在所有四个指标上都获胜。

我们使用LLM评估器计算的正面比较指标如下：

全面性（Comprehensiveness）：答案提供多少细节来涵盖问题的各个方面和细节？
多样性（Diversity）：答案在提供问题的不同视角和见解方面有多么多样化和丰富？
赋能（Empowerment）：答案在帮助读者理解和对主题做出明智判断方面表现如何？
直接性（Directness）：答案在多大程度上专门且清晰地解决了问题？

在我们的评估中，LLM被提供了一个问题、目标指标和一对答案，并被要求根据指标评估哪个答案更好，以及为什么。如果存在赢家，它将返回赢家，否则如果它们在根本上相似，并且差异微不足道，则返回平局。为了考虑LLM的随机性，我们对每次比较运行五次，并使用平均分数。表格2显示了LLM生成的评估示例。

表2 新闻文章数据集的示例问题，包括来自Graph RAG(C2)和Naïve RAG的生成的答案，以及LLM生成的评估。

3.5 配置

上下文窗口大小对任何特定任务的影响尚不清楚，特别是对于像gpt-4-turbo这样的模型，其上下文大小为128k个符元。鉴于信息可能在较长上下文中“丢失”的可能性，我们希望探索改变上下文窗口大小对数据集、问题和指标组合的影响。特别是，我们的目标是确定基线条件(SS)的最佳上下文大小，然后将其统一用于所有查询时的LLM使用。为此，我们测试了四个上下文窗口大小：8k、16k、32k和64k。令人惊讶的是，测试的最小上下文窗口大小(8k)在所有关于全面性(平均获胜率为 58.1%)的比较中普遍表现更好，同时在多样性(平均获胜率=52.4%)和赋能(平均获胜率=51.3%)上的表现与更大的上下文大小相当。鉴于我们更倾向于更全面和多样化的答案，因此我们在最终评估中使用了8k个符元的固定上下文窗口大小。

3.6 结果

索引过程生成了一个包含8564个节点和20691条边的图，用于Podcast数据集，以及一个更大的图，包含15754个节点和19520条边，用于News数据集。表格3显示了每个图社区层次结构不同级别上的社区摘要数量。

表3 上下文单元数量（C0-C3的社区摘要和TS的文本片段），相应的符元计数，以及最大符元计数的百分比。源文本的映射缩减摘要是资源最密集的方法，需要最多数量的上下文标记。根级社区摘要(C0)每次查询所需的标记要少得多(9x-43x)。

全局方法vs朴素 RAG：如图4所示，全局方法在所有数据集的全面性和多样性指标方面始终优于朴素RAG(SS)方法。具体来说，全局方法在Podcast transcripts中实现了72-83% 的全面性获胜率，在News articles中实现了72-80% 的全面性获胜率，而多样性获胜率分别在75-82%和62-71%。我们使用直接性作为有效性测试也获得了预期结果，即朴素RAG在所有比较中产生最直接的响应。

图 4：在两个数据集、四个指标和125个问题比较（每个问题重复五次并取平均值）中，（行条件）相对于（列条件）的正面胜率百分比。每个数据集和指标的总体获胜者以粗体显示。自我胜率未计算，但显示为预期的50%以作参考。所有Graph RAG条件在全面性和多样性方面都优于朴素RAG。条件C1-C3在答案全面性和多样性方面也略微优于TS（没有图索引的全局文本摘要）。

社区摘要vs源文本：使用Graph RAG将社区摘要与源文本进行比较时，社区摘要通常在答案的全面性和多样性方面提供了微小但一致的改进，除了根级别摘要。播客数据集中的中级摘要和新闻数据集中的低级社区摘要分别实现了57%和64%的全面性获胜率。多样性获胜率对于播客中级摘要为57%，对于新闻低级社区摘要为60%。表3还说明了Graph RAG与源文本摘要相比的可扩展性优势：对于低级社区摘要(C3)，Graph RAG所需的上下文标记减少了26-33% ，而对于根级社区摘要(C0)，所需的Token减少了97%以上。对于与其他全局方法相比性能略有下降，根级别的Graph RAG为迭代式问答提供了高效的方法，该方法代表着意义建构活动，同时在全面性(72%的获胜率)和多样性(62%的获胜率)方面保留了优于朴素RAG的优势。

赋能：赋能比较显示了全局方法与朴素RAG(SS)以及Graph RAG方法与源文本摘要(TS)的混合结果。对该指标的LLM推理进行分析的临时LLM使用表明，提供具体示例、引文和引用的能力被认为是帮助用户获得明智理解的关键。微调元素提取提示可能有助于在Graph RAG索引中保留更多这些细节。

4 相关工作

4.1 RAG方法和系统

当使用LLM时，RAG首先从外部数据源检索相关信息，然后将这些信息添加到LLM的上下文窗口中，以及原始查询。朴素RAG方法通过将文档转换为文本，将文本分割成块，并将这些块嵌入到一个向量空间中来实现这一点，在该空间中，相似的位置表示相似的语义。然后将查询嵌入到相同的向量空间中，使用最近 $k$ 个向量的文本块作为上下文。存在更高级的变体，但它们都解决了当感兴趣的外部数据集超过LLM的上下文窗口时该怎么办的问题。

先进的RAG系统(Advanced RAG)包括预检索(pre-retrieval)、检索(retrieval)、后检索策略(post-retrieval)，旨在克服朴素RAG的缺点，而模块化RAG系统包括用于交织检索和生成迭代和动态循环的模式。我们对Graph RAG的实现结合了与其他系统相关的多个概念。例如，我们的社区摘要是一种针对生成增强检索的自我记忆，它有助于未来的生成循环，而我们从这些摘要中并行生成社区答案是一种迭代或联合检索生成策略。其他系统还将这些概念结合起来用于多文档摘要(CAiRE-COVID)和多跳问答(ITRG；IR-CoT；DSP)。我们使用分层索引和摘要也与其他方法相似，例如通过对文本嵌入向量进行聚类来生成文本块的分层索引(RAPTOR)，或者生成“澄清树”来回答对模棱两可问题的多种解释。但是，这些迭代或分层方法都没有使用能够启用Graph RAG的自生成图形索引。

4.2 图形和LLMs

图形在LLM和RAG中的应用是一个正在发展的研究领域，已经建立了多个方向。这些方向包括使用LLM进行知识图谱创建和完善，以及从源文本中提取因果关系图。它们还包括高级RAG的形式，其中索引是知识图谱(KAPING)，其中图形结构的子集(G-Retriever)或派生的图形指标(Graph-ToolFormer)是查询对象，其中叙述输出牢固地基于检索到的子图的事实(SURGE)，其中检索到的事件图子图使用叙述模板序列化(FABULA)，以及系统支持创建和遍历文本关系图以进行多跳问答。在开源软件方面，LangChain和LlamaIndex库都支持各种图数据库，同时，更通用的基于图的RAG应用程序类别也正在兴起，包括可以在Neo4J和NebulaGraph格式中创建和推理知识图的系统。然而，与我们的Graph RAG方法不同，这些系统都没有利用图的自然模块化来对数据进行分区以进行全局摘要。

5 讨论

评估方法的局限性：到目前为止，我们的评估只考察了大约100万个符元，针对两个语料库的某种类型的理解问题。需要做更多的工作来了解性能如何在不同范围的问题类型、数据类型和数据集大小之间变化，以及如何使用最终用户验证我们的理解问题和目标指标。例如，使用SelfCheckGPT等方法比较捏造率（fabrication rates），也能改善目前的分析。

构建图索引的权衡：我们一直观察到Graph RAG在与其他方法的正面比较中取得了最佳结果，但在许多情况下，对源文本进行全局摘要的无图方法表现出竞争力。是否投资构建图索引的现实世界决策取决于多种因素，包括计算预算、每个数据集的预期终身查询次数，以及从图索引的其他方面获得的价值（包括通用社区摘要以及其他与图相关的RAG方法的使用）。

未来工作：支持当前Graph RAG方法的图索引、丰富的文本标注和分层社区结构为改进和调整提供了许多可能性。这包括通过基于嵌入的匹配用户查询和图标注，以更本地方式运行的RAG方法，以及结合基于嵌入的匹配社区报告，然后使用我们的map-reduce摘要机制的混合RAG方案的可能性。这种“汇总”操作也可以扩展到社区层次结构的更多级别，以及作为一种更具探索性的“向下钻取（roll-up）”机制来实现，该机制遵循更高级别社区摘要中包含的信息线索。

结论

我们提出了一种针对Graph RAG的全局方法，将知识图生成、检索增强生成(RAG)和查询聚焦摘要(QFS)相结合，以支持人类对整个文本语料库的理解。初步评估表明，在答案的全面性和多样性方面，与朴素的RAG基线相比，该方法取得了显著改进，并且与使用Map-Reduce源文本摘要的全局但无图方法相比，该方法也具有优势。对于需要对同一数据集进行大量全局查询的情况，基于实体的图索引中根级社区的摘要提供了比朴素RAG更好的数据索引，并且在令牌成本的一小部分内，其性能可与其他全局方法相媲美。

全局和局部图RAG方法的开源、基于Python的实现即将在https://aka.ms/graphrag上发布。