English 简体中文 繁體中文 한국 사람 日本語 Deutsch русский بالعربية TÜRKÇE português คนไทย french
查看: 1|回复: 0

RAG(二)深度解析GraphRAG:如何基于知识图谱提升RAG性能

[复制链接]
查看: 1|回复: 0

RAG(二)深度解析GraphRAG:如何基于知识图谱提升RAG性能

[复制链接]
查看: 1|回复: 0

252

主题

0

回帖

766

积分

高级会员

积分
766
AfIos456rz

252

主题

0

回帖

766

积分

高级会员

积分
766
4 天前 | 显示全部楼层 |阅读模式

前面了解了RAG的开山之作,今天来看下微软提出的GraphRAG是如何提升RAG性能的。
首先了解下研究动机:
传统的RAG方法在处理局部信息检索方面表现出色,但对于涉及整个文本语料库的全局性问题,如“数据集中有哪些主要主题?”这样的问题,它们的表现不佳。
更合适的任务框架应当是查询聚焦型摘要(Query-Focused Summarization,QFS),特别是抽象式摘要,它可以生成自然语言的总结而不仅仅是摘录片段。随着LLM的发展,GPT、Llama 和 Gemini 系列等模型可以通过上下文学习来总结任何在其上下文窗口内提供的内容,但是,对于需要对整个语料库进行查询聚焦型抽象摘要的情况,尤其是当文本量远超出了LLM上下文窗口的限制时,仍然存在挑战。
研究人员希望结合两种方法的优点,即RAG的精确性和QFS的大规模文本处理能力,以更有效地回答全局性质的问题。
因此,来自微软的研究团队提出GraphRAG,利用LLM构建了一个基于图的文本索引。此索引不仅包括节点(例如实体),还包括边(例如关系)和协变量(例如声明)。通过这种方法,Graph RAG能够更好地捕捉文本之间的关联,并支持对大规模文本集合的全局理解和摘要。
项目地址:https://aka.ms/graphrag
下面详细介绍下方法实现:
1、方法介绍


图1为GraphRAG的pipeline和实现细节,主要分为以下几个部分:
源文档(Source Documents) → 文本块(Text Chunks)
拿到一个文档,无论是构建一个图谱还是传统的RAG方法,第一步都是从原始文档中提取文本,并将其分割成适合后续处理的文本块。
这里就涉及到文本块的分割粒度问题:较长文本块,减少对LLM的调用次数,但可能由于LLM上下文窗口长度的限制而导致召回率下降。较短文本块,虽然增加了调用次数,但有助于保持较高的召回率,因为每个块的信息量较小,更容易完整地捕捉到其中的关键信息。
如图2,在 HotPotQA 数据集上,单轮提取的情况下,使用600 token大小的文本块几乎可以提取两倍于2400 token大小文本块的实体引用数量。这是因为较长的文本块可能会导致某些重要信息“丢失在中间”,特别是在LLM上下文窗口长度固定的情况下。

这里作者没有给出实际的分块方法,实际上,根据具体应用场景的需求来选择合适的文本块大小。通常来说,较小的文本块更适合保证高召回率,而较大的文本块则可能更经济高效,尤其是在处理非常大的文档集合时。为了确保连续文本块之间不会遗漏重要的上下文信息,可以在相邻文本块之间设置一定的重叠。例如,在论文中提到的数据集处理中,文本块大小为600 tokens,且相邻块之间有100 tokens的重叠。
文本块 → 元素实例(Element Instances)
在划分好文本块之后,一个基本要求是从每个文本块中识别并抽取图节点和边的实例。
具体来说,通过一个多部分的LLM提示来完成,首先识别所有实体(包括名称、类型和描述),然后识别清楚相关的实体之间的关系(包括源实体、目标实体及其关系描述)。最后,所有类型的元素实例(实体和关系)都被组织成一个统一的、由分隔符分隔的元组列表输出。
为了使提示适应特定领域的文档语料库,可以为LLM提供用于上下文学习的少量示例。例如,默认提示可能适用于广泛类别的“命名实体”(如人名、地名、组织名),但对于具有专业知识的领域(如科学、医学、法律等),则可以通过提供专门化的示例来优化提取效果。另外,还支持对与提取的节点实例关联的任何附加协变量进行二次提取。默认协变量提示旨在提取与检测到的实体相关联的声明,包括主题、对象、类型、描述、源文本跨度以及开始和结束日期。
为了平衡效率和质量,使用多个“gleaning”轮次来鼓励LLM捕捉任何之前可能遗漏的实体。这是一个多阶段的过程:

  • 评估完整性:首先询问LLM是否所有实体都已被提取,使用logit偏置强制模型做出二选一的回答(是/否)。
  • 继续挖掘:如果LLM回答有实体被遗漏,则通过提示告知“上次提取中遗漏了许多实体”,促使LLM补充这些遗漏的实体。
  • 实验验证:这种方法允许使用较大的文本块而不降低质量或引入噪音,如图2所示,在HotPotQA数据集上,600 token大小的文本块几乎能提取两倍于2400 token大小文本块的实体引用数量,但通过增加遍历次数(gleanings),可以显著提升较大文本块上的实体检测数量和质量。
