大家好，我是数据库小学妹👋我踩过的坑，你别再踩。
10 月 30 日，电科金仓要在北京办「Hello, AI数据库」2026 产品发布会。要发 AI 数据库演进路线，下午还有开发者大会。朋友圈转得挺热。我翻了翻邀请函，上午讲路线和产品，下午分专场，内核能力、智能运维、开发者实践各占一块。议程排得挺满，说明厂商自己也知道，光讲概念已经不够了，得拿能力说话。
我想起上个月陪一个团队做的 POC。那是一家做设备售后服务的公司，工单系统跑了七八年，知识库攒了二十多万条处理记录。他们想上问答，想让客服一句话就能查到历史工单怎么处理的。方案评审会上，三家厂商都来了，每家都说自己能做。
三家厂商，PPT 第一页都写着“AI 数据库”。功能清单一家比一家长。向量检索、混合查询、智能调优、自然语言运维，名词一个不少。可真到验收，问题就来了：这些能力到底落在哪一层，能不能一起用，出了事谁兜底。同一批数据摆进去，只跑五道题。结果不是谁更强，而是 AI 落在哪一层。
数据是造的，不是客户生产库。300 万条工单，20 万条知识片段，5 年设备台账。8 核 32GB，单并发。这个量级不算大，但足够让“空表跑得飞快”的方案现原形。表结构、用例和示意 SQL 都在下面，照着能复现。这篇讲三件事：AI 数据库是什么，怎么验收，什么场景先别上。看完你至少能拿着这五道题，去问下一家厂商。
AI数据库是什么？先给一句能落地的定义
AI 数据库，是把 AI 负载要用的能力，做进数据库的一套栈。存储、检索、优化、运维、开发接口，五层都要。别把它当成某一款产品。给关系库加个向量字段，也不算。
拆开看就五层。数据能不能同库同事务。检索能不能把向量、关键词、标量放在一次查询里。优化器看不看得见向量代价。运维自治有没有边界和审计。现有 SQL 和存储过程要不要重写。五层断一层，AI 就只能停在演示。
2026 年 7 月，中国信通院启动了一份报告的编制。报告叫《智能数据库技术研究报告》。金仓也出席了启动会。10 月 30 日的发布会，又会把“能力全景”摊开来讲。行业从“有没有 AI”往“能不能验收”走。
AI数据库和传统数据库，差的不只是向量
先看三代形态。同样是“AI 数据库”，AI 能力放的位置不一样。
| 形态 | AI 能力放在哪 | 典型做法 | 适合谁 | 代价 |
|---|---|---|---|---|
| 外挂式 | 库外 | 独立向量库加模型服务，应用层拼接 | 快速验证、纯向量场景 | 跨库一致性、双写补偿、多套运维 |
| 内置式 | 关系库内 | 向量类型和索引进库，混合排序靠应用 | 已有关系库、想低成本加检索 | 优化器和事务边界要看实现 |
| 原生式 | 内核与工具链 | 数据、检索、优化、运维、开发一起设计 | AI 负载是主线、要长期跑 | 迁移和治理成本高 |
外挂式上线快，团队熟。问题出在“数据要碰面”的时候。业务状态在关系库，向量在向量库。一次查询跨两个系统，先后顺序就成了架构问题。
内置式把向量放进同一个库，可“能存”和“能用好”是两件事。排序、优化器代价、事务边界，仍要一层层看。
原生式最容易被讲成口号。判断标准只有一条。五层能力是不是同一套设计，而不是五个模块拼起来。下面按五层拆。每层给一个验收动作，也给我在 POC 里看到的失败信号。
第一层：数据层，AI 要用的数据能不能同库同事务
第一个场景很普通。工单状态在业务表。处理记录被切成知识片段。向量存在另一套库里。客服改完工单状态，应用再异步写向量。中间隔了几百毫秒。
就是这几百毫秒出事。用户刚关单，问答里还能召回“处理中”的旧片段。第一反应是加补偿任务。补偿能修最终状态，修不了中间态。查询落在窗口里，还是会答错。
验收动作就一句。业务字段更新和向量写入，放进同一个事务。失败一起回滚。再查“已关闭工单”，不能召回“处理中”的向量。做不到，这一层就不算过。
KES 在 2025 年 7 月的发布会上，讲清楚了 V9 的“五个一体化”。键值、文档、向量这些模型，补进同一套引擎。关系、时序、GIS 这些老模型，也在同一套引擎里。支持几种模型不是终点。少一次跨库双写，才是。
第二层：检索层，混合检索不是“向量加过滤”
第二道题，准备了 30 条真实问法。10 条带工单号，10 条是口语描述，10 条混着型号和业务条件。看 Recall@10，也就是前 10 条里有没有该找的那条。
| 查询类型 | A 纯向量 | B 向量加过滤 | C 向量加关键词加过滤 |
|---|---|---|---|
| 精确单号 10 条 | 4 | 6 | 10 |
| 语义描述 10 条 | 8 | 8 | 9 |
| 混合条件 10 条 | 6 | 7 | 10 |
| 合计 Recall@10 | 18/30 | 21/30 | 29/30 |
数字来自演示环境，别当 benchmark。换个语料或模型，结果会变。纯向量对“意思像”敏感，对“单号对”不敏感。用户输入一串工单号。它可能召回一堆语义相近、单号不对的记录。标量过滤能筛范围，筛不掉字面。
混合检索要三路。向量管语义，关键词管字面，标量管范围。三路结果怎么合并、怎么去重、谁先谁后，才是工程难点。只做“向量加过滤”，精确查询会漏。只做“关键词加过滤”，口语问法会漏。
KES 这边，向量与标量可以原生混合查询。公开报道提到支持 IVFFlat、HNSW 索引。
示意 SQL 长这样。函数名和写法以所用版本为准，别直接抄。
SELECTticket_id,title,status,created_atFROMt_ticketWHEREtenant_id=:tenant_idANDstatus='closed'ANDcreated_at>=:start_timeORDERBYVECTOR_DISTANCE(embedding,:query_vec,'cosine')LIMIT10;这条 SQL 只解决了“向量加标量”。要让关键词也进来，还得看全文索引。能不能在一个计划里合并多路召回，是关键。POC 时别只问“支不支持向量”。拿精确单号、错别字、型号加口语三种问法，各跑一遍。跑完看 Recall，不要看演示页那几条漂亮结果。
第三层：优化层，数据库能不能解释自己的选择
第三道题，看执行计划。同一句 SQL，数据从 100 万涨到 300 万。统计信息没更新。计划会不会翻。向量索引有没有被选中。过滤是在扫描里完成，还是扫完再滤。
我一开始只看耗时。后来发现，缓存会把耗时盖住。第一次 800 毫秒，第二次 200 毫秒。你以为优化生效了，其实数据进了内存。验收要看四个数。估算行数和实际行数差多少。循环次数高不高。共享读是不是在啃磁盘。临时文件有没有落盘。
EXPLAIN(ANALYZE,BUFFERS)SELECTticket_id,titleFROMt_ticketWHEREtenant_id=:tenant_idANDstatus='closed'ORDERBYVECTOR_DISTANCE(embedding,:query_vec,'cosine')LIMIT10;失败信号很直接。优化器只会说“加索引”，看不到向量距离的代价。统计信息过期后，计划从索引扫描退化成全表扫描。换一个过滤条件，计划又变一次。调参数救不了这类问题。得看优化器有没有把向量代价算进去。
2026 年上半年，信通院两项测试结果公布。一项考数据库管理系统智能化基础能力。一项考融合型数据库基础能力。KES 两项都通过。公开报道称，它成为全行业首家通过融合型数据库测试的厂商。测试细项，公开报道没逐条展开。但至少说明，智能化能力能被第三方测试。选型时，这类结果可以写进验收表。但不能替代你自己的 EXPLAIN。
第四层：运维层，自治的边界比自治的速度重要
第四道题，我们模拟了一次“统计信息过期加慢查询突增”。告警响了，看三家怎么处理。
A 方案只告警，处理靠人。B 方案给建议，点不点由人。C 方案能做一些自治动作，但要先配策略。我们追问四个问题。它能改什么。影响范围多大。能不能回滚。谁签字。答不全，自治就只能算“辅助”。
这层最容易被演示带偏。大屏上一条曲线下去，看起来很智能。真到生产，改一个参数可能影响几百个会话。没有影响范围、回滚点和审计记录，动作越快越危险。
的卢运维智能体讲自然语言运维。故障预警准确率是 98% 以上。10 月 30 日的开发者大会，设了内核能力与智能运维专场。会讲智能性能调优、性能自治和 KEMCC 运维智能体。方向是从“人看告警”往“系统先看见、再给动作”走。但自治到什么程度，要看版本和策略。POC 里我们标了“部分通过”。
第五层：开发层，现有 SQL 和存储过程要不要重写
第五道题，最不性感，也最花钱。团队有 200 多个存储过程，业务 SQL 几万行。换库之前，先问这些 SQL 要不要重写。
验收动作很土。挑三条最常用的存储过程。一条查报表，一条做批处理，一条带事务。看能不能不改 SQL 就跑。再看驱动、连接池、ORM 要不要换。再看 AI 接口，是只能用厂商 SDK，还是能通过标准协议接进去。
A 方案两套 SDK。B 方案 SQL 兼容，AI 函数是厂商私有。C 方案 SQL 兼容。KES MCP Server 已经开源在 Gitee 上，AI 客户端可以通过标准接口连库。发布会还要讲 PL/SQL 到 PL/AI、KES Plus 的原生 AI 编程。这两项没写进通过项，因为还在路线里，等版本落地再验。
失败信号不是“跑不动”，是“能跑但没人维护”。两套 SDK、两套权限、两套监控，最后都压在同一个人身上。选型时把迁移工时算进去，比看跑分值钱。
五层摆一起，POC 结果说明什么
三家方案，五道题，结果如下。
| 关卡 | A 外挂式 | B 内置式 | C 融合型路线 |
|---|---|---|---|
| 数据同库同事务 | 不通过 | 部分 | 通过 |
| 混合检索三路召回 | 不通过 | 部分 | 通过 |
| 计划可解释 | 不通过 | 部分 | 通过 |
| 运维自治有边界 | 不通过 | 部分 | 部分 |
| 开发迁移成本 | 部分 | 通过 | 通过 |
C 过了四层半。运维自治算半个通过，PL/AI 还要等版本。A 也不是一无是处。纯向量、离线跑批、团队没有 DBA，它更轻。B 适合已经在关系库上跑、只想加一层检索的团队。
AI 数据库不是功能清单，是能力栈。任何一层断了，AI 都只能停在演示。三家都能在 PPT 上写“支持 AI”，差别在第五层之后还能不能落地。
AI数据库怎么选？先问五个问题
先问自己五句。第一，AI 查询和业务写入，要不要在同一个事务里？要，纯外挂先排除。第二，查询里精确词和语义词各占多少？精确多，必须有全文或关键词路。第三，能不能接受优化器看不见向量代价？不能，就要求计划可解释。第四，自治动作要不要人签字？要，就要求审计、回滚和审批。第五，现有 SQL 和存储过程有多少？多，就先算迁移工时。
五句里只要一句答不清，先别签合同。
边界：三种情况，先别急着上 AI 数据库
第一种，指标口径没统一。同一个“退款率”，三个部门三个算法。AI 只会把错误答案说得更自信。先把指标治理完，再谈检索。
第二种，交易高峰已经打满。主库 CPU 常年 80%，还想把 AI 查询混进来。先做资源隔离，或者走只读副本。融合不是把两类负载硬塞进一个实例。KES 的核心定位是 OLTP。AI 能力落在组件和场景层。
第三种，没有召回评测集。POC 只跑演示页那几条问题，结论一定是“效果不错”。先攒 100 条真实问法，标好标准答案，再选库。没有评测集，换什么库都是盲选。
KES 这条路线，强在哪，边界在哪
说回这场发布会。我看这条路线，重点不在名词多少，在五层有没有对应物。五层都有落点和边界。发布会给的是路线，版本给的是能力，POC 给的是结论。
KES 这条融合型路线，强在把五层放在一套底座里，少一次搬运。2026 年上半年两项权威测试。融合型数据库首家通过。这些能写进验收表。但它也有边界。交易高峰、权限治理、版本差异，仍要一项项验。
避坑清单：三个坑，我踩过两个
第一，把“支持向量”当成“AI 数据库”。向量只是第二层的一块。数据同不同库、事务同不同步、计划解不解释，才是分水岭。
第二，用空表和小数据做 POC。混合检索的召回。索引算子的选择。统计信息的更新。数据量小，这些都看不出来。涨到百万级才现形。那时候已经签完合同了。
第三，我自己就踩过。我曾经把发布会的能力全景，当成“当前版本就有”。后来做验收才发现。有些能力在路线里。有些要开参数。有些只在特定版本。签合同前，我会把每一项写成用例。什么版本。多大数据量。什么通过标准。谁来签字。写不清的，先不写进合同。
写在最后
AI 数据库的答案，得去五层能力栈里找。数据要同库。检索要三路。计划要能解释。自治要有边界。开发要算迁移成本。五层都过，才叫能用。过三层，叫能演示。
10 月 30 日的发布会，我会去听。不听它讲多少新名词。只看五层里哪几层有版本、有测试、有案例。KES 这条路线，胜在五层长在同一套底座上。但边界，仍要自己划。
你们做 AI 数据库 POC 时，最先测哪一项？评论区说说，我帮你把验收用例补全。我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋
