NL2SQL准确率卡在四成：问题在表注释不在模型
AI 总结
作者复盘一个政务数据平台落地案例：模型生成的SQL语法正确、表名字段名都对也能跑，但把注册渠道编码字段user_status当成了用户状态，真正的状态字段是is_valid，导致“有效用户数”算错。作者认为NL2SQL落地受阻主要在字段语义缺失、口径无归属等数据资产问题，建议三层做法：补齐含枚举值的表字段注释、写出含公式与时间窗与归属人的机器可读指标定义、再决定语义层放在库外还是库内。在同一模型、一百多道题的内部验证中，可执行率始终接近满分，答案正确率据称从四成多提升到八成五以上。
深度见解
案例说明生产环境里“能跑但猜错”的SQL比直接报错更危险，真实企业库中NL2SQL的准确率上限更多取决于注释与口径这类数据治理工作，而非模型本身。
AI 数据库的发布会上，各家讲的是库内推理、向量检索、多模融合，性能数字一个比一个漂亮。但项目落地时最先卡住人的往往不是这些，而是库里的表没人写注释、口径没人定。
这篇把方法拆成三层，每层都给可执行的 SQL，最后给一组同模型对比数据。
一、问题不在模型，先看一个真实现象
第一个项目是政务数据平台，一百六十多张表，挑一个业务口试点。POC 那周演示很顺，领导问什么都能出一条 SQL，还能出个表。
第二周业务真用起来，投诉就来了。上机去看：SQL 语法没有任何问题，表名对、字段名对、能跑、有结果。问题是过滤条件用错了字段——业务问「有效用户数」，模型查的是 user_status = 1，而这张表里 user_status 存的是注册渠道编码，真正的状态字段是 is_valid。
模型没报错，它只是把这个字段当成了「用户状态」，因为这字段在库里连一句注释都没有，它只能靠名字猜。