NL2SQL落地：别高兴太早，SQL生成只是第一步

这个坑我们也踩过，尤其是多表join和聚合函数那块，LLM生成的SQL经常跑出来结果不对，debug起来比手写还累。你提到“上个月销售额”的隐含语义问题太真实了，我现在都强制让用户在查询前先选业务场景模板，把退货、折扣这些变量固定住，不然LLM根本猜不对。

看到这个帖子，我直接拍桌了——这就是我们团队过去一年从“嗨翻全场”到“差点翻车”的全过程写照。你提到的SQL生成只是第一步，我甚至觉得第一步都算不上，充其量是个入口。真正决定NL2SQL能否从demo变成生产级工具的，是后面那些没人愿意提的脏活累活。我试着从一线实操经验出发，把这个话题拆得更细一些，也分享一些我们踩过的坑和最后趟出来的路。

先说你提到的准确率问题。我完全同意“简单查询80%以上，复杂查询50%以下”这个判断。但我想补充一个更扎心的观察：这个50%的准确率，很多时候不是LLM不会写SQL，而是它“写得很对，但逻辑是错的”。举个例子，我们之前有个场景是查“近30天退货率超过10%的品类”。LLM生成的SQL逻辑上是正确的：先按品类分组，计算退货订单数/总订单数，然后用HAVING过滤。但问题出在业务定义上——我们的退货订单在数据库中标记的是“退货申请时间”，而不是“订单完成时间”。用户说的“近30天”是指订单完成时间还是退货申请时间？LLM默认选了退货申请时间，结果把一批刚申请但还没实际退货的商品也拉进来了，导致业务方拿着数据去追责供应商，差点闹出乌龙。所以准确率问题的本质不是SQL语法，而是“语义对齐”——LLM不理解用户的业务语境，它只会基于它见过的训练数据做统计上的最优猜测。而每个企业的业务逻辑都是高度定制化的，这导致NL2SQL在实际落地中必须做一层“业务语义映射”，否则生成结果就是漂亮的垃圾。

关于你提到的安全执行，我更是有一肚子苦水。你同事那个“删除重复数据”清空半张表的事，我们团队也经历过类似的，只不过我们更惨一点——不是删数据，而是被LLM生成了一条UPDATE语句，把某张表的全部记录更新成了同一个值，因为用户问的是“把所有订单状态改成已完成”，而LLM没理解“所有”是个超集概念，它真的生成了一条UPDATE ... SET status='已完成' WHERE 1=1。幸好当时是测试环境，生产环境我们早就做了三层防护。这里我分享一下我们的方案，供大家参考：

第一层是数据库账号层，我们给NL2SQL服务分配了一个专用的只读账号，这是底线。但只读也有坑——有些查询会隐式触发临时表写入，比如某些数据库的ORDER BY + LIMIT在高并发下可能触发磁盘临时表，所以还要限制临时表空间大小。第二层是SQL解析层，我们用了一个改造过的sqlparse，对所有生成的SQL做AST级别分析。白名单校验不只是禁止DROP、DELETE、UPDATE、INSERT、ALTER这些显式危险语句，还要注意那些看着安全但实际危险的组合。比如SELECT INTO OUTFILE在某些数据库里可以写文件，TRUNCATE在某些方言里是DDL，还有CREATE TEMPORARY TABLE如果没限制生命周期也可能导致资源泄露。第三层是运行时防护，我们给查询设置了超时和资源上限。超时是硬性要求，一般OLTP类查询我们设5秒，OLAP类设30秒。资源上限更关键——限制了最大返回行数、最大JOIN表数、最大子查询嵌套深度。我们遇到过LLM生成一个8层嵌套子查询的SQL，直接把数据库搞挂了。

你问的两个问题，我来聊聊我的实战经验。第一个关于用户输入歧义，比如“最近订单”到底是最近7天还是最近10条。我们试过几种方案：一种是让LLM在生成SQL前先问用户澄清，但这在实际产品中体验很差，用户会觉得你傻。另一种是让LLM生成多个候选SQL，然后根据某种策略排序，但排序本身又是个难题。最后我们采用的方案是“业务规则注入”——在给LLM的prompt里，把常见模糊概念的默认定义写死。比如在prompt的系统指令里明确写：当用户未指定时间范围时，“最近”默认指最近7天；当用户未指定排序时，默认按创建时间降序。这个方案简单粗暴，但实测效果不错。当然前提是这些默认规则得跟业务方对齐，不能拍脑袋定。

第二个问题关于Schema变更，这是个大坑。我们团队一开始的做法是每次Schema变更就重新构造prompt，但数据库字段一多，几十张表几百个字段，prompt长度很快就超过上下文窗口了。后来我们换成了“动态Schema选择”方案：先让LLM根据用户问题判断需要哪些表，然后只把那几张表的Schema信息放进prompt。更进一步，我们还做了“字段级热度统计”——哪些字段经常被用户问到，就优先放进去。这样即使数据库加了新字段，只要新字段没人问过，就不会占用prompt空间。但真正的问题在于，新字段的业务含义LLM是不知道的。比如你加了一个“is_vip”字段，LLM不知道它代表什么，自然也不会在用户问“高价值客户”时想到用它。我们的解法是维护一个“业务语义词典”——每个字段对应一段自然语言描述，比如“is_vip: 标识用户是否为VIP会员，VIP会员标准为年度消费超过10万元”。这个词典跟Schema一起动态注入prompt。每次加新字段时，只要更新这个词典，LLM就能自动理解。效果很稳，而且不需要重新训练模型。

最后我想聊聊行业视野。我认同你说的“DBA和BI工程师角色不会消失，而是转向模型调优和异常监控”，但我认为这句话需要再加一个维度——NL2SQL真正改变的是“数据民主化”的路径。以前企业做数据民主化，要么走自助BI工具（Tableau、PowerBI），但学习曲线陡峭；要么走数据中台，但建设成本高。NL2SQL提供了一条新路：用自然语言作为交互层，底层对接现有的数据库和数仓。这条路的好处是门槛极低，坏处是它把“数据理解”的责任从人转移到了模型。这意味着企业必须投入更多精力去管理“模型的数据理解能力”——包括上面提到的业务语义词典、动态Schema选择、歧义处理规则等等。这些东西加起来，其实就是一个“轻量级的数据治理层”。所以我认为，未来NL2SQL落地成功的团队，不是那些LLM调参最牛的团队，而是那些数据治理最扎实的团队。

再分享一个我们正在做的探索：用NL2SQL做“查询意图分类+多模型路由”。简单说，就是用户输入问题后，先不急着生成SQL，而是判断这个问题属于哪类查询——是简单的聚合统计、复杂的多表关联、还是需要时序分析？然后根据分类路由到不同的模型或不同的推理策略。简单查询用轻量级模型，速度快成本低；复杂查询用强模型，但配合多轮澄清和验证。这个思路的核心是“不要用一把尺子量所有人”，NL2SQL的落地需要分层、分场景、分成本模型来设计架构。

最后总结一句：NL2SQL不是银弹，它是一个需要大量配套工程才能发挥价值的工具。那些宣传“一句话查数据”的厂商，要么还没踩到坑，要么踩了坑但没告诉你。作为一线工程师，我更愿意看到大家坦诚地分享这些坑，而不是包装成完美解决方案。希望这个帖子能帮更多团队少走弯路。