backup/translations
1
0
Fork 0
mirror of https://github.com/oldratlee/translations.git synced 2026-04-14 02:00:08 +08:00
Code Issues Projects Releases Wiki Activity

Infrastructure 由『框架』改译成『设施』

Browse Source
This commit is contained in:
Jerry Lee
2017-04-25 15:43:14 +08:00
parent 51106d3199
commit 65817bf972
1 changed files with 4 additions and 4 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
overlapping-experiment-infrastructure-more-better-faster-experimentation/README.md
View File

@@ -1,7 +1,7 @@
原文链接： [Overlapping Experiment Infrastructure: More, Better, Faster Experimentation](http://research.google.com/pubs/pub36500.html "Overlapping Experiment Infrastructure: More, Better, Faster Experimentation") - _Diane Tang, Ashish Agarwal, Deirdre O’Brien, Mike Meyer_
基于[火光摇曳Flickering](http://www.flickering.cn/)上 _lexqu（屈伟）_ 的译文稿`v1.2.0`： [Google 重叠实验框架：更多，更好，更快地实验](http://www.flickering.cn/uncategorized/2015/01/%E9%87%8D%E5%8F%A0%E5%AE%9E%E9%AA%8C%E5%B9%B3%E5%8F%B0%EF%BC%9A%E6%9B%B4%E5%A4%9A%EF%BC%8C%E6%9B%B4%E5%A5%BD%EF%BC%8C%E6%9B%B4%E5%BF%AB%E5%9C%B0%E5%AE%9E%E9%AA%8C/)
# 重叠实验框架：更多，更好，更快地实验
# 重叠实验设施：更多，更好，更快地实验
<!-- START doctoc generated TOC please keep comment here to allow auto update -->
<!-- DON'T EDIT THIS SECTION, INSTEAD RE-RUN doctoc TO UPDATE -->
@@ -34,11 +34,11 @@
`Google`是一个数据驱动型公司，这意味着所有对用户的改动的发布，都要决策者以相应的经验数据作为依据。这些数据大部分是由在线流量上的实验产生的。在`Web`的语境下，一个实验是由一股流量（比如，用户的请求）和在这股流量上进行的相对对比实验的修改组成的。修改包括用户可见的修改（比如，修改顶部广告的背景色），以及不可见的修改，比如测试一个新的广告点击率（`CTR`）预测算法，都可以通过实验的方式进行的。
要支持数据驱动方法论的挑战在于要跟上创新的速度。我们想支持进行尽可能多的实验，如果实验框架要限制同时进行的实验的数量，那是绝不可被接受的。我们进行实验是为了测试一些新的特性和挖掘一些已有特性的提升空间。对于已有特性，实验可以学习到用户的反应并可以对特性进行优化。试想一下，如果在搜索结果页上的内容都是通过参数控制的，包括展示方式和算法。通过对参数设置不同的参数值进行实验，我们可以用衡量指标（用户体验，收入或其它指标）来决定是否要进行哪些修改以得到最好的结果。
要支持数据驱动方法论的挑战在于要跟上创新的速度。我们想支持进行尽可能多的实验，如果限制了同时进行的实验的数量，那是绝不可被接受的。我们进行实验是为了测试一些新的特性和挖掘一些已有特性的提升空间。对于已有特性，实验可以学习到用户的反应并可以对特性进行优化。试想一下，如果在搜索结果页上的内容都是通过参数控制的，包括展示方式和算法。通过对参数设置不同的参数值进行实验，我们可以用衡量指标（用户体验，收入或其它指标）来决定是否要进行哪些修改以得到最好的结果。
对`UI`的修改通常会使用实验来评价用户反应，但需要注意的是算法的修改同样也需要实验。例如：假设一些团队想测试一个新的机器学习算法来预测广告`CTR`，或是测试对现有算法的调整（比如，修改学习速度或是收敛速度）。虽然线下评估可以进行一些分析后，可以缩小参数的最佳取值区间（不是最佳取值），但最终这些参数还是需要在线上流量进行评估，分析这些参数在真实的流量上的效果（因为修改可能会影响用户的行为，并改变流量本身的模式，这是不可能在线下环境评估的）。所以，评价这些机器学习算法是需要通过线上实验的方式进行的。
设计我们实验框架的目标是：_更多_，_更好_，_更快_。
设计我们实验设施的目标是：_更多_，_更好_，_更快_。
* **更多**：我们需要能同时进行多个实验的可扩展性。但是我们也需要灵活性：不同的实验需要不同的配置和不同的流量来衡量实验的统计意义上的效果显著性。有些实验只需要修改流量的一个子集，比如只是日语的流量，并需要取一个合理的流量规模。其它的实验有可能需要修改所有的流量，并对指标造成很大影响，这种才可以在小流量上进行测试。
* **更好**：不合理的实验是不应该让它在线上流量进行的。合理的但是很差的实验（比如，有`bug`的实验或是无意中产生的很差的实验结果）都应该能很快的被捕获并且停止它的进行。标准化的标价指标可以让所有的实验进行公平的比较：比如在计算`CTR`指标的时间，两个实验应该用相同的过滤器去掉爬虫流量。
@@ -71,7 +71,7 @@
在数据文件中配置实验，可以让实验更快更方便地创建：数据文件是可读的，并容易手工编辑，不需要进行代码变更，并可以由非工程师进行创建，而且配置数据的推动会比二进制程序的发布更加频繁，它使创建仅包含已有参数的实验更加方便快捷。
在开发我们的实验架构之前，我们使用一个简单的单层实验框架，在这个架构中，每个请求最多进行一种实验。先分配`Cookie`取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即`Cookie`取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在`Google`数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。
在开发我们的实验架构之前，我们使用一个简单的单层实验设施，在这个架构中，每个请求最多进行一种实验。先分配`Cookie`取模的流量的实验，再分配随机流量的实验。上游服务会优先分配流量，所以如果上游（即`Cookie`取模的实验）进行了很多实验，那么下游可能会得不到足够的流量，即流量饥饿问题。除了这些问题之外（包括前面提到的流量饥饿和偏置问题），单层实验可以满足我们设计目标中的易用和相对的灵活性。但是在`Google`数据驱动的文件中，单层的方法没有足够的可扩展性：我们无法快速地进行足够多的实验。
# 4. 重叠实验基础设施