RAG、GraphRAG 与 LightRAG：原理、架构与选型

第一章：RAG、GraphRAG 与 LightRAG 概述

定义

RAG（Retrieval-Augmented Generation，检索增强生成）

RAG 的核心思想是：先从外部知识库中检索与用户问题相关的信息，再将检索结果交给大模型生成答案。

传统 RAG 通常将文档切分成文本块，为文本块建立向量索引。用户提问时，将问题转换为向量，检索相似文本块，并把它们作为上下文提供给大模型。

它适合文档问答、知识库查询、产品手册检索等场景。

GraphRAG（Graph-based Retrieval-Augmented Generation，图增强检索生成）

GraphRAG 在检索流程中引入实体、关系和知识图谱。微软 GraphRAG 的典型实现还会对图进行社区发现，并生成不同层级的社区报告。

同时，它不会只保存抽取后的实体和关系：原始文本会被切分为 Text Unit（文本单元）并持久化，用于证据追溯，以及在 Basic / Local Search 中补充原文细节。

在索引侧，GraphRAG 通常会为实体描述建立向量入口；关系主要保存为 source、target、description 的关系记录或图边。Local Search 先向量召回实体，再通过实体结构读取关系。

它不仅关注某段文本与问题是否相似，还希望利用知识之间的关联，回答跨文档关系问题以及需要综合理解整个知识库的问题。

LightRAG（Lightweight Retrieval-Augmented Generation）

LightRAG 同样引入实体关系和知识图谱，但采用了不同的索引组织与检索设计。它将图结构与文本、向量等检索能力结合起来，并提供 Local、Global、Hybrid、Mix 等检索模式。

其设计重点之一是降低图增强检索的成本与复杂度，并支持面向持续更新的知识处理。

架构区别

RAG： 主要检索与问题语义相似的文本。
GraphRAG： 利用实体关系、社区结构和社区报告，增强局部关联分析与全局归纳。
LightRAG： 通过实体关系、文本关联和多种检索方式，兼顾局部事实与更广泛的关联信息。

传统 RAG 的应用范围最广。GraphRAG 与 LightRAG 则针对图增强检索的不同需求提供方案，不能仅凭框架名称判断哪一种使用得更多。

flowchart TB
    subgraph R["传统 RAG：以文本块为中心"]
        R1["原始文档"] --> R2["切块并建立文本向量索引"]
        R2 --> R3["问题向量检索相关文本块"]
        R3 --> R4["LLM 生成"]
    end

    subgraph G["GraphRAG：文本单元 + 图谱 + 社区报告"]
        G1["原始文档"] --> G2["文本切块"]
        G2 --> G3["构建 Text Unit：原文 + 来源"]
        G3 --> G3V["文本单元向量化"]
        G3V --> G3I["文本向量索引"]
        G3 --> G7["Basic / Local：读取原文证据"]
        G3I --> G7

        G2 --> G4["抽取实体与关系"]
        G4 --> G4E["实体记录 + 实体描述"]
        G4 --> G4R["关系记录 / 边：source + target"]
        G4E --> G4V["实体描述向量化"]
        G4V --> G4I["实体向量索引"]
        G4E --> G5["知识图谱：实体节点 + 关系边"]
        G4R --> G5
        G5 --> G6["社区发现与报告生成"]
        G4I --> G8["Local：先实体向量召回 → 再查关系结构"]
        G5 --> G8
        G6 --> G9["Global：综合社区报告"]
        G7 --> G10["LLM 生成"]
        G8 --> G10
        G9 --> G10
    end

    subgraph L["LightRAG：文本 + 图谱 + 双向图检索"]
        L1["原始文档"] --> L2["文本切块"]
        L2 --> L3["保存文本块并建立文本索引"]
        L2 --> L4["抽取实体、关系与描述"]
        L4 --> L5["图结构：实体节点 + 关系边"]
        L4 --> L6["实体向量：定位入口实体"]
        L4 --> L6R["关系向量：匹配入口关系"]
        L3 --> L7["文本检索"]
        L5 --> L8["Local：先找实体 → 再找关系"]
        L6 --> L8
        L5 --> L9["Global：先找关系 → 再找实体"]
        L6R --> L9
        L7 --> L10["补充文本与图关联"]
        L8 --> L10
        L9 --> L10
        L10 --> L11["组合检索结果"]
        L11 --> L12["LLM 生成"]
    end

注：这是用于理解设计差异的简化图，并非三个框架逐节点对应的完整执行流程。GraphRAG 的典型 Local 检索是 先通过实体描述向量召回实体，再按实体 ID / 名称读取关系记录或图边；关系主要作为结构化边保存，而不是先做关系向量召回。LightRAG 则同时保留实体向量与关系向量：Local 走“实体 → 关系”，Global 走“关系 → 实体”。

第二章：GraphRAG

2.1定义

GraphRAG 的核心思想是：将非结构化文本转化为实体关系图，并利用图结构及其社区总结来增强检索。

传统 RAG 主要保留文本片段之间的语义相似性，而图增强方案还希望显式表达知识之间的关系。

2.1.1 核心概念

1. Ontology：本体

本体用于描述系统希望识别哪些实体类型、关系类型，以及这些结构应如何组织。

例如，一个运维知识库可以定义：

实体类型：服务、故障、发布变更、告警。
关系类型：调用、依赖、导致、发生于。

本体可以理解为知识抽取的结构化约束，但并不是所有 GraphRAG 配置都必须预先提供一套固定本体；具体抽取方式取决于配置和提示词。

2. Entity：实体

实体是从文本中识别出来的具体对象。

例如：

订单服务
库存服务
库存扣减
超时故障

实体通常会包含名称、类型、描述，以及与原文或相关索引记录之间的关联。

3. Relationship：关系

关系描述实体之间的联系。

例如：

订单服务 → 调用 → 库存服务
库存服务 → 执行 → 库存扣减
库存服务 → 出现 → 超时故障

将实体作为节点、关系作为边，就可以形成知识图谱。

4. Knowledge Graph：知识图谱

知识图谱把抽取出的实体与关系组织成图结构。

