大家好我是数据库小学妹我踩过的坑你别再踩。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 条混着型号和业务条件。看 Recall10也就是前 10 条里有没有该找的那条。查询类型A 纯向量B 向量加过滤C 向量加关键词加过滤精确单号 10 条4610语义描述 10 条889混合条件 10 条6710合计 Recall1018/3021/3029/30数字来自演示环境别当 benchmark。换个语料或模型结果会变。纯向量对“意思像”敏感对“单号对”不敏感。用户输入一串工单号。它可能召回一堆语义相近、单号不对的记录。标量过滤能筛范围筛不掉字面。混合检索要三路。向量管语义关键词管字面标量管范围。三路结果怎么合并、怎么去重、谁先谁后才是工程难点。只做“向量加过滤”精确查询会漏。只做“关键词加过滤”口语问法会漏。KES 这边向量与标量可以原生混合查询。公开报道提到支持 IVFFlat、HNSW 索引。示意 SQL 长这样。函数名和写法以所用版本为准别直接抄。SELECTticket_id,title,status,created_atFROMt_ticketWHEREtenant_id:tenant_idANDstatusclosedANDcreated_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_idANDstatusclosedORDERBYVECTOR_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 时最先测哪一项评论区说说我帮你把验收用例补全。我是数据库小学妹帮你少走弯路少踩坑咱们下篇见 
长河君 · 2026/10/30 11:25:04 · 阅读 1.2k AI数据库是什么？五层能力栈与POC验收清单
大家好我是数据库小学妹我踩过的坑你别再踩。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 条混着型号和业务条件。看 Recall10也就是前 10 条里有没有该找的那条。查询类型A 纯向量B 向量加过滤C 向量加关键词加过滤精确单号 10 条4610语义描述 10 条889混合条件 10 条6710合计 Recall1018/3021/3029/30数字来自演示环境别当 benchmark。换个语料或模型结果会变。纯向量对“意思像”敏感对“单号对”不敏感。用户输入一串工单号。它可能召回一堆语义相近、单号不对的记录。标量过滤能筛范围筛不掉字面。混合检索要三路。向量管语义关键词管字面标量管范围。三路结果怎么合并、怎么去重、谁先谁后才是工程难点。只做“向量加过滤”精确查询会漏。只做“关键词加过滤”口语问法会漏。KES 这边向量与标量可以原生混合查询。公开报道提到支持 IVFFlat、HNSW 索引。示意 SQL 长这样。函数名和写法以所用版本为准别直接抄。SELECTticket_id,title,status,created_atFROMt_ticketWHEREtenant_id:tenant_idANDstatusclosedANDcreated_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_idANDstatusclosedORDERBYVECTOR_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 时最先测哪一项评论区说说我帮你把验收用例补全。我是数据库小学妹帮你少走弯路少踩坑咱们下篇见