说 RAG 工具，先得承认一件事：大多数 RAG 框架搭起来很爽，用起来很慢，维护起来很痛苦。尤其是微软 GraphRAG，动不动就要构建整个知识图谱，索引阶段跑半天，查询还要多跳推理，大文档集一上就卡成 PPT。
LightRAG 就是来解决这个问题的——HKUDS（香港大学数据科学实验室）出品，EMNLP 2025 论文支撑，GitHub 37.3K ⭐，最新 v1.5.4 刚支持多模态文档解析。
核心思路：图 + 向量双层检索
LightRAG 的设计哲学很简单：别把所有东西都塞进知识图谱里做全局推理，太慢。它的双层检索架构把任务分开——
局部层（Local）：精准匹配具体实体和属性。从知识图谱里拉出目标实体及其直接关联的邻居节点和边。适合「这个公司去年营收多少」这类具体问答。
全局层（Global）：宏观主题和跨文档推理。从图谱里找到覆盖大主题和高层次概念的关系链。适合「这家公司所在行业近五年的发展趋势是什么」这种需要整合信息的问题。
两种模式可以在同一次查询里同时调用（hybrid 或 mix 模式），也可以单独使用。默认的 mix 模式基本覆盖了大多数场景。
为什么比 GraphRAG 快 2 倍
官方评测数据说，在农业、计算机科学、法律、混合领域四个数据集上，LightRAG 全面超过 NaiveRAG、HyDE、RQ-RAG，与 GraphRAG 相比，Completeness 提升 10-35%，Diversity 提升 20-55%。
快的原因不是用了什么黑科技，而是 GraphRAG 的设计本身就贵：
- GraphRAG 建索引时要生成社区报告，每一簇节点都要让 LLM 做一次摘要，成本指数级增长。
- 查询时要做多跳推理，层数越多调用越多。
- 增量更新要重建全局索引。
LightRAG 没有社区报告这个概念，索引只做两件事：实体+关系抽取 → 存图，向量嵌入 → 存向量库。查询直接按实体和关系检索，不用 LLM 额外生成中间产物。所以索引速度和查询速度都明显更快。
v1.5.4 更新了什么
2026 年 6 月刚发布的版本有几个值得注意的更新：
多模态文档解析：集成了 MinerU 和 Docling 两个解析引擎，可以从 PDF、Word、Excel 里提取文字、表格、公式、图片，不再只处理纯文本。解析结果统一映射到实体-关系框架里做 RAG 检索。
四种分块策略：Fix（固定长度）、Recursive（递归切分）、Vector（向量相似切分）、Paragraph（段落语义切分）。不同类型的文档可以选不同策略，表格密集型文档用 Paragraph 效果通常更好。
角色级 LLM 配置：LightRAG 内部有 4 种 LLM 角色——EXTRACT（实体关系抽取）、QUERY（查询改写）、KEYWORDS（关键词生成）、VLM（多模态图片理解）。每个角色可以独立配置不同的模型，比如 EXTRACT 用性价比高的，QUERY 用能力强的 30B 模型。
OpenSearch 统一后端：PostgreSQL、MongoDB、Neo4j 之外的又一个选项，可以用 OpenSearch 同时承载四种存储（KV、向量、图、文档状态），适合已有 OpenSearch 基础设施的团队。
怎么上手
安装是开箱即用的，两行命令跑起来：
```bash
uv tool install "lightrag-hku[api]"
# 填 API key
cp env.example .env
# 编辑 .env 填入 LLM 和 embedding 配置
# 启动服务
lightrag-server
```
也可以 Docker 部署，自带 embedding 模型和存储后端的本地化选项，offline 场景也能跑。配置向导会引导你设置 LLM、提供商、存储后端、安全参数，不需要手动改很多 env 变量。
如果想自己写代码集成，Python SDK 也支持：
```python
from lightrag import LightRAG, QueryParam
rag = LightRAG(
llm_model="gpt-4o-mini",
embedding_model="bge-m3"
)
rag.insert("《圣诞颂歌》全文内容...")
# mix 模式查询（默认，推荐）
result = rag.query("Ebenezer Scrooge 性格有什么特点？",
param=QueryParam(mode="mix"))
print(result)
```
不是没有槽点
用了一段时间，有几个真实问题要说：
第一个是 LLM 质量依赖。实体和关系抽取完全靠 LLM 的能力。如果用 GPT-4o mini 这类小模型，某些复杂文档（参考文献多、表格密集、术语生僻）可能抽不出完整的关系图，查询结果自然受影响。官方建议用 30B 以上开源模型（Qwen3-30B-A3B 实测效果不错），但这意味着本地部署的硬件门槛也上去了。
第二个是 embedding 模型选定后不能改。LightRAG 的向量维度由 embedding 模型决定，一旦选定了（官方推荐 BAAI/bge-m3），更换需要清空所有已存向量数据重建索引。对于已经有大量数据的生产环境来说，这是一个需要一开始就规划好的事情。
第三个是 Reranker 启用后延迟增加 1-2 秒。开启重排确实能提升混合查询质量，但如果对延迟敏感的业务场景（比如在线客服），这个开销要认真评估。重排模型也建议本地部署，减少网络延迟。
跟同类怎么选
如果你的数据量在几千篇文档以内、没有跨文档全局推理需求，普通向量 RAG（ChromaDB + LangChain 方案）足够，没必要上知识图谱。
如果你的场景需要跨文档综合分析（比如一个行业分析报告库、一个法律条款合集），GraphRAG 和 LightRAG 都能覆盖。LightRAG 在速度、成本、增量更新友好度上更优；GraphRAG 在生态成熟度和文档配套上更完整（但 GraphRAG 索引速度慢的问题至今没有很好解决）。
如果你的数据高度动态（每天更新、实时查询），LightRAG 的增量索引优势非常明显——新文档只需要走标准抽取流程，然后直接 merge 进现有图谱，不用重建。
如果你的文档是多模态的（PDF 里全是表格、公式、截图），LightRAG v1.5+ 的 MinerU/Docling 集成是加分项。
一句话总结：需要快速部署、动态数据、低成本跑生产 RAG，选 LightRAG。 港大实验室维护，更新节奏稳定，开源社区活跃度很高，踩坑了也有人一起讨论。
GitHub：HKUDS/LightRAG
官方文档：github.com/HKUDS/LightRAG
标签：#LightRAG #知识图谱RAG #GraphRAG #RAG框架 #港大 #开源AI #向量检索
关注我，每期分享一个帮你省事的强大工具 🛠️