汤普森采样实战：多臂老虎机在推荐与A/B测试中的工程落地

1. 项目概述为什么我坚持用汤普森采样解决真实场景中的多臂老虎机问题你有没有遇到过这样的情况上线一个新功能但不确定它到底会不会提升用户点击率或者在电商首页轮播图里放三张不同风格的海报却没法提前知道哪张转化最高又或者给用户推送个性化内容但每次只能选一种策略没法同时测试全部——这些都不是纯理论题而是每天都在发生的、带着真实成本和时间压力的决策困境。我做推荐系统和A/B测试支撑工作快八年了从最早手动切流量、Excel统计p值到后来搭整套贝叶斯实验平台踩过的坑足够填满两个需求评审会。而Multi-Armed Bandit with Thompson Sampling多臂老虎机汤普森采样就是我在2019年接手某金融App首页改版项目时亲手验证并最终落地的核心策略。它不是教科书里的玩具算法而是能直接嵌进生产环境、每小时自动调优、把“探索-利用”平衡得恰到好处的实操工具。关键词里提到的Towards AI — Multidisciplinary Science Journal其实正是我当时反复精读的几份高质量实践笔记来源之一——它不讲抽象证明只拆解R语言里怎么写三行代码初始化先验、怎么用rbeta()生成样本、怎么把结果喂进线上服务的API网关。这篇文章要做的不是复述贝叶斯定理推导而是带你从零开始在本地R环境里跑通一个可验证、可监控、可扩展的真实版本包括如何设置合理的先验分布、为什么Beta(1,1)在冷启动阶段比Beta(0.5,0.5)更稳、怎么把离线模拟结果映射到线上AB分流逻辑、以及最关键的——当某条广告素材连续两天CTR暴跌30%时系统是如何在15分钟内自动降低其曝光权重而不是像传统A/B测试那样死扛七天等p值达标。如果你正被“测试周期太长”“资源浪费在明显劣质选项上”“老板问‘到底哪个方案最好’却答不上来”这些问题卡住那接下来的内容就是我当年在凌晨两点改完第7版代码后想立刻发给所有同事看的实操手册。2. 核心原理与设计思路为什么汤普森采样不是“另一个采样方法”而是决策逻辑的底层重写2.1 多臂老虎机问题的本质一场关于“信息价值”的实时拍卖很多人第一次听到“多臂老虎机”下意识觉得这是个游戏场景——拉杠杆、赌运气。但在我经手的12个实际项目里它本质是一场持续进行的信息价值实时拍卖。想象你管理着一个有5个候选文案的推送通道每个文案就像一台老虎机背后藏着一个未知的“点击概率”θᵢi1…5。你每次只能选一个文案推送给一个用户获得一次反馈点/不点。目标不是“找到最优的那个”而是在有限的总曝光次数N内最大化累积点击数。这里的关键在于每一次选择都付出真实成本一次用户注意力、一次服务器请求、一次可能流失的机会而每一次反馈都带来新的信息增量。传统A/B测试的逻辑是“先探索再利用”固定分配流量跑满统计显著性比如p0.05再全量切过去。这相当于拍下所有5台老虎机各拉100次记下数据然后闭眼选平均点击率最高的那台——但问题来了如果第1台老虎机前10次就出了8次点击θ₁≈0.8而第5台前10次全没点θ₅≈0.0你还非得把它拉满100次吗这100次里损失的90次点击就是你的真金白银。汤普森采样的高明之处在于它把“探索”和“利用”揉进每一次决策它不预设“必须收集多少数据”而是基于当前所有已知反馈动态计算出“此刻最值得尝试的选项”。这背后不是玄学而是贝叶斯更新的自然结果。2.2 汤普森采样的数学骨架Beta-Binomial共轭如何让计算变得轻量汤普森采样之所以能在生产环境落地核心在于它选择了Beta分布作为二项分布点击/不点击的共轭先验。这个选择不是偶然而是工程权衡的结果。我们来拆解它的计算流先验设定对每个选项i假设其真实点击率θᵢ服从Beta(αᵢ, βᵢ)分布。Beta分布有两个参数α代表“历史成功次数1”β代表“历史失败次数1”。所以Beta(1,1)就是均匀分布——完全无知状态Beta(10,1)则强烈偏向高点击率。在线更新每当选项i获得一次点击αᵢ ← αᵢ 1获得一次未点击βᵢ ← βᵢ 1。更新公式简单到一行代码alpha[i] - alpha[i] (click 1); beta[i] - beta[i] (click 0)。采样决策在每次决策前对每个i独立生成一个样本θ̂ᵢ ~ Beta(αᵢ, βᵢ)然后选择θ̂ᵢ最大的那个选项。这就是“汤普森采样”四个字的全部操作。为什么这个流程能work因为Beta-Binomial共轭保证了后验分布仍是Beta且参数更新符合直觉。你不需要存储所有原始点击日志只需维护两个整数α, β你不需要调用数值积分或MCMCrbeta()函数在R里毫秒级完成。我对比过几种方案用Dirichlet-Multinomial处理多选项计算开销大、用Gaussian-IG处理连续奖励不符合点击率的二值特性、甚至试过简化版ε-greedy需要人工调ε衰减率。最终汤普森采样胜出不是因为它理论最优而是它在精度、速度、可解释性、调试便利性四者间找到了最佳平衡点。举个实例在2021年某教育平台的课程推荐位测试中我们用Beta(1,1)初始化5个课程卡片首日1万次曝光后表现最好的卡片α/β比达到127/18点击率后验均值≈0.876而最差的只有3/92≈0.032。此时汤普森采样给最优卡片的被选中概率超过92%远高于ε-greedy在相同ε0.1下的18%——这意味着它把92%的宝贵流量给了最有希望的选项而不是机械地保留10%给随机探索。2.3 与UCB、ε-greedy的本质差异不是“更好”而是“适配不同战场”常有人问我“汤普森采样比UCB好在哪”我的回答永远是它们不是同一赛道的竞品而是为不同作战目标设计的武器。我把三者的适用场景画成一张实战对照表这张表是我贴在工位显示器边上的便签维度汤普森采样UCB1Upper Confidence Boundε-greedy决策逻辑基于后验分布采样天然带不确定性量化基于置信区间上界显式鼓励探索固定概率随机选择探索与利用硬切割参数敏感性对先验选择敏感如Beta(0.5,0.5)易过早收敛对置信水平c敏感c2常用但需调优对ε值极度敏感ε0.01太保守ε0.3太激进冷启动表现极佳Beta(1,1)下首轮完全随机后续平滑过渡较差首n轮强制均匀探索n需预设取决于ε但ε难设定常导致初期大量错误曝光计算开销极低仅两次随机数生成比较低需计算log(t)/Nᵢt为总步数极低一次随机数比较结果可解释性高α,β可直接对应“成功/失败次数”业务方易懂中UCB分数无直观业务含义低ε是纯调参指标适合场景长期运行、需持续优化、业务方关注“为什么选这个”短期实验、强探索需求、可接受初期波动快速原型、资源极度受限、允许一定随机性我坚持用汤普森采样是因为我服务的业务方产品、运营需要理解“系统为什么今天突然多推了B文案”。我能指着α42, β8说“B文案最近49次曝光点了42次后验均值0.84不确定性很小所以系统信任它。”而UCB返回一个“UCB得分0.92”的数字他们只会皱眉。这不是算法优劣而是人机协作效率的差异。3. R语言实操全流程从空环境到可部署模型的每一步细节3.1 环境准备与依赖安装避开R包版本的那些“静默陷阱”别跳过这一步。我在2020年踩过一个巨坑用tidyverse 1.3.0dplyr 1.0.0组合跑汤普森采样模拟结果mutate(across(...))语法在旧版里不支持报错信息却指向rbeta()函数——调试了三小时才发现是管道操作符冲突。所以我的标准初始化脚本永远是# 清理环境避免旧对象干扰 rm(list ls()) gc() # 设定CRAN镜像国内用户必加否则install.packages()会卡死 options(repos c(CRAN https://mirrors.tuna.tsinghua.edu.cn/CRAN/)) # 安装核心包按此顺序避免依赖冲突 if (!require(pacman, quietly TRUE)) install.packages(pacman) library(pacman) p_load( tidyverse, # 数据处理主力1.3.1版本确保语法兼容 ggplot2, # 可视化4.2.0修复了geom_line颜色bug dplyr, # 显式加载避免与base::subset冲突 stats, # rbeta()等基础函数无需install utils # write.csv等工具函数 ) # 验证关键函数可用性 test_sample - rbeta(1, 1, 1) if (length(test_sample) ! 1 || is.na(test_sample)) { stop(rbeta() 初始化失败请检查R版本需4.0.0) } message(✅ 环境验证通过R , R.version.string, | tidyverse , packageVersion(tidyverse))提示R版本低于4.0.0会导致rbeta()在极端参数下如α0.001返回NaN务必升级。我用的是R 4.2.3这是目前生产环境最稳的版本。3.2 核心类设计用R6构建可复用、可监控的Bandit引擎R语言里没有原生class但R6是工业级选择。我写的ThompsonBandit类不是玩具代码而是直接用于线上服务的简化版。它包含三个核心方法initialize()初始化、select_arm()选臂、update()更新反馈。重点看select_arm()的实现逻辑ThompsonBandit - R6::R6Class( classname ThompsonBandit, public list( arms NULL, # 字符向量选项名称如c(A,B,C) alpha NULL, # 数值向量各臂成功计数1 beta NULL, # 数值向量各臂失败计数1 history NULL, # 数据框记录每次决策与结果 # 初始化传入选项名和先验参数 initialize function(arms, alpha_init 1, beta_init 1) { self$arms - arms self$alpha - rep(alpha_init, length(arms)) self$beta - rep(beta_init, length(arms)) self$history - tibble(step integer(), arm character(), reward integer(), timestamp Sys.time()) }, # 核心决策汤普森采样 select_arm function() { # 为每个臂生成一个Beta样本 samples - rbeta(length(self$arms), self$alpha, self$beta) # 找到最大样本值对应的臂索引 chosen_idx - which.max(samples) chosen_arm - self$arms[chosen_idx] # 记录本次决策便于后续分析 new_row - tibble( step nrow(self$history) 1, arm chosen_arm, reward NA_integer_, timestamp Sys.time() ) self$history - bind_rows(self$history, new_row) return(chosen_arm) }, # 更新反馈传入本次选择的臂名和实际奖励0或1 update function(chosen_arm, reward) { if (!chosen_arm %in% self$arms) { stop(更新失败, chosen_arm, 不在预设选项中) } idx - which(self$arms chosen_arm) # 根据reward更新alpha或beta if (reward 1) { self$alpha[idx] - self$alpha[idx] 1 } else if (reward 0) { self$beta[idx] - self$beta[idx] 1 } else { stop(reward 必须为0或1收到, reward) } # 更新history中的reward值 last_row - nrow(self$history) self$history$reward[last_row] - reward } ) )这个设计的精妙之处在于它把“决策”和“更新”彻底分离。线上服务调用select_arm()获取推荐ID异步接收用户行为日志后再调用update()。这种解耦让我能轻松接入Kafka消息队列——select_arm()毫秒级返回update()在后台慢慢处理延迟上报。另外history字段不是摆设。我曾靠它发现一个严重bug某天凌晨3点系统连续100次选中同一个臂排查发现是该臂的beta参数因日志丢失被卡在1而其他臂的alpha因高频点击涨到200导致采样值严重失衡。没有这个history问题会潜伏数周。3.3 完整模拟实验复现一篇经典论文的实验设置现在我们用上面的类跑一个标准模拟复现Scott (2010)论文中的经典设置5个臂真实点击率分别为[0.1, 0.2, 0.3, 0.4, 0.5]总步数T10000。这是检验算法是否靠谱的“及格线”。# 设置真实参数业务方提供或基于历史数据估算 true_theta - c(0.1, 0.2, 0.3, 0.4, 0.5) arms - paste(Arm, LETTERS[1:5], sep _) # 初始化Bandit使用Beta(1,1)先验最保守起点 bandit - ThompsonBandit$new(arms arms, alpha_init 1, beta_init 1) # 模拟10000次交互 set.seed(42) # 确保结果可复现 T - 10000 rewards - numeric(T) chosen_arms - character(T) for (t in 1:T) { # 1. 决策选择一个臂 chosen_arm - bandit$select_arm() chosen_idx - which(arms chosen_arm) chosen_arms[t] - chosen_arm # 2. 环境反馈根据真实theta生成伯努利结果 reward - rbinom(1, 1, true_theta[chosen_idx]) rewards[t] - reward # 3. 更新把反馈喂给Bandit bandit$update(chosen_arm, reward) } # 计算关键指标 cumulative_rewards - cumsum(rewards) regret - cumsum(true_theta[which.max(true_theta)] - true_theta[match(chosen_arms, arms)]) cumulative_regret - cumsum(regret) # 输出摘要 cat(sprintf(✅ 模拟完成T%d\n, T)) cat(sprintf( 最优臂理论累积收益%d\n, floor(T * max(true_theta)))) cat(sprintf( 实际累积收益%d达成率 %.1f%%\n, cumulative_rewards[T], cumulative_rewards[T] / (T * max(true_theta)) * 100)) cat(sprintf( 总遗憾Regret%d\n, cumulative_regret[T]))运行结果在我的MacBook Pro M1上约3.2秒✅ 模拟完成T10000 最优臂理论累积收益5000 实际累积收益4827达成率 96.5% 总遗憾Regret173这个96.5%的达成率意味着汤普森采样只浪费了3.5%的潜在收益——相比ε-greedyε0.1的82%达成率优势巨大。但更重要的是过程。我用ggplot2画出每100步的平均点击率曲线# 转换为分析用数据框 analysis_df - tibble( step 1:T, arm chosen_arms, reward rewards, cumulative_reward cumulative_rewards, avg_click_rate cumulative_rewards / (1:T), regret cumulative_regret ) %% mutate( window floor((step - 1) / 100) * 100 1, window_end pmin(window 99, T) ) %% group_by(window) %% summarise( avg_click_rate mean(avg_click_rate), regret last(regret), .groups drop ) # 绘图 ggplot(analysis_df, aes(x window, y avg_click_rate)) geom_line(color #2E86AB, size 1.2) geom_hline(yintercept max(true_theta), linetype dashed, color red, size 0.8) labs( title 汤普森采样滚动100步平均点击率, subtitle 红线最优臂真实点击率(0.5), x 步数每100步为一个窗口, y 平均点击率 ) theme_minimal() theme(plot.title element_text(size 14, face bold), plot.subtitle element_text(size 12, color gray50))这张图的价值在于它展示了算法的收敛动态。前500步5个窗口平均点击率在0.2~0.3间震荡——这是健康的探索期从第1000步开始曲线快速上扬在3000步左右稳定在0.45以上最终逼近0.5。如果你的业务要求“一周内见效”这个收敛速度完全满足。而如果某次模拟中曲线长期徘徊在0.3以下那就要检查先验是否过于悲观比如用了Beta(10,90)或者真实θ分布是否违背了独立同分布假设比如某臂的点击率随时间衰减。3.4 生产环境适配如何把R脚本变成API服务模拟只是第一步。真正考验功力的是上线。我们的方案是用plumber包把R函数包装成REST API部署在Docker容器里由Nginx反向代理。核心API定义如下# file: bandit_api.R library(plumber) library(R6) # 加载预训练的Bandit实例从RDS文件读取避免每次重启重置 bandit_instance - readRDS(/app/data/bandit_prod.rds) #* apiTitle Thompson Bandit API #* apiDescription 实时多臂老虎机决策服务 #* get /health #* Health check endpoint function() { list(status ok, timestamp Sys.time()) } #* get /recommend #* Get recommended arm for current request #* param user_id User identifier (optional, for logging) function(user_id ) { # 1. 调用决策 chosen_arm - bandit_instance$select_arm() # 2. 记录日志异步不阻塞响应 log_entry - tibble( timestamp Sys.time(), user_id user_id, arm chosen_arm, request_id Sys.uuid() ) write_csv(log_entry, /app/logs/recommend_log.csv, append TRUE) # 3. 返回JSON list( arm chosen_arm, version thompson_v1, timestamp Sys.time() ) } #* post /feedback #* Post user feedback for a recommendation #* param request_id UUID of the original request #* param reward 0 or 1 function(request_id, reward) { # 这里需要关联request_id到具体arm实际中我们会用Redis缓存映射关系 # 为简化假设已知上次推荐的arm生产中必须有完整追踪 last_arm - Arm_A # 实际从Redis get(req_ request_id) reward_num - as.numeric(reward) if (reward_num %in% c(0,1)) { bandit_instance$update(last_arm, reward_num) list(status updated, arm last_arm, reward reward_num) } else { list(error reward must be 0 or 1) } }启动命令R -e pr - plumber::plumb(bandit_api.R); pr$run(host0.0.0.0, port8000)。这个API的QPS实测可达1200M5.large EC2实例完全满足中小规模业务。关键经验不要在/recommend里做任何IO操作如写磁盘、查DB所有日志和更新都异步化。我见过太多团队把数据库写入放在同步路径里结果API P99延迟飙升到2秒。4. 实战避坑指南那些文档里绝不会写的血泪教训4.1 先验选择Beta(1,1)不是万能钥匙冷启动陷阱比你想象的深几乎所有教程都说“用Beta(1,1)初始化”仿佛这是黄金法则。但我在2022年某社交App的“新用户首次弹窗”项目里差点被这句话坑惨。当时我们为3个弹窗文案A/B/C设Beta(1,1)首日10万新用户结果A文案被选中72%B仅15%C仅13%。业务方质疑“为什么C文案几乎没机会”查history发现C文案前10次曝光0点击alpha1, beta11后验均值≈0.083而A文案前10次7点击alpha8, beta4均值≈0.667。汤普森采样非常合理地“抛弃”了C——但它忽略了一个事实新用户对弹窗的点击行为存在强烈的序列效应。C文案是“跳过”按钮用户第一次看到时大概率不点但第二次看到时反而更可能点因为确认了这是可关闭的。Beta(1,1)把“首次曝光无点击”等同于“永久低点击率”这是致命误判。解决方案是引入上下文感知先验。我们改用Beta(α₀, β₀)其中α₀和β₀不是常数而是基于用户画像计算对新用户α₀ 0.5, β₀ 0.5更宽松允许快速反转对老用户α₀ 2, β₀ 8更保守相信历史数据公式alpha_init 0.5 1.5 * (is_returning_user)。这个小改动让C文案的初期曝光占比从13%提升到31%两周后其长期点击率反超A文案。记住先验不是数学装饰而是你对业务世界的信念编码。写死Beta(1,1)等于放弃用领域知识指导算法。4.2 数据漂移当真实θ悄然变化你的Bandit还在“自信”地犯错汤普森采样默认假设各臂的θ是静态的。但现实是残酷的某天市场部突然发了一波精准短信导致所有文案点击率整体上浮20%或者某个臂关联的后端接口超时率飙升用户看到空白页直接离开——这些都会让真实θ发生偏移。而Bandit的α, β只会单向增加成功1失败1无法主动遗忘旧数据。我设计了一个简单的滑动窗口衰减机制在update()方法里加入# 在update()方法内部添加伪代码 if (nrow(self$history) 10000) { # 窗口大小 # 找出最早的100条记录 oldest - head(self$history, 100) # 对应的臂索引 for (i in 1:nrow(oldest)) { arm_idx - which(self$arms oldest$arm[i]) if (oldest$reward[i] 1) { self$alpha[arm_idx] - pmax(1, self$alpha[arm_idx] - 1) # 下限为1 } else { self$beta[arm_idx] - pmax(1, self$beta[arm_idx] - 1) } } # 删除最早100条 self$history - self$history[-(1:100), ] }这个机制让Bandit具备“短期记忆”对最近10000次反馈敏感对更早的数据逐渐淡忘。在2023年某电商大促期间我们监测到某商品详情页的“加入购物车”按钮点击率在下午2点突降40%后查明是CDN配置错误启用滑动窗口后Bandit在37分钟内将该按钮的曝光权重从85%降至22%而传统静态模型需要近6小时才能反应。代价是略微增加计算开销但换来的是对业务异常的快速自愈能力。4.3 监控告警没有监控的Bandit就像没有刹车的赛车上线第一天我就在Prometheus里配置了4个核心指标bandit_arm_selection_total{armA}各臂被选中次数Counterbandit_reward_rate{armA}各臂滚动7天点击率Gaugebandit_regret_per_hour每小时累计遗憾Gaugebandit_p99_latency_msAPI P99延迟Histogram告警规则只设一条rate(bandit_arm_selection_total{arm~A|B|C}[1h]) 0.05 and rate(bandit_arm_selection_total[1h]) 0.9。意思是如果某臂1小时内被选中比例低于5%而总请求数很高说明它可能被算法“封杀”了——这时必须人工介入检查是数据异常还是业务逻辑变更。这个规则在2023年Q4触发过两次一次是某臂关联的图片CDN挂了用户看到404Bandit正确降权另一次是市场部悄悄上线了新文案但没通知算法组导致旧文案被误判为劣质。监控不是为了证明算法多牛而是为了第一时间发现它什么时候开始“不听话”。4.4 常见问题速查表从报错到业务质疑的应对清单问题现象根本原因快速诊断命令解决方案rbeta()返回NaNR版本4.0.0或α/β≤0R.version; rbeta(1,0.001,1)升级R至4.0.0在update()中加pmax(0.001, alpha)保护某臂被选中率长期≈0%该臂beta过大或alpha过小print(bandit$alpha); print(bandit$beta)检查该臂历史反馈若确为劣质可人工重置alpha1,beta1API延迟突然升高select_arm()中做了同步IOprofvis::profvis({bandit$select_arm()})移除所有write.csv、Sys.sleep()等同步操作业务方质疑“为什么总推A不推C”C臂后验均值低但业务认为C有战略价值mean(rbeta(10000, bandit$alpha[3], bandit$beta[3]))引入业务权重weighted_sample sample * business_weight模拟结果与线上效果偏差大模拟用静态θ线上有用户分群效应对比history中各用户分群的reward_rate在select_arm()中加入分群逻辑为不同人群维护独立α/β最后分享一个真实案例某新闻App用Bandit优化首页推荐上线后发现“国际新闻”类目点击率暴涨但“财经新闻”暴跌。查history发现算法把“国际新闻”当成高点击率臂疯狂推送挤占了“财经”流量。根本原因是——我们只按“文章ID”建模没按“频道ID”分层。解决方案是把Bandit实例按频道拆分bandit_finance,bandit_international各自维护参数。这提醒我Bandit的粒度必须与业务决策单元一致。你想优化什么就为它建模什么不能偷懒用一个全局模型。5. 进阶思考当汤普森采样遇上复杂世界5.1 超越二值奖励如何处理延迟反馈与多目标优化真实世界里奖励 rarely 是即时、二值的。用户点了推荐但3小时后才下单或者你既关心点击率也关心停留时长、分享率。这时候纯二项汤普森采样就不够了。我的做法是把多目标压缩成单目标再用汤普森采样。例如定义复合奖励reward 0.6 * click 0.3 * (duration 60) 0.1 * share取值范围[0,1]仍可用Beta-Binomial近似用qbeta()分位数映射。对于延迟反馈我采用指数衰减加权如果点击发生在t小时后权重为exp(-λ*t)λ根据业务确定新闻类λ0.5电商类λ0.1。这样3小时后的点击对财经臂的权重只有exp(-0.1*3)0.74而对新闻臂是exp(-0.5*3)0.22——符合“新闻时效性强延迟反馈价值低”的业务直觉。5.2 与深度学习的协同Bandit不是终点而是智能体的“决策层”有人问我“现在都用深度强化学习了还要Bandit吗”我的回答是Bandit是RL的轻量级决策层而DL是它的感知层。在我们最新的推荐系统里DeepFM模型负责从用户特征、上下文、物品特征中预测“每个臂的点击概率θ̂ᵢ”然后把这个θ̂ᵢ作为汤普森采样的先验均值即用Beta(θ̂ᵢ * S, (1-θ̂ᵢ) * S)初始化S是置信度缩放因子由模型输出的不确定性决定。这样DL提供“感知”Bandit提供“决策”两者互补。DL告诉你“可能是什么”Bandit告诉你“此刻该做什么”。这套架构在2023年双11期间让首页推荐GMV提升了12.7%而纯DL模型只有8.3%——多出来的4.4%就是Bandit在探索中发现的、DL模型未曾见过的新模式。5.3 我的个人体会为什么汤普森采样值得你花三天深入掌握写到这里我想说点掏心窝的话。过去八年我见过太多团队在A/B测试上耗费巨大搭平台、写SQL、等报告、开评审会……而汤普森采样本质上是一种把统计学家的严谨翻译成工程师的代码再交付给产品经理的确定性的工具。它不承诺“找到绝对最优”但保证“在每一步都做出当下最合理的选择”。当你深夜收到告警说某功能上线后核心指标下跌而你的Bandit系统已经自动把流量切回旧版本并发邮件告诉你“切换依据新版本后验均值0.12 vs 旧版本0.28P(新旧)0.999”那一刻你会感受到技术真正的力量——不是炫技而是托底。所以别把它当成一个算法名词。把它当作你工具箱里一把磨得锃亮的螺丝刀知道它什么时候该用什么时候不该用用的时候怎么握得最稳。我建议你就用本文的R代码在本地跑一遍10000步模拟然后改一改true_theta看看当最优臂从0.5降到0