一条SQL能跑通，不等于分析结论是对的。一段Python没有bug，也修不好一个从源头就错掉的业务假设。
2026年10月9日，Databricks宣布Genie One的代码执行功能进入公开预览。这个动作释放的信号很清楚：企业分析智能体正在从"返回SQL结果"走向多步计算、统计分析和情景推演。随之而来的工程问题是——如果第一步返回的数据看起来合理、语义上却是错的，后面几步老老实实建在它上面，会发生什么？
整条链路大致是这样：问题 → 指标解析 → 选表 → JOIN → SQL → Python分析 → 图表或预测 → 业务结论。每一个环节都能成功执行，最终决策却可能是错的。这种风险可以叫"分析误差传播"，它是一种通用的架构风险。
一个最小例子：语法正确，收入虚高
设想一张订单表里有两行订单明细，金额分别是100和50；一张支付表里有三条支付记录，金额分别是60、50、40。订单明细合计150，支付合计也是150。
现在智能体生成了这样一条查询：把订单明细表和支付表按订单号JOIN，再对明细金额求和。JOIN本身合法，数据库行为也完全正确，但两行明细乘以三条支付记录，连接后变成六行，求和结果成了450，而不是150。虚高了3倍。
针对这个指标，正确的修法不是随手加DISTINCT，而是用对的事实粒度：如果获批的收入指标不需要支付数据，就别把支付行连进来，直接对订单明细求和即可。如果分析确实需要支付数据，就先把每张事实表聚合到兼容的粒度，再合并。
这里有个关键区分：订单明细合计并不自动等于公司确认的收入。那取决于获批的业务定义。正确的粒度解决了扇出问题，但解决不了会计口径问题。
错误是怎么往下传的
假设智能体把这条虚高的查询结果喂给Python笔记本，后面的分组、环比、预测、摘要全部基于它展开。Python可能一行bug都没有，但输出会变成：错误的区域收入合计、误导性的国家排名、失真的增长率、建立在无效基线之上的预测，以及对一次根本没发生过的下滑或复苏的、听起来很有说服力的解释。
有个细节值得注意：如果这个放大倍数在不同时期还不一样，连百分比增长率都会算错。这就不只是数值被整体放大那么简单了。
在给智能体更多分析自主权之前，有四道正确性边界值得设卡。
- 业务含义：收入到底指什么？已下单、已开票、已确认、已收款，都可能是有效指标，但不能互换。选定的定义要显式表达出来，包括指标ID、归属方、聚合方式、时间维度和审批状态。如果两个指标都说得通，就澄清或套用受治理的默认值，别按列名相似度悄悄选一个。
- 物理映射：业务术语最终落到哪些字段？要核对来源字段、类型、过滤映射和日期语义。"欧洲"可能指客户所在地、销售区域，也可能指法人实体。
- 关系与粒度：键关系合法，不足以保证分析用的连接合法。要检查连接基数、事实粒度、桥接表、扇出风险和空值行为。一个实用的预检办法是：在提议的连接前后对比行数和业务键去重数，出现意料之外的成倍增长就该停下来查。
- 分析执行：只有查询地基验过了，才该让智能体继续往下算。已解析的指标、维度、过滤条件、时间窗口和数据集身份，要在每一步之间保持不变。后面的预测工具不该悄悄从确认收入切换到开票金额。
把查询计划当成一份契约
与其在智能体各阶段之间只传一条SQL，不如保留一份结构化的分析契约：问题、指标、指标归属方、维度、周期、事实粒度、连接路径，以及各项校验是否通过。这些校验值必须由真实的校验程序产出，而不是由语言模型自己声称。
一条更稳妥的流水线是：自然语言问题 → 解析业务含义 → 概念映射到物理数据 → 检索候选关系 → 校验基数和粒度 → 构建并校验查询计划 → 执行SQL → 跑Python、统计和预测 → 带证据返回结论。这样就把"找到一条看起来可行的路径"和"证明这条路径对该指标是安全的"分开了。
别只看执行成功率
生产环境的分析智能体，值得追踪的指标包括：SQL执行成功率、指标解析准确率、连接与基数校验通过率、粒度校验覆盖率、多步上下文一致性、端到端答案正确性。执行成功率是必要的运营指标，但它不是业务正确性指标。
随着智能体能跑代码、做预测、解释趋势，人们很容易把注意力放在分析引擎有多先进上。但更危险的失效模式可能简单得多：智能体一开始就用错了指标或连错了表，然后在错误的数据上做越来越复杂的运算。更好的推理，修不好对数据的错误理解。
热门跟贴