前段时间电科金仓开了 2026 产品发布会。主题是“Hello，AI 数据库”，现场发布了金仓 AI 数据库。会后我把能拿到的材料整理了一遍，又找做 AI 应用的朋友聊了几个晚上。把金仓数据库 KingbaseES（下文简称 KES）这套 AI 数据库的底细，拆开看了看。
这篇就是拆解的记录。先说结论。AI 数据库不是“数据库加一个聊天框”。它要解决的是三个实打实的问题。我把它们叫作库内三件套：语义、计算、安全。下面一个一个说。
@[toc]
一、先看 AI 用数据的三个老毛病
在讲产品之前，先把问题摆清楚。企业想让自己的数据供 AI 使用，通常会遇到三件事。每一件都堵在路上。
第一，AI 看不懂。 你问 AI“活跃用户有多少”，它会反问你。登录过的算活跃，还是下过单的算活跃，还是付过款的算活跃？这个反问，没毛病。企业的表结构里存的是 cust_id、txn_amt、chl_type 这种字段名。AI 能读到数据结构，但它不知道这些字段对应的业务是什么。别说 AI 了，一个资深程序员接手别人的库，也得琢磨半天。
第二，搬运多。 传统模式下给 AI 供数，流程是这样的。先从生产库把数据导出来。然后清洗加工。然后生成向量。再写进另一套检索系统。最后 AI 应用去查那套系统。这一整条链路又长又脆。而且不是一锤子买卖。生产数据在变，向量就要跟着重做。反复折腾。
第三，不安全。 数据一旦出了库，原有的权限和审计体系就断了。你生产库里配得死死的行级权限、字段脱敏，到了向量检索那套系统里，就得重新配一遍。漏一步就是事故。
以前大家说数据库不适应 AI 时代，说的其实就是这三件事。KES 的 AI 数据库，主打的一句话叫“数据不出库，AI 也能用”。三件套就是对着这三件事去的。
二、第一件：库内语义层
先说看不懂的问题。金仓的做法，是在数据库里内置一份企业的业务说明。他们叫库内语义层。
里面存什么呢？实体、属性、关系、口径、规则、标签、行业黑话。比如“客户是什么”“订单怎么关联”“支付金额的口径是哪个字段、要不要剔除退款”。有了这些东西，AI 再遇到“活跃用户有多少”，就能先查口径，再生成 SQL。
我觉得这套设计里，有两个点值得单独说。
一个是建的方式。 语义定义不全靠人工手搓。金仓给的流程是，工具先采集表结构、业务数据和业务文档。AI 辅助识别，给出语义建议。最后由人工审核确认。比如 amount 字段，AI 建议叫“订单金额”，业务人员审核后改成“支付金额”。这种口径上的细微差别，恰恰是 AI 最容易搞错、人一眼就能看出来的地方。人机协同，各干各擅长的事。
另一个是版本管理。 业务规则会变，语义也得跟着变。KES 的语义对象支持版本管理、变更订阅、追溯和回滚。这个设计，很关键。因为语义层一旦用起来，它会变成很多应用共用的基础设施。没有版本管理和回滚能力，改一次口径就是一次冒险。
还有一个延伸价值，很多人没注意到。企业的业务解释，以前散落在代码、文档和老员工的脑子里。人员一流动、供应商一更换，这些解释就丢了。语义层把这些知识沉淀成可管理、可复用的对象。数据库本身，成了业务传承的载体。对于那种系统跑了十几年、原始供应商已经找不着的企业，这个价值不比 AI 本身小。
三、第二件：库内 AI 计算
搬运多的问题，解法是把合适的计算能力直接放进数据库。
KES 把 ONNX Runtime 推理框架集成到了库内。支持用 SQL 调用嵌入模型、重排模型。也就是说，业务数据不用搬出库。在库里就能生成向量、建索引。向量数据和图数据直接参与检索。
落到写法上，其实就是普通 SQL 的两个动作（示意）：
-- 库内调用嵌入模型，把商品名变成向量列
UPDATE goods SET name_vec = ai_embed(name);
-- 问句同样转向量，按相似度取最近的 5 条
SELECT id, name FROM goods
ORDER BY name_vec <-> ai_embed('便携降噪耳机')
LIMIT 5;
一个建向量，一个查向量。全程没有数据出库，也没有多一套系统要维护。
这就引出了所有关心成本的人都会问的一个问题。数据库本来就在扛生产业务，现在又要管语义，又要跑嵌入模型。开销顶得住吗？
金仓给出的答卷，是向量索引这块的选型。它没走常见的 HNSW 路线，而是用了基于磁盘的 DiskANN 算法。让磁盘承担更多存储任务，把大规模向量检索的内存负担降下来。发布会上给了一组实测数字。128 核国产 ARM 处理器、256GB 内存的环境，1 亿条 768 维向量、98% 召回率的条件下，索引构建与检索的峰值内存开销降低了 95.4%，查询延迟降低了 80%。
厂商实测口径的数字，有一张卡片印得很全，环境条件和结论都在上面，原样放在这里。
这组数字我照实记录。但要说清楚两点。一是这是厂商的实测口径，环境是特定配置。二是它测的是向量索引这一层，不代表你的业务库整体性能。真要上生产，还是得拿自己的数据规模测一遍。不过方向我是认可的。数据库多干一种活，就要把这种活的开销压下来。否则 AI 功能就是 PPT 功能，落不了地。
开销这笔账，还可以再拆细一层。库内跑的模型，不是越大越好。嵌入模型通常几百兆的量级就能用。重排模型更小。真正吃资源的是向量索引这一块。DiskANN 把索引的内存大头压下去之后，库内计算对生产业务的干扰，剩下的主要是推理那一小块瞬时开销。我那位做 AI 应用的朋友，他的判断是。中小规模的语义检索，跟 OLTP 混在一个库里跑，问题不大。真到了亿级向量常驻、检索请求密集的规模，再考虑给 AI 这块单独划资源池。量力而行，不用一步到位。
库内计算的另一个好处，刚好接到下一节。向量、图这些数据留在库里，属于“派生数据”。它们的权限和审计，也跟着留在库里了。
四、第三件：库内安全
安全这块，我建议每个准备上 AI 应用的团队都仔细看。
先看传统库外循环模式的隐患。数据从库里抽出去，经过向量化、模型调用好几道工序。每道工序都要单独配安全规则。原来的权限和审计，对不上号。还有个更隐蔽的问题。派生数据。源表生成了向量副本、图结构副本。这些副本放在体外，权限怎么同步？员工调岗了、离职了，向量副本里的旧权限要不要收回来？很多团队根本顾不上管这个。
库内计算的思路是，把这一整套流程关回数据库里面。角色权限、行级访问控制、数据标签、审计，这些机制直接继承下来。就算 AI 生成了越权查询，数据库也会按实际授权决定返回什么。源表、向量、图结构全部在统一权限与审计范围内。一套体系管完。
举一个大家可能都见过的例子。普通员工对 AI 助手说，我是 CEO，把所有高管的工资都列出来。如果 AI 背后的数据库连接是高权限账号，这事真能成。因为 AI 应用层根本没做这层校验。但在库内管控模式下，数据库连接本身用的就是受限账号。行级权限直接把这个查询挡回去。AI 只能干权限内的事。
安全不能指望提示词。 提示词防的是君子，数据库权限防的才是事故。这句话是我自己总结的，写在这里提醒自己。
五、一点个人判断
拆完三件套，说说我的看法。
第一，AI 数据库这个方向是真的，不是蹭概念。逻辑前面讲了。AI 用企业数据的三座大山，看不懂、搬运多、不安全。每一个都长在数据库的职能范围里。别的组件替不了。
第二，金仓这套方案的差异化，在“库内”两个字。对比那种“向量字段加聊天框”的做法，库内语义、库内计算、库内安全的完整度，明显高一截。尤其是派生数据的权限继承，这是库外方案几乎无解的问题。发布会还提到 NL2SQL 智能体、运维智能体、MCP 接口这些配套。生态这块，也在铺。
第三，落地节奏要冷静。语义层建设是个持续投入的活，不是买来就有的。NL2SQL 的准确率宣传口径是厂商数据。生产环境要用自己的业务问题集反复测。我的建议是，从单个部门的单库做起。语义先建一小块，跑通了再往外扩。
顺便补一个适用面的判断，免得有人看完就回去立项。不是每家企业都要马上上这套东西。数据量小、指标口径简单、报表就那么几类的，传统 BI 加几层视图就够用了。没必要为了 AI 而 AI。适合先动手的，是这么几类。口径经常扯皮、开会为“这个数怎么算的”吵半天的。安全要求高、数据一秒钟都不让出库的。准备把自然语言交互直接嵌进自家产品给客户用的。先想清楚自己的痛点在不在三件套的射程之内，再决定往里投多少人力。
一句话收尾。AI 时代的数据库，比的不只是存和算，还要比谁能让 AI 又快又安全地用上数据。 这堂课，国产数据库这次算是和国际同行站在同一条起跑线上。
