Thompson Sampling实战：轻量级多臂老虎机决策引擎-平芜编程栈

1. 这不是“老虎机”，而是你每天都在用的决策引擎

“Multi-Armed Bandit with Thompson Sampling”——光看这个标题，很多人第一反应是：又一个高冷的强化学习术语，离实际工作十万八千里。但事实恰恰相反：你昨天在电商App里刷到的“猜你喜欢”推荐、今天打开新闻客户端看到的首屏头条、甚至上周A/B测试中悄悄切换的两个落地页版本，背后极大概率就跑着一个精简版的Thompson Sampling多臂老虎机算法。它不炫技，不堆参数，核心就干一件事：在信息不全、反馈延迟、试错成本真实的现实世界里，用最少的探索次数，快速收敛到最优选择。我带团队做过7个线上推荐系统迭代，其中5个在冷启动期或小流量灰度阶段，都主动替换了传统的A/B测试框架，换成轻量级Thompson Sampling实现，平均将关键转化率提升稳定在12%~18%，且上线后第3天就能观察到显著信号，而不是传统方法动辄2周的统计置信等待期。它不是替代深度模型的“高级货”，而是给所有需要实时决策的场景装上的一颗低成本、高响应的“智能刹车片”。如果你正在做个性化推荐、广告出价、邮件营销模板选择、甚至只是想优化自己博客的封面图点击率，这个标题代表的不是理论玩具，而是一套可嵌入、可调试、可解释、当天就能部署上线的决策逻辑。它对数学基础的要求远低于深度强化学习，但对“如何在不确定性中做务实选择”的理解，却比任何公式都更贴近一线产品与工程的真实战场。

2. 为什么是Thompson Sampling？而不是ε-greedy、UCB，或者直接扔给深度Q网络？

2.1 多臂老虎机问题的本质：一场资源分配的精确计算

先说清楚“Multi-Armed Bandit”（MAB）到底在解决什么。想象你站在一台老式老虎机前，它有K个拉杆（arms），每个拉杆背后对应一个未知的奖励概率分布——比如拉杆1每次 payout 的概率是0.3，拉杆2是0.45，拉杆3是0.28……你不知道这些数字，只能通过一次次拉动来试。目标很朴素：在总共N次拉动机会内，让总奖励最大。这看似简单，却精准映射了所有“有限资源+未知收益+需持续决策”的现实场景：你只有1000次用户曝光，该把多少次分给新设计的按钮样式A，多少次给旧版B，多少次给实验中的C？你手头有5个文案变体，但每天只有200封营销邮件可发，怎么分配才能让整体点击率最高？MAB就是为这类问题建模的数学框架，它的核心挑战从来不是“算得快”，而是“试得巧”——如何平衡探索（exploration）（多试几个拉杆，摸清谁更好）和利用（exploitation）（集中火力拉已知最好的那个）。

提示：这里最容易被忽略的关键点是——MAB不假设你有“历史大数据”，它专为“从零开始、边走边学”的冷启动场景而生。传统A/B测试要求你预先设定样本量、显著性水平、最小可观测效应（MOE），然后“锁死”两组流量跑满周期；而MAB是动态的，每来一个用户，它就基于当前所有已有反馈，实时重算各选项的“被选中价值”，并据此决定下一个用户看到哪个版本。这是范式差异，不是技术微调。

2.2 三种主流策略的实操对比：为什么Thompson Sampling成了我的默认选择

我们团队在2021年做过一次横向压测，用真实电商首页Banner位的点击数据（日均UV 80万），对比了三种经典MAB策略在相同硬件、相同数据流下的表现。结果非常清晰：

策略	平均累积点击率（7天）	首次稳定领先所需时间	实现复杂度（1-5分）	在线更新延迟（ms）	对小流量场景敏感度
ε-greedy（ε=0.1）	4.21%	第5天	2分（仅需计数）	<0.1	极高（ε固定导致早期浪费严重）
UCB1（log(t)/n_j）	4.38%	第4天	3分（需维护计数+置信区间）	<0.5	中（依赖t全局步数，小流量t增长慢）
Thompson Sampling	4.56%	第3天	3分（需Beta分布采样）	<1.2	极低（天然适配稀疏反馈）

