
检索增强生成(RAG)技术已经成为大语言模型落地应用的关键基础设施。然而,传统 RAG 的"切分 → 向量化 → 检索 → 生成"模式在面对多跳推理和长链关系追踪时常常力不从心。
香港大学数据科学实验室(HKUDS)推出的 LightRAG,通过引入知识图谱结构彻底改变了这一局面。自 2024 年 10 月在 arXiv 发布以来,该项目在 GitHub 上已获得 36,000+ Stars,并以 MIT 协议开源。它被 EMNLP 2025 接收为 Findings 论文,成为 RAG 领域不可忽视的力量。
本文所有技术细节均来自 LightRAG 官方 GitHub 仓库(https://github.com/HKUDS/LightRAG)及论文(arXiv:2410.05779),代码示例来自官方仓库源代码。
LightRAG 由香港大学数据科学实验室(HKU Data Science Lab,简称 HKUDS)的 Zirui Guo、Lianghao Xia、Yanhua Yu、Tu Ao、Chao Huang 等人共同研发。该实验室在 AI 和数据科学领域有着深厚积累,还先后推出了 RAG-Anything、MiniRAG、VideoRAG 等一系列有影响力的开源项目。
传统 RAG 的流程如下:
用户问题 → 向量检索 → 返回 Top-K Chunk → LLM 生成回答这个看似简洁的架构埋藏着三个致命缺陷:
缺陷 | 表现 |
|---|---|
上下文碎片化 | 文档被切分为独立 Chunk 后,实体间的关联关系被切断 |
长链关系丢失 | 多跳推理需要跨多个 Chunk 整合信息,传统 RAG 难以做到 |
缺乏全局理解 | 只能检索"最相似"片段,无法理解宏观主题与结构 |
举个例子:假设你在分析安全情报库,提问 “Log4Shell 漏洞与 Apache 基金会历史上哪些漏洞有关?”
这正是 LightRAG 的独特价值所在。
来源:LightRAG 论文 Section 1 - Introduction,Parallels with Existing RAG Systems
LightRAG 的核心不是简单地用图数据库替换向量库,而是将知识图谱与向量检索深度融合,形成一套双引擎检索架构。
根据官方论文的描述,LightRAG 包含以下关键组件:
文档输入
│
▼
┌──────────────┐
│ 实体关系抽取 │ ◄── LLM 驱动,从文本中提取实体与关系
└──────┬───────┘
│
▼
┌──────────────────────────────────┐
│ 双层索引系统 │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Low-Level │ │ High-Level │ │
│ │ 实体级索引 │ │ 主题级索引 │ │
│ └──────────┘ └──────────────┘ │
│ └──────┬───────┘ │
│ ▼ │
│ ┌──────────────────────────┐ │
│ │ 向量嵌入 + 图结构存储 │ │
│ └──────────────────────────┘ │
└──────────────────────────────────┘
│
▼
┌──────────────┐
│ 双层检索引擎 │ ← local / global / hybrid
└──────┬───────┘
│
▼
LLM 生成回答来源:LightRAG 论文 Figure 1 - System Architecture;LightRAG README.md - “Algorithm Flowchart” 章节
LightRAG 将数据分为四类存储,各自承担不同职责。这是理解其架构设计的关键:
存储类型 | 默认实现 | 存储内容 |
|---|---|---|
KV Storage | JsonKVStorage | LLM 响应缓存、文本 Chunk、文档元信息 |
Vector Storage | NanoVectorDBStorage | 实体向量、关系向量、Chunk 向量 |
Graph Storage | NetworkXStorage | 实体-关系图结构 |
Doc Status Storage | JsonDocStatusStorage | 文档索引状态与处理管道进度 |
这种模块化的设计使得 LightRAG 可以灵活替换存储后端——从默认的本地文件到 PostgreSQL(pgvector)、Neo4j、Milvus、Qdrant、Redis、Faiss、MongoDB、OpenSearch 等。
来源:LightRAG
lightrag/lightrag.py第 251-261 行,__init__方法中存储类型的字段定义;README.md - “Storage Architecture” 章节
LightRAG 支持五种查询模式,覆盖从精确检索到全面推理的完整光谱:
# 来源:LightRAG README.md - "Selecting Query Modes" 章节
# lightrag/lightrag.py - QueryParam 数据类定义模式 | 说明 | 适用场景 |
|---|---|---|
naive | 传统向量检索,不使用知识图谱 | 简单事实查询 |
local | 图谱局部检索,聚焦具体实体及其直接关系 | 特定对象/概念的精确问答 |
global | 图谱全局检索,关注宏观主题和跨文档推理 | 趋势分析、多文档概括 |
hybrid | 融合 local + global 的检索结果 | 综合查询(推荐) |
mix | 融合 local + global + naive 的全部结果 | 最全面的检索,默认模式 |
来源:LightRAG README.md - “Selecting Query Modes” 章节;论文 Section 3.3 - Dual-Level Retrieval
根据官方文档的说明,mix 模式通常能取得最佳效果,而启用 Rerank 可以进一步提升查询质量(但会引入约 1-2 秒的延迟)。
这是 LightRAG 在工程实践中的一个重要亮点。传统 GraphRAG(如微软的方案)每次新增文档都需要重新构建全局索引,成本极高。LightRAG 实现了增量图合并:
“New data only needs to go through a standard graph indexing pipeline to generate a local graph, which is then directly integrated into the existing graph via set merging.” —— LightRAG README.md - “Features & Advantages” 章节
这意味着:
1. 检索质量明显高于纯向量库
在我自己的知识库测试中,对于需要跨文档推理的问题(如"某漏洞影响了哪些版本的组件"),LightRAG 的 hybrid 模式比传统向量检索的准确率有明显提升(约 30-40%,此为主观使用心得,非官方 benchmark 数据)。这在安全知识库和漏洞库场景下尤其有价值。
2. 增量更新能力出色
不需要每次重新构建整个索引,这在实际生产环境中至关重要。试想一个日增百篇文档的企业知识库,如果每次都要全量重建,计算成本将难以接受。
3. 成本远低于 Neo4j + GraphRAG 方案
LightRAG 默认使用 NetworkX 作为图存储后端,不需要额外部署图数据库。论文中的数据也显示,LightRAG 相比现有方法大幅降低了 Token 消耗和 API 调用次数。
来源:LightRAG 论文 Section 5 - Experimental Results;Abstract
1. 初次构图速度较慢
首次插入大量文档时,LLM 需要逐个读取文本并提取实体和关系,这个过程是瓶颈所在。对于数万篇文档的规模,可能需要数小时才能完成初次构图。
2. 实体抽取依赖 LLM 模型能力
LightRAG 的实体关系抽取完全依赖 LLM,如果使用能力较弱的模型(如 7B 以下),抽取质量会明显下降。官方建议使用至少 32B 参数的模型,且上下文窗口不低于 32K tokens。【需核实:建议查阅官方 README “Selecting LLM Models” 章节确认当前推荐配置】
来源:LightRAG README.md - “Selecting LLM Models” 章节
基于以上特点,以下场景特别适合 LightRAG:
以下代码来自 LightRAG 官方 PyPI 页面和 GitHub README 中的示例。
# 来源:LightRAG README.md - "Installation" 章节
# 使用 pip 安装核心库
pip install lightrag-hku
# 安装包含 API 服务器的完整版
pip install "lightrag-hku[api]"# 来源:LightRAG README.md - "Quick Start" 章节
# 该示例可在官方仓库 examples/ 目录下找到
import os
from lightrag import LightRAG, QueryParam
from lightrag.llm import gpt_4o_mini_complete, gpt_4o_complete
# 创建工作目录
WORKING_DIR = "./dickens"
if not os.path.exists(WORKING_DIR):
os.mkdir(WORKING_DIR)
# 初始化 LightRAG
rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_func=gpt_4o_mini_complete, # 使用 gpt-4o-mini 作为 LLM
)
# 插入文档(文本字符串)
with open("./book.txt", "r", encoding="utf-8") as f:
rag.insert(f.read())
# 执行查询,指定模式为 hybrid
result = rag.query(
"What are the top themes in this story?",
param=QueryParam(mode="hybrid")
)
print(result)对于生产环境,建议使用异步 API:
# 来源:LightRAG README.md - "Quick Start" 章节(示例代码)
# 以及 lightrag/lightrag.py 中定义的 ainsert / aquery 协程
import asyncio
import os
from lightrag import LightRAG, QueryParam
from lightrag.llm.openai import gpt_4o_mini_complete, openai_embed
from lightrag.kg.shared_storage import initialize_pipeline_status
WORKING_DIR = "./rag_storage"
if not os.path.exists(WORKING_DIR):
os.mkdir(WORKING_DIR)
async def main():
# 初始化 LightRAG 实例
rag = LightRAG(
working_dir=WORKING_DIR,
embedding_func=openai_embed,
llm_model_func=gpt_4o_mini_complete,
)
# 重要:必须先初始化存储!
await rag.initialize_storages()
await initialize_pipeline_status()
# 异步插入文档
await rag.ainsert("Your document text here")
# 使用不同的查询模式
for mode in ["naive", "local", "global", "hybrid"]:
result = await rag.aquery(
"What are the top themes in this story?",
param=QueryParam(mode=mode)
)
print(f"[{mode}] {result}")
# 使用完毕后清理资源
await rag.finalize_storages()
asyncio.run(main())# 来源:LightRAG README.md - "Quick Start" 章节(Ollama 示例)
import os
from lightrag import LightRAG, QueryParam
from lightrag.llm import ollama_model_complete, ollama_embedding
from lightrag.utils import EmbeddingFunc
WORKING_DIR = "./my_rag_project"
os.makedirs(WORKING_DIR, exist_ok=True)
rag = LightRAG(
working_dir=WORKING_DIR,
llm_model_func=ollama_model_complete,
llm_model_name="gemma2:2b", # 或 qwen2:7b 等
llm_model_max_async=4,
llm_model_max_token_size=32768,
llm_model_kwargs={
"host": "http://localhost:11434",
"options": {"num_ctx": 32768}
},
embedding_func=EmbeddingFunc(
embedding_dim=768,
max_token_size=8192,
func=lambda texts: ollama_embedding(
texts,
embed_model="nomic-embed-text",
host="http://localhost:11434"
),
),
)
# 插入文档并查询
rag.insert(["文档内容1", "文档内容2"])
result = rag.query("你的问题", param=QueryParam(mode="hybrid"))
print(result)# 来源:lightrag/lightrag.py - LightRAG 类定义
# 关键参数说明
rag = LightRAG(
working_dir="./rag_storage", # 工作目录,存储索引和缓存
embedding_func=openai_embed, # 嵌入函数
llm_model_func=gpt_4o_mini_complete, # LLM 函数
top_k=60, # 检索返回的实体/关系数量(默认 60)
chunk_token_size=1200, # 文本分块大小(默认 1200 tokens)
chunk_overlap_token_size=100, # 分块重叠大小
cosine_threshold=0.4, # 向量检索余弦相似度阈值
)
# 插入文档:支持字符串或字符串列表
rag.insert("文本内容")
rag.insert(["文档1", "文档2", "文档3"])
# 查询接口
rag.query(
"问题",
param=QueryParam(
mode="hybrid", # 可选:naive/local/global/hybrid/mix
top_k=60, # 检索数量
response_type="多段摘要", # 回答风格
)
)如果你正在建设一个需要跨文档推理能力的企业知识库、安全情报库或法律法规库,LightRAG 绝对值得一试。它不是传统 RAG 的替代品,而是 RAG 的进化形态——这也正是它的标题中"真正适合生产环境的 RAG 框架"这句话的底气所在。
资源 | 链接 |
|---|---|
GitHub 仓库 | https://github.com/HKUDS/LightRAG |
论文 | https://arxiv.org/abs/2410.05779 |
PyPI 包 | https://pypi.org/project/lightrag-hku/ |
官方文档 | https://github.com/HKUDS/LightRAG/tree/main/docs |
文中所有技术细节均引用自 LightRAG 官方文档及论文,保障信息准确可靠。如有疏漏,欢迎指正交流。 如果这篇文章对你有帮助,欢迎点赞 👍、收藏 ⭐、关注 📌,你的支持是我持续创作的动力!
