作者 | gongyouliu

编辑 | gongyouliu

我们在上一章《推荐系统的效果评估》中提到了推荐系统在线评估的重要性。我们知道了在线评估的指标才是最真实、最可靠的。一般来说，当算法工程师想优化某个推荐算法时，会构建一个新的推荐算法，如果通过离线评估指标发现效果比线上的算法好，这时该怎么做呢？是直接全盘替换线上算法吗？

答案显然是否定的。直接取代是非常粗暴的做法，我们不能保证新算法的在线指标一定比老算法好（上一章我们讲过，离线指标好的算法在线指标不一定好）。比较好的做法是同时将这两个算法上线到产品中，通过运行一段时间来对比线上指标，看看具体的指标数据才最终决定新算法是不是更好，这就是本章要讲的AB测试。

本章我们对AB测试做一个比较全面的介绍，我们会从什么是AB测试、AB测试的价值、推荐系统的AB测试实现方案等3个方面来讲解AB测试技术。

AB测试在推荐系统算法迭代中起着非常关键的作用，是推荐系统非常核心的支撑能力，因此作者花一章的篇幅来详细介绍AB测试相关的原理和技术。希望本章能够帮助读者更好地理解AB测试的原理和价值，帮助读者在具体业务场景中用AB测试这个有效的工具来提升推荐系统的用户体验，为业务创造更大的价值。

16.1 什么是AB测试

AB测试的本质是分离式组间试验，也叫对照试验，在科研领域中已被广泛应用(它是药物测试的最高标准)。自2000年谷歌工程师将这一方法应用在互联网产品以来，AB测试越来越普及，已逐渐成为衡量互联网产品运营精细度的重要体现。

简单来说，AB测试在产品优化中的应用方法是：在产品正式迭代发版之前，为同一个目标制定两个(或两个以上)可行方案，将用户流量分成几组，在保证每组流量在控制特征不同而其他特征相同的前提下，让用户分别看到不同的设计方案，根据几组用户的真实数据反馈，科学地帮助我们进行产品迭代决策(比如你想优化登录页面的海报颜色，觉得蓝色比红色好，就可以针对两组用户，一组海报用红色，一组海报用蓝色，其他都相同，进行AB测试)。AB测试原理如下面图1。

AB测试是一种科学的评估手段，具备概率统计学理论的支撑。这里我简单解释一下原因。概率论中有一个中心极限定理，意思是独立同分布的随机变量的和服从正态分布。对于AB测试，我们比较的是两组样本的平均表现，AB测试保证A、B两组某个因素不一样(这个就是我们要验证的优化点)，A、B两组其他很多未知影响因素一样，当A、B两组样本足够多时(这时不同样本的同一因素是独立同分布的随机变量)，这两组样本相同因素产生的效果是满足同一正态分布的，因此可以认为对要验证的变量的作用是相互抵消的，这样待验证因素(即我们的控制变量)的影响就可以比较了，因此我们就可以通过AB测试实验来验证优化是否有效。

16.2 AB测试的价值

最近几年增长黑客的理念在国内互联网盛行，有很多这方面的专业书出版，很多公司甚至设立了CGO(首席增长官)的高管职位。增长黑客思维希望通过从产品中找到创造性的优化点，利用数据来驱动产品优化，提升用户体验及收益增长，最终达到四两拨千斤的效果。随着公司业务规模及用户的增长，利用数据来驱动业务发展越来越重要。增长黑客本质上就是一种数据驱动的思维，并且有一套完善的技术管理体系来科学地驱动业务发展，而这套体系中最重要的一种技术手段就是AB测试。

AB测试可以很好的指导产品迭代，为产品迭代提供科学的数据支撑。具体来说，AB测试的价值主要体现在如下4个方面。

16.2.1 为评估产品优化效果提供科学的证据

前面说过，AB测试是基于概率论与统计学原理之上构建的科学的测试技术，有很强的理论依据。

AB测试也经历过多年实践的检验，被证明是有效的方法。前面提到过AB测试是药物测试的最高标准，在药品制造业得到了很好的使用和验证。同时，各大互联网公司都大量使用AB测试技术，为整个互联网的发展提供了很好的榜样和示范作用。

