GraphRAG 与普通 RAG 的应用分析

背景

微软开源了 GraphRAG，各大技术社区都在讨论。今天这篇文章，把以下几个核心问题讲透：

• 普通 RAG 的能力边界在哪
• GraphRAG 解决的到底是什么问题
• 哪四类场景必须考虑 GraphRAG
• 工程上为什么不能无脑上 GraphRAG
• 混合路由架构怎么设计

普通 RAG 能力边界

普通 RAG 核心机制

文档 → 切 Chunk → 向量 Embedding → 存入向量数据库
                                    ↓
用户 Query → 向量化 → 语义相似度检索 → TopK Chunk → 喂给大模型 → 生成答案

这套机制的本质是文本片段的相似度匹配。它能做好的事情，和它做不好的事情，边界非常清晰。

普通 RAG 擅长

单点事实类问题，答案完整地存在于某个 Chunk 里。比如查询”接口超时时间””产品支持的功能””GPT-4 发布时间”这类事实。

只要答案在某个 Chunk 里写得明明白白，普通 RAG 基本都能精准召回。这类问题占据了企业知识库 70% 以上的查询量。

普通 RAG 短板

短板在于：它只能找到片段，但不一定能把片段之间的关系连起来。

来看一个真实场景。用户输入一个多条件查询：有没有一款适合拍视频、续航也不错、而且用户评价稳定的手机

普通 RAG 的处理方式如下：

• 可能召回 Chunk A：”XX 手机影像系统强大，视频拍摄能力突出”
• 可能召回 Chunk B：”XX 手机电池 5500mAh，续航表现优秀”
• 可能召回 Chunk C：”用户评价：用了半年，系统稳定，没有大问题”

问题是：A、B、C 可能来自三篇不同的文档，描述的是三款不同的手机。普通 RAG 把三个 Chunk 一起扔给大模型，大模型也不知道到底哪款手机同时满足这三个条件。

这就是普通 RAG 的根本局限：

它的检索单元是文本片段，不是实体，更不是关系。它擅长”找到相似的文字”，不擅长”找到满足多个关系约束的答案”。

那什么场景下这个问题会变得无法回避，下面逐一分析。

场景一：多维度关联查询

多维度关联查询的含义

注意，不是简单的多条件过滤。多条件过滤是 "价格 < 5000 AND 品牌 = 华为"，这是 SQL 能干的事。

多维度关联查询指的是：多个维度之间存在结构化的关系，需要沿着关系做导航和交集运算。

典型场景：商品推荐系统

商品知识不是一张扁平的表，而是一个关系网络：

商品 A ──→ 品牌: XX
       ──→ 价格段: 高端
       ──→ 核心卖点: 影像旗舰
       ──→ 适用人群: 摄影爱好者
       ──→ 用户口碑: 稳定

商品 B ──→ 品牌: YY
       ──→ 价格段: 中高端
       ──→ 核心卖点: 性能旗舰
       ──→ 适用人群: 游戏玩家
       ──→ 用户口碑: 良好

用户输入：”有没有适合拍视频、性能强、口碑稳定的旗舰机”

普通 RAG 的做法是在文本里模糊匹配，召回”影像强”的片段、”性能强”的片段、”口碑好”的片段，最后让大模型自己猜。

GraphRAG 的做法是：把知识建成图，然后沿着关系边做导航——找到”影像旗舰”节点，找到”性能旗舰”节点，找到”用户口碑稳定”节点，然后取它们关联的商品实体的交集。

这不是语义相似度的问题，这是图遍历的问题。

为什么普通 RAG 在这里失效

根本原因：普通 RAG 的检索空间是向量空间，它衡量的是两段文本像不像。而多维度关联查询需要的检索空间是关系空间，它需要的是沿着实体关系做路径查找。

两个完全不同的空间，用错工具，效果天差地别。

场景二：全局总结类问题

全局总结类问题的特征

不是问某个点，而是问整体。比如”最近几年高端手机的发展趋势””目前 AI Agent 行业的技术格局””公司各部门的业务关联情况”这类问题。

普通 RAG 在这里翻车

这类问题的特点是：答案不在任何一个 Chunk 里，而是分散在整个语料库中。

普通 RAG 召回的是 TopK 个最相似的 Chunk，可能Chunk 1 讲影像，Chunk 2 讲芯片，Chunk 3 讲价格，Chunk 4 讲 AI 功能。大模型拿到这些碎片化的信息，只能硬拼，最后生成一个面面俱到但毫无洞察的答案——读起来像目录，不像分析。

GraphRAG 的解法：社区发现 + 分层摘要

GraphRAG 的核心机制是这样的：

知识图谱
    │
    ▼
