AI 问数为什么不能等同于 Text-to-SQL？

很多人第一次接触 AI 问数，会把它理解成 Text-to-SQL。

用户问一句话，模型生成 SQL，数据库执行，再把结果返回。

这个链路很清楚，也很容易演示。

但企业真正落地时，Text-to-SQL 只是开始。

Text-to-SQL 解决的是查询生成

Text-to-SQL 的核心问题是：如何把自然语言转成可以执行的 SQL。

例如用户问“上个月各区域销售额是多少”，系统需要生成对应的查询语句。

如果问题简单、表结构清晰、字段命名规范，Text-to-SQL 可以工作得不错。

但企业里的问题往往不简单。

用户问的不是字段名，而是业务语言。

用户关心的不是 SQL 是否能跑，而是答案是否可信。

AI 问数要解决的是业务分析

AI 问数需要回答的问题更完整。

用户到底想看哪个指标？

指标口径是不是唯一？

应该按下单时间、支付时间还是核销时间统计？

用户有没有权限查看这个区域？

查询结果是否需要转成图表？

结果异常时，是否要继续拆解原因？

这些问题都不是 Text-to-SQL 本身能完全解决的。

只依赖 Text-to-SQL 的风险

第一，选错表。

企业可能有订单明细表、订单宽表、财务收入表、门店核销表。问题里说“销售额”，不代表每张表都合适。

第二，算错口径。

退款、取消、测试订单、内部交易、未核销订单是否排除，都会影响结果。

第三，忽略权限。

模型生成的 SQL 可能技术上能跑，但业务上不应该让当前用户看到。

第四，无法解释。

业务负责人需要知道为什么下降，而不只是看到一个下降数字。

更成熟的做法是引入语义和示例

Microsoft Fabric Data Agent 支持 instructions 和 example queries。

Databricks Genie Agent 也强调由数据团队配置 trusted data、metrics、business rules、example SQL queries 和 instructions。

Snowflake Semantic Views 则把逻辑表、关系、维度、事实和指标放到语义视图中。

这些设计背后的共同点是：不要让模型直接猜数据库。

企业需要把业务语义、指标口径和可信查询路径提前交给 AI。

AskTable 的定位

AskTable 的 AI 问数不是单纯 Text-to-SQL。

它需要从问题理解开始，结合 BuildTable 整理出的数据基础、字段语义、指标口径、权限边界和业务知识，生成更可信的回答。

SQL 可以是中间过程，但不是最终价值。

最终价值是业务人员能更快理解数据，并做出判断。

结论

Text-to-SQL 是 AI 问数的一个技术环节。

企业级 AI 问数是一套业务分析能力。

如果只关注“能不能生成 SQL”，很容易低估真实落地难度。

如果关注“能不能在正确权限下给出可信解释”，才真正进入企业 AI 数据分析的核心。

参考来源

• •Microsoft Fabric：Data Agent Example Queries
• •Databricks：Create and Manage a Genie Agent
• •Snowflake：Overview of Semantic Views