AI数据库落地实践：语义、执行与权限边界

大家好，我是数据库小学妹👋我踩过的坑，你别再踩。

这几天，我老刷到金仓发布会的信息。10月30日，是电科金仓2026产品发布会暨金仓数据库开发者大会，主题叫「Hello，AI数据库」。会上提出的主张是“AI数据库用金仓”。我手上正好卡着一个报表口径。看到这句，最先想到的不是模型，是那张对不上的表。

现场我没去。看下来有个感觉。这两年的AI数据库Demo，越来越顺了。但落地卡住的地方，可能不在模型。Demo解决的是“能不能答”。生产要解决的是“敢不敢用”。

AI数据库落地，卡的不是模型会不会写SQL。是写出来的SQL敢不敢跑，结果敢不敢用。 这两件事，模型管不了。

上个月，一个做零售的朋友来找我。业务方想要“直接问数”，说白了就是Text2SQL。他们先上了一套问数工具。一句“上个月华东退货率多少”，几秒出表。老板当场点头。两周后上线，同一个问题，答案和财务报表对不上。业务方问了几次，不问了。项目不是输在模型，是输在模型之外的事。

Demo和生产，差在哪

我把演示和生产里的常见问题，整理成了一张表。差别不在功能多少，在问题类型。Demo问的是标准句，生产问的是人话。Demo跑的是小数据，生产面对的是大表。

这张表里，没有一项是模型自己能解决的。问题出在模型之外。模型只负责翻译。翻译之后的事，才是落地的开始。

第一个落差：演示问标准句，生产问人话

“上个月华东退货率多少”，这句话至少有三处歧义。“上个月”是自然月，还是近30天。“华东”含不含线上仓。“退货率”按件算，还是按金额算。模型不会猜，它只会按字面翻译。

更麻烦的是多轮追问。第一句问“华东”，第二句问“那华南呢”。上下文没带上时间窗和指标，第二句就会重新猜一遍。同义词也坑。“退货”“退款”“售后”，在模型眼里是三件事。业务嘴里是一个意思。词典不写，SQL就查错表。时间窗也要定死。自然月、近30天、滚动7天，不能混着用。

-- 示意：问数只查语义层里的指标视图
SELECT stat_month, region_name, refund_rate_piece
FROM v_metric_refund_rate
WHERE stat_month = DATE '2026-09-01'
  AND region_name = '华东';

视图名和字段名是示意，写法按你们的口径来。关键不在SQL长短。在于模型能不能被限制在“已定义的口径”里。口径写进视图，注释写清分子分母。没定义的指标，直接提示“未纳入”。把“答错”变成“答不了”，信任还能补。口径不统一，模型越强，错得越自信。

这里能看出融合型数据库的价值。问数不只查订单表，可能还要查商品文档、售后工单、知识片段。如果每种数据一套库，应用层就要拼三次，口径更容易散。金仓AI数据库的能力，落在KES V9 2025上。键值、文档、向量，放在同一套引擎里。一条SQL就能做跨模型检索。少一次搬运，语义层就少一个分叉。

第二个落差：演示数据小，生产表很大

演示环境里，数据量通常不大，账号也只有一个人用。生产不一样。业务方问“最近一年所有订单明细”。模型生成SELECT ，没带时间过滤。表几千万行，一条问数扫全表，交易库的IO先满。计划里出现全表扫描，行数又是千万级。这条问数就不该放行。

我们的做法是四道闸。问数账号只读，语句只允许SELECT。单次返回行数设上限，超时自动中断。这四道闸不酷，但少了任何一道，DBA晚上都睡不好。再加一条：执行前看计划。全表扫描、嵌套循环太多的，先拦下来。资源也要分，问数走只读副本，别和交易抢。白天交易高峰，问数入口要限流。夜里跑批，也要错峰。问数账号和业务账号分开，密码不要共用。返回行数上限，按场景定。业务看明细，也得分页。

金仓AI数据库的底子，是KES V9 2025。智能优化器放进了管理链路。全诊断过程支撑也在里面，还有SQL映射应急。说白了，计划不对时，系统要先看见，再给人动作。但工具给建议，闸门还得自己设。参数、阈值、白名单，都要按业务定。

接口层也在变。KES MCP Server已经在Gitee开源，AI客户端可以通过标准接口连库。接口通了，不等于可以放开。权限、限流、审计，仍然要配在数据库这一侧。

第三个落差：演示只求答对，生产要能核对

这一层，很多项目上线前才想起来。界面有权限，菜单有权限，可自然语言没有菜单。用户问一句“技术部所有人的工资多少”，模型照着翻译。账号有权限，数据就出去了。所以问数入口不能自带一套权限。它要复用数据库的行级、列级权限。谁能看哪张表、哪些行、哪些列，在库里定。权限配在应用层，换个入口就绕过去了。

审计也要落到库这一层。谁问的，生成了什么SQL。扫了多少行，结果给了谁。出了事，能回放，能定位。审计不是给检查看的。是出事时，能还原现场。

