各位，我是老张。今天从一次实战出发，往下拆一层。

前年做过一次多跳查询的优化，场景是供应链溯源。一条物料要追到三级供应商，当时的写法是三次 join 套一个递归 CTE。数据量到千万级之后，这条 SQL 跑一次要四十多秒。后来上了独立的图库，秒级出结果，但同步链路成了新的麻烦。10 月 30 日金仓那场发布会，主题是「Hello，AI数据库」，会上讲到库内知识化。我第一个反应是问一句：图到底怎么不搬出去还能跑。

## 一、AI数据库 的图，为什么不必建在库外

先说结论。GraphRAG 的图知识，来源本来就是关系表。既然来源在库里，那把它抽出来再建一套，图的就是「查询形态更顺手」。

这个顺手有代价。代价有三处：同步链路、第二套权限、两份存储。所以判断这件事的标准很简单。如果库内能把图查询做得够用，外挂那一套的必要性就下降一大截。发布会第 32 页给了两句原话：「零搬迁·零冗余」「表变 ➡ 图即变」。这两句我拆了三天，下面是我拆出来的东西。

|维度|库外建图库|库内图化|
|:-:|:-:|:-:|
|数据来源|抽取后重建|直接读取关系表|
|数据新鲜度|取决于同步频率|与表实时一致|
|权限|第二套规则|沿用库内行级与语义级权限|
|存储|图与表各存一份|一份数据两种视图|
|运维|多一套备份监控|不增加系统数量|

表格最后一行最容易被忽略。它跟性能无关，跟你要养几套系统有关。那次优化最后怎么收的，我说一下。图库上了，查询从 40 秒降到 2 秒，业务满意。但半年后复盘，同步链路出过四次问题，每次都是一天。

这事对我有影响。从那以后我看任何方案，先看它要不要多养一套东西，再看它快多少。金仓把图化做进内核，动的就是这笔账。不是把图查得更快，是让你少一套系统。

## 二、AI数据库里，二维表怎么变成图

这一层是关键。关系表是二维的，图是节点加边，中间怎么接上。我的理解是这样：内核里存的仍然是表。图不是另一份数据，是按语义对象推导出来的视图。语义层里的实体、属性、关系，正好对应图的节点、标签、边。口径和规则对应的是边的方向与过滤条件，标签对应的是节点的分类。

换句话说，图化不是复制，是映射。映射规则写在语义对象里，随时可改。这也解释了「表变 ➡ 图即变」为什么成立：底层只有一份数据，映射是实时算的。表改了，图就是新的。