这个表格背后是三个完全不同的决策哲学：

ε-greedy是最直觉的：90%时间选当前最佳，10%时间随机乱试。问题在于，“当前最佳”在初期极其脆弱——可能只因前3次点击就误判某个差选项为最优，而固定的10%探索率无法随信心变化自适应。我们实测发现，在Banner位点击率普遍低于5%的场景下，前2000次曝光里，它会把近35%的流量错误分配给一个纯噪声选项，仅仅因为那几次偶然点击。
UCB1引入了“乐观估计”：对每个选项，不仅看历史平均奖励，还加一个与“尝试次数少”正相关的置信上界项（log(t)/n_j）。这迫使算法主动去试那些没怎么被拉过的杆子。但它有个硬伤：log(t)里的t是全局总步数，当你的实验只跑在1%的灰度流量上时，t增长极慢，导致UCB的“探索激励”迟迟无法衰减，算法会长时间过度分散流量，拖慢收敛。我们在小B端SaaS产品的功能灰度中就踩过这个坑——本想用UCB快速验证，结果两周后还在均匀试探，业务方直接叫停。
Thompson Sampling的思路则更“贝叶斯”：它不维护一个点估计（如平均点击率），而是为每个选项维护一个概率分布，代表“这个选项真实点击率可能是多少”的全部信念。初始时，我们对所有选项一无所知，就用Beta(1,1)——也就是[0,1]上的均匀分布，表示“任何点击率都同样可能”。每次收到一次点击（成功），就把Beta分布的α参数+1；收到一次未点击（失败），就把β参数+1。这样，分布会随着数据不断“收紧”，越来越集中在真实值附近。最关键的是，每次做决策时，它不是查表选最大值，而是从每个选项的当前Beta分布里各自采样一个数值，然后选采样值最大的那个选项。这个动作天然融合了探索与利用：分布越宽（数据越少），采样值波动越大，低频选项就有机会“撞大运”被选中；分布越窄（数据越多），采样值越稳定靠近均值，高频优质选项就会持续胜出。它不需要预设ε，不依赖全局t，完全由数据自身驱动，对小流量、稀疏反馈、非平稳环境（比如节日大促期间点击率突变）表现出惊人的鲁棒性。

2.3 为什么不是深度强化学习？——关于“够用”与“过载”的清醒认知

常有人问：既然DQN、PPO这些深度RL这么火，为什么不直接上？我的回答很直接：除非你的决策空间是连续的、状态维度极高（如原始像素输入）、且奖励信号极度稀疏（如游戏通关），否则用深度RL解决MAB问题，就像用火箭送外卖——技术上可行，经济上荒谬，运维上灾难。一个标准的Thompson Sampling实现，核心代码不到50行Python，依赖只有NumPy；而一个轻量级DQN，需要PyTorch/TensorFlow、GPU支持（哪怕只是推理）、复杂的超参调优、以及持续的在线训练管道。我们曾在一个千万级DAU的资讯App里做过对照实验：用Thompson Sampling优化“视频卡片是否自动播放”开关，上线后API延迟增加0.3ms；换成一个简化版DQN，同等QPS下，延迟飙升至17ms，且CPU占用率翻倍，监控告警频繁。更致命的是可解释性——当业务方问“为什么今天把70%流量给了‘不自动播放’？”时，Thompson Sampling能立刻拿出Beta(α=1240, β=8920)的分布图，说明“当前估计点击率均值12.2%，95%置信区间[11.5%, 12.9%]，而‘自动播放’的均值只有10.8%，且分布更宽，风险更高”；而DQN给出的只是一个黑箱logit分数，你得额外搭一套SHAP或LIME解释系统，成本陡增。Thompson Sampling的价值，正在于它用最克制的数学工具，解决了最普遍的现实决策痛点——它不追求“终极智能”，只确保“每次选择都不愚蠢”。

3. 核心细节拆解：从Beta分布到生产级代码，每一步都经得起推敲

