Text-to-SQL 为什么在企业里经常不准？

Text-to-SQL 看起来很直接：用户问一句话，AI 生成 SQL，数据库返回结果。

但在企业真实场景里，它经常不准。原因不是模型不会写 SQL，而是业务问题本身并不是一句 SQL 可以直接解决。

字段名不能代表业务含义

数据库字段往往来自系统实现。amount 可能是下单金额、支付金额，也可能是退款后净额；status 可能代表完成，也可能代表取消；created_at 可能是创建时间，但业务统计要按支付时间。

AI 如果只看字段名，就会猜错。

指标口径没有统一

“销售额”“GMV”“成交额”“收入”在不同部门可能不是同一个数字。

是否扣退款？是否包含优惠券？是否排除测试订单？按自然月还是财务月？这些都不是 SQL 语法问题，而是企业自己的业务规则。

没有统一口径，Text-to-SQL 只能生成“能跑的 SQL”，不能保证是企业认可的答案。

业务黑话不在数据库里

企业内部会说“高潜客户”“沉睡会员”“重点门店”“有效订单”“华南大区”。这些词背后可能是规则、名单、字段值和组织关系。

如果语义层没有记录这些信息，AI 很难把自然语言准确映射到数据。

权限会改变答案

总部、区域经理、店长问同一个问题，应该看到不同范围的数据。普通 Text-to-SQL 很容易忽略提问者身份，把“生成正确 SQL”误认为“给出正确答案”。

AskTable 如何承接

AskTable 不是只做 Text-to-SQL，而是在表字段备注、指标口径、字段值索引、业务文档、分析偏好和权限上下文之上回答问题。

SQL 只是执行路径的一部分。真正重要的是：AI 凭什么知道该查哪张表、按哪个口径算、给谁看什么范围。