干货分享|A/B实验在字节跳动推荐系统中的应用与实践

本文源自火山引擎A/B测试团队资深研发团队内部演讲，以下为分享实录：

1. 什么是A/B实验？

AB实验，也被称为A/B测试，是一种统计学方法，通过对比两个或多个版本的事物，以确定哪个版本对目标的影响更大，目前在各大互联网公司有非常广泛的应用。例如在字节跳动，2023年中数据显示，A/B测试平台目前服务了500多条业务、在线上开的实验总量超过了240万，每天新增的实验数有4000余个，同时线上运行的实验数有5万余个 。

2. 什么是推荐系统？

随着移动互联网的快速发展，用户规模和网络信息量都得到了爆炸式增长。在此背景下，信息过载导致用户产生选择焦虑，推荐系统也就应运而生。

可以说，推荐系统本质上是在用户需求不明确的情况下， 为用户从海量的内容中寻找其感兴趣的内容的技术手段，通过结合用户的基础信息（地域，年龄，性别等）、用户的历史行为（点击、播放、购买等）、以及内容本身的特征（分类、标签、价格等），利用机器学习技术构建用户的兴趣模型，再叠加一定的推荐策略，实现为用户提供精准的个性化内容服务，使流量得到充分的利用，最大限度地提高内容转化效率及用户获取信息的效率。

3. 推荐架构

虽然不同推荐产品的体验和调性差异很大，但其背后的推荐系统总体技术方案大同小异，一般都由在线服务和离线处理两个模块组成：

3.1 在线服务

在线服务是为用户提供内容的个性化推荐服务。其对效率要求比较高，需要在百毫秒级完成从海量备选集中筛选用户感兴趣的内容，一般由召回、粗排、精排、重排四个阶段组成。这四个阶段所处理的内容量由多到少、处理复杂度由简单到复杂、内容和用户的相关性由弱到强，随着阶段的推进逐步完成推荐。

3.2 离线处理

离线处理辅助于在线服务，能够为在线服务提供内容基础和数据基础：

• 用户发布的内容经过审核、打标签以及内容运营，筛选合规、优质内容，构建推荐内容池

• 对用户行为数据进行处理和计算，生成样本和特征，更新和优化推荐模型；

• 结合A/B实验分流结果和用户行为的打点上报，用于指标计算和实验分析，也可搭建指标报表和dashboard，观测如dau、用户时长等核心指标的走势

推荐系统中经常会有推荐算法、策略、特征、功能、UI的迭代，特别是推荐算法。但由于现在广泛应用深度学习模型，本身具有很强的黑盒属性。所以在进行调整后，用户体验如何，是否向着预期的方向发展，都无法通过经验来判断，需要通过A/B实验量化指标变化才能进行评估及后续优化。

因此，可以说A/B实验和推荐系统是相生相伴的，有推荐系统就必须有A/B实验。接下来就重点介绍A/B实验在持续改进推荐系统中的应用以及分享一些实践经验。

4. 使用A/B实验改进推荐系统

4.1 A/B实验的流程

一个标准的A/B实验包含分析并提出假设、实验设计、实验上线、实验观测、实验决策五个环节：

• 基于分析提出假设：即在业务体验和数据分析过程中，基于发现的问题和可优化点，提出某个实验的假设。例如某信息流推荐开发同学，在体验业务时提出一个假设：如果用户在消费视频时若能产生点赞关注等互动行为，可提升用户黏性从而提升用户留存。

• 实验设计：确定实验策略、实验目的、实验对象、实验时长等。例如基于上面的假设，可设计针对低活跃用户，优化推荐模型的实验策略；目标是提升用户留存率；实验时长则建议设置14天以上，覆盖两个完整周，以此消除工作日与周末用户消费视频的差异及波动。

• 实验上线：按照设计的实验方案，实现业务逻辑并进行线上实验。且需要在上线前通过设置实验白名单，体验并检查实验逻辑是否符合预期。

