本文来自香港大学数据智能实验室（HKUDS）和北京邮电大学，通讯作者为黄超教授。第一作者郭子睿，合作者包括夏良浩、余妍桦、敖图。

研究者提出了 LightRAG——一个将图结构融入文本索引和检索过程的 RAG 框架。核心思路是：传统 RAG 把文档切成块做向量匹配，但这种方法对复杂查询力不从心。LightRAG 用知识图谱捕捉实体间的依赖关系，再通过「双层检索」（Dual-level Retrieval）同时处理具体问题和抽象主题。效果相当直观：在最大的 Legal 数据集上，LightRAG 对 NaiveRAG 的总体胜率达到 84.8%，而检索阶段只需不到 100 个 token——GraphRAG 要 61 万个。

该论文已被 EMNLP 2025 Findings 接收，开源代码在 GitHub 上已获得 23,000+ Stars。

论文链接：https://arxiv.org/abs/2410.05779

代码仓库：https://github.com/HKUDS/LightRAG

现有 RAG 的瓶颈：扁平化检索无法处理复杂关联

检索增强生成（Retrieval-Augmented Generation, RAG）的核心流程不复杂：把外部文档切块，向量化存储，查询时按相似度召回相关片段，交给大语言模型（LLM）生成答案。Naive RAG、HyDE、RQ-RAG 等方法各有改进，但底层都依赖这套”切块 + 向量匹配”的逻辑。

问题在于，这种扁平化的数据表示很难捕捉实体之间的复杂关联。论文给了一个很直观的例子：当用户问”电动汽车的兴起如何影响城市空气质量和公共交通基础设施？“时，现有 RAG 会分别召回”电动汽车""空气污染""公共交通”三方面的文档，但无法把它们综合成一段连贯的回答。电动汽车改善空气质量，进而影响公共交通规划——这种跨主题的因果链条被切碎了。

微软的 GraphRAG 迈出了关键一步：用 LLM 从文档中提取实体和关系，构建知识图谱，再把节点聚类成社区（Community），检索时遍历社区报告获取全局信息。思路对了，但代价也很大。610 个社区，每个社区报告约 1000 个 token，检索一次就要消耗 61 万 token。更要命的是，每次更新数据都需要重建整个社区结构。

LightRAG 想解决的就是这个问题：能不能既享受图结构带来的检索质量提升，又把成本降下来？

核心架构：图索引 + 双层检索 + 增量更新

LightRAG 的整体架构包含三个紧密配合的模块，下图展示了完整的工作流程。

从文本到知识图谱：图增强文本索引

第一步是构建知识图谱。LightRAG 把文档切块后，用 LLM 从每个块中提取实体（节点）和关系（边）。比如从”心内科医生评估症状以识别潜在心脏问题”这句话中，提取出「心内科医生」和「心脏病」两个实体，以及「心内科医生诊断心脏病」这条关系。

提取之后有三个后处理步骤。LLM Profiling 为每个实体和关系生成键值对（Key-Value Pair），键是用于检索的短词组，值是描述性文本段落。实体用名称作为唯一索引键，关系则由 LLM 生成多个包含全局主题的索引键。去重（Deduplication）合并不同文本块中相同的实体和关系，减小图谱规模。这两个步骤确保图谱紧凑且可检索。

增量更新是这个模块的关键设计。新文档进来后，只需对新增部分做同样的提取和去重，然后与已有图谱取并集——新节点、新边直接”接”到现有图上。对比 GraphRAG 遇到新数据时必须拆掉整个社区结构重建的做法，LightRAG 的增量更新代价从重建 1399 个社区报告降到只处理新增文本。

双层检索：具体问题和抽象主题一起抓

有了知识图谱，怎么从中高效地找到相关信息？LightRAG 的答案是「双层检索」。

研究者把查询分为两类。「具体查询」（Specific Query）指向特定实体，比如”谁写了《傲慢与偏见》？“「抽象查询」（Abstract Query）涉及更广泛的主题，比如”人工智能如何影响现代教育？“这两类查询需要不同的检索策略。

低层级检索（Low-level Retrieval）聚焦具体实体及其属性和直接关系——找到精确匹配的节点和边。高层级检索（High-level Retrieval）从全局主题出发，聚合多个相关实体的信息，提供宏观视角。

