# ai 问数

AI 问数进入生产后，一次自然语言任务可能拆成大量 SQL，并在字段猜错、结果为空或多 Agent 探索时反复重跑。本文给出一套 Pro 成本守门清单，从任务预算、查询估价、并发与扫描限制，到缓存复用、取消传播和逐问题账单，帮助数据团队防住查询风暴。

Berkeley BAIR 讨论 Agent 成为数据库新用户后，一次根因分析可能展开成上千条 SQL，且多 Agent 实验里只有约 10%–20% 的子计划真正不同。做 AI 问数的团队如果只验最终答案，不看重复查询、并发、扫描量和取消机制，数据库会先替模型交学费。

很多数据团队一听语义层，就想到老 BI、指标平台和数据治理文档。但 Power BI、Databricks、MIT 和 Lyft 最近都在重新谈 semantic layer。对数据分析师和数据工程师来说，真正的问题是：怎么从 20 个高频业务问题开始，把指标、维度、权限、质量和拒答规则写成 AI 能调用的数据说明书？

很多公司做 AI 问数时，先关心模型会不会写 SQL，却忽略了一个更普通的问题：公司有没有一本能说明指标口径、数据来源、权限边界和适用场景的指标说明书？对数据分析师和 BI 同学来说，AI 最先暴露的往往不是模型能力，而是组织没有把业务语义写下来。

Power BI、Databricks 和 MIT 最近都在把语义模型、治理台和 GenAI 放到一起讲。对数据分析师和 BI 同学来说，问题不只是报表会不会被 AI 取代，而是你的指标、权限、口径和解释，能不能变成 AI 也能调用的业务接口？

AI 问数和 Text-to-SQL Demo 往往很顺：输入一句话，模型生成 SQL，图表立刻出现。但一到真实企业上线，就会遇到权限、口径、表名、脏数据和责任边界。本文从一次上线评审讲起，拆解 AI 问数翻车的 4 个原因，以及上线前必须补的 5 个基础动作。

AI 问数和 Text-to-SQL 正在进入数据团队，但数据分析师、数据开发和 BI 同学真正要担心的，不是模型不会写 SQL，而是它写得太顺、错得太像对。本文从一次指标复盘会讲起，拆开 AI 写 SQL 的 3 类背锅风险、1 段 SQL 对照、10 项上线检查和 20 个高频问题模板。

一次 AI 问数 Demo 里，模型把 LEFT JOIN 改成 INNER JOIN，SQL 看起来更短、更顺，却让未转化用户被悄悄排除。AI 写 SQL 的风险不只是语法错误，而是错得很像对的。本文拆解生成错误、业务逻辑错误和可信问数系统的边界，并自然介绍 Forge。