AI Contextual Bandits & Adaptive Experimentation Playbook

适用对象: AI Product Architect、AI Platform PM、Decision Science Lead、Risk Product Manager、Experimentation PM、金融零售增长 / 风控 / 催收 / 客服 / 定价 / 个性化负责人。 核心问题: 如何把 contextual bandits、adaptive experimentation、offline policy evaluation、next-best-action 和金融零售风险治理连接成一套可上线、可审计、可回滚的决策系统。 高级定位: 本文不讲 BA 入门需求收集，也不把 bandit 简化为“更聪明的 A/B test”。重点是训练 AI + 产品 + 架构判断: 何时探索、如何记录 propensity、怎样做反事实评估、哪些场景可自适应、哪些场景必须强治理。 作品集定位: 本 playbook 可直接转化为 Contextual Bandit Decision Service 架构图、Experiment Policy Card、Decision Log Contract、OPE Review Memo、Risk Gate、Kill Switch Runbook、金融零售案例包和高级面试答案。

重要说明: 本文是学习、作品集和架构训练材料，不构成法律意见、合规意见、投资建议、信贷决策建议、模型验证报告或审计结论。涉及信贷、财富、保险、定价、催收、欺诈拦截、差异化营销、消费者权益、公平信贷和隐私时，正式项目必须由 Business Owner、Legal、Compliance、Model Risk、Fair Lending、Privacy、Security、Data Owner、Operations、Architecture Review 和 Audit 共同审查。

---

Source Anchors

这些来源用于校准 contextual bandits、LinUCB、exploration / exploitation、offline policy evaluation、inverse propensity scoring、doubly robust、MWT、uplift / causal comparison 和 AI 风险治理语言。正式项目必须按机构政策、数据权限、监管要求和上线日期复核。

---

1. 一句话定位

Contextual bandits 是一类在线决策学习方法: 系统在每次决策时观察 context，选择一个 action，只看到被选 action 的 reward，然后在 exploration 与 exploitation 之间持续权衡，以优化长期决策表现。

在金融零售中，它不是“按钮颜色测试工具”，而是 next-best-action、offer optimization、contact center routing、fraud friction、collections treatment、dynamic pricing 和 personalization 的自适应决策控制层。

Customer / case / channel context
  -> eligibility, consent, policy and risk constraints
  -> action set generation
  -> exploration policy
  -> selected action + propensity
  -> customer / staff / system exposure
  -> delayed reward and guardrail outcome
  -> offline policy evaluation
  -> policy update, governance review, rollout or rollback

高级产品架构要回答的不是“哪个算法更酷”，而是:

• 这个业务场景是否允许探索，允许多大 exploration budget。
• action 是否会影响价格、额度、拦截、催收、财富建议或客户权益。
• reward 是否代表真实增量价值，而不是短期点击、接通或回款的代理指标。
• 日志是否记录了 action probability / propensity，使 offline policy evaluation 可行。
• fairness / consumer harm 是否进入上线门槛、监控和 kill switch。
• 自适应系统是否能解释“为什么在这个 context 下给了这个 action”。

---

2. 为什么重要

传统 A/B test 假设实验组策略在实验期间相对固定，适合验证少量明确改动。金融零售的 AI 决策场景经常更复杂:

• 客户 context 每次都不同: 余额、收入波动、风险评分、渠道、语言、生命周期、设备、历史互动、负债压力不同。
• action set 动态变化: 可用 offer、费率、客服队列、催收话术、欺诈验证方式、next-best-action 会随库存、政策和风险状态变化。
• 反馈稀疏且延迟: 点击马上出现，开户、还款、欺诈 chargeback、投诉、流失、逾期、客户伤害可能数天或数月后出现。
• 错误探索有真实成本: 不合适的价格、错误拦截、过度催收、误导性 offer、偏差化路由都可能造成合规、声誉和客户信任损害。
• 手工实验速度太慢: 每个 segment、channel、message、offer、risk intervention 都单独 A/B，会让决策学习滞后于市场变化。

一句话:

