GraphRAG 是什么？为什么知识图谱能增强传统向量检索？
这道题考的是你对 GraphRAG 核心原理的理解。简单说：GraphRAG 就是用图结构表达知识关系，让 RAG 具备关系推理能力，而不是简单地"用个图数据库"。为什么要这么做？因为传统向量 RAG 有四个致命缺陷。
GraphRAG 是什么
先搞清楚名字：GraphRAG = Graph（图结构）+ RAG（检索增强生成）。
核心不是"用什么数据库"，而是"怎么表达知识"。传统 RAG 把文档切成一个个 Chunk，向量化后存起来。GraphRAG 呢？它会从文本里抽取出实体和关系，用节点表示实体，用边表示关系。
举个好理解的例子。假设原文是："张三在阿里巴巴工作，李四是他的同事，王五是他们团队的技术负责人。"
向量 RAG 眼里，这就是三个独立的文本片段。GraphRAG 眼里呢？
- 节点：张三、阿里巴巴、李四、王五、团队
- 边：张三—在...工作—>阿里巴巴、李四—同事关系—>张三、王五—负责—>团队
关键点：关系不是简单的"相关"，而是具体的"上下游同事"、"负责"、"位于"这种语义。知识不再是孤立的碎片，而是连成了一张网。
向量 RAG 的四大硬伤
为什么要引入图结构？因为传统向量 RAG 有四个绕不过去的问题。
1. Chunk 孤岛
文档切成片段后，每个片段变成了"信息孤岛"。段落之间的关系——谁包含谁、谁依赖谁、谁是因果——全部丢失。
举个例子：
- Chunk A："苹果公司2023年营收下降10%"
- Chunk B："竞争对手三星同期增长5%"
向量检索可能认为这两个 Chunk 语义相似（都提了"公司""增长""下降"），但无法理解 A 和 B 是在做对比分析。
2. 多跳推理弱
复杂问题往往需要关联多个知识点。比如"特斯拉在中国建厂对国内新能源车市场的影响"——这需要：
- 特斯拉的建厂决策
- 中国新能源车市场的现状
- 两者的因果关系
向量 RAG 的 Top-K 召回无法保证这些跨文档的关键信息都被命中。你可能召回了一堆相关文章，但凑不出完整的推理链条。
3. 全局归纳难
向量检索擅长"找相似"，但"整体分析"是它的弱点。比如问："这份年报的核心观点是什么？"
Top-K 召回只能返回最相关的几个片段，无法回答需要综合全文的问题。这不是调参能解决的，是召回机制的天生局限。
4. 同名歧义
"苹果"可以指公司，也可以指水果。向量相似度无法区分这种歧义，因为两者的语义特征可能很接近。
你搜"苹果"，向量检索可能返回一堆水果相关的片段，遗漏了真正想要的"苹果公司"。
知识图谱怎么增强检索
GraphRAG 的核心思路是：把关系变成检索的一等公民。
关系感知
知识图谱不只告诉你"什么相关"，还告诉你"什么关系"。
同样是"苹果"和"华为"：
- 在"竞争关系"边下 → 商业对比
- 在"合作关系"边下 → 供应链或技术合作
你问的问题变了，召回的知识就变了。 这比纯语义相似度精准得多。
多跳推理
这是 GraphRAG 最核心的能力。假设你问："苹果公司的供应商有哪些？"
向量 RAG 可能召回一篇新闻稿，但 GraphRAG 可以这样做：
- 从"苹果公司"节点出发
- 沿"供应商"边找到"台积电"
- 再沿"供应商"边找到"台积电的供应商"
- 形成完整的供应链关系路径
这就是多跳推理：沿关系边一步步向外扩展，直到找到答案或达到跳数上限。
消歧能力强
回到"苹果"的问题。知识图谱里：
- 苹果公司 —[市值]—> 1万亿美元
- 苹果水果 —[产自]—> 山东烟台
通过关系边，你清楚知道搜的是哪个"苹果"。歧义被关系信息自动消解了。
可解释性强
向量检索返回的是一堆相似片段，你不知道系统为什么召回这些。GraphRAG 返回的是推理路径：
- 从哪个节点出发
- 沿哪条边
- 跳了几步
- 找到哪些相关实体
每一步都可追溯，不像黑盒。
GraphRAG 的代价与适用场景
GraphRAG 不是银弹，它有明显的代价。
代价
| 维度 | 向量 RAG | GraphRAG |
|---|---|---|
| 索引成本 | 基准 | 5-20 倍 Token 消耗 |
| 存储开销 | 基准 | 1.5-3 倍 |
| 运维复杂度 | 低 | 高（图谱需要维护） |
| 错误风险 | 单点 | 系统性（图谱构建错了会误导推理） |
最要命的是最后一条。向量 RAG 召回不准，大不了换几篇文档。GraphRAG 的关系边如果抽错了，整个推理链条都是歪的。
适用场景
GraphRAG 适合满足以下条件的情况：
- 需要跨文档关联的知识（比如 IT 故障影响分析、金融风控）
- 需要全局归纳（比如报告摘要分析）
- 有图谱运维能力的团队
- 数据更新频率不高（图谱重建成本大）
不适合的场景：
- 文档少、问题简单 → 向量 RAG 足够
- 数据必须秒级更新 → GraphRAG 的索引延迟受不了
- 没有图谱运维经验 → 宁可不用
判断标准
一个简单的选择逻辑：
先问自己：这个问题需要"关系推理"吗？
- 问"相关的文档有哪些"→ 向量 RAG
- 问"为什么会这样"、"影响的链条是什么"、"这些实体之间什么关系"→ GraphRAG
面试怎么答
基础版
GraphRAG 是"知识图谱 + RAG"，核心是用节点和边表达知识结构，而不是简单用图数据库。传统向量 RAG 的问题是 Chunk 切分后信息孤岛化，丢失了段落间的关系，无法做多跳推理，遇到同名实体也容易歧义。GraphRAG 通过关系边支持多跳推理和消歧，返回的结果是可追溯的推理路径。它的代价是索引成本高、运维复杂，所以适合需要跨文档关联和全局归纳的复杂场景，不适合简单问答或数据高频更新的场景。
加分版
在基础版基础上，加这些亮点：
强调"图结构"而非"图数据库"：GraphRAG 的重点是知识表示方式的转变，不是换了个存储引擎。
提到四种检索模式：Basic（单点查询）、Local（社区内查询）、DRIFT（动态遍历）、Global（社区聚合）。全局归纳用 Community Summaries 解决，这是向量 RAG 做不到的。
知道工程落地的关键：Neo4j 的 VectorCypherRetriever 把向量相似度和 Cypher 查询结合起来，是目前最实用的方案之一。
给出演示判断：能用一两句话说清楚"什么时候选 GraphRAG，什么时候选向量 RAG"。
一句话总结
GraphRAG 的本质是用图结构表达关系，让 RAG 从"找相似"升级到"做推理"——代价是更高的索引成本和运维复杂度，收益是突破向量 RAG 的多跳推理和全局归纳瓶颈。