AI 自动生成 SQL：从靠猜到可执行的工程实践

一、痛点复盘：断在“搬运”上的工作流

很多开发者都有过类似经历：遇到不熟悉的表结构时，先打开一个通用对话助手，把建表语句或字段列表粘贴进去，用自然语言描述想查什么，等模型输出 SQL；然后切回数据库客户端工具，粘贴执行；报错后复制错误信息，再切回去请求修复。运气好一轮通过，更多时候要在两个窗口之间来回折腾四五轮。

这个流程表面上看是“AI 不会写 SQL”，实际上真正的断点在“搬运”：人和上下文在两个割裂的系统之间来回运输，每搬运一次，信息就损耗一次——报错信息被截断、表结构粘贴不完整、上一轮的修改意图丢失。效率低只是表象，准确率上不去才是本质。

二、根因分析：模型不知道你的数据库长什么样

通用大模型的训练语料里包含海量公开 SQL 样例，写一条“查询每个部门平均薪资”这类典型需求并不难。真正的问题是：模型并不知道你的库里有没有部门表、薪资字段叫什么、两张表之间靠什么字段关联。

当模型缺乏真实 Schema 时，它只能基于“一个典型业务数据库可能长什么样”做概率性猜测。这类猜测生成的 SQL 有几个典型症状：

• 表名、字段名是“听起来合理但实际不存在”的，即所谓幻觉；
• JOIN 条件凭语义猜，关联键错误导致结果集膨胀或为空；
• 忽略软删除标记、租户隔离字段等业务约定；
• 方言不匹配，比如对目标数据库写出了它并不支持的函数或语法。

由此可以得出一个关键结论：提升 SQL 生成准确率的关键，往往不是换更强的模型，而是把真实、充分的上下文喂给模型。 这正是检索增强生成（RAG）在 Text-to-SQL 场景的用武之地。

rag-">三、解法核心：用 RAG 把“猜”变成“查”

3.1 五类应当自动注入的上下文

一个成熟的智能 SQL 生成系统，应该在每次生成前自动完成上下文检索，而不是让用户手工粘贴。实践中，以下五类信息的收益最高：

1. Schema 元数据：当前连接实例的表、字段、数据类型、索引、外键关系。外键尤其重要，它是 JOIN 条件最可靠的依据；
2. 字段业务备注：建表时的注释、数据字典里的口径说明。模型能据此理解某个状态值到底代表什么业务含义；
3. 高质量样例 SQL：历史上执行成功的查询、人工校对过的典型报表 SQL。few-shot 样例对生成质量的提升往往立竿见影；
4. 业务术语词典：把“大促”“动销率”这类内部黑话映射到具体表和计算口径，消除语义歧义；
5. 会话记忆：当前多轮对话的上下文（比如“只取前 20 条”指的是上一条 SQL），以及历史会话的向量摘要，避免每轮都从零开始。

3.2 上下文构建的技术细节

Schema 动辄几百张表，全量塞进 prompt 既昂贵又容易稀释模型注意力，实践中通常做两级召回：

• 表级召回：把每张表的“表名 + 注释 + 字段摘要”做成向量索引，用用户问题检索出最相关的 top-k 张表，并顺带带出与它们有外键关联的表；
• 样例召回：用同样方式在样例 SQL 库里找语义相近的历史问题，作为 few-shot 示例注入。

一个典型的 prompt 组装模板如下：

你是资深数据分析师。请基于以下上下文生成 {dialect} 方言的 SQL，
只输出可直接执行的 SQL，不要附加解释。
【候选表结构】
{retrieved_schemas}
【字段业务说明】
{column_comments}
【业务术语对照】
{glossary}
【相似问题参考】
Q: {similar_question}
SQL: {similar_sql}
【用户问题】
{user_question}

生成之后还要做静态校验：解析 SQL 中引用的表名、字段名是否真实存在于召回的 Schema 中，不存在的直接回炉重生成，把幻觉拦截在执行之前。

四、闭环设计：从提问到结果不离开一个界面

上下文问题解决后，第二个瓶颈是交互路径。如果生成和执行仍分布在两个工具里，搬运成本依然存在。更合理的形态是把“生成 → 执行 → 结果展示 → 追问改写”收进同一个界面：