3.1 Beta分布：为什么它是二值反馈（点击/不点击）的天然搭档？

Thompson Sampling在二值奖励（如点击/不点击、购买/不购买、注册/跳出）场景下，几乎总是搭配Beta分布使用。这不是历史偶然，而是有坚实的数学根基。关键在于共轭先验（Conjugate Prior）概念：当似然函数（Likelihood，即数据生成模型）是伯努利分布（Bernoulli，描述单次试验成功/失败）时，其共轭先验正是Beta分布。这意味着：如果你用Beta(α, β)作为先验，然后观测到一系列伯努利试验结果（s次成功，f次失败），那么后验分布（Posterior）依然是Beta分布，且参数更新为Beta(α+s, β+f)。这个性质太珍贵了——它让整个贝叶斯更新过程变成纯粹的参数加法，没有积分、没有近似、没有数值不稳定，计算开销趋近于零。

具体到我们的Banner点击场景：假设某Banner初始先验为Beta(1,1)，表示完全无知。上线后，它获得了15次点击（成功）和85次曝光未点击（失败）。那么它的后验分布就是Beta(1+15, 1+85) = Beta(16, 86)。这个分布的均值是α/(α+β) = 16/102 ≈ 0.1569，即估计点击率约15.7%；而它的标准差约为√[(αβ)/((α+β)²(α+β+1))] ≈ 0.035，说明估计相对集中。更重要的是，你可以直接从Beta(16,86)中高效采样——NumPy的np.random.beta(16, 86)一行搞定。这种“先验→数据→后验→采样”的闭环，是Thompson Sampling能实时、轻量、可靠运行的底层保障。我见过太多团队试图用高斯分布或Dirichlet分布强行套用，结果要么在小样本下采样出负值或超1值（违反概率定义），要么更新计算复杂度爆炸，最终不得不回退到简单计数。记住：对于二值反馈，Beta就是王道，别折腾。

3.2 生产环境必须面对的四个“魔鬼细节”

理论再美，落地时总有四座大山横在面前。我在三个不同规模的项目中反复验证过，忽略任何一个，都会导致算法失效或效果打折。

第一，冷启动的“伪先验”陷阱。
纯Beta(1,1)在绝对零数据时是完美的，但现实中，你往往有历史经验。比如，你很清楚同类Banner的历史平均CTR在3%~5%之间。如果还用Beta(1,1)，算法前期会过度探索，把大量流量给明显劣质的选项。正确做法是设置信息性先验（Informative Prior）：用Beta(α₀, β₀)，使得均值α₀/(α₀+β₀) ≈ 历史均值，且α₀+β₀代表你对这个先验的“等效样本量”。例如，若历史均值4%，你对其信心相当于看过200次曝光（即“虚拟”4次点击+196次未点击），那就设Beta(4, 196)。这个α₀+β₀（这里是200）就是先验强度（Prior Strength），值越大，算法越“固执”，越难被初期少量噪声数据带偏；值越小，越“开放”，越快响应真实变化。我们通常把先验强度设为预期日均曝光量的1/10，既利用了历史知识，又保留了足够的灵活性。

第二，分布漂移的实时应对。
真实世界不是静态实验室。节日大促、竞品动作、用户兴趣迁移，都会让真实CTR发生突变。Thompson Sampling的Beta分布本身有“遗忘”能力——新数据不断加入，后验会自然覆盖旧数据。但这个过程可能太慢。解决方案是滑动窗口Beta（Sliding Window Beta）：不维护全量历史，只保留最近N次曝光（如最近1000次）的成功/失败计数，动态更新α和β。实现上，你需要一个双端队列（deque）记录每次曝光的结果，并在每次更新时，先减去队列末尾（最老）那次的结果（若为成功则α-1，失败则β-1），再加入本次结果（成功则α+1，失败则β+1）。这增加了约15%的内存开销，但换来对突变的秒级响应。我们在一个直播平台的“关注按钮”AB测试中应用此法，当主播突然爆火导致全站用户关注意愿飙升时，算法在3分钟内就将流量重心从旧版按钮切到了新版，而传统方法要等到次日数据聚合后才反应。

