Causal Discovery / DoWhy / EconML / Structural Causal Models 解读

面向对象: AI Product Strategy Lead / Decision Intelligence PM / Enterprise Architect / Risk Analytics Architect。 核心问题: AI 产品容易把相关性误当效果。金融零售里的营销、授信、风控、运营和体验改造，真正要回答的是“如果我采取这个动作，会造成什么变化”，而不是“哪些变量一起变化”。 学习目标: 理解 SCM、DAG、causal discovery、causal inference、DoWhy、EconML、DAGitty、NOTEARS、混杂、可识别性、干预和敏感性分析，并映射到 AI 产品决策和架构治理。

---

Source Anchors

一句话:

Causal AI 的核心价值不是“让模型更聪明”，而是把产品、运营和风险决策从相关性 dashboard 升级到可审查的 intervention evidence。

---

1. 相关性产品为什么危险

常见 AI 产品误区:

这些结论可能被混杂因素污染:

• 优惠券发给了本来就活跃的客户。
• 人工复核的是模型已经筛过的高风险交易。
• 高收入和职业稳定性、资产结构相关。
• 使用 Copilot 的团队本来成熟度更高。
• 提醒发给了更容易联系的客户。

因果思维的产品问题是:

如果我们对某类客户采取动作 A，而不是不采取，会带来什么增量影响？

---

2. SCM 与 DAG: 把假设显性化

Structural Causal Model 关注变量之间的生成关系。DAG 是把这些关系画出来的工具。

例子:

Customer income -> credit limit -> default
Customer income -> default
Macro condition -> income
Macro condition -> default
Marketing offer -> spending -> default

DAG 的价值:

• 让团队显性讨论假设。
• 区分混杂、媒介、碰撞变量。
• 判断哪些变量应调整，哪些不应调整。
• 明确什么证据可以支持或推翻结论。

产品经理和架构师不需要把自己变成因果统计学家，但必须能组织 DAG review，防止 AI 团队把漂亮相关性直接变成政策。

---

3. Causal Discovery vs Causal Inference

两者经常被混用:

NOTEARS 这类方法尝试从数据中学习 DAG，但产品使用时要保持克制:

• 它可以生成候选结构，帮助发现问题。
• 它不能替代业务知识、实验设计和审查。
• 它依赖无环性、函数形式、噪声假设和观测变量完整性。
• 对隐藏混杂敏感。

更成熟的流程:

business question -> expert DAG -> discovery-assisted challenge -> identification -> estimation -> refutation -> decision

---

4. DoWhy: 建模、识别、估计、反驳

DoWhy 的工作流适合产品架构师理解因果证据链:

这套流程适合放入高风险 AI release gate:

• 营销 uplift 策略上线。
• 信贷政策调整。
• 催收联系策略。
• 风控拦截策略。
• 客服 AI 对 SLA 和投诉的影响。

---

5. EconML: 异质性处理效果与策略学习

很多产品问题不关心平均效果，而关心谁受益、谁受损。

EconML 的价值是把机器学习能力用于估计异质性处理效果。产品上要把它和政策引擎结合:

CATE estimate -> risk guardrail -> eligibility policy -> treatment assignment -> outcome feedback

---

6. 因果假设与可识别性治理

因果系统最重要的不是算法，而是假设治理。

Assumption register:

产品 gate:

• 没有 DAG，不进入因果评估。
• 没有识别说明，不进入政策建议。
• 没有敏感性分析，不进入高风险上线。
• 没有人群影响评估，不进入客户级自动决策。

---

7. Causal-to-Decision 架构

decision question
  -> causal graph workspace
  -> data cohort builder
  -> identification and estimation notebook/service
  -> refutation and sensitivity checks
  -> policy simulation
  -> decision memo
  -> experiment or controlled rollout
  -> outcome monitoring

关键组件:

---

8. 金融零售案例映射

Case A: 营销 Uplift

• Treatment: 是否发放优惠券。
• Outcome: 30 天增量消费或复购。
• Confounders: 历史活跃、客群、渠道、地区、季节、过去优惠响应。
• 输出: CATE 分层，识别 persuadable customers。
• 决策: 只向增量效果为正且投诉风险低的人群发放。

Case B: 信用额度政策

• Treatment: 提额。
• Outcome: 利息收入、消费增长、逾期、坏账。
• Confounders: 收入、历史还款、风险等级、宏观环境。
• 输出: 收益和风险的异质性效果。
• 决策: 政策引擎分层提额，并设置风险 guardrail。

Case C: 欺诈拦截策略

• Treatment: 实时拦截或强认证。
• Outcome: 欺诈损失、误拦、客户流失。
• Confounders: 模型分数、商户风险、金额、设备、历史行为。
• 输出: 拦截策略的净收益和客户摩擦成本。
• 决策: 对高净收益分层启用强认证，而不是一刀切。

---

9. AI 产品和指标因果性

AI 产品常用 adoption、usage、CSAT、AHT、accuracy 证明价值，但这些指标很多只是相关性。

更强证据:

面试中要体现: AI ROI attribution 必须有 causal design，否则容易把成熟团队、热门产品或季节因素当成 AI 效果。

---

10. Architecture Checklist

---

11. 面试表达

30 秒版本

因果 AI 的价值是防止团队把相关性当成产品效果。我会先定义 treatment、outcome、population 和 horizon，再画 DAG 暴露假设，用 DoWhy 做识别、估计和反驳，用 EconML 估计异质性效果，最后把结果接入政策模拟、实验或灰度发布。

2 分钟版本

比如营销优惠券，如果只看使用优惠券的客户复购率，可能把本来就活跃的客户误认为被优惠券影响。我的做法是建立 causal question canvas: 谁接受 treatment，观察什么 outcome，时间窗口多长，哪些混杂需要控制。然后组织 DAG review，判断调整集和可识别性。估计阶段可以用 DoWhy 管理建模、识别、估计、反驳流程，用 EconML 估计不同人群的 uplift。上线前还要做敏感性分析和人群影响评估。最终决策不是“模型说发券”，而是“在这些假设和风险边界下，对某些人群发券有正增量效果”。

CTO 追问

如果 CTO 问因果发现能不能自动替代实验，我会回答: 不能。NOTEARS 等因果发现方法可以帮助提出候选结构和挑战专家假设，但它依赖强假设，无法自动解决隐藏混杂。高风险决策仍需要实验、准实验、敏感性分析和治理审查。

---

12. Portfolio Task

做一个 “AI Decision Intelligence Causal Pack”:

最终要能讲清楚: 因果能力不是算法炫技，而是 AI 产品投资、增长、信贷和风控决策的证据纪律。