SQL 写对了，答案为什么还会错？

Fri, 04 Sep 2026 00:00:00 +0000

数据分析里最危险的结果，往往不是一条报错的 SQL，而是一条顺利运行、数字精确、图表漂亮，却回答了错误问题的 SQL。

假设运营问：“本月新增客户是多少？”系统找到 customer 表，按 created_at 统计去重 ID，返回 12,486。查询没有语法错误，结果也能复现。但销售团队口中的“新增客户”是首次付费客户，财务还要求排除退款和内部测试账户。12,486 只是“本月新建客户记录”，不是提问者准备据此做预算的指标。

SQL 没有错。错误发生在 SQL 之前。

正确性不是一个开关，而是一条链

一项数据结论至少要通过四层正确性：

语法正确：查询能被数据库解析和执行。
数据正确：表、Join、粒度、时间和质量状态符合任务要求。
口径正确：计算使用了组织认可、在当前时间有效的业务定义。
解释正确：结论没有超出证据，限制条件和不确定性被如实表达。

大多数 Text-to-SQL 指标首先测的是前两层的一部分。企业真正承担决策风险的，却是后两层。

五种常见的“正确地算错”

1. 同一个词，在不同团队代表不同事件

“客户”可能是注册用户、通过认证的企业、首次付费账户或签署合同的主体。“收入”可能是下单金额、支付金额、确认收入或扣除退款后的净收入。字段名相似，并不能证明业务含义相同。

Agent 如果静默选择一个定义，会让偶然的猜测看起来像确定事实。更好的行为是检索权威定义；存在多个有效口径时，把候选项和数字影响展示给用户确认。

2. 时间窗口没有对齐

“本月”可能指自然月、最近 30 天、财务账期，也可能受用户时区影响。同比还隐含工作日、节假日和完整周期是否可比。SQL 中一个看似无害的 CURRENT_DATE - 30，就可能改变管理层对趋势的判断。

3. Join 改变了数据粒度

订单表是一行一单，商品明细是一行一个 SKU。两表直接 Join 后对订单金额求和，会把多商品订单重复计算。查询能运行，抽样看起来也合理，只有先声明目标粒度并检查 Join 前后的行数和唯一键，才容易发现问题。

4. 状态过滤散落在历史 SQL 里

是否排除取消单、退款单、测试账户和风控交易，经常没有写在字段说明里，而是藏在某张看板或某位分析师维护的查询中。只给 Agent schema，相当于只给它词典，没有给它组织的会计规则。

5. 定义已经改变，答案仍在引用旧版本

指标口径会随业务发展而调整。文档、看板、语义层和历史 SQL 如果不同步，同一问题在不同入口会出现多个“官方答案”。这类版本漂移必须通过负责人、生效时间和弃用状态处理，不能靠模型选择看起来最新的一段文字。

为什么把更多 schema 塞进上下文仍不够

Spider 2.0 把 Text-to-SQL 放进更接近企业的环境：632 个工作流问题，数据库经常包含上千列，任务还需要检索元数据、方言文档和项目代码。论文发布时的基线结果显示，经典基准上的高分并不会直接迁移到这种复杂环境。

指标治理 on DataAgentX