AI Causal Discovery / Structural Decision Playbook
- [DoWhy](https://www.pywhy.org/dowhy/):用于把因果问题拆成建模、识别、估计、反驳检验的工程流程,适合把业务 DAG 转成可审计的因果估计管线。
AI 因果发现与结构化决策高级 Playbook
Source Anchors
- DoWhy:用于把因果问题拆成建模、识别、估计、反驳检验的工程流程,适合把业务 DAG 转成可审计的因果估计管线。
- EconML:用于 heterogeneous treatment effect、CATE、uplift、policy learning 等异质性效应估计,适合营销、授信、欺诈干预和运营策略分层。
- DAGitty:用于绘制 DAGs、验证 adjustment sets、检查 backdoor/frontdoor/IV 等识别路径,适合评审 causal assumptions 与 identifiability。
- NOTEARS:代表连续优化式 causal discovery,把有向无环约束转成可优化问题,适合作为候选结构学习工具,而不是自动真因果发现器。
- NIST AI RMF:用于 AI 风险治理的 Govern、Map、Measure、Manage 框架,适合把因果决策系统纳入模型风险、合规、审计与运营监控。
一句话定位
本 Playbook 面向已经具备成熟 BA、产品与架构经验的金融零售从业者,目标是把 causal discovery、SCM、DAGs、DoWhy/EconML、NOTEARS、DAGitty 等方法,转化为可审计、可上线、可治理的 product decisioning 能力:用结构化因果模型回答“哪个干预真的改变了业务结果、在哪些人群上改变、代价是什么、上线后如何持续控制风险”。
为什么重要
金融零售的 AI 决策很少缺少相关性,真正缺少的是“可行动的因果解释”。模型能告诉你高风险客户更可能逾期,但产品与风控决策需要回答的是:降低额度、提高验证强度、改变还款提醒、调整利率、增加人工复核,分别会让逾期率、收入、投诉、歧视风险和运营成本发生什么变化。
没有因果结构,AI 产品容易在四类场景中失真:
- 把选择偏差当作产品效果:高活跃用户更容易使用新功能,也更容易留存,功能本身未必提升留存。
- 把风控结果当作风险真相:被拒绝的申请人没有后续还款表现,训练数据只覆盖已批准人群,credit policy 的 counterfactual 缺失。
- 把拦截后的低损失当作欺诈模型胜利:fraud interventions 改变了攻击者行为,也改变了可观测样本,离线 AUC 无法代表干预收益。
- 把运营相关性当作流程改进证据:复杂 case 被更多人工处理,处理时长与差评相关,不代表人工处理造成差评。
高级 AI 产品与架构的重点不是“是否用了因果库”,而是把因果问题嵌入决策生命周期:问题定义、DAG/SCM 建模、识别治理、估计、干预设计、上线监控、风险复盘。
Causal-to-Decision 架构
1. 决策语义层
先定义业务决策,而不是先定义模型:
- 动作:推送优惠、额度调整、KYC 升级、人工复核、还款提醒、客服路由、库存补货、门店排班。
- 目标结果:转化、留存、GMV、净收入、逾期率、欺诈损失、误拦截、NPS、投诉率、SLA。
- 决策粒度:客户、账户、交易、门店、地区、产品组合、运营队列。
- 时间窗:实时、T+1、7 天、30 天、账单周期、季度。
- 约束:合规、公平性、隐私、资本占用、操作成本、客户体验、品牌风险。
2. 因果问题层
把业务问题翻译为 causal question:
- Treatment:可操作干预,例如“给予 5 美元优惠券”“将授信额度从 3000 提升到 5000”“触发 step-up authentication”。
- Outcome:决策要改善的指标,例如 incremental revenue、30 天逾期率、fraud loss、人工处理时长。
- Unit:被干预对象,例如客户、申请、交易、客服工单。
- Population:适用人群,例如新客、高风险申请人、跨境交易、低库存门店。
- Estimand:ATE、ATT、CATE、uplift、policy value、risk difference、odds ratio、cost-adjusted net benefit。
3. DAG/SCM 结构层
DAGs 用图表达因果方向,SCM 用结构方程表达变量生成机制。两者共同服务于一个目标:明确哪些变量是原因、结果、混杂、媒介、碰撞点、选择机制或不可观测因素。
典型结构:
Customer Need -> Feature Usage -> Retention
Customer Need -> Retention
Marketing Eligibility -> Offer -> Purchase
Risk Profile -> Credit Approval -> Delinquency
Risk Profile -> Delinquency
Fraud Intent -> Transaction Pattern -> Fraud Score -> Intervention -> Loss
SCM 可用更工程化的方式描述:
Offer = f1(Eligibility, ChannelCapacity, ExperimentAssignment, U_offer)
Purchase = f2(Offer, Intent, PriceSensitivity, Seasonality, U_purchase)
Profit = f3(Purchase, DiscountCost, FulfillmentCost, U_profit)
这类表达不是数学装饰,而是为了让团队判断 identifiability:在现有数据、实验设计和业务约束下,目标效应是否可以被识别。
4. Causal Discovery 层
causal discovery 用数据与约束生成候选 DAG,而不是代替业务判断。可组合使用:
- 约束法:基于条件独立测试,适合探索变量关系,但对样本量、测量误差和未观测混杂敏感。
- 评分法:搜索能解释数据且复杂度受控的图结构。
- 连续优化法:NOTEARS 把 DAG acyclicity 作为连续约束,适合高维结构学习实验。
- 时序与干预约束:时间顺序、系统日志、上线批次、政策变更、随机分配、外部冲击,比纯相关结构更有治理价值。
输出必须标注可信度:强业务先验、弱数据提示、存在方向歧义、疑似隐藏混杂、需要实验确认。
5. 识别与估计层
识别回答“能不能估”,估计回答“估多少”。DoWhy 适合把 model -> identify -> estimate -> refute 串成可重复流程;DAGitty 适合审查 adjustment sets;EconML 适合估计 CATE、uplift 和策略异质性。
常见路径:
- Backdoor adjustment:控制共同原因,避免 confounding。
- Frontdoor adjustment:通过中介路径识别直接控制困难的效应。
- Instrumental variables:使用影响 treatment 但只通过 treatment 影响 outcome 的工具变量。
- Difference-in-differences:使用政策或运营变更前后的组间差异。
- Regression discontinuity:使用阈值附近的准随机分配。
- Randomized experiment:最强识别来源,但也需要检查干扰、流量污染和执行偏差。
6. 决策与治理层
因果估计必须落成决策规则:
- 谁会获得干预。
- 干预强度如何分层。
- 何时停止或升级。
- 如何计算净收益与风险成本。
- 如何在上线后监控漂移、反馈回路、公平性、投诉和反事实缺口。
架构上建议形成独立的 Causal Decision Service:输入人群、候选干预、DAG 版本、识别策略、估计结果、治理状态;输出可执行策略、解释摘要、监控指标和审计记录。
因果发现与因果推断边界
causal discovery 解决什么
causal discovery 的核心用途是形成结构候选:
- 从复杂变量中发现可能的直接因果边。
- 暴露团队忽略的共同原因或选择机制。
- 为 DAG review 提供数据驱动线索。
- 在多渠道营销、信贷审批、欺诈拦截和运营流程中识别潜在路径。
它不能单独证明因果。尤其在金融零售中,未观测客户动机、风险偏好、渠道选择、欺诈意图和人工策略会造成强 confounding。
causal inference 解决什么
causal inference 在给定 DAG/SCM、assumptions 与识别策略后,估计干预对结果的影响:
- ATE:整体平均效果。
- ATT:对已接受干预人群的平均效果。
- CATE:特定客户或分层人群的异质性效果。
- Uplift:干预相对不干预的增量收益。
- Policy value:策略上线后的总收益与总风险。
边界原则
- causal discovery 产出“候选结构”,causal inference 产出“有条件成立的效应估计”。
- DAG 中的箭头来自业务机制、时间顺序、实验、系统日志和统计证据的组合。
- identifiability 先于模型精度。不可识别的问题,用更复杂模型只会让错误更精致。
- 所有 causal assumptions 都要进入 assumption register,由产品、风控、数据科学、架构、法务合规共同签署。
DAG/SCM 工作流
Step 1:从决策反推 causal question
不要问“哪些变量预测留存”,要问“如果我们改变 X,Y 会怎么变”。例如:
- 如果给高潜新客发免运费券,30 天净收入是否增加。
- 如果把中低风险客户额度上调 20%,坏账损失与交易收入的净效应如何。
- 如果对高疑似交易触发 step-up authentication,欺诈损失、误杀率和客户流失如何变化。
- 如果把客服工单路由给专属队列,投诉率与处理成本是否下降。
Step 2:列变量并分类
把变量拆成:
- Pre-treatment confounders:干预前共同影响 treatment 与 outcome 的变量。
- Treatment:产品、政策、运营或模型触发的干预。
- Mediators:干预之后位于路径中间的变量。
- Colliders:由两个原因共同造成,控制它会引入偏差。
- Selection variables:样本进入数据集的机制,例如审批通过、登录后曝光、人工复核后标注。
- Outcomes:主要指标、护栏指标、长期指标。
- Unobserved factors:客户意图、真实欺诈意图、外部经济压力、门店经理能力。
Step 3:画 DAG 并声明方向依据
每条边必须有依据:
- 时间先后。
- 产品机制。
- 风控政策。
- 营销投放规则。
- 系统路由逻辑。
- 合规或运营制度。
- 历史实验或自然实验。
- causal discovery 提示。
使用 DAGitty 检查 adjustment sets,用 NOTEARS 或其他 causal discovery 方法做结构探索时,必须把输出标为“候选边”,再通过业务与数据审查确认。
Step 4:定义 SCM
对关键变量写结构方程或自然语言版本:
FeatureUsage = f(Exposure, UserNeed, OnboardingQuality, DeviceCapability, U_usage)
Retention = f(FeatureUsage, UserNeed, ServiceQuality, CompetitorOffer, U_retention)
这样团队会看到:如果 UserNeed 无法观测,FeatureUsage 与 Retention 的相关性无法直接解释为功能因果效果。
Step 5:识别 estimand
明确目标:
- ATE:是否整体上线。
- CATE:哪些人群上线。
- Uplift:是否值得给优惠、提醒、人工干预。
- Risk-adjusted effect:收益减损失、资本、投诉和运营成本。
- Path-specific effect:某条机制路径是否成立,例如优惠通过提高下单频次而不是拉低毛利。
Step 6:估计、反驳与敏感性分析
建议管线:
- 用 DAGitty 或 DoWhy 确认识别表达。
- 用 DoWhy 生成估计策略并执行 refutation tests。
- 用 EconML 估计异质性效果,输出 CATE/uplift 分层。
- 对关键 confounding 做 sensitivity analysis。
- 对样本选择、干预执行偏差、数据泄漏和漂移做压力测试。
Step 7:转成上线策略
因果估计要进入产品与架构:
- 决策 API:输入客户/交易/工单状态,返回干预建议与理由。
- 策略引擎:把 CATE、风险阈值、成本、合规规则组合成 policy。
- 实验平台:支持 holdout、staged rollout、switchback、geo split。
- 监控平台:监控 uplift 衰减、投诉上升、异常人群、欺诈迁移。
- 审计日志:记录 DAG 版本、估计版本、策略版本、审批链路。
假设与识别治理
causal assumptions 清单
金融零售因果项目至少审查以下假设:
- No unmeasured confounding:已控制关键共同原因。
- Positivity / overlap:每类人群都有接受与不接受干预的可能性。
- Consistency:定义的干预足够明确,同一 treatment 不混入多种版本。
- SUTVA / no interference:一个单位的干预不会改变另一个单位的结果;营销、欺诈和运营队列经常违反该假设。
- Correct temporal ordering:控制变量发生在干预前,避免 post-treatment bias。
- Measurement validity:变量真实代表业务概念,例如“欺诈标签”不是单纯代表“被拦截后确认”。
- Stable policy environment:估计窗口内政策、渠道、宏观环境没有不可忽视的结构变化。
- Missingness mechanism:缺失不是由 outcome 或 treatment 共同造成,或已有建模处理。
- Identifiability:在 DAG 与数据条件下,目标 estimand 有明确识别表达。
confounding 治理
confounding 不是“多加控制变量”就能解决。错误控制会引入更大偏差:
- 控制 mediator 会低估总效应。
- 控制 collider 会打开虚假路径。
- 控制 treatment 后变量会造成 post-treatment bias。
- 忽略选择机制会让审批、曝光、标注数据中的估计失真。
治理做法:
- 所有控制变量必须标注发生时间与 DAG 角色。
- 建模特征表分成 pre-treatment、treatment、post-treatment、outcome-adjacent 四类。
- 对每个 adjustment set 给出 DAGitty/DoWhy 识别依据。
- 对高争议变量做有无控制的 sensitivity analysis。
identifiability 决策
当问题不可识别时,产品团队有三种选择:
- 修改问题:从“功能使用是否提升留存”改成“随机曝光入口是否提升留存”。
- 修改数据生成机制:引入实验、随机鼓励、阈值策略、分阶段上线。
- 修改决策目标:从精确效应估计改成有边界的保守策略,例如只在净收益下界为正的人群上线。
干预设计
实验优先级
- Individual RCT:适合营销优惠、消息提醒、功能入口曝光。
- Cluster RCT:适合门店、地区、客服团队、商户群组,降低干扰。
- Switchback experiment:适合高频运营系统,例如客服排班、风控策略、配送路径。
- Geo experiment:适合区域营销、门店运营、零售库存策略。
- Encouragement design:当不能强制 treatment 时,用随机鼓励作为 instrument。
- Quasi-experiment:利用阈值、政策变更、系统迁移、监管变化等外部或半外部冲击。
干预强度设计
干预不是二元开关,金融零售更常见的是强度曲线:
- 优惠券金额、频率、渠道。
- 信用额度、利率、账期、抵押要求。
- 验证强度、人工复核层级、冻结时长。
- 客服优先级、SLA、话术、升级规则。
- 库存安全水位、补货频率、门店排班密度。
用 EconML 等方法估计 CATE 后,不应直接把最高 uplift 人群全量覆盖。需要加入预算、风险、合规、客户疲劳、长期价值与公平性约束。
干预评估指标
每个干预至少包含:
- 主效果指标:例如 incremental profit、delinquency reduction、fraud loss avoided。
- 成本指标:优惠成本、资金成本、人工成本、系统成本。
- 护栏指标:投诉、流失、误拦截、审批公平性、SLA、监管触发。
- 长期指标:复购、信用表现、客户关系、攻击迁移、运营负荷。
- 分层指标:新老客、风险等级、收入段、渠道、地区、设备、商户类型。
产品决策落地
feature/metric causality
问题形态:新功能使用率上升后,留存也上升,是否说明功能提升留存。
高级处理:
- 把 Feature Exposure、Feature Usage、User Need、Onboarding Quality、Retention 分开。
- 识别 Feature Usage 是否是用户自选择造成。
- 对入口曝光做随机化,比对 usage-driven effect 与 exposure-driven effect。
- 对 activation metric 做中介分析,避免把“结果的早期信号”误当作“结果的原因”。
- 决策输出不只是“是否上线”,还包括入口位置、人群分层、教育触达和反向护栏。
marketing uplift
问题形态:优惠券、短信、push、广告投放是否带来增量收入。
高级处理:
- 区分 sure things、persuadables、lost causes、do-not-disturbs。
- 用 uplift/CATE 避免补贴本来就会购买的客户。
- 将渠道触达频率、客户疲劳、退订风险、毛利和履约成本纳入 policy value。
- 对跨渠道干扰做 cluster 或 geo 实验。
- 上线策略按“增量毛利 - 优惠成本 - 触达成本 - 投诉成本”排序,而非按购买概率排序。
credit policy
问题形态:额度、利率、审批阈值、还款提醒是否改善风险收益。
高级处理:
- 审批通过样本存在选择偏差,需要处理 reject inference 与 policy-induced missingness。
- credit policy 的 treatment 常是连续变量,例如额度与利率,需考虑剂量反应。
- outcome 不只是逾期率,还包括收入、资本占用、客户流失、投诉、公平性。
- 对阈值附近可用 regression discontinuity;对政策迁移可用 DiD;对随机额度试探可估计 CATE。
- 策略上线要有 champion/challenger、风险限额、分层监控和人工 override 审计。
fraud interventions
问题形态:拦截、step-up authentication、设备指纹、人工复核是否降低真实欺诈损失。
高级处理:
- fraud score 是风险信号,不是干预效果;intervention 会改变可观测欺诈标签。
- 攻击者会适应,干预有 spillover 与 displacement。
- 误杀成本必须显式进入目标函数,尤其是高价值客户、跨境旅客、紧急支付场景。
- 用 holdout 或随机 step-up 比例估计真实 fraud interventions 效果。
- 监控指标包括欺诈损失、误拦截、通过率、客户流失、人工队列压力、攻击模式迁移。
operational changes
问题形态:流程自动化、工单路由、门店排班、库存补货、客服脚本是否改善效率与体验。
高级处理:
- 运营变更常有团队级干扰,individual-level A/B 可能污染。
- 使用 switchback、cluster、geo 或队列级随机化。
- 控制 case complexity、季节性、人员经验、渠道混入,避免把复杂 case 的结果归因给人工处理。
- 结果指标要包括 SLA、一次解决率、返工率、投诉、人员负荷和单位成本。
- 决策规则需要可回滚,因为运营系统的反馈回路通常比营销更快。
风险治理
与 NIST AI RMF 对齐
- Govern:建立因果决策责任制,明确 DAG owner、estimand owner、policy owner、risk owner。
- Map:定义业务场景、受影响人群、法律与声誉风险、数据流、干预边界。
- Measure:衡量效应估计质量、假设脆弱性、偏差、公平性、鲁棒性、漂移。
- Manage:上线审批、限额、监控、回滚、例外处理、审计与复盘。
架构控制点
- DAG registry:保存 DAG 版本、变量定义、边依据、识别策略。
- Assumption register:保存 causal assumptions、证据强度、责任人和复核周期。
- Estimation pipeline:保存数据版本、代码版本、估计器、参数、refutation tests。
- Decision policy store:保存策略规则、阈值、成本函数、合规约束。
- Monitoring layer:监控 uplift 衰减、数据漂移、政策漂移、群体差异、投诉与人工 override。
- Audit trail:让每次干预能回溯到模型、DAG、策略、审批与业务理由。
关键风险
- 不可识别却上线:没有明确 identifiability,策略根据相关性执行。
- 隐藏混杂:客户意图、风险偏好、渠道选择、欺诈能力未观测。
- 错误控制变量:控制 mediator、collider 或 post-treatment 变量。
- 反馈回路:策略改变数据生成机制,下一轮模型把策略偏差学进去。
- 公平性风险:分层 uplift 可能提升利润,也可能扩大受保护群体差异。
- 解释错配:把预测解释当成因果解释,例如 SHAP 高贡献不等于可干预原因。
- 运营不可执行:估计收益高,但人工队列、客服 SLA、合规审批无法承接。
模板
1. causal question canvas
| 字段 | 高级填写方式 | 示例 |
|---|---|---|
| 决策动作 | 写成可执行干预,不写抽象目标 | 对中风险客户提高额度 15% |
| Outcome | 明确主指标、护栏指标、时间窗 | 90 天净收入;护栏为 30 天逾期、投诉、流失 |
| Unit | 明确分析与执行单位是否一致 | 客户账户为执行单位,授信申请为观测单位 |
| Population | 明确覆盖人群与排除规则 | 活跃 6 个月以上、无严重逾期、收入稳定客户 |
| Estimand | 选择 ATE、ATT、CATE、uplift 或 policy value | CATE 与风险调整后 policy value |
| Decision threshold | 写出上线阈值 | 净收益下界为正,且逾期提升小于风险限额 |
| Business owner | 明确产品、风险、运营、合规职责 | 信贷产品 owner 与模型风险 owner 联合审批 |
2. DAG review
| 审查项 | 评审问题 | 通过标准 |
|---|---|---|
| 时间顺序 | 控制变量是否全部发生在 treatment 前 | 特征表按事件时间切分 |
| 混杂路径 | 是否存在共同原因影响 treatment 与 outcome | 每条 backdoor path 有处理策略 |
| 中介变量 | 是否把 treatment 后变量误作控制变量 | mediator 被单独标注并用于机制分析 |
| 碰撞点 | 是否控制由 treatment 与 outcome 共同影响的变量 | collider 不进入 adjustment set |
| 选择机制 | 数据是否只覆盖通过审批、曝光或标注的人群 | selection node 在 DAG 中显式表示 |
| 未观测因素 | 是否存在客户意图、真实风险、攻击者能力 | 高风险未观测因素进入敏感性分析 |
| 工具支持 | 是否用 DAGitty 或 DoWhy 验证识别路径 | adjustment set 与 estimand 可复现 |
3. assumption register
| 假设 | 业务含义 | 证据来源 | 脆弱性 | 缓解方式 |
|---|---|---|---|---|
| No unmeasured confounding | 已捕捉主要共同原因 | 政策规则、日志、专家评审 | 客户动机不可观测 | 随机鼓励或敏感性分析 |
| Positivity | 各人群都有干预与未干预样本 | 历史策略覆盖率 | 高风险人群从未获批 | 缩小 population 或设计探索流量 |
| Consistency | 干预定义一致 | 产品配置与实验日志 | 不同渠道优惠体验不同 | 按渠道拆分 treatment |
| No interference | 单位之间互不影响 | 业务流程与实验设计 | 社交传播、队列挤占 | cluster 或 geo 设计 |
| Measurement validity | 标签代表真实业务结果 | 账务、风控、客服闭环 | 拦截后欺诈标签缺失 | holdout 与人工抽检 |
4. identification checklist
| 检查项 | 判断 |
|---|---|
| Estimand 已定义 | 明确 ATE、ATT、CATE、uplift 或 policy value |
| DAG 已版本化 | DAG 包含 treatment、outcome、confounders、mediators、colliders、selection |
| Adjustment set 已验证 | 使用 DAGitty/DoWhy 输出并经业务评审 |
| Positivity 已检查 | 关键分层中 treatment probability 不接近 0 或 1 |
| 数据时间线已验证 | 所有控制变量发生在 treatment 前 |
| 准实验条件已说明 | DiD、IV、RDD 等识别条件被写入 assumption register |
| 不可识别风险已处理 | 通过实验、随机鼓励、缩小范围或保守边界处理 |
5. intervention design
| 字段 | 高级填写方式 | 示例 |
|---|---|---|
| Treatment arms | 明确多个强度层级 | 无提醒、普通提醒、强提醒、人工电话 |
| Assignment | 随机、阈值、运营规则或策略模型 | 分层随机,风险等级内等比例分配 |
| Guardrails | 合规、体验、成本、队列压力 | 投诉率不高于基线 5%,人工队列不超过容量 |
| Spillover control | 说明干扰隔离方式 | 门店级 cluster,客服队列独立 |
| Rollout | 说明上线节奏 | 5% 探索、20% 分层扩展、50% 策略验证 |
| Stop rule | 写出停止或降级条件 | 任一护栏连续两天越界即自动回滚 |
| Audit evidence | 记录可审计资产 | 实验配置、DAG 版本、估计报告、审批记录 |
6. sensitivity analysis
| 维度 | 分析方式 | 决策含义 |
|---|---|---|
| 未观测混杂 | 调整假设强度,观察效应符号是否改变 | 符号易变则不全量上线 |
| 模型规格 | 更换估计器、变量集合、函数形式 | 结果稳定才进入策略层 |
| 样本选择 | 对不同 eligibility、渠道、时间窗复估 | 判断是否只在局部人群成立 |
| 干预执行 | 检查实际触达、通过率、人工执行偏差 | 执行偏差大时重估 ITT 与 TOT |
| 长期效果 | 观察短期与长期指标差异 | 防止短期收益透支长期价值 |
| 群体差异 | 按风险、收入、地区、年龄段、渠道审查 | 触发公平性和合规评审 |
7. governance review
| 评审维度 | 关键问题 | 交付证据 |
|---|---|---|
| 业务适当性 | 干预是否符合产品定位与客户承诺 | 决策 memo 与客户影响分析 |
| 因果有效性 | DAG、SCM、identifiability 是否成立 | DAG review、assumption register、识别报告 |
| 模型风险 | 估计器、数据、反驳检验是否可复现 | DoWhy/EconML pipeline 与版本记录 |
| 合规公平 | 是否产生不合理差异影响 | 分群效果、拒绝理由、人工申诉机制 |
| 运营承接 | 人工队列、客服、系统容量是否可支撑 | 容量模型与回滚预案 |
| 监控闭环 | 上线后如何捕捉失效与漂移 | 指标面板、阈值、责任链 |
8. 30-day/interview 模板
| 用途 | 结构 | 示例表达 |
|---|---|---|
| 30 天训练复盘 | 问题、DAG、识别、估计、干预、治理、决策 | “本周用 DAGitty 验证营销 uplift 的 adjustment set,并用 EconML 输出 CATE 分层。” |
| 面试 30 秒回答 | 观点、边界、业务例子 | “causal discovery 给候选结构,causal inference 在假设与识别成立时估计干预效果。” |
| 面试 2 分钟回答 | 场景、DAG/SCM、识别、估计、上线治理 | “在授信政策中,我会先处理审批选择偏差,再用阈值或探索流量估计额度调整的风险收益。” |
| 案例追问 | 反例、风险、落地控制 | “如果 positivity 不成立,我不会用复杂模型硬估,而是缩小人群或设计探索策略。” |
30 天训练计划
第 1 周:结构化因果基础与工具链
| 天 | 训练主题 | 产出 |
|---|---|---|
| Day 1 | 把一个产品增长问题改写成 causal question | causal question canvas |
| Day 2 | 用 DAGitty 绘制 feature/metric causality DAG | DAG review 表 |
| Day 3 | 写出 SCM:客户需求、功能曝光、功能使用、留存 | SCM 描述与变量分类 |
| Day 4 | 用 DoWhy 表达 backdoor adjustment | 识别报告 |
| Day 5 | 梳理 causal assumptions 与 confounding 风险 | assumption register |
| Day 6 | 对 NOTEARS 输出候选结构做业务评审 | 候选边分级清单 |
| Day 7 | 复盘 causal discovery vs causal inference 边界 | 2 分钟面试答案 |
第 2 周:营销与产品决策
| 天 | 训练主题 | 产出 |
|---|---|---|
| Day 8 | 设计优惠券 marketing uplift 实验 | intervention design |
| Day 9 | 用 EconML 思路拆 CATE 与 uplift 分层 | 分层策略表 |
| Day 10 | 处理渠道触达与客户疲劳 confounding | DAG 修订 |
| Day 11 | 设计 holdout 与 staged rollout | 上线节奏与 stop rule |
| Day 12 | 做 sensitivity analysis:未观测购买意愿 | 敏感性报告 |
| Day 13 | 把 uplift 转成 product decisioning policy | 策略规则 |
| Day 14 | 形成营销因果案例讲稿 | 面试案例答案 |
第 3 周:credit policy 与 fraud interventions
| 天 | 训练主题 | 产出 |
|---|---|---|
| Day 15 | 构建授信审批 DAG:申请、审批、额度、逾期 | DAG 与 selection node |
| Day 16 | 分析 reject inference 与 identifiability | 识别风险 memo |
| Day 17 | 设计额度探索或阈值准实验 | credit policy 干预方案 |
| Day 18 | 把风险收益、公平性、资本成本纳入 policy value | 决策函数 |
| Day 19 | 构建欺诈拦截 DAG:score、step-up、loss、误杀 | fraud interventions DAG |
| Day 20 | 设计欺诈 holdout 与攻击迁移监控 | 治理与监控方案 |
| Day 21 | 汇总信贷与欺诈面试答案 | STAR-T 案例 |
第 4 周:运营变更、架构与治理
| 天 | 训练主题 | 产出 |
|---|---|---|
| Day 22 | 选择一个 operational changes 场景:客服路由或门店排班 | 业务问题定义 |
| Day 23 | 设计 switchback 或 cluster experiment | 实验设计 |
| Day 24 | 梳理 SLA、投诉、人员负荷与成本护栏 | 指标树 |
| Day 25 | 设计 Causal Decision Service 架构 | 架构图说明 |
| Day 26 | 对齐 NIST AI RMF 的 Govern/Map/Measure/Manage | governance review |
| Day 27 | 建立 DAG registry 与 assumption register 的信息架构 | 元数据设计 |
| Day 28 | 做端到端 case:从问题到上线策略 | 完整 playbook 案例 |
| Day 29 | 模拟高压面试:识别、干预、风险、架构追问 | 面试问答集 |
| Day 30 | 形成作品集展示稿 | 一页 executive memo |
面试答案
1. causal discovery 和 causal inference 的区别是什么
30 秒答案:causal discovery 主要生成候选 DAG 或结构假设,告诉我们变量之间可能的因果方向;causal inference 在给定 DAG/SCM、causal assumptions 和 identifiability 成立后,估计某个 interventions 对 outcome 的影响。前者偏结构探索,后者偏效应估计,两者都不能脱离业务机制和实验设计。
2 分钟答案:在金融零售里,我不会把 causal discovery 的输出直接变成策略。比如 NOTEARS 可以从营销、客户、渠道变量中学习候选 DAG,但客户购买意愿、渠道选择和预算规则可能都是隐藏混杂。我的做法是把候选结构带入 DAG review,用 DAGitty 或 DoWhy 检查 adjustment set 和 identifiability,再用实验、随机鼓励或准实验估计 ATE/CATE/uplift。最后进入 product decisioning 时,还要加入成本、合规、公平性和运营容量约束。
2. 如何判断一个 feature metric 是否真的导致业务增长
30 秒答案:先区分 feature exposure、feature usage 和业务 outcome。使用率与留存相关不代表功能导致留存,因为用户需求可能同时驱动使用和留存。最好对曝光或入口做随机化,再用 DAG/SCM 识别混杂与中介路径。
2 分钟答案:我会画 DAG:User Need 影响 Feature Usage 和 Retention,Onboarding Quality 影响 Exposure 与 Usage,Feature Usage 可能影响 Retention。若直接回归 Retention on Usage,会有 confounding。更好的策略是随机化入口曝光,估计 exposure 对 retention 的 ITT,再分析 usage 作为 mediator 的机制路径。如果无法实验,就需要用 DoWhy/DAGitty 明确 adjustment set,并做敏感性分析。产品决策上,我会避免只优化使用率,而是看增量留存、长期价值、投诉和学习成本。
3. marketing uplift 为什么不能用购买概率模型替代
30 秒答案:购买概率模型预测谁会买,uplift 模型估计谁会因为干预才买。营销预算应投给 persuadables,而不是 sure things。
2 分钟答案:在零售营销中,高购买概率客户可能不需要优惠,给他们补贴会降低毛利。uplift/CATE 的目标是估计 Offer 与 No Offer 的差异效果。技术上可以用实验数据、EconML 的异质性效应估计或 doubly robust 方法;产品上要把优惠成本、触达成本、退订风险和履约成本纳入 policy value。上线后需要 holdout 监控,因为客户疲劳和渠道竞争会让 uplift 衰减。
4. credit policy 中最大的因果难点是什么
30 秒答案:最大难点是选择偏差和反事实缺失。被拒绝客户没有还款表现,已批准客户的表现又受到额度、利率和催收策略影响。
2 分钟答案:授信场景里,审批结果本身是 selection node。如果只用已批准样本估计额度提升对逾期的影响,会低估或高估真实风险。我的做法是先画 DAG,把申请质量、风险画像、审批政策、额度、使用率、逾期和收入放进去。识别上可以利用阈值附近的 regression discontinuity、政策变更的 DiD,或小比例随机探索额度。估计后不能只看逾期率,还要看净收入、资本占用、公平性、投诉和长期客户价值。
5. fraud interventions 如何评估真实效果
30 秒答案:不能只看拦截后欺诈损失下降,因为干预改变了标签和攻击者行为。需要 holdout、随机 step-up 或分层实验估计干预的增量效果。
2 分钟答案:欺诈场景的 treatment 可以是 step-up authentication、人工复核、冻结或拒绝交易。Fraud Score 是风险信号,Intervention 才是因果动作。干预后,真实欺诈可能不再发生,标签会缺失;同时攻击者会迁移。评估时我会设计小比例安全 holdout 或随机验证强度,估计 fraud loss avoided、false positive cost、客户流失、人工队列压力和攻击迁移。上线策略必须有实时监控和回滚,因为欺诈对抗会让历史估计快速失效。
6. 如果 identifiability 不成立,产品团队怎么办
30 秒答案:不要用复杂模型硬估。可以缩小问题、改变数据生成机制,或把策略改成保守边界决策。
2 分钟答案:我会先说明不可识别原因,例如隐藏混杂、positivity 失败、选择机制过强或缺少干预变异。然后给三类方案:第一,重定义 estimand,把整体效果改成人群内效果;第二,引入实验、随机鼓励、阈值策略或分阶段上线;第三,如果业务必须行动,就使用保守边界,只在净收益下界为正且护栏安全的人群上线。所有假设进入 assumption register,形成治理证据。
7. 因果能力如何进入企业 AI 架构
30 秒答案:把因果能力做成 Causal Decision Service,而不是散落在 notebook 里。核心资产包括 DAG registry、assumption register、estimation pipeline、policy store、monitoring 和 audit trail。
2 分钟答案:架构上我会把 causal discovery、DAG/SCM、识别、估计和策略上线分层。DAG registry 管结构版本和边依据;assumption register 管 causal assumptions;DoWhy/EconML pipeline 管估计和反驳检验;policy store 把 CATE、成本、风险和合规约束转成决策;monitoring 追踪 uplift 衰减、漂移、公平性和投诉;audit trail 支持模型风险与监管审查。这种架构能把 AI 从预测系统升级为可治理的干预决策系统。