LightRAG：实体与关系的双层检索

LightRAG 是一种结合知识图谱与向量检索的 RAG 方法。建库时，它从文本中抽取实体和关系，分别建立可检索的文本表示，并保存图连接和原文来源；查询时，它从问题中提取两类关键词，分别搜索实体与关系，再利用图连接补充上下文、取回原文，交给模型回答。

这两路入口分别从具体对象和较宽主题寻找证据。例如，“海岬项目依赖谁？”可以从海岬这个实体出发；“这些项目有哪些共同的供应风险？”则可以先检索与供应依赖相关的关系，找到问题中没有直接点名的项目和供应商。LightRAG 将这两种入口称为低层检索与高层检索。这里的层级指具体对象与较宽主题的区别，并不表示图有上下两层节点。

原文怎样变成可检索的实体与关系

继续看海岬和青禾的项目记录：

T1：海岬项目由顾遥负责，向映川采购控制板。
T2：映川控制板交付延期，导致海岬联调顺延。
T3：青禾项目也向映川采购控制板，已启动备选供应商评审。

建索引时先分块，用 LLM 抽取实体和关系，再合并跨块的相同对象。得到的关系可以解释为：

(海岬, 负责人, 顾遥)        <- T1
(海岬, 采购控制板自, 映川)  <- T1
(映川, 交付延期影响联调, 海岬) <- T2
(青禾, 采购控制板自, 映川)  <- T3

抽取之后，论文中的 profiling 步骤为实体和关系生成文本 key-value 表示：key 提供便于检索的词或短语，value 概括相关原文。实体用名称作为 key，关系可以具有体现较宽主题的多个 key。这样，“海岬”能够匹配实体，“供应延期”也能匹配描述这一主题的关系。

对象	检索表示	描述与来源
实体：海岬	海岬	采购映川控制板，由顾遥负责；T1
实体：映川	映川	向海岬、青禾供应控制板；T1、T3
关系：交付影响联调	供应延期、项目依赖、联调计划	控制板延期使海岬联调顺延；T2

这些表示与图连接承担不同工作，建库后需要保留以下数据：

数据	内容	查询时的作用
实体向量索引	实体名称、描述等文本的向量表示	从具体名称或对象描述找到节点
关系向量索引	关系关键词、描述等文本的向量表示	从主题找到相关边
图存储	实体、关系及它们的属性	找到命中实体的关联边，或命中关系的端点
原文存储与来源映射	文本块，以及实体、关系对应的来源 ID	将检索结果还原为可阅读、可引用的证据

向量索引负责找到相关实体或关系，图存储负责沿连接补充信息，来源映射负责取回原文。查询时只需搜索已有表示并读取相应对象。描述合并应保留“海岬已延期”和“青禾启动评审”的区别，否则两个检索入口都会读到同一份失真的摘要。

低层关键词：先找到具体对象

用户问：“海岬的控制板由谁供应，发生了什么交付问题？”LLM 从问题中提取低层关键词，例如“海岬”“控制板”。系统将关键词编码，与实体向量索引做相似度搜索，选出相关节点；随后从图存储中读取节点描述和关联关系，再按来源映射获取原文。

从海岬可以取得供应关系，并回到 T1；相关交付记录指向 T2。上下文中便同时出现供应商和延期影响，避免只找到项目简介却漏掉另一份进度记录。

这一路的扩展范围受命中的实体限制。实体定位准确时，相关边能够补出问题没有明说的供应商；若抽词时改错了项目名，后续就可能从错误节点扩展。因此应保留专名和编号，并限制实体候选数量与返回上下文的长度。

高层关键词：从主题找到关系

问题换成“海岬和青禾有哪些共同的供应依赖，风险表现一样吗？”LLM 提取的高层关键词可以是“共同供应商”“供应依赖”“交付风险”。系统将它们编码，搜索关系向量索引，先取得相关边，再读取这些边两端的实体及来源。

候选关系可能包括海岬与映川、青禾与映川的采购关系，以及控制板延期对海岬的影响。再取回关系端点、相关邻域和 T1 至 T3，就能把共同点与差别分开。

两路检索的区别在这里更清楚：低层先命中“海岬、青禾”，再找它们的边；高层先命中“供应、交付影响”相关的边，再找到涉及的项目。高层仍然按相关性选候选，覆盖范围取决于关系表示和检索数量。它不会自动遍历全库，过宽的主题词也可能召回大量无关关系。

两路怎样合起来回答

同一个问题可以同时使用两层：低层找到海岬与青禾，高层找到供应依赖和交付影响。论文利用检索对象附近的一跳邻域补充信息，再合并重复的实体、关系和来源片段。根据上下文预算选择要保留的内容，连同原始问题一起交给生成模型。

对上面的问题，证据足够支持：“两个项目都采购映川控制板；海岬已记录交付延期和联调顺延，青禾已启动备选供应商评审。现有片段没有说明青禾已经延期。”每部分结论都能回到具体来源。

同一段 T1 可能通过实体检索和关系检索同时返回，去重后只保留一份文本，但保留它支持哪些关系的映射。上下文裁剪时也要一起考虑描述与来源，避免保留“海岬延期”这一结论，却删掉支持它的 T2。图中存在“共同供应商”的连接，只能支持共同依赖这一事实，不能据此认定两个项目都已延期。

查询模式与论文方法怎样对应

官方仓库使用的常见模式名称如下。模式的具体参数和默认行为应以所用版本为准。

模式	检索侧重点
local	低层关键词对应的实体及相关上下文
global	高层关键词对应的关系与主题上下文
hybrid	结合 local 与 global
naive	普通文本块向量检索，用于基线比较
mix	图检索与文本块向量检索结合

local、global 和 hybrid 对应上面讲的两路入口及其结合；naive 与 mix 还涉及普通文本块检索，属于仓库提供的查询选择。加入文本块通道可以召回没有被抽成实体关系的细节，但实体、关系和文本块的评分单位不同，融合时需要分别组织候选，不能直接把分数相加。

LightRAG 的 global 与 Microsoft GraphRAG 的 Global Search 也不同：前者搜索关系表示，后者对社区报告做 map-reduce。LightRAG 在查询时拼接相关实体、关系和原文，没有预先生成覆盖各社区的报告。因此它更适合从关系中寻找问题所需的上下文，不能仅凭模式名就认为能完整归纳整个资料库。

增量更新的收益与未解决的问题

论文提出把新文档抽出的实体、关系合并到已有图，不必每次重新处理全部旧文本。对于持续新增的资料，这减少了重复抽取工作。

但“新增可合并”不意味着更正和删除也只需追加。若 T2 被撤回，应去掉它对关系和描述的贡献；若还有别的来源支持同一关系，保留关系并重算描述。没有支持来源的对象及关联检索表示需要失效，避免回答继续引用旧内容。

汇总描述同样受权限限制。用户能阅读 T1，不能阅读 T2 时，不应从“海岬”实体摘要里间接看到 T2 的延期信息。描述与上下文必须来自可见来源，不能把原文权限过滤视为已经保护了所有派生数据。

省去社区报告后，LightRAG 仍需支付实体关系抽取、描述合并、向量化和在线关键词生成的成本。新增文档只处理新内容，可以减少重复抽取；已有实体受到影响时，它们的描述和向量表示仍需同步更新，否则图与检索索引会指向不同版本的信息。

原始资料

• LightRAG: Simple and Fast Retrieval-Augmented Generation：图增强索引、双层检索与增量合并的原始论文。
• LightRAG 官方仓库：查询模式和实际接口。实现能力应与论文方法分开核对。