LightRAG是一套开源的检索增强生成(RAG)框架，由香港大学数据智能实验室(HKUDS)提出，并与北京邮电大学研究人员合作完成，相关论文于2024年10月发布于arXiv，后被EMNLP 2025收录为Findings论文。它在传统「向量检索加拼接提示」的RAG思路之上引入图结构，在索引阶段用大语言模型从文档中抽取实体与关系、构建知识图谱，再通过低层与高层相结合的双层检索机制生成答案，从而改善跨文档关联与多跳推理能力。
定义
LightRAG是一套轻量级的图增强检索增强生成框架，为检索增强生成(RAG)流程引入知识图谱结构，把文档组织为实体与关系构成的网络，并在此基础上完成检索与生成。它被定位为微软GraphRAG的一种高效替代方案，采用图与向量双层的存储与检索架构，衔接了传统基于向量的RAG与基于图的RAG。
该框架由香港大学数据智能实验室(HKUDS)推出，北京邮电大学的研究人员参与合作，论文题目为《LightRAG: Simple and Fast Retrieval-Augmented Generation》。论文作者包括郭子睿(Zirui Guo)、夏亮豪(Lianghao Xia)、于艳华(Yanhua Yu)、敖图(Tu Ao)与黄超(Chao Huang)[1]。项目以MIT协议开源，代码托管在GitHub，核心库通过PyPI以lightrag-hku为包名发布[2]。
原理
LightRAG的工作分为索引与检索两个阶段。索引阶段先把原始文档切分为文本块，再调用大语言模型从每个块中识别实体(如人名、地点、事件、概念)以及实体之间的关系，用这些元素构成知识图谱的节点与边[1]。随后系统为实体节点和关系边生成键值对：键是便于匹配的短词或短语，值则是概括相关片段的文本段落；实体通常以名称本身作为键，关系的键则由模型依据其语义生成[3]。来自不同块的相同实体与关系会被去重合并，以缩小图谱规模[1]。
检索阶段采用双层检索范式。面对具体、细节型的问题，低层检索通过向量相似度定位目标实体，再沿图谱中的直接相连边做邻域扩展，收集局部上下文；面对概念型、综述型的抽象问题，高层检索则进行多跳的语义关联扩展，汇总分散在多份文档中的主题线索。系统先由模型从用户查询中提取低层关键词与高层关键词，分别匹配实体索引与关系索引，再把两路结果与原始文本块合并后交给大语言模型生成回答。在数学上，该框架可表示为检索模块对查询与外部数据库的映射，即 $\hat{D}=\varphi(D)$，最终输出 $\mathcal{M}(q;D)=\mathcal{G}(q,\psi(q;\hat{D}))$，其中 $\varphi$ 为索引函数、$\psi$ 为检索函数、$\mathcal{G}$ 为生成模块。
存储层采用模块化设计。LightRAG在逻辑上划分出4类存储：键值存储保存文本块、模型响应缓存与文档元信息；向量存储保存文本块、实体与关系的嵌入向量；图存储保存实体与关系构成的图结构；文档状态存储跟踪索引处理的进度[4]。默认实现基于本地文件，生产环境可替换为PostgreSQL、Neo4j、Milvus、Qdrant、MongoDB、Redis、Faiss等后端，业务代码无需改动[4]。
在增量更新方面，新文档经同样的图索引步骤生成新的节点集与边集，再与原有的节点集、边集取并集合并进现有图谱，避免对整个数据库重新处理[3]。删除文档时，系统可利用索引阶段生成的模型缓存快速重建受影响的实体与关系。
发展历程
LightRAG的论文于2024年10月在arXiv公开，编号为arXiv:2410.05779，作者为郭子睿、夏亮豪、于艳华、敖图与黄超[5]。项目仓库创建于2024年10月2日，开源后短时间内即在代码托管平台获得较高关注度，两周左右标星数接近5000，并进入趋势榜[3]。
此后项目持续迭代，陆续增加了服务端组件、Web界面与知识图谱可视化、重排序模型接入、多模态文档解析以及多种文档解析引擎等能力。2025年，该成果被自然语言处理会议EMNLP 2025收录为Findings论文，刊载于论文集中第10746至10761页[1]。
应用
LightRAG主要面向需要跨文档关联与多跳推理的问答场景。在数据持续更新的企业知识库中，其增量更新与关系查询能力较有针对性，新文档可以较快并入现有图谱并投入问答[4]。法律与金融等垂直领域对全局理解和逻辑推理要求较高，图结构索引有助于捕捉实体之间的语义依赖。
框架提供多种查询模式以适配不同需求：naive模式沿用传统向量检索而不使用知识图谱；local模式聚焦具体实体及其直接关系；global模式关注宏观主题与跨文档推理；hybrid模式融合局部与全局结果；mix模式进一步纳入向量检索结果，是官方推荐的默认模式[4]。检索结果之上还可启用重排序模型，对召回内容重新打分排序，通常能改善查询效果，但也会带来一定延迟[4]。
在工程接入上，框架支持通过OpenAI、Ollama、Hugging Face、Azure、Gemini等多种方式对接大语言模型与嵌入模型。官方建议索引阶段使用参数规模至少320亿、上下文长度不低于32KB的模型，嵌入模型一旦确定就应在索引与查询阶段保持一致[2]。此外，项目集成了RAGAS评估框架与Langfuse可观测工具，并提供引用溯源功能，使生成的回答可以标注原始文档出处[4]。
局限
LightRAG的实体与关系抽取完全依赖大语言模型，抽取质量受模型能力制约，官方建议使用参数规模不低于320亿、上下文长度不低于32KB的模型，能力较弱的模型可能导致抽取质量下降[2]。首次插入大量文档时，模型需要逐块读取文本并抽取实体与关系，初次构建图谱耗时较长，文档规模越大所需时间越多。
检索质量方面，论文自身的对比实验显示，在法律、农业、计算机科学和混合领域数据上，LightRAG相对朴素RAG与GraphRAG具备优势[6]。但有独立评估指出结果更为复杂：在部分任务上朴素RAG表现接近，而GraphRAG在需要深度多跳推理的关系型问答上仍保留最高约10%的准确率优势[7]。此外，其查询阶段的成本优势明显，但索引阶段仍需依赖模型为每个文本块做实体关系抽取，开销与所对比方案相近[4]。
参见
参考资料
- LightRAG: Simple and Fast Retrieval-Augmented Generation [引用日期2026-10-14]
- lightrag-hku [引用日期2026-10-14]
- 开源两周4.7k标星，港大LightRAG大幅降低大模型问答成本，全面理解复杂实体依赖关系 [引用日期2026-10-14]
- LightRAG [引用日期2026-10-14]
- huggingface.co 上的网页 [引用日期2026-10-14]
- LightRAG [引用日期2026-10-14]
- lightrag [引用日期2026-10-14]