README-zh.md
<a href="https://pypi.org/project/lightrag-hku/"></a>
</p>
<p>
<a href="https://discord.gg/yF2MmDJyGJ"></a>
<a href="https://github.com/HKUDS/LightRAG/issues/285"></a>
</p>
<p>
<a href="README-zh.md"></a>
<a href="README.md"></a>
<a href="README-ja.md"></a>
</p>
<p>
<a href="https://pepy.tech/projects/lightrag-hku"></a>
<a href="https://hvtracker.net/agents/lightrag/"></a>
</p>
</td>
<td style="vertical-align: middle; padding-left: 12px;">
<a href="https://litewrite.ai">
</a>
</td>
</tr>
Fix（固定）、Recursive（递归）、Vector（向量）和 Paragraph（段落语义）。图1：LightRAG索引流程图 - 图片来源：Source 图2：LightRAG检索和查询流程图 - 图片来源：Source
</details>💡 使用 uv 进行包管理: 本项目使用 uv 进行快速可靠的 Python 包管理。首先安装 uv: curl -LsSf https://astral.sh/uv/install.sh | sh (Unix/macOS) 或 powershell -c "irm https://astral.sh/uv/install.ps1 | iex" (Windows)
注意：如果您愿意，也可以使用 pip，但为了获得更好的性能 and 更可靠的依赖管理，建议使用 uv。
📦 离线部署: 对于离线或隔离环境，请参阅离线部署指南，了解预安装所有依赖项和缓存文件的说明。
### 使用 uv 安装 LightRAG 服务器（作为工具，推荐)
uv tool install "lightrag-hku[api]"
### 或使用 pip
# python -m venv .venv
# source .venv/bin/activate # Windows: .venv\Scripts\activate
# pip install "lightrag-hku[api]"
# 配置 env 文件
# 从 GitHub 仓库的根目录上下载 env.example 文件
# 或从本地检出的源代码中获取 env.example 文件
cp env.example .env # 使用你的LLM和Embedding模型访问参数更新.env文件
# 启动 API-WebUI 服务。默认绑定所有网络接口(0.0.0.0)。
# 安全提示:对外网暴露前,请在 .env 中配置认证(LIGHTRAG_API_KEY,或
# AUTH_ACCOUNTS 搭配 TOKEN_SECRET);若仅需本机访问,可绑定 127.0.0.1;
# 否则所有接口都将公开可访问。
# 注意:为兼容 Ollama 客户端,/api/* 路由默认不鉴权;如需对其启用认证,
# 请将 WHITELIST_PATHS 收窄为 /health。
lightrag-server
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
# 一键初始化开发环境（推荐）
make dev
source .venv/bin/activate # 激活虚拟环境 (Linux/macOS)
# Windows 系统: .venv\Scripts\activate
# make dev 会安装测试工具链以及完整的离线依赖栈
# （API、存储后端与各类 Provider 集成），并构建前端；不会生成 .env。
# 启动服务前请先运行 make env-base，或手动从 env.example 复制并配置 .env。
# 使用 uv 的等价手动步骤
# 注意: uv sync 会自动在 .venv/ 目录创建虚拟环境
uv sync --extra test --extra offline
source .venv/bin/activate # 激活虚拟环境 (Linux/macOS)
# Windows 系统: .venv\Scripts\activate
### 或使用 pip 和虚拟环境
# python -m venv .venv
# source .venv/bin/activate # Windows: .venv\Scripts\activate
# pip install -e ".[test,offline]"
# 构建前端代码
cd lightrag_webui
bun install --frozen-lockfile
bun run build
cd ..
# 配置 env 文件
make env-base # 或: cp env.example .env 后手动修改
# 启动API-WebUI服务
lightrag-server
git clone https://github.com/HKUDS/LightRAG.git
cd LightRAG
cp env.example .env # 使用你的LLM和Embedding模型访问参数更新.env文件
# modify LLM and Embedding settings in .env
docker compose up
在此获取LightRAG docker镜像历史版本: LightRAG Docker Images
由 GitHub Actions 发布到 GHCR 的官方镜像已使用 GitHub OIDC 和 Sigstore Cosign 进行签名。校验方式请参阅 docs/DockerDeployment.md。
在 Apple Silicon（macOS 26）上，无需 Docker Desktop 即可在 Apple 原生的
container运行时上运行相同的 Postgres/Neo4j/Milvus 存储栈 —— 参见 docs/AppleContainerSetup.md。
除了手动编辑 env.example 之外，您还可以使用交互式向导生成配置好的 .env，并在需要时生成 docker-compose.final.yml：
make env-base # 必跑第一步：配置 LLM、Embedding、Reranker
make env-storage # 可选：配置存储后端和数据库服务
make env-server # 可选：配置服务端口、鉴权和 SSL
make env-base-rewrite # 可选：强制重建向导托管的 compose 服务块
make env-storage-rewrite # 可选：强制重建向导托管的 compose 服务块
make env-security-check # 可选：审计当前 .env 中的安全风险
设置向导工具的详细说明请参阅 docs/InteractiveSetup.md。
Native docx 解析器的可选引擎参数 smart_heading 使用 spaCy 做分句/NER 启发式判断。spaCy 运行时已包含在 api extra 中——只有两个钉定版本的语言模型（zh_core_web_sm / en_core_web_sm 3.8.0，GitHub release wheel，未发布到 PyPI）需要额外一步安装：
lightrag-download-cache --spacy-install
可以按文件/规则启用 smart_heading（如 LIGHTRAG_PARSER=docx:native(smart_heading=true)），也可以在 .env 中全局启用：
# 路由到 native 引擎的 .docx 文件默认启用 smart_heading；
# 单个文件/规则可用显式 native(smart_heading=false) 关闭。
DOCX_SMART_HEADING=true
全局开关开启（或 LIGHTRAG_PARSER 规则携带 native(smart_heading=true)）时，服务器会在启动阶段校验模型并在缺失时立即报错（附安装指引）。从不启用 smart_heading 的部署无需安装模型。Docker 主镜像已内置模型（lite 镜像不含）；离线环境请参阅离线部署指南。
Native markdown/textpack 解析器会通过 cairosvg 把内嵌的 SVG 图片栅格化为 PNG。cairosvg 是对 cairo 的 cffi 绑定：pip install cairosvg（随 api extra 一起安装）总能成功，但只有宿主机同时装了原生的 libcairo 共享库，栅格化才真正能跑——pip/uv 装不了系统库。缺失时栅格化会在运行时失败，对应的 SVG 会被跳过（不影响文档其余内容）；服务器会在启动时探测这一能力，缺失时以醒目的黄色警告提示，避免这个缺口一直藏到某篇文档处理时才被发现。
按平台安装对应的系统包：
# Debian / Ubuntu（官方 Docker 镜像已内置）
sudo apt-get install -y libcairo2
# RHEL / Fedora
sudo dnf install -y cairo
# macOS（Homebrew）
brew install cairo
# Windows：安装内含 libcairo-2.dll 的 GTK3 运行时
从不处理带内嵌 SVG 的 markdown/textpack 文档的部署，可以忽略这条启动警告。
LightRAG 是一个轻量级的知识图谱 RAG 框架，被视为 Microsoft GraphRAG 的高效替代方案。它采用双层架构来同时管理知识图谱（KG）和向量嵌入，完美填补了传统基于向量的 RAG 与基于图谱的 RAG 之间的技术鸿沟。LightRAG专为高扩展性而设计，有效地解决了大规模图谱索引和查询时计算开销大、响应缓慢以及增量更新成本高等问题；LightRAG在支持大规模数据集的同时，即使搭载 30B开源大语言模型（LLM），也能保持极高的RAG质量。
固定长度分块(F)、递归字符分块(R)、向量语义分块(V) 和 段落语义分块(P)。其中，段落语义分块(P) 是 LightRAG 专属的分块策略，可以让分块边界尽可能对齐文档原生的语义边界（标题、段落和表格），从而减少标题与内容错配、长表格切分后丢失标题行等问题。传统 RAG 系统缺乏有效处理文档中图片、公式和表格等多模态内容的能力。从 v1.5 版本开始，LightRAG 将多模态处理能力无缝集成到文件处理管线和查询流程中。LightRAG 通过知识图谱将这些多模态内容与正文有机联系起来，在回答用户查询时能够结合多模态信息，给出更准确、更可靠的答案。这一能力可大幅提升操作说明书、学术论文等多模态内容丰富文档的 RAG 质量。
LightRAG 服务器不仅提供给了一个供出选择体验LightRAG功能的Web UI，还提供了一个完整的 REST API。有关LightRAG服务器的更多信息，请参阅LightRAG服务器。
LightRAG 的工作过程中需要使用到 4 种角色的 LLM/VLM。应该为不同角色的 LLM 配置不同能力和速度的模型，以获得速度和能力之间的平衡。LightRAG 对大型语言模型（LLM）的能力要求会高于传统 RAG，因为它需要 LLM 执行文档中的实体关系抽取任务。在查询阶段，LLM 模型需要处理 LightRAG 召回的实体、关系和文本块等大量信息，需要模型具备在含有噪声的长上下文中作出高质量回答的能力。
按角色推荐的模型：
EXTRACT）：实体关系抽取会对每个文本块调用，选择主流的高速模型即可，并强烈推荐使用非思考模型（关闭 reasoning/thinking 模式），以免抽取变慢、变贵。国外可选 GPT-5.6-luna、Claude Haiku、Gemini-mini；国内可选 DeepSeek-V4-lite、Kimi。本地部署最低可考虑 Qwen3-30B-A3B-Instruct。QUERY）：负责在长且嘈杂的召回内容上生成最终答案，应选择比抽取模型更强的模型，尽量提高回答质量；此处使用带思考能力的模型没有问题。KEYWORD）：轻量、对延迟敏感的环节，一定要选择非思考模型以降低查询延迟；选用与抽取模型相当的高速模型即可。VLM）：主流的多模态模型均可，需支持图片输入。本地部署可考虑 Qwen3.6-35B-A3B。在可接受的时间和价格范围内，优先选择评分（各类公开榜单/基准）越高的模型越好。详细的模型配置请参见 RoleSpecificLLMConfiguration-zh.md
LightRAG 支持 4 种查询模式：
LightRAG 的默认查询模式为 mix。使用 mix 模式通常可以获得最为理想的查询结果。mix 模式比 naive 耗时略长；其他查询模式在耗时上基本相当。
在选择 Embedding 模型的时候需要注意其对多语言的支持能力。LightRAG 的检索质量对 Embedding 模型的依赖有限，因此建议尽量选择低维度和速度快的模型。选择主流最新的 Embedding 模型即可；本地部署首选 BAAI/bge-m3。建议尽量本地部署 Embedding 模型，以获得最好的性能。
重要提示：在文档索引前必须确定使用的 Embedding 模型，且在文档查询阶段必须沿用与索引阶段相同的模型。嵌入模型一旦选定通常就不能修改。如果修改的话，需要对所有文本块、实体和关系进行重新嵌入。LightRAG 目前没有提供重新嵌入的工具。有些存储（例如 PostgreSQL）在首次建立数据表的时候需要确定向量维度，因此更换 Embedding 模型后需要删除向量相关库表，以便让 LightRAG 重建新的库表。
查询阶段开启 Rerank 选项可以显著提高查询的质量。开启 Rerank 通常会引入 1～2 秒的延时。为了降低延时，建议尽量在本地部署 Rerank 模型。主流最新的 Reranker 皆可，本地部署推荐 BAAI/bge-reranker-v2-m3。Rerank 的相关配置方式请参考 .env.example 文件。Rerank 模型与 Embedding 模型不同，可以在查询阶段随时更换。
LightRAG 的默认流水线配置并不能让系统发挥最好的性能。文件内容解析的好坏会极大地影响文档的索引和查询效果。因此建议配置流水线开启 MinerU 文件解析引擎，并开启流水线的图片分析功能。建议添加的配置为：
LIGHTRAG_PARSER=*:native-iteP,*:mineru-iteP,*:legacy-R
VLM_PROCESS_ENABLE=true
VLM_LLM_MODEL=<your_vlm_model_name>
由于云端的 MinerU 服务有使用量、文件大小和页数等限制，建议使用本地部署的 MinerU。文件处理流水线的具体配置方法请参考 FileProcessingPipeline-zh.md
对于大规模的文档处理，需要提高文档处理的并发能力。几个涉及文件并发处理性能的关键环境变量包括：
MAX_PARALLEL_INSERT 应该为 MAX_ASYNC_LLM 的 1/3 左右为宜。# 设置示例
MAX_ASYNC_LLM=8
MAX_PARALLEL_INSERT=3
EMBEDDING_FUNC_MAX_ASYNC=16
EMBEDDING_BATCH_NUM=32
LightRAG 需要使用到 4 种后台存储类型，分别是：
LightRAG 的默认存储全部都是基于文件进行持久化的内存数据库。默认存储仅用于开发调试，不适合用于生产环境部署。生产环境如果希望使用同一个后台数据解决 4 种类型的后台存储，可以选择 PostgreSQL、MongoDB 或 OpenSearch。也可以单独为向量存储或图存储选择专业化的数据库，例如使用 Milvus 或 Qdrant 作为向量存储，使用 Neo4j 或 Memgraph 作为图存储。
在文档插入阶段还有以下环境变量建议根据实际需要进行调整：
Chinese, English。实体/关系能够最多与多少个文本块保持关联实体/关系关联文本块超过限制后是否继续更新实体关系的描述（默认不再更新，因为此时实体关系的描述已经足够丰富，继续更新的意义不大；放弃更新可以极大地提高知识库的构建速度）实体/关系关联的原始文件的最大数量，超过这个数量之后新的文件名不再写入到向量存储。实体关系抽取阶段的 LLM 超时通常源于以下三种原因之一。先判断原因，再采用对应的解决方案（参数可以组合使用）：
*_LLM_TIMEOUT 增大超时时间——既可以是全局的 LLM_TIMEOUT，也可以是抽取阶段专用的角色参数 EXTRACT_LLM_TIMEOUT。注意实际的执行超时是所配置值的两倍，因此 EXTRACT_LLM_TIMEOUT=300 对应最长 600 秒。OPENAI_LLM_MAX_TOKENS 或 OPENAI_LLM_MAX_COMPLETION_TOKENS 限制输出长度（具体参数名取决于 LLM 供应商，详见 env.example）。一个实用的估算规则是 max_output_tokens < LLM_TIMEOUT × 每秒token数（例如 9000 < 240s × 50 tps）。P）分块策略（例如 LIGHTRAG_PARSER=...-iteP）时，设置 CHUNK_P_DROP_REFERENCES=true 可在分块前自动删除匹配的参考文献块，从而避免参考文献产生大量低价值的实体关系（这是导致超时的常见原因）。也可以通过文件名提示 paper.[-P(drop_rf=true)].pdf 对单个文件启用；相关的检测参数（CHUNK_P_REFERENCES_TAIL_N、CHUNK_P_REFERENCES_HEADINGS）详见 env.example。在文档查询阶段还有以下环境变量建议根据实际需要进行调整：
实体、关系和文本块三部分，实体和关系的长度可以单独控制长度，文本块的长度由总长度减去实体和关系的长度来控制。⚠️ 如果您希望将LightRAG集成到您的项目中，建议您使用LightRAG Server提供的REST API。LightRAG SDK通常用于嵌入式应用，或供希望进行研究与评估的学者使用。
cd LightRAG
# 注意: uv sync 会自动在 .venv/ 目录创建虚拟环境
uv sync
source .venv/bin/activate # 激活虚拟环境 (Linux/macOS)
# Windows 系统: .venv\Scripts\activate
# 或: pip install -e .
uv pip install lightrag-hku
# 或: pip install lightrag-hku
LightRAG核心功能的示例代码请参见examples目录。您还可参照视频视频完成环境配置。若已持有OpenAI API密钥，可以通过以下命令运行演示代码：
### you should run the demo code with project folder
cd LightRAG
### provide your API-KEY for OpenAI
export OPENAI_API_KEY="sk-...your_opeai_key..."
### download the demo document of "A Christmas Carol" by Charles Dickens
curl https://raw.githubusercontent.com/gusye1234/nano-graphrag/main/tests/mock_data.txt > ./book.txt
### run the demo code
python examples/lightrag_openai_demo.py
如需流式响应示例的实现代码，请参阅 examples/lightrag_openai_compatible_demo.py。运行前，请确保根据需求修改示例代码中的LLM及嵌入模型配置。
注意1：在运行demo程序的时候需要注意，不同的测试程序可能使用的是不同的embedding模型，更换不同的embeding模型的时候需要把清空数据目录（./dickens），否则层序执行会出错。如果你想保留LLM缓存，可以在清除数据目录时保留kv_store_llm_response_cache.json文件。
注意2：官方支持的示例代码仅为 lightrag_openai_demo.py 和 lightrag_openai_compatible_demo.py 两个文件。其他示例文件均为社区贡献内容，尚未经过完整测试与优化。
SDK的使用说明详见 docs/ProgramingWithCore.md（英文）。有部份LightRAG功能没有提供 REST API，仅能够通过SDK使用。这部份功能往往是不稳定，不能保证在将来的版本上可以兼容。
LightRAG 在农业、计算机科学、法律和混合等领域均显著优于 NaiveRAG、RQ-RAG、HyDE 和 GraphRAG。完整评估方法论、提示词和复现步骤详见 docs/Reproduce.md（英文）。
| 农业 | 计算机科学 | 法律 | 混合 | |||||
|---|---|---|---|---|---|---|---|---|
| NaiveRAG | LightRAG | NaiveRAG | LightRAG | NaiveRAG | LightRAG | NaiveRAG | LightRAG | |
| 全面性 | 32.4% | 67.6% | 38.4% | 61.6% | 16.4% | 83.6% | 38.8% | 61.2% |
| 多样性 | 23.6% | 76.4% | 38.0% | 62.0% | 13.6% | 86.4% | 32.4% | 67.6% |
| 赋能性 | 32.4% | 67.6% | 38.8% | 61.2% | 16.4% | 83.6% | 42.8% | 57.2% |
| 总体 | 32.4% | 67.6% | 38.8% | 61.2% | 15.2% | 84.8% | 40.0% | 60.0% |
| RQ-RAG | LightRAG | RQ-RAG | LightRAG | RQ-RAG | LightRAG | RQ-RAG | LightRAG | |
| 全面性 | 31.6% | 68.4% | 38.8% | 61.2% | 15.2% | 84.8% | 39.2% | 60.8% |
| 多样性 | 29.2% | 70.8% | 39.2% | 60.8% | 11.6% | 88.4% | 30.8% | 69.2% |
| 赋能性 | 31.6% | 68.4% | 36.4% | 63.6% | 15.2% | 84.8% | 42.4% | 57.6% |
| 总体 | 32.4% | 67.6% | 38.0% | 62.0% | 14.4% | 85.6% | 40.0% | 60.0% |
| HyDE | LightRAG | HyDE | LightRAG | HyDE | LightRAG | HyDE | LightRAG | |
| 全面性 | 26.0% | 74.0% | 41.6% | 58.4% | 26.8% | 73.2% | 40.4% | 59.6% |
| 多样性 | 24.0% | 76.0% | 38.8% | 61.2% | 20.0% | 80.0% | 32.4% | 67.6% |
| 赋能性 | 25.2% | 74.8% | 40.8% | 59.2% | 26.0% | 74.0% | 46.0% | 54.0% |
| 总体 | 24.8% | 75.2% | 41.6% | 58.4% | 26.4% | 73.6% | 42.4% | 57.6% |
| GraphRAG | LightRAG | GraphRAG | LightRAG | GraphRAG | LightRAG | GraphRAG | LightRAG | |
| 全面性 | 45.6% | 54.4% | 48.4% | 51.6% | 48.4% | 51.6% | 50.4% | 49.6% |
| 多样性 | 22.8% | 77.2% | 40.8% | 59.2% | 26.4% | 73.6% | 36.0% | 64.0% |
| 赋能性 | 41.2% | 58.8% | 45.2% | 54.8% | 43.6% | 56.4% | 50.8% | 49.2% |
| 总体 | 45.2% | 54.8% | 48.0% | 52.0% | 47.2% | 52.8% | 50.4% | 49.6% |
docs/）下表优先给出中文版链接；同目录下的同名 *.md 为对应的英文原版。
部署与安装
| 文档 | 内容 |
|---|---|
| InteractiveSetup.md | make env-* 安装向导：生成 .env 以及由向导管理的 docker-compose.final.yml |
| DockerDeployment.md | Docker / Docker Compose 部署、镜像版本差异，以及用 Cosign 验证官方 GHCR 镜像 |
| AppleContainerSetup.md | 在 Apple 原生 container 运行时上运行 Postgres / Neo4j / Milvus 存储栈（Apple Silicon，无需 Docker Desktop） |
| OfflineDeployment.md | 离线/内网环境部署：预装依赖、tiktoken 缓存与 spaCy 模型 |
| MultiSiteDeployment.md | 单机反向代理后运行多个相互隔离的实例，共用一份 WebUI 构建产物（LIGHTRAG_API_PREFIX） |
| FrontendBuildGuide.md | WebUI 的构建与分发方式（Bun / Node），以及哪些安装场景需要自行构建 |
服务器与 API
| 文档 | 内容 |
|---|---|
| LightRAG-API-Server-zh.md | 服务器完整指南：启动、配置、认证、REST 接口与 WebUI 使用 |
文档处理
| 文档 | 内容 |
|---|---|
| FileProcessingPipeline-zh.md | 流水线规格说明：LIGHTRAG_PARSER 路由规则、各引擎参数、多模态分析、文档状态生命周期 |
| ParserServiceDeployment-zh.md | 自行搭建 MinerU 与 docling-serve 外部解析服务（Docker、GPU、模型权重） |
| ParagraphSemanticChunking-zh.md | Paragraph semantic (P) 分块策略：对齐标题/段落/表格边界、参考文献丢弃 |
| LightRAGSidecarFormat-zh.md | sidecar（*.parsed/）交换格式规范，所有支持多模态的解析引擎都必须遵循 |
| ThirdPartyParser-zh.md | 开发并注册自定义 parser 引擎 |
| ParserDebugCLI-zh.md | python -m lightrag.parser.cli —— 脱离服务器离线解析单个文件并查看结果 |
模型与存储
| 文档 | 内容 |
|---|---|
| RoleSpecificLLMConfiguration-zh.md | 按角色（EXTRACT / QUERY / KEYWORD / VLM）配置 LLM 与 VLM |
| AsymmetricEmbedding.md | 查询/文档非对称 embedding（EMBEDDING_ASYMMETRIC）与各模型的前缀 |
| MilvusConfigurationGuide.md | 通过 vector_db_storage_cls_kwargs 调整 Milvus 索引参数 |
SDK 与开发
| 文档 | 内容 |
|---|---|
| ProgramingWithCore.md | 以 Python SDK 方式使用 LightRAG，包含未通过 REST 暴露的功能 |
| Reproduce.md | 复现论文中的评测结果 |
| UV_LOCK_GUIDE.md | 何时以及如何更新 uv.lock |
lightrag/tools/）涉及存储的工具与服务器一样读取 .env 和环境变量，请在项目根目录下、使用同一套配置运行。其中若干工具会原地改写存储——是否必须先停掉服务器（以及其它写入方）请查看对应指南，rebuild_vdb 必须先停。
rebuild_vdb.py — lightrag-rebuild-vdb — README_REBUILD_VDB.md
丢弃并从权威数据源（图节点/边、text_chunks KV 存储）重建全部向量存储。用于向量写入失败后的恢复，以及更换 embedding 模型或维度之后的重建；另提供只读的一致性检查模式。
clean_llm_query_cache.py — lightrag-clean-llmqc — README_CLEAN_LLM_QUERY_CACHE.md
删除查询模式的 LLM 缓存条目（mix:*、hybrid:*、local:*、global:*、naive:*），同时保留成本高昂的抽取缓存。
migrate_llm_cache.py — python -m lightrag.tools.migrate_llm_cache — README_MIGRATE_LLM_CACHE.md
在不同 KV 存储后端之间迁移 default 模式缓存（抽取、摘要、多模态分析），并保持 workspace 隔离。
kg_integrity_repair.py — python -m lightrag.tools.kg_integrity_repair [--apply] — README_KG_INTEGRITY_REPAIR.md
全图审计，找出未被 full_entities / full_relations 恢复锚点引用的图数据，报告无法归属的孤儿对象，并可选地补齐锚点，使删除/重试流程重新能够发现它们。
source_conflict_repair.py — python -m lightrag.tools.source_conflict_repair list / ... repair — README_SOURCE_CONFLICT_REPAIR.md
列出争用同一个规范 source key 的文档，并把运维人员未选中的候选降级为重复项。工具本身从不自行裁定胜者，也从不删除内容。
download_cache.py — lightrag-download-cache [--spacy-install] — OfflineDeployment.md
预先下载离线部署及 docx smart_heading 引擎参数所需的 tiktoken 编码与钉版 spaCy 模型。
hash_password.py — lightrag-hash-password [--username USER] — LightRAG-API-Server-zh.md
生成可直接粘贴进 AUTH_ACCOUNTS 的 bcrypt 口令值。
check_initialization.py — python -m lightrag.tools.check_initialization --demo — ProgramingWithCore.md
SDK 诊断工具：校验 LightRAG 实例是否已完整初始化，用于排查最常见的「忘记 await rag.initialize_storages()」问题。
生态与扩展
<div align="center"> <table> <tr> <td align="center"> <a href="https://github.com/HKUDS/RAG-Anything"> <div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;"> <span style="font-size: 32px;">📸</span> </div> <b>RAG-Anything</b> <sub>多模态 RAG</sub>
</a>
</td>
<td align="center">
<a href="https://github.com/HKUDS/VideoRAG">
<div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;">
<span style="font-size: 32px;">🎥</span>
</div>
<b>VideoRAG</b>
<sub>极端长上下文视频 RAG</sub>
</a>
</td>
<td align="center">
<a href="https://github.com/HKUDS/MiniRAG">
<div style="width: 100px; height: 100px; background: linear-gradient(135deg, rgba(0, 217, 255, 0.1) 0%, rgba(0, 217, 255, 0.05) 100%); border-radius: 15px; border: 1px solid rgba(0, 217, 255, 0.2); display: flex; align-items: center; justify-content: center; margin-bottom: 10px;">
<span style="font-size: 32px;">✨</span>
</div>
<b>MiniRAG</b>
<sub>极简 RAG</sub>
</a>
</td>
</tr>
提交 Pull Request 前，请阅读 <a href=".github/CONTRIBUTING.md"><strong>贡献指南</strong></a>。
</div> <div align="center"> 我们感谢所有贡献者做出的宝贵贡献。 </div> <div align="center"> <a href="https://github.com/HKUDS/LightRAG/graphs/contributors"> </a> </div>@article{guo2024lightrag,
title={LightRAG: Simple and Fast Retrieval-Augmented Generation},
author={Zirui Guo and Lianghao Xia and Yanhua Yu and Tu Ao and Chao Huang},
year={2024},
eprint={2410.05779},
archivePrefix={arXiv},
primaryClass={cs.IR}
}
</a>
<a href="https://github.com/HKUDS/LightRAG/issues" style="text-decoration: none;">
</a>
<a href="https://github.com/HKUDS/LightRAG/discussions" style="text-decoration: none;">
</a>