LightRAG解读：最新发布的简化版GraphRAG，性能更好，简化了大量建图的步骤

LIGHTRAG: SIMPLE AND FAST RETRIEVAL-AUGMENTED GENERATION

作者：Zirui Guo

机构：北京邮电大学

来源：arXiv 2024.10.8

https://github.com/HKUDS/LightRAG

• 问题：传统的RAG在某些方面存在一定的限制，比如依赖平面数据表示以及对上下文感知不够，这些使得模型无法抓住复杂的内部关系。
• 方法：
  • 提出LightRAG，将图结构嵌入到文本索引和检索过程中。整体的框架包括一个双层的检索系统，从低级的和高级的知识发现中来增强综合的信息检索。
  • 使用了一种瞬时更新算法，确保及时更新新数据，允许系统保持有效性的同时对于数据变化能够迅速的响应。

1 Introduction

作者主要解决以下三个方面的问题

• 综合信息检索：确保抓住所有文档内部实体的完整上下文
• 增强检索效率：在基于图的知识结构上显著降低应答时间
• 迅速适用于新数据：确保系统保持与动态环境的相关性

双层检索策略（确保用户能够只收到需要的相关和全面的响应）

• low level检索：关注特定实体以及他们之间关系的精确信息
• high level检索：包含更广泛的话题

2 检索增强生成

整个系统的框架

RAG系统的框架被记为$\mathcal{M}$，也就是下面这个图

其中$\mathcal{G}$和$\mathcal{R}$分别代表生成模型和检索模型，$q$代表输入的query，$D$代表额外的数据库。检索模型$\mathcal{R}$包括两个关键函数：（1）Data Indexer$\varphi (\cdot )$：基于数据库构建特定的数据结构$\hat{D}$.（2）Data Retriever$\psi (\cdot )$：通过对比query和索引数据获取相关的文档。

结构流程图

文中作者没有介绍这个图，但从图中可以看出，整体结构包括首先通过文档构建索引图，该索引图包括实体节点（名称、实体类型、描述、Chunk ID）以及边也就是实体之间的关系（原实体、目标实体、关键词、描述、Chunk ID）；之后结合Query送进LLM得到low level keys和high level keys。

3 LightRAG 的结构

3.1 基于图的文本索引

图增强的实体和关系抽取

（1）分而治之：将整篇文档分割成更小的、易于管理的pieces，这样能够避免分析整篇文档，并且快速识别和评估相关的信息。

（2）通过抽取关系建立知识图，主要包括三步：

• 抽取实体和关系**$R(\cdot )$**：将原始文档chunk成$D_i$，之后对每个$D_i$通过给LLM一个prompt来抽取实体以及实体之间的关系。

• 通过LLM分析得到key-value对：根据实体$\mathcal{V}$和关系$\mathcal{E}$，使用一个LLM授权的分析函数**$P(\cdot )$**来生成一个文本的key-value对（K, V），每一个Key要么是一个单词，要么是一个短语，保证有效被检索到；相应的value是一个段落总结小片段

• 降重：对于每一个原始文本$D_i$利用一个降重函数**$D(\cdot )$**来识别并合并相同的实体和关系。

（3）个人总结：上面作者提到的步骤，相对于微软的GraphRAG，相当于实现了其前三步，而对于后面冗余的步骤，包括强弱关系打分、遗漏提示、生成社区、社区总结都省略了，可能作者认为这些步骤都没有必要，而且这些步骤还会使得构件图的过程花费大量的时间。

（4）作者总结：GraphRAG这种社区遍历技术效率太低，而作者这种从Graph中获得的（K, V）数据结构能够快速精准的检索。

快速适用于增量知识库

更新整个数据库而不需要对外部文档进行再一次的完全处理。

对于一个新的文档$D^{\prime }$，和之前一样提取实体$\widehat{{\mathcal{V}}^{\prime }}$和关系$\widehat{{\mathcal{E}}^{\prime }}$，之后与先前的实体和关系取并集。

3.2 双层检索范式（针对的是查询层面）

提出构建低级（细节）的和高级（抽象）的查询key，确保了具体的和抽象的询问都能得到有效的解决。

特定的query：与某个特定的节点或边有关，例如“谁写了傲慢与偏见？”

抽象的query：更多的是概念性的，与某个特定的实体无关，例如“人工智能是如何影响当代教育的？”

整合图与向量来有效的检索

（1）查询关键字的提取：对于一个给定的query，算法提取局部的query关键字 $k^l$以及全局的query关键字$ke{y}^g$

（2）关键字匹配：利用一种有效的向量数据库将局部query关键词与候选实体相匹配，将全局query关键词与链接到全局key（猜测应该是（k, v）对）的关系相匹配

（3）聚合高阶相关性：即聚合检索到的局部子图的邻居节点，用集合表示为：

这里的${\mathcal{N}}_v$以及${\mathcal{N}}_e$表示检索到的节点$v$和边$e$的一跳邻域节点。

3.3 基于检索增强的答案生成

利用检索到的信息

被检索的数据包括实体与关系的连接值V，是由分析函数产生的，也就是3.1节（2）的第二步形成的

上下文集成与答案生成

将检索到的信息与query统一起来送入LLM得到答案。

3.4 为什么高效

• 创建图的过程中被调用的次数为（total tokens/chunk size），也就是一个chunk调用一次，而GraphRAG一个chunk需要调用三次。

• 检索过程需要利用LLM生成相关的关键词，来查询实体关系对，而GraphRAG则需要遍历社区，因此这也提高了效率。

4 评估

作者基于以下四个问题进行评估

4.1 评估设置

• 数据集，使用UltraDomain benchmark，包括Agriculture、CS、Legal以及Mixed数据

• 问题生成：将每一个数据集中的所有内容作为一个上下文，告诉LLM生成5个users，每个user被指派5个任务，对每个task生成5个question，这样每个数据集就有125个问题

• baseline：Naive RAG、RQ-RAG、HyDE、GraphRAG

• 评估策略：使用GPT-4o-mini对每个baseline模型相对于提出的Light模型进行排名，使用了一种特别的prompt来使用于评判的LLM对于结果能够更好的评估。

• 评估维度：综合性、多样性、有效性、整体性能

4.2 对于RQ1的评估

得出的结论：

• 大规模的语料库情况下，基于图的RAG是有优势的
• 回答更加全面广泛，这归因于LightRAG的双向检索设置

4.3 对于RQ2的评估

设计消融实验，分别只使用低级检索（-High）、高级检索（-Low）、去除结构流程图中的Origin Text（-Origin）

从结果来看，-High和-Low的效果都降低了，而-Origin结果变好了，原因可能来自于检索过程中使用的基于图的索引，为答案提供了丰富的内容。

4.4 对于RQ3的评估

使用LLM对于LightRAG和GraphRAG的答案进行决策，表明Light在这四个方面是最好的。

个人总结

• 从这几个评估方面来看，对于基于Graph的RAG来说，评判其回答结果的好坏并没有一个严格的评判标准，从阅读的论文来看，都是使用辅助的LLM进行评判。

• 对于生成实体和关系的prompts来看，和GraphRAG较为相似，但没有展示教模型生成答案的正确例子