各位，我是老张。今天从一次实战出发，往下拆一层。
前年做过一次多跳查询的优化，场景是供应链溯源。一条物料要追到三级供应商，当时的写法是三次 join 套一个递归 CTE。数据量到千万级之后，这条 SQL 跑一次要四十多秒。后来上了独立的图库，秒级出结果，但同步链路成了新的麻烦。10 月 30 日金仓那场发布会，主题是「Hello，AI数据库」，会上讲到库内知识化。我第一个反应是问一句：图到底怎么不搬出去还能跑。
一、AI数据库 的图，为什么不必建在库外
先说结论。GraphRAG 的图知识，来源本来就是关系表。既然来源在库里，那把它抽出来再建一套，图的就是「查询形态更顺手」。
这个顺手有代价。代价有三处：同步链路、第二套权限、两份存储。所以判断这件事的标准很简单。如果库内能把图查询做得够用，外挂那一套的必要性就下降一大截。发布会第 32 页给了两句原话：「零搬迁·零冗余」「表变 ➡ 图即变」。这两句我拆了三天，下面是我拆出来的东西。
| 维度 | 库外建图库 | 库内图化 |
|---|---|---|
| 数据来源 | 抽取后重建 | 直接读取关系表 |
| 数据新鲜度 | 取决于同步频率 | 与表实时一致 |
| 权限 | 第二套规则 | 沿用库内行级与语义级权限 |
| 存储 | 图与表各存一份 | 一份数据两种视图 |
| 运维 | 多一套备份监控 | 不增加系统数量 |
表格最后一行最容易被忽略。它跟性能无关，跟你要养几套系统有关。那次优化最后怎么收的，我说一下。图库上了，查询从 40 秒降到 2 秒，业务满意。但半年后复盘，同步链路出过四次问题，每次都是一天。
这事对我有影响。从那以后我看任何方案，先看它要不要多养一套东西，再看它快多少。金仓把图化做进内核，动的就是这笔账。不是把图查得更快，是让你少一套系统。
二、AI数据库里，二维表怎么变成图
这一层是关键。关系表是二维的，图是节点加边，中间怎么接上。我的理解是这样：内核里存的仍然是表。图不是另一份数据，是按语义对象推导出来的视图。语义层里的实体、属性、关系，正好对应图的节点、标签、边。口径和规则对应的是边的方向与过滤条件，标签对应的是节点的分类。
换句话说，图化不是复制，是映射。映射规则写在语义对象里，随时可改。这也解释了「表变 ➡ 图即变」为什么成立：底层只有一份数据，映射是实时算的。表改了，图就是新的。
sql
-- 示意：图视图从关系表推导，不产生第二份存储
-- 节点来自供应商表，边来自供货关系表
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数据库的做法介于两者之间。数据仍在表里，但图视图给了优化器一条更短的路。
我的判断是：这条路对三到五跳、边数中等的场景够用。再深、再密的图，交给专业图库更省事。这是实话，也是选型时该问清的地方。工程上最怕的不是边界，是不知道边界在哪。
再补一个观察。图库快，是因为它把关系预先存成了邻接表，查的时候不用 join。这一步预建本身要花时间，也要占空间。库内省掉的正是这一步预建，代价是每次查询时多一次映射计算。
这两者在不同数据量下各有胜负。数据在千万级以下，库内基本够用。上到亿级、跳数又深，专业图库更合适。我不认为这是缺点。选型本来就是在数据量和系统数量之间做交换。
四、零搬迁的边界在哪
发布会讲的是能力，我补一段边界。这三条是我自己的判断，官方没写。写出来不为挑刺，是让你评估的时候手上有张清单。
第一，图关系必须能从表推导出来。 如果关系藏在文档里、藏在日志里，那推不出来，还是得先入库。
第二，多跳深度别指望无限。 五跳以内是常态，十跳以上建议另想办法。
第三，复杂图算法不是这条路的强项。 社区发现、中心度计算这类，专业图库的库更全。
三条合起来看，说的是适用范围，不是能力高低。AI数据库这条路线解决的是「图要不要单独存」，不是「图能不能取代图库」。任何方案都有适用区间，把区间说清楚，比只讲能力更让人敢用。我在别的项目上吃过反过来的亏。方案讲得全能，上线后发现三个场景不支持，返工比重做还贵。
金仓这次讲的多是具体做法，很少堆优势词，这种写法我认。讲得具体就能被验证：它说什么，你抬脚就能去试。
五、六个容易读漏的细节
第一个，语义对象是图化的前提。 没有实体和关系的定义，表变不出图。所以这条路的第一件事是把语义建起来，不是先建索引。
第二个，图化不产生新存储。 这一点决定了备份、容灾、扩容都不用翻倍。它是库内和库外最大的结构差异，也是成本差的主要来源。
第三个，权限跟着数据走。 图查询走的是库内权限，行级策略照样生效。不用在第二套系统里重配一遍，也不用担心两边规则对不上。
第四个，语义要建全，不是建个实体就完事。 只建实体不建关系，图查出来全是孤点。这不是工具的问题，是定义没做完。六要素是并列着讲的，实体、属性、关系、口径、规则、标签，缺一样语义层就不完整。建语义也没法一口气做完，我的建议是按问题倒推，业务问什么就建什么，用不上的先放着。
第五个，关系字段得干净。 关系表里用字符串存的关系最容易出问题，同一条边写成两个值，图就断了。我在一个项目上统计过，一张关系表里百分之七的记录，父节点字段带前后空格。
第六个，表的约束会被继承。 早年在图库里把一条边建重了，同一个供应商两条关系，多跳时结果翻倍。这类错误在关系表里很难发生，有主键和外键拦着。库内图化接了这份遗产，原来的清洗脚本和校验规则，一样都不用重写。
前三条讲结构，后三条讲工程，六条连起来其实是一件事。AI数据库 这条路把能力收回内核，连带把运维的复杂度也收了回去。这也是我看这套方案时最看重的一点。
六、AI数据库里，图和向量怎么配合
GraphRAG 里，图和向量不是二选一。向量解决「哪段内容和问题最像」，图解决「这些内容之间怎么连」。两条一起用，才能回答那种既要语义又要关系的问题。比如「和这家供应商有共同上游的企业，还供过哪些同类物料」。
这类问题只靠向量答不了，只靠图也答不准。先召回再扩展，是常规打法。发布会上给的是一套组合：库内向量化、库内图化、库内语义。三样都在一个引擎里。顺序也有讲究，向量先缩区间，图再扩关系。反过来做，节点数会先爆炸。
这一点在库内实现里不新鲜。AI数据库 把两件事放进同一个执行引擎，省掉的是一次跨系统搬运。写 SQL 的人感受不明显。你写的是一条带向量条件的图查询，先走哪一步由优化器决定。对一个运维来说，这个组合最大的好处是只有一套监控要盯。三样能力一套备份，一套权限，一套告警。
最后给三条我自己的判断，供参考。第一，看你的问题里多跳占多少，一半以上是多跳，图化值得做。第二，看关系能不能从表里推，推不出来就先解决入库。第三，看团队愿不愿意维护语义，不愿意的话，这套东西用不起来。
这三条比任何跑分都实在。能力再强，也得有人把定义写对。定义写错，图化只会把错误放大得更快。金仓这一轮把工具链铺好了，剩下的活还是人的。
写在最后
图不在库外建，靠的不是把图塞进数据库，是把图看成表的一种视图。想通这一点，后面的事都顺了。数据只有一份，视图可以有很多种，这也是它比库外方案省事的地方。
这个视角一变，很多争论就没意义了。比如「图库要不要上」，问题该换成「现有查询能不能用视图表达」。能表达的部分留在库里，不能表达的部分再上专用工具，这才是我理解的零搬迁。放到 AI数据库 这个语境里，它的意义更清楚。RAG 要的不是图本身，是图提供的多跳关系。关系能在库内算出来，就不必为了它再养一套系统。
AI数据库 这个词容易被讲虚，原因也在这儿。虚的不是概念，是没往下拆到存储那一层。金仓这一步真正动的是内核，不是包装。视图、语义、权限三样都在原来的位置上。
你们现在那张图，是单独存的还是从表推的？评论区说说。
我是底层玩家老张。咱不聊概念，只聊源码和压测跑出来的东西。