本文针对上周的工作进行了总结，上上周的工作将在接下来通过文章进行总结，主要内容为DEIN 模型。

为了解决推荐算法基于web实验的模型验证，我参考了Overlapping Experiment Infrastructure: More, Better, Faster Experimentation 2010 的google 这篇文章。

这篇文章针对当时的web验证方案进行了总结，并未google 的web实验验证方案的设计提供了参考，在此基础之上，google 工程师设计了自己的验证方案， 我将对相关的工作做概要性的简述。

首先从图1 出发：

这篇文章中提出了一个数据流通道的简易路径，主要由两个server（search ，ads）组成，前者构成了数据通道的前向，后者提供了后项， web server 为推荐的可执行容易， 一般来说数据并发量巨大可以采用evpp c++ web 容器， 如果访问并发量不大可以采用轻量级的web容器，例如flask。前者有着诸多优势，且支持多线程。后者开发容易，部署简单。

query中包含一些重要的参数：userid， feature conbination subsets ， cookie（google 特有，实际的参数是否带用根据具体的实际情况）。

有了基本的流程之后，我们进去图3观察：

 作者认为实验分为对照性实验以及单因素实验和多因素实验，实验所需要的样本以及参数需要通过对样本进行分流分桶以及进行实验参数的配置。图三主要展示了作者针对实验流量的分流。

作者引入了cookie 的概念，作者认为cookie是唯一的，可变的。且作为用户的唯一标识符。实际上在我们的系统中由于做不到google那样的庞大，可以采用数据库中的唯一字段，或者根据索引策略去实现。也可以将cookie与用户的数据库id相对应。google 工程师对于分流增加了两个策略：

1 ，求mod策略。

2，随机策略。

原文如下所示：

 假设存在两个对照实验组：实验组named 实验1， 对照组named 实验2. 我们对新进入的userid进行mod/2 为偶数则进入实验1，作为实验1 的样本，mod/2 为奇数，作为实验1 的样本。这里新进入的样本进行随机可能会产生两个问题（样本缺乏以及样本偏值的问题），我们的目标就是确定一个实验可变参数，其他参数保持一致，在此前提下进行对照实验。相关原文在第二部分的RELATED WORK中可以查询。如下所示：

 对于偏值问题可以在样本缺乏的问题上进行探讨。

简单的需求满足不了google 基于推荐实验验证的要求，主要针对多因素的实验验证，工程师做出了多层的模式，以更方便更灵活，更快的方式部署实验验证。

 对于求mod需要做出一些改变，工程师构建了一个函数，通过多个条件将数据进行分流，原文如下：

 f函数将流量划分为几大模块，对应图2中的几个层次。才层次中可以采用随机的方式进行流量分桶。每一次数据的进入类似抛硬币，等同于n次伯努利实验，在此基础上可以分析实验的前置工作，例如样本是否具有统计显著性等工作。在图3中给出了相关的f函数的使用方式。5.2 小节对前置工作给出了具体的方法。

实验的指标可以根据CTR或者基于CNN网络的指标进行相关的计算。例如准确率，召回率，ROC，多样性等等。

根据这边文章我对当前的工作进行了相应的构建。

从应用的角度介绍来AB test的一些内容，当收集好数据之后做推断性统计分析你可能需要具备以下知识，这里限于篇幅不做介绍，自行查阅统计学书籍阅读，可参考《统计学》贾跃平，可汗学院统计学等书籍和视频。

1、点估计

2、区间估计

3、中心极限定理（样本估计总体的核心，可以对比看一下大数定理）

4、假设检验

其中假设检验部分为核心，其他辅助更好的理解该部分内容，比如区间估计可以理解为正向的推断统计，假设检验可以理解为反证的推断统计，关于假设检验本身，你可能还需要知道小概率事件、t分布、z分布、卡方分布、p值、alpha错误、belta错误等内容。   

以上则是这篇文章最简要的概述，当然存在着不足，欢迎讨论，目前很多算法的A/B test     都遵循这篇文章的设计模式，在诸多领域都有着广泛的应用。