GraphRAG 把检索对象从孤立的文本块扩展为实体、关系与社区摘要，专门补向量 RAG 在跨文档推理和全局归纳上的短板。这篇教程讲清它的构建流程、两类查询模式的分工，以及引入图结构前必须算清的成本账。

它解决什么问题

向量 RAG 的标准动作是把文档切成 Chunk、向量化后按相似度取 Top-K。证据集中在少数片段时它表现很好，但有三类问题天然吃力：

  1. 跨文档多跳推理。「A 系统的负责人参与过哪些支付链路的故障复盘？」回答它需要沿「系统 → 负责人 → 复盘 → 链路」做多次受约束跳转。相关片段可能都被召回，但 Top-K 不会告诉系统该沿哪条路径把证据串起来——语义相近不等于逻辑相邻。
  2. 全局归纳。「这批投诉主要集中在哪几类问题？」答案不躺在任何单个片段里，需要对全语料做聚合。召回少了看不到全貌，召回多了 token 成本和噪声一起爆炸。
  3. 实体关系断裂。切分之后，同一个系统的定义、负责人、依赖组件散落在不同 Chunk 里，索引中不再共享任何显式关联。相似度能把它们排到一起，却无法表达「谁依赖谁、谁导致谁」。

GraphRAG 的定位就是补这三个盲区：索引期把实体和关系显式抽取出来织成图，查询时沿图结构收集证据。注意它是补充而非替代——简单事实问答用纯向量依然最便宜、最稳。

核心原理

用图表达知识

知识图谱由节点、边和属性构成：节点是实体（系统、负责人、故障、条款），边是关系（依赖、负责、影响、属于），属性记录时间、置信度、来源文档等补充信息。例如：

用户服务 --依赖--> Redis 集群
Redis 集群 --发生过--> 连接池耗尽事故
连接池耗尽事故 --影响--> 下单接口
张三 --负责--> 用户服务

有了这样的结构，「张三负责的系统有哪些影响下单链路的风险」就从语义匹配问题变成了图上的路径遍历问题。向量 RAG 看到的是几段文字，图看到的是对象之间的连接方式。

索引期：从文档到社区摘要

以 Microsoft GraphRAG 路线为例，构建流程分五步：

  1. 切分：文档切成 TextUnit，粒度同时影响抽取成本和关系完整度。
  2. 实体与关系抽取：让 LLM 从每个 TextUnit 抽出实体、关系和关键声明，输出受 JSON Schema 约束。
  3. 归一化：合并别名与重复节点（「订单中心」和「OMS」是不是同一个实体），补充来源位置。
  4. 社区检测：用 Leiden、Louvain 等算法把连接密集的节点聚成层级社区，一个社区大致对应一个主题群。
  5. 社区摘要：为每个社区生成摘要，作为全局问题的「预计算答案素材」。

查询期：Local 与 Global 两条路

  • Local Search：问题里有明确实体时，先用向量检索定位种子实体，再沿邻居、关系路径和关联原文扩展上下文。适合「订单中心依赖哪些服务」这类实体聚焦问题。
  • Global Search：问题指向全局主题时，对各社区摘要做 Map-Reduce 式的分批归纳再汇总。适合「过去一年反复出现的架构风险是什么」。
  • DRIFT Search：介于两者之间，实体邻居之外再混入社区摘要，补充跨社区背景。

成熟系统会做查询路由：事实型走向量，关系型走 Local，全局型走 Global，而不是把所有问题都扔进图里。

深入机制

实体抽取决定上限

抽取质量是 GraphRAG 的生死线。工程上有几条纪律：用 JSON Schema 强约束输出格式，避免自由文本解析；few-shot 示例必须覆盖正例、反例和边界例，明确告诉模型什么不该抽；限制单篇最大实体数，防止长文档里过度抽取；每个实体强制携带原文位置（source span），供溯源和人工抽检。消歧不能只靠模型猜，生产环境通常叠加术语词典、别名表、规则匹配和置信度阈值。每条关系还应带上 source_doc_id、confidence、updated_at 等字段——没有来源追溯的图谱，不该用于高风险问答。

社区摘要为什么能回答全局问题

全局问题的难点是证据分散在整个语料中，任何单次检索都看不全。社区检测先在图结构上把「频繁共现、关联紧密」的节点分组，摘要再把这些组的主题压缩成可读文本——相当于离线把「通读全库」的代价预付掉，查询时只需在摘要层筛选归纳，token 消耗从「读全库」降到「读目录」。但摘要是有损压缩，关键约束可能丢失，所以原文证据必须保留并支持回溯核验。