![11.10-老张-图1-表变图的映射.png](https://developer.qcloudimg.com/http-save/yehe-12565093/59ea034a72ee1a58f86b945ae8765b4b.png)

```
-- 示意：图视图从关系表推导，不产生第二份存储
-- 节点来自供应商表，边来自供货关系表
SELECT s.supplier_id   AS node_id,
       s.supplier_name AS label,
       r.parent_id     AS parent
FROM   supplier s
JOIN   supply_rel r ON r.child_id = s.supplier_id
WHERE  r.rel_type = 'supply'
  AND  r.valid_to IS NULL;   -- 只取当前有效关系
```
这段 SQL 的重点在最后一行。关系表天然带有效期，图库通常没有这个概念。带时间维度的图，在库外建就得自己补字段。放在库里，就是一次过滤。

这里补一句我的理解，不一定严谨，有不同看法的欢迎拍砖。映射层做得好不好，看一件事：改一个语义对象，图视图是不是立刻跟着变。如果改完还要重建一次图，那就不是视图，是物化。物化就要同步，同步就又回到外挂那套问题。

发布会那页写的原话是「表变 ➡ 图即变」。我理解重点是那个「即」字。AI数据库这条链路上，语义对象是定义源，只有一份。金仓把六要素放进语义层，为的就是让映射有据可依。没有实体和关系的定义，表变不出图。

## 三、AI数据库的多跳推理怎么跑

以前慢，不是因为图难算，是因为 join 次数随跳数线性增长。跳三层三次 join，跳五层五次 join。每次 join 都要扫一遍，成本叠加得非常快。

图库的做法是预建邻接表，跳数不再转成 join 次数。代价是图得单独存，还得跟着表更新。AI数据库的做法介于两者之间。数据仍在表里，但图视图给了优化器一条更短的路。

![11.10-老张-图2-多跳的两条路.png](https://developer.qcloudimg.com/http-save/yehe-12565093/d83f042a1800a4231ad698735b1e3838.png)

我的判断是：这条路对三到五跳、边数中等的场景够用。再深、再密的图，交给专业图库更省事。这是实话，也是选型时该问清的地方。工程上最怕的不是边界，是不知道边界在哪。

再补一个观察。图库快，是因为它把关系预先存成了邻接表，查的时候不用 join。这一步预建本身要花时间，也要占空间。库内省掉的正是这一步预建，代价是每次查询时多一次映射计算。

这两者在不同数据量下各有胜负。数据在千万级以下，库内基本够用。上到亿级、跳数又深，专业图库更合适。我不认为这是缺点。选型本来就是在数据量和系统数量之间做交换。

## 四、零搬迁的边界在哪

发布会讲的是能力，我补一段边界。这三条是我自己的判断，官方没写。写出来不为挑刺，是让你评估的时候手上有张清单。

**第一，图关系必须能从表推导出来。** 如果关系藏在文档里、藏在日志里，那推不出来，还是得先入库。

**第二，多跳深度别指望无限。** 五跳以内是常态，十跳以上建议另想办法。

**第三，复杂图算法不是这条路的强项。** 社区发现、中心度计算这类，专业图库的库更全。

三条合起来看，说的是适用范围，不是能力高低。AI数据库这条路线解决的是「图要不要单独存」，不是「图能不能取代图库」。任何方案都有适用区间，把区间说清楚，比只讲能力更让人敢用。我在别的项目上吃过反过来的亏。方案讲得全能，上线后发现三个场景不支持，返工比重做还贵。

金仓这次讲的多是具体做法，很少堆优势词，这种写法我认。讲得具体就能被验证：它说什么，你抬脚就能去试。

## 五、六个容易读漏的细节

**第一个，语义对象是图化的前提。** 没有实体和关系的定义，表变不出图。所以这条路的第一件事是把语义建起来，不是先建索引。

**第二个，图化不产生新存储。** 这一点决定了备份、容灾、扩容都不用翻倍。它是库内和库外最大的结构差异，也是成本差的主要来源。

**第三个，权限跟着数据走。** 图查询走的是库内权限，行级策略照样生效。不用在第二套系统里重配一遍，也不用担心两边规则对不上。

**第四个，语义要建全，不是建个实体就完事。** 只建实体不建关系，图查出来全是孤点。这不是工具的问题，是定义没做完。六要素是并列着讲的，实体、属性、关系、口径、规则、标签，缺一样语义层就不完整。建语义也没法一口气做完，我的建议是按问题倒推，业务问什么就建什么，用不上的先放着。

**第五个，关系字段得干净。** 关系表里用字符串存的关系最容易出问题，同一条边写成两个值，图就断了。我在一个项目上统计过，一张关系表里百分之七的记录，父节点字段带前后空格。

**第六个，表的约束会被继承。** 早年在图库里把一条边建重了，同一个供应商两条关系，多跳时结果翻倍。这类错误在关系表里很难发生，有主键和外键拦着。库内图化接了这份遗产，原来的清洗脚本和校验规则，一样都不用重写。

前三条讲结构，后三条讲工程，六条连起来其实是一件事。AI数据库 这条路把能力收回内核，连带把运维的复杂度也收了回去。这也是我看这套方案时最看重的一点。

## 六、AI数据库里，图和向量怎么配合

GraphRAG 里，图和向量不是二选一。向量解决「哪段内容和问题最像」，图解决「这些内容之间怎么连」。两条一起用，才能回答那种既要语义又要关系的问题。比如「和这家供应商有共同上游的企业，还供过哪些同类物料」。

这类问题只靠向量答不了，只靠图也答不准。先召回再扩展，是常规打法。发布会上给的是一套组合：库内向量化、库内图化、库内语义。三样都在一个引擎里。顺序也有讲究，向量先缩区间，图再扩关系。反过来做，节点数会先爆炸。

这一点在库内实现里不新鲜。AI数据库 把两件事放进同一个执行引擎，省掉的是一次跨系统搬运。写 SQL 的人感受不明显。你写的是一条带向量条件的图查询，先走哪一步由优化器决定。对一个运维来说，这个组合最大的好处是只有一套监控要盯。三样能力一套备份，一套权限，一套告警。

最后给三条我自己的判断，供参考。第一，看你的问题里多跳占多少，一半以上是多跳，图化值得做。第二，看关系能不能从表里推，推不出来就先解决入库。第三，看团队愿不愿意维护语义，不愿意的话，这套东西用不起来。

这三条比任何跑分都实在。能力再强，也得有人把定义写对。定义写错，图化只会把错误放大得更快。金仓这一轮把工具链铺好了，剩下的活还是人的。

## 写在最后

图不在库外建，靠的不是把图塞进数据库，是把图看成表的一种视图。想通这一点，后面的事都顺了。数据只有一份，视图可以有很多种，这也是它比库外方案省事的地方。

这个视角一变，很多争论就没意义了。比如「图库要不要上」，问题该换成「现有查询能不能用视图表达」。能表达的部分留在库里，不能表达的部分再上专用工具，这才是我理解的零搬迁。放到 AI数据库 这个语境里，它的意义更清楚。RAG 要的不是图本身，是图提供的多跳关系。关系能在库内算出来，就不必为了它再养一套系统。

AI数据库 这个词容易被讲虚，原因也在这儿。虚的不是概念，是没往下拆到存储那一层。金仓这一步真正动的是内核，不是包装。视图、语义、权限三样都在原来的位置上。

你们现在那张图，是单独存的还是从表推的？评论区说说。

我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。


前年做过一次多跳查询的优化，场景是供应链溯源。一条物料要追到三级供应商，当时的写法是三次 join 套一个递归 CTE。数据量到千万级之后，这条 SQL 跑一次要四十多秒。后来上了独立的图库，秒级出结果，但同步链路成了新的麻烦。10 月 30 日金仓那场发布会，主题是「Hello，AI数据库」，会上讲到库内知识化。我第一个反应是问一句：图到底怎么不搬出去还能跑。

AI数据库 GraphRAG 怎么落地？零搬迁式图化与多跳查询

GraphRAG 的常见做法是抽数据建独立图库，代价是同步链路和两套权限。库内知识化走的是另一条路：二维表直接图化，零搬迁零冗余。本文拆这条链路在内核里靠什么支撑，以及它的能力边界。

数据库

人工智能

架构设计

金仓AI数据库以库内图化实现GraphRAG，消除外挂图库的同步与存储负担。图视图由关系表实时映射，支持多跳查询且表变图即变，兼顾性能与运维简化，是零搬迁的选型思路。

代码解释

GraphRAG

容灾

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

AI数据库 GraphRAG 怎么落地？零搬迁式图化与多跳查询-腾讯云开发者社区-腾讯云

AI数据库 GraphRAG 怎么落地？零搬迁式图化与多跳查询

AI数据库 GraphRAG 怎么落地？零搬迁式图化与多跳查询

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