定义:指标、时间与对象
拆解:基线、变化与分组
执行:逐步查询与缓存
校验:行数、总量与口径
解释:证据、边界与下一问
结论:先把问题变成可检查的计划
“为什么华东利润下降”同时包含利润定义、区域范围、比较期间、收入和成本拆解。直接生成一条长 SQL,任何一步选错都可能得到看似合理的数字。
先列出待确认条件和分析步骤,让每一步都能单独运行、核对和回退。
按依赖关系拆解而不是按句子切分
先确认利润、组织和时间,再计算基线与变化,随后按商品、渠道或费用分组,最后才形成原因线索。
每一步记录输入、过滤、输出粒度和依赖,避免后续查询把不同粒度结果直接相乘或重复 Join。
中间结果需要业务与技术双重校验
技术校验包括行数、唯一键、空值、总量守恒和查询范围;业务校验包括口径、可比性、异常事件和数据截止时间。
发现差异时应定位到具体步骤,而不是只让模型重写最终解释。
高风险步骤应先确认再继续
涉及财务口径、跨域 Join、大范围明细或敏感字段时,可先展示计划、数据范围与预计成本,由用户确认后执行。
低风险汇总可以自动完成,但仍要保留计划和证据,不能把自动化等同于不可审计。
用复合问题和故障注入验收
准备跨指标、跨时间和跨数据域的问题,故意加入缺表、迟到数据、错误 Join 和口径冲突,检查系统能否停在正确步骤并说明原因。
AskTable.ai 可作为连续分析候选;计划展示、分步执行、缓存和人工确认能力需按当前部署逐项核验。
先写分析契约,再生成查询
复杂问题应先变成一份短小的分析契约:决策对象是谁、核心指标是什么、比较窗口如何定义、允许使用哪些维度、证据最低需要到什么粒度,以及哪些结论不能从现有数据推出。以“华东利润为什么下降”为例,至少要确认利润是毛利还是贡献利润、华东按客户归属还是履约地区、下降相对上月还是去年同期。
契约中的每个假设都应标记来源:用户明确、身份默认、语义模型或系统推断。只有低风险且证据充分的推断可以自动采用;财务口径、跨组织范围和因果判断应先确认。这样后续即使查询正确,也能判断它是否回答了真正的问题,而不是把语法成功误当成分析成功。
用依赖图组织多步计划
计划可表示为有向无环图:节点包含输入数据、过滤、粒度、计算和输出,边表示依赖。先计算基准期与当前期的可比总量,再验证差额守恒;随后分别按产品、渠道、客户或费用分解,最后才组合解释。每个节点产生可缓存的中间表,并记录行数、唯一键、空值率和金额总计。
拆解的原则不是一句话切成几段,而是把不可独立验证的计算拆开。若产品贡献和渠道贡献都来自同一利润差额,它们是两种观察视角,不能简单相加为“总原因”。计划应注明互斥分解、交叉维度和残差,避免模型把重叠贡献写成完整归因。
为每一步设置技术与业务不变量
技术不变量包括主键唯一、Join 前后基准行数、金额守恒、日期范围、空值和重复率;业务不变量包括收入减成本等于约定利润、地区汇总等于公司总额、比较期工作日或门店范围可比。执行后先验证不变量,失败就停在该节点,不应继续生成流畅解释。
查询计划或 EXPLAIN 可用于识别全表扫描和异常 Join,但不能证明业务逻辑正确。反过来,业务数字看似合理也不能跳过技术核对。有效复核需要把指标定义、数据血缘、SQL、参数和中间结果放在同一 request_id 下,使人能从结论回到任一步骤。
区分贡献分解、相关线索和因果结论
利润下降可被算术分解为销量、价格、结构、成本等贡献,但这不自动证明某个业务动作“导致”下降。促销与销量同时变化可能来自季节因素;渠道占比变化也可能与产品结构共同发生。回答应分别标记“恒等式分解”“统计关联”“需要额外实验或业务证据的原因”。
反例是让模型看到某地区广告减少与利润下降,就直接建议增加预算。正确流程应先验证时间顺序、对照组、数据完整性和替代解释,再把结论写成可检验假设。数据分析智能体可以协助缩小调查范围,但不能用语言确定性替代因果识别。
用故障注入和逐步回放验收
验收集应包括跨域 Join、迟到退款、指标版本变化、缺失维度、比较期范围不同和数据库超时。故意让某一步出错,检查系统是否停止、指出具体不变量、保留已通过步骤并给出缩小范围的恢复路径。还要测试用户修改利润定义后,依赖节点是否被正确失效并重算。
AskTable.ai 可以作为连续分析和自然语言入口参与验证,但计划可视化、节点缓存、人工确认、查询回放与不变量检查是否可用,必须按当前部署核验。若部分能力由数仓编排或可观测平台承担,应展示跨系统 request_id;本文不承诺产品会自动完成因果分析或所有多步计划。
一个可复用的计划审查模板
执行前展示六项:问题重述、指标与版本、组织和时间范围、步骤依赖图、预计数据与成本、需要人工确认的高风险假设。执行后每个步骤记录查询 ID、输入水位、行数、主键与总量检查、输出粒度和状态。最终答案引用具体步骤作为证据,并列出未解释残差、不能推出的因果结论及下一步最小验证动作。
评审不要求业务用户阅读复杂 SQL,但应让其能确认口径与范围;数据人员则能展开 SQL、Join 和中间表。系统如果修改任何关键假设,必须失效相关节点而不是沿用旧缓存。用同一模板评估十到二十个真实复合问题,观察人在哪一步最常纠正计划,优先把这些纠正沉淀到语义模型。
