AI 数据库落地 NL2SQL：一个项目把注释补完，准确率从 45% 到 86%

先说结论：AI 数据库落地时，NL2SQL 项目做不好，九成不是模型选错了，是库里的表没人写注释。

这个结论是撞出来的。参与和跟进的 AI 数据库项目加起来七八个，横跨政务、能源、制造几个行业，库有国产的也有开源的，表最多的一千多张，主攻场景基本都是自然语言查数。没有一个项目的 POC 是不通过的，也没有一个项目是三个月后还在被业务主动使用的。

这篇文章是这几个项目攒下来的一份复盘，按「现象、根因、改造、验证」四段写，能直接照着改。

一、现象：SQL 能跑，答案错

一个政务数据平台，一百六十多张表，挑一个业务口试点。POC 那周演示顺利，第二周业务一用，投诉就来了。

查下来是这样：业务问「有效用户数」，模型生成 user_status = 1。这张表里 user_status 存的是注册渠道编码，真正的状态字段是 is_valid，取值 0 和 1。SQL 语法完全正确，表名字段名都对，能跑，有结果，没报错——就是算错了。

原因是 user_status 这个字段在库里没有任何注释，模型只能靠字段名猜。

后来我们回头查，这个错口径的看板在业务侧挂了三个月，中间还上过一次汇报。报错的 SQL 会被人改掉，猜错的 SQL 会一路跑到会上。

二、根因：三件事，两件与模型无关

• 字段语义缺失：拼音缩写、英文简称、历史遗留的 f1、f2，注释为空。
• 口径没有落处：剔除退款、剔除测试单、财务月关账这类规则，在制度文件里、在老员工脑子里，不在库里。
• 指标没有归属人：同一个概念多张表都有，说不清哪张是权威表。

只有第三条勉强算模型问题（上下文不足），前两条是数据资产的事。

公开数据也能印证。同一批模型，语义清晰的场景能到九成；真实企业库加进脏数据、上千列、方言差异，落到六成甚至四成；允许提问模糊、需要多轮追问的场景，三成上下。掉下来的这一截，和 SQL 语法能力没关系，和 schema 能不能被理解有关系。

三、改造：四步，两个人两周

3.1 补核心表的注释

只补被问得最多的那二十张，不要全库铺开——我们试过，补到第三周就没人愿意干了。

项	要求	例子
表注释	装什么、从哪来、什么频率更新	订单主表，来源交易库，日更
字段注释	业务含义 + 枚举取值	订单状态：0 待支付 1 已支付 2 已取消
单位精度	元还是分，是否含税	订单金额，单位元，含税
关系	能对上的写清楚	关联客户表 customer_id
废弃标记	不用的标出来	已废弃，用 new_flag 代替

普通 DDL 就行，不依赖产品特性：

COMMENT ON TABLE  biz_order IS '订单主表，来源交易库，T+1 更新';
COMMENT ON COLUMN biz_order.order_status IS '订单状态：0待支付 1已支付 2已取消 3已退款';
COMMENT ON COLUMN biz_order.amount       IS '订单金额，单位：元，含税';
COMMENT ON COLUMN biz_order.user_status  IS '注册渠道编码：1官网 2APP 3小程序，非用户状态';

先把空注释的字段拉出来，就是一张任务清单。KES / openGauss / PostgreSQL 系：

SELECT c.relname AS 表名,
       COALESCE(obj_description(c.oid), '')      AS 表注释,
       a.attname AS 字段名,
       COALESCE(col_description(c.oid, a.attnum), '') AS 字段注释
FROM   pg_class c
JOIN   pg_namespace n ON n.oid = c.relnamespace
JOIN   pg_attribute a ON a.attrelid = c.oid
WHERE  n.nspname = 'public' AND c.relkind = 'r'
  AND  a.attnum > 0 AND NOT a.attisdropped
ORDER  BY c.relname, a.attnum;

MySQL 用 information_schema.columns 的 column_comment，Oracle 用 user_tab_columns 的 comments，取法一样。

3.2 建指标定义表

把公式、时间口径、排除规则、归属人落在库里：

CREATE TABLE meta_metric (
  metric_code  VARCHAR(64) PRIMARY KEY,   -- 指标编码
  metric_name  VARCHAR(128),              -- 业务叫法
  synonyms     VARCHAR(512),              -- 同义词
  formula      TEXT,                      -- 计算逻辑
  time_rule    VARCHAR(256),              -- 时间口径
  exclude_rule VARCHAR(512),              -- 排除规则
  owner        VARCHAR(64),               -- 口径归属人
  updated_at   TIMESTAMP
);

一句话拆开就明白为什么要这张表。「上个月卖得最好的品类」：卖得最好按 GMV、订单数、件数还是毛利？上个月按自然月、近 30 天还是财务月？退款和测试单算不算？品类取叶子类目还是二级类目？四个点任何一个没定义，答案就可能不一样。

口径归属人要写人名，写部门没用，出问题时找不到人。

3.3 配回归集

每个口径配三个标准问法和标准答案。语义改了要能重跑，否则三个月后又回到原点。

3.4 再谈语义放在哪

前三步都是数据活，这一步才涉及选型。

一类做法是在库外加语义层或指标平台，好处是跨源统一，代价是多一跳链路、权限要二次对齐。

另一类做法是放回数据库侧。金仓数据库 10 月发布的 KES AI 数据库把语义定义、向量推理、安全管控做进内核，元数据采集后系统自动提建议、业务人员确认生效，语义与数据同库维护，结构变更能同步感知；达梦在 NDBC 上讲的是语义层与 NL2SQL 并行、由语义层生成并校验 SQL；腾讯云 TDSQL Nexa 是统一入口加语义与权限治理。

一条判断：语义放在哪，决定权限和审计要不要做两遍。数据不出库的方案，行级权限与审计天然跟着数据走；语义在库外，就要保证两套权限规则始终一致——难的不是做，是长期维持。

四、验证：只补注释，不换模型

同一个政务项目，同一套模型、同一批问题：

阶段	可执行率	口径正确率	答案正确率
原始库（注释覆盖率约 30%）	接近满分	六成上下	四成多
补完 20 张核心表的注释与枚举	接近满分	八成上下	七成多
加指标定义表 + 同义词 + 回归集	接近满分	九成上下	八成五以上

强调一下：单项目、一次内部验证，题量一百出头，绝对数字别当基准，看趋势。全程没换模型、没调提示词。补注释那一步两个人两周干完，是整个项目里投入产出比最高的一段。

五、五个实测出来的注意点

别一次补全库，补到第三周就没人干了。

枚举值必须写，不写枚举等于没写注释。

归属人写人名，写部门找不到人。

验收分三层：语法可执行、口径符合定义、结果与人工一致。第一层几乎必然满分，要盯后两层。

把注释写进流程，新增字段必须带注释，否则半年后又变成噪音。

六、结语

模型每年都在变强，真实企业库上的成绩也一直在涨，但涨不到九成。库里没写下来的东西，模型猜不到，这部分只能靠人补。

第一步不是选模型，是打开核心表看一眼字段注释有多少是空的。那个数字，基本就是你 AI 数据库里 NL2SQL 这一块的天花板。

---

本文基于多个项目的综合经验整理，数据与场景已做脱敏和合并处理。厂商信息均来自公开材料。
李白客，信创行业独立观察者。关注数据库、AI 基础设施与国产化替代。