一、推荐系统的评估体系
在推荐系统评估中，经常遇到2类问题：
A/B测试时流量不够用，需要排队进行自己的测试，拖慢实验的新思路和迭代优化模型的进度。
如何选择这么多种离线评估和在线评估测试方法。
小结：建立起一套推荐系统的评估体系。
1.1 评估体系
评估体系：由多种评估方式组成、兼顾效率（用较少资源）和正确性。
图 1 就是一个典型的评估体系示意图。从图中我们可以看到，处于最底层的是传统的离线评估方法，比如 Holdout 检验、交叉检验等，往上是离线 Replay 评估方法，再往上是一种叫 Interleaving 的线上测试方法，最后是线上 A/B 测试。
这4层得以平衡效率和准确性，越底层的方法就负责更多筛选任务，所以要求“快”（类似召回层要快，排序层要准），而在模型快上线前，就应该用最顶层——最接近真实产品体验的A/B测试，来进行最后的模型评估。
图1 推荐系统的评测体系 （出自《深度学习推荐系统》）
1.2 模型筛选过程
栗子：
现在有 30 个待筛选的模型，如果所有模型都直接进入线上 A/B 测试的阶段进行测试，所需的测试样本是海量的，由于线上流量有限，测试的时间会非常长。但如果我们把测试分成两个阶段，第一个阶段先进行初筛，把 30 个模型筛选出可能胜出的 5 个，再只对这 5 个模型做线上 A/B 测试，所需的测试流量规模和测试时间长度都会大大减少。这里的初筛方法，就是我们在评估体系中提到的离线评估、离线 Replay 和在线 Interleaving 等方法。
1.3 两点注意
一个是离线 Replay 这个方法，虽然之前学习离线 Replay 的原理（在离线状态下对线上更新过程进行仿真，让整个评估过程“动”起来。），但是对于它的相关工程架构还没有讲过；
第二个是上面提到过的线上 Interleaving 方法。
二、Netflix 的 Replay 评估方法实践
离线 Replay 方法的原理：离线 Replay 通过动态的改变测试时间点，来模拟模型的在线更新过程，让测试过程更接近真实线上环境。
2.1 未来信息处理
在Replay实现过程中要注意“未来信息”问题，或者叫做“特征穿越”问题。在 Replay 过程中，每次模型更新的时候，我们都需要用历史上“彼时彼刻”的特征进行训练，否则训练和评估的结果肯定是不准确的。
【举栗】
假设 Replay 方法要使用 8 月 1 日到 8 月 31 日的样本数据进行重放，这些样本中包含一个特征，叫做“历史 CTR”，这个特征只能通过历史数据来计算生成。
8 月 20 日的样本就只能够使用 8 月 1 日到 8 月 19 日的数据来生成“历史 CTR”这个特征，绝不能使用 8 月 20 日以后的数据来生成这个特征。在评估过程中，如果我们为了工程上的方便，使用了 8 月 1 日到 8 月 31 日所有的样本数据生成这个特征，供所有样本使用，之后再使用 Replay 的方法进行评估，那我们得到的结论必然是错误的。
为了实现支持这种历史特征的复现，Netflix建立了一套从数据生成到数据处理再到数据存储的数据处理架构。
2.2 Netflix的时光机
Netflix 为了进行离线 Replay 的实验，建立了一整套从数据生成到数据处理再到数据存储的数据处理架构，并给它起了一个很漂亮的名字，叫做时光机（Time Machine）。
在时光机这个架构之上，使用某个时间段的样本进行一次 Replay 评估，就相当于直接穿越到了彼时彼刻，用当时的日志和特征进行模型训练和评估，就像进行了一次时光旅行（Time Travel）一样。
下图 4 就是时光机的架构，图中最主要的就是下图右下角的 Snapshot Jobs（数据快照）模块。它是一个每天执行的 Spark 程序，它做的主要任务就是把当天的各类日志、特征、数据整合起来，形成当天的、供模型训练和评估使用的样本数据。
它还会以日期为目录名称，将样本快照数据保存在分布式文件系统 S3 中（Snapshots），再对外统一提供 API（Batch APIs），供其他模型在训练和评估的时候按照时间范围方便地获取。
S3就是HDFS在amazon 云方案上的实现。
图4 Netflix的离线评估数据流架构——时光机 （出自The Netflix Tech Blog ）
Snapshot Jobs 主任务的源数据来源：图片中Snapshot Jobs模块的上方的 Context Set 模块和左边的 Prana 模块，具体负责的功能如下：
Context Set 模块负责保存所有的历史当天的环境信息。 环境信息主要包括两类：
一类是存储在 Hive 中的场景信息，比如用户的资料、设备信息、物品信息等数据；
另一类是每天都会发生改变的一些统计类信息，包括物品的曝光量、点击量、播放时长等信息。
Prana 模块负责处理每天的系统日志流。 系统日志流指的是系统实时产生的日志，它包括用户的观看历史（Viewing History）、用户的推荐列表（My List）和用户的评价（Ratings）等。这些日志从各自的服务（Service）中产生，由 Netflix 的统一数据接口 Prana 对外提供服务。
小结：
（1）Snapshot Jobs：通过 Context Set 获取场景信息，通过 Prana 获取日志信息，再经过整合处理、生成特征之后，保存当天的数据快照到 S3。
（2）在生成每天的数据快照后，使用 Replay 方法进行离线评估就不再是一件困难的事情了，因为我们没有必要在 Replay 过程中进行烦琐的特征计算，直接使用当天的数据快照（Snapshot Jobs）就可以了。
三、Interleaving 评估方法
3.1 提出的意义
Interleaving 评估方法提出的意义：
它是和 A/B 测试一样的在线评估方法，能够得到在线评估指标；
目的是为了比传统的 A/B 测试用更少的资源，更快的速度得到在线评估的结果。
3.2 Interleaving实现细节
在传统的 A/B 测试中，我们会把用户随机分成两组。一组接受当前的推荐模型 A 的推荐结果，这一组被称为对照组 。另一组接受新的推荐模型 B 的推荐结果，这组被成为实验组。
在 Interleaving 方法中，不再需要两个不同组的用户，只需要一组用户，这些用户会收到模型 A 和模型 B 的混合结果。也就是说，用户会在一个推荐列表里同时看到模型 A 和模型 B 的推荐结果。在评估的过程中，Interleaving 方法通过分别累加模型 A 和模型 B 推荐物品的效果，来得到模型 A 和 B 最终的评估结果。
图5 传统A/B测试和Interleaving方法的比较 （出自The Netflix Tech Blog ）
（1）保证模型的公平性
我们需要考虑推荐列表中位置偏差的问题，要想办法避免来自模型 A 或者模型 B 的物品总排在第一位。因此，我们需要以相等的概率让模型 A 和模型 B 产生的物品交替领先。这就像在野球场打球的时候，两个队长会先通过扔硬币的方式决定谁先选人，再交替来选择队员。
先选模型 A 或者模型 B 的排名第一的物品作为最终推荐列表的第一个物品，然后再交替选择，直到填满整个推荐列表。所以，最后得到的列表会是 ABABAB，或者 BABABA 这样的顺序，而且这两种形式出现的概率应该是相等的，这样才能保证两个模型的公平性。
（2）模型混合的过程
理解 Interleaving 方法混合模型 A 和 B 结果的过程。和刚才说的野球场选人的过程一样，我们先选模型 A 或者模型 B 的排名第一的物品作为最终推荐列表的第一个物品，然后再交替选择，直到填满整个推荐列表。所以，最后得到的列表会是 ABABAB，或者 BABABA 这样的顺序，而且这两种形式出现的概率应该是相等的，这样才能保证两个模型的公平性。
（3）综合效果
最后，我们要清楚推荐列表中的物品到底是由模型 A 生成的，还是由模型 B 生成的，然后统计出所有模型 A 物品的综合效果，以及模型 B 物品的综合效果，然后进行对比。这样，模型评估过程就完成了。
小结：Interleaving 的方法由于不用进行用户分组，因此比传统 A/B 测试节约了一半的流量资源。但是 Interleaving 方法不能彻底替代传统 A/B 测试，在测试一些用户级别而不是模型级别的在线指标时，我们就不能用 Interleaving 方法。
【具体的指标】
比如用户的留存率，用户从试用到付费的转化率等，由于 Interleaving 方法同时使用了对照模型和实验模型的结果，我们就不清楚到底是哪个模型对这些结果产生了贡献。但是在测试 CTR、播放量、播放时长这些指标时，Interleaving 就可以通过累加物品效果得到它们。这个时候，它就能很好地替代传统的 A/B 测试了。
四、作业
在 Interleaving 方法中，推荐列表是由模型 A 和模型 B 的结果共同组成的，那如果模型 A 和模型 B 的结果中有重叠怎么办？是保留模型 A 的结果还是模型 B 的结果呢？你有什么好的想法吗？
【答】可以随机交替选择模型A或B来显示，如果本次随机选择了模型A，那下次可以选择模型B，这样不丢失模型A和B的信息。