元素实例 → 元素摘要(Element Summaries)
使用LLM“提取”源文本中的实体、关系和声明描述实际上已经是一种抽象摘要生成的形式。这意味着LLM不仅仅是在简单地识别这些元素,而是在创造独立有意义的概念摘要。这些概念可能是隐含的,而不是由文本本身明确陈述的(例如,隐含关系的存在)。
为了将所有此类实例级摘要转换为每个图元素(即实体节点、关系边和声明协变量)的单个描述性文本块,需要对匹配的实例组进行进一步的LLM摘要生成。这个过程确保了每个图元素都有一个单一、连贯且描述性的文本块,从而提高了信息的清晰度和组织性。
这里存在的一个潜在的问题是,LLM可能不会始终以相同的文本格式提取对同一实体的引用,这可能导致重复的实体元素,进而产生图中的重复节点。
但是对于LLM来说,这又是很容易解决的一个问题:由于紧密相关的“社区”将在接下来的步骤中被检测并总结,而且LLM能够理解多个名称变化背后共同的实体,因此整个方法对于这些变化具有鲁棒性。只要所有变化都通过足够的连接指向一组紧密相关的实体,整体方法就可以保持一致性和准确性。换句话说,即使存在不同的命名方式或拼写变化,LLM依然能够识别它们代表的是同一个实体,从而避免了不必要的重复。
总体而言,在潜在噪声图结构中对同质节点使用丰富的描述性文本,这与LLM的能力和全局查询聚焦摘要生成的需求相一致。通过这种方式,不仅捕捉到了文档中的显式信息,也涵盖了那些隐含但重要的概念。这些特性也将图索引与典型的知识图区分开。传统的知识图依赖于简洁且一致的知识三元组(主体、谓词、客体)进行下游推理任务,而图索引则更注重描述性和灵活性,旨在支持更广泛的认知活动和复杂的查询任务。
最终输出的是经过LLM总结后的描述性文本块,这些文本块代表了图中的各个元素(实体、关系和声明)。每个元素现在都有一个简明而全面的描述,这不仅有助于理解该元素本身,还便于在后续步骤中对其进行处理和分析。
元素摘要 → 图社区(Graph Communities)
基于提取出的实体、关系和声明,创建一个图结构,其中实体作为节点,关系作为边,边权重代表关系实例的归一化计数。给定这样的图,使用社区检测算法将图划分为多个节点社区,每个社区由一组紧密相连的节点组成,这些节点之间的连接比与其他节点的连接更为紧密。
GraphRAG中的社区算法采用Leiden算法,因为它能够高效地恢复大规模图的层次社区结构。此层次结构的每个级别都提供了一个社区划分,以互斥且集体穷尽的方式覆盖图的节点,从而实现分治的全局摘要生成。
最终输出的是一个经过社区检测算法处理后的图结构,其中原始节点被划分为若干个社区。每个社区包含了一组紧密相关的节点,这些节点之间的连接强度高于与外部节点的连接。这样的社区划分不仅有助于理解数据的整体结构,也为后续的查询聚焦型摘要生成提供了基础。