Adaptive experimentation 把实验从“阶段性验证一个版本”升级为“在风险边界内持续学习哪个 context 该匹配哪个 action”。

2.1 A/B、Multi-Armed Bandit、Contextual Bandit、Uplift 的边界

Contextual bandit 的优势在于只处理一步决策或短期动作选择，工程和治理复杂度低于完整 RL，但比 A/B 和 multi-armed bandit 更适合个性化决策。

2.2 金融零售中的高价值场景

---

3. Contextual Bandit-to-Decision 架构

3.1 参考架构

Business decision inventory
  -> decision and risk tier classification
  -> data contracts and feature store
  -> action catalog and eligibility policy
  -> reward and guardrail definition
  -> exploration policy and budget control
  -> decision service
  -> propensity-aware event logging
  -> delayed outcome attribution
  -> offline policy evaluation
  -> online ramp and adaptive learning
  -> monitoring, kill switch and evidence binder

3.2 核心组件

3.3 决策调用序列

1. Channel requests decision(customer_id, surface, event_type)
2. Identity / consent / purpose policy validates eligible context
3. Context service returns feature vector and missingness flags
4. Action catalog returns eligible actions
5. Policy engine removes prohibited actions and adds constraints
6. Exploration controller selects policy mode and budget
7. Bandit policy scores actions and samples one action
8. Decision API returns action, probability, policy version and explanation
9. Exposure logger records what was actually shown or executed
10. Outcome pipeline joins delayed reward and guardrail metrics
11. OPE and monitoring evaluate candidate policies and live risk

3.4 Multi-armed bandit 到 contextual bandit 的升级路径

Stage 1: A/B test
  Compare fixed variants with stable randomization.

Stage 2: Multi-armed bandit
  Shift traffic toward better arms using aggregate reward.

Stage 3: Segmented bandit
  Run separate bandits by coarse segment such as channel or lifecycle.

Stage 4: Contextual bandit
  Use rich context to choose action for each decision.

Stage 5: Governed adaptive decisioning
  Add eligibility, fairness, OPE, risk gates, kill switch and evidence binder.

成熟度判断:

• 如果团队不能稳定记录 action probability，就不应宣称具备 contextual bandit 能力。
• 如果 reward 没有延迟归因和 guardrail，就只能做低风险 engagement learning。
• 如果 action 会影响价格、额度、拒绝或催收强度，必须进入 governed adaptive decisioning。

---

4. 探索 / 利用权衡

Exploration / exploitation 是 bandit 的核心矛盾:

• Exploitation: 选择当前估计最优 action，最大化短期已知收益。
• Exploration: 有控制地尝试不确定 action，获得信息，改善未来决策。

金融零售中，探索不是“随机试错”，而是受风险预算、客户保护、合规约束和业务价值约束的投资。

4.1 Exploration budget 的产品定义

Exploration budget = 组织愿意为学习承担的受控机会成本和风险暴露上限。

4.2 风险分层探索策略

4.3 常见算法选择

4.4 算法不是第一决策

在产品架构评审中，优先顺序应是:

Decision risk
  -> action eligibility
  -> reward validity
  -> logging completeness
  -> exploration budget
  -> OPE readiness
  -> governance and rollback
  -> algorithm family

算法可替换，日志和治理债务很难补救。没有 propensity 的历史数据很难支持可信的 inverse propensity scoring 或 doubly robust 评估；没有 exposure log 的实验无法区分“被分配”和“真正看到”；没有 policy version 的决策无法复盘。

---

5. 策略、日志、反事实评估

5.1 Policy lifecycle

Policy proposal
  -> risk tier and action scope review
  -> offline data readiness check
  -> logging and propensity validation
  -> shadow / replay evaluation
  -> limited online exploration
  -> OPE and guardrail review
  -> ramp, freeze, rollback or redesign
  -> post-decision evidence binder

每个 policy 都应被当作产品资产管理，而不是 notebook 或模型文件:

5.2 Decision log contract

Contextual bandit 的日志不是普通埋点。它必须支持反事实评估和审计复盘。

最低要求:

