推荐效果线上评测：AB测试平台的设计与实现

作者：放按钮.PM；原文标题：《推荐效果线上评测：AB测试平台的设计与实现》

推荐语：当你发现别人都在加薪，唯独你停滞不前的时候，你是否反问过自己，是不是懂的少了？如果你还停在大数据开发只懂sql语句的话，那你离被淘汰不远了，除非你的领导对大数据非常了解，也清楚你这块的难度，大部分互联网公司的领导，都是一人挂多个部门，所以你的部门大领导不一定认为你的sql有多么牛逼，所以你就要什么多学，别人开会讨论策略和模型如果你都听不懂，不妨静下心来学习一下，提升自己的实力。br

第一篇

1、背景

在推荐系统中，评测效果，除了离线的AUC，更合理的方法是通过线上真实的AB测试，来比较策略的效果。

AB测试来自医学的双盲实验，在双盲测试中：

1. 病人随机被分成两组，在不知情的情况下，分别服用安慰剂跟测试用药

2. 经过一段时间后，再来比较两组病人的表现是否有显著差异。

从而决定药物是否真的有用。

互联网行业的AB测试类似，对于一个策略/UI，在同一个时间维度，保证其他体验一致的情况下，分析实验组跟对照组的区别，以便做决策判断。

因为经常接触AB测试，以及看到了国内一些公司的AB平台不同的设计实现方法，整理一下AB测试平台相关知识。

2、具体说明

本文从以下方面讨论。

• 2.1 单层实验：方法以及问题

• 2.2 多层重叠实验架构：一切从google的论文说起

• 2.3 国内公司的解决方案文章分享

2.1单层实验

2.1.1 方法

顾名思义，单层实验的模式是：

1. 把所有的用户放在一起，有相互独立的用户标识（比如cid，uid，cookis等）

2. 以某种分流的方法（比如随机），给每个实验组，分配一定的用户。

3. 每个实验分到的用户正交

2.1.2 问题

单层实验一定程度说是可行的，但是会遇到一定的问题

1. 扩展性差，只能同时支持少量实验。但是以数据驱动的业务，需要极快的创新速度，大量的创新需要被测试，会严重delay业务。

2. 如果在单层同时进行多个实验，实验之间不是独立事件，并行的时候，同一个策略，只能进行一个实验，如果多个并行支持，无法实现。不同策略之间也有影响。

3. 流量饥饿问题：假设我们整体用户要做5个实验，如果前2个实验占据了大部分的流量，后面的3个实验就有很少的流量可以供使用，甚至没有流量可用。

4. 流量偏置问题：假设上游的实验把所有的年轻人都获取了，下游的实验，没有年轻人的样本。导致有偏差。

2.2 多层重叠实验架构：一切从google的论文说起

Google在2010年的KDD上公布了自己的分层实验框架，之后，国内的大部分的AB测试平台，都是基于此论文建设。首先分享一下这篇论文的英文版以及中文翻译版

• 中文版：https://www.csdn.net/article/2015-01-09/2823499

• 英文版：https://research.google.com/pubs/pub36500.html

2.2.1  设计实验平台的目标

• 更多：多个实验可以并行扩展，而且能够保证灵活性

• 更好：保证实验合理，不合理实验不能上，合理实验出bug能及时止损，保证每个实验有公平合理的比较

• 更快：能够快速创建实验，而且能够快速提供结果分析

2.2.2 手段

思考：保留单层实验框架易用，快速的优点的同时，增加可扩展性，灵活性，健壮性。

核心思路：将参数划分到N个子集，每个子集都关联一个实验层，每个请求会被N个实验处理（每层一个实验），每个实验都只能修改自己层相关联的参数（在参数子集中的参数），并且同一个参数不能出现在多个层中。

2.2.3 具体设计：分流模型

名词概念解释：

• 域（domain）：划分的一部分流量

• 层（layer）：系统参数的一个子集

• 实验（exp）：在一个域上，对一个或者多个参数修改，改变请求路径的过程

简单的理解，我们把流量在纵向上的划分叫做域（domain），流量请求从纵向判断先开始。然后我们把横向上的划分，称为层（layer），在同一个层，不同策略（exp）是隔离开的，一个策略（exp），可以被多个层控制，每个层都可以有多个实验。流量在每个层都会被重新打散。

流量在每个层被打散的方法，称之为 分配函数，google在论文里提到了四种（因为是基于PC搜索，所以用户标识是cookie）。支持多种流量分配类型的主要目的一方面是为了保持处理的一致性，另外也希望覆盖到所有的情况。

1. user_id mods = f（user_id,layer）%100

2. cookies mods= f（cookies,layer）%100