16.2.2 借助AB测试可以提升决策的说服力

因为AB测试是有统计学作为理论基础，并且又有工业上的实践经验作为支撑，利用AB测试得到的结论具备极大的说服力。因此，在用数据说话上，大家在意识形态上更容易达成一致，这样就可以让产品迭代更快的推行下去。

16.2.3 AB测试可以帮助提升用户体验

任何涉及到用户体验、用户增长相关的优化思路都可以通过AB测试来验证，通过验证得出有说服力的结论，从而推动产品朝着用户体验越来越优的方向发展。

16.2.4 AB测试可以帮助提升公司变现能力

搜索、推荐、广告、会员等涉及到收益相关的产品及算法都可以通过AB测试来验证新的优化思路是否可以提升盈利性指标。其中盈利性指标可以根据公司业务和发展阶段来定义。

总之，一切涉及到用户体验、用户增长、商业变现的产品优化都可以借助AB测试技术，驱动业务做得更好，AB测试是一种科学的决策方式。

既然AB测试这么重要，大家肯定想知道怎么在具体的业务场景中实现AB测试的能力。由于本章主要是讲解推荐系统的AB测试，因此，我们在下面一节来具体讲解推荐系统的AB测试实现方案。

16.3 推荐系统的AB测试实现方案

基于16.1节中提到的AB测试的实现原理，再结合推荐系统的特性，我们给出一种通用灵活的推荐系统AB测试的实现方案，具体实现原理及业务流程见下面图2，下面我们结合该图来具体说明其中的思路与方法。

在进行详细讲解之前，我们先对图中4个重要概念进行说明，方便大家更好地理解图中流程及后面的细节讲解。

• uid：用户的唯一识别id
• biz：业务标识，代表什么场景的推荐算法，比如首页个性化、详情页关联推荐等
• alg：具体的算法标识，比如协同过滤、FM、深度学习等
• url：某个算法的服务接口URL

16.3.1 AB测试的核心模块

上图下面绿色虚线圈中的两个模块就是AB测试必须具备的两个核心模块，下面我们来详细说明各个模块的功能。

• AB测试管理模块

AB测试管理模块的目的是让产品经理、运营人员或者算法开发人员方便快速地创建AB测试实验，增加新的AB测试分组，调整AB测试方案各个分组的比例，让AB测试运转起来。同时也用于管理AB测试平台用户创建、权限管理，让用户具备编辑、拷贝、使用AB测试实验的能力，做到高效易用。

为了方便操作，实验管理模块一般会提供一个UI界面，具体的管理界面怎么做，可以根据具体业务来实现，一般也不会很复杂，下面图3就是作者曾经负责的一家公司的AB测试管理界面（其中最下面的流量比例就是各种算法对应的比例，图3这里更复杂一点，将不同召回、排序算法的组合看成是一个完整的推荐算法）。

简单的AB测试管理模块也可以是一个简单的配置文件，如下面图4。最好将这个配置文件做成一个web服务，可以在浏览器中访问、修改，这样更加方便。其实最简单的方式是将这个配置文件作为下面要讲到的AB测试分组模块代码工程中的一个配置文件，这个时候修改就比较麻烦了，只能算法工程师或者运维人员操作（一般产品、运营是不会修改代码的），修改完成后还需要对AB测试分组服务进行重新发布。

• AB测试分组模块

分组模块的目的是根据各种业务规则，将用户流量分为A、B两组(或者多组)。可以说分组模块是AB测试最核心的模块，好的AB分组方案可以让流量分配得更均匀随机。复杂的AB测试场景需要具备根据用户、地域、时间、版本、系统、渠道、事件等各种维度来对请求进行分组的能力，并且保证分组的均匀性和一致性。本章我们只考虑对uid进行分组的最简单的AB测试场景，在一般情况下也够用了。