• 必须记录 selected action 的 probability。
• 必须记录未被选择但可选的 action set。
• 必须区分 assignment、decision、exposure 和 outcome。
• 必须记录 policy version、feature version、reward version 和规则版本。
• 必须能追溯 fallback 和人工覆盖。

5.3 Offline policy evaluation

Offline policy evaluation 是在不上线候选策略的情况下，用历史 bandit data 估计候选 policy 表现。它的价值不是替代线上实验，而是在客户暴露前淘汰明显不稳或高风险策略。

Replay evaluation

Replay 只使用历史中候选 policy 会选择同一 action 的事件来估计 reward。它直观、保守，但样本效率可能低。

适合:

• 历史策略有随机化。
• action set 相对有限。
• 候选 policy 与历史 policy 有足够重叠。

风险:

• 如果历史探索太少，coverage 不足。
• 如果 context 或 action catalog 已变化，重放结果可能失真。

Inverse propensity scoring

Inverse propensity scoring, IPS, 用 observed reward 除以 logging policy 选择该 action 的概率，修正历史策略造成的选择偏差。

Estimated value =
  average over events [
    reward * indicator(candidate_policy_action = logged_action) / logged_propensity
  ]

产品解释:

• 如果历史策略很少选择某 action，propensity 很小，该样本权重会很大，方差会升高。
• IPS 不是“有日志就可信”，它依赖 propensity 准确、policy 重叠和 reward 口径稳定。
• 金融场景中要同时看总体 value、分群 value、低 propensity 覆盖、置信区间和 guardrail。

Doubly robust

Doubly robust 结合 reward model 与 propensity weighting。直觉上，它既利用模型预测未观察 action 的 reward，也用 propensity 修正选择偏差。

产品价值:

• 相比纯 IPS，通常能降低方差。
• 相比纯 reward model，对模型错设更有韧性。
• 适合在金融零售中做候选 policy 筛选，但不能替代高风险上线门禁。

审查问题:

• reward model 是否使用了上线时不可用的未来信息。
• propensity 是否来自真实 logging policy，而不是事后估计拼接。
• treatment overlap 是否足够，低覆盖 segment 是否单独标红。
• negative reward、投诉、误杀、逾期、人工覆盖是否进入评估。

5.4 OPE Review Memo 标准

---

6. Adaptive Experimentation 产品决策

Adaptive experimentation 是产品机制，不只是统计机制。它改变了团队如何定义 hypothesis、分配流量、看指标和做上线决策。

6.1 适合 bandit 的产品条件

6.2 不适合直接 bandit 的产品条件

6.3 产品指标树

Primary reward
  -> Incremental conversion / cure / resolution / fraud prevented

Business quality
  -> margin, lifetime value, retention, risk-adjusted return

Customer outcome
  -> task success, complaint, opt-out, trust, hardship accommodation

Fairness and harm
  -> subgroup exposure, adverse outcome, wait time, pricing dispersion

Operational health
  -> queue load, manual review capacity, agent override, system latency

Learning health
  -> exploration rate, propensity distribution, action diversity, OPE coverage

6.4 场景设计样例

Personalization / Next-best-action

Context:
  customer lifecycle, balances, cash-flow volatility, product holdings,
  channel, consent, recent events, support history

Actions:
  savings nudge, autopay setup, credit education, budgeting tool,
  appointment prompt, no-action

Reward:
  completed action, 30-day retention, reduced overdraft, lower complaint

Guardrails:
  frequency cap, opt-out, vulnerable customer rules, product suitability,
  equal exposure to beneficial education

高级判断:

• no-action 必须是合法 action，避免系统为了 reward 过度触达。
• 教育内容和产品 offer 要分开治理，避免把教育伪装成销售。
• reward 应加入长期客户结果，不只看点击。

Offer optimization

Context:
  eligibility, channel, relationship depth, cost-to-serve, offer history,
  churn risk, profitability, consent, complaint history

Actions:
  cashback offer, fee waiver, bundle, rate discount, points boost,
  retention call, no-offer

Reward:
  incremental acceptance, margin-adjusted revenue, retained relationship