• 实验观测：实验上线后，观察实验指标的变化趋势。这个阶段也可以抽样检查实验用户的推荐结果和行为数据，进一步验证实验逻辑是否正确。

• 实验决策：根据实验结果决定下一步计划，若实验效果为负向，则应关闭实验或进行相应的数据分析并迭代优化实验策略后重新上线实验；若实验有显著正向，则可全量发布，且在全量发布时建议同步创建反转实验，以便观察实验的长期收益。因为一般A/B实验的周期相对比较短，短期的正向收益也可能是由于新算法或新策略的新鲜度较高带来的，因此可通过反转实验来检验长期收益是否符合预期。实验上线后，也可以进行进一步的数据分析发掘是否有新的A/B实验点，以此循环往复。

在字节跳动，每天都运行着大量的推荐实验，以下分享几个我们积累的实践经验。

4.2 A/B实验在推荐系统的应用方向

推荐系统的本质是连接内容和用户，这样就构成了<内容，推荐系统，用户>的三元组，A/B实验也是围绕这个三元组展开。内容侧，可以进行内容池优化、内容打标优化、视频封面模型的优化等；用户侧，可以通过A/B实验实现功能优化、性能优化、UI改进等；而在推荐系统方面，可A/B实验的维度更多，例如多路召回优化、粗排和精排模型迭代升级优化、模型多目标融合优化、重排多样性/兴趣探索优化、广告收入优化等等，可以说，在推荐系统中，万物皆可A/B实验。

需要指出的是，在进行内容侧的A/B实验时，例如信息流产品可能会做作者发布视频奖励、视频清晰度调整等，改变的是内容侧的属性，但我们通常观察的是大盘用户侧的指标。在进行这类实验时，建议转化为用户侧实验并辅助观测内容侧指标来评估，权衡用户侧和内容侧的综合收益后再决策是否上线。

比如视频带货推荐中，商家分润规则调整仅对实验用户生效，通过对比实验组与对照组的指标差异评估对大盘的影响的同时，可以创建并观察商家入驻率等内容侧指标的变化。在大盘收入指标不变、商家入驻率指标有提升，甚至大盘收入指标微跌、商家入驻率显著提升的情况下，都可以发布上线。

另外，A/B实验上线后，我们会频繁地查看分析实验指标。有的实验在开启后前几天可能出现指标下跌，这种情况下不建议立即关闭实验，因为我们遇到过很多这种指标开始下跌、后续慢慢回涨的情况，比如在内容多样性策略实验中，当增强兴趣探索后，短期可能会因为探索而出现用户不感兴趣的内容变多导致消费时长下跌，但从长期来看。探索到更多用户兴趣后，用户黏性更强，用户消费时长也会慢慢回涨，且更有益于平台生态。因此在面对实验开始指标下跌的情况，一般还是建议继续实验至少一周以上，覆盖观察一个完整周后再进行评估会更加准确。

在查看指标时，也建议多关注实验指标下钻分析结果，例如关注不同性别、不同年龄层用户的指标变化，有的产品也会关注不同活跃度用户、特别是新用户和低活用户的指标变化趋势，因为这类用户更决定了产品未来的增长。在DataTester，可以借助用户属性过滤功能，查看指标的下钻分析数据。

4.3 实验参数在A/B实验的作用

在推荐系统中，我们常常会想看不同算法叠加不同的策略或功能的效果，这时可以借助实验参数来做功能组合的A/B实验。实验参数，是对A/B实验中实验版本的补充，一般是一个功能控制配置项，需要开发人员获取并解析后才能生效。

借助实验参数，一方面能区分对照组和实验组，另一方面通过合理的实验配置的设计，可以在不增加开发工作量的情况下进行更灵活的实验。目前火山引擎DataTester支持Number、String、Boolean、Json类型的实验参数配置，可以帮助用户实现不同维度的A/B实验。

