从向量检索到图检索：RAG 2.0 时代，图数据库凭什么成为新基建？

一、RAG 1.0 的问题，出在哪里？

RAG 这个词，企业 AI 圈子里几乎人人都在说。

原理很清楚：先从知识库里检索出和问题相关的内容，再把这些内容塞给大模型，让它生成回答。这套路线解决了大模型"不知道公司内部知识"的问题，也压制了一部分"幻觉"——毕竟有原文在，模型总不好乱说。

但做过真实项目的人都知道，RAG 落地之后，有几类问题反复出现，靠调参数很难根治：

"答非所问" ——用户问的是"张经理负责哪些项目、这些项目状态怎么样"，系统检索回来的是几段分别提到张经理的文本，每段都沾边，但没有一段说清楚"项目 A 由张经理负责、当前处于验收阶段"这种完整的关联信息。大模型只能拼凑，结果要么遗漏，要么乱填。

"上下文割裂" ——知识库里有一份合同、一封邮件、一张会议纪要，三份文档合起来才能说清楚一件事的来龙去脉。但向量检索按相似度打分，三份文档未必都能进入召回集，即使都召回了，也只是独立的三段文本，大模型不知道它们之间的逻辑关系。

"推理深度不足" ——"这家供应商的上游原材料供应商里，有没有被列入限制名单的？"这个问题需要两跳：先找上游供应商，再核查名单。向量检索做不了多跳，通常只能触达第一层，要么多轮检索拼接，要么直接放弃。

这三个问题指向同一个根源：向量检索把知识存成了碎片，丢失了碎片之间的关系。

RAG 1.0 的天花板，就在这里。

二、RAG 2.0 是什么？为什么是"图"？

解法已经清晰：不能只存文本片段，还要存关系。

这就是 GraphRAG 的核心思路——把知识库从"一堆文档的向量集合"升级为"一张结构化关系图"。每一个实体（人、公司、项目、合同、产品……）是一个节点，实体之间的关联（负责、属于、引用、依赖、触发……）是一条边，整个知识库变成一张可以遍历、可以推理的图谱。

检索的时候，不再是"找最相似的片段"，而是"从相关节点出发，按关系路径走到答案"。

拿刚才"张经理负责哪些项目"的例子来说：图谱里，张经理是一个人物节点，"负责"关系连接着若干项目节点，每个项目节点有状态、里程碑、参与人等属性。一次图遍历，完整的信息就拿到了，不需要拼接，不需要猜测。

这不是概念创新。微软 2024 年发布 GraphRAG 开源框架，几个月内 GitHub 超过 3 万 star；学术界和工业界的评测数据显示，在复杂推理类问题上，GraphRAG 相较传统 RAG 的准确率提升幅度普遍在 30% 到 60% 之间。部分金融风控场景的实测数据更高——因为风控问题本来就是多跳关联推理，向量检索在这里几乎不够用。

RAG 2.0 时代的核心升级，是检索层的范式切换——从向量相似度检索，升级到图结构检索加向量语义检索的混合模式，而图数据库正是这一切的基础设施。

三、图检索和向量检索，到底有什么本质差异？

很多人会问：我在向量数据库里存元数据和引用关系，不就能模拟图检索了吗？

这个想法很自然，但在真实场景里会遇到三堵墙：

第一堵墙：多跳性能

向量数据库没有原生的图遍历机制。要做 3 跳检索，你需要先检索第一层，拿到结果后再做第二次检索，再做第三次——每次检索都是一次全库相似度计算，3 跳就是 3 次。在节点数量达到百万量级时，这个延迟是不可接受的。图数据库的图遍历算法从起点出发沿边走，时间复杂度与图的局部结构相关，而不是与全库规模线性相关，3 跳、5 跳的查询在毫秒级内完成。

第二堵墙：关系语义

向量数据库存的是"相似"，表达不了"A 监管 B"和"A 供货给 B"这种不同性质的关系。图数据库的边可以有类型、属性、方向，关系的语义完整保留。这直接决定了检索的精度——"找所有受监管方"和"找所有供货方"是两个截然不同的查询，向量相似度分不清楚。

第三堵墙：动态更新

企业知识库不是静态的。合同签了、人员变动了、新风险出现了，图谱需要实时更新。向量数据库更新一批文档，通常要重新向量化、重新建索引，代价不低。图数据库支持细粒度的节点和边的增删改，更新一条关系就更新一条边，不影响整图结构，实时性更强。

这三堵墙，决定了"用向量数据库模拟图检索"只是临时方案，在规模和复杂度上都有天花板。真正支撑 RAG 2.0 落地，需要一个原生的图数据库。