Guardrails:
  fairness, pricing dispersion, complaint, cannibalization, offer fatigue

高级判断:

• offer 成本必须进入 reward，否则 bandit 可能偏向高补贴。
• 需要 holdout 估算增量，否则会奖励本来就会转化的人。
• 对弱势或受保护 proxy group，要监控可得性、价格、条件和实际结果。

Dynamic pricing

Context:
  risk, demand, funding cost, competitor signal, relationship value,
  product constraints, geography, customer segment

Actions:
  price / rate / fee level within approved grid

Reward:
  risk-adjusted margin, acceptance, retention, default-adjusted value

Guardrails:
  fair lending, price discrimination, explainability, complaint,
  margin floor, customer harm threshold

高级判断:

• dynamic pricing 是高风险 bandit 场景，不应从黑箱个性化价格开始。
• 可探索空间必须被 policy grid 限制，并保留原因码和价格分布审计。
• 对信贷、保险、财富收费等场景，要由合规和模型风险确认可用特征、定价依据和客户解释。

Fraud friction

Context:
  transaction risk, merchant, device, location, account history,
  session anomaly, customer vulnerability, prior false positive

Actions:
  approve, silent monitor, OTP, biometric step-up, manual review,
  temporary decline

Reward:
  fraud loss prevented, good transaction approved, friction minimized

Guardrails:
  false positive, account access harm, subgroup decline rate,
  manual review SLA, complaint, abandonment

高级判断:

• fraud bandit 的 reward 必须同时奖励好客通过和损失减少。
• exploration 不应直接尝试高伤害 decline，探索空间应集中在 friction 强度和路由。
• delayed chargeback 会让 early reward 偏乐观，需要多窗口 reward。

Collections treatment

Context:
  delinquency stage, repayment history, cash-flow pattern, hardship signals,
  contact preference, prior response, regulatory constraints

Actions:
  reminder, self-service plan, hardship offer, agent call,
  reduced contact, pause and review

Reward:
  cure, sustainable repayment, kept promise, reduced repeat delinquency

Guardrails:
  consumer harm, over-contact, complaint, vulnerable customer escalation,
  script compliance, long-term re-default

高级判断:

• 催收 bandit 必须把消费者伤害和投诉作为硬 guardrail。
• 短期回款最大化可能伤害长期复原和客户信任。
• 对脆弱客户或 hardship signals，应优先触发人工关怀或保护策略。

Contact center routing

Context:
  intent, language, sentiment, customer value, product, queue state,
  agent skill, prior contact, case complexity

Actions:
  specialist queue, self-service flow, callback, AI assist mode,
  retention agent, escalation

Reward:
  first contact resolution, CSAT, handle time adjusted by quality

Guardrails:
  wait-time fairness, abandonment, repeat contact, complaint,
  agent workload, escalation correctness

高级判断:

• routing reward 不能只优化 AHT，否则会牺牲复杂客户和弱势群体。
• 坐席技能和负载是动态 context；action 也受实时 capacity 约束。
• AI assist 建议被坐席采纳与否要记录，避免把人工判断误归因给模型。

---

7. 风险治理

Contextual bandit 在金融零售中最大的风险不是算法失控，而是“系统持续优化了一个狭窄 reward，同时把伤害外部化给客户、坐席、投诉团队或未来风险”。

7.1 NIST AI RMF 映射

7.2 Consumer harm taxonomy

7.3 Fairness / consumer harm 审查问题

• 哪些 context 特征可能是受保护属性或其 proxy。
• action 是否影响价格、服务可得性、验证强度、催收强度或人工关注。
• 不同群体是否获得相似的有益 action 机会。
• 探索流量是否在某些群体上过度集中。
• reward 是否把投诉、退订、人工覆盖、长期违约、重复来电纳入负向信号。
• 是否存在“利润更高但客户结果更差”的策略。
• 是否能向客户、坐席、审计和监管解释策略边界。

7.4 Kill switch

Kill switch 不是上线后再补的按钮，而是 bandit 决策服务的核心控制面。

Kill switch 运行要求:

