LightRAG 评测：用图索引把 RAG 的召回成本降下来

它解决的是 RAG 的哪个痛点

传统 RAG 把文档切块后做向量检索，能回答单点事实，但跨段落、跨文档的关系问题经常答不准。LightRAG 的论文标题直接点出目标：简单且快速的检索增强生成。它用知识图谱把实体和关系显式建出来，让检索不只看相似度，还能沿着图结构走。适合的场景是知识库问答、企业文档检索、需要可解释来源的问答系统。它的定位不是通用聊天框架，而是把图谱索引和 RAG 流程绑定在一起的专用方案。

索引和检索的实际机制

LightRAG 的索引阶段会把文档交给 LLM 抽取实体和关系，构建知识图谱。这个抽取不是一次性完成，而是分块处理，再合并成全局图。检索阶段支持多种查询模式，包括本地、全局和混合，其中混合模式是默认。它还引入了 reranker，用来提升混合查询的效果。整个流程里，LLM 承担了图谱抽取和查询理解两个关键角色，这意味着 LLM 的质量直接决定图谱的准确度。文档删除功能会自动触发知识图谱重建，保证查询性能，但这也意味着删除操作的成本不低。

部署方式：uv 工具链和服务器模式

安装路径很明确，推荐用 uv 而不是 pip。命令是 uv tool install "lightrag-hku[api]"，这会装成命令行工具。装完后要复制 env.example 到 .env，再填 LLM 和 embedding 的配置。项目提供 setup wizard，可以用 Docker 本地部署 embedding、reranking 和存储后端，这对不想碰云服务的团队很友好。服务器模式意味着你可以把索引和查询封装成 API，前端或业务系统直接调用。离线部署也有专门文档，说明作者考虑了内网环境。整体部署不算复杂，但依赖 uv 这个额外工具，如果团队不熟 uv，会有学习成本。

存储后端的选型不是小事

LightRAG 支持多种存储后端，包括 Neo4j、PostgreSQL、MongoDB 和 OpenSearch。Neo4j 是图数据库，天然匹配知识图谱。PostgreSQL 和 MongoDB 是全能型，可以同时存向量和图结构。OpenSearch 是后加入的统一存储，能覆盖全部四种存储需求。选哪个不只是性能问题，还关系到运维。Neo4j 需要专门的图数据库运维知识，PostgreSQL 和 MongoDB 大多数团队更熟悉。OpenSearch 适合已经用 Elasticsearch 生态的团队。文档没有给出各后端的性能对比，所以选型时要自己压测。

多模态和 chunking 策略带来的复杂度

2026 年 5 月的更新把 RagAnything 合并进来，支持通过 MinerU 或 Docling 解析 PDF、图片、Office 文档、表格和公式。这确实扩展了适用面，但也引入了新的依赖。多模态解析不是 LightRAG 核心，而是外部服务，意味着你要额外部署这些服务。同时，文本分块策略增加到四种：Fix、Recursive、Vector、Paragraph。策略多了，调参空间也大了。对新手来说，这可能不是好事，因为选错策略会直接影响图谱抽取质量。文档没有给出不同策略的适用场景建议，需要自己实验。

角色分离的 LLM 配置：灵活但费心

LightRAG 支持为 EXTRACT、QUERY、KEYWORDS、VLM 四种角色配置独立的 LLM。你可以用便宜的小模型做关键词提取，用强模型做图谱抽取，用 VLM 处理图像。这种设计很务实，能降低成本。但代价是配置复杂度上升，你要为每个角色挑选模型、设置 API key、调参数。如果团队没有明确的模型选型标准，很容易在配置上消耗大量时间。另外，2025 年 9 月的更新专门优化了开源 LLM 的图谱抽取精度，说明开源模型在抽取任务上曾经有明显短板，如果你打算用 Qwen 这类开源模型，需要重点验证这个环节。

评估与追踪：RAGAS 和 Langfuse 的集成

从 2025 年 11 月起，LightRAG 集成了 RAGAS 做评估，Langfuse 做追踪。API 会返回检索到的上下文，方便计算 context precision 这类指标。这对生产环境很重要，因为 RAG 系统的效果不能只看最终答案，还要看检索质量。有追踪和评估，团队才能定位是索引问题还是查询问题。不过，这些集成是框架层面的，真正的评估指标设计还是要自己来。RAGAS 的评估需要一套测试集，这本身就是一项前期投入。

已知局限和替代方案

LightRAG 最明显的局限是索引阶段依赖 LLM 抽取图谱，这既慢又贵，而且抽取质量不稳定。文档提到开源 LLM 的抽取精度是专门优化过的，说明它不是天然就好。另一个局限是文档删除会触发图谱重建，频繁更新文档的场景下，计算开销会很大。替代方案方面，你可以考虑直接使用向量数据库加普通 RAG 流程，比如 LangChain 搭配 FAISS 或 Milvus，这种方式没有图谱构建成本，但关系推理能力弱。另一个方向是 GraphRAG 项目，它同样用图谱，但实现更重，面向更复杂的全局性问题。LightRAG 的优势在于轻量，GraphRAG 的优势在于深度，两者对 LLM 的调用模式和索引策略都不同。

编辑结论

LightRAG 适合那些已经确定要用图谱增强检索、且愿意接受索引阶段额外计算成本的团队。它不适合只做简单向量检索的轻量场景，也不适合对文档删除和知识更新频率要求极高的系统，因为删除后需要自动重建知识图谱，代价不低。采用前先验证三件事：一是你的 LLM 在 EXTRACT 角色下的图谱抽取质量是否稳定，二是所选存储后端（如 Neo4j、PostgreSQL、MongoDB 或 OpenSearch）是否与你的运维能力匹配，三是 uv 工具链和离线部署方案能否融入现有 CI/CD。如果这些都能接受，LightRAG 的图索引机制值得一试；如果只是想要一个即插即用的向量 RAG，它可能不是最省事的选择。

官方来源

1. Official documentation
2. Official README
3. Project repository
4. Release notes