数据没算错,AI 为什么还是分析错了?

数据与 AI 实践 · 智能决策专栏

数据没算错，AI 为什么还是分析错了？

用一次成交下滑 15% 的复盘，看清事实、统计分解与因果证据的边界

题图｜当 SQL 与报表数字完全准确时，真正的风险往往藏在从“数字”跳向“原因”的那一步。

一家线下门店正在复盘最近两期的获客与转化效果：前后两批到店新客同样都是 1000 人，但最终成交人数却从上期的 200 人 掉到了本期的 170 人。老板把报表交给 AI 助手，问：“到店客户明明没少，为什么成交下降了？”

几秒钟后，AI 给出了一段看似极其顺畅的回答：“整体转化率从 20% 下降至 17%，说明销售团队跟进不足、接待有所松懈。建议加强销售培训，提高课后跟进频次。”

你看，加减乘除没有算错，整改建议也很具体。但致命的问题，恰恰出在中间那个轻描淡写的“说明”上——汇总报表只记录了“少成交 30 人”的结果，却没有任何一个字段直接记录了团队为什么没成交。 本文将顺着这个典型教学算例，一步步拆解 AI 是如何在算术正确之后跨过证据边界的。

图 1｜同样的总量下滑可以对应多种候选原因；仅凭汇总表无法直接断定是谁之过。

01 口径核验｜先确认我们究竟在比较什么

在追问“为什么下降”之前，第一步要先锁死统计口径：报表里的“成交下降”究竟是如何定义的？这份报表比较的是同一家门店、两个等长获客周期内首次到店的新客，及其到店后满 30 天观察窗口内的有效首单成交情况。两批客户均已走完完整的 30 天观察窗口。

这里的成交人数，按到店后第 30 天仍有效的首笔订单统计，每名客户最多计一次——它不等同于自然月的笼统交付量，也不包含老客复购订单。两期数据的去重逻辑、退订剔除和渠道归属规则完全一致，底层订单与客户明细也已核对无误。

核对到这里，我们可以确凿地认定两条事实：第一，成交人数减少 30 人，相对上期 200 人的降幅是 15%，而转化率从 20% 变成 17%，下降的是 3 个百分点（两种表述对应不同算式，汇报时绝不能混用）；第二，这两批客户中，本期的整体转化率确实更低。

但此时，“销售跟进变差”、“客户需求减弱”、“竞争对手促销”依然只是并列的候选解释。当前这张三行汇总表还不能替其中任何一条作证。尤其容易被忽略的盲区是：两批到店客户的总人数相同，绝不代表两批客户的内部构成相同。 如果把“总人数没变”误读成“其他条件都没变”，就会把所有账面落差都压到销售团队身上。下一步，应该先看这 1000 人分别从哪里来。

02 结构拆解｜渠道内没有下降，整体却下降了

把同一批客户按首次登记的获客来源展开。为便于直观复算，示例中门店仅有两个互不重叠、覆盖全部新客的渠道：老客转介绍 A 和 线上推广 B。

展开之后可以看到：转介绍渠道 A 依然是每 100 人成交 30 人（30%），线上推广渠道 B 依然是每 100 人成交 10 人（10%）。两个渠道各自的转化率分毫未变，真正改变的是它们在总客流中的占比。

图 2｜总体转化率是按各渠道到店人数占比加权的平均值；高转化渠道占比萎缩直接拉低了总体均值。

上期两个渠道各占一半，加权整体转化率是 20%。本期转介绍渠道少了 150 人（对应少成交 45 人），线上推广渠道多了 150 人（对应多成交 15 人），合起来恰好净少成交 30 人。在数据分析中，这就是典型的结构效应（Mix-Shift Effect）。

03 证据边界｜算清了账面差额，不等于查明了业务原因

发现渠道构成变化之后，人们很容易出现第二次归因跳跃：“既然转介绍客户减少了 150 人，那主要原因一定就是渠道运营团队不力。”