• 独立于模型部署链路，可由授权业务 / 风险 / 技术负责人触发。
• 触发后保留 decision log、policy version、影响范围、回退时间和原因。
• 每个 high-risk policy 都有预演过的 rollback path。
• kill switch 不只针对模型错误，也针对日志丢失、propensity 异常、队列拥堵、公平性越界和投诉激增。

7.5 上线门禁

---

8. 模板

8.1 Contextual Bandit Policy Card

8.2 Reward Design Card

8.3 Decision Log Schema Brief

Decision event:
  decision_id
  timestamp
  customer_key
  channel
  decision_surface
  context_snapshot_id
  feature_version
  eligible_actions
  blocked_actions_with_reasons
  selected_action
  action_probability
  exploration_mode
  policy_version
  ruleset_version
  explanation_code

Exposure event:
  decision_id
  exposed_flag
  exposed_timestamp
  rendered_action
  staff_or_customer_surface

Outcome event:
  decision_id
  reward_value
  reward_window
  outcome_timestamp
  guardrail_flags
  complaint_flag
  override_flag
  fairness_slice_keys

8.4 OPE Review Memo

Policy under review:
Baseline policy:
Candidate policy:
Business decision:
Risk tier:

Data window:
Events used:
Coverage:
Propensity integrity:
Estimator results:
  Replay:
  IPS:
  Doubly robust:

Segment analysis:
Guardrail analysis:
Fairness / consumer harm analysis:
Operational impact:
Decision:
  shadow / limited ramp / redesign / freeze / retire

Conditions for next review:
Rollback path:
Approvers:

8.5 Risk Gate Checklist

8.6 Executive Decision Memo

Decision requested:
Approve limited ramp of contextual bandit policy for [decision surface].

Why now:
Current fixed policy under-serves heterogeneous customer needs and slows learning.

Evidence:
OPE shows candidate policy improves risk-adjusted reward versus champion,
with acceptable variance, overlap and guardrail performance.

Risk controls:
Traffic cap, segment cap, action eligibility, fairness monitoring,
consumer harm guardrails and policy-level kill switch are active.

Decision boundary:
No autonomous changes to credit denial, account closure, legal action,
or high-impact pricing outside approved policy grid.

Scale condition:
Ramp only if reward, guardrail, fairness, operations and logging metrics
remain within thresholds for the review window.

---

9. 30 天训练计划

目标: 用 30 天把 contextual bandits 从算法概念转化为可落地的金融零售 AI 产品架构能力。默认学习者已经具备高级 BA / PM / 架构基础。

30 天结束时应能产出:

• Contextual Bandit Decision Service 架构图。
• Policy Card、Reward Card、Decision Log Contract、OPE Memo。
• 三个金融零售案例: offer optimization、fraud friction、contact center routing。
• 一个高风险治理案例: collections treatment 或 dynamic pricing。
• 一套面试答案: 算法、产品、架构、风险、合规、OPE、fairness、kill switch。

---

10. 面试答案

10.1 Contextual bandit 和 multi-armed bandit 的区别是什么

30 秒版本:

Multi-armed bandit 在多个 arms 中学习哪个总体效果最好；contextual bandit 会在每次决策时使用用户、渠道、产品、风险等 context，学习“什么 context 下该选什么 action”。金融零售中的 next-best-action、offer optimization、fraud friction 和 routing 更接近 contextual bandit，因为客户和案件差异决定了最优动作。

2 分钟版本:

Multi-armed bandit 适合低风险、context 不重要或 action 效果差异主要体现在总体平均值的场景，例如几个 banner 文案或内容卡片。Contextual bandit 则把每次决策表示为 context、action、probability、reward 四件事。它只观察被选 action 的 reward，因此必须记录 propensity，才能做 offline policy evaluation。

在金融零售里，contextual bandit 的关键不是算法本身，而是治理: 先用 eligibility 和 policy engine 限制 action set，再用 exploration budget 控制流量和成本，最后用 IPS、doubly robust、guardrail 和 fairness monitoring 判断策略是否能 ramp。对于影响价格、信贷、催收、欺诈拦截的场景，不能把它当普通增长实验处理。

