27 评估体系:如何解决A B测试资源紧张的窘境?
你好,我是王喆。
我们在进行推荐系统评估时经常会遇到两类问题。
一类是在做线上A/B测试的时候,流量经常不够用,要排队等别人先做完测试之后才能进行自己的测试。线上A/B测试资源紧张的窘境,会大大拖慢我们试验的新思路,以及迭代优化模型的进度。
另一类是,离线评估加上在线评估有那么多种测试方法,在实际工作中,我们到底应该选择哪一种用来测试,还是都要覆盖到呢?
其实,这两个问题的答案是有深刻联系的,并不是孤立的。我认为最好的解决办法就是,建立起一套推荐系统的评估体系,用它来解决不同评估方法的配合问题,以及线上A/B测试资源紧张的问题。这节课,我就带你一起来厘清如何建立起一整套推荐系统评估体系。
什么是推荐系统的评估体系?
首先,什么是评估体系呢?我先给它下一个定义,推荐系统的评估体系指的是,由多种不同的评估方式组成的、兼顾效率和正确性的,一套用于评估推荐系统的解决方案。一个成熟的推荐系统评估体系应该综合考虑评估效率和正确性,可以利用很少的资源,快速地筛选出效果更好的模型。
那对一个商业公司来说,最公正也是最合理的评估方法就是进行线上测试,来评估模型是否能够更好地达成公司或者团队的商业目标。但是,正如我们开头所说,线上A/B测试要占用宝贵的线上流量资源,这些有限的线上测试机会远远不能满足算法工程师改进模型的需求。所以如何有效地把线上和离线测试结合起来,提高测试的效率,就是我们迫切的需求。
那我们该怎么去构建起一整套评估体系呢?图1就是一个典型的评估体系示意图。从图中我们可以看到,处于最底层的是传统的离线评估方法,比如Holdout检验、交叉检验等,往上是离线Replay评估方法,再往上是一种叫Interleaving的线上测试方法,我们等会还会详细介绍,最后是线上A/B测试。
这四层结构共同构成完整的评估体系,做到了评估效率和评估正确性之间的平衡,越是底层的方法就会承担越多筛选掉改进思路的任务,这时候“评估效率”就成了更关键的考虑因素,那对于“正确性”的评估,我们反而没有多么苛刻的要求了。
总的来说,离线评估由于有着更多可供利用的计算资源,可以更高效、快速地筛选掉那些“不靠谱”的模型来改进思路,所以被放在了第一层的位置。
随着候选模型被一层层筛选出来,越接近正式上线的阶段,评估方法对评估“正确性”的要求就越严格。因此,在模型正式上线前,我们应该以最接近真实产品体验的A/B测试,来做最后的模型评估,产生最具说服力的在线指标之后,才能够进行最终的模型上线,完成模型改进的迭代过程。
讲了这么多,你可能会觉得,道理没问题,但工作中真的是这样吗?不如,我们来看个例子。下图就是一个很形象的工作中的模型筛选过程。
假设,现在有30个待筛选的模型,如果所有模型都直接进入线上A/B测试的阶段进行测试,所需的测试样本是海量的,由于线上流量有限,测试的时间会非常长。但如果我们把测试分成两个阶段,第一个阶段先进行初筛,把30个模型筛选出可能胜出的5个,再只对这5个模型做线上A/B测试,所需的测试流量规模和测试时间长度都会大大减少。这里的初筛方法,就是我们在评估体系中提到的离线评估、离线Replay和在线Interleaving等方法。
到这里,我想你已经清楚了什么是推荐系统的评估体系,以及评估体系是有哪些方法组成的。但在这些组成方法中,我们还有两点要重点注意:一个是离线Replay这个方法,虽然我们之前讲过离线Replay的原理,但是对于它的相关工程架构还没有讲过;第二个是上面提到过的线上Interleaving方法。 下面,我就借着流媒体巨头Netflix的实践方案,来讲解一下离线Replay和在线Interleaving的细节。
Netflix的Replay评估方法实践
借着下图3,我们来回顾一下,第24讲学过的离线Replay方法的原理:离线Replay通过动态的改变测试时间点,来模拟模型的在线更新过程,让测试过程更接近真实线上环境。
但是在Replay方法的实现过程中,存在一个很棘手的工程问题,就是我们总提到的“未来信息”问题,或者叫做“特征穿越”问题。因此在Replay过程中,每次模型更新的时候,我们都需要用历史上“彼时彼刻”的特征进行训练,否则训练和评估的结果肯定是不准确的。
我来举个例子,假设Replay方法要使用8月1日到8月31日的样本数据进行重放,这些样本中包含一个特征,叫做“历史CTR”,这个特征只能通过历史数据来计算生成。
比如说,8月20日的样本就只能够使用8月1日到8月19日的数据来生成“历史CTR”这个特征,绝不能使用8月20日以后的数据来生成这个特征。在评估过程中,如果我们为了工程上的方便,使用了8月1日到8月31日所有的样本数据生成这个特征,供所有样本使用,之后再使用Replay的方法进行评估,那我们得到的结论必然是错误的。
那么问题来了,在工程上,为了方便按照Replay方法进行模型评估,我们应该怎么去建立一套数据处理的架构,支持这种历史特征的复现呢?接下来,我们就看一看Netflix是怎么解决这个问题的。
Netflix为了进行离线Replay的实验,建立了一整套从数据生成到数据处理再到数据存储的数据处理架构,并给它起了一个很漂亮的名字,叫做时光机(Time Machine)。
下图4就是时光机的架构,图中最主要的就是Snapshot Jobs(数据快照)模块。它是一个每天执行的Spark程序,它做的主要任务就是把当天的各类日志、特征、数据整合起来,形成当天的、供模型训练和评估使用的样本数据。它还会以日期为目录名称,将样本快照数据保存在分布式文件系统S3中(Snapshots),再对外统一提供API(Batch APIs),供其他模型在训练和评估的时候按照时间范围方便地获取。
这个Snapshot Jobs主任务的源数据是从哪来的呢?你可以重点关注它上方的Context Set模块和左边的Prana模块。接下来,我再详细和你说说这两个模块的任务。
Context Set模块负责保存所有的历史当天的环境信息。 环境信息主要包括两类:一类是存储在Hive中的场景信息,比如用户的资料、设备信息、物品信息等数据;另一类是每天都会发生改变的一些统计类信息,包括物品的曝光量、点击量、播放时长等信息。
Prana模块负责处理每天的系统日志流。 系统日志流指的是系统实时产生的日志,它包括用户的观看历史(Viewing History)、用户的推荐列表(My List)和用户的评价(Ratings)等。这些日志从各自的服务(Service)中产生,由Netflix的统一数据接口Prana对外提供服务。
因此,Snapshot Jobs这个核心模块每天的任务就是,通过Context Set获取场景信息,通过Prana获取日志信息,再经过整合处理、生成特征之后,保存当天的数据快照到S3。
在生成每天的数据快照后,使用Replay方法进行离线评估就不再是一件困难的事情了,因为我们没有必要在Replay过程中进行烦琐的特征计算,直接使用当天的数据快照就可以了。
在时光机这个架构之上,使用某个时间段的样本进行一次Replay评估,就相当于直接穿越到了彼时彼刻,用当时的日志和特征进行模型训练和评估,就像进行了一次时光旅行(Time Travel)一样。
Interleaving评估方法是什么
讲完了离线Replay的工程实现方法,我们再来聊一聊什么是Interleaving在线评估方法。
那Interleaving评估方法提出的意义是什么呢?主要有两方面:首先,它是和A/B测试一样的在线评估方法,能够得到在线评估指标;其次,它提出的目的是为了比传统的A/B测试用更少的资源,更快的速度得到在线评估的结果。
清楚了Interleaving评估方法提出的意义,我们就可以更好地理解Interleaving方法的具体细节了。下面,我们对比A/B测试,来看看Interleaving方法的具体实现过程。
在传统的A/B测试中,我们会把用户随机分成两组。一组接受当前的推荐模型A的推荐结果,这一组被称为对照组 。另一组接受新的推荐模型B的推荐结果,这组被成为实验组。
在Interleaving方法中,不再需要两个不同组的用户,只需要一组用户,这些用户会收到模型A和模型B的混合结果。也就是说,用户会在一个推荐列表里同时看到模型A和模型B的推荐结果。在评估的过程中,Interleaving方法通过分别累加模型A和模型B推荐物品的效果,来得到模型A和B最终的评估结果。
下图可以帮助我们更形象地对比A/B测试和Interleaving方法。
那你可能想问了,在使用Interleaving方法进行测试的时候,我们该怎么保证对模型A和模型B的测试是公平的呢?如果有一个模型的结果总排在第一位,这对另一个模型不就不公平了吗?
这个问题很好,我们确实需要考虑推荐列表中位置偏差的问题,要想办法避免来自模型A或者模型B的物品总排在第一位。因此,我们需要以相等的概率让模型A和模型B产生的物品交替领先。这就像在野球场打球的时候,两个队长会先通过扔硬币的方式决定谁先选人,再交替来选择队员。
理解了原理,我们再结合下面的图示,来进一步理解Interleaving方法混合模型A和B结果的过程。和刚才说的野球场选人的过程一样,我们先选模型A或者模型B的排名第一的物品作为最终推荐列表的第一个物品,然后再交替选择,直到填满整个推荐列表。所以,最后得到的列表会是ABABAB,或者BABABA这样的顺序,而且这两种形式出现的概率应该是相等的,这样才能保证两个模型的公平性。
最后,我们要清楚推荐列表中的物品到底是由模型A生成的,还是由模型B生成的,然后统计出所有模型A物品的综合效果,以及模型B物品的综合效果,然后进行对比。这样,模型评估过程就完成了。
总的来说,Interleaving的方法由于不用进行用户分组,因此比传统A/B测试节约了一半的流量资源。但是Interleaving方法能彻底替代传统A/B测试吗?其实也不能,在测试一些用户级别而不是模型级别的在线指标时,我们就不能用Interleaving方法。
比如用户的留存率,用户从试用到付费的转化率等,由于Interleaving方法同时使用了对照模型和实验模型的结果,我们就不清楚到底是哪个模型对这些结果产生了贡献。但是在测试CTR、播放量、播放时长这些指标时,Interleaving就可以通过累加物品效果得到它们。这个时候,它就能很好地替代传统的A/B测试了。
到这里,我们就形成了一个完整、高效且准确的评估系统。希望你能从整体的角度重新审视一遍这个体系中的每个方法,如果有不清楚的,再好好回顾一下我讲的知识点。
小结
这节课,我们利用之前讲过的知识,总结出了推荐系统的评估体系。这个评估体系由传统离线评估、离线Replay、线上Interleaving,以及线上A/B测试四个层级组成。这四个层级由下到上评估效率逐渐降低,但是评估的准确性逐渐升高,它们共同组成一个能够高效筛选候选模型的评估体系。
针对这个评估体系中的两个要点,离线Replay实践和Interleaving方法,我们又深入学习了它们的工程架构和实现细节。
其中,离线Replay借鉴了Netflix时光机的经验,这个时光机的数据流体系通过融合日志流和场景信息数据,生成天级别的数据快照,并对外提供统一的API,供模型训练和评估使用,使用时就像做了一次时光旅行。
对于Interleaving方法,我们应该清楚它实现的三个要点:
- 它不进行用户分组;
- 它的实验推荐列表是通过间隔地选择模型A和模型B的推荐物品得到的;
- 为了保证它的公平性,我们要从模型A或者模型B中随机选择第一个物品,就像野球场选人一样完成推荐列表的生成。
还是老习惯,我把这节课的重要知识点总结在了下面的表格里,方便你及时回顾。
这节课也是我们模型评估篇的最后一节课,希望通过整个模型评估篇的学习,你不仅能够熟悉起每一种评估方法,而且能够清楚它们之间的区别和联系,形成一个高效的评估体系。相信它会加快你模型迭代的速度,对你的实际工作产生非常积极的影响!
课后思考
在Interleaving方法中,推荐列表是由模型A和模型B的结果共同组成的,那如果模型A和模型B的结果中有重叠怎么办?是保留模型A的结果还是模型B的结果呢?你有什么好的想法吗?
今天讲的评估体系,你知道怎么建立了吗?欢迎把你的思考和疑问写在留言区,不妨也把这节课分享给你的朋友们,我们下节课见!
- fsc2016 👍(32) 💬(1)
问题:和选择推荐第一个商品的逻辑一样,如果第一次出现重叠商品,可以随机归入到A或B模型中,以后进行交替并入 老师,实战课程快结束了,学到了很多,非常感谢老师分享和解答问题。请问老师,github还有没有相关的推荐实战项目以供继续学习了。或者在个人提升方面,可以从哪些方面继续提升了。
2020-12-16 - 那时刻 👍(6) 💬(2)
在 Interleaving 方法中,如果模型 A 和模型 B 的结果中有重叠怎么办?我感觉可以随机交替选择模型A或B来显示,如果本次随机选择了模型A,那下次可以选择模型B,这样不丢失模型A和B的信息。 另外,请问老师,线上是否可以同时采用Interleaving方法和AB测试呢?我感觉如果两个测试方法不正交的话,是可以的。
2020-12-16 - 科学养牛 👍(3) 💬(1)
历史快照怎么办呢?是还要一天一天的补回来吗
2021-07-13 - 笑笑是个好孩子 👍(0) 💬(2)
时光机里面的S3是什么啊?
2021-06-29 - 范闲 👍(0) 💬(1)
1.A模型和B模型交叉选择。详细点说就是上次选A,这次选B 2.不过从现在的情况来看,本质上可以当做同类模型的不同版本,可以对流量做切分。比如80%走A模型,20%走B模型。离线的时候再颠倒过来走。这样其实可以更好的观察效果
2021-01-26 - 浣熊当家 👍(0) 💬(3)
对于思考题,我的想法是重合的部分既属于A模型也属于B模型,在评估两个模型的时候都把它算上,比较能真实反映A和B的performance
2020-12-22 - Wiiki 👍(0) 💬(1)
王老师,您好,推荐系统实战篇总体快告一段落了,感谢您的倾情分享~ 还想问一下呀,咋们的课程后续会介绍推荐系统实时方面的课程吗,以及flink在实时推荐中的应用~
2020-12-21 - Alan 👍(2) 💬(0)
答:我认为在设计一个比较相似度权重累加计算系统。例如:A模型计算结果(a,c,d,a)-(a2,c1,d2),B模型计算结果(a,b,e,d)-(a1,b1,d1,d1),于是推荐的结果(a3,b1,c1,d1,e1),很明显a排在最前面即可。至于保留的问题,可以根据用户点击结果,来调整的A模型与B模型的权重,二者并存。若是必须留存,那就留下推荐模型A((a2,c1,d2))与用户反馈结果(a2,c1),相似度最高的A模型。
2021-04-08 - Geek_8a732a 👍(1) 💬(0)
交替等概率分配到模型A和模型B中去
2021-08-23 - Geek_742481 👍(1) 💬(0)
关于测试框架的介绍,好像老师的https://zhuanlan.zhihu.com/p/68509372 这篇文章介绍的更详细 ^_^
2021-06-10 - ꧁꫞꯭R꯭e꯭i꯭r꯭i꯭꫞꧂ 👍(0) 💬(0)
对于课后问题:我不太认同随机选择的方法,我觉得把它作为第三类对象处理会不会更好?相当于这类对象即算作模型A,又算作模型B,这样我觉得就比较公平,因为如果只重复一部电影的话,那么随机将导致不公平;另外,如果我的推荐列表对象少的话,比如业务上我只需要推荐五个对象,那么一部电影的随机将造成比较大的误差。因此我不太认同评论区中随机的方法。
2023-02-01