┌─────────────────────────┐
│  社区发现算法              │
│  (如 Leiden 算法)         │
│  把图谱划分为若干社区       │
└──────────┬──────────────┘
           │
     ┌─────┼──────────┬──────────┐
     ▼     ▼          ▼          ▼
  社区A   社区B      社区C      社区D
  影像    芯片性能    品牌竞争    用户需求
     │     │          │          │
     ▼     ▼          ▼          ▼
  局部摘要 局部摘要   局部摘要   局部摘要
     │     │          │          │
     └─────┴──────────┴──────────┘
                  │
                  ▼
           全局汇总摘要

第一步，用社区发现算法把知识图谱划分成若干个语义社区。每个社区里的实体关系紧密，社区之间相对松散。

第二步，对每个社区分别做摘要，生成局部摘要。

第三步，把所有局部摘要汇总，生成全局摘要。

这个分层摘要的机制，天然适合回答”整体趋势””行业格局”这一类问题。因为它不是从碎片拼凑，而是从结构化的社区出发，每个社区都有自己的主题和洞察，最后合并起来就是全局视图。

场景三：隐性关系发现

隐性关系的定义

两个实体之间，文本里从来没有直接说明它们有关系，但通过中间节点可以推断出关联。

举个例子：

• 产品 A 和产品 B 从来没有被任何文档直接比较过
• 但产品 A：价格段 = 高端，目标人群 = 商务用户，核心能力 = 影像
• 产品 B：价格段 = 高端，目标人群 = 商务用户，核心能力 = 影像

在图结构里，产品 A 和产品 B 虽然不直接相连，但它们共享了多个相同的邻居节点。这种结构上的接近性，就是隐性关系。

普通 RAG 无法发现隐性关系的原因

普通 RAG 的检索是基于 Query 和 Chunk 的语义相似度。如果没有任何文档把产品 A 和产品 B 放在同一段文字里，普通 RAG 就完全没有办法发现它们之间的联系——因为它的信息组织单位是文本片段，不是实体关系图。

依赖隐性关系发现的典型业务场景

• 竞品分析：发现没有被直接对比，但实质上高度重叠的竞品
• 风控排查：多个看似无关的账户，通过中间节点发现它们共享同一控制人
• 推荐系统：用户 A 和用户 B 从未被直接比较，但行为模式高度相似
• 药物研发：两种靶点蛋白没有被同一篇论文提及，但通过通路网络发现它们在同一信号通路上

这些都是普通 RAG 根本做不到的事。

场景四：分散信息的因果链追溯

问题描述

有些问题的答案，需要从多个文档中串联多条信息，才能推导出根因。

典型的例子是”XX 项目延期的根本原因分析”。真实的答案可能分散在：

• 需求文档：中期发生了重大需求变更
• 排期表：关键开发人员被借调到其他项目
• 研发周报：接口联调出现了预期外的问题
• 测试反馈：某个第三方 SDK 有 Bug，阻塞了测试进度
• 客户沟通记录：客户在验收阶段新增了功能点

普通 RAG 的处理方式

普通 RAG 最可能召回的是某一篇文档中的一个片段，比如会议纪要里的一句话：”本次会议确认项目延期两周，主要原因是需求变更。”

这个答案不算错，但不完整。真正的根因是多个因素叠加的结果，只看其中一个，会误导决策。

GraphRAG 的处理方式

GraphRAG 把人、需求、任务、时间、风险、依赖关系全部建模成图的节点和边：

需求变更 ──→ 影响任务A ──→ 阻塞任务B ──→ 延期
    ↑
开发人员借调 ──→ 任务A人力不足 ──→ 延期
    ↑
SDK Bug ──→ 联调阻塞 ──→ 延期
    ↑
客户新增需求 ──→ 验收阶段返工 ──→ 延期

从”项目延期”这个现象出发，沿着关系边可以追溯到多个根因节点。这是图上的路径查找问题，不是文本相似度问题。

GraphRAG 的代价：为什么不能无脑上

讲完四个场景，必须马上泼一盆冷水。GraphRAG 的索引阶段和普通 RAG 完全不在一个量级：

环节	普通 RAG	GraphRAG
文档处理	切 Chunk	实体抽取 + 关系抽取
索引构建	向量 Embedding	图构建 + 社区发现 + 每社区摘要
LLM 调用量	低（只做 Embedding）	极高（抽取、摘要都在调 LLM）
索引时间	分钟级	小时级甚至天级（视语料规模）
查询延迟	毫秒 ~ 秒级	秒级 ~ 十秒级（遍历 + 合成）
存储成本	向量数据库	图数据库 + 向量库 + 摘要存储

