27 | 评估体系：如何解决A/B测试资源紧张的窘境？

我们在进行推荐系统评估时经常会遇到两类问题。

一类是在做线上 A/B 测试的时候，流量经常不够用，要排队等别人先做完测试之后才能进行自己的测试。线上 A/B 测试资源紧张的窘境，会大大拖慢我们试验的新思路，以及迭代优化模型的进度。

另一类是，离线评估加上在线评估有那么多种测试方法，在实际工作中，我们到底应该选择哪一种用来测试，还是都要覆盖到呢？

其实，这两个问题的答案是有深刻联系的，并不是孤立的。我认为最好的解决办法就是，建立起一套推荐系统的评估体系，用它来解决不同评估方法的配合问题，以及线上 A/B 测试资源紧张的问题。这节课，我就带你一起来厘清如何建立起一整套推荐系统评估体系。

一个是离线 Replay 这个方法，虽然我们之前讲过离线 Replay 的原理，但是对于它的相关工程架构还没有讲过；第二个是上面提到过的线上 Interleaving 方法。 下面，我就借着流媒体巨头 Netflix 的实践方案，来讲解一下离线 Replay 和在线 Interleaving 的细节。

Netflix 的 Replay 评估方法实践

Context Set 模块负责保存所有的历史当天的环境信息。 环境信息主要包括两类：一类是存储在 Hive 中的场景信息，比如用户的资料、设备信息、物品信息等数据；另一类是每天都会发生改变的一些统计类信息，包括物品的曝光量、点击量、播放时长等信息。Prana 模块负责处理每天的系统日志流。 系统日志流指的是系统实时产生的日志，它包括用户的观看历史（Viewing History）、用户的推荐列表（My List）和用户的评价（Ratings）等。这些日志从各自的服务（Service）中产生，由 Netflix 的统一数据接口 Prana 对外提供服务。

Interleaving 评估方法是什么

小结

这节课，我们利用之前讲过的知识，总结出了推荐系统的评估体系。这个评估体系由传统离线评估、离线 Replay、线上 Interleaving，以及线上 A/B 测试四个层级组成。这四个层级由下到上评估效率逐渐降低，但是评估的准确性逐渐升高，它们共同组成一个能够高效筛选候选模型的评估体系。针对这个评估体系中的两个要点，离线 Replay 实践和 Interleaving 方法，我们又深入学习了它们的工程架构和实现细节。其中，离线 Replay 借鉴了 Netflix 时光机的经验，这个时光机的数据流体系通过融合日志流和场景信息数据，生成天级别的数据快照，并对外提供统一的 API，供模型训练和评估使用，使用时就像做了一次时光旅行。对于 Interleaving 方法，我们应该清楚它实现的三个要点：它不进行用户分组；它的实验推荐列表是通过间隔地选择模型 A 和模型 B 的推荐物品得到的；为了保证它的公平性，我们要从模型 A 或者模型 B 中随机选择第一个物品，就像野球场选人一样完成推荐列表的生成。还是老习惯，我把这节课的重要知识点总结在了下面的表格里，方便你及时回顾。