一、整体工作流程

LightRAG 以检索增强生成（RAG） 为核心，通过文档处理（索引阶段） 与查询生成（检索阶段） 的闭环设计，融合知识图谱与向量检索提升响应准确性，具体流程如下：

1. 文档处理（索引阶段）

• • 多模态文档输入与拆分：支持文本、PDF、图像等多模态文档（通过 RAG-Anything 集成），自动拆分为文本块（Chunk），作为基础处理单元，拆分粒度可通过 chunk_token_size 等参数配置。
  • 实体与关系提取：基于 LLM 从每个文本块中并行提取实体（如人物、组织）和关系（如“隶属”“合作”），提取任务通过 LLM 队列调度，并发度由 llm_model_max_async 控制（默认 8 个并发）。
  • 实体与关系合并：单个文档的所有文本块处理完成后，合并重复或冲突的实体/关系（如同一实体的不同表述归一化），确保知识一致性，合并阶段优先级高于提取阶段。
  • 存储持久化：文本块、实体、关系分别存入向量存储（如 FAISS、pgvector）、知识图谱存储（如 Neo4J）和文档状态存储（跟踪处理进度）。

1. 查询与生成（检索阶段）

• • 用户查询输入：支持多种检索模式（naive 基础搜索、local 局部检索、global 全局检索、hybrid 混合检索等），可配置返回结果数量（top_k）、是否启用重排序（enable_rerank）等参数。
  • 双重检索机制：结合向量数据库（检索语义相关文本块）和知识图谱（检索实体关联关系），获取多维度上下文。
  • 上下文构建与生成：基于检索结果构建上下文（含实体、关系、文本块），调用 LLM 生成回答，确保输出锚定外部知识，减少幻觉。

二、检索机制

以下是整理后的LightRAG核心优势：

1. 引入图结构

通过图结构（节点代表实体、边代表实体关系）索引文本数据，能更好地捕捉和表示复杂依赖关系，提升上下文的连贯性与丰富性。

2. 综合信息检索

从全量文档中提取实体间相互依赖的完整上下文，弥补了传统RAG仅关注文本块（Chunk）局部信息、缺乏全局综合信息的不足。

3. 双层检索系统

结合**低层次（具体实体/属性）和高层次（广泛主题/概念）**的检索策略：

• 低层次检索：聚焦特定实体及其关系的精准信息；
• 高层次检索：覆盖广泛的主题信息；
  可满足不同类型的查询需求。

4. 增量更新算法

新数据到来时，系统会增量式更新知识图谱，无需重建整个索引，大幅提升数据处理效率。如果是不同领域的文档 要构建新的社区

5. 实体和关系提取

利用大语言模型自动识别文本中的实体与关系，生成键值对，优化检索过程。

6. 增强检索效率

相较于GraphRAG的社区遍历方法，LightRAG专注于实体和关系的检索，减少检索开销，提升图结构知识的检索效率，显著降低响应时间。

三、知识图谱的存储方式

LightRAG 支持多类型知识图谱存储后端，可按需配置，具体如下：

1. 默认存储

• • 采用 NetworkXStorage（基于 NetworkX 库），为内存级存储，不持久化数据，适用于测试、轻量场景或临时验证。

1. 持久化存储选项

• • Neo4J：企业级图数据库，支持高并发与复杂关系查询，通过环境变量（NEO4J_URI、NEO4J_USERNAME 等）配置连接，适合生产环境。
  • PostgreSQL + Apache AGE：借助 AGE 插件实现图存储，可与向量存储（pgvector）一体化部署，适合已有 PostgreSQL 基础设施的场景。
  • MongoDB：通过集合（Collections）存储实体与关系，适合轻量化图结构需求，支持与 KV 存储、向量存储共用实例。
  • Memgraph：兼容 Neo4j Bolt 协议的内存图数据库，查询速度快，适合对响应时延要求高的场景。

1. 配置方式

• • 初始化 LightRAG 时指定 graph_storage 参数，例如：

rag = LightRAG(
    working_dir="./data",
    graph_storage="Neo4JStorage"  # 切换为 Neo4J 存储
)
await rag.initialize_storages()  # 初始化存储连接

• • 数据库连接信息通过环境变量或配置文件（参考 env.example）指定，确保灵活性与安全性。

总结

LightRAG 通过“文档拆分→实体/关系提取→合并→存储”的索引流程构建多模态知识底座，结合向量检索的语义匹配与知识图谱的关系推理，实现精准高效的检索增强生成。知识图谱存储支持内存与持久化多选项，兼顾易用性与生产级需求，而混合检索模式则进一步提升了复杂查询场景下的响应质量。

二、LightRAG 支持的 6 种检索方式（查询模式）

