深度学习推荐系统实战_35_26_在线测试如何在推荐服务器内部实现AB测试
你好，我是王哲这节课，我们来聊一聊推荐系统的线上AB测试。
那上两节课，我们进行了推荐系统离线评估方法和指标的学习。
但是，无论采用哪种方法，离线评估，依然无法完全的还原线上的所有变量。
比如说视频网站最想要提高的指标是用户的观看时长。
那在离线评估的环境下，可以模拟出这个指标呢，显然是非常困难的那即使能够在离线生成这样一个指标，它是不是能够真实客观的反映线上的效果，也要打一个问号。
所以，对于几乎所有的互联网公司来说，线上AB测试都是验证新模型、新功能、新产品是否能够提升效果的。
主要测试方法。
那这节课我们就来讲一讲线上AB测试。
希望通过今天的课程，能帮助你了解到AB测试的基本原理。
Ab测试的分层和分桶的方法，以及怎么在spell access st推荐服务器中实现AB测试模块。
那AB测试又叫做分流测试，或者说分桶测试。
在通过把被测对象随机分成AB两组，分别进行对照测试的方法，得出实验结论。
那具体到到荐模型测测的场景景，它的流程是这样的，先把用户随机的分成实验组和对照组，然后给实验组的用户是以新模型。
对对照组的用户是以旧模型在经过一定时间的测试后，计算出实验组和对照组各项线上的评估模型来比较一定模型的效果差异。
最终挑选出效果更好的推荐模型。
好了，现在我们知道了什么是线上AB测试，那它到底有什么优势来？几乎所有的互联网公司主要要使用它来确定模型的最终的效果呢？你有想过这是什么原因吗？那我总结了一下，主要有三点原因，接下来我们就一起来聊一聊。
那首先，离线评估是无法完全还原线上的工程环境的那一般来讲，离线评估往往不考虑线上环境的延迟、数据丢失、标签数据缺失等等的情况，或者说很难还原线上环境的这些细节。
因此，离线评估环境只能说是理想状态下的工程环境或出的评估结论存在一定的失真的现象。
其次，线上系统的某些商业指标在离线评估中是无法计算的那离线评估一般是针对模型本身进行评估，无法直接的获得与模型相关的其他指标，特别是商业指标。
像我们上节课讲的离线评估，关注的往往是ROC曲线PR曲线的改进，而线上评估却可以全面了解推荐模型带来的用户点击率、留存时长、PV访问量这些比指标的变化。
那其实这些指标才是最重要的商业指标，他们跟公司要达成的商业目标紧密相关。
而这些指标都要由AB测试进行更全面准确的评估。
最后是离线评估，没法完全消除。
数据有偏现象的影响，那什么叫数据有偏呢？那因为离线数据都是系统利用了当前算法生成的数据，因此这些数据本身就不是完全客观中立的，它是用户在当前模型下的反馈。
所以说用户本身可能已经被当前的模型带跑偏了。
你再用这些有偏的数据来衡量你的新模型，得到的结果就可能是不客观的那正是因为离线评估存在着这三点硬伤，所以我们就必须利用线上AB测试来确定模型的最终效果。
明确的这一点，是不是让我们的学习更有方向了呢？接下来我们就再深入去学习一下AB测试的核心原则和评估指标。
那刚才我们说过，AB测试的原理就是把用户分桶后进行对照测试。
这听上去好像没什么难的，但其实我们要考虑的细节还是有很多。
比如说到底怎样才能对用户进行一个公平公正的分桶呢？如果有多组实验在同时做AB测试，怎样做才能让他们互不干扰？下面我们就来详细的讲一讲AB测试的分桶和分层的原则，告诉你让AB测试公平且高效执行的方法是什么样的那在AB测试分桶的过程中，我们需要注意的是样本的独立性和分桶过程的无偏性。
那这里的独立性指的是同一个用户在测试的全程只能被分到同一个桶里。
无偏性指的是在分桶过程中，用户被分到哪个实验桶里，应该是一个纯随机的过程。
举个简单的例子，我们把用户ID是奇数的用户分到对照组，把用户ID是偶数的用户分到实验组。
这个策略只有在用户ID完全是随机生成的前提下，才能说是无偏的。
如果用户ID的奇偶分布不均，我们就无法保证奋斗过程的无偏性。
所以在实践的时候，我们经常会使用一些比较复杂的哈希函数，让用户ID尽量的随机的映射到不同的桶里面。
那说完了分桶，那什么是分层呢？要知道，在实际的AB测试场景下，同一个网站或者说应用，经常要进行多组不同类型的AB测试。
比如说前端组的同学正在进行不同app界面的AB测试的时候，后端组也在进行不同的中间件效率的AB测试。
那同时算法组也有可能在进行推荐场景a和推荐场景b的AB测试。
那这个问题就来了，这么多的AB测试同时进行，我们怎样才能让他们互不干扰呢？你可能会说，这还不简单吗？我们全都并行的进行这些实验，用户都不重叠不就行了。
那这样做当然是可以的，但是效率非常低。
你如果在工作中进行过AB测试，肯定会知道线上的测试资源是非常紧张的。
如果不进行合理的设计，很快所有的流量资源就会被AB测试占满。
为了解决这个问题，我们就要用到AB测试的分层原则了。
Google在一篇关于实验测试平台的论文里，就详细介绍了AB测试分层以及层内分桶的原则。
如果你没看过这篇论文，没有关系，你记住我总结出来的这两句话就够了。
层与层之间的流量，正交同层之间的流量互斥，它是什么意思呢？那接下来我就针对这两句话做一个详细的解释。
首先我们来看层与层之间的流量。
正交这句话，它指的是层与层之间的独立实验的流量，是正交的一批实验用的流量。
穿越每层实验的时候，会被再次随机打散，然后再用于下一层的实释。
这本书好像还是有点抽象。
那我们再来看看文稿中的示意图。
假设在一个x层的实验中，流量被随机平均分成了x一和x二这两部分。
那么当它穿越到y层的实验之后，x一和x二的流量会被随机，并且均匀的分配给y层的两个桶y一和y二。
那如果说y一和y二的x层流量分布不均，那么y层的样本就是有偏的y层的实验结果就会被x层的实验影响，也就没法客观的反映y层实验组和对照组变量的影响了。
那理解了第一句话，我们再来看看什么叫做同层之间的流量互斥。
那这里的互斥具体有两层含义。
第一层是如果同层之间进行多组AB测试，那么不同测试之间的流量不可以重叠，这是第一个互斥。
第二层是说一组AB测试中的实验组和对照组的流量是不重叠的这是第二个互斥。
那在基于用户的AB测试里，互斥的含义还可以被进一步的解读为不同实验之间以及AB测试的实验组和对照组之间的用户应是不重叠的。
特别是对于推荐系统来说，用户体验的一致性是非常重要的。
我们不可以让一个用户在不同的实验组之间来回跳跃，这样会严重的损害用户的实际体验。
也会让不同组的实验结果相互影响。
因此啊在AB测试中，保证同一个用户始终被分配到同一个组中。
是非常有必要的那AB测试的正交与互斥的原则，共同保证了AB测试指标的客观性。
而且由于分层的存在，也让功能不相关的AB测试可以在不同的层上执行。
充分利用了流量资源。
那在清除了AB测试的方法之后，我们要解决的下一个问题就是怎么选取线上AB测试的指标。
那一般来说AB测试是模型上线前的最后一道测试。
那通过AB测试检验的模型，会直接服务于线上用户，来完成公司的商业目标。
因此，AB测试的指标应该与线上业务的核心指标保持一致，这就需要我们因地制宜的制定最合适的推荐指标。
呃，具体怎么做呢？那其实也不困难，就是在实际的工作中，我们需要跟产品运营团队多沟通。
在测试之前大家一起制定大家都认可的评估指标。
那我在文稿的表格中列出了电商类推荐系统、新闻类推荐系统、视频类推荐性的主要线上AB测试评估指标。
你可以参考一下，看了这些指标，我想你也发现了线上AB测试的指标和离线评估指标的差异是非常大的这主要是因为离线评估由于不具备直接计算业务核心指标的条件，因此他才退而求其四选择了偏向于技术评估的模型相关指标。
但公司更关心的是能够驱动业务发展的核心指标，这也是AB测试评估指标的选取原则啊。
总的来说，在具备线上环境条件的时候，利用AB测试验证模型，对核心业务的提升效果是必要的。
从这个意义上来讲，线上AB测试的作用是离线评估永远无法替代的那搞清楚了AB测试的主要方法和指标。
下一步就是让我们一起来在spare resist上实现一个AB测试的模块，彻底掌握它吧。
那既然是线上测试，那我们肯定需要在推荐服务器内部来实现这个AB测试的模块。
那模块的基本框架不难实现，就是针对不同的user ID随机分配给不同的实验桶。
每个桶对应着不同的实验设置。
那比较方便的是我们可以直接在上一篇刚实现过的chinese喜欢功能上进行实验。
那实验组的设置是算法neurroc f那对照组的设置是item to back embedding算法。
接下来我们就说一下详细的实现步骤，你可以参考我在文稿中的代码一起来听。
首先我们在spiracs里边建立了一个模块块AB test,那负责每个用户分配实验设置。
其中a组使用的模型。
Bucket a model是EMB,代表着item to weack embedding算法b组使用的模型。
Bucket b model是neural CF.那除此之外，我们还给不在AB测试的用户中设置了默认模型EMB.那默认模型是不在实验范围内的用户的设置，那模型设置完就到了分配实验组的阶段。
这里我们使用了get confiict by ULID函数，来确定用户所在的实验组，具体怎么做呢？那因为这个函数只接收user ID作为唯一的输入参数。
所以我们利用user ID的hash code,把数值型的ID打散。
然后利用user ID的harsh code和traffic spring number这两个参数进行取余数的操作，根据余数的值来确定user ID在哪一个实验组里。
那你可能对traffic spring number这个参数的作用还不熟悉，我来进一步解释一下。
那这个参数的含义就是说我们把全部的用户分成几份。
这里我把所有的用户分成了五份，让第一份用户参与a组实验。
第二份用户参与b组实验，其余用户继续使用系统的默认设置。
那这样的操作就是所谓的分流操作，也就是把流量划分之后，选取一部分参加a组测试。
那在实际要进行AB测试的业务逻辑中，我们需要调用AB测试模块来获得正确的实验设置。
比如说我们这次选用了猜你喜欢这个功能进行AB测试，就需要在相应的实现。
Reck for you service类中添加AB测试的代码，具体的实现也非常简单，就是调用AB test get conflict by user ID函数，获取用户对应的实验设置，然后把得到的参数model传入后续的业务逻辑代码中。
那在使用我给出的代码的时候，你需要注意。
我设置了一个全局的AB test,使能的标识，config is enable AB test.那你在测试这部分代码的时候，要把这个标识改为true.当然了，在实际的应用中，AB测试的实现当然要比我实现的更复杂一些。
比如不同的实验设置往往是存储在数据库中的，我们需要从数据库中拿到它。
再比如说，为了保证分组时的随机性，我们往往会创建一些复杂的hash code函数，保证能够均匀的把用户分到不同的实验桶中。
但整个AB测试的核心逻辑没有变化，但可以完全参考我们今天的实践过程。
好了，今天的实践就到这里，我们一起来做个总结。
那这节课我们讲解了线上AB测试的基本原理和评估指标，并且在spiro SS上实现了AB测试的模块。
我带你从AB测试的定义和优势设计原则以及在线评估指标这三个方面回顾一下。
那AB测试又叫做分流测试或者分组测试。
它通过把被测对象随机分为AB两组，通过对照测试的方法得出实验结论。
那相比于离线评估，AB测试有三个优势，分别是实验环境，就是线上的真实生产环境，可以直接得到线上的商业指标。
那最后一个是不受离线数据数据有偏现象的影响。
那在AB测试的设计过程中，我们要遵循层与层之间的流量，正交同层之间的流量互斥这一个设计原则，这样才能既正确又高效的同时完成多组AB测试。
那除此之外，在线上评估指标的制定过程中，我们要尽量保证这些指标与线上业务的核心指标保持一致。
那这样才能够更加准确的衡量模型的改进，是不是真正帮助到了公司的业务发展，达成了公司的商业目标。
为了方便你复习，我把一些核心的知识点总结在了文稿中的表格里，你可以去看一看。
最后我们再来看一道思考题，那我们今天讲的AB测试分层和分桶的原则你都了解了吗？那如果我们在测试模型的时候，一个实验是在首页上测试新的推荐模型。
另一个实验是在内容页测试新的推荐模型。
你觉得这两个实验应该放在同一层，还是可以放在不同的层呢？为什么期待在留言区看到你的思考。
那如果有其他的疑问，也欢迎随时提出来，我会尽量一一解答，我们下节课见。