让AI查数据库：Text2SQL在企业落地的五个难点与解法

Demo 惊艳，生产翻车

“让业务同事用自然语言查数据，AI 自动生成 SQL”——这个场景听着就值钱。Demo 阶段也确实惊艳：一句”上月华东区销售额多少”，秒出 SQL 和结果。

但一上生产，问题全来了。本文拆解 Text2SQL 真正的五个难点。

难点一：Schema 又大又乱

企业数据库动辄几百张表、上千字段，命名还千奇百怪（t_ord_hdr、usr_st）。直接把整个 Schema 塞给模型，既超上下文，又制造噪音。

解法：

• Schema 检索：先用向量/关键词检索出与问题相关的表，只喂这几张
• 别名与注释：给表和字段配上业务语义描述（“ord_st = 订单状态：0待付/1已付/2取消”）
• 示例映射：“销售额”对应哪个字段，用业务词典固化下来

orders:
  desc: "订单主表"
  fields:
    ord_amt: "订单金额（元）"
    ord_st: "状态：0未付 1已付 2退款"

Schema 的语义化，是 Text2SQL 效果的第一杠杆。

难点二：业务歧义

“上个月的销售”——是自然月还是滚动 30 天？“华东区”包含哪些省？“活跃用户”怎么定义？

模型不懂你的业务口径，就会给出看似正确、实则错误的答案。这比报错更危险。

解法：

• 指标字典：把每个业务指标的口径写成精确定义，作为上下文注入
• 澄清机制：歧义太大时，Agent 主动反问，而不是瞎猜
• 默认口径：为高频指标设定默认规则，减少来回

宁可多问一句，不要给错答案。

难点三：数据库方言与复杂查询

不同数据库 SQL 方言不同（MySQL/PostgreSQL/Snowflake/BigQuery），窗口函数、日期函数写法各异。复杂查询（多表 JOIN、子查询、同比环比）更容易出错。

解法：

• 明确告知模型目标方言
• 给 Few-shot 示例：把典型复杂查询的正确写法做示例
• 语法校验：生成的 SQL 先过一遍解析器，语法错误直接反馈重生成
• 执行校验：在只读副本上试跑，报错则让模型基于错误信息修正

难点四：安全边界

这是最重要的一层，也最容易被忽视。

如果 AI 能自由生成 SQL 并执行，一个”删除所有用户”的输入就可能酿成大祸。哪怕是查询，也可能被注入 UNION SELECT 拖走敏感数据。

解法：

1. 只读连接：Text2SQL 用只读账号，物理上禁止写操作
2. 行/列级权限：按提问者身份限制可见数据范围
3. SQL 审查：执行前用白名单——只允许 SELECT，禁止 DDL/DML、多语句、危险函数
4. 限流与超时：防止拖库式的大查询
5. 审计日志：每次生成的 SQL 和执行结果全量记录

拒绝：DROP / DELETE / UPDATE / INSERT / ; -- 多语句 / INTO OUTFILE
允许：单条 SELECT，强制 LIMIT

把”能查什么”和”能查多少”都锁死，是 Text2SQL 上线的前提。

难点五：结果可信度

SQL 跑出来一个数字，对不对？用户无从判断。如果 AI 悄悄用了错误的字段或口径，会误导决策。

解法：

• 展示 SQL：让用户能看到 AI 到底查了什么（透明化）
• 结果自检：让 Agent 复核——“这个数字合理吗？是否遗漏了过滤条件？”
• 多方案对比：条件允许时生成两种口径的结果供对照
• 标注不确定性：低置信度时明确提示

一个推荐架构

用户问题
  → 意图理解 & 歧义澄清
  → Schema/指标检索
  → SQL 生成（带 Few-shot）
  → 语法 + 安全审查
  → 只读执行
  → 结果校验 & 自然语言解释
  → 返回（附 SQL）

落地清单

• Schema 是否已语义化（别名+注释）？
• 是否有指标口径字典？
• 歧义时是否有澄清机制？
• 是否用只读账号 + 行/列级权限？
• 是否有 SQL 白名单审查？
• 是否展示生成的 SQL？
• 是否有结果自检与超时限流？

结语

Text2SQL 的价值毋庸置疑，但它不是”接个模型就完事”。它的难点一半在数据治理，一半在安全边界。 把 Schema 语义化、口径固化、安全锁死，这个功能才能真正交给业务用，而不是停留在演示视频里。