3. cookie-day mods= f（cookie-day,layer）%100

4. random=f(random)

这其中有两种特殊的情况：

1. condition：用户样本有特殊要求，在通过分配函数分配到一部分流量后，部分实验可以通过 分流条件（condition）仅分配特定条件的流量给实验或域，以达到更高效利用流量的目的。典型的条件比如：国家（google是全球的产品），语言，浏览器等。分配条件一般直接在实验或者域的配置中指定。

2. trigger：实验触发条件有特殊要求，仅在某些请求下触发，而这种实时计算类的没有办法事先分配好，只能通过程序自己判断。这种情况下，重要的工作是记录事实（factual，当实验被触发）跟反事实（counter-factual，当实验可以被触发）。反事实在对比实验中记录。

下图是整个AB实验用户实验列表Re的判断流程

2.2.4 具体设计：具体实验流量分配

有了分流模型，流量分配函数，我们在做实验的时候，还需要注意，AB平台能够很好的指导业务，准确的进行实验。

准确的进行实验，有几个关键事项：1）实验合理性   2）代码准确性&数据准确性  3）实验结果置信保证   4）实时监控。

1）实验合理性

google的做法是，有一个实验委员会，每次实验的时候，实验者提供一个简单的checklist，checklist中需要保护以下的问题答案：

• 基本的实验特性：比如实验测试什么，它们的假设是什么

• 实验创建：要修改哪些参数，每个实验分别要测试什么，在哪一层

• 实验的流量分配跟触发条件：使用什么分配类型，什么分配条件，在多大比例的流量触发实验

• 实验分析：关注哪些指标，实验要检测的指标敏感度是什么

• 实验规模跟时间跨度：保证给定的流量，有足够统计量来保证指标敏感度

• 其他补充：比如是否需要预时期跟后时期来保证（预时期跟后时期的意思就是，在实验前或者后，观察实验组与对照组的天然差异）

2）代码准确性&数据准确性

一些基础的检查，比如 是否所有必填字段都填写了，对照组跟实验组是否流量一致大小，是否跟别的实验有冲突等

3）实验结果置信保证

这节很重要，个人感觉是分流模型外，论文里最重要的部分。首先，很多人分配流量都是凭借直觉，或者有多少就用多少。最后的数据结果不置信，反而对产品有负向伤害。简单的说，这种 “抽取样本来估计全局”的实验，需要保证”样本的结果能够代表全局”，即样本量应该让实验有足够的统计意义。

一个实验的有效规模，google定义为：

为了求N，需要有几个先验的参数：

• ①实验所关注的指标是什么

• ②对于每个指标，想改变的敏感度 ，比如：想检测2%左右的波动

• ③针对每个指标，一个抽样单元（N=1） 样本标准误差为s，则实验大小为N的标准误差为
  如果实验组大小=对照组大小，比如实验组=2N，那么2N必须大于等于才能满足最小变化检测需求。其中 16，是根据置信度（通常取95%，），期望的统计功效（通常为80%，）决定。
  谷歌在每一层共享一个对照组，被多个实验共享。如果对照组比实验组大很多，系数就可以用10.5，而不是16.（不用取2N，取N）
  真实实验中，不同指标，不同分配方法有不同的s，google提供了一个工具，可以让实验者权衡流量大小与敏感度。为了保证置信区间的正确性，一直进行一组 同质测试，来检测指标的自然变化。

4）实时监控

google有实时监控，检测某些指标超出正常值范围的波动。

2.2.5 具体设计：实验数据分析工具

1. 正确的计算跟显示置信区间

2. 很好的图形化界面

3. 很好的理解数据，比如：辛普森悖论的观察跟理解

4. 一致性有唯一的实现保证，比如 使用相同的spam过滤器

5. 讨论会，专门的讨论解读数据

2.2.6 最后

最后总结的时候比较散，写的太长了，不想写了。

有一个比较想说的，就是google把历史的ab测试总结起来，做了一个知识库，这个挺好，有助于总结学习。

然后即使是google，也经常有错误，比如日志经常不对。

 

2.3 国内公司的解决方案文章分享

大部分国内公司的解决方案，都是根据google的论文做的，但是在分层上，有根据业务划分的，有根据用户画像划分的（取决于实际的AB测试环境要求）。

这篇文章更多偏向google的理论解读，下一篇文章将基于国内目前有的公司的架构以及goole的理论，详细介绍一下AB测试平台的一种工程实现。

收集的一些国内公司的文章介绍如下：

• 大众点评：Gemini

• 微博广告：Faraday

• 阿里的一个文章

• PPTV

最后，分享一个网站

• http://exp-platform.com/