• 模型输出 SQL 后，用户直接点击执行，结果表格就近渲染；
• 看到结果后可以继续用自然语言追问：“只看最近 7 天”“按金额降序”“加一列占比”，系统基于上一条 SQL 和会话记忆做增量改写，而不是推倒重来；
• 每次改写保留版本痕迹，方便回退对比。

这个闭环的价值不只是省去切换窗口：每轮执行结果本身就是新的反馈信号，系统可以据此判断 SQL 是否真的跑通，把“用户报错 → 贴错误 → 再修”的人工环节变成系统内部的自动迭代。

五、安全闸门：执行前的那道审查

让 AI 直接对数据库执行 SQL，生产环境里必须有人兜底。生成侧再准，也需要在执行前加一道独立的风险评估闸门，规则至少覆盖：

• 无 WHERE 条件的 DELETE、UPDATE：直接拦截；
• 全表 TRUNCATE、DROP：明确告警并要求二次确认；
• 生产环境连接下的任何写操作：二次确认，或干脆通过只读账号彻底禁止；
• 缺少 LIMIT 的大结果集查询：建议加限制或设置超时。

简单场景可以用规则匹配快速兜底，严谨场景建议先把 SQL 解析成语法树（AST）再判断，避免正则被注释、换行等写法绕过：

HIGH_RISK_RULES = [
    ("DELETE_WITHOUT_WHERE", lambda ast: ast.is_delete and ast.has_no_where),
    ("UPDATE_WITHOUT_WHERE", lambda ast: ast.is_update and ast.has_no_where),
    ("FULL_TRUNCATE",        lambda ast: ast.is_truncate),
    ("WRITE_IN_PROD",        lambda ast: env.is_prod and ast.is_write),
]
def guard(sql, env):
    ast = parse(sql)
    for name, hit in HIGH_RISK_RULES:
        if hit(ast):
            return RiskResult(blocked=True, reason=name)
    return RiskResult(blocked=False)

配套的运维习惯同样重要：为 AI 使用专用的低权限账号、设置查询超时与返回行数上限、高危操作全量审计留痕。

六、工程落地：一条可演进的建设路线

6.1 最小可行版本

不必一开始就建大而全的平台。一个 MVP 只需要四件事：定时同步 Schema 与注释入库、一个向量索引、一个组装 prompt 的模板、一个带风险拦截的执行入口。这个版本就能覆盖日常大部分即席查询需求。

6.2 持续变准的反馈闭环

系统的准确率应该随使用时间提升，关键在两个回路：

• 样例沉淀：用户手动修正过的 SQL、执行成功的高频查询，经确认后写回样例库，成为下一次检索的 few-shot 材料；
• 坏例归因：对生成失败的案例做分类（召回不足 / 术语歧义 / 方言问题），分别反哺索引覆盖和词典建设。

6.3 技术选型建议

嵌入模型和大模型底座可以自建，也可以直接使用云上托管能力，例如百度智能云提供的通用大模型服务与向量检索类产品，好处是免运维、弹性扩容，适合快速验证；对数据敏感的团队则可选择私有化部署，架构上并无本质差异。评估效果时，建议用统一的评测集度量“一次执行通过率”和“平均往返轮次”两个指标，比主观感受更可靠。

七、常见坑与规避建议

• Schema 爆炸：面对数百张宽表时，表级召回要结合外键扩展，把与命中表直接关联的表也带进来，否则 JOIN 写不全；
• 术语歧义：“订单”可能指主表也可能是流水表，词典里要显式声明默认口径；
• 方言漂移：在 prompt 中显式声明目标方言，并在校验层检查函数兼容性；
• 过度信任：即使所有闸门都在，也应保留“执行前人工过目”的习惯，尤其是涉及写操作的场景。

八、写在最后

“AI 生成 SQL”这件事的胜负手，从来不在模型本身，而在上下文工程与执行闭环。把 Schema、注释、样例、术语、记忆这五类上下文自动喂给模型，把生成、执行、改写收进同一个界面，再配上独立的执行安全闸门，“自然语言查数据”才能从碰运气变成可复现的日常能力。这套思路不仅适用于 SQL 场景，也可以平移到任何“模型缺乏私有上下文”的生成任务中。