冰淇淋销量和溺水人数在统计上同涨同跌，但没人会说是冰淇淋导致溺水——真正起作用的是夏天这个共同原因。相关是「一起变」，因果是「因为所以」，而大模型擅长的是前者。分不清这两件事，是 AI 做数据分析时常见的错误，也是使用它的人容易踩的坑。
两种关系，两种用法
相关性回答的是「这两件事是否一起出现」，因果回答的是「改变其中一件，另一件会不会跟着变」。前者的用途是预测：看到 A 出现，估计 B 大概率出现，很多场景下这已经够用。后者的用途是决策：要不要投入资源去做 A，取决于「做 A 能不能带来 B」。把预测用的相关证据直接拿来支持决策，是数据分析和 AI 问答里常见的一类翻车。
两者的差别可以用一句话记住：相关可以用来「猜」，因果才能用来「改」。想猜明天大概会怎样，相关性就够了；想改变结果，必须先确认因果链条确实存在。
模型为什么容易混淆
原因有三层。其一，它学的是数据里的模式，不掌握产生数据的机制：训练数据里「一起出现」的东西，它就会放进同一段关联叙述。其二，它没有干预能力：判断因果需要「改变一个变量、观察另一个变量」的实验，而模型只是旁观数据，从未对世界做过任何操作。其三，混杂因素常常不在数据里：像「夏天」这种同时推动两件事的共同原因，如果没有被记录下来，任何基于这份数据的模型都无法识别它。
什么时候会出事
预测类任务里，混淆的代价有限——推荐系统按相关性推内容，推得不够准也只是体验问题。决策类任务里代价就大了。典型例子：数据显示「用了某功能的用户留存更高」，据此加大推广这个功能，结果可能毫无效果，因为真实的因果链也许是「活跃用户本来就更愿意尝试新功能」，功能只是活跃度的伴随现象，谈不上是留存的原因。方向反过来的投入，钱和时间都会白花。
怎么把判断拉回因果
有效的做法按成本从低到高排。头一件是追问第三因素：看到相关结论，先问「有没有一个 C 同时导致了 A 和 B」，同时核对时间顺序，原因必须发生在结果之前。其次是分层看数据：把人群拆开分别看，如果相关性在不同子群里消失或反向，混杂的可能性大增。再往后是做实验：A/B 测试通过随机分组天然排掉混杂因素，是判断因果最可靠的方式，关键决策值得为它专门设计实验。最后是明确人机分工：让 AI 负责「发现」——找出数据里值得看的关系，因果结论由结合了业务背景的人来下。
反向因果也常被读成正向。医院数据里「常去医院的人健康状况差」，方向其实是「健康差导致常去医院」；「表现得活跃的用户留存高」，也可能是「快要流失的用户特意回来做最后一波操作」的假象。判断方向有个朴素办法：把结论倒过来说一遍，看哪一句更符合常识和业务流程——谁导致谁，业务里通常有现成的答案，只是被数据的表象盖住了。
把模型当分析员，别当裁判
大模型在因果问题上的正确用法是辅助：让它列出一个相关性背后所有可能的解释（包括混杂因素、反向因果、选择偏差），再逐条设计检验方法，而不是直接采信它给出的因果叙述。同一类模型在不同复杂度的分析任务上表现差异很大，7B 和 70B 的能力差异决定了复杂推理任务该用哪一档；不确定哪档够用时，免费版和付费版的代际差异可以作为试跑起点。想在自有业务数据上做离线验证，也有团队会部署开源权重模型，开源模型的商用边界一文中对可行性有说明。判断标准始终是同一条：凡是准备据此花钱、改流程的结论，必须过实验这一关。
| 任务类型 | AI 能承担的部分 | 人必须补上的判断 |
|---|---|---|
| 销量与运营分析 | 找出一起变动的指标组合，列出可能的解释 | 区分伴随现象和原因，定投入方向 |
| 用户行为研究 | 分层拆数据，标出子群之间的差异 | 判断混杂因素是否存在，设计验证方法 |
| 产品功能决策 | 汇总使用数据与留存表现的相关性 | 用 A/B 测试验证因果，再决定放量 |
| 报告与结论审核 | 检查结论是否超出数据支持的范围 | 对「因为…所以…」逐条追问第三因素 |
相关与因果速查
- 相关是「一起变」，因果是「改变 A，B 跟着变」
- 模型旁观数据、做不了干预，因果结论要靠实验补
- 先问第三因素，再核时间顺序，最后才谈实验
- 「用了功能的用户留存高」不等于功能导致留存高
- 花钱、改流程级别的结论，一律过 A/B 测试
