LLM生成SQL与数据查询：方案对比、风险与落地步骤
LLM生成SQL，真正的难点是什么
让大语言模型把“上个月各地区的收入是多少”转换成SQL，看起来只需一次提示。但模型必须理解业务词汇、表关系、时间范围和权限规则。若“收入”在不同团队中分别指订单金额、实收金额或扣除退款后的金额，语法正确的查询仍可能给出错误答案。因此，评估方案时不能只看SQL能否执行，还要看结果是否符合业务定义，以及错误时会不会泄露或修改数据。
常见做法有三类：直接在提示词中附上数据库结构；通过检索增强按问题挑选相关表和字段；让模型调用受控工具，逐步查看结构、生成查询并读取结果。三者各有适用范围，关键是把模型限制在清晰、可验证的工作流里。
三种方案的优缺点
- 提示词附带Schema：把相关表名、字段、类型和少量示例放入上下文，再要求模型输出SQL。优点是搭建快、链路短，适合表数量少、结构稳定的分析库。缺点是Schema过长会挤占上下文；字段注释不清时，模型容易猜错关联条件或把相似字段混用。表结构变化后，提示内容也必须同步更新。
- 检索增强生成：先用问题检索相关表、字段说明、业务口径和历史查询，再把这些资料交给模型。优点是大型数仓只需提供少量相关上下文，也能纳入经审核的指标定义。缺点是检索错了，SQL往往从一开始就偏离；还需要维护文档、索引和表字段映射。应在结果中保留引用的表和口径，方便用户核对。
- 工具调用与分步执行：模型通过工具查看Schema、生成SQL，再由应用校验和执行。优点是适合交互式分析，也能在缺少信息时先询问用户。缺点是开发和测试成本较高，工具权限配置不当会扩大风险；多轮调用还会增加延迟与模型费用。应让工具只读，并限制可查询的数据源。
一套可落地的安全流程
第一步，先收集问题所需的表结构、字段说明、主外键和指标定义，不要把所有数据库信息无差别塞进提示词。第二步，要求模型输出结构化结果，例如SQL、使用的表、时间区间和假设；若问题缺少币种、时区或指标口径，就先追问，而不是自行补全。
第三步，在执行前用SQL解析器或数据库方言工具检查语法和访问对象，拒绝多语句、DDL、DML及未授权表。只允许SELECT还不够：设置只读数据库账号、语句超时、结果行数上限，并对敏感列做权限控制。第四步，先在测试库或只读副本运行，再将SQL、模型版本、Schema版本和执行错误记录下来。不要把未经脱敏的个人数据直接发送给模型服务。
第五步，用真实问题建立评测集，覆盖常见指标、复杂关联、空结果和模糊问题。比较查询结果而不只是SQL字符串，因为等价SQL写法可能不同；同时统计执行成功率、结果正确率、澄清率、延迟和单次成本。模型升级、提示词调整或Schema变动后都应回归测试。
模型与成本如何权衡
较小或较快的模型适合分类问题、改写查询和结构简单的SQL；复杂关联、歧义判断和多步分析则值得尝试能力更强的模型。实际表现取决于Schema质量、提示词和业务定义，不能只凭模型名称判断。可先用一批代表性问题对Claude与GPT模型进行同条件测试，再按任务路由：简单请求走低成本模型，难题升级处理，并设置令牌预算与失败回退。
预算有限的团队可以考虑59API这类AI API中转服务，以按量付费方式接入Claude Opus、Sonnet、Haiku、Fable及GPT模型。59API提供与Claude Code、Codex和OpenAI SDK兼容的接口，API Base URL为https://api.59api.com；其模型定位为原生官方品质，不做降级，并提供推荐返利。具体费用应以当前价格页面为准。若正在搭建Text-to-SQL原型，可先注册59API，用同一评测集比较模型的正确率、延迟和成本，再决定生产路由方案。