图社区 → 社区摘要(Community Summaries)
接下来就是为每个社区生成独立有用的、类似报告的摘要,以帮助用户理解数据集的全局结构和语义。这些社区摘要可以用于后续的查询聚焦型摘要生成,特别是在处理需要对整个语料库进行综合理解的复杂查询。
对于大型数据集,单个社区可能包含大量信息,如何有效地将这些信息浓缩成有意义的摘要是一个挑战。GraphRAG分为叶级社区和高级社区生成:

  • 叶级社区摘要生成:叶级社区(即最底层社区)的元素摘要(节点、边、协变量)被优先考虑,即对于叶级社区,首先按源节点和目标节点的度(边的权重)的降序排列,然后,依次将源节点、目标节点、相关协变量以及边本身的信息添加到LLM的上下文窗口中,直到达到token限制。这确保了最重要和最具代表性的信息被优先考虑。
  • 更高级别社区摘要生成:如果所有元素摘要都能适应上下文窗口的token限制,则直接生成该社区的摘要。如果无法全部适应,则按元素摘要tokens数量递减的顺序对子社区进行排名,并迭代的用较短的子社区摘要替换其关联的较长元素摘要,直到适应上下文窗口。这种方法允许在保持信息完整性的同时,减少token使用量。
社区摘要 → 社区答案 (Community Answer)→ 全局答案(Global Answer)
给定用户查询,上一步生成的社区摘要可用于生成最终答案,这是一个多阶段过程。社区结构的层次性质也意味着可以使用不同级别的社区摘要来回答问题。
这里存在一个问题:层次社区结构中的特定级别是否提供了摘要细节和范围的最佳平衡,以应对一般理解问题。
对于给定的社区级别,任何用户查询的全局答案生成如下:

  • 准备社区摘要:为了确保相关信息均匀分布,而不是集中在单个上下文窗口中,首先将社区摘要随机打乱,并分成预定义token大小的块。这样可以避免某些重要信息因超出上下文窗口限制而被忽略,保证了信息的完整性和多样性。
  • 映射社区答案:对于每个分块,使用LLM并行生成中间答案。这意味着每个文本块都会产生一个独立的初步回答。LM还被要求为每个生成的答案提供一个0-100的评分,指示该答案对于回答目标问题的帮助程度。这有助于后续筛选最有用的信息。
  • 归约为全局答案:中间社区答案按帮助性分数的降序排序,并迭代地添加到新的上下文窗口中,直到达到 token 限制。此最终上下文用于生成返回给用户的全局答案。
2、实验设置

数据集

为了评估Graph RAG的有效性,作者选择了两个具有代表性的数据集,每个数据集大约包含一百万token,相当于约10本小说的文字量。这些数据集反映了用户在现实世界活动中可能遇到的文档集合类型。

  • 播客转录文本(Podcast Transcripts):由微软CTO Kevin Scott主持的技术播客《Behind the Tech》的编译转录文本。包含1669个600-token文本块,块间有100-token重叠(约100万tokens)。
  • 新闻文章(News Articles):从2013年9月到2023年12月期间发布的涵盖娱乐、商业、体育、技术、健康和科学等多个类别的新闻文章。包含3197个600-token文本块,块间有100-token重叠(约170万tokens)。
测试问题生成

为了生成适用于全局认知任务的问题,作者采用了一种以活动为中心的方法自动化生成问题。这种方法确保了问题只传达对数据集内容的高层次理解,而不是具体细节,从而更适合评估RAG系统在更广泛的认知任务中的表现。

  • 活动中心法:给定一个数据集的简短描述,要求LLM识别N个潜在用户和每个用户的N个任务,然后为每个(用户,任务)组合生成N个需要理解整个语料库的问题。
  • 示例问题:例如,对于播客转录文本,问题可能涉及“哪些剧集主要讨论科技政策和政府监管?”;对于新闻文章,则可能是“当前哪些健康话题可以整合到健康教育课程中?”。

  • 数量:对于每个数据集,N=5,共生成125个测试问题。
为了全面评估Graph RAG的性能,作者比较了六种不同的条件,包括使用不同层级社区摘要的Graph RAG方法、直接对源文本进行映射-归约摘要的方法(TS),以及朴素的语义搜索RAG方法(SS)。具体描述如下:

  • C0:使用根级社区摘要(数量最少)来回答用户查询。
  • C1:使用高级社区摘要来回答查询。这些是C0的子社区(如果存在),否则是C0社区的向下投影。
  • C2:使用中级社区摘要来回答查询。这些是C1的子社区(如果存在),否则是C1社区的向下投影。
  • C3:使用低级社区摘要(数量最多)来回答查询。这些是C2的子社区(如果存在),否则是C2社区的向下投影。
  • TS:直接对源文本进行映射-归约摘要的方法,类似于Graph RAG的最后步骤,但直接作用于原始文本而非社区摘要。
  • SS:一种朴素的RAG实现,通过检索文本块并将其添加到上下文窗口中直到达到指定的token限制。
