为什么说"没有图数据库的 RAG 是不完整的"？

一家互联网公司的技术总监在 2025 年底做了一次内部复盘。他的团队花了四个月搭建了一套企业级 RAG 系统——文档解析、切块、向量化、检索、大模型生成，整条链路跑通了，Benchmark 测试的准确率达到了 82%。上线之后，前两周用户反馈"不错，比搜索好用"。但到了第三周，问题开始集中爆发：法务团队问"这份合同和去年那份补充协议有冲突吗"，系统回答"根据合同文档，补充协议的效力从属于主合同"——这段话确实在文档里写了，但系统没有发现这份合同的签约方与去年那份补充协议的签约方通过三层股权关联是同一家关联企业，而这正是判断冲突的关键。运维团队问"这次 K8s 节点故障会影响哪些业务线"，系统回答"K8s 节点故障可能导致 Pod 重新调度"——这是通用知识，但系统没有发现这个节点上运行着订单服务的三个 Pod，而订单服务是支付链路的核心依赖。技术总监在复盘报告中写道："RAG 能检索到内容，但检索不到关系——而企业真正需要回答的问题，80% 都和关系有关。"

这个结论不是个例。2026 年，越来越多在 2024-2025 年间部署了 RAG 系统的企业都在经历类似的阵痛：系统在"事实型问答"上表现优异，但在"推理型问答"上频频翻车。根因只有一个——普通 RAG 只检索了内容，没有检索关系。而没有关系推理能力的 RAG，注定是不完整的。

一、普通 RAG 的三层结构性缺口

要理解"不完整"在哪里，需要先把普通 RAG 的工作原理拆开看。标准 RAG 流程是：文档切块 → 向量化 → 存入向量数据库 → 用户提问时检索语义最相似的 Top-K 文档块 → 拼接到大模型提示词中 → 大模型生成回答。这套架构在"答案就写在某段文档里"的场景中表现很好，但在企业真实业务场景中，它有三层结构性缺口。

缺口一：关系平均化——检索到了内容，丢失了关系结构。 向量检索的召回逻辑是语义相似度——问题和文档块在向量空间中距离近就召回。但文档块被切块后，实体之间的关系结构就打散了。一份合同文档里写了"甲方 A 向乙方 B 采购设备，担保方为 C 公司"，这段话被切块后存入向量库。用户问"A 和 C 是什么关系"，检索能找到这段话，大模型能回答"C 是担保方"。但用户问"A 的实际控制人是否与 C 有关联"，系统就答不上来了——因为实际控制人信息在工商数据里、股权关联关系在另一份文档里、C 公司的股东信息又在第三份文档里，三段内容在向量空间中可能相距很远，Top-K 检索根本不会同时召回。关系被切碎了，检索只能找到关系的一个切片，找不到完整的关系链路。

缺口二：多跳断链——每一跳都在丢信息，三跳后几乎归零。 企业推理型问题几乎都是多跳的。"这笔交易有没有风险"需要走 3 跳（交易→对手方→关联企业→违约记录），"这个故障影响哪些业务"需要走 4 跳（组件→微服务→业务系统→业务线→客户影响面），"这个客户适合什么产品"需要走 2-3 跳（客户→相似客户→购买偏好→产品匹配）。普通 RAG 处理多跳的方式是逐跳检索：先检索第一跳的相关文档，提取答案，再根据答案构造第二跳的查询，再检索，再提取……每一跳都有召回率损耗——假设每跳召回率为 80%，三跳后召回率只剩 51%，四跳后只剩 41%。信息在逐跳传递中指数级衰减，三跳之后的推理结果几乎不可信。

缺口三：实体混淆——同名实体无法消歧，推理方向就错了。 企业数据中同名实体极其常见——"张三"可能是客户经理，也可能是投保人，也可能是供应商法人代表。"北京公司"可能是集团总部，也可能是某子公司，也可能是某个区域事业部。向量检索基于语义相似度召回文档块，它无法区分"张三（客户经理）"和"张三（投保人）"——两者在向量空间中几乎重合。当用户问"张三负责哪些客户"时，系统可能召回了投保人张三的理赔记录，把"理赔金额"当成了"客户经理管理的客户保额"。实体消歧是推理的起点——起点搞错了，后面的所有推理都是在错误的方向上走。

三层缺口叠加，导致普通 RAG 在推理型问题上表现拉胯——不是模型不够聪明，也不是向量库不够快，而是架构本身缺失了关系推理这一层。

二、图数据库补上的三块拼图

图数据库接入 RAG 后，系统从普通 RAG 升级为 GraphRAG。补上的是三块拼图——恰好对应三层缺口。

