GraphRAG 实战：用知识图谱补上向量检索的多跳短板

原创于 2026-10-26 13:25:30 发布 · 447 阅读

本内容遵循CC 4.0 BY-SA版权协议

本文详解GraphRAG技术如何利用知识图谱弥补向量检索在多跳问答中的结构性缺陷。重点阐述其索引构建四步流程（文本切块、LLM实体关系抽取、社区发现、社区摘要），区分Local Search（基于实体邻居遍历）与Global Search（基于社区摘要的Map-Reduce）两种查询模式，并对比普通RAG，强调其在多跳关系推理和全局总结任务上的不可替代性。同时指出工程落地需采用混合架构，控制索引成本，依赖LLM调用优化与查询路由策略。

个人主页： > for_ever_love__ <（欢迎各位大佬莅临😊）

其他栏目: > 大模型开发从0到1 <

其他栏目: > iOS项目总结大全 <

其他栏目: > 我想学python了 <

其他栏目: > iOS UI <

文章目录

GraphRAG 实战：用知识图谱补上向量检索的多跳短板

GraphRAG 实战：用知识图谱补上向量检索的多跳短板

向量检索有一个结构性盲区：它按"语义相似"找文档，不理解实体之间的关系。问"这家公司 CEO 的校友创办的企业和本公司有什么业务往来"，这种两跳三跳的问题，向量检索召回一堆零散段落，答案要靠模型硬拼——拼错是常态。GraphRAG（微软 2024 年开源）的思路是把文档抽成知识图谱，查询时在图上前向遍历。这篇文章讲透它的完整机制：索引怎么建、两种查询模式差在哪、成本有多贵、以及什么时候值得上。

一、向量检索为什么在多跳问题上天然残疾

先看失败案例。知识库里三份文档：

文档 A：“张伟于 2015 年创立蓝海科技，任 CEO。”
文档 B：“李娜毕业于清华计算机系，是张伟的大学校友。”
文档 C：“李娜 2020 年创办清风数据，专注企业知识图谱。”

用户问：“蓝海科技 CEO 的校友创办了什么公司？”

向量检索的困境：查询和任何单个文档的语义相似度都不高（"蓝海科技 CEO 的校友创办的公司"这个意思，三个文档各自只沾一点边），Top-K 召回可能三个都轮空，或者召回了但模型拿到了也不一定能正确串起"CEO→张伟→校友→李娜→清风数据"这条链——这是检索层面的问题，不是生成层面的。

这类问题的共性：答案不在任何单个段落里，而在多个文档的实体关系链上。图谱恰好是表示关系链的原生结构。

二、GraphRAG 索引构建：四步流水线

GraphRAG 的索引是全自动的，输入文档目录，输出一个查询引擎。核心四步：

1. 文本切分（TextUnits）
   文档按 token 切块（默认 1200 token，重叠 100），作为后续处理的原子单位

2. 实体关系抽取（Entity & Relationship Extraction）
   每个 TextUnit 过一遍 LLM，用抽取提示词产出：
     - 实体：名称、类型、描述
     - 关系：源实体、目标实体、关系描述、强度
   例：从文档 A 抽出 (张伟)-[创立]->(蓝海科技)

3. 社区发现（Community Detection）
   对全量图谱跑 Leiden 层次聚类，把连通紧密的实体子图识别为"社区"
   社区有层级：大社区套小社区

4. 社区摘要（Community Reports）
   每个社区过一遍 LLM 生成摘要报告：
   社区主题、包含的关键实体、关键关系、社区的整体叙述

这套索引的本质：把原始文档压缩成两层结构——细粒度图谱（实体关系，供局部查询）和粗粒度社区摘要（主题叙述，供全局查询）。构建成本全在 LLM 调用上：每个 TextUnit 一次抽取，每个社区一次摘要，一个中型语料库（几千文档）的建索引费用是几十到几百美元，而且每次加文档增量建也要钱。

三、两种查询模式：选错模式等于白建

GraphRAG 的查询分 Local（局部）和 Global（全局），这是理解它的关键：

3.1 Local Search：实体出发的邻居遍历

from graphrag.query import local_search

response, context = await local_search(
    config=config,
    entities=["张伟", "蓝海科技"],   # 或从 query 里 NLP 抽取
    communities_level=2,
    response_type="multiple paragraphs",
    query="蓝海科技 CEO 的校友创办了什么公司？"
)

流程：从查询中识别实体 → 在图谱里找这些实体 → 取它们的关系边 + 关联的 TextUnits（原始文本块）+ 所在社区的摘要 → 把这些结构化上下文塞进生成提示词。

适用：问具体实体的事实型问题（“X 的 Y 是什么”），和向量检索的场景重叠，但多了关系边——"张伟"的邻居实体（蓝海科技、李娜）会显式进入上下文，多跳链条不用模型猜。

3.2 Global Search：社区摘要的 Map-Reduce

from graphrag.query import global_search

response, context = await global_search(
    config=config,
    query="这个知识库整体覆盖了哪些行业主题？"
)

流程：按社区层级 Map（每个社区的摘要 + 相关文本，各自生成一个"方面性回答"）→ Reduce（LLM 把几百个方面性回答聚合成最终答案）。

适用：全局性、总结性问题（“语料库的主题分布”、“所有文档的共性观点”）——这类问题向量检索根本无能为例，它的 Top-K 只覆盖局部相似段落，永远答不了"整体"。

选型速查：

问题类型	选
具体实体的事实查询	Local（或普通向量 RAG）
跨文档的多跳关系	Local
全局总结、主题归纳	Global
细节检索（“某段原文怎么说”）	普通向量 RAG（GraphRAG 不干这个）

四、GraphRAG vs 普通 RAG：一组对照

维度	向量 RAG	GraphRAG
索引成本	embedding，便宜	LLM 抽取，贵一个量级
查询成本	检索便宜，生成看模型	Local 便宜，Global 很贵（几百次 LLM 调用）
多跳推理	❌ 弱	✅ 强
全局总结	❌ 弱	✅ 专长
细粒度原文	✅ 强	一般（TextUnits 是原始块，但不做语义精排）
增量更新	加文档重新 embedding	加文档增量抽取 + 社区要重算
可解释性	引用段落	可以追溯实体和关系边

结论先行：GraphRAG 不是向量 RAG 的替代品，是互补品。它的甜蜜区是"多跳关系 + 全局总结"两类问题，为这两类问题付 LLM 索引的钱。只做简单事实问答的系统，上 GraphRAG 是烧钱。

五、工程落地：混合架构才是生产答案

务实的架构是三路并行，按查询路由：

用户查询
  │
  ├─ 查询分类器（轻量 LLM 或规则）
  │    ├─ 事实型（具体实体/细节）→ 向量 RAG 通道
  │    ├─ 关系型（多跳/实体间关系）→ GraphRAG Local
  │    └─ 全局型（总结/主题）→ GraphRAG Global
  │
  └─ 结果融合（Global 太贵，只路由不过度触发）

各通道内部优化：