当普通 RAG 无法回答复杂关系问题时，GraphRAG 往往被视为下一步升级方向。

普通 RAG 通常根据语义相似度找到若干文档片段，再由大语言模型生成答案。这种方法擅长“找到与问题相关的内容”，却未必能还原分散在不同文档中的实体关系。例如：

• 某个零部件出现质量问题，会影响哪些设备和订单？
• 某位客户与哪些合同、联系人和历史服务事件有关？
• 一项政策变化，会影响哪些业务流程和责任部门？

这类问题的答案往往不在一个独立片段中，而是隐藏在多个实体及其关系之间。GraphRAG 的价值，正是在检索过程中利用这些关系，把原本分散的事实连接起来。

但这并不意味着所有 RAG 系统都应该升级为 GraphRAG。

引入 GraphRAG 不只是增加一个图数据库。系统通常还需要完成实体抽取、关系识别、实体消歧、图谱更新、检索路径控制和结果重排。如果问题本身不依赖关系，或者关系无法被可靠构建，那么图检索增加的复杂度未必能够换来更好的答案。

因此，在讨论如何建设 GraphRAG 之前，我们应该先回答一个更基本的问题：

什么时候不该优先使用 GraphRAG？

图 1：当答案可以从单个片段中获得时，普通检索通常已经足够；当答案依赖多个实体之间的关系时，GraphRAG 才可能产生明显价值。

先明确：GraphRAG 不是普通 RAG 的替代品

“GraphRAG”并不是一个只有单一实现方式的固定产品，而是一类利用图结构改善检索和上下文组织的方法。

以微软开源的 GraphRAG 为例，其标准索引流程会从原始文本中抽取实体、关系和声明，再进行社区发现并生成不同层级的社区报告。查询时，它提供了 Local Search、Global Search、DRIFT Search 和 Basic Search 等多种方式。

其中：

• Local Search 主要围绕特定实体及其关系组织上下文；
• Global Search 主要利用社区报告回答涉及整个语料库的全局性问题；
• Basic Search 则采用更接近传统 RAG 的向量 Top-K 检索。

微软 GraphRAG 自身仍然保留了 Basic Search，这说明图检索与向量检索并不是简单的替代关系，而是在解决不同类型的问题。

判断是否需要 GraphRAG，关键不在于数据量有多大，也不在于 GraphRAG 是否流行，而在于：

用户的问题是否真正依赖实体之间的关系？

以下四类问题，通常不适合一开始就把 GraphRAG 作为首选方案。

第一类：答案集中在单个片段中的事实问题

很多企业知识问答看起来涉及大量文档，但用户实际提出的问题并不复杂。例如：

• 公司的差旅报销标准是什么？
• 某款设备出现 E102 错误应该如何处理？
• 产品支持哪些操作系统？
• 合同的有效期到什么时候？
• 如何申请某项内部权限？

这类问题的答案通常集中在一个文档片段或者一条结构化记录中。系统要做的主要工作，是找到这个片段，而不是沿着实体关系继续扩展。

普通 RAG 的处理过程可能是：

用户问题
    ↓
检索相关文档片段
    ↓
根据片段生成答案

如果引入图检索，过程可能变成：

用户问题
    ↓
识别问题中的实体
    ↓
将实体映射到图中节点
    ↓
沿关系寻找相邻节点
    ↓
读取节点关联的文本
    ↓
生成答案

当答案在第一次检索中就能够找到时，后续的关系扩展并没有带来新的有效信息，反而可能引入不相关的邻居节点，增加上下文噪声。

因此，当问题的本质是“找到一段正确的文本”时，全文检索、关键词检索或者向量 RAG 通常已经足够。

当然，问题类型发生变化后，结论也会变化。

“产品 A 的保修期是多少”通常不需要图；但如果问题变成：

产品 A 使用了供应商 B 的某个零件，而这个零件刚刚被召回，会影响哪些保修服务和客户订单？

答案开始依赖产品、零件、供应商、订单和保修政策之间的关系。此时，图检索才可能提供普通片段检索难以获得的上下文。

所以，判断标准不是文档数量，而是回答问题是否需要连接多个事实。

第二类：以语义相似为核心的问题

第二类图检索收益有限的场景，是内容推荐和相似性检索。例如：

• 找出与这篇文章主题相似的文章；
• 推荐描述相近的商品；
• 检索与当前故障现象相似的维修案例；
• 寻找与职位要求相匹配的简历；
• 从历史工单中查找语义相近的问题。

这类问题的核心是“相似”，而不是“相连”。

向量检索回答的是：

哪些内容在语义空间中与当前查询最接近？

图检索回答的则是：