拼图一：关系结构化存储——让关系不再被切块打散。 图数据库的节点和边结构天然表达关系。"甲方 A""乙方 B""担保方 C"是三个节点，"采购""担保"是两条有向边。这些关系不依赖文档切块来保持完整性——它们以图结构的形式存储在数据库中，一次查询就能完整返回"A→担保→C"的关系路径。当用户问"A 和 C 的关联"时，图数据库直接遍历 A 和 C 之间的所有边，返回完整的关系链路，而不是从散落的文档块中拼凑。悦数图数据库在亿级节点规模下支持多跳关系遍历响应时间保持在毫秒至百毫秒级别，确保关系检索不成为 GraphRAG 链路的延迟瓶颈。

拼图二：多跳一次性走完——让信息不再逐跳衰减。 图数据库的多跳遍历能力是关系型数据库和向量库都不具备的。从起始节点出发，沿指定边类型走 N 跳，一次调用就能返回完整的多跳路径。交易→对手方→关联企业→违约记录，四跳路径在图数据库中是一条连续的遍历——不存在"先查第一跳再查第二跳"的串行衰减问题。悦数支持 3～10 跳图遍历在亿级规模下保持百毫秒级响应，让 GraphRAG 的多跳推理一次性完成，信息不再逐跳损耗。

拼图三：实体精确锚定——让同名实体不再混淆。 图数据库中每个节点有唯一 ID 和明确的标签类型——"张三（客户经理）"的节点标签是 Employee，"张三（投保人）"的节点标签是 Customer。即使两者姓名相同，在图中的 ID 不同、标签不同、关联的边也不同。GraphRAG 在实体识别阶段将用户问题中的"张三"锚定到图数据库中的具体节点——通过上下文判断是客户经理还是投保人——后续推理从这个精确锚定的节点出发，不会走错方向。

六维对比的结论很清晰：普通 RAG 和 GraphRAG 不是"好和更好"的关系，而是"不完整和完整"的关系——缺少图数据库的 RAG，就像一个只读了教材正文但没做课后习题的学生，知识面覆盖了，但推理能力没有训练出来。

三、GraphRAG 的五步推理链路

图数据库接入 RAG 后，一条完整的推理链路分五步：

步骤一：意图解析与分流。 大模型接收用户问题，判断这是"事实型问答"还是"推理型问题"。事实型问题（"合同模板在哪里下载"）走普通向量检索路径，直接从文档中召回答案。推理型问题（"这份合同有没有合规风险"）进入 GraphRAG 链路。分流的意义在于——不是所有问题都需要图遍历，简单问题走轻量路径降低延迟，复杂问题走推理路径保证准确性。

步骤二：实体识别与图锚定。 大模型从问题中提取关键实体——"这份合同""合规风险"——并在图数据库中定位这些实体对应的节点。"这份合同"锚定到 Contract 节点，"合规风险"锚定到 Risk 节点。如果实体在图中找不到匹配节点，系统触发追问。这一步解决了实体消歧问题——通过图锚定，确保后续推理从正确的节点出发。

步骤三：图遍历抽取关系子图。 从锚定节点出发，按业务逻辑定义的边类型和跳数进行图遍历。以合同合规风险为例：从 Contract 节点出发，沿"签约方"边找到签约企业节点，沿"股权控制"边找到实际控制人节点，沿"关联交易"边找到关联企业节点，沿"合规记录"边检查是否有违规历史。这一步的输出是一个结构化的关系子图——包含了推理所需的所有关系路径。

步骤四：混合上下文组装。 图遍历返回的关系子图与向量检索返回的文本片段混合组装为增强提示词。关系子图提供"实体之间什么关系"的结构信息，文本片段提供"规则怎么规定"的语义内容。大模型在提示词中同时看到关系路径和规则文本，可以进行真正的推理："该合同的签约方 A 通过三层股权关联了关联企业 B，B 在 2025 年因违规关联交易被监管处罚，根据《关联交易管理办法》第 12 条，本合同存在合规风险。"

步骤五：可解释追溯。 推理完成后，系统不仅给出结论，还返回推理路径——"合同→签约方 A→股权控制→关联企业 B→合规记录→违规处罚→风险结论"。用户可以点击路径中的任何一个节点查看详情，理解推理是怎么得出的。这种可解释性在企业场景中至关重要——合规审计要求每项 AI 决策有完整推理链可追溯。

四、三大企业场景：不完整的 RAG vs 完整的 GraphRAG

