GraphRAG 适合哪些场景？长文档、多实体关系和企业知识库怎么用？
这道题考的是场景判断能力。你能不能说清楚什么时候该用 GraphRAG、什么时候不该用，以及企业落地要注意什么。核心就一句话：GraphRAG 解决的是"关系推理"问题，而不是"相似匹配"问题。
1. GraphRAG 解决的核心问题是什么
先说向量 RAG 是怎么工作的。它把你文档切成一块块文本chunk，然后问问题时去找"长得像"的文本块。简单说就是找相似内容。
GraphRAG 完全不一样。它先把文档里的实体和关系抽出来，构建一张图谱。问问题时，它顺着关系链路去找答案。
举个例子。"某负责人参与过哪些影响支付链路的事故？"
用向量 RAG 的话，它会去找包含"负责人"、"支付链路"、"事故"这些关键词的文本。但如果这些信息分散在不同文档里，向量 RAG 可能就找不到。
用 GraphRAG 的话，它会先找到这个负责人节点，然后沿着"参与→项目→影响→支付链路"这条关系链路追溯，把相关实体串起来。答案藏在关系链条里，不在任何单独一段文本中。
这就是两者的本质区别：向量 RAG 找的是相似文本，GraphRAG 找的是关联关系。
2. 三类典型适用场景及判断标准
什么情况下该用 GraphRAG？我给你三个标准场景。
第一类：多跳关系推理
问的是"A 通过什么路径影响了 B"。典型问题：
- "某供应商的财务问题会波及哪些下游项目？"
- "这个bug的影响链是什么？"
- "谁是这个需求的相关干系人？"
这类问题答案不在任何单一文档里，而是分散在多个实体之间的关系中。
第二类：跨文档全局归纳
把多份文档放在一起分析整体模式。比如分析30份用户访谈记录，找出共性需求；或者汇总一季度的所有复盘会纪要，提取系统性改进方向。
向量 RAG 每次只召回最相似的几个chunk，容易遗漏全局信息。GraphRAG 能把相关实体聚合起来做全局层面的推理和总结。
第三类：精确结构化查询
问的是"2025年Q4哪些项目依赖供应商A"这种需要精确追溯的问题。GraphRAG 可以顺着"项目→供应商"这条边精确查询，比向量检索的模糊匹配靠谱多了。
判断标准很简单：问的是"关系"还是"内容"。问关系用 GraphRAG，问内容用向量 RAG。
3. 什么时候不该用 GraphRAG
不是所有场景都适合 GraphRAG。杀鸡焉用牛刀，这些情况就别折腾图谱了：
简单知识库。就几十篇文档，问的都是"这条政策第几条怎么说的"这种直接问题，向量 RAG 足够了。你搞个知识图谱，维护成本比收益高得多。
源文档质量差。GraphRAG 的效果严重依赖文档质量。格式混乱、实体不清、关系模糊的文档，抽出来的图谱也是一塌糊涂。
实时性要求高。GraphRAG 的查询延迟比向量 RAG 高 1.2 到 10 倍。如果你的场景要求毫秒级响应，不适合。
没人维护图谱。GraphRAG 不是一次性建设，需要持续更新和维护。图谱过时了比没有图谱还危险。
成本方面，GraphRAG 的 Token 消耗是向量 RAG 的 5 到 20 倍。这个代价你要心里有数。
4. 企业落地的关键决策点
如果你确定要用 GraphRAG，有几个关键决策点。
检索策略怎么选
MS出品的GraphRAG支持三种检索模式：
- Local Search：针对具体实体做局部查询，适合"某个人/项目/公司"的详细情况查询
- Global Search：做全局层面的归纳总结，适合"这季度整体情况如何"这种宏观问题
- Hybrid Search：混合模式，先用向量检索召回候选实体，再用图遍历扩展关联信息。大多数场景的最佳实践就是这个，别上来就只用一个。
三个常见坑
图谱膨胀。实体和关系越来越多，查询性能直线下降。解决方案：定期裁剪、设置关系深度限制、对低频关系做合并。
图谱过时。文档更新了但图谱没同步，问出来的答案可能是错的。解决方案：建立自动化更新管线，或者至少设置定期重建机制。
响应延迟。每个环节都要设性能预算：抽取环节目标多少毫秒、图遍历环节多少毫秒、生成环节多少毫秒。超了就降级处理。
评测体系怎么建
从三个维度评：
- 检索质量：召回的实体和关系准不准、全不全面
- 生成质量：答案是否准确、连贯、有没有幻觉
- 系统性能：延迟、吞吐、资源消耗
建议先定清楚你的业务指标，再反推技术指标。比如业务要求"供应商风险查询准确率≥95%"，你再拆解到检索召回率和精确率要多少。
面试怎么答
基础版（能拿到基础分）：
GraphRAG 适合关系推理类场景，跟向量 RAG 的本质区别在于：向量 RAG 找相似文本，GraphRAG 找关联关系。典型场景有三个：一是多跳关系推理，比如"某供应商出问题会影响哪些项目"；二是跨文档全局归纳，比如分析多份访谈记录找共性；三是精确结构化查询，比如"哪些项目依赖供应商A"。简单知识库和实时性要求高的场景不适合。实际落地一般用 Hybrid 模式，兼顾向量检索的召回和图遍历的深度。
加分版（能拉开差距）：
判断该不该用 GraphRAG，问自己一个第一性问题：这道题问的是"关系"还是"内容"？问关系用 GraphRAG，问内容用向量 RAG。成本上，GraphRAG 的 Token 消耗是向量 RAG 的 5 到 20 倍，延迟高 1.2 到 10 倍，这个代价要匹配场景复杂度。落地关键点：检索策略按查询类型选（Local/Global/Hybrid），常见坑是图谱膨胀、图谱过时、响应延迟。评测体系要覆盖检索质量、生成质量、系统性能三类指标。
一句话总结
GraphRAG 解决的是"关系推理"问题——问的是关系链路用 GraphRAG，问的是具体内容用向量 RAG，复杂场景用 Hybrid。