2025年7月14日·2 分钟
裘德亚·珀尔的因果思维：更好的 AI、调试与决策
了解裘德亚·珀尔的因果模型如何帮助团队解释 AI 行为、调试故障并在超越相关性的基础上做出更清晰的产品决策。
了解裘德亚·珀尔的因果模型如何帮助团队解释 AI 行为、调试故障并在超越相关性的基础上做出更清晰的产品决策。
一个团队在仪表盘上注意到看似“显而易见”的模式：收到更多通知的用户回访更多。于是他们提高了通知量。一周后，保留率反而下降，流失投诉上升。发生了什么？
原来的模式是真实的——但具有误导性。最活跃的用户本来自然会触发更多通知（因为他们更多地使用产品），同时他们也更频繁回访。通知并没有导致保留；是活跃度同时导致了两者。团队基于相关性采取了行动，结果无意中创造了更糟的体验。
因果思维是一种习惯：问自己——**什么导致什么，我们怎么知道？**你不再停留在“这两件事一起变化”上，而是尝试区分：
这并不是对数据持怀疑态度——而是在把问题说清楚。“通知与保留相关吗？”和“发送更多通知会提高保留吗？”是不同的问题。第二个问题是因果的问题。
本文关注三个实际场景，在这些场景中，单纯找模式往往会失败：
这不是一篇偏重数学的因果推断导览。你不需要掌握 do‑calculus 的记号就能获得价值。目标是给出一套心理模型和团队可用的工作流，用来：
如果你曾经发布过“在数据上看起来不错”但现实中无效的改动，因果思维可能正是缺失的一环。
裘德亚·珀尔是计算机科学家和科学哲学家，他的工作重塑了许多团队关于数据、AI 与决策的思维。在他的因果革命之前，计算领域“从数据学习”更多关注统计关联：发现模式、拟合模型、预测下一步会发生什么。这个方法很强大——但一旦你问的产品或工程问题涉及“因为”这个词，它常常就会失效。
珀尔的核心转变是把因果性当作一等概念，而不是叠加在相关性之上的模糊直觉。不只是问“当 X 高时，Y 也高吗？”，因果思维会问：“如果我们改变 X，Y 会变吗？”这个差别看似微小，但把预测与决策区分开来了。
关联回答“哪些东西倾向于同时发生”。因果则试图回答“如果我们干预，会发生什么”。这在计算中很重要，因为许多实际决策本质上是干预：发布功能、改变排序、添加保护、修改训练集或调整策略。
珀尔通过把因果性框定为一种建模选择加上显式假设，使其更具可操作性。一般来说，你不能仅从数据“自动发现”因果；你要提出一个因果故事（通常基于领域知识），然后用数据去检验、估计和修正它。
这些工具为团队提供了一种共同语言，使他们能从找模式转向以清晰有纪律的方式回答因果问题。
相关性意味着两件事一起变化：当一个上升，另一个倾向于也上升（或下降）。它非常有用——在数据密集的团队中尤其如此，因为它有助于预测和检测。
例如，当温度上升时，冰淇淋销量高涨，一个相关信号（温度）可以改进预测。在产品与 AI 工作中，相关性驱动排序模型（“展示更多相似用户点击的内容”）、异常检测（“这个指标通常跟另一个指标同步”）和快速诊断（“当延迟上升时错误也会上升”）。
问题出在我们把相关性当作另一个问题的答案：**如果我们故意改变某物，会发生什么？**那是因果的问题。
相关关系可能由第三个因素驱动，该因素同时影响两个变量。改变 X 并不一定会改变 Y——因为 X 可能并非导致 Y 变化的原因。
想象把每周的营销费用与每周销售额绘图，看到强正相关。很容易得出“更多投入导致更多销售”的结论。
但假设两者在假期期间都会上升。季节性（一个混杂因子）会驱动更高的需求，也触发更大的预算。如果你在非假期周增加投入，销售可能不会显著上升——因为基础需求并不存在。
当你听到自己问：
当动词是改变、推出、移除或减少时，相关性只是起点——不是决策准则。
因果图——通常画为DAG（有向无环图）——是一种把团队假设可视化的简单方式。你不再用模糊的措辞争论（“可能是模型”或“也许是界面”），而是把故事画到纸上。
目标不是完美真相；而是一份团队可以批评的“系统如何工作的草稿”。
假设你在评估新手引导教程（T）是否提高激活率（A）。
分析中的常见反应是“控制所有可用变量”。在 DAG 术语里，这可能意味着无意中调整了：
有了 DAG，你是有针对性地调整变量以阻断混杂路径——而不是因为变量存在就去调整它。
从白板和三步开始：
即便是粗略的 DAG，也能让产品、数据与工程在运行数字前就围绕同一个因果问题达成一致。
珀尔因果思维中的一个大转变是把观察某件事和改变某件事区分开来。
如果你观察到启用通知的用户保留更好，你学到的是一种模式。但你仍然不知道通知是否导致了保留，还是活跃用户只是更可能打开通知。
一次干预不同：它意味着你主动把某个变量设为某个值，然后观察接下来的结果。在产品术语中，这不是“用户选择了 X”，而是“我们发布了 X”。
珀尔经常把这一区别表述为：
“do”这一思想基本上是在提醒你：你正在打断变量通常取值的原因。当你干预时，通知之所以开启并非因为活跃用户选择了它，而是因为你强制或引导了设置。这就是干预的意义：通过干预来隔离因果关系。
大多数真实的产品工作本质上是干预型的：
这些动作的目标是改变结果，而不仅仅是描述它们。因果思维会让问题保持诚实：“如果我们做这件事，会改变什么？”
你无法在没有关于因果结构（即使是非正式的因果图）的假设下解释干预或设计好的实验。
例如，如果季节性同时影响营销支出和注册，那么在不考虑季节性的情况下“做（改变）”支出仍然可能误导你。干预很强大，但只有在基础因果故事至少大致正确时，它们才能回答因果问题。
反事实是特定类型的“如果怎样？”问题：对于这个具体案例，如果我们采取了不同的行动（或某个输入不同），结果会怎样？这不是“平均会怎样？”，而是“对于这个人/这张工单/这笔交易，结果会变吗？”
当有人要求通向不同结果的路径时，反事实就出现了：
这些问题天然是用户级别的，也足够具体以指导产品改进、政策与解释。
想象一个拒贷模型拒绝了申请。基于相关性的解释可能会说，“储蓄少与被拒高度相关。”反事实会问：
如果申请人的储蓄增加 3000 美元（其他条件不变），模型会批准吗？
如果答案是“会”，你得到可操作的结论：一个可能能翻转决策的现实改变。如果答案是“不会”，你避免了给出误导性的建议（比如“增加储蓄”），而真正的障碍可能是负债收入比或不稳定的就业历史。
反事实依赖于一个因果模型——关于变量如何相互影响的故事，而不仅仅是一个数据集。你必须决定什么可以现实地改变、作为结果会改变什么、什么必须保持不变。没有这种因果结构，反事实可能变成不可能的情景（“在不改变收入或支出的情况下增加储蓄”），从而产生无用或不公平的建议。
当 ML 模型在生产中失效时，根因很少是“算法变差”。更多的是系统中某处发生了改变：你收集的数据变了、标注方式变了、或用户行为变了。因果思维能帮助你停止猜测，开始隔离到底是哪一项改变造成了性能下降。
一些反复出现的问题包括：
这些在聚合仪表盘上看起来可能“一切正常”，因为相关性可以保持高，但模型正确的原因已经改变。
一个简单的因果图（DAG）把调试变成一张地图。它迫使你问：这个特征是标签的原因、标签的结果，还是与我们如何测量它的方式有关？
例如，如果标注策略 → 特征工程 → 模型输入，你可能构建了一个预测标注策略本身而非底层现象的管道。DAG 使这一路径可见，以便你可以阻断它（移除该特征、更改埋点，或重新定义标签）。
别只检查预测，试试有控制的干预：
许多“可解释性”工具回答一个狭窄的问题：为什么模型给出了这个分数？ 它们通常通过突出影响输入（特征重要性、显著图、SHAP 值）来做到这一点。这可能有用——但它并不等同于解释模型所在的系统。
预测解释是局部且描述性的：“这笔贷款被拒主要因为收入低和利用率高。”
系统解释是因果且可操作的：“如果我们以一种能反映真实干预的方式提高已验证收入（或降低利用率），决策会改变吗？下游结果会改善吗？”
前者帮助你理解模型行为，后者帮助你决定该做什么。
因果思维把解释与干预联系起来。不再只是问哪些变量与分数相关，而是问哪些变量是有效的杠杆，当被改变时会产生什么效果。
因果模型会迫使你明确：
这很重要，因为一个“重要特征”可能只是代理——对预测有用，但用于行动则危险。
事后解释可能看起来有说服力，但仍然完全基于相关性。如果“支持工单数”强烈预测流失，特征重要性图可能诱使团队通过“让支持更难联系”来减少工单。这样的干预可能会增加流失，因为工单本身是产品问题的症状，而非原因。
基于相关性的解释在分布转移时也很脆弱：一旦用户行为改变，同样被突出显示的特征可能不再具有相同含义。
当决策带来后果并需要问责时，因果解释尤其有价值：
当你需要采取行动而不仅仅是解释时，解释就需要因果骨干。
A/B 测试是因果推断最简单、最实用的形式。当你随机分配用户到 A 或 B 变体时，你在执行一次干预：你不是观察用户所选择的，而是设置他们所看到的。在珀尔的术语中，随机化使“do(variant = B)”成为现实——因此结果差异可以可信地归因于改动，而不是谁恰巧接触到它。
随机分配切断了用户特质与暴露之间许多隐藏联系。资深用户、新手、时段、设备类型——这些因素仍然存在，但它们在组间（平均上）被平衡。这种平衡是把指标差异转化为因果结论的关键。
即便是优秀团队也并不总能做干净的随机化测试：
在这些情况下，你仍然可以进行因果思考——只是需要明确假设与不确定性。
常见选项包括 差分中的差分（比较不同组随时间的变化）、回归断点（利用如“仅当分数高于 X 才会处理”的临界规则）、工具变量（一个自然的推动因素会改变暴露但不会直接改变结果）、以及 匹配/加权 以使组更可比。每种方法都用假设换取随机化；因果图可以帮助你清晰地陈述这些假设。
在上线测试（或观察性研究）前，写下：主要指标、护栏、目标人群、持续时间和决策规则。预注册不能消除偏差，但能减少指标挑选并使因果主张更可信——也更便于团队讨论。
大多数产品争论听起来像：“发布 Y 后指标 X 变了——所以 Y 有效。”因果思维把问题收紧成更清晰的提法：“改动 Y 是否导致了指标 X 的变化，幅度是多少？” 这种转变把仪表盘从“证明”变成“起点”。
定价调整： 与其问“涨价后收入上升了吗？”，不如问：
新手引导调整： 与其说“新用户现在更常完成引导”，不如问：
推荐排序变化： 与其只看“CTR 提升”，不如问：
仪表盘常把“谁得到了改动”与“谁本来表现好”混在一起。一个典型例子：你发布新的引导流程，但首先向使用最新应用版本的用户展示。如果新版本主要被更活跃的用户采用，你的图表可能显示的提升部分（或大部分）是版本采纳，而不是引导本身的效果。
产品分析中其他常见的混杂因子：
有用的 PRD 节可以直接命名为“因果问题”，内容包括：
如果你在用快速迭代（尤其是 LLM 辅助开发），这一节更为重要：它能防止“我们能很快上线”变成“我们在不知道会造成什么的情况下上线”。许多使用 Koder.ai 的团队会在规划阶段把这些因果问题写进去，然后快速实现有特性标志的变体，采用快照/回滚来在结果（或副作用）令人惊讶时保持实验安全。
PM 定义决策与成功标准。数据伙伴把它翻译成可测的因果估计与合理性检查。工程确保改动可控（特性标志、清晰的暴露日志）。支持分享定性信号——定价改动常“看起来有效”，同时可能悄悄增加取消或工单量。当每个人在因果问题上达成一致时，发布就是学习，而不只是发布。
因果思维不需要博士水平的全面推广。把它当作团队习惯：把你的因果故事写下来，受团队质疑，然后让数据（和可能的实验）去证实或修正它。
要取得进展，请事先收集四项输入：
实践中速度很关键：你把因果问题快速变成受控改动的速度越快，争论模糊模式的时间就越少。这也是许多团队采用像 Koder.ai 这样的平台的原因——从“假设 + 计划”到可运行、可埋点的实现（Web、后端或移动）只需数天而非数周，同时通过分阶段发布与回滚保持严谨。
如果你想复习实验基础，见 /blog/ab-testing-basics。关于伪装成“效应”的常见产品指标陷阱，见 /blog/metrics-that-mislead。
因果思维是一种从“哪些事倾向一起变？”转向“如果我们采取行动，会发生什么？”的转变。裘德亚·珀尔在计算与统计中推动的这类思维，能帮助团队避免那些在真实干预面前站不住脚的自信结论。
相关性是线索，不是答案。
因果图（DAG）让假设可视并可讨论。
干预（“do”）不同于观察（“see”）。
反事实帮助解释单个案例：“如果这一点不同，会怎样？”
好的因果工作会记录不确定性与替代解释。
因果结论需要谨慎：隐藏的混杂、测量误差与选择效应可能颠覆结论。解药是透明——写下假设，展示所用数据，并说明哪些结果会推翻你的主张。
如果你想更深入，可以浏览 /blog 上的相关文章，比较因果方法与其他分析与“可解释性”方法，看各自的适用场景与误导风险。
相关性帮助你用于预测或检测（例如：“当 X 上升时，Y 常常也上升”）。因果关系回答的是决策问题：“如果我们有意改变 X，Y 会发生什么？”
在做预测与监控时可用相关性；在你要发布变更、制定政策或分配预算时应运用因果思维。
因为该关联可能由混杂驱动。在通知示例中，高度活跃的用户既触发/收到更多通知，又更频繁返回。
如果你对所有人都增加通知频率，你改变的是体验（一次干预），但并没有改变用户的内在活跃度——因此保留率可能不会提升，甚至可能下降。
DAG（有向无环图）是一个简单的图示：
它的价值在于让假设显性化，帮助团队达成一致：应该控制哪些变量、不应控制哪些变量，以及哪个实验才能真正回答问题。
常见错误是“控制所有可用变量”，这可能无意中调整了中介或碰撞变量，从而引入偏差。
“See” 是观察自然发生的情况（用户自行选择、分数很高）。“Do” 是主动设定一个变量（发布功能、强制默认）。
关键在于：一次干预会打破该变量通常取值的原因，因此比单纯观察更可靠地揭示因果。
反事实问的是：对于这个具体个案，如果我们做了不同的事，结果会如何改变。
它在以下情景有用：
要做出合理的反事实，你需要一个因果模型，否则你会提出不现实的情形。
关注的是上游发生了什么改变以及模型可能利用了什么：
因果思维会促使你采用有针对性的干预（消融、扰动测试）而不是追逐巧合的指标波动。
并不总是如此。特征重要性解释为何影响预测，并不等同于你应该如何改变系统。
一个“重要”特征可能只是代理或症状（例如，工单数量能预测流失）。对代理采取干预（“通过隐藏支持让工单减少”）可能会适得其反。因果解释将重要性与有效可控杠杆及其在干预下的预期结果联系起来。
当可行时，随机化的 A/B 测试是最佳选择。但当遇到下列情况时，你可能无法随机化：
这时可以考虑准实验方法：差分中的差分、回归断点、工具变量、匹配/加权等——但要明确这些方法所依赖的假设。
在文档中加入一个短节，迫使在分析前就明确：
这能让团队在因果问题上达成一致，而不是事后在仪表盘上拼凑故事。