举个量化的例子：一份 100 万 Token 的企业知识库，普通 RAG 的索引成本可能只需要几美元的 Embedding 费用。而 GraphRAG 的索引阶段——实体抽取、关系抽取、社区摘要——可能需要几十甚至上百美元的 LLM 调用费用。

这还没有算查询阶段的开销。每次查询，GraphRAG 可能需要遍历更多节点、读取更多关系、合成更长的上下文，这些都是 Token 成本。

所以结论非常清晰：

如果你的场景 80% 以上都是简单事实类问题，上 GraphRAG 就是过度设计。 花钱更多，延迟更高，简单问题的回答质量可能还更差。

工程实践：混合路由架构

真正做过线上系统的人，不会在普通 RAG 和 GraphRAG 之间二选一。正确的做法是混合路由。

架构设计

用户 Query
    │
    ▼
┌─────────────────────────┐
│   Query Router          │
│   (LLM / 规则引擎)       │
│   判断问题类型           │
└──────────┬──────────────┘
           │
     ┌─────┼──────────────┬──────────────┐
     ▼     ▼              ▼              ▼
  简单事实  结构化查询     关系推理        全局总结
     │        │             │              │
     ▼        ▼             ▼              ▼
  普通RAG   SQL查询      GraphRAG      GraphRAG
  + BM25    (转SQL)      (图遍历)      (社区摘要)
     │        │             │              │
     └────────┴─────────────┴──────────────┘
                         │
                         ▼
                   答案合成 & 输出

Query Router 的设计方式

Query Router 是整个混合路由的大脑。它的职责是判断用户的问题属于哪一类，然后路由到对应的检索引擎。

实现方式有三种，从轻到重：

方式一：规则路由

基于关键词和句式模式匹配，速度快，成本低。

def route_query(query: str) -> str:
    # 全局总结类关键词
    summary_keywords = ["趋势", "格局", "整体", "总结", "概括", "发展"]
    if any(kw in query for kw in summary_keywords):
        return "graphrag_summary"

    # 结构化查询类关键词
    if "多少" in query or "什么时候" in query or "是什么" in query:
        return "normal_rag"

    # 关系推理类关键词
    relation_keywords = ["关联", "影响", "原因", "依赖", "共同"]
    if any(kw in query for kw in relation_keywords):
        return "graphrag_relation"

    return "normal_rag"  # 默认走普通 RAG

方式二：LLM 分类路由

用一个小模型（如 GPT-4o-mini）对 Query 做分类，准确率更高，但有额外延迟和成本。

ROUTER_PROMPT = """
请将以下用户问题分类为以下类型之一：
- factual：简单事实查询，答案在某段文本中
- sql：可转为结构化查询的问题
- relation：需要跨实体关系推理的问题
- summary：需要全局总结或趋势分析的问题

用户问题：{query}
类型：
"""

方式三：混合路由

规则优先，规则无法判断时再调 LLM。成本和延迟之间取得平衡。

路由策略的核心原则

默认走普通 RAG，只在明确需要时路由到 GraphRAG。

原因很简单：大部分查询都是简单事实类问题，GraphRAG 应该是”特种兵”，不是”常规军”。

如果反过来，所有问题都走 GraphRAG，你会发现：成本上去了，延迟上去了，简单问题的准确率反而下降了。因为 GraphRAG 的上下文更长、噪声更多，大模型反而更容易被干扰。

一张表总结：场景与工具对应关系

问题类型	举例	推荐工具	原因
单点事实	“接口超时时间查询”	普通 RAG / SQL	Chunk 里有答案，杀鸡不用牛刀
多条件过滤	“价格 < 5000 的华为手机”	SQL / 结构化查询	这是数据库的活
多实体关系推理	“适合拍视频、口碑好的旗舰机”	GraphRAG	需要沿关系边做交集
全局趋势	“AI Agent 行业格局”	GraphRAG	需要社区摘要机制
隐性关系发现	“两个账户的关联分析”	GraphRAG	需要图结构推断
跨文档因果追溯	“项目延期的根因”	GraphRAG	需要多路径汇聚
简单对比	“A 和 B 的区别”	普通 RAG	两段文本拼起来就行

总结

技术在演进，但工程思维不变。GraphRAG 不是普通 RAG 的替代品，而是补充。它们解决的是不同类型的问题，没有谁比谁更高级，只有谁更适合哪个场景。

做技术选型的时候，正确的思路不是列举某个技术的优点，而是先说清楚现有方案的能力边界，再说新方案补的是什么，最后说工程上怎么把两者结合起来。

能把这个选型逻辑讲清楚，就说明不是在追热点，而是真的做过系统，踩过坑，想清楚了。