发帖
雷达卡
你在学术界学到的所有因果推断知识都是正确的，但这些知识还远远不够——我们大多数从事应用因果推断的人都有这样的体会。
事实上，关键差异在于依赖分析结果的决策所具有的重要性：并非每一项决策都值得投入同等水平的证据支持。让你的严谨性和因果推断方法与决策的重要性相匹配，否则只会浪费资源。
以产品探索为例。在开发和发布产品之前，需要在多个环节验证大量假设。若每一个答案都追求完美的因果推断，意义何在？这不过是在一个包含众多相关、甚至必要但单独来看并不充分的决策棋盘上，向前挪动一小步而已。得益于重视增量证据、学习和迭代的流程，风险已分散、对冲到了多个决策中。
与此同时，因果推断伴随着实际的机会成本：严谨性会延迟产生影响的时间，而可能有另一个项目正等待着你——在那个项目中，这种严谨性才真正有助于提高决策质量（降低风险、提高准确性和可靠性）。
我常用“最终决策与建设性决策”这一框架来简化这一理念：
建设性决策推动流程向前推进。“我们是否应该进一步探索这个功能？”“这个用户问题是否值得深入研究？”——决策失误会让你损失一个冲刺周期，最多两个；但决策正确，目前也不会改变公司的格局。
最终决策需要投入资源或改变方向，决策失误的代价高昂且难以挽回：“我们是否应该投入200万美元开发这个项目？”“我们是否应该终止这条产品线？”“我们应该将更多营销预算分配到这个渠道还是那个渠道？”
在科技行业，决策的数量和速度都是无与伦比的。有时，这些是最终决策，但更常见的是建设性决策。
作为数据科学家，我们会参与这两种类型的决策。若无法区分当前面对的是哪一种，就会提出错误的问题或追求错误的答案，最终浪费资源。
在本文中，我想分享三个规则——每当开展因果推断项目时，我都会反复回顾这些规则：
从问题出发，而非答案
如果无需因果推断就能更轻松地解决问题，那就这么做
在因果推断项目中也应用80/20原则
规则听起来往往枯燥乏味，但实际上，这些规则帮我大幅提升了工作影响力。
下面我们来详细解读。
1. 从问题出发，而非答案
每一个因果推断项目都始于你试图解决的问题，而非识别策略和估计方法。这是“做正确的事”而非“正确地做事”的完美例子。你的方法可能无懈可击，但如果解决的是错误的问题，又有什么价值呢？提醒自己，以一个清晰明确的业务问题启动项目，那么在项目真正开始之前，你就已经完成了50%的工作。
如果你技术能力很强，很可能熟悉因果推断项目的流程：从有向无环图（DAG）到模型，再到推断、敏感性分析，最终得出答案。
但你了解组织中解决问题的流程吗？
问题背后的真正问题
大问题会被分解成小问题。对于需要寻找解决方案的团队来说，这样更易于处理，也能让我们调动多个团队解决更大（子）问题的不同部分。同一团队内的不同角色也是如此：你在估计客户流失的驱动因素；而你的产品经理需要这个结果来决定是投资于客户留存还是用户获取。
这就是挑战所在：作为数据科学家，你正在解决的问题往往并非最终目标。
你的问题嵌套在其他人的问题之中。你周围和上级的人，需要你的答案作为他们解决自身问题的一个输入。认识到这种依赖性，你就能调整因果推断方法，使其真正贴合上游的需求。这样做的好处是具体的：能更紧密地对齐关注的因果估计量，或者更快地判断出完全无需使用因果推断。归根结底，这能缩短获得洞见的时间。
有一次，我沉迷于网络理论（2018年，正是马尔可夫随机场让我理解了有向无环图）。在我看来，一切都是网络。于是我着手构建了我们内部商业智能（BI）工具使用情况的网络：所有仪表板都是节点，当同一用户使用不同仪表板时，节点之间的边会变粗。我计算了各种中心性指标，识别出了具有影响力的仪表板——那些能将不同部门连接起来的仪表板，还有更多相关分析。我围绕这些分析构建了一整套故事，但最终没有任何后续行动。问题在于，我从未关注过利益相关者试图解决的真正问题。或许我以为这个决策属于最终决策类型，但它自始至终都是一个建设性决策。一个简单的仪表板使用量统计就足以完成任务，但我却把它当成了一个研究项目。
这就是曾经的我。而且类似的事情后来也发生过。但我学到的教训是：从问题出发，而非答案。
反规则：关注错误的问题
如果你想快速浪费资金，那就去解决错误的问题。这样做不仅会让解决方案无法产生实际成果，而且在那段时间里没有解决正确问题的机会成本也会不断累积。
因此，在积极寻找问题背后的真正问题时，当你找到它，要批判性地判断这是否是一个值得开始解决的正确问题。
从这个意义上说，从答案出发反而能提供一种检验方法。但具体做法略有不同。问问自己：
如果我们得到了这些答案，我们会知道哪些以前不知道的信息？
如果我们知道了这些信息，那又如何？
如果“那又如何”这个问题的答案不仅对你有意义，对你的经理以及他们的经理（按理说）也有意义，那么你就找对了问题。
就是这么神奇。
2. 如果无需因果推断就能更轻松地解决问题，那就这么做
不存在千篇一律的因果推断方法。某些方法之所以成为标准，是因为我们已经充分梳理了它们的假设条件，而非因为使用它们是机械性的操作。每种情况都可能以其独特的方式违背这些假设，而每种情况都值得投入充分的严谨性。
但问题在于，从资源角度来看，我们无法为所有情况都提供这样的严谨性。
这时，应用因果推断就变成了一种经济决策：我们应该投入多少资源，才能在达到必要置信水平的前提下，获得期望的结果？
下次遇到问题时，不妨问问自己这个问题。
幸运的是，并非每一项分析都需要像完整的因果推断项目那样严谨，才能让投资回报率转为正值。
替代方案：常识、领域知识和关联分析，也能得出足够好的答案。
说这话确实有点让人不舒服；追求原则性和严谨性的我，现在有点讨厌自己。但我学到，将这种权衡作为一种战略选择是值得的。
举个例子来说明：
问题是：我们是否应该进一步投资于功能A？现在，我可以很容易地将其转化为：功能A对用户获取/留存有什么影响？（这在SaaS场景中是一个非常常见的角度，本质上是一个因果问题）
如果影响很大，我们就投资；否则就不投资。
仅仅一个“影响”一词，就会让我直接进入因果推断模式，因为影响≠关联。但我们知道，因果推断的成本很高。这个问题值得吗？有没有替代方案？
一种方法是了解有多少用户在使用这个功能。考虑到用户选择使用该功能，他们的使用频率如何？这能表明该功能可能具有的价值，并发出我们可以进一步投资该功能的信号。无需双重差分（diff-in-diff）、逆概率加权（IPSW），也无需A/B测试：但如果这些答案是否定的，精确的因果推断还有意义吗？
真相可能介于两者之间；这些问题的答案可能更具指示性而非决定性，而主要问题可能仍然悬而未决。但可以肯定的是，比起开始时，问题已经不那么模糊了：如果这些答案引发了更深入的研究，那么产品团队就已经在行动了，而且很可能是朝着正确的方向。或许之后会进行更严谨的因果推断。
反规则：跳过因果推断存在风险
假设产品团队从你的分析中获取了信号，并对该功能进行了一些实质性的“改进”。由于样本量小且时间紧张，他们跳过了A/B测试，直接发布了改进版本。
狂热的实验主义者此时会感到崩溃。但我认为，如果有人经过计算后得出结论：进行实验的风险大于不进行实验的风险，那么这很可能是一个正确的决策。当然，我把这个案例设定得非常笼统，没有人能真正为任何一方辩护。这超出了本文的重点。
但之后，当团队进入下一个冲刺周期时，产品经理仍然强调，从之前发布的版本中学习经验教训至关重要。他们仍然希望：a）了解改进的影响；b）某些用户群体受到的影响是否更大或更小。
你会很高兴，因为“学习→迭代”正是你试图培养的思维模式。但你也会感到困扰，至少有三个原因：
缺乏可交换性：你知道使用该功能的用户是一个高度自我选择的群体。将他们与非用户进行对比？真的可行吗？
交互效应：假设某个用户群体确实受到了更大的影响。现在回想第一点：我们是在以高度活跃的用户为条件进行分析。可能这个群体表现出更大的影响，仅仅是因为这些用户本身就高度活跃。当我们考虑活跃度较低的用户时，同一个群体可能不会表现出这种差异性影响。但你无法得知这一点——你的工作数据只偏向于高度活跃的用户。
碰撞偏差：在更糟糕的情况下，以高活跃度为条件可能会逆转用户群体与关注结果之间的关系。这样的分析会将团队引向错误的方向。
3. 在因果推断项目中也应用80/20原则
这个标题可能会误导你。我并不是说要敷衍你的分析：当问题需要充分的严谨性时，就必须投入足够的精力。这里的80/20原则是指，在一项决策中，你的精力应该分配到哪些方面，而不是你在因果分析部分钻研得有多深。
回想一下“嵌套问题”的理念。你的因果推断项目通常嵌套在一个更大的商业决策中，而且它很少是唯一重要的维度。利益相关者必须权衡成本、时间、战略契合度、可逆性，以及你的估计结果。因果推断并非我们需要了解的全部。
如果你的因果答案在该决策中仅占30%的权重，却将其当作100%来处理，就是一种浪费。更糟糕的是：这是一种带有机会成本的浪费，因为剩下的70%仍未得到解答。
这就是“最终决策与建设性决策”框架的价值所在。对于建设性决策，将精力分散到多个维度上，几乎总是比专注于一个维度更好。对于最终决策，因果维度往往是核心，此时精力分配的逻辑就会反转。
规则1、2和3相互重叠，但并不相同。规则1问的是你是否在解决正确的问题。规则2问的是你是否根本需要因果推断。规则3则假设你已经通过了前两个规则的检验。现在的问题是：在项目内部，你是否在回答正确的多个问题，并让因果推断仅承担它实际应有的权重？
交付决策，而非估计结果
最近的一个项目：估计新定价层级对每用户收入（revenue per user）的影响。出于本能，我选择了我能想到的最简洁的识别策略：带有平行趋势敏感性分析的双重差分、安慰剂检验，或许还会加上合成控制法以确保结果可靠。这很容易需要一个月的时间。
但当我跳出细节，发现产品经理有三个未解决的问题，而不仅仅是一个：
对每用户收入的影响是什么？（因果性）
我们是否在蚕食现有定价层级的用户？（因果性，不同结果）
如果效果不佳，这种调整的可逆性如何？（非因果性；属于运营和产品问题）
花一个月时间解决问题1，会导致问题2和3只能得到半吊子的答案。这个决策需要三个问题的答案都大致正确，而不是一个问题的答案绝对精确。因此，我在两周内完成了问题1的简化版双重差分分析（并明确标注了局限性），将剩余时间用于解决问题2和3。利益相关者带着全面的情况进入决策会议，而不是一个数字和两个无奈的耸肩。
反规则：当因果问题就是决策本身时
如果在一个因果估计结果就是整个决策核心的项目中应用80/20原则，你就会掏空分析的核心价值。
这就是最终决策场景。“我们是否应该向这个渠道投资200万美元？”“这种处理方式是否能显著降低客户流失率？”当其他维度要么已经确定，要么确实是次要因素时，因果估计结果就不是众多输入之一，而是唯一的输入。为了腾出时间去做那些不会改变决策的工作而在这方面偷工减料，就违背了最初的规则：此时你又在错误地分配资源。
关键在于判断你所处的场景。一个快速的测试方法：如果你无法列出利益相关者除了你的估计结果之外还需要的三个维度，那么你的因果答案很可能就是决策本身。不要在这样的项目上应用80/20原则。
那么，接下来该怎么做？
这些规则适用于所有分析工作，而不仅仅是因果推断。但在我过去的工作中，因果推断是我最能感受到这些规则重要性的领域。
每当我忍不住想要为一个没人问过的问题设计一个完美的合成控制法时，我都会在心里提醒自己：
我们从研究中学习方法。这一点我永远不会停止。但在实际工作中，我们要敏锐地判断应用这些方法何时能带来价值，何时不能。
如果这些规则中的任何一条能让你下次节省一个冲刺周期，或者避免与产品经理发生争执，那就是一种胜利；而这些胜利会不断累积。严谨性要在关键时刻体现出来。你其余的时间，应该用在同样重要的事情上。
推荐学习书籍 《CDA一级教材》适合CDA一级考生备考，也适合业务及数据分析岗位的从业者提升自我。完整电子版已上线CDA网校，累计已有10万+在读~ !
京公网安备 11010802022788号
