LightRAG是一个基于知识图谱的检索增强生成（RAG）系统，通过将文档转换为知识图谱并支持多层次检索，它能够理解实体关系、进行多跳推理和全局理解。文章详细介绍了LightRAG的整体架构设计、核心算法（包括文档索引流程、实体关系抽取、知识融合算法和查询检索流程），并提供了小白理解指南和关键概念速查。通过学习LightRAG，程序员可以轻松构建高效的知识库，提升信息检索和生成能力。

1、什么是 LightRAG？

LightRAG 是一个基于知识图谱的检索增强生成（RAG）系统，它的核心创新在于：

• 将文档转换为知识图谱（实体+关系）
• 支持多层次检索（局部/全局/混合）
• 使用向量数据库加速语义搜索
• 通过LLM生成高质量答案

2、核心价值

相比传统RAG（只做文本块检索），LightRAG通过构建知识图谱，能够：

• 理解实体关系：不仅知道"张三"和"李四"，还知道他们是"同事关系"
• 多跳推理：能回答"张三的同事的老板是谁"这类复杂问题
• 全局理解：既能回答细节问题，也能回答宏观问题

3、整体架构设计

1. 三层架构

2. 核心组件关系

LightRAG (主控制器)
├── 文档插入流程
│   ├── 文本分块 (chunking_by_token_size)
│   ├── 实体抽取 (extract_entities)
│   └── 知识融合 (merge_nodes_and_edges)
│
├── 查询流程
│   ├── 关键词提取
│   ├── 图谱检索 (kg_query)
│   ├── 向量检索 (naive_query)
│   └── LLM生成答案
│
└── 存储管理
├── full_docs (完整文档)
├── text_chunks (文本块)
├── entities_vdb (实体向量)
├── relationships_vdb (关系向量)
└── chunk_entity_relation_graph (知识图谱)

4、核心算法设计

算法1: 文档索引流程

1.1 文本分块算法 (chunking_by_token_size)

目的：将长文档切分为适合LLM处理的小块

核心逻辑：

def chunking_by_token_size(
tokenizer,           # 分词器
content,             # 原始文本
chunk_token_size,    # 每块最大token数 (默认1200)
chunk_overlap_token_size  # 重叠token数 (默认100)
):
# 步骤1: 将文本编码为token序列
tokens = tokenizer.encode(content)
# 步骤2: 滑动窗口切分
chunks = []
for start in range(0, len(tokens), chunk_token_size - chunk_overlap_token_size):
chunk_tokens = tokens[start : start + chunk_token_size]
chunk_text = tokenizer.decode(chunk_tokens)
chunks.append(chunk_text)
return chunks

关键设计：

• 重叠窗口：相邻块有100个token重叠，避免切断语义
• Token计数：基于token而非字符，确保LLM输入不超限
• 可选分隔符：支持按段落/句子分割后再按token切分

1.2 实体关系抽取 (extract_entities)

目的：从文本块中提取结构化的实体和关系

核心流程：

async def extract_entities(chunks, global_config):
results = []
for chunk_id, chunk_data in chunks.items():
# 步骤1: 构造提示词
prompt = PROMPTS["entity_extraction"].format(
entity_types=config["entity_types"],  # 实体类型列表
tuple_delimiter="<|#|>",              # 字段分隔符
record_delimiter="\n",                # 记录分隔符
input_text=chunk_data["content"]      # 文本块内容
)
# 步骤2: 调用LLM提取
extraction_result = await llm_func(prompt)
# 步骤3: 解析LLM输出
entities, relationships = parse_extraction_result(extraction_result)
# 步骤4: 存储到缓存
results.append({
"chunk_id": chunk_id,
"entities": entities,
"relationships": relationships
})
return results

LLM输出格式示例：

entity<|#|>张三<|#|>人物<|#|>公司CEO，负责战略决策
entity<|#|>ABC公司<|#|>组织<|#|>一家科技公司
relation<|#|>张三<|#|>ABC公司<|#|>任职于<|#|>张三是ABC公司的CEO
<|COMPLETE|>

