当关系本身构成证据时，请使用Graph RAG
内容提要
向量检索擅长按语义找相似文本，但无法证明事实关联。当答案依赖多跳关系（如漏洞库→服务→客户→合同→通知政策）时，应引入Graph RAG：将业务记录建模为节点和有向边，显式记录USES、SUPPORTS、GOVERNED_BY等关系。图回答“什么相连”，原文回答“政策怎么说”，二者缺一不可。遍历需限制边类型、跳数、租户边界与时效，缺失边应如实报告而非推断。
延伸解读
何时需要Graph RAG：多跳关系是关键信号
文章指出，当答案依赖多个业务记录之间的显式关系时，向量检索的相似性匹配不足以证明事实关联。例如漏洞库→服务→客户→合同→通知政策这类多跳问题，需要图来记录USES、SUPPORTS、GOVERNED_BY等有向边。如果问题涉及所有权、依赖、授权或政策范围，且需要证明一条记录为何适用于另一条，就应考虑Graph RAG。反之，自包含的知识库或单文档可答的问题通常不需要。
图与向量检索互补，而非替代
文章强调，图回答“什么相连”，原文回答“政策怎么说”，二者缺一不可。向量检索擅长按语义找到相关文档，但无法建立操作连接；图能显式记录关系，但不应把政策条款复制进图，否则会制造另一个需要维护的真相版本。实际流程中，先用向量检索找到候选实体和段落，再解析到具体记录，沿允许的关系遍历，最后取回源文档解释结果。
遍历必须受限，缺失边应如实报告
文章提醒，图遍历需要明确限制：允许跟随的边类型、跳数、租户或账户边界、连接时效和可接受置信度。这些限制应作为查询和访问约束在结果进入模型前强制执行，而非提示词中的建议。如果服务没有记录所有者，或两份记录对当前合同有分歧，代理应报告该情况，而不是推断路径。例如“我能识别受影响的服务，但无法验证其当前所有者”是有用的回答，可避免事件中向错误客户发送通知。
从现有关系起步，评估路径与来源
文章建议，许多关系已存在于关系表中，如外键连接服务与团队、部署表连接版本与环境。复制到独立图系统可能带来更新延迟和权限模型问题。可考虑在支持图与向量搜索的数据库中直接查询现有表，例如使用SQL属性图和GRAPH_TABLE。决策规则比具体数据库更重要：平台应让团队检查代理使用的确切路径，并将每个节点和边追溯到来源，且受相同访问规则保护。评估时需检查实体解析、关系时效和边界，并验证检索文档是否支持答案。
Q&A
Graph RAG 和向量检索有什么区别？
向量检索擅长按语义相似度查找文本，但无法证明事实之间的关联。Graph RAG 将业务记录建模为节点和有向边，显式记录关系（如 USES、SUPPORTS、GOVERNED_BY），从而回答“什么相连”，而原文回答“政策怎么说”。两者互补，缺一不可。
什么时候应该使用 Graph RAG？
当答案依赖于多跳关系，需要跨实体连接事实、追踪依赖或证明一条记录为何适用于另一条时，应使用 Graph RAG。例如漏洞库→服务→客户→合同→通知政策这类问题。重复的多跳问题、由所有权/权限/依赖/政策控制的决策，以及因缺失或过时连接导致的事故，都是强烈信号。
Graph RAG 中的图是如何构建的？
图由系统已记录的关系构建，每个边可追溯到操作源，而非从文档中推断。将每条记录转为节点，用类型化的有向边记录关系，如服务 USES 库、服务 SUPPORTS 环境、合同 GOVERNED_BY 政策。每条连接携带来源和所有者，必要时添加置信度或生效日期。
Graph RAG 的遍历需要哪些限制？
遍历需指定允许跟随的边类型、最大跳数、适用的租户或账户边界、连接的新鲜度要求以及可接受的置信度。这些限制应作为查询和访问约束在结果到达模型之前应用，而不是作为提示中的建议。
如果图中缺失边或记录冲突，应该如何处理？
如果服务没有记录所有者，或两条记录对哪个合同有效存在分歧，代理应报告该情况，而不是在现有事实之间推断路径。例如回答“我可以识别受影响的服务，但无法验证其当前所有者”是有用的。不支持的结论可能导致通知发送给错误的客户。
Graph RAG 与关系数据库如何结合？
许多关系已存在于关系表中，如外键连接服务与团队、部署表连接服务版本与环境。可将这些事实保留在关系数据库中，使用 SQL 属性图（如 Oracle AI Database 的 GRAPH_TABLE）和 AI 向量搜索在同一数据库内进行图查询和语义检索，避免跨多个存储的协调工作。
