企业官网建设流程全解析

如何用 LightRAG 快速搭建知识图谱检索增强生成系统

【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG

LightRAG 是一个轻量级的知识图谱 RAG（检索增强生成）框架：文档导入后自动提取实体与关系，建成知识图谱，再用双层次检索回答问题。适合有一点 Python 基础、想先验证"这套知识问答能不能跑通"再谈生产化的开发者。

什么情况下你需要 LightRAG

先对号入座，三种场景命中任意一条，这个框架就是为你准备的。

• 内部技术文档、手册、规范堆在仓库里，同事反复问同样的问题，你想给它一个问答入口，但不想自己从零搭索引和排序链路。
• 问题跨文档：比如"某组件为什么频繁告警"需要同时引用三篇文档的信息，纯按文本块检索的传统 RAG 容易只命中其中一篇。
• 你有一批 PDF、Word、Markdown 格式的混合文档，希望多格式统一入库，并且答案能回溯到原文出处。
• 想先用小样本验证知识库的问答质量，再决定生产环境选哪种存储后端。

十分钟跑通 LightRAG

这一节跟着敲四条命令，你就能在本地看到第一次查询结果。

环境要求只有两条：Python 3.10 及以上（项目pyproject.toml中声明的最低版本），一个可用的 LLM 与 Embedding 模型 API。无需 GPU。

第一步，安装。从 PyPI 装服务端（含 API 与 WebUI 依赖）：

pip install "lightrag-hku[api]"

第二步，最小配置。配置已经从config.ini迁移到.env文件（仓库根目录的config.ini.example顶部已注明该格式将逐步移除）：

cp env.example .env # 编辑 .env：填入 LLM 与 Embedding 模型配置，env.example 内每项均有注释说明 lightrag-server

第三步，验证。服务默认监听 9621 端口，确认存活：

curl http://localhost:9621/health

打开浏览器访问http://localhost:9621，WebUI 会出现 Documents、Knowledge Graph、Retrieval、API 四个标签页。至此，你的第一套知识图谱 RAG 服务已经在运行了 🚀

原理速览：一张图看懂双层次检索

这一节只回答一个问题：文档进去之后发生了什么，它和普通 RAG 差在哪。

打个比方：普通 RAG 像图书馆的关键词搜索框，输入几个词，返回几个相关段落，段落之间互不相识。LightRAG 则先请一位"馆员"通读每篇文档，登记索引卡——卡上写实体（人、系统、概念）和实体间的关系——形成一张知识图谱。你提问时，它先查索引卡找到相关的实体与概念（图层次检索），再回原文库把对应的文本段落取出来（向量层次检索），最后把两层证据一起交给 LLM 组织答案。

这就是"双层次"的含义：上层走知识图谱，擅长跨文档的宏观关联；下层走向量库，擅长精确命中具体事实。查询时默认使用mix模式，合并 local（局部实体）、global（全局关系）与 naive（纯向量块）三路结果，另有local、global、hybrid、naive四种模式可按需切换。

把它接进真实业务：搭建文档问答知识库

这一节按动手路线走一遍企业知识库场景，不堆功能清单。

你先做 A：把待入库文档放进INPUT_DIR目录（默认./inputs，可在.env修改），或在 WebUI 的 Documents 页直接点击 Upload 上传，支持 PDF、Word、Markdown 等格式。

再做 B：触发文档处理（WebUI 的 Scan 按钮），在列表里等待状态变为 Completed。处理时系统会自动完成解析、分块、实体关系抽取三步。

用 C 验证：在 Retrieval 标签页提一个跨文档问题，检查答案与引用的原文；再切到 Knowledge Graph 标签页，确认实体之间的连线符合你的领域预期。

如果验证通过，再考虑批量导入与权限控制；如果答案质量不达标，先回头调分块策略和 LLM 角色配置，而不是急着换存储。

上生产之前：本地、Docker、Kubernetes 怎么选

这一节只回答选型问题：三种形态各适合谁，第一步分别做什么。

• 本地：个人验证用。pip install加lightrag-server即可，默认使用文件持久化的内存数据库，文档少、单机、无并发时体验最好，但不适合生产。
• Docker：团队共用的单机部署。cp env.example .env && docker compose up，数据落在./data/rag_storage，服务监听 9621 端口。注意在.env中配置认证（如LIGHTRAG_API_KEY），否则所有接口对外公开。
• Kubernetes：生产环境多副本部署。仓库提供 Helm Chart，见 K8s 部署配置，运行 install_lightrag.sh 一键安装，配套数据库组件在k8s-deploy/databases/下。

存储后端按此原则选：开发用默认文件存储；生产想要单一后端托管全部四类存储（KV、向量、图谱、文档状态），选 PostgreSQL、MongoDB 或 OpenSearch；想要组合拳，则向量用 Milvus/Qdrant、图谱用 Neo4j/Memgraph。

进阶与避坑：六个参数和评估手段

1. 分块策略：支持 Fixed、Recursive、Vector、Paragraph 四种；中文长文档建议用 Paragraph 语义分块，块边界对齐标题与段落，减少"标题和正文分家"。
2. Embedding 模型定了就不能换：更换后所有文本块、实体、关系都要重建，且没有现成的重嵌工具，PostgreSQL 后端还需删掉向量表重建，选型前先想清楚。
3. LLM 缓存：KV 存储会缓存实体抽取等 LLM 响应，重复文档不会重算；修改了提示词后需用 clean_llm_query_cache.py 清缓存，否则看到旧结果会误判。
4. 并发调优：大批量入库时调整MAX_ASYNC_LLM、MAX_PARALLEL_INSERT（约为前者的 1/3）、EMBEDDING_BATCH_NUM，变量说明见env.example。
5. Rerank 取舍：开启后查询质量明显提升，但每次多 1–2 秒延迟；在意响应时间的场景建议把重排模型部署到本地。
6. 质量要量化：仓库内置 RAGAS 评估，见 评估说明，关注忠实度、答案相关性、上下文召回与精度四项，经验阈值 0.8 以上。

接下来你可以做的三件事 ⚙️

1. 跑一遍官方示例，看完整的初始化、插入、查询代码长什么样：examples/lightrag_openai_demo.py。
2. 通读 docs/ 里的 API Server 与文件处理管线文档，把前面"先做 A 再做 B"的流程替换成你自己的文档源。
3. 浏览 lightrag_webui/ 了解界面能力，或直接对照 K8s 部署配置 规划生产拓扑。

挑一件今天就动手，你的第一张知识图谱离得很近 ✨

【免费下载链接】LightRAG[EMNLP2025] LightRAG: Simple and Fast Retrieval-Augmented Generation项目地址: https://gitcode.com/GitHub_Trending/li/LightRAG