它不仅记录“订单服务”和“库存服务”分别是什么，还显式记录二者之间存在调用关系。

这样，当用户询问某个服务发生故障会影响哪些系统时，检索过程就可以利用已建立的关系寻找关联知识。

5. Community：社区

在微软 GraphRAG 的典型索引流程中，会使用 Leiden 等方法对知识图谱进行分层社区发现。

社区不是人为随意分组的标签，而是社区发现算法基于图结构得到的群组。

例如，一组紧密关联的订单、库存、支付服务及其故障记录，可能形成某个社区。

社区的具体划分结果取决于图结构、算法和参数，不一定与业务部门或系统边界一致。

6. Community Report：社区报告

社区报告是对某个社区及其关联信息进行总结后形成的文本。

它可以概括：

社区涉及哪些主要系统。
这些系统之间存在什么关联。
反复出现哪些故障。
有哪些值得关注的趋势或问题。

社区报告的重要作用是将大量细粒度的图信息转化为适合大模型阅读的综合性上下文。

7. Embedding：向量表示

向量表示将文本单元、实体描述等转换为向量，使系统能够进行语义相似度检索。在 GraphRAG 的典型 Local 流程中，检索入口是实体描述向量；关系主要保存在边/关系记录中，通过实体关联读取。

需要注意，GraphRAG 的不同检索模式使用的索引并不完全相同。不能认为所有模式都只进行向量检索，也不能认为每种模式都会读取所有数据。

2.1.2 核心概念之间的关系

flowchart TD
    A["原始文档"] --> A1["文本切块"]
    A1 --> T1["Text Unit：原文 + 来源"]
    T1 --> T2["持久化文本单元"]
    T1 --> T3["文本单元向量化"]
    T3 --> T4["文本向量索引"]

    A1 --> B["抽取实体与关系"]
    B --> E1["实体记录 + 实体描述"]
    B --> R1["关系记录 / 边<br/>source + target + description"]
    E1 --> E2["实体描述向量化"]
    E2 --> E3["实体向量索引"]
    E1 --> C["知识图谱"]
    R1 --> C
    C --> D["社区发现"]
    D --> E["社区报告"]

    T2 --> F0["Basic / Local：回溯原文证据"]
    T4 --> F0
    E3 --> F["Local Search：先做实体向量召回"]
    C --> F2["再按实体查关系边与邻近实体"]
    F --> F2
    F2 --> H
    E --> G["Global Search：综合社区报告"]
    F0 --> H
    G --> H
    H --> I["LLM 生成答案"]

关键补充一：GraphRAG 不只存实体、关系和社区。文本切块后的 Text Unit（文本单元） 也会被持久化，并与实体、关系和社区报告建立来源关联，供 Basic / Local Search 回溯原文、补充事实证据。

关键补充二：GraphRAG 的 Local 入口是 实体描述向量，不是关系向量。它先召回候选实体，再通过实体的 source / target 关系记录或图边找到关系与邻近实体。关系主要用于结构化遍历，不应该和“实体、文本单元一起做向量召回”混写。

补充理解：文本单元、实体描述和社区报告可以分别建立向量索引。这里的“文本单元持久化”是内容数据；文本单元向量、实体描述向量才是辅助检索索引，两者不是一回事。

图中的箭头表达的是概念之间的主要关系，不代表每一个框都对应固定的数据库表或独立服务。

2.1.3 数据存储

微软 GraphRAG 的标准索引流程会产生实体、关系、文本单元、社区、社区报告等数据。其默认索引产物主要以 Parquet 表的形式保存，向量则写入配置的向量存储。它并不要求一定部署独立的 Neo4j 图数据库。(GitHub Microsoft)

理解这部分，需要区分三个层次：

层次	作用	示例
逻辑数据模型	描述系统中有哪些知识对象	文本单元、实体、关系、社区、社区报告
持久化数据	保存索引处理结果	Parquet 文本/实体/关系/社区表、数据库记录、向量存储
检索索引	加速在线查询	文本单元向量、实体描述向量、社区报告向量；关系边/关系表则用于结构化遍历

Text Unit 不是“抽取完就可以丢掉”的临时数据。 它既是原文追溯依据，也是 Basic Search 和 Local Search 补充细节时的重要上下文；实体与关系可以指向它，社区报告也可以通过来源信息继续向下追溯。

关系也不是与实体同级的向量入口。 在这套典型实现中，关系以 source、target、description 等字段保存为关系记录或图边；Local Search 先通过实体向量找到实体，再利用实体 ID / 名称在关系结构中找到相关关系。这样“先量化实体，再顺着实体结构找关系”的路径才不会被误解成“实体和关系一起向量化”。

逻辑上存在知识图谱，不等于物理上一定使用图数据库。

例如，知识图谱中的实体与关系可以通过结构化表保存。应用程序读取节点与边的数据后，也可以在内存中完成图遍历或其他图操作。

如果生产环境需要高效执行复杂图查询，也可以选择 Neo4j 等专门的图数据库。但是否采用，应根据数据规模、查询模式、并发量和维护需求决定。

2.2 离线索引构建

GraphRAG 的离线阶段负责把原始文档转换为在线检索可以使用的结构化索引。

以下统一用运维知识库中的一个经典问题作例子：“订单服务为什么最近频繁出现请求超时？” 知识库可能包含架构说明、故障排查记录和发布变更记录。图中的实体与关系用于串联这些记录，原文则保留具体时间、指标和现象。

微软 GraphRAG 的标准流程包括实体、关系及关键声明抽取、社区发现、社区摘要与报告生成，以及文本向量化等环节。具体流程可通过配置调整。(GitHub Microsoft)