关键技术：

• Few-shot提示：提供示例引导LLM输出标准格式
• 多轮Gleaning：如果首次提取不完整，追加提示再次提取
• 缓存机制：提取结果存入llm_response_cache，避免重复调用

1.3 知识融合算法 (merge_nodes_and_edges)

目的：将多个文本块的提取结果合并为统一的知识图谱

核心挑战：

• 同一实体在不同块中可能有不同描述
• 同一关系可能被多次提取
• 需要保持数据一致性

算法流程：

async def merge_nodes_and_edges(chunk_results, knowledge_graph_inst):
# 步骤1: 按实体名分组
entity_groups = defaultdict(list)
for result in chunk_results:
for entity in result["entities"]:
entity_groups[entity["name"]].append(entity)
# 步骤2: 合并实体描述
for entity_name, entity_list in entity_groups.items():
# 收集所有描述
descriptions = [e["description"] for e in entity_list]
# 使用LLM总结（如果描述过多）
if len(descriptions) > 3:
merged_description = await summarize_descriptions(descriptions)
else:
merged_description = "\n".join(descriptions)
# 更新图谱
await knowledge_graph_inst.upsert_node(
entity_name,
{
"description": merged_description,
"entity_type": entity_list[0]["type"],
"source_id": GRAPH_FIELD_SEP.join([e["chunk_id"] for e in entity_list])
}
)
# 步骤3: 合并关系（类似逻辑）
# ...

关键设计：

• Map-Reduce总结：描述过多时分批总结再合并
• Source ID追踪：记录每个实体/关系来自哪些文本块
• 并发控制：使用keyed_lock确保同一实体的更新串行化

算法2: 查询检索流程

2.1 查询模式对比

2.2 Local模式详解

核心思路：从实体出发，找到相关文本块