所有检索方式通过 QueryParam(mode="xxx") 或前端 / WebUI 的「查询模式」配置，核心差异在于检索范围、使用的技术、数据来源：

检索模式	英文标识	核心逻辑	适用场景	依赖的存储 / 技术
基础检索	naive	无高级优化的「纯向量检索」，仅基于文本块向量做相似性匹配，无知识图谱参与	快速测试、简单文本检索	向量存储
本地检索	local	聚焦「上下文相关的实体 / 文本」，仅检索与查询强相关的局部信息，仅检索该实体 1~2 跳（hops）内的关联实体	精准小范围问答（如单文档）	向量存储 + 知识图谱（实体精准匹配）
全局检索	global	遍历「全量知识库」，检索所有相关的实体、关系、文本块检索该实体在全图谱中的所有关联实体（跳数无上限）	大范围 / 跨文档问答	向量存储 + 知识图谱（全量遍历）
混合检索	hybrid	融合 Local + Global，先局部精准检索，再全局补充，平衡精度与覆盖度	通用场景（默认模式）	向量存储 + 知识图谱 + 权重融合策略
混合增强	mix	「知识图谱 + 向量检索」深度融合，同时检索实体关系和语义相似文本	复杂多实体关联问答（如推理）	向量存储 + Neo4j / 图谱存储（核心依赖）
跳过检索	bypass	不执行任何检索，直接将查询传给 LLM	无需知识库的原生 LLM 问答	无（仅依赖 LLM）

各模式的关键细节：

1. Naive（基础检索）

• • 无知识图谱参与，仅做「文本块向量 Top-K 检索」；
  • 无 Rerank 优化（可手动开启），速度最快但精度最低；
  • 代码示例：rag.aquery("问题", param=QueryParam(mode="naive"))。

1. Local（本地检索）

• • 先通过查询提取核心实体，仅检索该实体「直接关联」的文本 / 关系；
  • 检索范围小，精度高，适合单文档 / 小知识库的精准问答。

1. Global（全局检索）

• • 不限制实体范围，遍历全量知识图谱 + 全量文本块向量；
  • 覆盖度最高，但速度稍慢，适合跨文档 / 多实体关联问答。

1. Hybrid（混合检索）

• • LightRAG 默认模式，权重分配 Local（70%）+ Global（30%）（可自定义）；
  • 先 Local 保证精度，再 Global 补充遗漏，平衡「速度 - 精度 - 覆盖度」。

1. Mix（混合增强）

• • 唯一深度融合「知识图谱 + 向量」的模式：① 先通过知识图谱检索实体 - 关系；② 再通过向量检索相似文本块；③ 融合两类结果后 Rerank；
  • 依赖 Neo4j 等高性能图谱存储，适合复杂推理（如「A 和 B 的关系？C 相关的 D 有哪些？」）。

1. Bypass（跳过检索）

• • 纯 LLM 问答，不检索任何知识库；
  • 用于对比「有 RAG」和「无 RAG」的回答差异。

三、检索的扩展配置（调优检索效果）

除了选择模式，还可通过参数调整检索行为：

1. Top-K 配置

• • top_k：知识图谱实体 / 关系的检索数量（仅非 naive 模式生效），默认 40；
  • chunk_top_k：文本块的检索数量（所有模式生效），默认 20；
  • 可通过环境变量 TOP_K/CHUNK_TOP_K 或前端输入框修改。

1. Rerank 重排序

• • 检索结果默认通过 Cohere/Jina/ 阿里云 Rerank 模型重排序；
  • 可通过 enable_rerank=False 关闭，或配置不同 Rerank 模型（如 BAAI/bge-reranker）。

1. 令牌数限制

• • max_entity_tokens/max_relation_tokens：限制实体 / 关系上下文的令牌数，避免上下文过长；
  • max_total_tokens：总上下文令牌数上限，防止 LLM 输入超限。

四、检索模式的使用方式

1. 代码中调用（Python）

python

运行

# 示例：使用 Mix 模式（知识图谱+向量融合）
resp = await rag.aquery(
    "唐僧有几个徒弟？",
    param=QueryParam(
        mode="mix",        # 指定检索模式
        top_k=50,          # 图谱实体检索数量
        chunk_top_k=25,    # 文本块检索数量
        enable_rerank=True # 开启重排序
    ),
)

2. Ollama API 调用（通过前缀）

发送查询时添加模式前缀，无需改代码：

plaintext

/mix 唐僧有几个徒弟？  # Mix 模式
/hybrid 公司的组织架构？ # Hybrid 模式
/bypass 1+1等于几？    # 跳过检索

3. WebUI 配置

在前端「查询设置」面板选择：

• 下拉框选择「Mix/Hybrid/Local 等」；
• 手动输入 top_k/chunk_top_k 调整检索数量；
• 支持重置为默认值（Mix 模式，top_k=40，chunk_top_k=20）。