flowchart TD
    A["原始文档"] --> B["文本切块"]

    subgraph TEXT["文本构建线：保留原文与来源"]
        B --> T1["Text Unit：原文 + 来源"]
        T1 --> T2["持久化文本单元<br/>Parquet / 数据库"]
        T1 --> T3["文本单元向量化"]
        T3 --> T4["文本向量索引"]
    end

    subgraph GRAPH["图谱构建线：实体与关系分开处理"]
        T1 --> G1["LLM 抽取实体与关系"]
        G1 --> G2["实体记录 + 实体描述"]
        G1 --> G3["关系记录 / 边<br/>source + target + description"]

        G2 --> G4["实体描述向量化"]
        G4 --> G5["实体向量索引<br/>供 Local 先召回实体"]
        G2 --> G6["知识图谱：实体节点"]
        G3 --> G6

        G6 --> G7["社区发现"]
        G7 --> G8["生成社区报告"]
        G8 --> G9["报告持久化 / 可选向量化"]
    end

    T2 -. "来源关联" .-> G2
    T2 -. "来源关联" .-> G3

这张图把 GraphRAG 的离线构建拆成两条并行链路：

文本构建线： 原始文档 → 文本切块 → Text Unit（原文与来源）→ 文本单元持久化 → 文本单元向量化 → 文本向量索引。它负责保留原文证据，供 Basic Search 和 Local Search 回溯细节。
图谱构建线： Text Unit → 抽取实体与关系 → 实体记录、关系记录分别落库 → 实体描述向量化 → 构建知识图谱 → 社区发现 → 社区报告。

这里必须分清：GraphRAG 的向量入口主要是实体描述，不是关系。 关系以 source、target、description 等字段保存为边或关系记录；Local Search 先通过实体向量召回实体，再按实体 ID / 名称查关系结构。

除此之外，系统还会为检索需要建立辅助索引，例如：

文本块向量：帮助检索原文片段。
实体描述向量：帮助从问题中定位相关实体。
社区报告向量：帮助定位与问题相关的社区报告。

这些向量索引服务于不同的在线检索模式，其中 关系不作为与实体并列的向量入口。需要区分：文本单元本身是持久化内容；文本单元向量和实体描述向量才是辅助检索索引。

下面使用同一份业务文档，展示各阶段究竟产生什么数据。

2.2.1 原始文档、文本切块与文本构建流程

假设原始文档内容如下：

“订单服务调用库存服务完成库存扣减。当库存服务响应超时，订单服务可能出现处理失败。近期库存服务发生过一次发布变更，变更后超时问题出现得更加频繁。”

切块后，可能形成如下文本单元。

{
  "text_unit_id": "tu_001",
  "text": "订单服务调用库存服务完成库存扣减。当库存服务响应超时，订单服务可能出现处理失败。",
  "document_id": "doc_001"
}

以上是为了说明数据结构而编写的示意 JSON，并非微软 GraphRAG 的完整官方输出格式。

Text Unit 是后续抽取、追溯和索引构建的分析单元。它可以保留原文来源，帮助系统将抽取出的实体和关系与原始文本关联起来。GraphRAG 的文本构建流程可以单独表示为：

flowchart LR
    A["原始文档"] --> B["文本切块"]
    B --> C["Text Unit<br/>原文 + document_id + text_unit_id"]
    C --> D["持久化文本单元<br/>Parquet / 数据库"]
    C --> E["文本单元向量化"]
    E --> F["文本向量索引"]
    C --> G["作为实体与关系抽取的输入"]
    D --> H["Basic / Local: 回溯原文"]
    F --> H
    G -. "来源追踪" .-> I["实体 / 关系 / 社区报告"]

这条文本构建线不会因为抽取出了实体和关系而消失。相反，文本单元会一直保留，并通过 text_unit_ids 等来源关系支撑原文回溯。实体描述可以向量化，关系则主要以边/关系记录供遍历；两者不要写成同一个向量化步骤。

2.2.2 实体与关系抽取

LLM 根据文本识别出实体和关系。

示意实体数据：

[
  {
    "name": "订单服务",
    "type": "服务",
    "description": "负责处理订单业务"
  },
  {
    "name": "库存服务",
    "type": "服务",
    "description": "负责执行库存相关操作"
  },
  {
    "name": "超时故障",
    "type": "故障",
    "description": "库存服务响应超时，可能导致订单处理失败"
  }
]

示意关系数据：

[
  {
    "source": "订单服务",
    "target": "库存服务",
    "description": "订单服务调用库存服务执行库存扣减"
  },
  {
    "source": "库存服务",
    "target": "超时故障",
    "description": "库存服务发生响应超时"
  },
  {
    "source": "超时故障",
    "target": "订单服务",
    "description": "超时可能导致订单处理失败"
  }
]

这里需要注意：实体和关系都是从文本中推断、抽取出来的结构化结果，不是原文中天然存在的数据库记录。

抽取结果可能遗漏信息，也可能把含糊表达识别错误。因此，生产系统需要关注抽取质量、来源追溯和数据验证。

更重要的是，实体和关系在后续索引中的处理方式不同：实体描述可以生成 Embedding，进入实体向量索引；关系主要保留 source、target、description 等结构信息，作为边或关系记录存储。Local Search 找到实体后，再通过这些实体的关联关系读取边，而不是先对关系做向量召回。

2.2.3 构建知识图谱

抽取完成后，系统将实体作为节点、关系作为边组织起来。

flowchart LR
    A["订单服务"] -->|"调用"| B["库存服务"]
    B -->|"发生"| C["超时故障"]
    C -->|"可能导致处理失败"| A

    T1["文本单元 tu_001<br/>订单服务调用库存服务"]
    T2["文本单元 tu_002<br/>库存服务响应超时"]
    T1 -.->|"原文关联"| A
    T1 -.->|"原文关联"| B
    T2 -.->|"原文关联"| B
    T2 -.->|"原文关联"| C

实体与关系是图结构，文本单元是它们的事实来源。GraphRAG 会保存这种来源关联，因此从图检索回到原文时，仍然能找到具体记录，而不是只剩抽取后的实体名称。

这里的边对应关系记录。GraphRAG 的典型 Local 检索不会先把边向量化再找关系，而是先用问题向量匹配实体描述，定位实体，再按实体关联读取边和邻近实体。

通过图结构，可以从一个实体出发寻找直接关联对象。

例如，从“库存服务”出发，可以发现它与订单服务之间存在调用关系，也可以找到与它相关的超时故障。

但要注意：图中存在路径，只说明索引中记录了相应关联，并不意味着系统已经证明了严格的因果关系。

2.2.4 社区发现