实际检索分三步走。先用 LLM 从查询中提取局部关键词和全局关键词。然后通过向量数据库把局部关键词匹配到候选实体，全局关键词匹配到关系。最后，收集已检索元素的一跳邻居节点，引入高阶关联信息。这种”关键词匹配 + 邻居扩展”的方式比 GraphRAG 的社区遍历高效得多——一次查询只需 1 次 API 调用、不到 100 个 token。

生成阶段：结构化信息直接喂给 LLM

检索到的信息被组织为实体描述、关系描述和原文片段三个部分，拼接后交给 LLM 生成最终答案。和传统 RAG 的生成阶段相比，区别在于输入内容的质量更高——已经过图结构筛选和去噪。

实验结果：全面超越传统 RAG，检索成本降千倍

四个数据集上的全面对比

研究者在 UltraDomain 基准的四个数据集上做了评测：Agriculture（12 篇文档，200 万 token）、CS（10 篇，230 万 token）、Legal（94 篇，508 万 token）、Mix（61 篇，62 万 token）。基线包括 NaiveRAG、RQ-RAG、HyDE 和 GraphRAG，所有 LLM 操作统一使用 GPT-4o-mini，chunk size 固定为 1200。评估用 GPT-4o-mini 做 LLM Judge，从全面性（Comprehensiveness）、多样性（Diversity）、赋能性（Empowerment）和总体四个维度打分。

结果很清晰。在 Legal 数据集上（最大、最复杂），LightRAG 对所有基线的总体胜率都在 52% 以上：对 NaiveRAG 达到 84.8%，对 RQ-RAG 为 85.6%，对 HyDE 为 73.6%，对 GraphRAG 为 52.8%。

几个关键发现。图增强 RAG 在大规模语料上优势显著——数据集越大，LightRAG 和 GraphRAG 相比纯块检索方法的领先幅度越大。在 Legal 上，传统方法的胜率被压缩到仅 20% 左右。LightRAG 在多样性指标上特别突出，在 Legal 上对 GraphRAG 达到 73.6% 的胜率。双层检索同时覆盖具体实体和全局主题，这比 GraphRAG 的社区遍历方式检索面更广。

即使在最小的 Mix 数据集上，LightRAG 对 GraphRAG 的总体胜率也接近持平（49.6%），对其他方法的胜率均在 57% 以上。

消融实验：每个模块都有不可替代的作用

消融实验拆解了 LightRAG 的核心组件，以 NaiveRAG 作为对照基线。

去掉高层检索（-High 变体），性能在几乎所有数据集上都有明显下降。只看具体实体和直接邻居，能挖得深但视野窄，面对需要综合理解的复杂查询就力不从心了。去掉低层检索（-Low 变体），全面性尚可但缺乏深度——能收集更广的信息，具体细节却不够，在需要精确回答的场景下吃亏。完整的混合模式同时保证广度和深度，表现最均衡。

一个有意思的发现：去掉原文（-Origin 变体），仅用图谱信息生成答案，性能几乎没有下降，在 Agriculture 和 Mix 上甚至略有提升。研究者认为这说明图索引过程已经有效提取了关键信息，而原文中的无关内容反而可能引入噪声。换句话说，一个构建得好的知识图谱，本身就是足够的信息源。

成本分析：差距是数量级的

在 Legal 数据集上，GraphRAG 的检索阶段消耗约 61 万 token（610 个二级社区 × 每个约 1000 token），需要数百次 API 调用。LightRAG 的检索阶段只需不到 100 个 token、1 次 API 调用。差距超过三个数量级。

增量更新的对比更夸张。新增同等规模的数据时，GraphRAG 需要重建全部 1399 个社区报告，约 1399 × 2 × 5000 个 token。LightRAG 只需处理新增部分的实体和关系提取，然后把新节点和新边接入现有图谱。

总结

这篇论文的核心贡献可以概括为三点。

把知识图谱引入 RAG 的文本索引和检索过程，解决了扁平化检索无法处理复杂实体关联的问题。双层检索范式同时覆盖具体查询和抽象查询，兼顾检索的深度和广度。增量更新算法避免了重建整个索引的开销，使 RAG 系统在动态数据环境下也能高效运行。

GitHub 23K+ Stars 说明社区对轻量级图增强 RAG 方案的需求很强烈。未来，如何进一步优化图谱构建质量、支持更复杂的多跳推理场景，仍是值得探索的方向。