分组模块的难点是怎么分组才能保证用户是真的按照AB测试管理人员配置的各个算法的比例进行分组的。这里我简单说明一个非常简单的实现方案，这个方案可以大致保证按照管理人员指定的比例进行分组，并且同一个用户每次分到的组是不变的（只要分组比例不变）。假设有两个推荐算法进行AB测试，分别是alg_1、alg_2，配置的比例是60%：40%。那么可以将用户id先进行hash（字符串有hashcode方法可以获得对应的hash值）获得一个长整形数值d，然后计算d % 100，根据计算得到的值来进行分组。如果 d % 100 ∈ （0, 59），那么该用户就属于alg_1这一组，如果 d % 100 ∈ （60, 99），那么该用户就属于alg_2这一组。

上面这个方法也可以非常简单地推广到多个算法进行AB测试的场景。这里提一下，利用用户id进行hash可能得到的结果分布不够随机，导致最终alg_1：alg_2 与 60%：40%差距较大，这时可以自己构造一个定制化的hash函数，具体怎么构造这里不详细讲解，读者可以思考一下。

AB分组模块一般是通过提供一个接口来实现，方便推荐系统web接口服务来调用，获得用户对应的具体的分组（算法）。下面图5就是作者之前实现的一种AB分组服务接口，这个接口将产品中所有的推荐算法业务（biz）对应的分组都展现出来了。

16.3.2 AB测试的业务流程

上面对AB测试的核心模块进行了简单介绍，下面对上面图1中标注数字的核心流程进行说明，方便大家基于数据流向更好地理解推荐系统AB测试的流程。图中大部分大家应该能够看懂，下面我们综合讲解几个核心流程（按照图中数字从小到大的顺序，这个顺序也代表了真实的数据流向顺序）。

16.3.2.1 新服务注册备案

这对应图1中的-1代表的阶段。这个阶段说的是算法工程师已经实现了一种新的推荐算法，并且将这个算法部署好了，现在可以用于具体的推荐业务进行AB测试了。这时就需要将该算法相关的信息注册到注册中心，方便其它模块访问（类似产品生产好了就可以上架了，这样顾客就可以购买了）。当然，更简单的AB测试系统可以不需要注册中心，可以通过文档系统（甚至是口头沟通）来同步信息。

16.3.2.2 配置待AB测试的算法比例

这对应图1中的0代表的阶段。这个阶段说的是AB测试管理人员想进行新的AB测试了，他需要配置某个推荐场景（比如首页个性化推荐）中各个进行AB测试的算法的比例。一般新上线的算法，我们需要配置比较低的比例（比如5%），避免新算法上线效果不好，对用户体验和收益带来影响。

当某个推荐场景的新AB测试配置好了，AB测试就生效了。之后如果有新用户来使用APP的该推荐场景，这时就进入了在线AB测试阶段。

上面我们讲解的两个阶段（对应图1中标注-1、0的两个阶段）其实是AB测试的准备阶段，下面将要讲解的才是真正的AB测试过程。

16.3.2.3 用户使用产品上的推荐服务

这对应图1中的1、2两个阶段。这时用户就会请求推荐系统web服务接口，这个接口的目的是将该用户的最终推荐结果反馈给用户，这样用户就可以在产品的界面上看到给他的推荐结果了。请求的过程涉及到很多服务访问，具体我们在下面16.3.2.4、16.3.2.5两小节中说明。

16.3.2.4 推荐接口获取用户关联的算法

这对应图1中的3、4、5、6四个阶段。推荐web服务接口将uid、biz传递给AB测试分组模块，分组模块基于AB测试配置人员配置的该场景下各种算法的比例计算出该用户对应的算法（alg），然后从服务注册中心获得二元组对应的算法url，最后将返回给推荐系统web服务接口。这一步获取的主要信息只有两个：一个是具体的算法alg、一个是算法对应的接口url。

16.3.2.5 推荐接口将推荐结果反馈给用户

这对应图1中的7、8、9、10四个阶段。当推荐系统web服务接口有了alg、url，它就知道怎么为该用户去请求对应的推荐列表（这里的url对应图1上面一排最右边的推荐系统服务A或者推荐系统服务B，具体要看该用户被分配到哪个测试组，这里的推荐系统服务A、B一般只会返回包含推荐item_id的列表，并不会包含其它额外信息）。当获得了该用户的推荐列表后，推荐系统web服务会将推荐列表组装成合适的数据结构并将最终的推荐结果在APP上展示给用户，这样用户就能看到自己的推荐了。