当知识库中有大量实体与关系时，单纯遍历整张图并不总是适合回答全局问题。

GraphRAG 因此可以对图进行社区发现，识别关联紧密的实体群组。

例如，规模更大的知识库中可能存在：

订单处理相关实体。
库存管理相关实体。
支付与结算相关实体。
多个服务共同涉及的故障与变更实体。

社区划分由图结构和算法决定，不应简单理解为按照服务名称或业务部门分组。

2.2.5 生成社区报告

社区发现之后，GraphRAG 可以对不同层级的社区生成摘要和报告。

示意报告：

订单处理与库存管理存在紧密关联。订单服务依赖库存服务完成库存扣减。当库存服务发生响应超时时，订单处理可能失败。相关故障分析应进一步检查服务调用链、超时配置和近期发布变更。

这个报告只是为了演示数据流而编写的示例，并不代表社区报告一定会生成上述内容。

社区报告将多个实体和关系组织成更容易阅读的文本，有助于后续对较大范围知识进行归纳。

2.2.6 向量化与索引持久化

完成相应的索引构建后，系统会持久化相关数据，包括：

文本单元及其来源信息：保留原文、文档来源及可追溯关联。
文本单元向量：支持原文语义检索和证据回找。
实体记录及实体描述向量：实体描述进入向量索引，作为 Local Search 的入口。
关系记录 / 边：保存 source、target、description 等结构，供根据实体查关系。
社区及社区报告：用于全局归纳；报告本身也可建立向量索引。

这里不要把“实体向量”和“关系向量”合并表述。GraphRAG 的典型 Local 流程是：问题 → 实体描述向量召回实体 → 用实体结构查关系边 → 回溯文本单元。

微软 GraphRAG 默认将索引产物保存为 Parquet 表，向量存储则由配置决定。Parquet 是列式文件格式，并不是图数据库。(GitHub Microsoft)

至此，离线索引构建完成。

2.3 在线检索

离线阶段负责建立知识索引，在线阶段则根据用户问题选择合适的检索路径。

微软 GraphRAG 的查询引擎提供 Local Search、Global Search、DRIFT Search 和 Basic Search 等模式。它们在使用的数据、检索过程及适合的问题类型上有所区别。(GitHub Microsoft)

flowchart TD
    A["用户问题"] --> B{"选择检索模式"}
    B --> C["Local：实体向量召回 → 再查关系结构与文本"]
    B --> D["Global：社区报告（文本）→ 归纳"]
    B --> E["Basic：直接检索文本单元"]
    B --> F["DRIFT：社区报告 → 实体/关系局部探索"]
    C --> G["组织检索上下文"]
    D --> G
    E --> G
    F --> G
    G --> H["LLM 生成答案"]

为了看清数据到底怎么流转，下面重点展开 Local Search；其他模式先保留各自最关键的区别，不再把所有内部索引都塞进一张图里。

这是检索模式的概念总图。各模式的具体内部步骤有所不同，不能把它理解为每个模式都执行相同的数据查询。

2.3.1 Local Search：局部检索

适合问题：围绕具体实体，查找它的关联对象、属性及相关事实。

其典型检索方向是 先实体、后关系：先定位候选实体，再从实体出发沿关系边扩展，最后回到相关文本单元补充证据。

继续使用前面的例子：

订单服务为什么最近频繁出现请求超时？

假设图谱中有以下关系：

订单服务 ──调用──> 库存服务 ──依赖──> MySQL
                         └──使用──> 数据库连接池

Local Search 的典型数据流可以简化为：

flowchart TD
    A["用户问题"] --> B["问题向量化"]
    B --> C["在实体向量索引中匹配实体描述"]
    C --> D["定位候选实体：订单服务、库存服务"]
    D --> E["用实体 ID / 名称查询关系记录或图边"]
    E --> F["得到关系与邻近实体"]
    F --> G["通过 text_unit_ids 等来源关联回文本单元"]
    G --> H["组织上下文"]
    H --> I["LLM 生成答案"]

具体可以理解为：

先向量化实体： 将问题转换为向量，与实体描述向量进行语义匹配，找出可能相关的实体。实体描述向量是实体说明文字的向量表示，不是关系向量。
再通过实体查关系： 用候选实体的 ID / 名称查询关系记录或图边，获取相关关系和邻近实体，例如订单服务调用库存服务。关系在这一步通过结构关联被读取，而不是先做关系向量召回。
补充原文证据： 通过文本单元与实体、关系的来源关联回原文，找到“连接池使用率达到 98%”或“近期调整过连接池配置”等具体记录。
生成答案： 将实体、关系和相关原文组织为上下文，交给 LLM 综合回答。

因此，Local Search 不等于“只做一次向量检索”，也不等于“只遍历图谱”。它会结合图结构与文本上下文。实际执行细节会随 GraphRAG 版本和配置变化。

2.3.2 Global Search：全局检索

适合问题：需要对整个知识库或大范围知识进行总结、归纳和分析。

例如：

知识库中反复出现的系统故障有哪些？它们有哪些共同特点？

如果只检索几个相似文本块，可能难以覆盖大量文档中的共同主题。

GraphRAG 的 Global Search 会利用社区报告进行全局分析。其典型实现采用 Map-Reduce 思路：先对相关报告进行分阶段分析，再汇总中间结果形成答案。

可以简化为：

flowchart TD
    A["用户问题"] --> B["社区报告集合"]
    B --> C["分批分析报告"]
    C --> D["生成中间答案"]
    D --> E["汇总与归纳"]
    E --> F["最终答案"]

这里的关键是：先利用社区报告压缩、组织大范围知识，再进行归纳，而不是直接把整个知识库原文塞进上下文。

不过，Global Search 通常需要处理较多报告，因此可能产生较高的 LLM 调用和 Token 成本。

2.3.3 Basic Search：基础检索

适合问题：答案主要存在于某些具体文本片段中，不需要复杂的图关系分析。

例如：

原始文档是如何描述库存服务超时问题的？

Basic Search 采用更接近传统 RAG 的检索方式，根据问题检索相关文本片段，再交给 LLM 生成答案。

它适用于简单的文档事实查询，也可以作为图增强检索的基础对照方案。

