SQL生成大模型选型：定制能力与推理稳定性的平衡及算力配置

SQL 生成这件事看起来只是把自然语言翻译成 SQL但真正落到生产环境里你会发现它同时被两股力量拉扯一边是业务方希望模型能懂各种奇奇怪怪的口径、方言函数、历史遗留表结构也就是定制能力另一边是线上系统要求它每次生成的语句都能跑、不报错、不慢查询也就是推理稳定性。这两者往往互相打架——定制得越深模型越容易自由发挥约束得越死遇到新场景又直接摆烂。最近不少人在讨论 SQL 生成到底该选哪家大模型以及背后的算力该怎么配我把自己这段时间的实测和踩坑整理一下尽量说人话。1. SQL 生成任务的真实难点拆解1.1 为什么会写 SQL和能稳定生成 SQL是两回事很多人评估模型时习惯拿几个经典问题去问比如查一下每个部门薪资最高的员工模型答得挺漂亮就认为可以上线了。但生产环境的 SQL 生成完全是另一回事。真实场景里你面对的是几百张表、字段命名毫无规范、同一个业务概念在不同表里有三四种叫法还有大量视图、存储过程、分区表。模型要在这种环境里生成一条能跑的语句靠的不是会 SQL 语法而是对上下文的精确理解和对边界的严格自律。我做过一个对比测试同一个模型在只给表名的情况下生成 SQL和在给出完整 DDL、字段注释、样例数据、业务口径说明的情况下生成 SQL准确率差距能到 40 个百分点以上。这说明什么说明 SQL 生成的质量很大程度上不取决于模型聪不聪明而取决于你喂给它的上下文够不够、准不准。而上下文一多token 消耗就上去了推理成本和时间也跟着涨这就直接牵扯到算力问题。另一个容易被忽略的点是方言差异。MySQL、PostgreSQL、SQL Server、Oracle、DB2 在函数名、日期处理、字符串拼接、分页语法上都不一样。模型如果训练数据里这几种方言混在一起它很容易生成四不像——比如用了 MySQL 的LIMIT却配了 SQL Server 的TOP。这种错误在语法检查阶段可能过但一执行就挂。所以定制能力的核心之一其实是把方言约束住。1.2 定制能力和推理稳定性为什么会冲突定制能力的本质是让模型学会你私有的那套规则特定的表命名习惯、特定的业务口径、特定的函数封装。常见做法有两种一种是通过提示词工程把规则塞进上下文另一种是通过微调让模型把这些规则内化。前者灵活但吃 token后者稳定但更新慢。推理稳定性的本质是让模型的输出可预测、可校验、可回滚。你希望同样的输入永远得到语义一致的输出希望生成的 SQL 能通过静态检查希望执行计划不会突然变成全表扫描。要做到这些光靠模型本身不够还得有外层的校验、重试、缓存机制。冲突就出在这里你为了定制能力往上下文里塞的东西越多模型的注意力就越容易被稀释输出就越不稳定你为了稳定性把输出约束得越死模型面对新场景的泛化能力就越差。所以选型时不能只看哪个模型 SQL 写得好而要看哪个模型在给定丰富上下文和给定严格约束这两个条件下表现都足够稳。1.3 一个被低估的变量算力供给的稳定性大家讨论模型选型时很少把算力单独拎出来说。但实际做 Agent 类应用算力供给的稳定性直接决定了你的推理稳定性。原因很简单SQL 生成往往不是一次调用就完事而是一个多轮流程——先做意图理解再检索相关表结构再生成候选 SQL再做语法校验失败了还要重试。这一套下来单次用户请求可能触发 3 到 8 次模型调用。如果算力供给不稳定出现排队、超时、限流你的重试逻辑就会被打乱用户体验直接崩。更麻烦的是有些场景下你需要并发处理大量 SQL 生成请求比如批量数据查询、报表自动生成这时候算力的弹性就非常关键。所以我在选型时会把算力支撑是否坚实作为一个独立维度来评估而不是只看模型跑分。2. 定制能力的三条实现路径与各自代价2.1 提示词工程最快上手但天花板明显提示词工程是绝大多数团队的第一步。做法是把表结构、字段说明、业务规则、few-shot 示例全部拼进 prompt让模型照着生成。优点是改起来快今天发现一个口径问题改改提示词明天就生效不用重新训练。但它的代价也很直接。第一是token 成本。一个中等规模的库把相关表的 DDL 和注释塞进去轻松就是几千 token如果再加 few-shot 示例上万 token 很常见。每次调用都吃这么多 token成本和延迟都上去了。第二是上下文长度限制。再大的上下文窗口也有上限表一多就塞不下只能做检索而检索本身又会引入新的不确定性。第三是规则冲突。当提示词里的规则越来越多模型很容易顾此失彼遵守了 A 规则就忘了 B 规则。我的经验是提示词工程适合规则相对稳定、表数量可控的场景比如几十张表以内的业务域。一旦超过这个规模就得考虑别的路径。2.2 微调把规则内化但要算清账微调的思路是拿一批高质量的问题-SQL对让模型学会你的私有规则。好处是推理时不用塞那么多上下文token 省了延迟也低了而且规则内化之后一致性更好。但微调有几个坑必须提前想清楚。第一是数据质量。你喂进去的 SQL 如果有错模型学到的就是错的而且这种错误很难通过提示词纠正回来。第二是更新成本。业务口径变了你得重新准备数据、重新训练、重新验证周期比改提示词长得多。第三是灾难性遗忘。微调过头模型可能在你的私有场景上表现很好但通用 SQL 能力反而退化了。还有一个现实问题微调本身是要吃算力的。全量微调对显存和卡数的要求很高LoRA 这类参数高效微调虽然门槛低一些但也不是随便一台机器就能跑。所以微调这条路适合有稳定数据来源、有持续迭代预算的团队。2.3 检索增强折中方案但检索质量决定一切检索增强RAG是介于两者之间的方案。核心思路是不把所有表结构都塞进上下文而是根据用户问题先检索出最相关的几张表和字段再拼进 prompt。这样既保留了定制能力通过检索到的私有 schema又控制了 token 消耗。这个方案的效果几乎完全取决于检索质量。检索错了表后面全错。我踩过的坑是早期用纯向量检索结果经常把语义相似但业务无关的表召回进来比如订单和订单日志向量距离很近但用错了就是灾难。后来改成向量检索 关键词过滤 业务域标签的混合策略召回准确率才上来。另外检索增强对算力的要求也不低因为检索本身要跑 embedding 模型如果并发高embedding 的算力消耗不能忽略。所以这条路也不是免费的。路径定制能力推理稳定性token 成本迭代速度算力需求提示词工程中中高快中微调高高低慢高检索增强中高中高中中中高3. 推理稳定性到底靠什么兜底3.1 语法校验只是第一道关很多人以为生成的 SQL 能通过语法解析就算稳了其实差得远。语法正确但语义错误的 SQL 比比皆是比如 join 条件写错导致笛卡尔积、聚合函数用错层级、where 和 having 混用。所以校验至少要分三层语法层能不能解析、语义层表名字段名是否存在、类型是否匹配、性能层执行计划是否合理、有没有全表扫描风险。语法层可以用现成的 SQL parser比如sqlparse、sqlglot这类库成本很低。语义层需要接元数据服务把生成的 SQL 里的表名、字段名拿去和真实 schema 比对。性能层最麻烦通常要拿EXPLAIN去跑但生产环境不可能每条都跑所以一般只对高风险语句做抽样检查。3.2 重试机制的设计比模型本身更重要SQL 生成失败是常态关键是怎么重试。我见过两种极端一种是不重试失败就报错用户体验差另一种是无脑重试同一个 prompt 反复问结果模型每次给的都差不多白白烧算力。比较合理的做法是带反馈的重试。第一次生成失败后把失败原因比如字段 xxx 不存在作为反馈拼进下一轮 prompt让模型有针对性地修正。实测下来带反馈的重试通常 2 到 3 轮就能收敛比无脑重试效率高得多。但这也意味着单次请求的模型调用次数增加了对算力的弹性要求更高。还有一个技巧是缓存。相同或相似的问题如果之前生成过正确的 SQL直接复用不用再调模型。缓存命中率在报表类场景里能到 30% 以上省下来的算力相当可观。3.3 输出格式约束让模型按模板说话让模型自由输出 SQL稳定性天然就差。更好的做法是约束输出格式比如要求模型输出 JSON里面包含sql、explanation、confidence三个字段。这样解析起来稳定还能根据 confidence 决定要不要人工介入。更进一步可以用结构化生成的方式让模型只填充模板里的槽位而不是自由发挥。比如预定义好SELECT ... FROM ... WHERE ...的骨架模型只负责填表名、字段、条件。这样生成的 SQL 结构可控出错概率大幅降低。代价是灵活性下降复杂查询可能表达不了所以适合固定模式的查询场景。4. 算力配置被忽视的选型维度4.1 推理算力和训练算力是两笔账很多人一说算力就想到训练其实对 SQL 生成这类应用推理算力才是长期开销。训练是一次性的或者周期性的推理是每天都在跑的。一个日活几千的 Agent 应用每天可能产生几万次模型调用这个量级的推理算力需求远比训练一次模型要大。推理算力的需求主要看三个变量调用量、单次 token 数、模型规模。调用量好估算单次 token 数取决于你的上下文策略提示词工程吃 token 多微调吃得少模型规模则直接决定单次推理的算力消耗。这三个变量乘起来就是你需要的推理算力盘子。4.2 精度选择对算力的影响推理时用 FP16 还是 INT8对算力需求影响很大。简单说INT8 量化能把显存占用和算力需求降到 FP16 的一半左右但会带来一定的精度损失。对 SQL 生成这种任务精度损失主要体现在边界情况上比如复杂嵌套查询、罕见函数调用。我的经验是通用查询用 INT8 没问题复杂查询建议走 FP16可以做分级路由简单请求走量化模型复杂请求走全精度模型。这里要提醒一句量化不是免费的午餐。有些模型量化后会出现胡言乱语生成的 SQL 语法都对但逻辑离谱。所以量化后一定要做充分的回归测试别直接上线。4.3 弹性算力对 Agent 场景的意义Agent 类应用的算力需求是波动的。白天业务高峰SQL 生成请求集中晚上批量报表任务跑起来又是一波高峰。如果算力是固定的要么高峰期不够用要么低谷期浪费。所以我在选型时会特别关注算力供给是否弹性。弹性算力的价值在于高峰期能快速扩容保证推理不排队低谷期能缩容控制成本。对 SQL 生成这种调用量波动大、单次延迟敏感的场景弹性算力几乎是刚需。这也是为什么我在评估模型服务时会把背后的算力支撑能力作为一个独立考量——模型再好算力供给跟不上线上照样崩。5. 我的选型实测与踩坑记录5.1 测试集怎么设计才有参考价值我见过太多用几个 demo 问题测模型的选型方式结论基本不可信。真正有参考价值的测试集应该覆盖这几类简单单表查询占实际请求的大头、多表 join考验 schema 理解、聚合与分组考验语义理解、嵌套子查询考验复杂逻辑、方言特有问题考验定制能力、边界情况空值、除零、类型转换。每类准备 20 到 30 条总共一两百条人工标注正确答案然后跑准确率。更重要的是要记录失败案例的失败原因是语法错、语义错还是性能差。这个分布比一个笼统的准确率数字有用得多。5.2 我踩过的几个坑第一个坑是过度依赖模型自带的 schema 理解。早期我偷懒只给表名不给字段结果模型经常猜字段名猜错的概率很高。后来老老实实把 DDL 和注释都喂进去准确率立刻上了一个台阶。教训是上下文能给的尽量给别让模型猜。第二个坑是忽略方言约束。有一次测试集里混了 MySQL 和 SQL Server 的题模型生成的 SQL 方言混乱我一开始以为是模型能力问题后来发现是提示词里没明确指定方言。加上请使用 MySQL 语法这句约束后问题基本消失。教训是方言必须显式约束不能指望模型自己判断。第三个坑是重试逻辑写得太粗暴。最初的重试是把原 prompt 再发一遍结果模型给的答案几乎一样白白浪费算力。改成带错误反馈的重试后收敛速度快了很多。教训是重试要带信息不能空转。第四个坑是没做算力容量规划。上线初期调用量小没感觉后来业务量上来高峰期开始出现超时。回头一算才发现推理算力根本没留够余量。教训是算力规划要按峰值算不能按均值算。5.3 关于选哪家的一点个人看法回到标题的问题SQL 生成推荐哪家大模型。我的看法是没有绝对的最优解只有匹配你场景的解。如果你的场景表结构稳定、规则清晰提示词工程加一个通用能力强的模型就够了如果你的场景规则复杂、更新频繁可能需要在微调和检索增强上多投入如果你对推理稳定性要求极高那算力供给的弹性就必须重点考察。我自己的做法是分级路由简单查询走轻量模型复杂查询走能力强的模型同时用缓存和带反馈的重试兜底。这样既控制了成本又保证了稳定性。至于算力我会优先选择供给弹性好、能按需扩容的方案因为 SQL 生成这类 Agent 应用的负载波动太明显了固定算力很难兼顾成本和体验。最后分享一个小心得别指望一次选型定终身。模型迭代很快今天的最优解半年后可能就不是了。所以架构上要留好切换模型的余地把模型调用抽象成一层接口换模型时只改配置不改业务代码。这样无论后面哪家模型更强你都能快速跟上而不用推倒重来。