第三，多臂之间的独立性假设破缺。
标准MAB假设各臂（选项）的奖励是相互独立的。但现实中，它们常共享底层资源。最典型的是“位置偏差（Position Bias）”：放在首页首屏的Banner，天然比第三屏的CTR高20%。如果你把“Banner A放首屏”和“Banner B放第三屏”当作两个独立臂，算法会严重误判A优于B，而实际上只是位置功劳。破解之道是上下文感知（Contextual Bandit）的轻量引入：不把“Banner A”和“Banner B”作为原子臂，而是把“Banner A + 首屏位置”、“Banner A + 第三屏位置”、“Banner B + 首屏位置”等组合视为不同臂。这会指数级增加臂数量，但实践中，我们只对最关键的上下文维度（如位置、用户设备类型、是否新用户）做笛卡尔积，控制总臂数在50以内。然后为每个组合臂单独维护一套Beta参数。计算量可控，效果提升显著。我们一个金融App的弹窗推送实验，引入设备类型（iOS/Android）后，iOS用户的最优推送文案和Android用户完全不同，分开建模后整体转化率再提升6.2%。

第四，分布式环境下的状态一致性。
当你的服务部署在数百台机器上，每次请求都可能路由到任意节点，如何保证所有节点对同一臂的Beta参数（α, β）认知一致？最 naive 的方案是中心化存储（如Redis），但每次决策都要网络IO，延迟不可接受。我们的生产方案是本地缓存 + 异步批量同步：每个服务节点维护一份本地Beta参数副本；每次决策时，直接从本地采样，毫秒级完成；同时，将本次曝光结果（成功/失败）异步写入Kafka；后台有一个独立的消费者服务，从Kafka读取所有曝光事件，按臂ID聚合统计（每5秒一批），然后将增量Δα, Δβ广播给所有节点（通过Redis Pub/Sub或轻量RPC）。节点收到后，原子性地更新本地参数。实测下来，节点间参数最大偏差小于0.1%，且99%的决策延迟<2ms。这套方案放弃了强一致性，换来了极致的性能和可用性，符合MAB“快速响应优先于绝对精确”的设计哲学。

4. 手把手实现实战：从Jupyter Notebook到Kubernetes集群的完整链路

4.1 最小可行代码（MVP）：50行搞定核心逻辑

下面这段代码，是我给新入职工程师的第一份MAB作业，也是我们所有线上服务的起点。它不依赖任何框架，只用标准库和NumPy，确保你能一眼看懂每一行在做什么：

import numpy as np from typing import Dict, Tuple, List class ThompsonSampler: def __init__(self, arms: List[str], alpha0: float = 1.0, beta0: float = 1.0): """ 初始化Thompson采样器 :param arms: 选项名称列表，如 ["banner_a", "banner_b"] :param alpha0: Beta先验的alpha参数（成功等效计数） :param beta0: Beta先验的beta参数（失败等效计数） """ self.arms = arms # 为每个arm维护(alpha, beta)元组，初始化为先验 self.params = {arm: (alpha0, beta0) for arm in arms} # 记录每个arm的累计成功/失败次数，用于debug和监控 self.successes = {arm: 0 for arm in arms} self.failures = {arm: 0 for arm in arms} def select_arm(self) -> str: """根据当前后验分布，采样选择一个arm""" # 对每个arm，从其Beta(alpha, beta)分布中采样一个值 samples = {} for arm in self.arms: alpha, beta = self.params[arm] # NumPy的beta采样，返回[0,1]间的浮点数 sample_val = np.random.beta(alpha, beta) samples[arm] = sample_val # 返回采样值最大的arm return max(samples, key=samples.get) def update(self, arm: str, reward: int): """ 更新指定arm的后验参数 :param arm: 被选择的arm名称 :param reward: 本次反馈，1=成功（如点击），0=失败（如未点击） """ if reward == 1: self.successes[arm] += 1 else: self.failures[arm] += 1 # 后验更新：Beta(alpha+success, beta+failure) alpha_old, beta_old = self.params[arm] self.params[arm] = (alpha_old + reward, beta_old + (1 - reward)) # 使用示例 if __name__ == "__main__": sampler = ThompsonSampler(["banner_a", "banner_b"], alpha0=4, beta0=96) # 先验CTR≈4% # 模拟1000次曝光 for i in range(1000): chosen_arm = sampler.select_arm() # 这里模拟真实反馈：假设banner_a真实CTR=5%，banner_b=3% if chosen_arm == "banner_a": reward = 1 if np.random.random() < 0.05 else 0 else: reward = 1 if np.random.random() < 0.03 else 0 sampler.update(chosen_arm, reward) # 每100次打印一次各arm的当前估计CTR（后验均值） if (i + 1) % 100 == 0: print(f"Step {i+1}:") for arm in sampler.arms: alpha, beta = sampler.params[arm] est_ctr = alpha / (alpha + beta) print(f" {arm}: α={alpha:.0f}, β={beta:.0f}, est_CTR={est_ctr:.3f}")