评价指标(Metrics)

为了评估不同条件下生成的答案质量,作者选择了一个基于LLM的头对头比较方法,定义了四个目标度量标准,旨在捕捉对认知活动有益的质量特征:

  • 全面性(Comprehensiveness):答案提供的细节覆盖了多少方面和细节?
  • 多样性(Diversity):答案在提供不同视角和见解上有多丰富?
  • 赋能性(Empowerment):答案在帮助读者理解和做出明智判断上有何效果?
  • 直接性(Directness):答案如何具体且明确地解决提问?
表2显示了LLM生成的评估示例:

3、实验结果

索引过程生成了一个由8564个节点和20691条边组成的播客数据集图,以及一个由15754个节点和19520条边组成的更大的新闻数据集图。表3显示了不同级别的图社区层次结构中社区摘要的数量。
Graph RAG vs Naïve RAG



  • 全面性(Comprehensiveness):
    Graph RAG vs Naïve RAG:所有全局方法(C0, C1, C2, C3, TS)在全面性方面均优于朴素RAG(SS)。这是因为全局方法能够更好地捕捉和整合来自多个社区摘要的信息,提供更广泛的内容覆盖。
    层级选择的影响:使用中间层和低层社区摘要的Graph RAG(C2, C3)表现尤为突出,在全面性上超过了直接总结源文本的方法(TS),并且在相同指标下具有更低的token成本。
  • 多样性(Diversity):
    Graph RAG的优势:Graph RAG方法在多样性方面同样表现出色,特别是当使用较低层次的社区摘要(C2, C3)。这些方法能够提供更加丰富多样的视角和见解,涵盖了更多的子话题和细节。
    原因分析:由于较低层次的社区摘要包含更详细的子社区信息,因此它们可以提供更广泛且深入的回答,避免了高层次摘要可能遗漏的具体内容。
  • 赋能性(Empowerment):
    全局方法与朴素RAG(SS)以及Graph RAG方法与源文本摘要生成(TS)的结果参差不齐。临时使用LLM分析LLM推理表明,提供具体示例、引用和引文的能力被认为是帮助用户达成明智理解的关键。调整元素提取提示可能有助于在Graph RAG索引中保留更多这些细节。
  • 直接性(Directness):
    平衡考量:虽然直接性是衡量答案是否具体且明确地解决提问的一个重要标准,但它通常与全面性和多样性呈反比关系。因此,作者并未期望任何一种方法能在所有四个度量标准上都占据优势。
    Graph RAG的表现:尽管如此,Graph RAG在保持高全面性和多样性的前提下,依然能够在直接性方面提供清晰且有针对性的回答。
社区摘要 vs. 源文本

社区摘要通常在答案的全面性和多样性方面提供了小幅但一致的改进,除了根级摘要。
表3还说明了Graph RAG与源文本摘要生成相比的可扩展性优势:对于低级社区摘要(C3),Graph RAG需要少26-33%的上下文token,而对于根级社区摘要(C0),它需要少97%以上的token。与其他全局方法相比,性能略有下降,根级Graph RAG提供了一种高度高效的方法,用于迭代式问答,这是理解活动的特征,同时在全面性(72%胜率)和多样性(62%胜率)方面保留了优于朴素RAG的优势。

4、总结

在大模型时代,都不看好知识图谱的发展,其实将知识图谱和LLM结合,能够更好的将开放域知识引入LLM,GraphRAG就是一个LLM和图谱结合非常好的例子。
GraphRAG对于需要全文理解,摘要生成等任务,是一个非常好的解决方案,但是这里存在一个巨大的隐患,图谱构建的过程,可能需要大量的资源和时间。
对于GraphRAG和RAG的使用,更多的还是根据任务需求来决定。
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

252

主题

0

回帖

766

积分

高级会员

积分
766

QQ|智能设备 | 粤ICP备2024353841号-1

GMT+8, 2025-3-10 19:22 , Processed in 1.593657 second(s), 29 queries .

Powered by 智能设备

©2025

|网站地图