链载Ai

标题: 比GraphRAG还好的LightRAG到底是何方神圣? [打印本页]

作者: 链载Ai    时间: 昨天 11:55
标题: 比GraphRAG还好的LightRAG到底是何方神圣?

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;background: rgb(250, 81, 81);color: rgb(255, 255, 255);visibility: visible;">1. 为什么要提出 LightRAG?

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;visibility: visible;">检索增强生成(Retrieval-Augmented Generation,RAG)通过整合外部知识源来增强大型语言模型,这种整合使 LLM 能够生成更准确和与上下文相关的响应,显著提高实际应用中的效用。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;visibility: visible;">然而,现有的 RAG 系统存在关键的局限性,阻碍了它们的性能:

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;">为了解决这些局限性,作者准备将图结构(知识图谱)纳入文本索引和相关信息检索。图特别有效地表示不同实体之间的相互依赖关系,这能够更细致地理解关系。基于图的知识结构的整合有助于将来自多个来源的信息综合成连贯且上下文丰富的响应。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;">因此,作者提出了LightRAG:一个基于图的文本索引范式与双层检索框架无缝集成的RAG系统。

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;display: table;background: rgb(250, 81, 81);color: rgb(255, 255, 255);">2. LightRAG架构

ingFang SC", "Hiragino Sans GB", "Microsoft YaHei UI", "Microsoft YaHei", Arial, sans-serif;font-size: 14px;letter-spacing: 0.1em;">上图展示了LightRAG的架构,分为两个主要部分:

2.1 基于图的文本索引

图增强的实体和关系提取:LightRAG 通过将文档分割成更小、更易于管理的部分来增强检索系统。允许在不分析整个文档的情况下快速识别和访问相关信息。利用大型语言模型(LLM)来识别和提取各种实体(例如,名称、日期、地点和事件)以及它们之间的关系,然后创建一个知识图。

这样的设计有以下几个优点:

增量更新知识库*

对增量知识库的快速更新方法有两个关键目标:

2.2 双层检索范式

LightRAG 在微观和宏观两个维度生成查询键,从而实现在特定文档块和复杂的依赖关系里检索相关信息。

为了适应不同的查询类型,LightRAG 在双层检索范式中采用了两种不同的检索策略。确保了特定和抽象的查询都得到有效处理,使系统能够根据用户需求提供相关响应。

图与向量检索相结合的检索

通过将图结构与向量表示相结合,使检索算法能够有效地利用本地和全局关键字,简化搜索过程并提高结果的相关性。

这种双层检索范式不仅通过关键字匹配促进了相关实体和关系的高效检索,而且通过整合来自构建的知识图的相关结构信息增强了结果的全面性。

2.3 答案生成

检索信息的利用:利用检索到的信息通过LLM 根据收集的数据生成答案。收集到的数据包括由相关实体和关系,包括名称、实体和关系的描述以及原始文本的摘录。

上下文整合和答案生成:将查询与这个多源文本统一,LLM 生成根据用户需求定制的信息丰富的答案,确保与查询的意图一致。这种方法通过将上下文和查询都整合到 LLM 模型中简化了答案生成过程(下图是提示词)。

3. 效果评估

3.1 RQ1:LightRAG在生成性能上与现有RAG基线方法相比有何优势?

图增强型RAG系统在处理大规模语料库时的优势:面对需要大量token和复杂查询时,LightRAG和GraphRAG等基于图的RAG系统,始终优于NaiveRAG、HyDE和RQRAG等纯基于块的检索方法。随着数据集规模的增长,这一性能差异尤为显著。例如,在最大的法律数据集中,基线方法的胜率仅约20%,而LightRAG则明显占优。这一趋势凸显了图增强型RAG系统在捕捉大规模语料库内复杂语义依赖方面的优势,有助于更全面地理解知识,从而提升泛化性能。

LightRAG在提升响应多样性上的优势:与各基线方法相比,LightRAG在多样性(回答问题的角度等是否具备多样性)指标上尤为突出,特别是在大型法律数据集中。这一优势源于LightRAG的双层检索模式,能够从低级和高级两个维度全面检索信息。这种方法有效地利用基于图的文本索引,始终把握查询的完整上下文。

LightRAG超越GraphRAG:尽管LightRAG和GraphRAG都采用基于图的检索机制,但LightRAG尤其在处理大型数据集和复杂语言环境时,始终优于GraphRAG。在包含数百万令牌的农业、计算机科学和法律数据集中,LightRAG展现出明显优势,大幅超越GraphRAG,凸显了其在多样化环境中全面理解信息的能力。

3.2 RQ2:双层检索和基于图的索引如何提升LightRAG的生成质量?

3.3 RQ3:LightRAG在多种场景的案例中展现了哪些独特优势?

3.4 RQ4:LightRAG的成本及其对数据变化的适应能力如何?

从两个关键角度将我们的 LightRAG 的成本与表现最佳的基线 GraphRAG 进行比较。

3.4.1 检索阶段

GraphRAG 生成了 1399 个communities,有 610 个二级communities被积极用于检索。每个communities报告平均 1000 个tokens,导致总标记消耗为 610000 个tokens(610 个communities×每个communities 1000 个tokens)。

此外,GraphRAG 需要单独遍历每个communities,导致数百次 API 调用,显著增加了检索开销。相比之下,LightRAG 通过使用少于 100 个tokens进行关键字生成和检索,整个过程仅需要一次 API 调用。这种效率是通过LightRAG检索机制实现的,该机制无缝集成了图形结构和矢量化表示以进行信息检索,从而消除了预先处理大量信息的需要。

3.4.2 增量数据更新阶段

两个方案在实体和关系提取方面表现出相似的开销。

然而,GraphRAG 在管理新添加的数据方面显示出显著的低效率。当引入与法律数据集相同大小的新数据集时,GraphRAG 必须拆除其现有的社区结构以纳入新的实体和关系,然后完全重新生成。

这个过程每个社区报告产生大约 5000 个token的大量标记成本。鉴于有 1399 个communities,GraphRAG 将需要大约 1399×2×5000 个标记来重建原始和新的社区报告——这是一个过高的费用,突显了其低效率。

相比之下,LightRAG 将新提取的实体和关系无缝集成到现有图形中,无需完全重建。这种方法在增量更新期间导致显著较低的开销,展示了其优越的效率和成本效益。







欢迎光临 链载Ai (https://www.lianzai.com/) Powered by Discuz! X3.5