这个结论依然走得太快了。转介绍到店人数为什么从 500 变成 350？可能是邀请激励活动减少，也可能是上期刚办过集中裂变活动透支了存量需求，或者是活动触达了不同人群。账面上的人数增减，不会自动告诉我们背后的业务过程。

在复盘时，必须把两类问题严格分开：统计分解（Statistical Decomposition）回答的是“账面差额由哪些部分组成”；因果判断（Causal Inference）回答的是“什么变化促成了结果，以及改变某项做法能否改善结果”。 下一轮调查，应该把候选解释转化为一张可核查的证据清单：

这些过程记录能让解释更有根据，也能直接揪出逻辑矛盾。例如，若跟进延迟是在成交下滑之后才出现的，就绝不能用它去解释此前已经发生的下降——证据的时间先后顺序必须对得上。 但也要注意，“出现得早”、“同时变化”或“分组后仍相关”，都不单独构成充分的因果证明；更细的分组也不必然更正确，还必须判断分组变量在业务链路中扮演什么角色。

同样，千万不要因为看到转介绍渠道的历史转化率更高（30%），就直接拍板把所有推广预算全部转过去。新增客户能否维持原有的高转化率、老客转介绍池子是否还有增量空间、每单边际获客成本（Marginal CAC）如何，都还需要独立测算。

04 幻觉剖析｜AI 容易在哪一步把“假设”写成“结论”？

回顾整条分析链路，这类归因错误往往发生在“算术完成之后”。大模型即使分毫不差地读出了每一个数字，仍极易在解释数字时跨过证据边界：

图 3｜事实、统计解释与因果判断处于不同证据阶梯；每向右推进一步都必须补充对应颗粒度的依据。

第一，把行业一般经验直接套成了这家门店的现场事实。 “跟进不及时可能降低成交率”是一个合理的通用业务机制，但要判断本次下滑是否由它造成，必须依赖这家门店的现场过程记录与可比对照。熟悉常见原因，不等于观测到了实际原因。

第二，顺着提问里已经藏好的预设结论作答。 如果提问本身是“销量下降说明团队执行不力，请分析具体问题”，任务指令就已经把待验证的解释当成了既定前提。模型会顺着这个前提补充细节，最终生成一份逻辑连贯却未经证实的报告。

第三，把“列出原因”当成了“完成分析”。 只提供一张汇总表，却在指令中要求“必须给出三个主要原因”，会迫使模型用没有来源的解释去填补空白。严谨的分析应该允许模型明确回答：目前已定位到渠道构成变化，但尚不能确认变化由什么造成。

这并不意味着大模型完全不会因果推理——它可以利用常识与领域知识辅助构建候选因果图谱，但同时也存在不可预测的越界风险。对具体业务场景而言，再强的模型推理能力，也不能替代尚未采集到的现场证据。

05 工程落地｜让 AI 交付一份能够复核的分析

面对同一道业务复盘题，我们可以把给 AI 的任务指令改成下面这样——核心原则是强制让结论与证据等级一一对应，并明确允许保留未知：

图 4｜通过四层结构化输出契约与系统底座留痕，将 AI 从“编故事模式”切换到“可复核工程模式”。

落到本例，一份经得起业务与数据团队交叉复核的分析报告如下表所示：

需要注意的是，随机分组试验能帮助我们评估某项新邀请方式的效果，但一次短期改善仍不能保证长期有效，更不能自动证明“它就是上一轮下降的原因”。在无法开展随机试验的场景下，也可以做历史或跨店可比对照，但必须在报告中诚实说明比较所依赖的前提假设和仍未排除的差异。

当这套方法真正沉淀到企业的智能决策或 Agent 系统里时，还应在工程底层同步保存查询口径版本、分组拆解结果、数据表来源血缘和核验记录。提示词负责规范表达任务，而扎实的数据底座和检查流程，才负责让每一个业务结论都可以被追查。