当 AI 遇到关联数据：为什么纯向量检索解决不了复杂关系问题？

公司的新 AI 助手上线了，接入了内部文档、合同库、知识库，向量检索，语义召回，一应俱全。

第一周，大家都觉得挺好用——问个政策，找份合同，比以前搜索框快多了。

但两个月后，问题来了。

有人问："这家供应商和我们的关键客户之间有没有业务往来？"助手一脸茫然。有人问："这个零件的质量问题，历史上追溯到过哪些供应商批次？"助手给出了一段模糊的总结，全是相似内容，没有明确路径。有人问："如果这家合作方出了风险，我们的哪些在途项目会受牵连？"助手只能说：这超出了我的能力范围。

这不是向量检索做坏了，而是它从一开始就没能力做好这类问题。

一、向量检索的本质与边界

向量数据库做的事情，本质上是：把文本、图片、音频等非结构化内容转化为高维向量，通过计算向量空间中的相似度，找到"语义上接近"的内容。

这件事它做得相当好。问"推荐一个和 Netflix 商业模式类似的公司"，向量检索能找到；问"这段话在知识库里有没有相似的描述"，向量检索能找到；问"找所有和'碳中和'语义相关的段落"，向量检索也能找到。

但向量检索有一个根本性的结构限制：它检索的是内容，不是关系。

向量空间里，每个文档是一个独立的点。这些点之间有距离，但没有边——没有"A 是 B 的供应商"，没有"C 担任 D 的法人代表"，没有"项目 E 依赖合同 F 依赖客户 G"。关联关系，不存在于向量的高维空间里。

一旦问题涉及"关系链"，向量检索就到了它的边界。

二、五类向量检索答不上来的问题

以下五类问题，是企业 AI 应用中高频出现的真实诉求，也是纯向量检索系统的共同软肋：

① 多跳路径查询

"公司 A 的主要供应商的主要客户是谁？"这是一个典型的两跳关系问题。向量检索能召回关于公司 A 供应商的文档，却无法在这批文档的基础上进一步推理它们的客户关系，因为它没有维护"供应商—客户"这条边。

② 关系路径追溯

"这款产品的原材料来自哪里，经过了哪些加工环节，现在的库存在哪个仓库？"这是一条端到端的物料追溯链。每一跳都是一条关系，关系之间有方向、有属性。向量模型的相似度计算，无法完成路径追踪。

③ 影响范围评估

"如果某核心供应商断供，哪些在产品受影响，涉及哪些客户合同？"这需要从一个节点出发，沿着图的边做传播分析，计算影响覆盖的范围。这是图算法的核心用途，不是相似度检索能触达的。

④ 隐性关联发现

"这两家公司表面上没有业务往来，但它们的实际控制人是同一个人"——这种隐性连接埋藏在结构里，不在任何一个文档的文本表面。向量检索找不到这种关系，因为没有任何文档在语义层面把这两家公司拉近。

⑤ 时序关系推理

"这个设备在上次故障之后更换了哪些零件，下次同类故障发生的可能路径是什么？"这需要在时序事件上叠加关系推理，是图上的时态查询，向量相似度无从表达"之后"这个结构性含义。

三、为什么这些问题本质上是"图问题"

这五类问题的共同特征是：它们都需要在实体之间沿关系路径游走，答案不在某一个文档里，而在实体与实体的连接关系里。

图数据库的核心设计，正是为了表达和计算这种连接：

• 节点：代表实体（公司、人、设备、合同、产品……）
• 边：代表关系（供应商、客户、控制、依赖、生产、追溯……）
• 属性：为节点和边附加时间戳、金额、状态等上下文信息
• 路径遍历：沿边从一个节点走到另一个节点，可以是一跳、三跳、五跳，甚至不定深度

当数据被建模为图之后，"公司 A 的供应商的客户"就变成了一个 2 跳图查询，在毫秒级内完成；"影响范围评估"变成了从目标节点出发的广度优先遍历；"隐性关联发现"变成了两个节点之间的公共邻居检测；"时序路径推理"变成了带时间属性过滤的路径搜索。

这些都是图数据库的基本操作，不需要任何 AI 加持，就能直接回答。

以悦数图数据库为例，在亿级节点规模下，3~5 跳关系查询稳定在百毫秒以内，支持复杂子图匹配与全图算法并行计算，这是任何向量数据库都无法在同一数据结构上实现的能力。

四、悦数 GraphRAG：让向量与图在同一个推理链路里协同

向量检索解决"在哪里"，图推理解决"怎么连"——两者协同，才能完整回答复杂的企业 AI 问题。

悦数图数据库原生支持 GraphRAG 架构，将图数据库与大模型推理链路深度集成：

第一步：图结构召回

用户提问后，系统先在图数据库上执行图查询，找到与问题相关的实体和关系路径，提取出一个子图作为结构化上下文。这一步确保了关联关系被完整保留，而不是被向量平均掉。

第二步：混合上下文组装

将图结构（实体关系路径）与向量检索结果（语义相关文档片段）一起拼入 Prompt，给大模型提供"有结构、有语义"的双重上下文。结构告诉模型"谁和谁有关系"，语义告诉模型"这些内容说了什么"。

第三步：大模型推理与生成

大模型基于完整的双重上下文生成答案，可以回答"为什么"和"会怎样"，而不只是"是什么"。

第四步：Text2nGQL 自然语言查询

悦数支持将自然语言问题自动转译为 nGQL 图查询语句，让业务用户无需了解图查询语法，直接以对话方式探索图谱，降低了图数据能力的使用门槛。

这套架构已通过与 LlamaIndex、LangChain 的深度集成验证，可以无缝融入企业现有的 AI 应用开发栈。

五、哪些企业场景应该优先考虑图数据库

不是所有企业 AI 应用都需要图数据库，但以下这些场景，建议把图数据库列为必选项：

金融风控与反欺诈：欺诈团伙的认定依赖多层关系网络，团伙成员之间的设备共用、资金流转、担保关系等，都必须在图上识别，向量检索无从触达。

供应链韧性分析：供应商—物料—产品—客户是一条多层依赖链。断供影响范围评估、替代方案寻找、风险传播模拟，都是图遍历问题。

企业知识图谱问答：当知识分布在多个部门、多个系统、多个文档时，知识之间的关联关系往往才是答案所在，而不是单篇文档的语义内容。

IT 运维与故障根因分析：服务依赖图、基础设施拓扑、告警传播路径，都是图结构。根因定位本质上是一个从故障节点反向溯源的图遍历问题。

医疗知识推理与药物研发：疾病—基因—靶点—药物的关联网络，是生物医学 AI 的核心数据结构。纯向量模型没有能力在这张网络上做多步推理。

向量检索是大模型时代的重要基础设施，但它不是企业 AI 的全部答案。当你的业务问题涉及"谁与谁有关系""关系链上发生了什么""如果一个节点出了问题会影响哪些节点"时，你需要的工具是图数据库。

悦数图数据库以亿级图规模、毫秒级多跳查询、动态 Schema、原生 GraphRAG 和 Studio 可视化，提供了企业级图推理能力的完整解决方案。向量解决语义，图解决关系，二者协同，才是真正能支撑复杂企业 AI 应用的基础设施架构。