亚马逊支付用上下文老虎机做个性化，七周AB测试一组转化率提升高个位数
Amazon Payments在Amazon SageMaker AI上运行多目标上下文多臂老虎机，七周线上A/B测试中一组客户最终漏斗转化率提升高个位数百分比，另一组没有改善。团队称问题出在内容，而不是模型。
AI解读：生成式AI让批量生产个性化内容变得又快又便宜，但新的难题是：面对这么多版本，该给每位访客展示哪一个，以及要花多久才能学会答案。Amazon Payments的做法是用多臂老虎机边服务边学习，在七周线上A/B测试里，一组客户的最终漏斗转化率提升高个位数百分比，另一组则没有跑赢原有页面。
他们选的是上下文老虎机里的LinUCB，不按人工划分的固定人群分组，而是把支付行为、交易构成等信号编成特征向量，给每次访问单独调整探索力度。平台用的是Amazon SageMaker AI批处理架构，每周跑一次任务，更新模型并把每位客户的推荐结果写进低延迟键值存储供实时查询。
最有意思的失败案例是第二组客户：模型几乎试遍了整个内容池，仍然找不到能击败静态页面的组合，审批环节的回退还达到统计显著。团队明确说这不是模型的问题，而是内容池里根本没有赢家——老虎机负责选，但候选内容的质量得靠人加生成式AI一起补。
Amazon Payments将基于AI的个性化应用到产品获取漏斗，使用的是运行在Amazon SageMaker AI上的多目标上下文多臂老虎机（contextual multi-armed bandit）。在一项为期七周的线上A/B测试中，当前观察到一个人群的最终漏斗转化率取得高个位数百分比的相对提升，另一个人群相较现有体验没有改善。团队称问题出在内容，而不是模型。
生成式AI已经能够快速、低成本地生产大量个性化内容。Amazon Payments此前的文章介绍过如何在Amazon Bedrock上用生成式AI大规模产出符合品牌规范与护栏的个性化内容。新的挑战变成了选择问题：在所有选项中，该给每位客户展示哪一个，以及需要多久才能学到答案。
多臂老虎机（MAB）是一种为“选项多、流量有限”场景打造的强化学习方法。它一边学习哪个选项表现最好，一边继续服务客户；把每个内容变体视为一条“臂”，让它们在真实流量中竞争，并逐步把曝光移向表现好的臂，同时保留一部分流量继续测试其余的臂。这就是利用（服务当前最佳臂）与探索（尝试把握较小的臂以收集证据）之间的基本权衡。因为老虎机从不停止这两件事，它会随着新变体的加入持续改进，也不必等测试结束才行动。A/B/n测试仍有其位置，但生成式AI加快了可学习变体的增长，团队预计老虎机会扮演越来越重要的角色。
在Amazon Payments，团队选择了UCB策略，即选择“估计奖励加不确定性奖励”最高的臂，天然平衡利用与探索。其确定性选择规则让每次曝光决策都可审计、可复现。不过，标准老虎机为全体受众学习一个最佳臂；个性化需要依据访客是谁来调整，这正是上下文老虎机提供的。
分段老虎机为每个手工定义的组各跑一个实例，但分组是任意的，且每组都需要自己的流量。上下文老虎机直接以特征向量（属性的数值表示）为条件，因此在一个上下文中学习到的模式可以迁移到所有相似的访问，无需为每组单独分配流量。其生产系统用行为信号（支付行为、交易构成及类似特征）构成上下文向量来表示每位客户，取代固定分群。实体ID（如entity_id这样的不透明键）只用于把学到的推荐路由回正确的访客，绝不作为模型输入。
他们选择了LinUCB（Li等人，2010年提出）。虽然存在更新的老虎机算法，LinUCB仍是久经考验的方法：计算高效、可审计（确定性选臂），并且能在有限冷启动数据下自然处理较大的臂空间。其关键假设是某条臂的期望奖励是上下文向量的线性函数，这使它能够泛化到未见过的访客。
LinUCB如何按特征学习，以及如何优化整条漏斗
每条臂在每次曝光时维护两个持续更新的账本：b是奖励账本（哪些访客信号带来了转化，b += reward · x）；A是经验账本（该臂见过哪些访客，A += x·xᵀ，从单位矩阵开始）。奖励除以经验得到估计值（θ = A⁻¹·b）。经验账本也会随着证据增加而缩小探索奖励。臂的评分公式为：score(a, x) = θᵀ·x + α · √(xᵀ · A⁻¹ · x)，前一项是估计，后一项是不确定性奖励。奖励是依上下文而变的：对某条臂很少见到的访客类型奖励较大，对常见的访客类型奖励较小。普通老虎机以单一的全局速率探索，而LinUCB为每个被评分的访客调整探索程度。
该用例中的客户旅程包含三步：申请开始、提交、批准。目标因此是多阶段结果，而非单一指标。这些阶段并不同步变化：为“开始”优化的内容往往吸引广泛受众，但批准取决于报价是否真正适合申请人。孤立优化某一阶段可能损害另一阶段，团队称之为跷跷板问题。反过来，只优化批准会让模型缺少信号，因为批准既稀少又有延迟。
他们的做法是同时优化整条漏斗：为每个阶段（开始、提交、批准）各跑一个LinUCB模型，再通过线性组合合并它们的UCB分数：selected_arm = argmax_a [ w_start · UCB_start(a, x) + w_submit · UCB_submit(a, x) + w_approve · UCB_approve(a, x) ]。阶段权重可按业务优先级赋值，或通过单独的校准步骤学习得到。团队使用了大致相等的权重。在实践中，可以在模型预热后给批准更高的权重，或者在权衡确实存在争议时使用帕累托前沿。
内容池、批处理架构与部署细节
老虎机的效果取决于臂池的质量。核心思路是用少量经过审核的构建块组合出大量变体。内容由两类部分组成：行业主题图片和利益点导向的标语。臂空间是这些部分的笛卡尔积，每条臂是一个（图片、标语）配对，因此数量适中的构建块就能产出大量不同的页面变体。图1展示了构建块被逐一审查后组合成完整臂池。
在规模上保证安全，靠的是几层控制。首先是审查“零件”而不是“组合”：与其审查每一种可能的组合（随着空间增长并不现实），团队预先审查每个单独的构建块。由于构建块的数量保持少而可审，组合却快速增长，审查零件一次即为整个组合空间提供保证。其次是设计系统保证一致性：把内容锚定到已批准的颜色、布局、组件和模式，使变体在构造上就保持视觉一致、符合品牌，而不是靠运气。
在初始部署中，构建块是在人工细致监督下策划的，即使生产过程中有生成式AI工具辅助。团队看到了大幅扩大零件池（文本、图像、布局）的明确潜力，这会拓宽老虎机的选择空间。随着池子增长，老虎机与生成式流水线形成良性循环：生成式AI拓宽候选集，老虎机找出对每位访客产生最强结果的组合。
Amazon SageMaker AI是支持模型全生命周期的AI模型开发服务，也是端到端流水线背后的主要AWS服务，统一提供模型训练、批处理、版本控制和监控。团队采用批处理架构有两个原因：选择问题本质上是离线的（反馈在数天内累积），以及观察发现访客选择行为的变化不够快，不需要实时更新模型。一个定时SageMaker AI Processing作业读取上一周期的反馈，更新模型，并为下一周期写出新推荐。
具体流程是：每周一次SageMaker AI批作业从Amazon Simple Storage Service（Amazon S3）读取客户结果，更新老虎机模型，并把每位客户的推荐发布到低延迟键值存储。从每周频次开始是一个保守的基线；一旦模型展示出稳定提升，提高频率是直接可行的。可能延迟数天的批准反馈会纳入后续批次。
数据收集方面，客户曝光和结果（开始、提交、批准）在会话结束时记录，并作为观测流入Amazon S3。模型更新与推理方面，SageMaker AI Processing作业运行Python入口点：它从S3加载最新模型状态（自动发现最新日期前缀，因此多次运行之间无需重新配置），把数据拆分为反馈行和推理行，在反馈上以增量方式更新模型，并对每个潜在客户评分以选出一条臂。团队使用Processing作业是因为该工作负载是单一、自包含的步骤，既更新又评分，并带有自定义S3 I/O；Training作业和Batch Transform都不太贴合这一模式。
持久化与输出方面，作业把更新后的模型状态写回S3（放在新的日期化路径中，自带版本历史和便捷回滚），同时写入观测和臂内容。每位客户的推荐（每个客户映射到所选臂）发布到低延迟键值存储（例如Amazon DynamoDB），为实时流量提供服务。
模型预热方面，团队从一段随机内容分配期对每个模型进行热启动，这提供无偏数据，让老虎机在没有选择偏差的情况下初始化信念，并从第一天起更高效地使用探索预算。推理扩展方面，为大量潜在客户评分的计算量很大，两项优化使其保持在预算内：预计算臂矩阵的逆（同一批次内不变），以及用Python的multiprocessing.Pool把潜在客户集合分块并行评分。
页面服务路径很简单，因为重活已在批作业中完成。个性化页面由低延迟键值存储（例如Amazon DynamoDB）交付，其中保存每位客户预计算的推荐。客户到来时，页面按实体ID查询一次，渲染预计算臂的内容，没有实时模型推理。对于需要实时评分的场景——上下文只在请求时才知道，或内容必须在会话内自适应——Amazon SageMaker AI实时推理端点是自然替代方案，它在低延迟API背后托管模型。
该设计还有一个值得一提的稳健性：如果某位访客没有推荐，页面会回退到默认静态体验，因此没有客户会比基线更差。这种回退限制了下行风险，也让增量上线更安全。
生产中学到的经验
模型设计方面：当人群差异很大时，应分开训练。如果受众分成特征或转化率显著不同的群体，单一共享模型会让更大或噪声更多的群体主导学习内容。为每个群体训练一个模型，给予各自的特征集和臂空间，能让每个受众的信号清晰呈现。
要优化整条漏斗，而不是代理指标。最重要的设计决策是走向多目标。单阶段老虎机会让团队在上游指标上“获胜”，却损害最终决定业务价值的下游指标。团队在部署前通过实证验证了这一点：针对单一漏斗阶段优化的策略，总会在其他某个地方产生至少一个负向提升。多目标表述是唯一能在三个阶段同时保持非负估计的方法。如果业务目标与第一次点击相隔数步，就把所有步骤都编码进奖励。
内容策略方面：选择算法只解决了一半挑战，内容池的质量同样重要。在他们的A/B测试中，一个人群在三个漏斗指标上均看到方向性正向提升，最终阶段目前取得高个位数百分比的相对提升。对第二个人群，模型探索了大部分臂池，仍未找到任何能击败静态页面的组合；提升为负，且审批环节的回退达到统计显著。这不是模型失败。充分的探索可以确认内容池中没有赢家。如果老虎机广泛探索各条臂仍无法击败对照（静态体验、没有老虎机），那么需要重新审视的是臂，而不是算法。这正是生成式内容流水线变得不可或缺的地方：它们扩大并刷新老虎机抽取的池子，让模型更有可能找到获胜组合。
评估方面，离线评估和A/B测试回答不同的问题。离线重放（在留出数据上把策略与随机分配比较）告诉你“模型是否胜过随机分配”，作为初步验证。但只有常规A/B测试（老虎机个性化对比静态基线）才能判断真实效果。
另一个值得考虑的做法是把基线也做成一条臂。把现有默认体验作为臂之一，意味着如果对某位客户没有个性化臂能击败默认，UCB会自然倾向于服务默认，从而限制系统可能回退的幅度。