四、企业 AI 落地：图数据库承担哪几层价值？

把图数据库接入 RAG 2.0 架构，它不只是一个检索工具，而是在整个 AI 应用链路里承担多层价值：

知识图谱层——让 AI 看懂业务结构

企业的业务逻辑本质上是一张图：组织架构、产品体系、供应链、客户关系、风险传导链……这些都是实体加关系的网络结构。图数据库把这张业务结构图沉淀成机器可读的知识图谱，是 AI 理解"业务是什么"的基础。没有这一层，AI 再聪明也只是在处理孤立的文本，不懂业务逻辑。

检索增强层——让 AI 找到真正相关的信息

在 GraphRAG 架构里，图数据库承担精准检索的角色：先做实体识别，把问题里的关键词映射到图谱节点，再从这些节点出发做图遍历，按关系路径拿到关联信息，再结合向量检索补充语义相关内容，最终组装成结构完整、逻辑连贯的上下文传给大模型。这个流程比纯向量检索精准得多，生成质量自然更高。

推理支撑层——让 AI 做多步分析

金融风险传导、供应链断供影响评估、欺诈团伙识别……这些业务分析本质上是图算法问题：最短路径、社区发现、中心性分析。图数据库内置的图计算能力，让这类多步推理任务不需要大模型硬猜，而是由算法精确计算，大模型只负责把结果翻译成自然语言。

记忆积累层——让 AI 越用越聪明

AI Agent 每次执行任务后，把新的实体、关系、推理结论写回图数据库，图谱持续生长。下一次执行类似任务时，直接调用已有的图谱知识，不需要重新分析。这让 AI 系统具备真正的企业知识沉淀能力，而不是每次都从零开始。

五、从 RAG 1.0 迁移到 GraphRAG，需要做什么？

很多企业已经跑了一段时间的 RAG 系统，现在想升级到 GraphRAG，通常需要走以下几个步骤：

第一步：梳理核心实体类型

不是所有知识都适合图化。先把业务里最关键、最高频出现在问答中的实体类型梳理出来——比如金融行业的"企业-股东-高管-关联交易"、制造业的"产品-供应商-工厂-工序"。把核心实体图化，覆盖 80% 的问答场景，剩下的长尾知识继续用向量存储。

第二步：设计图谱 Schema

实体类型确定后，设计节点的属性字段和边的类型。这一步要结合实际的查询需求来设计，常见的查询路径在 Schema 里要有对应的边类型。Schema 设计好后，图数据库的建模就有了依据。

第三步：建立知识抽取流水线

文档、数据库、API 等原始知识源里的信息，需要经过实体识别和关系抽取，转换成节点和边写入图数据库。这一步通常结合 NLP 模型和业务规则来做，质量直接决定图谱的可用性。

第四步：实现混合检索层

RAG 2.0 的检索通常是图检索加向量检索的混合模式：图检索负责精确的关系路径查询，向量检索负责语义相关内容召回，两路结果合并后传给大模型。这个混合检索层需要针对具体业务场景调优召回策略和融合权重。

第五步：持续图谱维护

图谱上线后不是一次性工程，需要建立持续更新机制：新数据进来触发知识抽取，旧数据失效时标记或删除对应节点和边，定期审查图谱质量。这套机制到位，图谱才能始终保持有效。

整个迁移过程，最难的通常不是技术，而是图谱 Schema 设计和知识抽取质量。这两个地方做好了，RAG 2.0 的效果会有明显的跃升；这两个地方没做好，就算换了图数据库，问答质量也不会有本质改变。

六、悦数图数据库

RAG 2.0 的基础设施之争，核心是图数据库的性能与生态。悦数图数据库以 C++ 原生存储引擎与 Shared-Nothing 分布式架构为基础，在千亿级节点边规模下仍能保持毫秒级多跳遍历性能，为 GraphRAG 的图检索路径提供高性能底座。原生支持图、向量、全文三模混合检索，无需多系统拼接即可完成 GraphRAG 架构的混合召回，大幅降低工程复杂度。率先支持 ISO-GQL 国际标准图查询语言，图谱查询逻辑具备跨平台可移植性；不停服线性扩缩容能力，随知识图谱规模持续增长平滑扩展，无需停机重建索引。悦数 AI 应用平台提供从知识图谱构建、实体抽取到混合检索的完整工具链，帮助企业以最低的工程成本完成从 RAG 1.0 到 GraphRAG 的架构升级，真正让 AI 看懂业务、答对问题。