深度学习推荐系统实战_36_27_评估体系如何解决AB测试资源紧张的窘境
你好，我是王哲。
今天我想和你聊一聊推荐系统的评估体系。
我们在进行推荐系统评估的时候，经常会遇到两类问题。
一类是这样的，在做线上AB测试的时候，流量经常不够用。
另排队，等别人先做完实验之后，才能进行自己的实验。
那线上AB测试资源紧张的窘境会大大拖慢。
我们实验新思路、迭代优化模型的速度。
另一类是离线评估，加上在线评估，有那么多的测试方法。
在实际的工作中，我们到底应该选择哪一种用来测试还是都要覆盖到呢？那其实这两个问题的答案是有深刻联系的，并不是孤立的。
我认为最好的办法就是建立起一套推荐系统的评估体系，用它来解决不同评估方法的评合问题，以及线上AB测试资源紧张的问题。
这节课我就带你一起来理清如何建立起一整套推荐系统的评估体系。
首先什么是评估体系呢？我先给它下一个定义。
推荐系统的评估体系，指的是由多种不同的评估方法组成的，兼顾效率和正确性的一整套用于评估推荐系统的解决方案。
一个成熟的推荐系统评估体系，应该综合考虑评估效率和正确性，可以利用很少的资源，快速的筛选出效果更好的模型。
那对于一个商业公司来说，最公正也是最合理的。
评估方法，就是进行线上测试评估模型是否能够更好的达成公司或者团队的商业目标。
但是正如我们开头说的那个问题那样，线上AB测试要占用宝贵的线上流量资源。
这些有限的线上测试机会远远还不能满足算法工程师改进模型的需求。
所以咱们有效的把线上和离线测试结合起来，提高测试的效率就是我们迫切的需求。
那我们该怎么去构建起一整套评估体系呢？横稿中的图一就是一个典型的评估体系示意图。
结合这个示意图，我们可以看到处于最底层的是传统的离线评估方法，比如后道检验、交叉检验等等。
往上是离线replay评估方法，再往上是一种叫做interliving的线上测试方法，我们等会儿还会来详细讲。
最后是线上AB测试。
这四层结构共同构成了完整的评估体系，做到评估效率和评估正确性之间的平衡。
越是底层的方法就会承担越多，筛选掉改进思路的任务。
那这时候评估效率就成了更关键的考虑因素。
这个阶段对于正确性的评估，我们就没有过多苛刻的要求了。
总的来说，离线评估由于有着更多可供利用的计算资源，可以更高效、更快速的筛选到那些不靠谱的模型改进思路，所以被放在了第一层的位置。
随着候选模型被一层层筛选出来，越接近正式上线的阶段，评估方法对评估正确性的要求就越严格。
因此，在模型正式上线之前，我们应该以最接近真实产品体验的AB测试来做最后的模型评估，产生最具有说服力的在线指标之后，才能够进行最终的模型上线，完成模型改进的迭代过程。
想了这么多，你可能会觉得道理没问题，但工作中真的是这样吗？那不如我们来看一个例子。
那我在文稿中放了一张示意图，它形象的展示了一个工作中筛选模型的过程。
我们一起来看一下，假设现在有三十个待筛选的模型，如果所有的模型都直接进入线上AB测试的阶段，进行测试所需的测试样本是海量的。
由于线上流量有限，测试的时间会非常长。
但如果我们把测试分成两个阶段，第一个阶段先进行初筛，把三十个模型筛选出可能胜出的五个。
在只对这五个模型做线上AB测试，把所需的测试流量规模和测试时间长度都会大大减少。
而这里的初筛，就是我们在评估体系中提到的离线评估、离线replay和在线intel lain等方法。
到这儿，我想你已经清楚了。
什么是推荐系统的评估体系，以及评估体系是由哪些方法组成的。
但在这些评估方法中，我们还应该要注意两点，一个是离线replay这个方法。
虽然我们之前讲过离线replay的原理，但是对于它的相关的工程架构还没有讲过。
那第二个是上面提到过的interliving方法。
接下来，我们就借着流媒体巨头NAFA lis的实践方案来讲解一下离线replay和在线interliving的原节。
那我们先借着文稿中的示意图来回顾一下离线replay方法的原理啊。
离线replay通过动态的改变测试时间点来模拟模型的在线更新过程，让测试过程更接近线上真实环境。
但是在replay方法的实现过程中，存在一个很棘手的工程问题，就是我们总提到的未来信息问题，或者叫做特征穿越问题。
因此，在replay过程中，每次模型更新的时候，都需要用历史上彼时彼刻的特征进行训练。
否则训练和评估的结果肯定是不正确的。
我来举个例子，那假设replay方法要使用八月一日到八月三十一日的样本数据进行存放。
那这些样本中包含一个特征叫做历史CTR,那这个特征只能通过历史数据的计算来完成。
比如说八月二十日的样本，就只能够使用八月一日到八月十九日的数据来生成历史CTR这个特征绝不能使用八月二十日之后的数据来生成这个特征。
那在评估的过程中，如果我们为了工程上的方法之用，八月一号到八月三十日，所有的样本数据来生成这个特征，供所有的样本使用之后，再用replay的方法进行评估。
那我们得到的结论就必然是错误的。
因为未来的数据穿越到了当前的特征上。
那问题来了，在工程上为了方便按照replay方法进行模型评估，我们应该怎么去建立一套数据处理的架构，支持这种历史特征的复现呢？接下来我们看一看neffx是怎么解决这个问题的那naface为了进行离线repay的实验，建立了一整套从数据生成数据处理，再到数据存储的处理架构，并且给它起了一个很漂亮的名字，叫做时光机。
我在文稿中给出的时光机的架构。
那仔细看这张图图中最主要的模块就是一个叫snapshot jobs的模块。
那中文叫做数据快照模块，它是一个每天执行的spark程序。
它做的主要任务就是把当天的各类日志特征数据整合起来，形成当天的供模型训练和评估使用的样本数据。
它还会以日期为目录名称，把样本快照数据保存在分布式文件系统s ray里边，再对外统一提供API供其他模型在训练和评估的时候，可以按照时间范围方便的获取。
那这个snapshot jobs主任务的原数据是从哪里来的呢？你可以重点关注它上方的context site模块和左边的pronna模块。
接下来我再详细和你说说这两个模块的任务。
Context site模块负责保存所有的历史当天的环境信息。
环境信息主要包括两类类类类存存在在中的的场景信息。
比如用用户的资料、设备的信息、物品的信息，这样的数据，另一类是每天都会发生改变的一些统计类信息，包括物品的曝、量量、击、量量、播放时长这样信信息。
而praca模块负责每天处理系统日志流，那系统日志流指的是系统实时产生的日志，它包括用户的观看历史，它户的推荐列表和用户的评价等等。
这些日志从各自的服务中产生由net flist的统一数据接口prrad a对外提供服务。
因此啊，snapshot jobs这个核心模块的每天的任务就是通过site获取场景信息，通过prada获取日志信息，在经过整合的处理生成特征之后，保存当天的数据快照到s ray.那在每天生成数据快照之后，使用replay方法进行离线评估，就不再是一件困难的事情了。
因为我们没有必要在replay过程中进行繁琐的特征计算，直接使用当天的数据快照就可以了。
那在时光机这个架构上，使用某个时间段的样本进行一次replay评估，就相当于直接穿越到了彼时彼刻用当时的日志和特征进行模型的训练和评估。
就像进行了一次时光旅行一样，他讲完了离线replay的工程实践方法。
那我们再聊一聊什么叫做interliving的在线评估方法。
那interliving的评估方法的提出的意义是什么呢？主要有两个方面。
首先它是和AB测试一样的在线评估方法，所以能够得到在线评估方标。
其次，他提出的目的是为了比传统的AB测试，用更少的资源更快的速度得到在线评估的结果。
那清楚了intelliliving评估方法的意义，我们就可以更好的理解它的技术细节了。
下面我们对比AB测试，来看一看intel living方法的实现的具体过程是怎么样的那在传统的AB测试中，我们会把用户随机分成两组，一组接受当前推荐模型a的推荐结果，这组叫做对照组。
另一组接受新的推荐模型b的推荐结果，这组叫做实验组。
而在intelliliving方法中，不再需要两个不同组的用户了，只需要一组用户，这些用户会收到模型a和模型b的混合结果。
也就是说用户会在一个推荐列表里面同时看到模型a和模型b的推荐结果。
那在评估的过程中，intellive ving方法会通过分别累加模型a和模型b推荐的物的效果。
另得到模型a和模型b最终的评估结果。
你可以看一下我在文稿中放的示意图，它可以帮助我们更形象的对比AB测试和intel liging方法。
那你可能想问了，在使用特运方法法进行试的时候，我们应该怎么保证模型intelia和模型b的测测试是公平的呢？那如果有一个模型的结果总排在第一位，那么对另另外一个模型总不不平平吗？要那这个问题很好，我们确需要考虑推荐列表中位置偏差的问题，要想办法避免来自模型a或者模型b的物品总是排在第一位。
因此我们需要以相等的概率让模型a和b产生的物品交替领先。
这就像在野球场打球的时候，两个队长会先通过掷硬币的方式决定谁先选人，再交替来选择队员。
那理解的原理，我们再结合文稿里的图示，进一步理解特运用方法，混合模型intelea和b的结果的过程。
那和刚才说的野球场选人的过程一样，我们先选模型a或者模型b排名第一的物品作为最终推荐列表的第一个物品，然后再交替选择，直到填满整个推荐列表。
所以最后得到的列表会是这样的，要么是ABABAB或者是BABABA这样的顺序，而且这两种顺序出现的概率应该是相等的，这样才能保证两个模型的公平性。
最后我们要清楚推荐列表中的物品到底是由模型a生成的，还是由模型b生成的，然后统计出所有模型a物品的综合效果和模型b物品的综合效果，然后进行对比，这样评估过程就完成了。
总的来说，特inteligin方法由于不用进行用户分组，因此比传统AB测试节约了一半的流量资源。
但是特intelimin方法能彻底的替代传统AB测试吗？其实也不能在测试一些用户级别，而不是模型级别的在线指标时，就不能用特inteliming方法。
比如用户的留存率，用户从使用到付费的转化率等等。
由于英特liliving方法同时使用了对照模型和实验模型的结果，我们就不清楚到底是哪个模型对这些结果产生了贡献。
但是在测试CTR、播放量、播放时长这些指标的时候，特intelimin就可以通过累加物品效果得到这些指标。
这个时候它就可以很好的替代传统的AB测试到这里，我们就形成了一个完整、高效且准确的评估系统。
希望你能从整体的角度重新审视一遍这个系统中的每个方法。
如果有不清楚的，再回头看一看，回顾一下我刚才讲的知识点。
好了，那我们一起来总结一下今天的重点吧。
这节课我们利用之前讲过的知识，总结出了推荐系统的评估体系。
这个评估体系由传统离线评估、离线replay、线上intel living以及线上AB测试这四个层级组成。
这四个层级由下到上的评估效率逐渐降低，但是评估的准确性逐渐升高。
他们共同组成了一个能够高效筛选候选模型的评估体系。
针对这个评估体系中的两个要点，离线replay和intelt living方法，我们又深入学习了他们的工程架构和实现细节，其中离线replay借鉴了NAFFIX光机的经验。
那这个时光机的数据流体系，通过融合日流和场景信息生成天级别的数据快照，并对外提供统一的API供模型训练和评估使用。
使用时就像做了一次时光旅行。
那对于用方法我们应该清楚他们实现的三个要点，一是它不进行用户分组。
二是它的实验推荐列表的生成过程是通过间隔的选择模型introlea和模型b的推荐物品得到的。
三是为了保证它的公平，b要随机的选择。
第一个物品是来自模型a还是模型b就像野球场选人一样，完成推荐列表的生成，还是老习惯？我把这节课的重要知识点总结在了文稿中，方便你回顾这节课，也是我们推荐模型评估片的最后一节课。
希望通过整个模型评估片的学习，你不仅能够熟悉每一种评估方法，而且能够清楚它们之间的区别和联系，形成一个高效的评估体系。
相信它会加速你模型迭代的速度，对你的实际工作产生积极的影响。
最后我们来看一道思考题。
那在的运用方法中，推荐列表是由模型intellea和模型b结果共同组成的那如果模型a和模型b的结果中有重叠怎么办呢？是保留a的结果还是b的结果呢？你有什么好的想法吗？那今天讲的评估体系，你知道怎么建立了吗？欢迎把你的思考和疑问写在留言区。
那不妨也把这节课分享给需要的朋友们，我们下节课见。