LightRAG：把 RAG 做简单，同时保留知识图谱的推理能力

RAG 这件事有个尴尬的现状：方案越来越强，但越来越难落地。

完整的图 RAG 方案效果好，代价是要维护实体抽取、图构建、多路存储、增量更新一整套流程。部署一套下来，还没开始解决业务问题，基础设施已经吃掉大半个月。

于是很多团队退回到最简单的那条路：切块 + 向量检索。够用，但一碰到需要关系推理的问题就露怯。

LightRAG（来自香港大学数据科学实验室 HKUDS）想卡的这个位置是：比完整图 RAG 简单得多，但没把图的能力丢掉。

README 的关键词就是标题那三个：Simple and Fast。

能力很强，但起步太重

双级检索：它的核心机制

LightRAG 算法上最有辨识度的是双级检索。

思路是这样：文档进来后，除了切块，还会抽取实体和关系，形成一张知识图谱。检索时同时走两条路——

低层级检索针对具体实体。问"某某函数的参数是什么"，它沿着实体找具体信息。

高层级检索针对抽象主题。问"这套系统的整体设计思路"，它抓的是更上层的概念节点。

这个分层设计解决的是 RAG 里一个常见病：问题的抽象层次和文档切块的粒度不匹配。宏观问题用微观切块回答，答案就会碎；反之又会太虚。两级同时检索，能覆盖不同抽象层次的问题。

从更新记录看它的演进

README 里的 News 列表信息量很大，能看出这个项目在想什么：

切块策略可自选——现在提供四种：Fix、Recursive、Vector、Paragraph。切块策略对 RAG 效果影响巨大，但很多框架只给一种。给四种可选，等于承认"没有一种切块方式适合所有文档"。

角色化 LLM 配置——支持为四种不同角色分别配置 LLM：EXTRACT（抽取）、QUERY（查询）、KEYWORDS（关键词）、VLM（视觉模型）。

这个设计很实际。抽取实体需要强模型（要理解复杂语义），但关键词生成用便宜模型就够。分开配置能显著降低成本，而且不牺牲关键环节的效果。

多模态支持——2026 年 5 月把 RAG-Anything 合并进了 LightRAG，通过 MinerU / Docling 服务做多模态内容解析和抽取。另外还有独立的 RAG-Anything 项目专门处理文本、图像、表格、公式。

Reranker 支持，并把它设为默认查询模式。README 提到这一步"显著提升混合查询性能"。把重排设为默认说明作者对效果很有信心——重排会增加延迟，敢默认开是因为收益足够大。

文档删除会触发知识图谱自动重建。这是个容易被忽略但很重要的细节：删文档不重建图，会导致图里残留孤立节点，查询性能逐渐劣化。

存储后端可选——PostgreSQL、MongoDB、Neo4J、OpenSearch 都能用。OpenSearch 集成的更新记录里写着"为全部四种 LightRAG 存储提供完整支持"，说明它的架构是分层的（向量、图、键值、文档索引分开存）。

面向开源模型的图谱抽取优化——2025 年 9 月专门针对 Qwen3-30B-A3B 这类开源模型提升了抽取准确度。

这条对国内用户价值不小：不是所有人都在用最强的闭源模型，能在开源模型上把抽取做好，等于把整套方案的成本门槛降下来了。

评估与可观测——集成了 RAGAS 做评估、Langfuse 做链路追踪，并且 API 会同时返回检索到的上下文和查询结果，以支持上下文精确度指标。

最后这一点是认真做工程的表现——要算上下文精确度，你必须能拿到"实际召回了什么"，只给最终答案是不够的。

把 RAG 做到足够简单，才会真的被用起来

安装与环境

官方推荐用 uv 管理包（比 pip 更快、依赖解析更可靠），也支持 pip。有独立的 LightRAG Server 安装方式，命令是 uv tool install "lightrag-hku[api]"。

这里有个容易踩的坑：Python 包名和项目名不一样——包叫 lightrag-hku，不是 lightrag。装错了会装到别的东西上。

另外官方提供了离线部署指南，针对离线或气隙（air-gapped）环境，说明如何预装所有依赖和缓存文件。这个对企业内网部署是必需文档——很多开源项目只考虑"有网环境"，到了内网全是坑。

还有安装向导，支持通过 Docker 在本地部署嵌入模型、重排模型和存储后端。这一步解决的是"模型从哪来"的问题。

配套生态也值得一提：作者团队还放出了 RAG-Anything（多模态 RAG）、VideoRAG（超长视频理解）、MiniRAG（用小模型做 RAG）。多个方向都有对应项目，说明研究积累比较扎实。

适合谁用

想用图 RAG 但被复杂度劝退的团队。这是它最直接的定位。

需要在成本和效果之间权衡的项目。角色化 LLM 配置让"哪里用强模型、哪里用便宜模型"变成可调的，而不是一刀切。

主要使用开源模型的团队。它专门针对开源模型的抽取准确度做过优化。

没有公网的内网环境。离线部署指南是实打实的支持。

不太适合：

  • 只需要简单语义检索的场景。上向量库就够，不必引入图。
  • 完全不想碰基础设施的个人用户。它仍然需要理解并配置存储后端的组合，有学习成本。
  • 对延迟极度敏感的场景。图检索 + 重排相比纯向量检索会慢，官方把重排设为默认也说明它优先效果。

项目地址： https://github.com/HKUDS/LightRAG

本文依据项目官方仓库 README 与更新记录整理编写。功能与配置方式请以官方最新文档为准。