Tag: A/B Testing

对照实验系统论文阅读笔记（二）

~ azurezyq ~ 2 Comments

这一次我们阅读和翻译关于分层实验平台的来自Google的论文Overlapping experiment infrastructure: more, better, faster experimentation （没有找到特别官方的链接，学术搜索能搜到）。

 

Google也大量需要在线的对照实验来做决策，几乎所有的微小的改变，都需要通过实验决定。相比众多的实验，流量的数量已经成为了瓶颈。为了更高效、更准确地做更多的实验，这篇文章设计了分层实验平台。同一份流量可以同时做多个实验。

 

更多、更好、更快

 

实验平台不仅能同时运行多个实验，也要具有灵活性：不同的实验可以使用不同的配置、不同的流量大小。不正确的实验不应当被允许运行，正确但影响很差的实验应当被迅速发现并中止。实验的设置和进行应当容易并迅速，即使不是工程师也可以做（不需要写代码）。实验指标应当实时可用，这样实验就可以被迅速评估。简单的重复实验应当很容易做，最理想情况下，实验平台可以用做灰度发布（gradually ramping up）。

 

发展到这一步，不仅需要工程上的架构设计，也需要相应的工具和对使用流程的控制。

 

背景

 

这里说的分层实验平台只用在Web互联网服务上，不包括Google Apps、Chrome等（我们可以想象一下，实际上，非Web服务也可以做对照实验，但是如果要做重叠的实验则有一定的困难）。

 

与之前在（一）中提到的对照实验系统一样，做对照实验完全由参数来控制。使用参数使得实验容易创建，因为他们可以是易读的文字，不是代码。同样，数据文件比程序文件更容易快速部署。

 

在最初，Google使用了一种可以称作“单层实验平台”的架构。一个流量只能做一个实验。首先分配基于Cookie划分流量的实验，然后再划分基于随机分配流量的实验。这种架构不足以支持足够多的实验。

 

分层架构

 

layer

 

我们将参数划分为若干个子集，每个子集之内的参数是可能互相影响的，也就是说不能同时做实验的；子集之间的参数则是不会互相影响的（正交的）。这种划分可以来自于检查，也可以来自于过往实验的结果。用每一个子集对应一个抽象的“层”的概念。同时，把对流量的每一个划分抽取对应一个抽象的“领域”（domain）的概念。一个领域里可以有多层，一个层里也可以有多个领域。如图。而这个图也可以看做最宏观上Google Web的层和领域的划分。

 

虽然看起来有点复杂，但这个划分有很多好处。一个非重叠实验领域，可以方便地做影响非常大的实验（可能实验的参数跨遍各层，只能在这个领域做）；它允许在两个领域中对相同的参数做不同的划分；我们也可以比较容易地把一个参数从一层中移到另一层中（如果发现这样更有利于流量的利用）。

 

注意到图(c)中增加了发布层Lanuch Layer。Lanuch Layer是一种特殊的层，它们必须运行着100%的流量（它们所在的领域称default domain，不能与其他domain纵向切分），同一个参数最多出现在一个Launch层中，同时最多出现在一个普通层中。Launch中参数的取值，可以被下面普通实验层中进行的实验的参数取值所覆盖。

 

发布层的典型应用是，每一个待发布的参数版本，新建一个发布层，而当它稳定后，删掉这个发布层。由于发布层在default domain中，因此它可以用来最终验证实验间的相互影响。

流量的划分不仅有基于cookie、random的，也会根据实验的要求有更灵活的其他方式，比如userid，query-string等。而不同的划分方式可能会在领域与层之间造成饥饿和有偏的问

题，为此，需要给每个领域和层指定流量划分方式，对已经被上层抽取造成的有偏的流量要加以标识，排除掉它们以避免有偏。

 

分层实验框架的工程架构基本就是如此，而这篇论文的后半部分还用了很大的篇幅讨论前面说到的”工具和使用流程控制”，我们在下一篇阅读笔记中讨论。

 

对照实验系统论文阅读笔记（一）

~ azurezyq

对于互联网公司来说，使用对照实验系统（常被称作A/B Testing，Controlled Experiments，与科学研究中常用的对照实验的原理是完全一致的）来做很多决定都是非常有效和必要的。我们有理由相信大规模地、有效地应用对照实验，是Google公司和百度广告系统取得成功的重要原因之一。：）

这篇论文Practical Guide to Controlled Experiments on the Web是2007年Kohavi等人在KDD发表的论文，是比较早期的介绍在互联网系统中应用对照实验的文章，这次我们从这篇论文的翻译和学习笔记开始介绍对照实验系统。

优势

使用对照实验系统被称作“听用户的意见”，这与用户调查不同，用户自己也未必清楚他们的行为在指定的情况下会是什么样，或者他们的体验是好是坏。然而在互联网上面，他们在用鼠标投票，依次做决定比听从“专家”的意见要靠谱和快速。论文中把公司里的专家的意见称作“High Paid Person’s Opinion”，取了个简称叫HiPPO（河马）。-_-|| 事实的确如此，当使用对照实验系统的时候，互联网公司就从争执中解脱了出来，以用户的反馈为向导在可量化的道路上快速地优化创新~~ 可惜这只是理想情况，实践中对实验系统实践的好坏，可以造成巨大的差别。

