GraphRAG：知识图谱增强的检索增强生成

作者：Maurice | 灵阙学院

RAG 的局限性

传统 RAG（Retrieval-Augmented Generation）通过向量相似度检索相关文档片段，再将其作为上下文送入 LLM 生成回答。这种方法在以下场景表现不佳：

  1. 多跳推理：答案需要综合多个文档中分散的信息片段
  2. 全局摘要：需要对整个文档集合的宏观理解，而非局部片段
  3. 隐含关系：信息之间的关联没有在文本中直接表述
  4. 时序推理：需要理解事件的先后顺序和因果关系

举例来说，问"哪家公司在大模型领域的布局最全面？"需要跨越多个文档、综合多维信息才能回答，单靠向量检索很难覆盖所有相关片段。

GraphRAG 的核心思想

Microsoft Research 提出的 GraphRAG 将知识图谱引入 RAG 管线，分为两个阶段：

索引阶段（Indexing）

  1. 文本分块：将源文档切分为文本块（Chunk）
  2. 实体与关系抽取：使用 LLM 从每个文本块中抽取实体和关系
  3. 知识图谱构建：将所有三元组合并为全局知识图谱
  4. 社区检测：使用 Leiden 算法对图进行层次化社区划分
  5. 社区摘要：为每个社区生成自然语言摘要

查询阶段（Query）

GraphRAG 提供两种查询模式：

Local Search（局部搜索）：

  • 将用户问题映射到最相关的实体
  • 从这些实体出发，收集邻域信息（关系、属性、关联文本块）
  • 将结构化图上下文与原始文本一起送入 LLM

Global Search（全局搜索）：

  • 遍历所有社区摘要
  • 使用 Map-Reduce 策略：先让 LLM 基于每个社区摘要生成局部答案
  • 再将所有局部答案合并为最终全局答案

实现架构

源文档集合
    |
    v
[文本分块] --> [LLM 实体/关系抽取] --> [知识图谱构建]
                                           |
                                           v
                                    [Leiden 社区检测]
                                           |
                                           v
                                    [社区摘要生成]
                                           |
                                    (索引完成，存入图数据库)

用户提问
    |
    v
[问题分析] --> Local Search: 实体匹配 + 邻域扩展
           --> Global Search: 社区摘要 Map-Reduce
    |
    v
[上下文组装] --> [LLM 生成回答]

与传统 RAG 的对比

维度 传统 RAG GraphRAG
检索单元 文本片段 实体 + 关系 + 社区
检索方式 向量相似度 图遍历 + 语义匹配
多跳推理 弱（依赖片段重叠） 强（天然多跳）
全局理解 弱（只看局部） 强（社区摘要）
索引成本 低（Embedding） 高（LLM 抽取 + 图构建）
索引延迟 秒级 分钟~小时级
幻觉控制 一般 更好（结构化约束）
可解释性 弱 强（可展示推理路径）

实际应用场景

企业知识库问答

传统 RAG 在企业知识库场景中经常遇到信息分散的问题。例如，一家公司的产品信息可能分布在产品文档、销售材料、技术白皮书等不同文档中。GraphRAG 通过构建统一的知识图谱，能够将分散信息整合为连贯的回答。

法规合规查询

法规文件之间存在大量引用关系（如"依据《XX法》第N条"），这些引用形成天然的图结构。GraphRAG 可以：

  • 追溯法规引用链，提供完整的法律依据
  • 识别法规修订对下游规定的级联影响
  • 发现不同法规之间的潜在冲突

竞品情报分析

将市场上的公司、产品、技术、投融资等信息构建为知识图谱，支持：

  • "A 公司在哪些领域与 B 公司直接竞争？"
  • "最近获得融资的 AI 公司使用了哪些共同技术？"
  • "某技术方向的主要参与者及其关系网络是什么？"

优化策略

降低索引成本

GraphRAG 最大的成本来自 LLM 调用（实体抽取）。优化方向：

  1. 分级抽取：先用小模型粗筛，再用大模型精抽
  2. 增量更新：新文档只更新受影响的子图，不重建全局
  3. Schema 引导：预定义本体约束，减少 LLM 的自由度
  4. 批量处理：将多个文本块打包送入一次 LLM 调用

提升检索质量

  1. 混合检索：同时使用图检索和向量检索，取并集
  2. 个性化社区：根据用户角色动态调整社区权重
  3. 路径评分：对图上的推理路径进行可信度评分
  4. 实体消歧：使用上下文信息消解同名不同义的实体

生产部署建议

  1. 图数据库选择：Neo4j（中小规模）或 NebulaGraph（大规模）
  2. 向量存储：配合 Milvus 或 Qdrant 存储 Embedding
  3. 缓存策略：高频查询的社区摘要做缓存
  4. 监控指标：图规模、查询延迟、LLM 调用量、回答质量

开源实现

microsoft/graphrag

Microsoft 官方实现，功能最完整：

  • 完整的索引管线（分块 → 抽取 → 图构建 → 社区检测 → 摘要）
  • Local Search 和 Global Search 两种查询模式
  • 支持自定义 LLM 和 Embedding 提供者
  • 配置化的抽取提示词和社区粒度

nano-graphrag

社区维护的轻量版 GraphRAG：

  • 代码量约 Microsoft 版的 1/10
  • 支持多种图数据库后端
  • 更容易定制和集成
  • 适合学习和快速原型

LightRAG

另一种轻量级图增强 RAG 方案：

  • 使用更简单的图构建策略
  • 支持增量索引更新
  • 查询延迟更低
  • 适合对实时性要求较高的场景

实践建议

  1. 从小开始：先在一个垂直领域的小文档集上验证效果
  2. 评估 ROI：GraphRAG 的索引成本较高，确保业务场景确实需要多跳推理
  3. 渐进增强：可以先用传统 RAG，在需要的地方逐步引入图增强
  4. 关注质量：实体抽取的质量直接决定了图谱的价值，投资在抽取优化上
  5. 版本管理：知识图谱需要版本管理，记录每次更新的变更

Maurice | maurice_wen@proton.me