推荐系统web服务接口返回的推荐结果会包含各种信息，比如物品的id、标题、海报图、等等。总之，用户在界面上看到的与推荐的物品相关的一切信息都会包含在接口返回的JSON结构体中。下面图6就是返回的一种可行的数据结构。

图6接口返回参数中包含biz、alg两个字段，它们是用于识别具体的推荐场景（如首页信息流推荐、详情页关联推荐等）和具体的推荐算法（如内容推荐、矩阵分解、协同过滤等）。包含biz、alg主要目的是希望当用户在前端访问推荐系统时，可以将相关信息进行埋点（至少要将uid、biz、alg、item_id、time、时长等核心信息埋点），埋点后可以将信息回收至大数据平台（数据回收相关的知识点我们在第3章中进行过完整的介绍，这里不赘述），方便后续对AB测试的效果进行评估，获得推荐系统的在线评估指标（具体的评估方法及指标，参考第15章的介绍）。

到这里我们就介绍完了AB测试的具体实现方案和流程，整个过程和逻辑还是非常简单的，主要涉及到的是一些工程方面的工作。在公司中，一般AB测试系统是工程团队来实现的，算法工程师并不会参与，但推荐算法工程师知道AB测试具体的实现原理可以更深刻地理解怎么对推荐系统进行AB测试和评估。

需要注意的是，在对推荐系统进行AB测试过程中，我们需要关注如下3点，才能让AB测试能力得到正确的运用，更准确地衡量各个算法的效果。

• AB测试一定要在统计学意义上“显著”

AB测试是有成本的，AB测试的目的是得出正确的结论来优化产品体验、提升收益转化，所以AB测试指标的提升一定要是统计学上“显著”的，是真实有效的。一般来说，当每个分组的用户规模足够大（每个分组至少几百个用户）、测试时间足够长（至少一周以上）、分组算法足够随机这3个条件都具备时，AB测试的结论在统计意义上是显著的。具体怎么利用严格的数学方法计算显著性，大家可以查阅相关资料，这里不展开讲。

• 损失最小性原则

我们做AB测试的目的是优化用户体验，但是有可能我们认为有效的优化在真实上线时反而是不好的，为了避免这种情况发生对用户体验和收益的负面影响。我们在做AB测试时尽量用小的流量来测试新的算法或者优化点，当数据证明优化点是有效的，才逐步推广到所有用户（如按照5%->10%->20%->50%->80%->100%这样的阶段拓展新算法的占比）。实验过程中如果数据不好，最多只影响到测试的这批少量用户，不至于产生大的负面影响。

• 处理好AB测试与缓存的关系

互联网公司通过大量采用缓存技术来加速查询，同时提升整个系统的高性能、高可用能力。当为某个推荐模块做AB测试时，特别要考虑缓存情况，这时可能会出现问题。这里举个例子说明，如果某个用户开始是老算法策略，如果在做AB测试时，给用户分配到了新算法策略，如果有缓存的话，那么用户会从缓存获取到老算法策略，这时跟实际上用户分配到的新算法策略不一致。最简单的解决办法是通过配置推荐系统web服务取消缓存，每次请求都回源，这样就不会出现这个问题了。

总结

AB测试对于推荐系统在真实业务场景中提升用户体验、产生业务价值是非常重要的，正是AB测试（配合推荐系统效果评估）才让推荐系统成为一个可以不断迭代的、数据驱动的闭环系统。

本章我们介绍了推荐系统AB测试的相关知识点，大家知道了什么是AB测试，AB测试的价值以及对于推荐系统具体怎么做AB测试，这些知识点是推荐算法工程师必须要掌握的。本章的重点是AB测试的2个核心模块（其中怎么进行AB分组是需要了解具体实现细节的）和AB测试的业务流程，有兴趣的读者还可以参考本章提供的思路自行实现一套简单的AB测试系统。