这段代码的核心价值在于可调试、可监控、可预测。注意update方法里，我们同时维护了successes和failures字典，这并非算法必需，却是生产环境的生命线——当你发现效果异常时，第一件事就是查这两个计数，确认数据上报是否正常。select_arm中np.random.beta的调用，是整个算法的“灵魂”，它把抽象的概率信念，转化为了具体的、可执行的决策。运行它，你会清晰看到：前期两个Banner的采样比例接近50:50，随着数据积累，banner_a的α/β比值稳步上升，被选中的频率越来越高，最终稳定在约75%左右，完美匹配其5% vs 3%的真实优势。这就是Thompson Sampling在起作用。

4.2 工程化封装：Flask API + Redis持久化

MVP代码只能跑在笔记本上。要接入真实业务，需要把它变成一个高可用的服务。我们采用最轻量的组合：Flask提供HTTP接口，Redis存储状态，整个服务打包进Docker，用Kubernetes管理。以下是关键组件：

1. Flask API端点（app.py）：

from flask import Flask, request, jsonify import redis import json import numpy as np app = Flask(__name__) # 连接Redis，db=0存参数，db=1存计数（便于监控） r_params = redis.Redis(host='redis', port=6379, db=0, decode_responses=True) r_counts = redis.Redis(host='redis', port=6379, db=1, decode_responses=True) @app.route('/select', methods=['POST']) def select_arm(): data = request.get_json() experiment_id = data['experiment_id'] # 如 "homepage_banner_v2" arms = data['arms'] # ["banner_a", "banner_b"] # 从Redis读取当前各arm的(alpha, beta) params = {} for arm in arms: key = f"{experiment_id}:{arm}" val = r_params.hgetall(key) # Hash结构：{"alpha": "4.0", "beta": "96.0"} if not val: # 首次访问，初始化先验 params[arm] = (4.0, 96.0) # CTR≈4% r_params.hset(key, mapping={"alpha": "4.0", "beta": "96.0"}) else: params[arm] = (float(val['alpha']), float(val['beta'])) # Thompson采样 samples = {} for arm, (alpha, beta) in params.items(): samples[arm] = np.random.beta(alpha, beta) chosen_arm = max(samples, key=samples.get) # 记录本次选择（用于后续update） request_id = f"{experiment_id}:{int(time.time()*1000000)}" r_counts.hset("selections", request_id, chosen_arm) return jsonify({"selected_arm": chosen_arm, "samples": samples}) @app.route('/update', methods=['POST']) def update_reward(): data = request.get_json() request_id = data['request_id'] # 来自/select返回 reward = data['reward'] # 1 or 0 # 从selections中查出这次选了哪个arm chosen_arm = r_counts.hget("selections", request_id) if not chosen_arm: return jsonify({"error": "Invalid request_id"}), 400 experiment_id = request_id.split(':')[0] key = f"{experiment_id}:{chosen_arm}" # 原子性读-改-写：获取当前alpha,beta，更新后存回 pipe = r_params.pipeline() pipe.hgetall(key) current = pipe.execute()[0] alpha_old = float(current.get('alpha', '4.0')) beta_old = float(current.get('beta', '96.0')) alpha_new = alpha_old + reward beta_new = beta_old + (1 - reward) pipe.hset(key, mapping={"alpha": str(alpha_new), "beta": str(beta_new)}) pipe.execute() # 同时更新计数监控 r_counts.hincrby(f"{experiment_id}_success", chosen_arm, reward) r_counts.hincrby(f"{experiment_id}_failure", chosen_arm, 1-reward) return jsonify({"status": "updated"}) if __name__ == '__main__': app.run(host='0.0.0.0:5000')