列级也要管，手机号、身份证号、成本价，能不能看，按角色配。审计日志要留够追溯周期，别只留七天。大规模部署时，管控平台比单库配置更重要。金仓AI数据库的管控，落在KEMCC上。跨环境统一纳管，实例和工具放在一个界面里。入口越多，越需要一处能看全。

还有结果本身。业务方要的不是一段话，是一个能核对的数字。答案旁边要有三样东西：SQL、指标口径、数据时间范围。业务一眼能看出数据截到哪天。再加一道人工复核。高风险指标，比如收入、成本、人数，先复核再发布。复核不是走形式。复核人要知道口径。同一个问题问三次，尽量给同一个答案。问数要可复现，不能像聊天。

金仓AI数据库，现在走到哪了

问数不是终点。能答对，是个好起点。生产里更难的，是答错时说不说得清错在哪。生成的SQL要能回到开发工具里改、调、审。上线前，权限、回滚、审计，仍要先于功能。

“AI数据库用金仓”，我第一次听，以为是一句品牌口号。拆完三个落差，我有了另一种理解，重点在“用”字。数据在库里，口径在库里，权限在库里，执行和审计也在库里。数据在A库，权限在B系统，审计在C平台。模型再强也接不住。都在库里，问数才有可能真正上线。

开发者大会这个角度，我更关心落地。开发者看Demo时，不会只看答得顺不顺。他们想知道，接口怎么接进来，SQL出了错怎么改，出了问题怎么查回去。这些都不在模型里，在库的入口、工具和审计里。

金仓AI数据库这条线，强在数据库本身就是这些能力的落点。KES V9 2025有多模融合和智能优化器。KEMCC负责统一管控。从存储、检索到开发、运维，尽量放在一套底座里。边界也要说清。模型理解、指标治理、组织流程，数据库替不了。发布会给的是能力。能不能用起来，还得看企业自己补哪几层。

案例复盘：停两周，补三样东西

回到开头那个零售项目。我们停了两周，没换模型，补了三样。第一，12个核心指标写成视图，口径进注释，问数只能查视图。视图上线前，财务在评审单上签了字。第二，问数账号只读。返回行数设上限，超时中断。慢查询走只读副本。第三，每条答案带SQL、口径和时间范围。高风险指标人工复核。

第三周重新上线。业务方的问题变了。从“它答得对不对”，变成“这个口径我们认不认”。我觉得这才是正常状态。技术把答案算准，业务把口径认下来，两边各干各的。

还有个细节。业务方原话是“我就想知道昨天为什么退货多”。这种问题，问数答不了原因。它能给数，给不了归因。后来我们把这类问题放回分析看板。问数只接“是多少”，不接“为什么”。

上AI数据库前，先问三句

如果你也在评估AI数据库，先别急着比模型。模型只是其中一环。先把下面三句答清楚。答不清，Demo再顺也别急着上。

• 业务问的是“是多少”，还是“为什么”？
• 核心指标有没有唯一出处，谁签字？
• 出了问题，能不能回放到人和SQL？

三句里有两句答不上，先做固定报表。问数可以等，信任等不起。固定报表不惊艳，但它能被核对。还有三种情况，我会劝业务先等等。不是技术做不到，是现在上不划算。等条件补齐，再上也不迟。

• 业务把问数当“万能分析”，指望它给原因。
• 指标口径还没人签字，部门各算各的。
• 权限还挂在应用层，库里没有行列控制。

AI数据库避坑清单：三个坑，我踩过最后一个

第一，拿演示当验收。演示挑的是标准问句，数据也小。上线前换成模糊问句、脏数据、大表，各跑一遍。

第二，只测答对，不测答错。拿“查所有人工资”试一次，也拿“未定义指标”试一次。看它是拒绝，还是硬编一个答案。硬编出来的答案，比拒绝更麻烦。

第三，我自己踩过。早期做报表，我把“近30天”默认成了“上月”，和财务差了一天。后来我把时间口径写进注释，答案也强制显示时间范围。小改动，省了很多解释。

写在最后

上面这些坑补到最后，拼的是底座。金仓AI数据库想做的，就是让口径、权限、审计都回到库里。数据本来就在库里，剩下的事也该在一处收口。底座稳了，才敢放开用。

说到底，三个落差落在一个地方。AI数据库不是把模型塞进库里就完事。它得把问题理解、执行安全、权限和证据一起接住。这一层接住了，问数才敢给业务用。金仓走的是这条路线，把数据、口径、权限都放回库里。开头那个零售项目，最后是靠人对齐口径解决的。AI数据库能做的，是让这种对齐不用每次从头来。

你们公司上AI问数时，最先卡在哪一层？是口径、执行，还是权限？评论区说说。我帮你把验收用例补全。

我是数据库小学妹，帮你少走弯路少踩坑，咱们下篇见👋