2.3.4 DRIFT Search：结合全局背景与局部探索

DRIFT 的全称是 Dynamic Reasoning and Inference with Flexible Traversal。

它试图结合全局信息与局部探索：先利用语义相关的社区报告建立初步背景，再通过后续问题和局部检索逐步扩展信息。

例如：

库存服务近期为什么频繁超时？哪些相关变更可能值得排查？

系统可以先从相关社区报告获取背景，再围绕库存服务、超时故障和变更记录进一步探索。

DRIFT 的特点是利用社区信息拓宽局部检索的起点，并通过探索过程补充更具体的事实。(GitHub)

需要注意，DRIFT 不只是把 Local Search 与 Global Search 的结果简单拼接，其实际探索流程和中间结果组织更为复杂。

四种模式如何选择？

模式	主要检索思路	适合的问题
Local	围绕具体实体获取关联信息	某服务依赖什么？故障会影响谁？
Global	利用社区报告进行全局归纳	整个知识库中有哪些共性问题？
Basic	直接检索相关文本片段	原文如何描述某个问题？
DRIFT	从全局背景出发进行局部探索	某个问题的背景、关联和细节是什么？

2.4 GraphRAG 的优势与局限

优势

关联能力更强。 实体与关系有助于发现跨文档、跨实体的联系。
支持全局归纳。 社区发现与社区报告可以将大量细粒度信息组织成更高层级的总结。
检索方式更丰富。 可以根据具体实体查询、全局问题分析等不同需求选择检索模式。

局限

索引成本较高。 实体关系抽取、社区发现和社区报告生成都可能带来额外的计算及 LLM 调用成本。
维护复杂度较高。 除了原始文本，还需要管理图结构、社区及相关报告等索引产物。
更新可能影响较大范围。 修改一条关系可能影响局部图结构，也可能改变社区划分及其报告。

增量更新：为什么不只是替换一段文本？

假设原先的关系是：

订单服务 ──调用──> 库存服务

后来系统架构调整，订单服务改为调用库存网关：

订单服务 ──调用──> 库存网关 ──调用──> 库存服务

这次变更可能涉及：

原有关系是否仍然有效。
新增实体及其关系。
相关文本和索引是否需要更新。
如果图结构变化影响社区划分，相关社区报告是否需要重新计算。

这并不意味着每次修改都必须重建整张图。实际需要重算的范围取决于更新策略、索引依赖和具体实现。

但如果系统不能正确识别旧关系失效，就可能出现新旧知识同时存在的问题。

因此，GraphRAG 的更新设计不仅要考虑新增数据，还要考虑关系失效、社区变化和报告一致性。

第三章：LightRAG

3.1 定义

LightRAG 的核心思路同样是利用实体与关系组织知识，但它采用了不同于微软 GraphRAG 的索引与检索设计。

其公开实现将知识图谱与向量检索结合起来，并通过多种查询模式在局部实体、广泛关系和原始文本等信息之间进行检索。(GitHub)

其中最关键的区别之一是图检索方向：

Local：先找实体，再找关系。 从问题定位入口实体，再沿关系边扩展到邻近实体和相关文本，方向是 实体 → 关系。
Global：先找关系，再找实体。 从问题匹配关系描述或关系向量，再回溯这条关系连接的实体及其上下文，方向是 关系 → 实体。

3.1.1 核心概念

1. Entity：实体

从文本中识别出来的具体对象，例如订单服务、库存服务和超时故障。

实体通常具有名称、描述、类型等信息。

2. Relationship：关系

用于表达实体之间的关联，例如订单服务调用库存服务。

LightRAG 会利用实体和关系构建图结构，使在线检索可以根据相关实体或关系寻找关联知识。

3. Knowledge Graph：知识图谱

实体是节点，关系是边。

图结构可以帮助系统获取文本中分散的关联信息，而不必完全依赖文本向量相似度。

4. Text Chunks：文本块

文本块保存原始文档中的具体内容。

它们与实体和关系相互补充：图结构提供关联信息，原始文本提供更完整的上下文和细节。

5. 低层级与高层级检索

LightRAG 论文提出双层级检索思路，可以粗略理解为：

低层级（Local 的典型方向）： 先定位具体实体，再查它的关系与邻近实体，即 实体 → 关系。
高层级（Global 的典型方向）： 先匹配更广泛的关系，再回溯关系两端的实体及其上下文，即 关系 → 实体。

这里的“层级”不是指数据库中一定存在两层物理结构，也不能直接等同于 GraphRAG 的 Local Search 和 Global Search。真正重要的是 LightRAG 同时保留实体向量与关系向量，因此可以在两种方向之间切换。

LightRAG 的具体检索模式还会根据不同的数据索引进行组合。

6. 多类存储

LightRAG 将不同用途的数据组织到不同的逻辑存储中。其官方实现主要涉及四类存储：

存储类型	主要职责	数据示例
KV Storage	保存文本、抽取结果、缓存等键值数据	文本块、抽取结果、LLM 缓存
Vector Storage	保存向量及其检索索引	文本块、实体、关系的向量
Graph Storage	保存知识图谱	节点与边
Document Status Storage	管理文档处理状态	文档 ID、处理状态

实际支持的后端及其适用范围会随版本变化。官方仓库列出的选择包括 PostgreSQL、MongoDB、OpenSearch，以及用于向量或图存储的专用后端等。默认的内存存储实现主要用于小规模测试和开发，不应直接当作生产部署方案。(GitHub)

flowchart TD
    A["原始文档"] --> B["文本切块"]

    B --> C["保存文本块与原文关联"]
    C --> D["KV Storage"]
    C --> E["文本块向量化"]
    E --> H["Vector Storage"]

    B --> F["LLM 抽取实体、关系与描述"]
    F --> F1["实体与实体描述"]
    F --> F2["关系与关系描述"]
    F1 --> G["构建知识图谱：实体节点 + 关系边"]
    F2 --> G
    G --> I["Graph Storage"]
    F1 --> J1["实体描述向量化"]
    F2 --> J2["关系描述向量化"]
    J1 --> H
    J2 --> H

    D --> K["在线检索"]
    H --> K
    I --> K
    K --> L["组织上下文"]
    L --> M["LLM 生成"]