对照实验

最简单的对照实验系统，是将用户分成50%对50%的两组，一组为实验组，一组为对照组。对指定的指标，比较两组的统计结果，得出实验组的效果。

实验系统的结果评价中存在一个非常重要的统计问题，随机划分用户之后，会产生抽样的误差。可以计算，对于不同的置信水平，要达到不同的实验精度，需要不同的总流量数。对此这篇论文讲得非常简单，我们在以后对其他论文的介绍中会再提到。这篇论文只简单地举个例子，如果要以实验指标相对变化5%为精度，在95%的置信水平下，需要500,000个流量（用户）。需要的流量数与实验精度是平方反比的关系，一般来讲一个改进能提高相对1%已经算是很不错了，所以说需要的流量通常还是相当大的，小流量的系统在这里会非常痛苦，因为这意味着更长的实验时间。

实验的评价标准应当在实验进行之前就确定，换句话说就是用哪些指标做判断应该先选，否则，如果有很多已有的标准，然后在实验过程中看哪个是正面的并且达到了“精度”就认为存在这个效果，就落入了著名的统计学错误“我早就知道了”。而在实践中，这项原则很多人都”不愿意”遵守。

扩展

实验组的流量比例可以逐步扩大，每一个阶段都可以运行相当长的时间，这样可以避免实验组的负面效果或者bug对整个系统造成过大的影响。而这个过程也可以自动进行。其实与这种方法类似的，就是所谓的灰度发布。

实验甚至可以全自动进行，考虑系统中的某些参数是需要不断随时间调整的情况，可以先指定标准，然后随时自动地根据实时实验结果调整参数。

对照实验可以用做程序迁移时的检查，也就是观察一次新的变更是否并不影响用户体验。对于某些公司来说，这可能才是对照实验最重要的用途。

不足

对照实验是有效的，可是却不能带来解释。

短期利益和长期利益不一致的问题。解决这个问题，应当制定更合理的综合性的标准，但是这件事情并不容易做。

先入为主或者新鲜感造成的影响。这是两个相反的效应，为了识别和避免，可以考虑用新用户做一组同样的实验进行对比。

要实验的功能必须先实现。

一致性问题，用户可能会发现他们在使用一个行为不一致的系统。即使按用户抽样也不一定能避免这个问题。

同时进行的实验的相互影响。这篇论文认为实际上这种情况很少发生，这方面的担心常常是过度的。另一方面，可以做自动的检测来判断实验间是否互相影响了。不过，说起来容易做起来难。

信息公开问题。对于较大的改动可能必须要先公布才能开始上线。然而公开的信息可能影响用户行为。

实现

论文中提及的是，使用足够强度的随机算法，将用户根据标签计算散列，并为每个散列准备对应的partition，在抽样时选择指定的partition就可以实现任意比例的抽样。然而这好像并不是一种非常好的实现方式。

对于流量的分派，有三种方法，第一是split，包括物理上的或者虚拟的。物理划分大概是最直接的一种方法，但是这种方法需要一个分布式的配置甚至程序的部署系统。第二种方法是在server端选择，server端程序在处理过程中计算随机函数，并且给出不同的行为。这种方法带来了额外的编程代价，通常变更实验时还需要改变代码。第三种方法是在client端选择，按论文所说，这种是通过JavaScript之类的方法实现的，感觉很受局限，似乎意义不大。

实践中学到的

作者这里引用了一句很经典的话：在现实中理论和现实的差距比理论上要大得多。

对数据做分析：整体上指标的结果只是一个方面，实验实际上提供了丰富的信息可以做研究。不过这里要小心之前提到的”我早就知道了“错误。

性能很重要：不知不觉拖慢了网页的加载速度可能会影响很多指标，程度往往令人惊讶。当你发现实验指标很难解释的时候多想想是否是性能的问题。

是否一次只实验一件事？有些人认为一次应该只实验一件事，作者认为这个限制过于严格了。与之前提到的一样，大多数情况下实验并不会互相影响（真的是这样吗？），另一方面技术上让实验并行又是完全可行的，因此作者建议这样的做法：只对确实很可能互相影响的事情分开做实验。在以后我们也许会讨论实验的并行以及实验间相互影响的检测之类的话题。

持续运行A/A测试：与其他测试同时，持续地运行A/A测试。这可以用来检测用户是否被合理划分，数据是否被正确收集，以及设想的置信水平是否确实可靠。

自动的灰度发布和放弃：理论上这是可行的，而且实践中确实也有人已经这样做了。也许，自动调参会是更激进，也更有用的。

了解时间周期效应：在一天的不同时段，或者一周的不同日期，用户行为可能会有很大的差异。因此即使你有足够的流量，最好也要让实验运行数个整天，或者数个整周。

实验的评价标准一定要在实验之前就确定：呵呵，又一次见到这条，这件事确实非常值得强调，而且在很多地方很遗憾地没有被遵守。另外，作者在这里更多强调的是实验各方应当对此达成一致，也就是说在实验前就统一认识，确认哪些指标的变化是符合预期的。为了解决类似的问题，我们在以后的文章中可能会见到另一种方法，通过一个权威机构“实验委员会”来最终解释实验。