AI 数据库选型：三个数之外的能力层

评审备忘录 · 技术评估版

备忘对象：AI 数据库能力分层评估 事由：三个数之外，能力层怎么落到验收 结论：附条件通过——能力可分四层评，打包与价格不补 用途：架构组会前材料

结论先说：峰值并发、数据增长、可用性窗口这三个数仍然要问；但评审表只写这三个数不够，还要加一列“能力层”。这份备忘不评估任何一家厂商，只把公开材料里的能力拆成可验收的层，再给维护清单和暂缓条件。

事由：结论要能给，但必须带条件

评审会上最常见的两种表态：一种是“可以上”，一种是“再看看”。两种都没写条件。前一种把风险留给上线，后一种把问题留给下次会。

附条件结论的写法不难：可以评，不必现在定；写明哪几条满足后进入 POC，哪几条不满足就暂缓。结论后面跟着条件，才有人知道下一步做什么。议程上不妨留十分钟给这张表，比多听一页功能演示有用。

争议：三个数管撑住，能力层管养住

一方说：容量三问过了，剩下就是比功能。另一方追问：功能验收之后，谁维护语义、谁重建索引、谁负责回滚？这三个数回答不了。

三个数回答的是撑不撑得住：高峰会不会排队，三年后跑不跑得动，停机窗口能接受多长。能力层回答的是养不养得起：语义谁建，推理在哪跑，权限谁管，外围谁维护。两件事不能互相替代。

底座不稳，AI 能力越多越危险；底座稳了，才轮到问上面那一层。表里的“三年”和窗口都是示例假设，不是客户数据；假设变了，结论要重算。

争议：分层不是分产品

一方说：三项能力都在库里，再分四层是多此一举。另一方追问：四层如果由同一个团队交付，交付物能不能列在一张清单上？列不出来，分层就不是多此一举。

四层不是四个产品，是四个问题。把它们分开问，是为了让每一层都有交付物、责任人和验收动作。这张表作为评审附件，四层逐行填。

这四层不一定对应四个交付包。公开材料没写打包、授权、价格，采购时别默认是一个包；本文不猜，也不排名。

如果方案主张让数据尽量留在库内完成 AI 处理，要追问这句话描述的是处理位置，还是全链路边界；模型如果还要调外部 API，出域那一段要单独画在数据流图上。

语义层最容易被低估。它不像查询那样当场出结果，却决定“问数”能不能问对。常见路径是 AI 识别、人工审核、持续学习；人工审核要占业务部门的时间，不是装完软件就自动发生。

争议：维护清单比功能清单长

一方说：厂商有远程支持，维护不是大问题。另一方追问：响应时间、口径变更、索引重建窗口，哪一条写进了合同？

功能清单决定能不能进来，维护清单决定能不能过下去。维护清单至少写五行动作：语义层维护实体与口径，模型做版本管理与效果回归，索引记录构建与重建，同步监控延迟与失败，权限做矩阵与审计复核。

每一行动作后面都要有人名。写不出日常动作，说明这项能力还没有人接手；只写部门，等于没人。维护清单还要写变更触发：业务口径调整、换模型、数据量增长、组织调整。触发条件不写，值班人只能等出了问题再判断。

附件：公开材料摘录

2026 年 10 月 30 日，金仓发布会。公开材料列出三项“库内”能力：库内语义构建、库内计算推理、库内原生安全管控；发布会前后还提到数据准备、检索、应用开发、数据同步。主张是“数据不出库，AI 也能用”。打包方式、授权方式、价格，公开材料没有写。

只摘录，不补。事实只到这里，下面所有分层都是选型方法，不是产品承诺。发布会没有公开报价，本文不猜，也不替厂商补交付范围。

附条件结论：四项验收，缺一项暂缓

结论是附条件通过：可以进入 POC，暂不进入采购。四项验收用你自己的业务问题、你自己的权限、你自己的更新频率去试。

• 答案不能复核，只能给结论、说不清依据，暂缓。
• 低权限账号能绕开权限看到不该看的数据，暂缓。
• 换模型或重建索引没有停写窗口、没有回滚步骤，暂缓。
• 找不到回滚责任人，三方互相指，暂缓。

四项里缺一项，就先停在 POC 门口。补齐再谈采购，补不齐不必勉强表决。

未决事项：把边界图画出来

下次评审带三样材料：一张数据流图，标清数据从哪来、在哪一段被处理、哪一段出了库；一张四层交付清单，写清哪层由厂商交付、哪层由甲方自建；一份维护人名表，附交接记录。

如果数据流图只能画到库边界，库外那一段就单独列一页，不要用一句“走内网”带过。图画不清楚，验收样本也设计不出来。

本文只对本次评审有效。产品会更新，报价会变化，公开材料也会补充；本文不替代 POC，不替任何一方下结论。