LightRAG HKUDS/LightRAG

能干什么

一个轻量级的知识图谱 RAG 框架（EMNLP 2025），定位是 Microsoft GraphRAG 的高效替代。双层架构同时管知识图谱和向量：建库时让 LLM 从文档里抽实体-关系建图，查询时双级检索——local 模式抓具体实体细节、global 模式抓跨文档主题关系，再混上传统向量检索（naive / hybrid / mix 五档可选）。它不靠社区报告和多跳推理，把索引和查询阶段的 LLM 调用次数压得明显更低（延迟和 token 成本都省）。支持增量更新、删文档后自动重建受影响图谱；解析引擎多（MinerU / Docling / 自带原生解析，原生引擎能处理文档里的图片、表格、公式）；四种切块策略；存储后端可换（默认内存版只适合小规模测试，生产推荐 PostgreSQL，也支持 MongoDB / OpenSearch / Neo4j / Milvus 等）。带 WebUI + REST API 服务器；可按角色（抽取 / 查询 / 关键词 / 视觉）分别配不同模型——官方给本地部署的参考是抽取角色至少 Qwen3-30B-A3B 级（项目自述口径）。

怎么干

• uv tool install "lightrag-hku[api]"（或 pip install "lightrag-hku[api]"）
• 把 env.example 拷成 .env，配 LLM 与 embedding（本地可全指向 Ollama/vLLM），跑 lightrag-server 起 WebUI + API（也可 docker compose up）
• WebUI 传文档建图谱，然后用 local/global/hybrid/naive/mix 不同查询模式问答；生产环境把存储切到 PostgreSQL 等后端

本站怎么用

栏目里 RAGFlow 是「产品化知识库引擎」、Khoj 是「个人第二大脑」，LightRAG 是「图谱 RAG 算法框架」这一档——读者想搞清楚「RAG 检索到底怎么做的」、或者要在开源算法上自己拼知识库（接本地模型）时，它是当前代表。注意它的索引阶段要用 LLM 抽实体-关系，官方对本地模型的门槛建议比一般聊天重（见显存口径），不是「随便塞个小模型」就能跑的。

显存口径

总账比一般 RAG 重：抽取角色要用能干实体抽取的 LLM（官方建议本地部署至少 Qwen3-30B-A3B 级——项目自述口径，未本站复现；该模型 Q4 量化权重按参数量×精度粗估约 18G 量级，属本站估算非项目数据，实际以 /capacity/ 所选模型档位为准）+ embedding 模型常驻（官方推荐 bge-m3 类）；查询角色可配更强模型。若抽取走在线 API、查询走本地，本地显存压力可显著降低。默认内存存储只够小规模，数据集大要切生产存储。