LightRAG：比 GraphRAG 轻 10 倍的图增强检索方案，代价是什么

LightRAG 保留了 GraphRAG 的图增强检索能力砍掉了社区聚类报告——那个烧钱的步骤。索引成本降到约 1/10代价是放弃了规则推理、时序管理、程序化 Schema。港大数据科学实验室HKUDS出品论文发在 EMNLP 2025GitHub 38k StarMIT 协议Python最近一次更新就在今天2026-07-25。三种 RAG 的位置关系上面这张图把三种方案放在一条线上•Chunk-RAG传统方案——文档切片 → 向量编码 → 相似度匹配。简单、便宜但跨文档关联和全局问题答不好•GraphRAG微软方案——在切片之上加了 LLM 抽取实体关系、建图、社区聚类 LLM 摘要。全局理解力强但索引成本极高更新要全量重建•LightRAG港大方案——保留 LLM 抽取和建图砍掉社区聚类报告用双层检索替代。成本降到 GraphRAG 的约 1/10关键点LightRAG 省的不是实体抽取的钱——每个 chunk 还是要全量调 LLM 做抽取。它省的是 GraphRAG 在抽取之后叠的那层社区聚类摘要。后面成本章节会展开。图谱怎么建从文本到知识图LightRAG 的处理流程分两阶段索引阶段建图建索引检索阶段按模式查图查向量。先说索引。第一步文档切片原始文档进来先做 chunking。LightRAG 支持四种分块策略2026-05 新增固定 token、按分隔符、语义感知、以及基于文档结构的分块。这一步和传统 RAG 一样没有 LLM 参与。第二步LLM 抽取实体和关系对每个 chunk调用一次 LLM让它干两件事识别实体——给每个实体打上名称、类型、描述。类型由entity_types_guidance参数控制默认 11 类•Person人物、Organization组织、Location地点•Event事件、Concept概念、Method方法•Content内容作品、Data数据、Artifact人造物•Creature生物、NaturalObject自然物你可以换成自己的领域类型。法律领域定义TaxLaw / CourtCase / LegalPerson医疗领域定义Disease / Drug / Gene随便改。识别关系——从同一个 chunk 里找实体之间的关联每条关系记录源实体、目标实体、关键词、描述。要求拆成二元关系如果一句话涉及三个实体的关系拆成多对二元关系而且视为无向边。抽取 prompt 的核心指令拆解只认输入文本——实体和关系必须从 chunk 的原文里识别不能自己编命名一致性——实体名用 title case 格式每个实词首字母大写保证同一实体在不同 chunk 里名字一致方便后续去重第三人称——描述用第三人称写禁止用这篇文章我们的公司这类代词控制输出量——有max_total_records和max_entity_records上限超了就截断补抽机制——第一轮抽完会再跑一轮让 LLM 检查有没有漏掉的实体或关系第三步写入图 向量编码抽取完之后做两件事图存储——实体作为节点、关系作为边写入图数据库。如果同一实体在多个 chunk 里被抽取到会做描述合并把多段描述喂给 LLM 生成一段综合摘要。向量编码——实体名称描述、关系描述、原始 chunk 文本分别做 embedding 存入向量库。这一步形成三个向量索引实体向量库、关系向量库、文本向量库。 这一步的 LLM 消耗在哪每个 chunk 至少调一次 LLM 做抽取可能再调一次做补抽。如果同一实体被多个 chunk 抽到合并描述时还有额外的 LLM 调用。抽取阶段的开销和文档量成正比跟 GraphRAG 差不多。查询怎么走双层检索的五种模式查询进来后LightRAG 先用 LLM 提取查询里的关键词分两层•low_level_keywords低层——具体的实体名、专有名词、技术术语•high_level_keywords高层——抽象概念、主题、问题类型比如查询「苹果公司在 AI 领域的竞争策略」low_level 会提AppleAIhigh_level 会提竞争策略人工智能趋势。然后按选择的模式检索•naive——纯向量检索不查图。和传统 RAG 一模一样基准对照用•local——拿 low_level 关键词去实体向量库匹配找到实体节点后遍历它的直接邻居和关联边。适合问「某公司某产品」「某人物履历」•global——拿 high_level 关键词去关系向量库匹配找跨文档的主题关系链。适合问「行业趋势」「某领域整体格局」•hybrid——local global 结果合并•mix——local global naive 全合并默认推荐覆盖率最高local 检索的具体路径low_level 关键词 → 实体向量库 top-k 相似 → 命中的实体节点 → 图遍历取邻居节点和关联边 → 从边的关系描述里再找相关文本 chunk。一层层展开但每一层都用余弦相似度阈值过滤不是全图遍历。默认mix模式把三种检索结果全部召回再过一遍 Reranker 重排序最后把图谱数据实体关系和文档 chunk 一起塞进生成 prompt。这个设计的关键洞察不同问题需要不同粒度的检索。「张三是谁」需要 local「这个行业的竞争格局」需要 global。LightRAG 用模式切换来覆盖而不是像 GraphRAG 那样统一走聚类报告。成本「轻 10 倍」到底省在哪里这是最容易被误解的地方。先把话说清楚。两个系统都要全量抽取实体和关系。GraphRAG 和 LightRAG 在这一步的开销差不多——每个 chunk 调一次 LLM 做实体识别和关系抽取这一步省不掉原文有多少 chunk 就要调多少次。真正的差异在抽取之后GraphRAG 抽完实体关系后还要做社区检测Leiden 算法把图分成若干社区然后为每个社区调用 LLM 生成摘要报告。社区数量和文档规模正相关大语料库上这一步的 LLM 调用量轻轻松松破千次。而且文档更新时社区结构可能整体重构摘要报告要重新生成。LightRAG没有这一步。抽完实体关系就直接建索引不聚类不生成社区报告。查询时靠双层检索动态召回相关子图替代了预先算好的聚类摘要。所以「轻 10 倍」指的是抽取之后的社区聚类摘要那一步被砍掉了整体索引成本约为 GraphRAG 的 1/10具体倍数因语料规模而异但量级差异是确定的。不是内存体积不是二进制大小是 LLM 调用次数。⚠️ 别误读成本优势如果你以为 LightRAG 比 GraphRAG 省了实体抽取的钱那搞反了。两个系统的抽取开销半斤八两。LightRAG 省的是 GraphRAG 在抽取之上叠的那层社区摘要——但那层恰好是 GraphRAG 回答全局性问题的底气所在。代价为了轻量放弃了什么这部分是重点。LightRAG 的「轻」不是免费的它用一系列能力的缺失换来了低成本。1. 无规则引擎不能做约束推导LightRAG 的知识只能被检索不能被推理。对比蚂蚁集团的 KAGKnowledge Augmented GenerationKAG 有一个 KGDSL领域特定语言规则引擎可以定义「如果 A 且 B则 C」这样的逻辑规则让系统做约束推导。LightRAG 没有这个。它所有的「推理」都是隐式的——靠 LLM 在生成阶段从检索到的上下文里现推。这意味着需要确定性逻辑推导的场景合规检查、资格判定、规则计算LightRAG 不可靠。2. 无时序管理事实没有有效期LightRAG 的知识图谱是无时间戳的事实集合。一条关系「A公司 收购 B公司」一旦写入就是「永远成立」。如果这条关系后来失效了收购被撤销、政策被废止你只能靠删文档重建来处理——而且系统不会自动知道「这条事实在 X 日期后失效」。对于政策法规、合同条款这类有时效性的内容这是硬伤。「根据 2024 年的政策这个税率是多少」这种带时间限定的问题LightRAG 答不好。3. Schema 约束是 Prompt 级不是程序级前面提到entity_types_guidance是注入到 Prompt 里的文字。这意味着• LLM可能不按你定义的类型分类hallucination• 同一实体在不同文档里可能被分到不同类型• 没有 schema validation类型错误不会被拦截对比 KAG 的程序化 Schema实体类型、属性、关系定义都是结构化的入库前有校验。LightRAG 的约束是「尽力而为」不是「必须如此」。4. 无精确多跳推理LightRAG 的图遍历是检索手段不是推理引擎。它可以找到 A→B→C 的关系路径通过图遍历但不能保证这条路径在逻辑上成立因果关系 vs 相关关系 vs 巧合。「A 导致 BB 导致 C所以 A 导致 C」这种因果链推导LightRAG 做不了精确推理。它能召回相关的关系三元组但因果判断完全交给 LLM 在生成阶段「猜」。5. 实体去重不完善同一实体在不同文档中被多次抽取时LightRAG 靠 LLM 的命名一致性title case 规范来去重。这在实践中不完全可靠•Apple Inc.Apple苹果公司可能被当成三个不同实体• 缩写、别名、不同语言的名称去重成功率受 LLM 能力影响GraphRAG 有类似问题但 KAG 这类有程序化 Schema 的方案会好很多有规范化实体名 别名表。快速上手cpenvSDK 用法fromimportawaitawait 四种 LLM 角色可分别配置2026-05 新增 Role-specific LLM 配置EXTRACT抽取用便宜的非 thinking 模型、QUERY生成用更强的模型、KEYWORDS关键词用快模型控延迟、VLM多模态。按角色选模型成本和质量分开优化。什么场景该用什么场景别碰适合用 LightRAG• 需要跨文档关联但 Chunk-RAG 召回率不够• 成本敏感上不起 GraphRAG 的聚类报告开销• 想轻量部署一个 PostgreSQL 就够不需要 Java Neo4j 全家桶• 垂直领域需要自定义实体类型约束法律、医疗、金融• 文档频繁更新需要增量索引而非全量重建不适合用 LightRAG• 需要规则推理和因果推导 → 用 KAG 或上规则引擎• 需要时序版本管理政策法规修订追踪→ 上专门的时序知识图谱• 需要精确的多跳事实查询 → 图遍历是近似的不是精确的• 实体去重要求极高 → Prompt 级去重不够可靠学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】