From 51106d31994af4c8fa7ef8d2c4b4becd847d1117 Mon Sep 17 00:00:00 2001
From: Jerry Lee <oldratlee@gmail.com>
Date: Tue, 25 Apr 2017 15:38:04 +0800
Subject: [PATCH] =?UTF-8?q?=E6=B7=BB=E5=8A=A0=E7=9B=AE=E5=BD=95=EF=BC=9B?=
 =?UTF-8?q?=E5=8A=A0=E5=9B=BA=E5=8E=9F=E6=96=87=E6=9C=AC=E6=9D=A5=E5=B0=B1?=
 =?UTF-8?q?=E6=9C=89=E7=9A=84=E6=A0=87=E9=A2=98=E7=BC=96=E5=8F=B7?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../README.md                                 | 71 +++++++++++++------
 1 file changed, 49 insertions(+), 22 deletions(-)

diff --git a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
index d876969..04c1f3b 100644
--- a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
+++ b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
@@ -3,7 +3,34 @@
 
 # 重叠实验框架：更多，更好，更快地实验
 
-# 序言
+<!-- START doctoc generated TOC please keep comment here to allow auto update -->
+<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
+
+
+- [1. 序言](#1-%E5%BA%8F%E8%A8%80)
+- [2. 相关工作【略】](#2-%E7%9B%B8%E5%85%B3%E5%B7%A5%E4%BD%9C%E7%95%A5)
+- [3. 背景](#3-%E8%83%8C%E6%99%AF)
+- [4. 重叠实验基础设施](#4-%E9%87%8D%E5%8F%A0%E5%AE%9E%E9%AA%8C%E5%9F%BA%E7%A1%80%E8%AE%BE%E6%96%BD)
+- [5. 工具与流程](#5-%E5%B7%A5%E5%85%B7%E4%B8%8E%E6%B5%81%E7%A8%8B)
+    - [5.1 工具](#51-%E5%B7%A5%E5%85%B7)
+    - [5.2 实验设计与样本量](#52-%E5%AE%9E%E9%AA%8C%E8%AE%BE%E8%AE%A1%E4%B8%8E%E6%A0%B7%E6%9C%AC%E9%87%8F)
+        - [5.2.1 样本量](#521-%E6%A0%B7%E6%9C%AC%E9%87%8F)
+        - [5.2.2 Trigging, Logging, & Counter-factuals](#522-trigging-logging--counter-factuals)
+        - [5.2.3 Pre- & Post-Periods](#523-pre---post-periods)
+    - [5.3 Fast Analytics](#53-fast-analytics)
+    - [5.4 Education](#54-education)
+        - [5.4.1 Experiment council](#541-experiment-council)
+        - [5.4.2 解读数据（`Interpreting the Data`）](#542-%E8%A7%A3%E8%AF%BB%E6%95%B0%E6%8D%AEinterpreting-the-data)
+- [6. Result](#6-result)
+    - [6.1 More](#61-more)
+    - [6.2 Better](#62-better)
+    - [6.3 Faster](#63-faster)
+- [7. 结论与工作展望](#7-%E7%BB%93%E8%AE%BA%E4%B8%8E%E5%B7%A5%E4%BD%9C%E5%B1%95%E6%9C%9B)
+- [8. 参考资料](#8-%E5%8F%82%E8%80%83%E8%B5%84%E6%96%99)
+
+<!-- END doctoc generated TOC please keep comment here to allow auto update -->
+
+# 1. 序言
 
 `Google`是一个数据驱动型公司，这意味着所有对用户的改动的发布，都要决策者以相应的经验数据作为依据。这些数据大部分是由在线流量上的实验产生的。在`Web`的语境下，一个实验是由一股流量（比如，用户的请求）和在这股流量上进行的相对对比实验的修改组成的。修改包括用户可见的修改（比如，修改顶部广告的背景色），以及不可见的修改，比如测试一个新的广告点击率（`CTR`）预测算法，都可以通过实验的方式进行的。
 
@@ -23,9 +50,9 @@
 
 本文提出的解决方案是将参数分成子集，每个参数子集包含相互不能独立修改的参数。一个参数子集会与一个包含实验的层相关联，不同层的实验的流量是正交的。每个`query`可以在 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个实验中，其中 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 是层的数量。
 
-# 相关工作【略】
+# 2. 相关工作【略】
 
-# 背景
+# 3. 背景
 
 在讨论`Google`的实验之前，我们先描述一下我们实验架构所处的环境，这样能更清楚的理解我们实验架构所要设计的目标和所受到的限制。
 
@@ -46,9 +73,9 @@
 
 在开发我们的实验架构之前，我们使用一个简单的单层实验框架，在这个架构中，每个请求最多进行一种实验。先分配`Cookie`取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即`Cookie`取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在`Google`数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。
 
-# 重叠实验设施（`overlapping experiment infrastructure`）
+# 4. 重叠实验基础设施
 
-在本节中，我们将介绍重叠实验框架，它在尽量保留单层实验框架的优点（易用，快速）的同时，增加了可扩展性，灵活性，和健壮性。我们还实现了一种可控的，定义明确的逐步放量的方式。
+在本节中，我们将介绍重叠实验基础设施（`overlapping experiment infrastructure`），在尽量保留单层实验系统的优点（易用、快速）的同时，增加了可扩展性、灵活性和健壮性。我们还实现了一种可控的、定义明确的逐步放量的方式。
 
 前面解释过，多因素实验并不适用于`Google`的实验场景，因为实验参数可能并不相互独立（比如，粉色的字和粉色的背景）。有了这个限制，我们的核心思路是将参数划分到 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个子集。每个子集都关联着一个实验层，每个请求最多会被 <img src="http://chart.googleapis.com/chart?cht=tx&chl=N" style="border:none;" alt="N" /> 个实验处理（每层一个实验）。每个实验只能修改自己层相关联的参数（即在参数子集中的参数），并且同一参数不能出现在多个层中。
 
@@ -105,20 +132,20 @@
 * 评估实验指标。根据实验结果，判断是否要进行新一轮的实验，即通过修改或创建新的实验，或甚至修改代码从根本上改变特性。
 * 如果特性可以发布，就进入发布过程：创建一个新的发布层和发布层实验，逐步的放量这个实验，并最终删除发布完的发布层，然后将发布层实验的相关参数设为系统默认参数。
 
-# 工具与流程
+# 5. 工具与流程
 
 虽然重叠架构是有能力运行更多的实验，更快速地进行实验，并能同步优化实验效果，但只依靠架构还是不够的。我们还需要工具，研究，和教育过程来支持更快速的实验。在本节，我们讨论几个关键的工具和过程，以及它们如何帮助我们扩展的。
 
-## 工具
+## 5.1 工具
 
 * **数据文件检查：** 数据文件的其一优势是它们可以被自动检查错误，这可以避免一些不合理的实验运行。我们会自动检查法语错误（所有的必填字段都有并且合法），一致性和约束错误（比如，`id`的唯一性，根据所有的参数判断是否实验在正确的层，是否这一层有足够的流量来支持实验，流量约束检查，如果实验要求的流量已经被另一个实验使用了，等等，注意当可用的分配条件集合变大时，这些检查就变的复杂了），和基本的实验设置检查（是否实验有对比实验，并且对比实验在相同的层，是否对比实验与实验的流量分配方式和规模一致，等等）。
 * **实时监控：** 我们用实时监控来检测基本的指标（比如`CTR`），我们通过实时监控尽快地发现某个实验是不正常的，实验者可以设置监控指标的期望值区间（也有这些指标的默认波动区间），如果监控指标超出了期望的波动区间，那么会触发自动告警，然后实验者可以修改期望区间或停止他们的实验，或调整它们的实验参数值，但它允许实验者可以激进地对于可能的潜在的变化进行测试，因为错误或预期之外的影响会被很快检测到。
 
-## Experiment Design & Sizing
+## 5.2 实验设计与样本量
 
-相比基本的对实验配置的基本检查外（比如，每个实验都必须有一个对照实验，它与实验使用相同的分流条件），实验设计和样本量是更高级的话题。
+相比基本的对实验配置的基本检查外（比如，每个实验都必须有一个对照实验，它与实验使用相同的分流条件），实验设计（experiment design）和样本量（`sizing`）是更高级的话题。
 
-### Sizing
+### 5.2.1 样本量
 
 如 _Kohavi_ 论文[7]中所述，样本量应该让实验有足够的统计意义，可以统计认为有意义的指标很小的变化。在本节中，我们讨论以及实验样本量，以及实验依赖的设置，还有一些相关的样本量的工具。
 
@@ -147,17 +174,17 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 为了为我们的实验规模工具收集数据，我们一直运行一组 **同质测试**（`uniformity trial`），比如，我们运行许多对比实验或A vs. A实验。这些实验有着不同的实验规模和分配类型，我们可以用这些结果经验地衡量我们指标的自然变化（`natural variance`），并可以测试我们计算的置信区间的正确性。
 
-### Trigging, Logging, & Counter-factuals
+### 5.2.2 Trigging, Logging, & Counter-factuals
 
 回顾一下，流量分配是指分配给实验的流量，但是一个实验可能不会对所有分配给它的流量进行新特性服务，相反，一些实验可能仅在某种请求时被 **触发**（`trigger`），比如一个实验是测试何时应该显示天气信息，它可能会得到全部的流量 ，但只有一部分流量的查询会触发显示天气，这一部分但触发查询就称为触发集合。
 
 通常，我们无法仅将触发集合的流量给实验，因为要确定请求是否触发，是需要运行时计算的，这种运行时的计算正是触发无法实现成分配条件的原因（这个触发条件很难构造对照实验流量），所以，重要的工作是记录事实(`factual`，当实验被触发)和反事实(`counter-factual`，当实验可被触发)，反事实是在对比实验中记录的，比如在前面的例子中，事实（当天气信息展示）是记录在实验中的，反事实是记录在对照实验中的。比如当这个查询是可以展示天气信息的（因为它是在对比实验中，所以实际并没展示）。这些日志对于实验样本量和分析实验都很重要，因为流量中包括了没有实验变化的请求，这些请求会稀释实验的作用，在触发集合上衡量实验结果会更准确衡量实验的影响。另外，通过关注于触发集合的显著效果，实验流量的需求可以减少，因为实验的有效规模是依赖于我们要想检测的敏感度的倒数（<img src="http://chart.googleapis.com/chart?cht=tx&chl=1%2F%5Ctheta%5E2" style="border:none;" alt="1/\theta^2" />）。
 
-### Pre- & Post-Periods
+### 5.2.3 Pre- & Post-Periods
 
 一个预时期(`pre-period`)是指在先于开始实验的一个时期，这时期与实验有着相同的流量（比如，相同的`cookie`取模），但没有实验的效果，一个后时期（`post-period`）是类似的概念，区别是它是在实验之后的，这两个时期类似于一个对比实验与另一个对比实验比较，只是使用实验的流量，预时期是保证一个实验与它的对比实验是实际可比的，而不受其它因素影响，比如，有未捕获的垃圾流量或是爬虫，后时期判断运行实验是有学习到的效果，这些技术仅能用于用户`id`和`cookie`取模实验。
 
-## Fast Analytics
+## 5.3 Fast Analytics
 
 虽然前面提到的架构，可以同时进行许多实验，并快速地运行一个实验，但没有实验分析工具，一个真正的实验进程是无法在本质上快速进行的。对实验工具完整的讨论已经超出了本文的范围，但这里我们讨论一个重要的设计目的。
 
@@ -172,11 +199,11 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 只有一个工具提供实验准确的指标意味着我们有唯一的一致性实现，它使用相同的过滤器（比如，移除潜在的爬虫流量和垃圾流量），这样，不同的团队之间就可的`CTR`值就具有了可比较性。一个唯一的工具也更高效，因为计算会一次完成后，并呈现给实验者们，而不是每个实验者进行他们自己的计算。
 
-## Education
+## 5.4 Education
 
 现在我们有了重叠架构和相关工具，实验设计已经完成了进行更多、更快、更好的技术方面的要求。我们还是要讨论一下人的因素。教育在促进健壮的实验目标中是同样重要的。在`Google`，有两个过程来保证实验是良好设计的，并且一个实验的结果是能被理解和传播的。
 
-### Experiment council
+### 5.4.1 Experiment council
 
 第一个过程我们称之为实验委员会，它包含一组工程师，他们会审核实验者在做实验前提交的一个轻量级的checklist，checklist中问题包括：
 
@@ -189,7 +216,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 初次使用的实验者会通过这些问题学习合理的实验设计和实验样本量，并了解实施一个实验背后的技术细节。有经验的实验者仍会发现checklist仍是有用的。不止于此，这个方法可以将所产生的更好的实验实践传播出来（比如，产生了新的工具来促进实验，产生了新的评价指标，等等），这个checklist是一个`Web`应用，`Web`应用对于存档和教育都是有用的，教育作用体现在实验者可以阅读以往的checklist来理解相关信息。
 
-### Interpreting Data
+### 5.4.2 解读数据（`Interpreting the Data`）
 
 另一个过程是讨论会，实验者们带着他们的实验结果与专家进行讨论，讨论的目标是：
 
@@ -199,18 +226,18 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 讨论会对实验者是一个学习如何理解实验结果的有益之所，有经验的实验者通常不会犯以前犯过的错误，并可以预期要得到完全理解的实验结果，需要什么数据。讨论是开放的，将来要进行实验的人，可以参加以了解运行一个实验需要了解什么。实验都会记录，我们就有了一个知识库。
 
-# Result
+# 6. Result
 
 我们在2007年3月部署了我们的重叠实验架构（以有很多工具和处理预时期和后时期的架构发布），最终衡量我们整个系统成功的指标是我们在运行更多的实验，更好地运行，更快得到结果的能力。
 
-## More
+## 6.1 More
 
 我们可以用几个标准来判断我们是否成功地运行更多的实验，在一个时期上一共运行了多少实验，这些实验中有多少发布了，有多少不同的实验在运行实验（见图5）。要说明的是实验的数目包含了对照实验的数目。对于运行实验人数，一些实验是有多个拥有者的（比如，如果某人离开城市或发生了事），或是将团队邮件列表中的成员也认为拥有者。不幸的是，我们无法轻松地知道有多少拥有者是非工程师，但有意思的是，非工程师的数据是在增加的，对分布层的数量，我们只计算了使用重叠架构的发布层的数量。在重叠实验之前，我们用其他的一些机制发布实验，但它们的频率在下降。在所有的图中，y轴上的数据出于保密的原因隐去了（它们是线性比例），但从趋势上可以明显地看出，我们系统支持了指数级增加的实验，发布，实验者。
 
 <img src="figure-05-1.jpg" width="290"><img src="figure-05-2.jpg" width="290"> <img src="figure-05-3.jpg" width="290">  
 **图五：实验，拥有者，发布数量在时间上的趋势图**
 
-## Better
+## 6.2 Better
 
 另一个衡量我们整体系统工具和系统的指标是判断是否比以前运行实验更好，于此我们仅有耳闻，没有实际的数据，但我们是实验委员会和讨论组的成员，我们见过这个系统发布前后的许多实验情况，我们观察的结论是：
 
@@ -221,7 +248,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 显然理想的结果是上述问题都不存在，但是考虑到我们有更多的实验者，而上述问题即在下降，这已经是一个不错的结果。
 
-## Faster
+## 6.3 Faster
 
 最后的一个衡量我们系统成功的指标是我们是否最终更快地得到数据，并更快地做出决策，对于速度，我们还是没有具体数据，但我们可以讨论对实验速度的观察，实验可以分解为下面几个阶段：
 
@@ -232,7 +259,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 概括才言，当前的耗时点有：实现一个实验，在预时期的运行时间、自定义分析。这些耗时点是我们努力解决的点。
 
-# Conclusions and future work
+# 7. 结论与工作展望
 
 在本文中，我们描述了重叠实验架构、相关工具和教育过程来以进行更多实验，更好且更健壮的实验，和更快的实验。我们并给出了实践中我们的工作的结果：更多实验，更多实验者，更多发布，并更快速且有更小的错误了。虽然实际的实现是针对`Google`，但关于设计的讨论对于任何想收集统计数据评估变化的公司都是适用的。
 
@@ -247,7 +274,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小，比如 <img src="http:/
 
 **感谢**：很多参与了本文的工作，并没有以作者的身份出现。下面下一个不完全的参与者名单：Eric Bauer、Ilia Mirkin、Jim Morrison、Susan Shannon、Daryl Pregibon、Diane Lambert、Patrick Riley、Bill Heavlin、Nick Chamandy、Wael Salloum、Jeremy Shute、David Agraz、Simon Favreau-Lessard、Amir Najmi、Everett Wetchler、Martin Reichelt、Jay Crim、and Eric Flatt。Robin Jeffries、Rehan Khan、Ramakrishnan Srikant、Roberto Bayardo，他们对本文提出宝贵意见。
 
-# Reference
+# 8. 参考资料
 
 * [1] D. Agarwal, A. Broder, D. Chakrabarti, D. Diklic, V. Josifovski, and M. Sayyadian. Estimating rates of rare events at multiple resolutions. In **_Proceedings of the ACM Conference on Knowledge Discovery and Data Mining (KDD)_**, 2007.
 * [2] W. G. Cochran. **_Sampling Techniques_**. Wiley, 1977.