可以把它记成两条互补的数据处理路径：一条保留文本原文，另一条从同一批文本中抽取实体和关系。其中实体向量主要服务于 Local 的“先实体、后关系”，关系向量主要服务于 Global 的“先关系、后实体”。文本、图结构及向量索引随后在在线检索时协同使用。

这张图展示的是 LightRAG 的逻辑数据流和存储职责，不意味着四类存储一定部署成四个独立数据库。

例如，生产环境可以通过一个 PostgreSQL 部署承载多类存储，也可以根据吞吐量、数据规模及运维要求组合不同的后端。

与 GraphRAG 的关键区别

两者都会抽取实体和关系，也都会使用图结构与语义检索，但设计重点不同。

GraphRAG 的典型索引流程包含社区发现与社区报告生成，并以这些结构支持全局搜索。
LightRAG 的典型流程侧重实体关系图、文本关联及多类检索索引，不依赖 GraphRAG 式的社区报告生成流程。
LightRAG 会分别索引实体和关系：Local 用实体入口向关系扩展，Global 用关系入口回溯实体；这是它区别于“只有实体检索”或“只有文本检索”的核心设计。

这也是为什么不能直接把两者的架构图画成完全相同的流程。

3.2 离线索引构建

LightRAG 的离线阶段将原始文档转换为实体关系图、文本数据和相应的向量索引。

继续使用同一个问题——“订单服务为什么最近频繁出现请求超时？”——来观察数据如何流转：文本块一方面被保留下来供原文检索，另一方面被用于抽取实体和关系，形成图结构。这样检索时既能看到“订单服务调用库存服务”的关联，也能找回“连接池使用率达到 98%”之类的原文细节。

与 GraphRAG 相比，它的典型构建流程不以社区发现和社区报告生成作为必经步骤，而是侧重图结构、文本与多类索引的组织。

flowchart TD
    A["原始文档"] --> B["文本切块"]

    B --> C["保存原始文本块"]
    C --> D["KV Storage"]
    B --> E["文本块向量化"]
    E --> H["Vector Storage"]

    B --> F["LLM 抽取实体、关系与描述"]
    F --> F1["实体与实体描述"]
    F --> F2["关系与关系描述"]
    F1 --> G["构建或更新知识图谱：实体节点 + 关系边"]
    F2 --> G
    G --> I["Graph Storage"]
    F1 --> J1["实体向量化"]
    F2 --> J2["关系向量化"]
    J1 --> H
    J2 --> H

    D --> K["在线检索可用的数据"]
    H --> K
    I --> K

这张图只保留最重要的数据流。要重点看到：关系不是只作为图谱里的边存在，它还会生成关系描述并建立关系向量，供 Global 检索“先找关系，再回溯实体”。文档处理状态等辅助信息仍会由相应存储管理，但不放进主图，避免干扰对核心流程的理解。

3.2.1 文本切块与实体关系抽取

继续使用相同的业务文档：

文本切块之后，LightRAG 会利用 LLM 抽取实体、关系和相关描述，并整理为框架内部使用的数据。

下面仍然使用示意数据：

{
  "chunk_id": "chunk_001",
  "content": "订单服务调用库存服务完成库存扣减。",
  "entities": [
    {
      "name": "订单服务",
      "type": "服务"
    },
    {
      "name": "库存服务",
      "type": "服务"
    }
  ],
  "relationships": [
    {
      "source": "订单服务",
      "target": "库存服务",
      "description": "订单服务调用库存服务"
    }
  ]
}

需要强调：这是为了理解数据之间的关联而编写的示意结构，并不是 LightRAG 源码中所有实体、关系和文本记录共同采用的统一 JSON 格式。

实际实现会将抽取结果整理到相应的数据结构和存储后端。

3.2.2 构建知识图谱

实体和关系被整理后，系统会创建或更新相应的图结构。

例如：

flowchart LR
    A["订单服务"] -->|"调用"| B["库存服务"]
    B -->|"发生"| C["超时故障"]
    D["发布变更"] -->|"可能相关"| C

这张图用于展示关联关系，不代表 LLM 一定会从原文抽取出所有这些边。尤其是“发布变更可能导致超时”这样的因果关系，需要有足够的文本证据，不能仅凭时间先后自动认定。

3.2.3 构建向量索引与持久化数据

LightRAG 会为相应内容建立向量索引，并将文本块、实体、关系及其相关数据保存到相应的存储中。

例如：

文本块用于直接检索原始内容。
实体向量可以帮助 Local 先找到与问题语义相关的实体，再沿关系扩展。
关系向量可以帮助 Global 先找到与问题相关的关系描述，再回溯这条关系连接的实体。
图结构用于获取实体及关系之间的关联。
KV 存储可以保存文本块、抽取结果和缓存等数据。

这样，在线检索时就不必只在原始文本上做向量搜索，还可以结合图结构与其他索引信息。

与 GraphRAG 的离线构建对比

环节	GraphRAG	LightRAG
文本处理	文本切块	文本切块
实体关系抽取	是	是
图结构构建	是	是
社区发现	标准流程的重要环节	不属于其典型必经流程
社区报告生成	标准流程的重要环节	不属于其典型必经流程
多类索引	文本单元向量、实体描述向量、社区报告向量；关系主要存为边/关系记录	文本块、实体描述和关系描述都可建立向量索引

两者都需要处理抽取成本与索引质量问题，但具体的数据产物和后续维护方式并不相同。

3.3 在线检索

LightRAG 提供多种检索模式，让调用者根据问题选择不同的信息获取方式。

官方仓库目前主要介绍 Naive、Local、Global、Hybrid 和 Mix 等模式；具体版本的查询参数还可能包含 Bypass。这里按照六种模式的语义进行说明，但正式部署前应核对所使用版本的查询接口与源码。(GitHub)

