对于互联网公司来说，使用对照实验系统（常被称作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测试。这可以用来检测用户是否被合理划分，数据是否被正确收集，以及设想的置信水平是否确实可靠。
自动的灰度发布和放弃：理论上这是可行的，而且实践中确实也有人已经这样做了。也许，自动调参会是更激进，也更有用的。
了解时间周期效应：在一天的不同时段，或者一周的不同日期，用户行为可能会有很大的差异。因此即使你有足够的流量，最好也要让实验运行数个整天，或者数个整周。
实验的评价标准一定要在实验之前就确定：呵呵，又一次见到这条，这件事确实非常值得强调，而且在很多地方很遗憾地没有被遵守。另外，作者在这里更多强调的是实验各方应当对此达成一致，也就是说在实验前就统一认识，确认哪些指标的变化是符合预期的。为了解决类似的问题，我们在以后的文章中可能会见到另一种方法，通过一个权威机构“实验委员会”来最终解释实验。
Codingstory 