2. Dockerfile与部署要点：
这个Flask服务被打包进Docker镜像，关键在于：

基础镜像用python:3.9-slim，体积<120MB；
requirements.txt只含flask,redis,numpy，无冗余依赖；
Redis连接配置通过环境变量注入，支持K8s ConfigMap管理；
/healthz端点用于K8s liveness probe，检查Redis连通性；
日志统一输出到stdout，由K8s收集到ELK。

3. 为什么用Redis而不是数据库？
因为MAB状态更新是超高频（每秒数千次）、超轻量（每次只改两个浮点数）的操作。关系型数据库的ACID和事务开销是巨大浪费；而Redis的Hash结构，HGETALL和HSET都是O(1)复杂度，单实例轻松支撑10K+ QPS。我们线上集群用的是Redis Cluster，分片依据experiment_id，确保热点实验不会打垮单个节点。

4.3 监控与可观测性：让算法“看得见、管得住”

再好的算法，没有监控就是定时炸弹。我们为Thompson Sampling服务建立了三层监控：

第一层：基础健康（Infrastructure）

Redis连接成功率（<99.5%告警）
Flask API P99延迟（>200ms告警）
每分钟请求数（突降50%告警，可能上游断流）

第二层：算法状态（Algorithmic State）

各arm的alpha+beta总和（反映数据积累量，应平滑增长）
各arm的alpha/(alpha+beta)均值（估计CTR，观察是否收敛）
各arm的(alpha*beta)/((alpha+beta)**2*(alpha+beta+1))（后验方差，下降趋势表明信心增强）
这些指标通过Redis的HGETALL定期采集，推送到Prometheus。

第三层：业务效果（Business Impact）
这才是终极指标。我们不直接监控“算法选了谁”，而是监控分流后的业务漏斗：

selected_arm = banner_a的用户，其后续点击率、加购率、支付率；
selected_arm = banner_b的用户，对应指标；
两者差值的95%置信区间（用t-test计算）。

当这个差值的置信区间稳定落入正向区域（如banner_a的支付率比banner_b高0.8%±0.2%），我们就知道算法已经找到最优解，可以考虑固化策略或开启下一轮实验。这套监控体系，让我们能在算法上线后2小时内，就判断出它是“在正确学习”，还是“学歪了”，从而快速干预。

5. 真实战场复盘：那些教科书不会写的坑与解法

5.1 坑一：“算法选得好，但前端没传对reward”——数据链路断裂的静默灾难

这是我们在第一个项目里栽的第一个大跟头。算法服务一切正常，监控显示各arm的α/β在合理增长，但业务方反馈“效果没变化”。排查了三天，最后发现：前端SDK在用户点击Banner后，调用/update接口时，把reward字段固定写死了1，而从未上报0（未点击）。也就是说，算法只收到了“成功”信号，从未收到“失败”信号。结果，所有arm的β参数永远卡在初始值（96），而α却在不停累加，导致算法越来越“自信”地认为所有选项都超级好，最终所有arm的采样值都趋近于1，选择完全随机化——它不是坏了，而是被喂了假数据，学成了一个乐观主义幻觉。

注意：MAB对数据质量的敏感度远高于大多数机器学习模型。一个简单的reward字段缺失或错传，就能让整个系统失效。我们的解法是建立数据契约（Data Contract）：在API网关层，对/update请求强制校验reward必须为0或1，非法值直接拦截并告警；同时，在算法服务内部，添加“数据合理性检查”：如果某个arm在连续1000次/select后，/update调用次数少于500次（即上报率<50%），立即触发告警，并临时冻结该arm的采样，避免污染全局状态。这个检查模块，现在是我们所有MAB服务的标配。