10.2 为什么 LinUCB 适合解释 contextual bandit

30 秒版本:

LinUCB 是 contextual bandit 的经典算法，它假设 reward 可以由 context-action 特征线性解释，并用不确定性上界做探索。它适合向业务解释“模型为什么既利用当前最佳估计，又会探索不确定但有潜力的动作”。

2 分钟版本:

LinUCB 来自 personalized news recommendation 的经典研究。它把用户和内容特征作为 context，用线性模型估计每个 action 的 reward，同时给不确定性更高的 action 一个 upper confidence bound。这样系统不是纯随机探索，而是在高潜力和高不确定之间权衡。

金融零售中，LinUCB 的优势是速度快、可解释、对稀疏场景友好，适合做低到中风险的 next-best-action 或 offer optimization 起点。限制是线性假设可能无法捕捉复杂交互，且它仍然需要高质量 action catalog、propensity logging、reward design 和 fairness guardrail。我的设计会把 LinUCB 放在 governed decision service 内，而不是让模型直接越过资格和风险规则。

10.3 Epsilon-greedy 和 Thompson Sampling 如何选择

30 秒版本:

Epsilon-greedy 简单、透明、容易预算，但探索比较粗；Thompson Sampling 用后验采样自然平衡探索和利用，通常更高效，但对后验建模、约束和解释要求更高。金融零售先看风险和治理成熟度，再选算法。

2 分钟版本:

Epsilon-greedy 的产品优点是容易向业务解释: 大多数流量走当前最佳策略，一小部分流量用于探索。它适合早期平台、低风险内容、文案和入口排序。但它的探索可能不够聪明，所以必须用 eligibility policy 排除明显不合适 action。

Thompson Sampling 更像概率化的 uncertainty-aware 决策。它从每个 action 的后验分布采样，天然让更不确定但潜力高的 action 获得探索机会。它适合样本较多、reward 稳定、团队能解释 posterior 和监控漂移的场景。

在 dynamic pricing、fraud friction、collections 等高风险场景，我会先限制 action grid、加保守探索、设置 segment cap 和 kill switch，而不是单纯追求 Thompson Sampling 的效率。

10.4 Offline policy evaluation 为什么是 bandit 平台的核心

30 秒版本:

Contextual bandit 只看到被选 action 的结果，天然缺少其它 action 的标签。Offline policy evaluation 用带 propensity 的历史日志估计候选策略表现，是上线前过滤风险策略的核心能力，但不能替代线上受控 ramp。

2 分钟版本:

OPE 的前提是历史日志记录了 context、eligible action set、selected action、action probability、policy version、exposure 和 reward。没有 probability，就很难做 inverse propensity scoring；没有 exposure，就无法判断客户是否真的受到策略影响；没有 action set，就无法判断候选 policy 是否有 coverage。

我会用 replay、IPS 和 doubly robust 做三角验证。Replay 保守但样本效率低；IPS 修正选择偏差但可能高方差；doubly robust 结合 reward model 和 propensity weighting，通常更稳。OPE report 不能只给平均 reward，还要给 coverage、置信区间、低 propensity 诊断、分群 guardrail、fairness 和 consumer harm 指标。高风险场景仍需要 shadow、limited ramp 和 kill switch。

10.5 Bandit 和 uplift modeling 如何配合

30 秒版本:

Uplift / CATE 估计“谁会因为 treatment 产生增量效果”，contextual bandit 解决“在每次 context 下选择哪个 action 并持续学习”。前者更偏因果估计和 targeting，后者更偏在线决策和 adaptive experimentation。

2 分钟版本:

EconML / DoWhy 类工具帮助团队声明因果假设、估计 heterogeneous treatment effects，并回答哪些客户真正因干预受益。这对 offer targeting、催收干预、教育提醒非常重要，因为高响应不等于高增量。

Contextual bandit 则把这些洞察放入在线决策循环。比如先用 uplift model 识别最可能从预算工具受益的客户，再让 bandit 在合规 action set 内学习不同渠道、文案、时点和 next-best-action 的组合。成熟做法是让 uplift 提供先验和策略约束，让 bandit 负责持续学习和分配，同时用 OPE 和 holdout 验证长期增量。