某个实体与哪些实体存在关系？沿这些关系能找到什么？

两者可以相互补充，但不能相互等同。

例如，用户希望找到与某款产品功能相似的其他产品。此时，产品描述的语义相似度可能就是最重要的排序依据。即使系统已经建立了品牌、供应商、零件和产品之间的图谱，这些关系也未必能够帮助判断产品功能是否相似。

如果为了完成一个简单的相似性检索任务，额外构建大量实体和关系，系统可能付出了更高的索引与维护成本，却没有明显改善最终结果。

但是，当问题同时包含“相似性”和“关系约束”时，混合检索便可能体现价值。例如：

推荐一款与当前产品功能相似、兼容已有配件，并且不依赖某个供应商的替代产品。

这个问题包含三个不同条件：

1. 功能相似，需要语义或向量检索；
2. 配件兼容，需要查询产品与配件之间的关系；
3. 排除特定供应商，需要继续检查供应关系。

此时，单纯依靠向量相似度很难完整回答问题，图检索也不适合单独承担语义匹配。更合理的办法是先通过向量检索找到候选产品，再利用图关系进行过滤和扩展。

因此，当问题主要寻找“相似内容”时，可以优先采用向量检索；只有当相似性之外还存在明确的关系约束时，才需要考虑将图检索加入流程。

第三类：实体和关系无法被稳定识别的问题

GraphRAG 能否产生价值，不只取决于查询算法，还取决于图本身是否可靠。

以微软标准 GraphRAG 为例，系统需要从文本中抽取实体、关系和声明，对实体与关系描述进行汇总，再进行社区发现和社区报告生成。

但并不是所有数据都天然适合被转换成图。

一些常见的困难包括：

• 历史文档缺少统一的命名规范；
• 同一个设备在不同系统中使用不同名称；
• 不同实体恰好拥有相同简称；
• 文本中大量使用“它”“该系统”“有关部门”等模糊指代；
• 关系只在特定时间或条件下成立；
• 文档表达的是观点、情绪和风格，而不是稳定事实；
• 数据变化速度很快，刚刚抽取的关系很快就会失效。

例如，三份文档分别使用了以下名称： 华东一号机组 1#生产设备 新厂主设备

如果系统无法判断它们是否指向同一个对象，知识图谱中可能会生成三个不同节点，导致相关信息被分散。相反，如果系统错误地将三个不同设备合并成一个节点，又会污染这个节点关联的所有关系。

普通 RAG 出现检索错误时，影响往往止步于片段召回；图谱中的关系一旦出错，错误可能随着图遍历继续传播。

假设系统错误地建立了“A 设备使用 B 零件”的关系。当查询继续沿着零件、供应商、订单和客户关系扩展时，一条错误的边可能把多个原本不相关的事实全部带入上下文。图检索并不会自动让数据更可信，它只会更有效地利用图中已有的关系——无论这些关系是正确还是错误。

因此，当实体无法稳定识别、关系难以验证，或者数据变化速度超过图谱维护能力时，不应该急着将全部数据转换为知识图谱。

更稳妥的方式可能是：

• 先使用全文检索或向量 RAG；
• 利用部门、时间、文档类型等元数据过滤结果；
• 只对少量高价值实体进行结构化；
• 由业务人员维护关键关系；
• 保留关系对应的原始文本证据；
• 在小范围验证实体消歧和关系抽取质量。

GraphRAG 的效果上限，不只取决于大模型能力，也取决于关系数据是否可信。如果图谱质量无法得到基本保证，扩大图谱规模可能只是在扩大错误。

图 2：图谱中的实体或关系一旦识别错误，错误可能随着多跳遍历进入更多上下文；图检索会利用关系，但不会自动判断关系是否可信。

第四类：低延迟和低成本优先的问题

标准 GraphRAG 的索引过程比普通向量 RAG 更复杂。

除了文档切分和向量化，它还可能需要调用大模型完成实体抽取、关系抽取、描述汇总和社区报告生成。微软在入门文档中明确提醒，GraphRAG 可能消耗大量大模型资源，建议先使用教程数据集和成本较低的模型进行实验。

在微软当前提供的两种索引方法中，标准方案通过大模型执行较完整的实体和关系抽取；FastGraphRAG 则使用传统自然语言处理方法替代部分大模型操作，以降低成本，但生成的图谱也可能更加嘈杂。据其文档估计，标准方案中图抽取约占索引总成本的 75%——这个比例因具体实现而异，不能直接套用到所有 GraphRAG 系统，但足以说明建图并非没有代价。