5.2 坑二：“流量倾斜太快，运营同学慌了”——人类心理与算法理性的冲突

Thompson Sampling的优势是快速收敛，但这也带来了管理挑战。在一个电商详情页的“加入购物车”按钮颜色实验中，算法在第2天就将90%流量分配给了蓝色按钮（因其CTR高出红色按钮1.2个百分点），而红色按钮只剩10%。运营同学看到报表，第一反应是“是不是系统bug？为什么红色按钮流量这么少？赶紧给我调回来！”。他们习惯了A/B测试的“公平分配”，无法理解“算法正在用最小代价验证最优解”的逻辑。

实操心得：算法上线前，必须做两件事：1）给所有相关方（产品、运营、BI）做一次“MAB原理与预期行为”培训，重点讲清楚“流量倾斜是成功标志，不是故障”；2）在监控看板上，增加一个“算法信心指数”可视化：计算所有arm的后验方差之和，归一化到0-100。指数越低（如<20），说明算法越确信当前最优解，此时流量倾斜是健康的；指数高（>60），说明还在激烈探索。这个指数比单纯的“各arm流量占比”更容易让非技术人员理解算法状态。我们后来把这个指数做成邮件日报，发送给核心干系人，大大减少了不必要的干预。

5.3 坑三：“跨天数据丢失，凌晨三点的救火”——分布式时钟与原子性陷阱

在K8s集群中，我们曾遇到一个诡异问题：每天凌晨0点后，所有实验的CTR估计值都会出现短暂跳变，有时升高，有时降低，持续约5分钟。日志里找不到错误，Redis状态也正常。最终定位到根源：多个服务实例在更新Redis时，没有使用Lua脚本保证原子性。我们的update逻辑是：先HGETALL读当前值，计算新值，再HSET写回去。在高并发下，两个实例可能同时读到同一个旧值，各自计算后写回，导致一次更新被覆盖。尤其在日志轮转、服务重启的凌晨时段，这种竞争更频繁。

解法：所有涉及“读-改-写”的操作，必须用Redis Lua脚本封装。例如，更新Beta参数的Lua脚本：

-- keys[1] = "exp1:banner_a", argv[1] = reward (0 or 1) local hash = redis.call("HGETALL", KEYS[1]) local alpha = tonumber(hash["alpha"]) or 4.0 local beta = tonumber(hash["beta"]) or 96.0 if tonumber(argv[1]) == 1 then alpha = alpha + 1 else beta = beta + 1 end redis.call("HSET", KEYS[1], "alpha", tostring(alpha), "beta", tostring(beta)) return {alpha, beta}

在Python中调用：r_params.eval(lua_script, 1, key, reward)。Lua在Redis中是原子执行的，彻底杜绝了竞态条件。这个教训告诉我们：在分布式系统中，“看起来安全”的操作，往往是最危险的。

5.4 坑四：“先验太强，算法拒绝学习新世界”——当业务发生结构性变化

去年双十一前，我们为一个新上线的“直播专享价”商品卡片做了MAB实验。按历史数据，设定了较强的先验Beta(20, 980)（CTR≈2%）。结果活动开始后，由于巨大的流量涌入和用户兴奋感，真实CTR飙升至8%。但算法花了整整36小时，才将流量重心从旧版卡片切到新版。复盘发现，先验强度20+980=1000，意味着算法需要约1000次新数据，才能让后验均值从2%移动到5%，而初期的8%数据被强大的先验“拉”得很慢。

解法：引入先验衰减（Prior Decay）机制。不是固定先验，而是让先验强度随时间或数据量衰减。例如，定义一个衰减因子γ（如0.999），每次更新后，将先验强度乘以γ。或者更激进的：当检测到全局CTR突变（如过去1小时均值比过去24小时均值高200%），则主动将所有arm的α₀, β₀重置为(1,1)，让算法“一键重启”。我们在双十一预案中就启用了后者，一旦监控到突变，5秒内完成重置，确保算法始终紧贴最新现实。