混合是最常见的落地形态

实际系统很少纯图检索。典型链路是：向量检索找种子实体 → 图上 k-hop 扩展 → 把路径、邻居和关联 Chunk 一起交给重排 → 进入上下文。向量负责「找到入口」，图负责「补全关系」。

工程实践

  • 成本结构先算清。构建期的 LLM 调用量与语料规模成正比：实体抽取、关系抽取、实体描述、社区摘要每一步都是钱。更新一篇文档可能牵动实体、边、社区划分和多份摘要，远比「删旧 Chunk 写新 Chunk」复杂。
  • 分阶段引入。先把向量 RAG 基线做稳（解析、混合检索、重排、引用），再对线上 badcase 归因：只有失败持续集中在「召回了但串不起来」和「全局归纳」时，才从轻量图谱起步——只抽核心实体、只保留少数高价值关系、每条关系挂原文证据。
  • 权限不能只看文档级。社区摘要可能混入无权文档的信息，查询时按文档 ID 过滤已经晚了。应按权限分区分别生成摘要，或让高敏感语料只走鉴权后的局部检索。
  • 评测要分层。检索层看实体/关系召回率和社区一致性，生成层看忠实度与引用准确性，业务层看采纳率。必须用多跳问答数据集对比纯向量 baseline，避免为图而图。
  • 延迟预期要现实。Global Search 涉及多次 LLM 调用，延迟远高于普通 RAG，适合离线分析型问答，不适合毫秒级客服场景。

对比与权衡

维度 向量 RAG GraphRAG 混合方案
检索对象 文本 Chunk 实体、关系、路径、社区摘要 向量初召 + 图扩展
擅长问题 局部事实问答 多跳推理、全局归纳 事实与关系混合负载
构建成本 切分 + Embedding，中等 抽取、消歧、社区摘要，高 介于两者之间
查询延迟 低，一次 ANN 检索 Global 高，Local 中等 按路由分流，可控
维护成本 更新 Chunk 即可 实体、边、社区、摘要都要增量维护 图部分按需更新
典型风险 召回不全、证据孤立 抽取错误导致整张网跑偏 路由错误、链路复杂

引入判断标准很朴素：badcase 里没有持续出现多跳关系和全局归纳，就不要上图；数据量小、文档质量差、团队没有图建模能力时，先把混合检索和重排做稳收益更高。

面试视角

GraphRAG 和普通向量 RAG 的核心区别是什么？ 检索对象不同：前者是实体、关系、路径和社区摘要，后者是文本块。向量 RAG 回答「哪段文字像问题」，GraphRAG 回答「这些对象怎么连在一起」；代价是抽取、消歧、摘要和增量维护都进入了系统边界。

向量 RAG 的哪些盲区促使你引入图结构？ 三类：Chunk 切分后实体关系断裂、Top-K 无法做多跳路径推理、全局归纳超出单次检索窗口。判断依据是 badcase 归因，而不是技术热度。

Local Search 和 Global Search 分别怎么工作？ Local 从向量命中的种子实体出发，沿图扩展邻居、路径和原文；Global 对预先生成的社区摘要做 Map-Reduce 归纳。前者服务实体关系问答，后者服务跨语料主题问题。

GraphRAG 的成本在哪里，如何控制？ 成本在构建期的 LLM 抽取与摘要、更新期的图维护、查询期的多次调用。控制手段：限制实体和关系类型范围、按权限分区生成摘要、用查询路由把简单问题挡在图外、用多跳评测集验证收益后再扩大投入。

什么场景不该用 GraphRAG？ 数据量小且问题简单、源文档质量差（抽出来的图更脏）、秒级实时性要求、团队缺少图建模与评测能力——这些情况下向量加混合检索更划算。

小结

  1. GraphRAG 补的是向量 RAG 的三类盲区：关系断裂、多跳推理、全局归纳，而不是全面替代。
  2. 构建链路是实体关系抽取 → 归一化 → 社区检测 → 社区摘要；查询分 Local、Global、DRIFT，成熟系统按问题类型路由。
  3. 实体抽取和消歧质量决定上限，每条关系必须挂来源、置信度和版本。
  4. 成本集中在构建期的 LLM 调用、更新期的图维护和 Global 查询延迟；先用 badcase 归因证明需要它。
  5. 混合架构（向量找种子、图做扩展）是最常见的落地形态，纯图检索很少是正确答案。