场景一：金融风控合规审查。 某城商行的合规审查 RAG 系统上线后，法务团队反馈"系统能找到合同条款，但判断不了合同风险"。原因在于——合同风险不是条款本身的问题，而是签约方关联关系的问题。接入图数据库后，系统从合同节点出发，遍历签约方的股权穿透链路，检查实际控制人是否与已知的受限主体存在关联。一个真实案例：某份贷款合同的签约方在表面上看与银行黑名单无关联，但图数据库通过 4 跳股权穿透发现，签约方的实际控制人通过三家壳公司间接持有一家被列入黑名单的企业 15% 的股份——这条关系链路在文档中完全不可见，但在图中一目了然。

场景二：IT 运维故障影响分析。 某互联网公司的运维 RAG 系统能回答"Kafka 告警阈值是多少"，但回答不了"这次 Kafka 故障影响哪些业务"。接入图数据库后，系统从 Kafka 节点出发，沿"被调用"边遍历下游微服务，沿"支撑"边找到业务系统，最终输出影响面评估："Kafka 延迟影响 3 个下游服务，其中订单服务为核心链路，预计影响下单和支付，建议优先处理。"故障定位时间从 40 分钟缩短到 5 分钟——因为图遍历一次性走完了 4 跳依赖链路，不需要逐跳检索。

场景三：企业知识库智能问答。 某制造企业的知识库 RAG 系统在回答"产品 A 的供应商有哪些替代方案"时，只能检索到产品 A 的供应商列表文档，无法推荐替代方案。接入图数据库后，系统从产品 A 节点出发，沿"供应"边反向找到原材料需求节点，沿"可替代"边找到备选供应商节点，同时检查备选供应商的产能、资质和历史交货记录。输出的不是一个静态列表，而是一个动态推理结果——"产品 A 的核心原材料可由供应商 B（产能充足，但 2025 年有两次延迟交货记录）和供应商 C（产能有限，但历史交货准时）替代，建议按 7:3 分配采购份额。"

三个场景的共同结论：普通 RAG 回答的是"文档里有什么"，GraphRAG 回答的是"根据关系推理出什么"。前者是检索，后者是推理——企业需要的是推理。

五、悦数五项核心能力

GraphRAG 的完整实现，对图数据库提出了五项核心要求：

亿级多跳实时查询。 推理型问题几乎都是多跳的，系统需要在毫秒级完成 3～10 跳的图遍历，否则用户等待超过 3 秒就会放弃使用。悦数在亿级节点规模下支持多跳查询响应时间保持在百毫秒级别，确保 GraphRAG 的推理延迟不影响用户体验。

原生 GraphRAG。 悦数 GraphRAG 不是在向量检索之上外挂一个图查询模块，而是在引擎层面将图遍历与语义检索深度耦合。图遍历负责获取结构化的关系路径，语义检索负责补充文本上下文，两者在同一个查询计划中完成——不是"先查图再查向量"的两步走，而是一次调用完成混合检索。这种原生设计避免了两次 API 调用的延迟叠加，也避免了应用层拼接结果的开发成本。

Text2nGQL 自然语言接口。 GraphRAG 的用户是企业员工而非技术人员。Text2nGQL 让用户用自然语言提问，系统自动转化为图查询。"找出这份合同的签约方在四跳以内关联的所有受限主体"这样的自然语言描述，直接转化为精确的多跳遍历查询。这让推理能力不只服务于技术团队，而是普惠到每一个业务岗位。

动态 Schema 适配场景扩展。 企业 RAG 系统的覆盖场景会持续扩展——今天做合同审查，明天扩展到运维故障分析，后天扩展到供应链管理。每个新场景可能引入新的实体类型和关系类型。悦数动态 Schema 允许在不中断服务的情况下添加新的节点标签和边类型，新场景即接即用，不需要停机迁移。

Studio 可视化调试。 GraphRAG 的推理链路比普通 RAG 复杂得多——开发者需要看到图遍历走了哪些节点、跳了几跳、在哪里断了、为什么没找到预期路径。悦数 Studio 提供图谱可视化界面，支持查询路径可视化展示和节点详情下钻，让开发者和业务人员都能直观检查推理链路的正确性。

说"没有图数据库的 RAG 是不完整的"，不是否定向量检索的价值——向量检索在语义召回上依然是最高效的手段。 但语义召回只是 RAG 的第一层能力，关系推理是第二层。只有把这两层叠加起来，RAG 才真正具备回答企业复杂业务问题的能力。向量检索让 RAG 能"找到相关内容"，图数据库让 RAG 能"推理出正确结论"——前者是基础，后者是完整。2026 年，企业需要的不再是"能检索的 RAG"，而是"能推理的 GraphRAG"——而这一切的起点，就是接入图数据库。