10.6 如何设计金融零售 offer optimization bandit

30 秒版本:

我会先建立 action catalog 和资格规则，再设计成本感知 reward，记录 propensity，用 limited exploration 优化不同客户 context 下的 offer，同时把 fairness、价格分布、投诉、退订和 margin 作为上线门禁。

2 分钟版本:

Offer optimization 的 action 不只是“给哪个优惠”，还包括不给 offer、给教育内容、给顾问回访、给 bundle 或 fee waiver。Context 包括资格、渠道、关系深度、历史 offer、客户价值、风险、同意和投诉历史。

Reward 不能只看接受率，因为高补贴会天然提高转化。我会用 margin-adjusted incremental value，扣除补贴、资金成本、运营成本和投诉惩罚。实验上，先用低风险流量和保守 exploration budget，上线前做 OPE，线上用 segment cap 和 fairness dashboard。对可能涉及差别待遇的价格或费用，必须走 legal、compliance、fair lending 和 model risk gate，并保留原因码与审计证据。

10.7 Fraud / collections 场景为什么更难

30 秒版本:

因为 reward 延迟、客户伤害高、错误成本不对称。Fraud 要同时优化损失和好客通过；collections 不能只优化短期回款，还要控制过度触达、脆弱客户伤害、投诉和长期复原。

2 分钟版本:

Fraud friction 的 action 包括放行、OTP、人工复核和拒绝。短期 reward 可能看不到 chargeback，因此要有多窗口 reward。系统必须监控 false positive、账户访问伤害、人工复核 SLA 和分群误杀率。

Collections treatment 的 action 包括提醒、自助还款计划、人工关怀、宽限和降低触达。短期 cure rate 可能掩盖消费者伤害或 repeat delinquency。我的设计会把 hardship signals、contact cap、script compliance、complaint 和 vulnerable customer escalation 作为硬约束，并把 aggressive treatment 排除在普通探索之外。对这两类场景，bandit 更适合优化 friction / treatment 强度和路由，而不是自主决定高伤害动作。

10.8 Kill switch 应该怎么设计

30 秒版本:

Kill switch 必须是 contextual bandit decision service 的一级能力，可以按 policy、segment、action、exploration 或系统级别回退到 champion / rule-based safe mode，并记录触发原因、影响范围和恢复证据。

2 分钟版本:

我会把 kill switch 设计成独立控制面，而不是依赖模型发布流程。触发条件包括 reward 崩坏、guardrail 越界、fairness 异常、投诉激增、propensity 日志异常、feature store 错误、人工队列拥堵和外部风险事件。

回退目标要提前定义: policy-level 回到 champion policy，action-level 禁用问题 offer，segment-level 对特定群体走固定规则，exploration-level 暂停探索，system-level 进入 deterministic safe mode。每次触发都进入 evidence binder，包括 policy version、decision count、客户影响、恢复动作和复盘结论。金融零售里，不能只有“停止模型”，还要确保客户服务、风险处理和人工补救同步启动。

---

11. 高级总结

Contextual bandits 在金融零售 AI 中的真正价值，不是让实验更自动，而是让高频决策在明确风险边界内持续学习。成熟方案必须同时具备:

• 产品层: decision inventory、action catalog、reward design、exploration budget。
• 架构层: decision API、policy engine、feature store、propensity logging、outcome attribution。
• 评估层: replay、inverse propensity scoring、doubly robust、OPE review、online ramp。
• 治理层: fairness / consumer harm、NIST AI RMF evidence、kill switch、audit trail。
• 业务层: personalization、next-best-action、offer optimization、dynamic pricing、fraud / collections / contact center routing 的场景化边界。

高级 AI PM / Product Architect 的判断标准是:

不是“我们用了 contextual bandit”，而是“我们能证明每一次自适应决策在当时 context、当时 action set、当时 probability、当时约束和后续 outcome 下是可解释、可评估、可治理、可回退的”。