flowchart TD
    A["用户问题"] --> B{"选择 Query Mode"}
    B --> C["Naive：只查文本"]
    B --> D["Local：先找实体 → 再找关系"]
    B --> E["Global：先找关系 → 再找实体"]
    B --> F["Hybrid：组合 Local 与 Global"]
    B --> G["Mix：双向图检索 + 文本检索"]
    B --> H["Bypass：跳过常规知识检索"]

    C --> I["组织上下文"]
    D --> I
    E --> I
    F --> I
    G --> I
    H --> J["直接进入模型生成路径"]
    I --> K["LLM 生成"]
    J --> K

为了突出 LightRAG 最有代表性的检索思路，下面重点展开 Mix：它把图谱关联信息与原始文本检索结合起来。其余模式要先理解 Local 与 Global 不只是范围不同，入口方向也相反：Local 是 实体 → 关系，Global 是 关系 → 实体。

该图是概念级流程。不同模式实际获取哪些数据、如何排序和截断，以及是否执行后续 LLM 调用，都取决于具体版本和配置。

3.3.1 Naive：基础文本检索

适合问题：答案可以直接从某些原始文本片段中获取。

例如：

原始文档是如何描述库存服务超时的？

Naive 主要通过文本块的向量检索获取相关文本，不使用图增强检索路径。

可以理解为：

用户问题
  ↓
文本向量检索
  ↓
获取相关文本块
  ↓
组织上下文
  ↓
LLM 生成答案

它适合直接查询原文，也可以用来与图增强模式比较检索效果。

3.3.2 Local：局部实体检索

适合问题：围绕具体对象获取属性、关联实体及相关事实。

例如：

库存服务发生超时后，可能影响哪些业务？

Local 模式会利用与问题相关的实体信息及其关联关系获取局部上下文。

可以简化理解为：

用户问题
  ↓
实体向量检索：定位入口实体
  ↓
以入口实体为起点查关系边与邻近实体（实体 → 关系）
  ↓
补回相关文本块与原文证据
  ↓
组织相关上下文
  ↓
LLM 生成答案

因此，Local 的核心方向是 先实体、后关系：先从问题定位“库存服务”等实体，再从它出发查“库存服务发生超时故障”“库存服务使用连接池”等关系，最后补充相关文本。它不是只做实体名称字符串匹配，也不是直接全局遍历所有关系。

3.3.3 Global：更广泛的关系检索

适合问题：需要综合更广泛的实体关系或跨多个上下文进行归纳。

例如：

知识库中有哪些反复出现的服务故障？它们涉及哪些系统？

Global 模式侧重利用关系及其相关信息提供较广泛的上下文。

它和 Local 的入口方向相反，可以简化理解为：

用户问题
  ↓
关系向量检索：匹配关系描述或关系边
  ↓
从命中关系回溯两端实体及其描述（关系 → 实体）
  ↓
补充相关文本块与原文
  ↓
组织更广泛的上下文
  ↓
LLM 生成答案

因此，Global 的核心方向是 先关系、后实体：不是先选定一个具体实体再往外扩展，而是先找与问题相关的广泛关系，再回到这些关系连接的实体和文本上下文。

它与 GraphRAG 的 Global Search 不是同一种实现。

GraphRAG 的典型 Global Search 依赖社区报告并采用分阶段归纳；LightRAG 的 Global 模式则围绕其自身的图索引和相关检索流程组织信息。

因此，二者虽然名称相同，但底层的数据组织和检索算法不同。

3.3.4 Hybrid：组合局部与全局检索

Hybrid 模式结合 Local 与 Global 两种检索思路。

例如：

库存服务近期为什么频繁超时？它的故障可能影响哪些业务系统？

这个问题既需要找到具体的库存服务及其故障信息，也需要获取更广泛的关联关系。

Hybrid 希望同时获得两类信息，再进行上下文组织和答案生成。

可以简化为：

用户问题
  ├── Local：实体 → 关系，获取具体实体及局部关联
  └── Global：关系 → 实体，获取更广泛的关系及关联实体
                 ↓
             合并检索结果
                 ↓
             LLM 生成答案

具体的合并、去重和排序机制以实际版本实现为准。

3.3.5 Mix：组合图检索与文本检索

这是最能体现 LightRAG“图结构 + 原文”组合思路的示例模式。

用户提问：

订单服务为什么最近频繁出现请求超时？请结合原始记录说明排查方向。

此时，仅获取实体关系可能缺少具体故障细节；仅检索文本块又可能遗漏跨文档关联。Mix 会结合图检索和文本向量检索，再组织上下文。

flowchart TD
    A["用户问题"] --> B["Mix 检索"]
    B --> C["Local 图检索：实体 → 关系"]
    B --> D["Global 图检索：关系 → 实体"]
    B --> E["Naive 文本检索：查找相关原文"]
    C --> F["整合双向图信息与文本证据"]
    D --> F
    E --> F
    F --> G["组织上下文"]
    G --> H["LLM 生成答案"]

例如，图检索与文本检索可能分别提供：

图检索结果： 订单服务调用库存服务；库存服务依赖 MySQL，并使用数据库连接池。
文本检索结果： 故障记录显示连接池使用率达到 98%；变更记录显示近期调整过最大连接数。

LLM 将两类信息结合起来，生成有关系脉络、又有原文依据的回答。

注意：这张图表达的是概念上的并行检索与结果整合，不代表所有 LightRAG 版本内部都严格按照这几个节点顺序执行。组合更多检索来源也不一定总能提升效果；上下文噪声、排序质量和 Token 限制仍会影响最终结果。

3.3.6 Bypass：跳过常规检索

Bypass 的含义是跳过常规知识检索流程，具体行为应以所使用版本的实现为准。

在具有上述语义的实现中，可以将其理解为：

用户输入
  ↓
跳过知识库检索
  ↓
直接进入模型生成路径

它适用于调用者已经提供完整上下文，或者只希望测试模型直接生成能力的场景。

但不能因此认为 Bypass 一定会自动调用某个外部知识库，也不能将其视为 Naive 的另一种向量检索方式。

六种模式如何选择？

