diff --git a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
index c66c17c..67d6a9a 100644
--- a/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
+++ b/overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
@@ -48,9 +48,9 @@
为了达到这些设计的目标,我们不仅需要实验设施来进行更多的实验,并且需要一些工具和指导过程来支持更多和更快的实验。
-对于实验设施,有两个很明显的选择,或是要支持单层实验或是要支持多因素实验。单层实验意味着每个请求最多只会通过一个实验,单层实验是很容易使用的,并且也具有灵活性,但是扩展性不足。多因素实验在统计学上进行了大量的讨论,多因素实验中每个参数(因素)都可以被独立地实验,在实验中每个参数(因素)都可以独立地被实验,每个实验中只测试一个参数,这个参数会覆盖所有其它实验中的其它参数。每个查询可以同时在
个实验中,其中
是参数的个数。虽然这种方法进行了多年的研究和实践,但对于`Google`的系统却不适用,因为`Google`有几千个参数,并且不能被独立的分析。例如:要对两个参数进行分析,一个参数是`Web`页面的背景色,另一个是文字的颜色,虽然『蓝色』对两个参数都是合法值,但是如果两个参数都取『蓝色』,那么页面是不可读的。
+对于实验设施,有两个很明显的选择,或是要支持单层实验或是要支持多因素实验。单层实验意味着每个请求最多只会通过一个实验,单层实验是很容易使用的,并且也具有灵活性,但是扩展性不足。多因素实验在统计学上进行了大量的讨论,多因素实验中每个参数(因素)都可以被独立地实验,在实验中每个参数(因素)都可以独立地被实验,每个实验中只测试一个参数,这个参数会覆盖所有其它实验中的其它参数。每个查询可以同时在
个实验中,其中
是参数的个数。虽然这种方法进行了多年的研究和实践,但对于`Google`的系统却不适用,因为`Google`有几千个参数,并且不能被独立的分析。例如:要对两个参数进行分析,一个参数是`Web`页面的背景色,另一个是文字的颜色,虽然『蓝色』对两个参数都是合法值,但是如果两个参数都取『蓝色』,那么页面是不可读的。
-本文提出的解决方案是将参数分成子集,每个参数子集包含相互不能独立修改的参数。一个参数子集会与一个包含实验的层相关联,不同层的实验的流量是正交的。每个查询(`query`)可以在
个实验中,其中
是层的数量。
+本文提出的解决方案是将参数分成子集,每个参数子集包含相互不能独立修改的参数。一个参数子集会与一个包含实验的层相关联,不同层的实验的流量是正交的。每个查询(`query`)可以在
个实验中,其中
是层的数量。
# 2. 相关工作成果【略】
@@ -79,7 +79,7 @@
在本节中,我们将介绍重叠实验基础设施(`overlapping experiment infrastructure`),在尽量保留单层实验系统的优点(易用、快速)的同时,增加了可扩展性、灵活性和健壮性。我们还实现了一种可控的、定义明确的逐步放量的方式。
-前面解释过,多因素实验并不适用于`Google`的实验场景,因为实验参数可能并不相互独立(比如,粉色的字和粉色的背景)。有了这个限制,我们的核心思路是将参数划分到
个子集。每个子集都关联着一个实验层,每个请求最多会被
个实验处理(每层一个实验)。每个实验只能修改自己层相关联的参数(即在参数子集中的参数),并且同一参数不能出现在多个层中。
+前面解释过,多因素实验并不适用于`Google`的实验场景,因为实验参数可能并不相互独立(比如,粉色的字和粉色的背景)。有了这个限制,我们的核心思路是将参数划分到
个子集。每个子集都关联着一个实验层,每个请求最多会被
个实验处理(每层一个实验)。每个实验只能修改自己层相关联的参数(即在参数子集中的参数),并且同一参数不能出现在多个层中。
一个很明显的问题是如何划分参数。首先,我们可以根据模块化的程序(服务)对参数进行子集划分,不同程序的参数可以划分到不同的子集中(这会解决前面提到的流量饥饿和偏置的问题)。然而一个程序所有的参数并不一定要在一个参数子集中,我们可以通过分析(比如,我们知道某些参数是相互独立的)或是通过以前实验(比如,分析以前将参数放到一起修改的实验)可以对一个程序的参数进行进一步划分。
@@ -154,27 +154,27 @@
一个实验的有效规模定义为:
-
+
-在工程实践中,我们主要关注
和
,但要通过
个和才能影响相关的实验指标,为了正确确定
值,我们需要知道:
+在工程实践中,我们主要关注
和
,但要通过
个和才能影响相关的实验指标,为了正确确定
值,我们需要知道:
* 实验所关注的指标是什么。
-* 对每个指标,我们想检测实验改变的敏感度(
)值是什么。比如,实验者想检测到2%的点击率变化。
-* 对每个指标,一个抽样单元(
)样本标准误差是(
),实验大小为
的标准误差为
。
+* 对每个指标,我们想检测实验改变的敏感度(
)值是什么。比如,实验者想检测到2%的点击率变化。
+* 对每个指标,一个抽样单元(
)样本标准误差是(
),实验大小为
的标准误差为
。
-_Kohavi_ 假设实验与对照实验有相同的大小,比如
,那么必须
大于等于
才能满足最小变化检测需求,16这个值是由置信度(
,通常为95%)和期望的统计功效(
,通常为80%)决定的。
+_Kohavi_ 假设实验与对照实验有相同的大小,比如
,那么必须
大于等于
才能满足最小变化检测需求,16这个值是由置信度(
,通常为95%)和期望的统计功效(
,通常为80%)决定的。
-我们这套重叠做法的一个优点是我们可以在每一层创建一个大的比照实验,这样它可以被多个实验共享,如果共享的对照实验规模比实验大的多(
),那么我们可以用
而不是
,这样虽然样本量变小为
,却有着90%的统计功效(
)。
+我们这套重叠做法的一个优点是我们可以在每一层创建一个大的比照实验,这样它可以被多个实验共享,如果共享的对照实验规模比实验大的多(
),那么我们可以用
而不是
,这样虽然样本量变小为
,却有着90%的统计功效(
)。
-在确定实验规模的过程中,更重要的问题是如何估计标准误差
,特别是当我们使用很多比率指标
时(比如,覆盖率,有多少查询是返回广告的(有广告返回的查询/全部查询量))。问题产生于是实验的单元与分析的单元不一致时,比如,对于覆盖率,分析的单元是一个查询,但对于`cookie`取模的实验而言,实验的单元是一个`cookie`(一系列查询),并且我们无法假设来来自同一用户或`cookie`的请求之间是相互独立的,我们的方法是计算
,即每个实验的标准误差,然后以
来表示
,在上例中,
是每个`cookie`取模的标准误差,且
。对于比率指标,我们用`delta`方法计算
[11]。
+在确定实验规模的过程中,更重要的问题是如何估计标准误差
,特别是当我们使用很多比率指标
时(比如,覆盖率,有多少查询是返回广告的(有广告返回的查询/全部查询量))。问题产生于是实验的单元与分析的单元不一致时,比如,对于覆盖率,分析的单元是一个查询,但对于`cookie`取模的实验而言,实验的单元是一个`cookie`(一系列查询),并且我们无法假设来来自同一用户或`cookie`的请求之间是相互独立的,我们的方法是计算
,即每个实验的标准误差,然后以
来表示
,在上例中,
是每个`cookie`取模的标准误差,且
。对于比率指标,我们用`delta`方法计算
[11]。
-图4是在不同实验中,包括`cookie`取模和随机流量实验,对于覆盖率指标与标准误差呈
的关系,图中的斜线即是
,坐标轴上的值出于保密的原因隐去了,但可以看出`cookie`取模的斜线比查询的斜线陡峭,比如在相同的准确度下衡量相同的覆盖率的变化,一个`cookie`取模的实验需要比随机流量实验大的规模。
+图4是在不同实验中,包括`cookie`取模和随机流量实验,对于覆盖率指标与标准误差呈
的关系,图中的斜线即是
,坐标轴上的值出于保密的原因隐去了,但可以看出`cookie`取模的斜线比查询的斜线陡峭,比如在相同的准确度下衡量相同的覆盖率的变化,一个`cookie`取模的实验需要比随机流量实验大的规模。
-**图4**:在分配类型下计算覆盖度
的斜线
+**图4**:在分配类型下计算覆盖度
的斜线
-因为不同的指标和不同的分配有着不同的
,那么我不应该让每个实验者自己去计算它, 我们提供了一个工具计算实验者指定的关注指标和指标敏感度,分配类型(比如`cookie`取模或是随机流量)和他们想要的某种流量(比如,分配条件,比如日语流量),工具就告诉实验者他需要多大规模流量才可以支持他的要求的实验。实验者可以轻松地在流量大小和敏感量之间权衡,有了这个工具,我们可以认为实验者在运行实验之前会设置合理的实验规模。
+因为不同的指标和不同的分配有着不同的
,那么我不应该让每个实验者自己去计算它, 我们提供了一个工具计算实验者指定的关注指标和指标敏感度,分配类型(比如`cookie`取模或是随机流量)和他们想要的某种流量(比如,分配条件,比如日语流量),工具就告诉实验者他需要多大规模流量才可以支持他的要求的实验。实验者可以轻松地在流量大小和敏感量之间权衡,有了这个工具,我们可以认为实验者在运行实验之前会设置合理的实验规模。
为了为我们的实验规模工具收集数据,我们一直运行一组 **同质测试**(`uniformity trial`),比如,我们运行许多 对比实验或A vs. A实验。这些实验有着不同的实验规模和分配类型,我们可以用这些结果经验地衡量我们指标的自然变化(`natural variance`),并可以测试我们计算的置信区间的正确性。
@@ -182,7 +182,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小,比如
)。
+通常,我们无法仅将触发集合的流量给实验,因为要确定请求是否触发,是需要运行时计算的,这种运行时的计算正是触发无法实现成分配条件的原因(这个触发条件很难构造对照实验流量),所以,重要的工作是记录事实(`factual`,当实验被触发)和反事实(`counter-factual`,当实验可被触发),反事实是在对比实验中记录的,比如在前面的例子中,事实(当天气信息展示)是记录在实验中的,反事实是记录在对照实验中的。比如当这个查询是可以展示天气信息的(因为它是在对比实验中,所以实际并没展示)。这些日志对于实验样本量和分析实验都很重要,因为流量中包括了没有实验变化的请求,这些请求会稀释实验的作用,在触发集合上衡量实验结果会更准确衡量实验的影响。另外,通过关注于触发集合的显著效果,实验流量的需求可以减少,因为实验的有效规模是依赖于我们要想检测的敏感度的倒数(
)。
### 5.2.3 前期与后期
@@ -236,7 +236,7 @@ _Kohavi_ 假设实验与对照实验有相同的大小,比如 。要说明的是实验的数目包含了对照实验的数目。对于运行实验人数,一些实验是有多个拥有者的(比如,如果某人离开城市或发生了事),或是将团队邮件列表中的成员也认为拥有者。不幸的是,我们无法轻松地知道有多少拥有者是非工程师,但有意思的是,非工程师的数据是在增加的,对分布层的数量,我们只计算了使用重叠实验的发布层的数量。在重叠实验之前,我们用其他的一些机制发布实验,但它们的频率在下降。在所有的图中,y轴上的数据出于保密的原因隐去了(它们是线性比例),但从趋势上可以明显地看出,我们系统支持了指数级增加的实验,发布,实验者。
+我们可以用几个标准来判断我们是否成功地运行更多的实验,在一个时期上一共运行了多少实验,这些实验中有多少发布了,有多少不同的实验在运行实验(见图5)。要说明的是实验的数目包含了对照实验的数目。对于运行实验人数,一些实验是有多个拥有者的(比如,如果某人离开城市或发生了事),或是将团队邮件列表中的成员也认为拥有者。不幸的是,我们无法轻松地知道有多少拥有者是非工程师,但有意思的是,非工程师的数据是在增加的,对分布层的数量,我们只计算了使用重叠实验的发布层的数量。在重叠实验之前,我们用其他的一些机制发布实验,但它们的频率在下降。在所有的图中,`Y`轴上的数据出于保密的原因隐去了(它们是线性比例),但从趋势上可以明显地看出,我们系统支持了指数级增加的实验,发布,实验者。
<img src=)

**图5**:实验,拥有者,发布数量在时间上的趋势图