某些查询方式同样可能消耗更多资源。例如，Global Search 会从多个社区报告生成中间回答，再对这些回答进行筛选和汇总。它适合回答“整个数据集有哪些主要主题”一类全局问题，但官方也将其描述为资源密集型方法。

因此，下面这些场景需要谨慎评估：

• 高频、低价值的客服问答；
• 对响应时间非常敏感的在线应用；
• 文档和关系持续高频变化；
• 大部分用户问题都属于简单事实查询；
• 普通 RAG 已经能够满足准确率要求；
• 团队暂时没有维护实体与关系数据的能力。

这里真正应该比较的，不是“GraphRAG 是否比普通 RAG 先进”，而是：

GraphRAG 带来的质量提升，能否覆盖额外增加的索引成本、查询延迟和运维复杂度？

如果大多数查询都不需要多跳关系，把所有请求都交给 GraphRAG 并不是理想设计。更合理的办法是对查询进行分流：

简单事实问题   → 全文检索或向量检索
语义相似问题   → 向量检索
明确关系问题   → 图检索
相似＋关系约束 → 向量与图混合检索
全局总结问题   → 社区摘要或分层汇总

这样既能在复杂问题中利用图，又不会让简单问题承担没有必要的成本。

不是什么都做成图，而是为问题选择合适的数据模型

讨论 GraphRAG 的边界，并不是在否定图数据库的价值。恰恰相反，只有先区分哪些问题真正依赖关系，图数据库的价值才会变得具体。

这也提供了一个理解 ArangoDB 多模型能力的角度。

根据 ArangoDB 官方文档，ArangoDB 可以在同一数据库系统中处理 JSON 文档和图关系，并通过 AQL 执行文档查询、全文检索、向量检索和图遍历等操作。其社区版原生支持文档模型、图遍历以及 ArangoSearch 全文检索与向量检索，无需额外授权；部分高级功能（如 SmartGraph、EnterpriseGraph 等）则需参考企业版说明。

这种多模型能力的意义，并不是要求开发者把每一次查询都改造成图查询，而是允许应用根据问题选择不同的数据访问方式。

例如，一套知识应用可以：

• 将原始知识和业务属性保存为文档；
• 对文本执行全文或向量检索；
• 将产品、零件、供应商和订单之间的重要联系表达为图；
• 只在问题涉及关系时执行图遍历；
• 在复杂问题中组合文本相关性与关系约束。

从这个角度看，多模型的价值不是“图可以解决一切”，而是避免把所有问题强行塞进同一种数据模型。

当然，使用同一数据库支持多种检索方式，也不代表系统会自动获得高质量的 GraphRAG。实体如何定义、关系如何验证、查询从哪里开始遍历、扩展多少跳以及如何保留原始证据，仍然需要结合具体数据进行设计。

数据库提供的是能力，能否取得效果仍然取决于数据质量与检索策略。

图 3：合理的知识检索架构不是让所有问题都经过图，而是根据问题类型选择全文、向量、图或混合检索。ArangoDB 的多模型能力可以为这些不同的数据访问方式提供统一的数据基础。

如何判断一个问题是否需要 GraphRAG

在决定引入 GraphRAG 之前，可以先提出以下几个问题：

1. 答案是否分散在多个文档或数据源中？
2. 回答问题是否必须连接两个以上的实体？
3. 这些实体和关系能否被稳定识别？
4. 关系错误是否能够被发现、验证和修正？
5. 向量检索加元数据过滤是否已经足够？
6. 图检索带来的质量提升是否值得额外成本？
7. 用户是否需要查看答案所依据的关系路径？

如果多数答案是否定的，那么普通 RAG 很可能仍然是更合理的起点。

如果答案分散在多个数据源中，问题需要多跳关系才能解决，而且这些关系能够被可靠构建和持续维护，那么 GraphRAG 才更有机会发挥价值。

结语

GraphRAG 解决的核心问题，不是“如何检索更多内容”，而是“如何利用关系组织出更有用的上下文”。

当答案集中在单个片段中，当任务主要依赖语义相似度，当实体关系无法稳定识别，或者当系统对成本和延迟极其敏感时，图检索的收益都可能低于它带来的复杂度。

因此，GraphRAG 不应该成为普通 RAG 的默认升级步骤，也不应该因为系统已经使用了图数据库，就被应用到所有查询中。

判断一个问题是否需要 GraphRAG，有一个相对简单的方法：

如果删除实体之间的关系，我们是否仍然能够可靠地回答这个问题？

如果答案是肯定的，那么图检索大概率是锦上添花，而非雪中送炭。

如果删除关系后，问题中的关键因果、影响范围、依赖路径或业务约束也随之消失，那么这才是 GraphRAG 真正值得出现的地方。