以视频带货推荐场景为例，我们假设商品内容展示时机不同会对用户的视频消费时长和电商GMV产生影响，因此设计如下实验：

• 对照组：视频开始播放时立即展示商品卡片

• 实验组1：视频播放5秒后展示商品卡片

• 实验组2：视频播放10秒后展示商品卡片

我们可以设计实验参数goods_card_show_time=0/5/10分别对应对照组、实验组1和实验组2，然后在代码中解析goods_card_show_time参数并实现视频播放{goods_card_show_time}秒后展示商品卡片，即可完成上述实验。假如后续要实验“视频播放8秒后展示商品卡片”的效果，则无需修改代码，仅需要创建一个实验参数为goods_card_show_time=8的实验即可，甚至可以创建更多组不同参数值的实验后取最优的goods_card_show_time值全量发布。

需要注意的是，从开发同学的视角看，实验参数是一个功能控制配置，因此在进行A/B实验参数设计的时候需要避免一个误区：不要按实验设计来设计实验参数。例如如下场景：

一个不恰当的实验参数设计方案是枚举所有实验组（如下interact_optimize_mod的设计），此时功能的控制只能通过硬编码来处理，如果涉及到实验方案调整，或者其他实验需要复用某些功能，则都需要另外开发。

合理的实验参数应该按功能控制维度来设计，针对上面的实验，可以设计如下控制参数，然后通过这些参数的组合达到实验的效果：

对照组：无推荐模型优化，不展示互动引导

实验组1：优化推荐模型互动目标，不展示互动引导

实验组2：优化推荐模型互动目标，且在视频播放剩10秒时展示互动引导5秒

实验组3：优化推荐模型互动目标，且在视频播放剩15秒时展示互动引导8秒

通过以上设计的实验参数，便可实现多个功能维度的A/B实验。可以说，合理利用实验参数，往往可以达到事半功倍的效果，这一点在移动端APP实验中尤为重要，因为APP一般发版周期长，无法做频繁变更，而有了实验参数，就可以在不发版的情况下，开启多组不同参数的A/B实验，筛选最优参数组合在线上生效。

4.4 全量发布A/B实验

当A/B实验决出优胜组后，我们便可以将优胜组的策略全量发布。那么如何发布呢？

一种做法是修改代码，将优胜组策略对应的参数对全量用户生效，同时将对照组下线，这种方式的缺点是每次全量发布都需要修改代码后发布上线，流程复杂增加了出错风险，特别是如果要全量发布客户端实验，考虑到客户端发版除了开发测试，还需要应用商店审批上线，这种方式将会严重影响迭代效率，并且这种方式难以回滚，在新特性上线时可能会造成上下游服务负载过高而影响用户体验。

基于以上可能存在的问题，一般的做法是会开发一套配置系统，将A/B实验控制逻辑配置化，当需要全量发布实验时，只需要全量发布对应实验配置即可，若发布时出现异常可通过回滚配置恢复服务。

在DataTester，除了能够为用户提供A/B实验的能力，还能为用户提供FeatureFlag功能，以满足A/B实验全量发布的诉求，用户无需再开发上述的配置服务。基于FeatureFlag功能，全量发布实验时，用户仅需要将实验配置固化为Feature，然后发布Feature即可，同时此功能支持自定义流量满足灰度发布的需求，保护上下游服务，出现异常时也支持配置秒级回滚，高效保障服务安全上线。

以上就是DataTester在推荐系统改进中的实践及其经验总结，希望对大家有所启发。火山引擎DataTester作为火山引擎数智平台VeDI旗下的核心产品，源于字节跳动长期的技术和业务沉淀。目前，DataTester已经服务了上百家企业，包括美的、得到、博西家电、凯叔讲故事等知名品牌，助力企业在业务增长、用户转化、产品迭代、策略优化以及运营提效等环节科学决策，将成熟的“数据驱动增长”经验赋能给各行业。