async def kg_query_local(query, entities_vdb, text_chunks, param):
# 步骤1: 提取低层关键词
ll_keywords = await extract_keywords(query, level="low")
# 示例: ["张三", "职位", "工作内容"]
# 步骤2: 向量检索相关实体
entities = await entities_vdb.query(
query=" ".join(ll_keywords),
top_k=param.top_k  # 默认60
)
# 返回: [{"entity_name": "张三", "description": "...", "source_id": "chunk1,chunk2"}]
# 步骤3: 收集实体关联的文本块
chunk_ids = set()
for entity in entities:
chunk_ids.update(entity["source_id"].split(GRAPH_FIELD_SEP))
# 步骤4: 获取文本块内容
chunks = await text_chunks.get_by_ids(list(chunk_ids))
# 步骤5: 构造上下文
context = format_context(entities, chunks)
# 步骤6: LLM生成答案
answer = await llm_func(
prompt=PROMPTS["rag_response"].format(
context=context,
query=query
)
return answer

关键技术：

• 关键词提取：使用LLM从问题中提取实体名
• 向量相似度：通过embedding找到语义相关的实体
• Source ID追踪：快速定位实体出现的文本块

2.3 Global模式详解

核心思路：从关系出发，理解全局结构

async def kg_query_global(query, relationships_vdb, entities_vdb, param):
# 步骤1: 提取高层关键词
hl_keywords = await extract_keywords(query, level="high")
# 示例: ["组织架构", "管理层级", "部门关系"]
# 步骤2: 向量检索相关关系
relationships = await relationships_vdb.query(
query=" ".join(hl_keywords),
top_k=param.top_k
)
# 返回: [{"src": "张三", "tgt": "ABC公司", "description": "任职于", ...}]
# 步骤3: 获取关系涉及的实体
entity_names = set()
for rel in relationships:
entity_names.add(rel["src"])
entity_names.add(rel["tgt"])
entities = await entities_vdb.get_by_names(list(entity_names))
# 步骤4: 构造图谱上下文
context = format_graph_context(entities, relationships)
# 步骤5: LLM生成答案
answer = await llm_func(
prompt=PROMPTS["rag_response"].format(
context=context,
query=query
)
)
return answer

关键设计：

• 关系优先：通过关系理解实体间的连接
• 社区发现：可选地使用图算法找到实体社区
• 层次聚合：支持多跳关系的递归查询

2.4 Rerank优化

目的：对检索到的文本块重新排序，提升相关性

async def rerank_chunks(query, chunks, rerank_func):
# 步骤1: 准备重排序输入
rerank_input = [
{"query": query, "document": chunk["content"]}
for chunk in chunks
]
# 步骤2: 调用Rerank模型
scores = await rerank_func(rerank_input)
# 返回: [0.95, 0.82, 0.67, ...]
# 步骤3: 按分数排序
ranked_chunks = sorted(
zip(chunks, scores),
key=lambda x: x[1],
reverse=True
)
# 步骤4: 过滤低分块
filtered_chunks = [
chunk for chunk, score in ranked_chunks
if score > MIN_RERANK_SCORE  # 默认0.0
]
return filtered_chunks

5、代码结构分析

核心代码 vs 辅助代码

核心代码（必须理解）

1.lightrag.py (2500行)

• LightRAG.__init__: 初始化存储和配置
• ainsert: 文档插入主流程
• aquery: 查询主流程
• adelete_by_doc_id: 文档删除逻辑

2.operate.py (5000行)

• extract_entities: 实体抽取
• merge_nodes_and_edges: 知识融合
• kg_query: 图谱查询
• naive_query: 向量查询

3.base.py (1000行)

• BaseVectorStorage: 向量存储接口
• BaseGraphStorage: 图存储接口
• QueryParam: 查询参数定义

辅助代码（可选理解）

kg/* (存储实现)

• json_kv_impl.py: JSON文件存储
• postgres_impl.py: PostgreSQL存储
• neo4j_impl.py: Neo4j图数据库

llm/* (LLM适配器)

• openai.py: OpenAI API
• ollama.py: Ollama本地模型
• gemini.py: Google Gemini

api/* (Web服务)

• lightrag_server.py: FastAPI服务器
• routers/: API路由定义

6、关键流程详解

流程1: 文档插入完整流程

用户上传文档
↓
[1] 文档入队 (apipeline_enqueue_documents)
- 生成doc_id (MD5哈希)
- 检查重复
- 存储到full_docs
- 状态设为PENDING
↓
[2] 文本分块 (chunking_by_token_size)
- 按1200 token切分
- 100 token重叠
- 生成chunk_id
↓
[3] 并行处理块 (extract_entities)
- 每块调用LLM提取实体/关系
- 结果存入llm_response_cache
- 更新chunk的llm_cache_list
↓
[4] 知识融合 (merge_nodes_and_edges)
- 按实体名分组
- 合并描述（可能调用LLM总结）
- 更新图谱和向量库
- 使用keyed_lock保证一致性
↓
[5] 持久化 (_insert_done)
- 调用所有存储的index_done_callback
- JSON存储写入磁盘
- 状态设为PROCESSED
↓
完成

并发控制：

• max_parallel_insert: 控制同时处理的文档数（默认2）
• llm_model_max_async: 控制并发LLM调用数（默认4）
• keyed_lock: 确保同一实体的更新串行化

流程2: 查询完整流程

用户提问
↓
[1] 关键词提取
- 调用LLM提取高层/低层关键词
- 高层: 抽象概念 (如"组织架构")
- 低层: 具体实体 (如"张三")
↓
[2] 根据模式检索
├─ local模式
│   - 向量检索实体
│   - 获取关联文本块
│
├─ global模式
│   - 向量检索关系
│   - 获取关联实体
│
└─ hybrid模式
- 合并local+global结果
↓
[3] Rerank (可选)
- 使用Rerank模型重排序文本块
- 过滤低分块
↓
[4] Token控制
- 统计实体/关系/块的token数
- 按优先级截断（保证不超max_total_tokens）
↓
[5] 构造上下文
- 格式化实体、关系、文本块
- 添加引用信息
↓
[6] LLM生成答案
- 使用rag_response提示词
- 支持流式输出
↓
返回结果

Token控制策略：

# 默认配置
MAX_ENTITY_TOKENS = 6000      # 实体上下文
MAX_RELATION_TOKENS = 8000    # 关系上下文
MAX_TOTAL_TOKENS = 30000      # 总预算
# 动态分配
chunk_tokens = MAX_TOTAL_TOKENS - actual_entity_tokens - actual_relation_tokens

7、存储层设计

存储类型与职责

存储实例映射

# LightRAG中的存储实例
self.full_docs              # KV: 完整文档内容
self.text_chunks            # KV: 文本块内容
self.full_entities          # KV: 文档的实体列表
self.full_relations         # KV: 文档的关系列表
self.entity_chunks          # KV: 实体->块ID映射
self.relation_chunks        # KV: 关系->块ID映射
self.entities_vdb           # Vector: 实体向量
self.relationships_vdb      # Vector: 关系向量
self.chunks_vdb             # Vector: 文本块向量
self.chunk_entity_relation_graph  # Graph: 知识图谱
self.doc_status             # Status: 文档状态
self.llm_response_cache     # KV: LLM缓存

数据流转示例

插入时：

文档 → full_docs (KV)
↓
文本块 → text_chunks (KV) + chunks_vdb (Vector)
↓
实体提取 → chunk_entity_relation_graph (Graph) + entities_vdb (Vector)
↓
关系提取 → chunk_entity_relation_graph (Graph) + relationships_vdb (Vector)
↓
元数据 → full_entities (KV) + full_relations (KV)

查询时：

问题 → 关键词提取
↓
entities_vdb.query() → 相关实体
↓
chunk_entity_relation_graph.get_node() → 实体详情
↓
text_chunks.get_by_ids() → 文本块内容
↓
LLM生成答案

8、小白理解指南

类比1: LightRAG就像一个智能图书馆

传统RAG（普通图书馆）：

• 只有书架和书
• 找书靠关键词搜索
• 不知道书之间的关系

LightRAG（智能图书馆）：

• 有书架（文本块）
• 有索引卡（实体）
• 有关系网（知识图谱）
• 馆员（LLM）能理解你的问题，找到最相关的书和索引卡

类比2: 文档处理像做笔记

• 分块：把一本厚书分成章节（每章1200字）
• 提取：从每章提取关键人物和事件
• 整理：把所有章节的笔记合并，去重
• 建索引：制作人物关系图和事件时间线

类比3: 查询像问图书馆员

Local模式（问具体问题）：

• 你：“张三是谁？”
• 馆员：查索引卡→找到"张三"→翻出相关书页→总结答案

Global模式（问宏观问题）：

• 你：“公司的组织架构？”
• 馆员：查关系图→找到所有"任职"关系→画出组织图→解释

Hybrid模式（问复杂问题）：

• 你：“张三在公司的影响力？”
• 馆员：查索引卡（张三的详情）+ 查关系图（张三的关系网）→综合分析

关键概念速查

9、常见问题

Q1: 为什么要分块？ A: LLM有输入长度限制（如4K token），必须把长文档切小块处理。

Q2: 为什么要建知识图谱？ A: 纯文本检索只能找到"包含关键词"的段落，图谱能理解"张三和李四是同事"这种关系。

Q3: 向量数据库有什么用？ A: 快速找到语义相似的内容。比如搜"CEO"能找到"首席执行官"。

Q4: Rerank是什么？ A: 第一次检索可能不准，Rerank用更强的模型重新打分，把最相关的排前面。

Q5: 为什么需要缓存？ A: LLM调用很慢很贵，缓存能避免重复计算。比如同一个文本块的实体提取结果可以复用。

总结

LightRAG的核心优势

知识图谱：理解实体关系，支持复杂推理

多模式查询：local/global/hybrid适应不同问题

高效检索：向量+图谱双重索引

可扩展：支持多种存储后端（JSON/PostgreSQL/Neo4j）

生产就绪：完善的并发控制、错误处理、状态管理

学习路径建议

入门（1-2天）：

• 运行lightrag_openai_demo.py，理解基本流程
• 阅读base.py，理解核心接口
• 查看prompt.py，理解提示词设计

进阶（3-5天）：

• 阅读lightrag.py的ainsert和aquery方法
• 理解operate.py的extract_entities和kg_query
• 尝试修改提示词或查询参数

高级（1-2周）：

• 实现自定义存储后端
• 优化实体抽取算法
• 添加新的查询模式
• 集成到生产系统

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】

为什么要学习大模型？

我国在A大模型领域面临人才短缺,数量与质量均落后于发达国家。2023年，人才缺口已超百万，凸显培养不足。随着AI技术飞速发展，预计到2025年,这一缺口将急剧扩大至400万,严重制约我国AI产业的创新步伐。加强人才培养,优化教育体系,国际合作并进是破解困局、推动AI发展的关键。

大模型入门到实战全套学习大礼包

1、大模型系统化学习路线

作为学习AI大模型技术的新手，方向至关重要。 正确的学习路线可以为你节省时间，少走弯路；方向不对，努力白费。这里我给大家准备了一份最科学最系统的学习成长路线图和学习规划，带你从零基础入门到精通！

---

2、大模型学习书籍&文档

学习AI大模型离不开书籍文档，我精选了一系列大模型技术的书籍和学习文档（电子版），它们由领域内的顶尖专家撰写，内容全面、深入、详尽，为你学习大模型提供坚实的理论基础。

3、AI大模型最新行业报告

2025最新行业报告，针对不同行业的现状、趋势、问题、机会等进行系统地调研和评估，以了解哪些行业更适合引入大模型的技术和应用，以及在哪些方面可以发挥大模型的优势。

4、大模型项目实战&配套源码

学以致用，在项目实战中检验和巩固你所学到的知识，同时为你找工作就业和职业发展打下坚实的基础。

5、大模型大厂面试真题

面试不仅是技术的较量，更需要充分的准备。在你已经掌握了大模型技术之后，就需要开始准备面试，我精心整理了一份大模型面试题库，涵盖当前面试中可能遇到的各种技术问题，让你在面试中游刃有余。

适用人群

第一阶段（10天）：初阶应用

该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。

• 大模型 AI 能干什么？
• 大模型是怎样获得「智能」的？
• 用好 AI 的核心心法
• 大模型应用业务架构
• 大模型应用技术架构
• 代码示例：向 GPT-3.5 灌入新知识
• 提示工程的意义和核心思想
• Prompt 典型构成
• 指令调优方法论
• 思维链和思维树
• Prompt 攻击和防范
• …

第二阶段（30天）：高阶应用

该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。

• 为什么要做 RAG
• 搭建一个简单的 ChatPDF
• 检索的基础概念
• 什么是向量表示（Embeddings）
• 向量数据库与向量检索
• 基于向量检索的 RAG
• 搭建 RAG 系统的扩展知识
• 混合检索与 RAG-Fusion 简介
• 向量模型本地部署
• …

第三阶段（30天）：模型训练

恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。

到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？

• 为什么要做 RAG
• 什么是模型
• 什么是模型训练
• 求解器 & 损失函数简介
• 小实验2：手写一个简单的神经网络并训练它
• 什么是训练/预训练/微调/轻量化微调
• Transformer结构简介
• 轻量化微调
• 实验数据集的构建
• …

第四阶段（20天）：商业闭环

对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。

• 硬件选型
• 带你了解全球大模型
• 使用国产大模型服务
• 搭建 OpenAI 代理
• 热身：基于阿里云 PAI 部署 Stable Diffusion
• 在本地计算机运行大模型
• 大模型的私有化部署
• 基于 vLLM 部署大模型
• 案例：如何优雅地在阿里云私有部署开源大模型
• 部署一套开源 LLM 项目
• 内容安全
• 互联网信息服务算法备案
• …

学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。

如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】