模式	主要检索方向与信息来源	适合的问题
Naive	文本块向量 → 文本块	查找原文、直接事实
Local	实体向量 → 关系边 → 邻近实体 → 文本块	具体实体、直接关联
Global	关系向量 → 关系描述 → 端点实体 → 文本块	跨实体、跨上下文的归纳
Hybrid	Local + Global，双向图检索	同时需要局部细节与广泛关联
Mix	Local / Global 图检索 + 文本向量检索	同时需要关联知识与原文证据
Bypass	跳过常规知识检索	已有上下文、直接生成

3.4 LightRAG 的优势与局限

优势

兼顾图与文本。 通过实体关系组织知识，同时保留文本片段作为原始信息来源。
提供多种检索方式。 可以根据问题选择局部实体检索、广泛关系检索或组合检索。
面向增量处理设计。 支持新增知识处理，并提供文档删除等相关机制，适合需要持续更新的知识库。

局限

实体关系抽取仍有成本。 图增强检索并不意味着可以省去 LLM 抽取与数据整理。
多类索引需要协同维护。 图、向量、文本及文档状态之间需要保持一致。
更新不等于没有维护成本。 修改或删除内容时，仍需要处理旧实体关系、失效索引和相关数据的一致性。

增量更新：LightRAG 如何处理知识变化？

假设原始文档记录：

订单服务调用库存服务。

后续架构变更，文档更新为：

订单服务调用库存网关。
库存网关调用库存服务。

系统需要关注的变化包括：

新增库存网关实体。
新增订单服务与库存网关之间的关系。
新增库存网关与库存服务之间的关系。
检查原有订单服务直接调用库存服务的关系是否仍然有效。
更新相关文本与向量索引。
确保旧知识不会继续被检索为当前事实。

重点是：新增实体和关系比较容易理解，但旧关系失效往往才是更新机制中更难处理的部分。

配图 8：增量更新示意图

flowchart TD
    A["原始文档"] --> B["原有实体与关系"]
    B --> C["原有图结构与检索索引"]

    D["新文档或变更文档"] --> E["识别新增、修改与删除"]
    E --> F["重新抽取相关实体与关系"]
    F --> G["更新图结构"]
    F --> H["更新文本与向量索引"]

    G --> I["检查失效关系及孤立实体"]
    H --> J["检查索引与原文一致性"]
    I --> K["完成更新"]
    J --> K

这张图展示的是增量更新需要处理的逻辑，不是 LightRAG 每次更新都会严格执行的固定内部步骤。

具体来说：

新增文档： 处理新文本，抽取实体关系，并更新相关索引。
修改文档： 需要识别新旧内容的差异，避免旧关系持续存在。
删除文档： 需要处理文档关联的文本及相关知识，并确认共享实体和关系是否仍被其他文档支持。

LightRAG 的公开实现提供增量更新和选择性删除相关机制；但更新效率、需要重算的数据范围，以及是否会触发更大范围的索引修复，仍取决于具体实现和数据情况。(GitHub)

因此，不能把“支持增量更新”理解为任何修改都只需修改一个节点，也不能认为它在所有场景下都一定比全量重建更便宜。

第四章：总结

4.1 核心差异对比

对比维度	GraphRAG	LightRAG
核心设计	文本单元构建、知识图谱、社区发现、社区报告	文本块、实体关系图与多类检索索引
离线构建重点	文本单元持久化与向量化；实体抽取与实体描述向量化；关系边构建；社区报告生成	实体关系抽取、图结构构建、文本及实体/关系向量索引
主要知识组织	文本单元、实体、关系、社区、社区报告等	文本块、实体、关系及相关索引数据
检索方式	Local、Global、Basic、DRIFT 等	Naive、Local、Global、Hybrid、Mix、Bypass 等
检索方向	Local：实体向量召回 → 实体 → 关系结构；Global：社区报告归纳	Local：实体 → 关系；Global：关系 → 实体
索引入口	文本单元向量、实体描述向量、社区报告向量；关系走边/关系表遍历	文本块向量、实体向量、关系向量
全局分析	社区报告是典型设计的重要组成部分	通过自身的关系检索及组合检索提供广泛上下文
数据存储	默认可将索引产物保存为 Parquet，向量存储可配置	通过 KV、向量、图及文档状态等逻辑存储组织数据
主要优势	适合复杂关系分析与知识库全局归纳	兼顾图结构与原始文本，提供多种检索模式
主要成本	抽取、社区发现、报告生成及后续维护	抽取、多类索引维护及数据一致性处理
增量更新	需要考虑实体关系、社区及报告等产物的变化	提供增量处理机制，但仍需维护图、文本与索引一致性
选型关注点	全局分析需求、索引成本和更新复杂度	检索效果、更新需求、多类存储的维护成本

4.2 应该如何选型？

场景一：传统 RAG （目前用的最多）

如果主要需求是从文档中检索相关内容，例如产品手册问答、制度查询、操作文档搜索，那么可以先从传统 RAG 开始。

它的知识组织和检索链路相对简单，适合先验证数据质量、召回效果和答案准确性。

场景二：GraphRAG （目前用的最少）

如果业务需要回答跨文档、跨实体的关联问题，或者需要总结整个知识库的主要主题、共性问题和复杂关联，可以考虑 GraphRAG。

但需要评估实体关系抽取、社区发现、社区报告生成等环节的索引成本，以及后续更新和维护的复杂度。

场景三：LightRAG

如果业务需要结合实体关系与原始文本检索，并且知识库需要持续更新，可以考虑 LightRAG。

但仍然需要通过真实数据评估检索质量、索引成本、在线延迟及更新后的数据一致性，不能只根据框架名称判断它一定更轻量或更便宜。

最终总结

三者的差异，核心在于如何组织知识，以及如何利用这些知识回答问题。

RAG： 主要通过检索相关文本增强回答。
GraphRAG： 通过实体关系、社区结构和社区报告增强关联分析与全局归纳。
LightRAG： 通过实体关系、文本关联及多种检索模式结合图检索与文本检索。

选择方案时，应该从实际问题出发，综合考虑知识关联程度、全局分析需求、数据更新频率、检索效果、资源成本和维护复杂度。

没有一种方案适用于所有场景。对于多数项目，先建立可靠的传统 RAG 基线，再根据实际问题引入图增强能力，通常是更容易验证成本与收益的工程路径。