Contextual Bandits：LinUCB、Thompson Sampling 与在线学习
一句话:
Contextual Bandits / LinUCB / Thompson Sampling 解读
面向对象: AI Product Manager / Decision Intelligence Architect / Growth PM / Risk Product Lead。 核心问题: A/B 测试把流量固定分给几个方案，推荐系统按历史相关性排序；但金融零售的 offer、next-best-action、渠道路由、催收触达和客服分流需要在真实反馈中持续学习，同时控制探索风险。 学习目标: 理解 contextual bandits、multi-armed bandit、LinUCB、Thompson Sampling、epsilon-greedy、offline policy evaluation、inverse propensity scoring、doubly robust，并映射到自适应实验和受控个性化架构。
Source Anchors
| Source | Link | 用途 |
|---|---|---|
| LinUCB / Personalized News Recommendation | https://arxiv.org/abs/1003.0146 | 理解把个性化内容推荐建模为 contextual bandit，以及 LinUCB 的探索/利用机制 |
| Vowpal Wabbit Contextual Bandits | https://vowpalwabbit.org/docs/vowpal_wabbit/python/latest/tutorials/python_Contextual_bandits_and_Vowpal_Wabbit.html | 参考 contextual bandit 的工程数据格式、action、cost/reward、probability logging |
| Microsoft SynapseML Vowpal Wabbit CB | https://microsoft.github.io/SynapseML/docs/Explore%20Algorithms/Vowpal%20Wabbit/Contextual%20Bandits/ | 参考大规模上下文 bandit 与反事实评估工作流 |
| NIST AI RMF | https://www.nist.gov/itl/ai-risk-management-framework | 把 adaptive decisioning 纳入风险识别、度量、治理和持续监控 |
一句话:
Contextual bandit 是“带上下文的自适应决策实验”: 系统根据用户/场景上下文选择动作，只观察被选择动作的结果，并在探索新动作和利用当前最佳动作之间持续权衡。
1. 为什么产品团队需要 Bandit 思维
传统 A/B 测试适合回答:
哪个方案平均更好？
Contextual bandit 更适合回答:
对这个上下文里的这个用户，现在应该尝试哪个动作，同时还能学习更好的策略？
金融零售中常见动作:
| 场景 | Context | Action | Reward |
|---|---|---|---|
| 信用卡 offer | 客户画像、消费、风险等级、渠道偏好 | 返现、免息、积分、无 offer | 增量消费、风险调整收益、投诉成本 |
| 催收触达 | 逾期阶段、历史响应、联系偏好、投诉风险 | 短信、电话、App、宽限、人工 | 回款、投诉、成本、复逾 |
| 客服路由 | 问题类型、客户等级、情绪、队列状态 | 机器人、人工、专家队列、回拨 | 解决率、AHT、NPS、SLA |
| 欺诈干预 | 风险分数、金额、设备、商户、历史 | 放行、强认证、人工、拒绝 | 避免损失、误拦成本、客户摩擦 |
| 零售促销 | 门店、SKU、库存、价格、天气、节假日 | 折扣、捆绑、陈列、无动作 | 毛利、库存周转、缺货风险 |
高阶 PM 的判断点是: 哪些动作可以探索，哪些动作必须受保护，哪些人群不能实验。
2. Multi-Armed Bandit 到 Contextual Bandit
Multi-armed bandit 的基础问题:
每次从多个动作中选一个，只看到被选动作的 reward，长期目标是最大化累计 reward。
Contextual bandit 加入上下文:
observe context x
choose action a
observe reward r(a)
update policy pi(a | x)
和监督学习的区别:
| 维度 | 监督学习 | Contextual Bandit |
|---|---|---|
| 标签 | 通常有完整标签 | 只观察被选择动作的反馈 |
| 数据来源 | 静态历史数据 | 由策略本身生成 |
| 核心风险 | 过拟合、偏差 | 探索风险、选择偏差、反事实缺失 |
| 评估 | train/test split | counterfactual / off-policy evaluation |
| 产品形态 | 预测或排序 | 自适应动作选择 |
3. 三种基本策略
Epsilon-Greedy
大多数时候选当前最佳动作，少数时候随机探索。
适合:
- 快速 baseline。
- 低风险动作。
- 初期探索。
问题:
- 随机探索可能浪费高价值流量。
- 不利用不确定性结构。
- 对受监管或高伤害动作过于粗糙。
LinUCB
LinUCB 对每个动作估计 reward，并加入不确定性上界:
score = estimated reward + uncertainty bonus
产品含义:
- 不确定但可能有价值的动作会获得探索机会。
- 随着数据变多，不确定性降低。
- 适合线性特征结构较强的个性化场景。
Thompson Sampling
从后验分布中抽样，按抽样后的最优动作执行。
产品含义:
- 探索概率自然随不确定性变化。
- 表达比固定 epsilon 更柔和。
- 适合需要概率化探索预算的场景。
4. Logging 是 Bandit 产品的核心
Bandit 系统必须记录 propensity，也就是当时选择该动作的概率。没有 propensity，后续就很难做反事实评估。
最低日志:
| 字段 | 说明 |
|---|---|
| event_id | 决策事件 |
| timestamp | 决策时间 |
| context_snapshot | 当时可用上下文 |
| available_actions | 当时可选动作集合 |
| chosen_action | 实际选择动作 |
| action_probability | 该动作被当前策略选中的概率 |
| reward_observed | 观测到的结果 |
| reward_delay | reward 延迟 |
| policy_version | 策略版本 |
| guardrail_result | 风险、合规、公平性检查结果 |
许多团队做 bandit 失败，不是算法不行，而是日志缺失导致无法证明策略是否真的更好。
5. Offline Policy Evaluation
新策略不能直接全量上线。需要用历史日志评估“如果当时用新策略，会怎样”。
常见方法:
| 方法 | 核心思想 | 风险 |
|---|---|---|
| Inverse Propensity Scoring | 用选择概率修正历史样本偏差 | 高方差，低概率样本权重大 |
| Self-Normalized IPS | 对 IPS 做归一化 | 可能引入偏差 |
| Doubly Robust | 结合 reward model 和 IPS | 模型和 propensity 都要管好 |
| Replay evaluation | 只在新旧策略选择一致时计入 | 数据利用率低 |
产品上线门禁:
- 日志必须包含 propensity。
- 新策略覆盖的人群不能超出历史支持范围太远。
- OPE 结果要按客群、渠道、风险等级分层。
- 不能只看平均 reward，还要看投诉、误伤、公平性和长期价值。
6. Bandit Decision Architecture
context service
-> action eligibility / policy guardrail
-> bandit policy service
-> exploration budget manager
-> action execution
-> reward attribution
-> counterfactual log store
-> offline policy evaluation
-> policy review and rollout
关键组件:
| 组件 | 职责 |
|---|---|
| Context service | 只提供当时可用、权限允许、可审计的上下文 |
| Action catalog | 定义动作、成本、风险、适用人群和禁用条件 |
| Exploration budget | 控制探索比例、人群、时间窗和风险边界 |
| Policy service | 执行 LinUCB、Thompson Sampling 或其他策略 |
| Guardrail | 拦截不合规、不公平、高伤害动作 |
| Reward service | 管理延迟 reward、归因窗口和多目标 reward |
| OPE lab | 用 IPS/DR/replay 评估候选策略 |
| Review board | 审核策略变更、异常、回滚和人群影响 |
7. 金融零售治理风险
Bandit 系统的高风险点:
| 风险 | 例子 | 控制 |
|---|---|---|
| Consumer harm | 对脆弱客户探索高摩擦催收动作 | 禁止探索人群和 action risk tier |
| Fairness drift | 某些客群长期收到较差 offer | 分层监控、最低服务保障 |
| Reward hacking | 只优化短期点击，伤害长期价值 | 多目标 reward 和 guardrails |
| Feedback delay | 坏账、投诉、复购反馈滞后 | reward maturity window |
| Policy instability | 策略频繁变化造成运营不可解释 | cadence、change log、rollback |
| Selection bias | 历史策略导致反事实不可见 | 强制探索预算和 propensity logging |
8. 面试表达
30 秒版本
Contextual bandit 是自适应实验和个性化决策的中间层，比 A/B 更动态，比完整 RL 更可控。它根据上下文选择动作，只观察被选动作的 reward，所以必须设计 exploration budget、propensity logging、offline policy evaluation、guardrail 和回滚。
2 分钟版本
在金融零售里，我会把 bandit 用在可控、低到中风险、反馈相对明确的动作上，比如 offer 优化、客服路由、渠道触达和 next-best-action。架构上先有 action catalog 和 eligibility policy，排除不合规或高伤害动作，再由 LinUCB 或 Thompson Sampling 做探索/利用权衡。每次决策必须记录 context、action、probability、policy version 和 reward，后续用 IPS 或 doubly robust 做离线策略评估。上线不只看 reward，还要看公平性、投诉、误伤、长期价值和运营容量。
CTO 追问
如果问为什么不用普通推荐模型，我会回答: 推荐模型通常在静态历史数据上学相关性，而 bandit 会主动管理探索，减少只利用旧策略造成的选择偏差。没有 bandit 或实验机制，系统很难知道没被推荐的动作是否更好。
9. Portfolio Task
做一个 “Adaptive Offer Bandit Pack”:
| Artifact | 内容 |
|---|---|
| Action catalog | 每个 offer/动作的成本、风险、适用条件 |
| Context schema | 客户、渠道、时点、产品、风险上下文 |
| Exploration policy | 探索比例、人群排除、kill switch |
| Logging contract | event、probability、policy version、reward |
| OPE plan | IPS、DR、分层评估和 guardrail 指标 |
| Decision memo | 为什么从 A/B 升级到 bandit，边界和风险 |
最终要能讲清楚: bandit 不是“更聪明的推荐”，而是有探索预算、反事实日志和治理边界的自适应决策系统。