编辑:LRST
【新智元导读】LightRAG通过双层检索范式和基于图的索引策略提高了信息检索的全面性和效率,同时具备对新数据快速适应的能力。在多个数据集上的实验表明,LightRAG在检索准确性和响应多样性方面均优于现有的基线模型,并且在资源消耗和动态环境适应性方面表现更优,使其在实际应用中更为有效和经济。
随着大语言模型(LLM)自身能力的日趋完善,很多学者的目光聚焦于如何帮助大模型处理和感知大规模的私有数据库。RAG(Retrieval-Augmented Generation)系统采用检索方法,从私有数据库中高效、准确地召回与查询高度相关的信息内容,用以增强通用大模型处理查询的语境知识和生成效果。
现有RAG方法基于信息索引和检索算法,在整合外部知识源方面已经取得了一定的成效,然而这些方法普遍存在以下问题亟待解决:
1. 当前方法大多采用扁平的向量化表示方法,这限制了模型对外部数据的理解和检索的准确性,影响了检索的效果。
2. 现有工作缺乏对实体间相互联系的充分探索,导致面对复杂的高级问题时无法有效结合多个方面的信息进行联系和总结。
为了应对这些问题,北京邮电大学、香港大学的研究人员提出了一种使用图结构数据进行增强的RAG系统——LightRAG,利用图结构对复杂关系的准确描绘,LightRAG能够有效地解决上述问题。
论文地址:https://arxiv.org/abs/2410.05779
项目地址:https://github.com/HKUDS/LightRAG
为了实现系统的性能和效率,LightRAG的设计聚焦于解决以下挑战:
1. 信息检索的全面性:RAG系统应当能够全面考虑查询和外部知识在不同层级的语义,既能够感知具体的实体,也能够理解抽象概念。
2. 信息检索的效率:在保证检索准确性的情况下,能够进行高效的信息检索,是RAG系统面对海量查询请求时的关键能力。
3. 对新数据的快速适应能力:在实际使用过程中,外部数据库常常发生持续不断的演化,如何让RAG系统保持灵活的更新能力,是一个重要问题。
为了解决上述挑战,LightRAG系统具有以下关键设计。
基于图数据结构的文本索引LightRAG首先对外部数据库进行预处理,以利于处理查询时的高效性和准确性,这一过程被称为文本索引。为了充分理解数据库中实体间的相互联系,这一过程采用了图的数据结构进行增强。
总体来说,这一过程包含以下几个重要阶段:
1. 实体和关系抽取:为了获取索引图中的基本元素,LightRAG首先使用大语言模型处理原始文本数据,识别出其中具有固定语义的实体、以及它们之间的关系。例如在一篇医学文章中识别出「心脏病」以及「心内科医生」这两种实体,并指出两者之间的治疗关系。
通过这一过程,首先可以很好地提取出数据中关键的细粒度语义元素,方便之后的信息检索;其次,这种关系结构可以很好地将原始数据中的信息联系起来,加强RAG系统对实体间联系的理解和感知,提升检索的全面性。
2. 用于检索的键值对生成:通过上述步骤获得了图数据的骨架后,LightRAG继续使用大语言模型方法,生成每个实体和关系的检索键和检索值。其中检索键是较短的文本,用于与查询文本的语义进行匹配。
节点的检索键通常是他的文本名称本身,而关系的检索键则通过提示大语言模型的方法生成,反应了该关系对关联的抽象语义。检索值则为相对大段的文本描述,是检索后用于增强通用大模型回答查询的细节信息。通过这种方法,LightRAG的检索既能够感知丰富具体的语义信息以提升准确性,又可以通过键值进行快速索引和数据获取。
3. 实体和关系去重:对较长的外部文本数据,上述过程会重复提取一些相同或者高度相似的实体和关系。为了进一步提升RAG系统的效率,接下来通过提示大语言模型来进行实体和关系的去重,得到最终的图结构索引。
4. 增量更新:为了应对外部数据库体量的不断扩大,LightRAG基于上述过程设计了增量方法。通过采用同样的实体和关系抽取、键值对生成、图结构元素的去重和合并过程,LightRAG可以避免对全部数据进行重新处理,而只进行增量式的信息索引和合并,大大提升了RAG系统的适应能力。
LightRAG的双层检索范式为了提升模型的全面性,LightRAG充分考虑到了具体查询和抽象查询这两类查询请求的不同。前者通常明确关联于实际的实体,需要检索回相关的实体并结合问题进行总结。而后者主要设计抽象的概念,需要准确识别出具象实体和抽象概念之间的联系,才能得到需要的信息进行回答。
对应这两类查询请求,LightRAG采用了一种双层检索范式:在底层检索中,LightRAG基于实体包含具象语义的键值进行检索和召回;而在高层检索中,LightRAG首先识别出查询请求所涉及的抽象概念,以将其与关系中的抽象检索键进行匹配。
这种双层检索范式的优势在于,它通过结合特定查询和抽象查询的处理方式以及低级别检索和高级别检索策略,并整合图和向量进行检索,从而能够有效适应多样化的查询类型。这使得它不仅可以精确检索到与特定实体相关的详细信息,还能获取更广泛主题的相关知识,进而确保系统能够为用户提供全面且相关的回答,满足不同用户的需求。
在检索过程中,LightRAG将图数据检索与向量数据库检索进行结合,既考虑到了召回实体和关系的邻域信息,也考虑到了如何在实现中进行快速匹配。
实验实验设置评估数据集
为了全面评估模型的性能,我们精心选择了来自UltraDomain的四个具有不同特征的数据集。首先,Agriculture数据集专注于农业实践领域,包含了12篇文档,总token数达到2,017,886个。其内容广泛涵盖了农业相关的各种主题,为模型在农业领域的理解和处理能力提供了测试平台。
接下来是CS(计算机科学)数据集,由10篇文档组成,总计2,306,535个token。该数据集涉及计算机科学的多个方面,包括算法、人工智能、软件工程等,旨在评估模型在计算机科学领域的表现。
第三个数据集是规模最大的Legal数据集,包含了94篇文档,累计5,081,069个token。它聚焦于公司法律实践,涵盖了各种法律文件、案例分析和法规解读,测试模型在法律文本处理和法律知识理解方面的能力。
最后,Mix数据集包含了61篇文档,共计619,009个token。该数据集汇集了多个学科的文本,包括人文、社会科学和自然科学等,旨在评估模型在处理跨领域、多主题内容时的综合性能。
通过选择这些多样化的数据集,我们得以在不同领域和规模下全面评估模型的表现,为实验结果的可靠性和普遍性提供了保障。
问题生成
为了测试模型在各种复杂问题上的处理能力,我们针对每个数据集生成了一系列需要深入理解的问题。具体方法是,将每个数据集的所有文本内容视为背景上下文,然后利用大型语言模型(LLM)生成问题。
首先,我们让LLM为每个数据集创建五个虚拟的RAG用户,每个用户代表不同的信息需求或兴趣领域。接着,针对每个用户,设计了五个独特的任务,模拟他们可能提出的查询类型。
对于每个用户-任务组合,LLM进一步生成了五个需要全面理解整个语料库才能回答的问题。通过这种方式,每个数据集最终产生了125个多样化的问题(5个用户 × 5个任务 × 5个问题),从而全面评估模型在处理各种查询时的能力。
实现和评估细节
在实验实施过程中,我们采用了nano向量数据库来管理向量化的数据,以提高检索的效率和速度。在LightRAG模型中,所有基于LLM的操作默认使用了GPT-4o-mini模型,以保持实验的一致性和可比性。
在预处理阶段,统一将所有数据集的文本块大小设置为1200个token,旨在平衡模型的计算效率和上下文捕获能力。一些关键参数被固定,以减少变量对实验结果的影响。
为了评估模型的性能,我们采用了基于LLM的多维度比较方法。具体定义了全面性、多样性、赋能性和总体表现四个评估维度。这些维度从不同角度衡量模型的回答质量,确保评估的全面性。
由于检索增强生成(RAG)模型的查询通常没有标准答案,直接评估回答的准确性存在挑战。
为此,我们利用GPT-4o-mini对基线模型和LightRAG的回答进行排名评估。通过交替排列答案、盲审等方式,确保评估过程的公平性和客观性。最终,我们计算了各模型在不同维度上的胜率,以量化它们的性能差异。
回答质量比较我们将LightRAG与多种基线模型在四个选定的数据集(Agriculture、CS、Legal、Mix)上进行了比较,评估它们在不同维度下的性能表现。
以Agriculture数据集为例,在全面性维度上,Naive RAG模型的胜率为32.69%,而LightRAG的胜率达到了67.31%,显著优于基线模型。同样地,在多样性维度上,Naive RAG的胜率为24.09%,而LightRAG高达75.91%。这种优势在CS、Legal和Mix数据集上也得到了体现,LightRAG在多数评估维度上的胜率都明显超过了基线模型。
通过深入分析实验结果,我们得出了以下结论:
首先,基于图的RAG系统在处理大规模语料和复杂查询时表现出更好的性能。
LightRAG和GraphRAG等模型利用图结构捕获了语料库中的复杂语义依赖关系,随着数据集规模的增加,这种优势更加明显。
例如,在规模最大的Legal数据集上,基线方法的胜率仅约为20%,而LightRAG显著领先。这表明,图增强的RAG系统能够更全面地理解和整合知识,提高模型的泛化能力。
其次,LightRAG在多样性维度上展现了卓越的优势。
与各种基线模型相比,LightRAG在提供丰富、多样化的回答方面表现突出,尤其是在Legal数据集等大型数据集上。
这主要归功于LightRAG的双层检索策略,它能够从低级别(具体细节)和高级别(宏观主题)两个层次全面检索信息,充分利用基于图的文本索引,捕获查询的完整上下文,从而生成更为丰富的回答。
消融实验为了深入了解模型各组件对整体性能的影响,我们对LightRAG进行了消融实验,重点考察了双层检索机制和语义图在模型中的作用。实验结果如下,我们从中观察到了以下现象:
首先,仅使用低级别或高级别检索的影响:
1. 当仅使用低级别检索(即移除高级别检索,称为「-High」变体)时,模型在几乎所有数据集和评估指标上性能显著下降。例如,在Agriculture数据集的全面性维度,胜率从LightRAG的67.31%下降到35.79%。
2. 反之,当仅使用高级别检索(即移除低级别检索,称为「-Low」变体)时,虽然在全面性上可能有所提升,但在涉及具体实体细节的指标上表现不足。例如,在Agriculture数据集的多样性维度,胜率从LightRAG的75.91%降至35.09%。
3. 双层检索机制对于模型性能至关重要。仅使用低级别检索时,模型过于关注特定实体及其直接关联,无法全面理解复杂查询所需的广泛信息,导致性能下降。仅使用高级别检索则缺乏对具体细节的深入挖掘。在这两种情况下,模型的回答都不够完整或精准。这表明,结合低级别和高级别检索的双层策略能够平衡信息的广度和深度,为模型提供更全面的数据支持,从而提升整体性能。
其次,语义图在检索中的作用:
1. 当在检索过程中不包含原始文本(称为「-Origin」变体)时,模型在四个数据集上的性能并未显著下降,甚至在某些数据集(如Agriculture和Mix)上还有所提升。
2. 语义图在信息提取中的有效性得到验证。当移除原始文本时,模型性能未见明显下降,说明基于图的索引过程已经成功提取了关键信息。语义图结构本身提供了足够的上下文,用于回答查询。而原始文本中可能存在的冗余或不相关信息,反而可能干扰模型的检索和回答过程。
案例研究为了更直观地展示模型在实际应用中的表现,我们进行了具体的案例研究,比较了LightRAG和GraphRAG在回答特定问题时的效果。此次研究聚焦于一个涉及机器学习的问题:
「哪些方法可以对特征值进行规范化以提高机器学习的效果?」
我们分别获取了两个模型对该问题的回答,并使用大型语言模型(LLM)对它们在各个评估维度上的表现进行评估。结果显示,LightRAG在全面性、多样性和赋能性等所有维度上均优于GraphRAG。
在全面性方面,LightRAG的回答涵盖了更多的特征规范化方法,如归一化、标准化和归一化到特定区间等,体现了更强的信息整合能力。
在多样性维度上,LightRAG提供了多种不同的技术手段,涵盖了数据预处理的各个方面,信息更加丰富。
在赋能性方面,LightRAG的回答不仅列出了方法,还对每种方法的适用场景和优缺点进行了详细解释,帮助用户更好地理解和应用这些知识。
通过这个案例,我们可以得出以下结论:
1. 基于图的索引策略提升了模型的理解深度。LightRAG在全面性上的优势,得益于其精确的实体和关系提取能力,以及对知识的深入整合。
2. 双层检索策略增强了回答的质量和丰富性。低级别检索使模型能够深入挖掘具体细节,高级别检索则提供了宏观视角,两者结合提高了回答的全面性和实用性。
模型开销与适应性分析在实际应用中,模型的资源消耗和对动态环境的适应性至关重要。我们从两个关键角度对LightRAG和表现最优的基线模型GraphRAG进行了比较:一是索引和检索过程中使用的token数量和API调用次数,二是在动态环境中处理数据变化时的效率和成本。
以Legal数据集为例进行评估:
在检索阶段:
1. GraphRAG:生成了1,399个社区,其中610个用于实际检索。每个社区报告平均包含1,000个token,总消耗约610,000个token。同时,检索过程中需要逐一遍历这些社区,导致数百次API调用,增加了时间和资源成本。
2. LightRAG:仅使用了不到100个token用于关键词生成和检索,整个过程只需一次API调用。这大大降低了token消耗和API调用次数,提高了检索效率。
在增量数据更新阶段:
1. GraphRAG:当引入与Legal数据集等规模的新数据时,需要拆除现有的社区结构并完全重新生成。每个社区报告约需5,000个token,对于1,399个社区,总计需要约13,990,000个token,成本极高。
2. LightRAG:利用增量更新算法,能够直接将新提取的实体和关系无缝集成到现有的图结构中,无需完全重建索引,大幅降低了token消耗和处理时间。
通过上述分析,我们发现:
1. LightRAG在检索效率和资源消耗上具备明显优势。其优化的检索机制减少了不必要的信息处理,降低了token和API调用的使用量。
2. 在动态数据环境中,LightRAG的适应性更强。通过增量更新能力,能够有效应对数据的频繁变化,保持系统的高效性和成本效益。
综上所述,LightRAG在信息检索效率、成本效益和动态环境适应性方面都优于GraphRAG。这使其在需要处理大量数据和频繁更新的实际应用场景中,更具优势和竞争力。
参考资料:
https://arxiv.org/abs/2410.05779
https://sites.google.com/view/chaoh