五、各检索模式的性能对比

维度	naive	local	global	hybrid	mix	bypass
检索速度	最快	快	慢	中	中慢	极快
回答精度	最低	高	中	高	最高	无知识库支撑
知识覆盖度	低	低	最高	中高	中高	无
依赖图谱	❌	✅	✅	✅	✅✅	❌
适合数据量	小	小	大	中 - 大	大	无

mix 模式的混合核心逻辑

1. 并行触发两种检索

• • 向量检索：将用户查询转为向量，与知识库中的文本块向量做余弦相似度匹配，获取语义相关的文本块。
  • 知识图谱检索：从用户查询中提取核心实体，在图谱中检索该实体的多跳关联节点（实体 / 关系），并匹配这些节点对应的文本块。

1. 特征加权融合对两种检索得到的候选文本块，分别赋予不同权重：

• • 知识图谱检索结果：权重更高（因为实体关系是结构化知识，与查询的关联性更精准）。
  • 向量检索结果：权重次之（语义相似性是泛化匹配，可能存在冗余）。

1. 统一重排序（Rerank）融合后的候选文本块会传入重排序模型（如 bge-reranker-v2-m3），基于「查询 - 文本」的语义匹配度做二次打分排序，最终筛选出最相关的文本作为上下文。

mix 与 hybrid 模式的核心区别

很多人会混淆 mix 和 hybrid，两者的混合逻辑完全不同：

维度	mix 模式	hybrid 模式
混合对象	向量检索 + 知识图谱检索	局部检索（local） + 全局检索（global）
混合层级	特征层 + 结果层 深度融合	结果层 简单拼接
权重策略	支持自定义权重分配	固定权重（如 local 占 70%，global 占 30%）
核心优势	结构化知识与语义匹配深度结合，精度最高	平衡局部精准性与全局覆盖度，通用性强

总结

LightRAG 的检索机制核心是「模式化 + 可配置」：

基础场景用 naive/local，追求速度； 通用场景用 hybrid（默认），平衡精度与覆盖； 复杂推理用 mix，依赖知识图谱 + 向量融合； 纯 LLM 对比用 bypass； 所有模式均可通过 top_k/Rerank/令牌数 调优，适配不同数据量和精度需求。

GraphRAG与 LightRAG 检索机制的核心对比

对比维度	GraphRAG	LightRAG
核心依赖	必须依赖知识图谱+社区划分（Leiden/Louvain算法分组），无社区则无法运行。	可依赖知识图谱（local/global/mix模式），也可脱离图谱纯向量检索（naive模式）。
检索策略数量	4种：基础搜索（纯向量）、本地搜索（实体多跳）、全局搜索（社区摘要）、漂移搜索（全局+本地）。	6种：naive（纯向量）、local（实体局部）、global（全量图谱）、hybrid（局部+全局）、mix（向量+图谱融合）、bypass（无检索）。
图谱利用方式	以社区为核心，先按社区筛选，再遍历社区内实体关系，依赖预划分的社区结构。	以实体为核心，直接遍历实体的多跳关系，无强制社区划分（社区是可选的逻辑隔离单元）。
混合检索逻辑	漂移搜索（DRIFT）：先全局社区摘要→再本地实体遍历，是流程上的串行混合。	mix模式：同时触发向量检索+图谱检索→特征层加权融合→重排序，是特征上的并行混合。
社区的作用	社区是检索的基础单元，用于降低全图遍历的复杂度，必须预划分。	社区是知识库的隔离单元（类似文件夹），仅用于区分不同领域数据，与检索逻辑无关。
多跳推理能力	依赖社区内的实体路径，支持多跳，但跨社区推理需要额外的社区关联逻辑。	直接遍历全图实体关系，支持任意深度的多跳推理（通过max_depth参数控制）。
向量检索的定位	仅作为基础搜索的基线，核心检索依赖图谱/社区，向量是辅助。	向量检索是独立模式（naive），也可与图谱深度融合（mix），是核心能力之一。
检索效率	社区预划分降低了遍历成本，但社区间关联会增加开销，中等效率。	无强制社区，实体检索更直接；mix模式通过重排序优化效率，整体效率较高。
适用场景	宏观主题总结、社区内的关联推理（如“行业趋势分析”）。	复杂实体关系推理、多模态检索、通用问答（覆盖简单→复杂全场景）。

总结核心差异

• GraphRAG：是“社区驱动的图谱检索”，适合大规模知识库的宏观分析，但依赖预划分的社区结构，灵活性较弱。
• LightRAG：是“实体驱动的混合检索”，图谱与向量能力深度融合，社区仅用于数据隔离，更灵活适配不同场景。