32. 推荐系统的测试方法及常用指标介绍.pdfVIP

当我们刚开始学习推荐系统的时候，我就希望你想清楚为什么要做推荐系统。在 逐渐深入的过程中，我开始唠叨推荐系统的林林总总。 到了今天，假如你已经有了自己的推荐系统，这个系统已经上线，代替了以前绝 大多数人工的工作，夜以继日地工作，为电商网站创造销售额，为信息流创造阅 读时间和互动，为社交网站创造社交关系。 为什么要关注指标 然而，这样你就可以安心睡大觉了吗？显然你想错了，它成功上线时，也是你失 业的时候，我们暂且不说是否真的有这一天。就算是一切正常运作，你还是需要 每天把这个系统捧在手心，教它在刁钻的用户面前如何长大，既要小心它学坏， 也要小心它偷懒不学无术。 总之，养过孩子的人会懂的。面对推荐系统这样一个有诸多复杂因素联动起作用 的系统，要时时刻刻知道它好不好，健不健康，你同样需要掌握一些测试方法和 检测指标。 推荐系统的测试方法 在最开始几篇中，我说过你需要有不确定性思维，但是这绝不是帮你在老板那里 开脱的说辞。 推荐系统也需要测试，只是它不同于传统的功能测试。传统软件的功能测试，功 能的响应是有预期的，点击一个加关注按钮，应该有什么响应，是被产品文档明 确规定的；也因此在开发功能的时候，可以同步写出测试用例来。 这非常明白，在功能开发时，你做了任何改动，只要跑一下测试用例，逻辑对不 对就一目了然了。反观推荐系统就没那么容易了，你什么都没动，可能两次推荐 的结果都有可能不一样，而且很可能这个不一样也是你自己或者你老板要求的。 那么推荐系统要怎么测试呢？与其说推荐系统没有确定性的预期响应，不如说推 荐系统的响应维度更高。 因为确定性的功能响应像是一个点，而推荐系统的响应则是高维空间中的一个区 域，而不是一个点。那么是不是推荐系统不需要单元测试了呢？显然也不是。 归纳起来，推荐系统的测试方法有四种： 业务规则扫描、离线模拟测试、在线 对比测试、用户访谈。 1. 业务规则扫描 首先，业务规则扫描本质上就是传统软件的功能测试。确定的业务规则会对应有 确定的规则，这些规则就可以翻译成单元测试，像是运行单元测试那样，对推荐 系统逐一扫描业务规则。 通常这些业务规则对测试的要求也有“软的”和“硬的”两种。前者会对业务规则违 反情况做一个基线规定，比如触发几率小于万分之一，在扫描测试时统计触发次 数，只要统计触发几率不超过基线，就算是合格。 而硬的规则，就是一票否决，例如一些业务黑名单，简直就是高压线，测试时碰 不得，碰了就是 Bug，就要想办法修正。 除了业务规则，还有一些容易被人忽视的地方，比如绝大多数推荐模型都涉及了 数学计算，而数学计算中也有一些潜在的规则不能违反。 比如除数不能为 0 ，比如计算机的浮点数精度有限，经过一些指数运算后可能就 出现预期之外的结果，还可能一些连续相乘的计算要防止出现 0 的乘数，类似 这些在计算中的潜在业务规则，也需要扫描测试。 2. 离线模拟测试 其次，就是在离线模拟测试。这是一种军事演习式的测试。模拟测试当然无法代 替真实数据，但是也能暴露一些问题。通常做法是先收集业务数据，也就是根据 业务场景特点，构造用户访问推荐接口的参数。 这些参数要尽量还原当时场景，然后拿这些参数数据去实时访问推荐推荐，产生 推荐结果日志，收集这些结果日志并计算评测指标，就是离线模拟测试。 显然，离线模拟测试是失真的测试，并且评测指标也有限，因为并不能得到用户 真实及时的反馈。但是仍然有参考意义。 这些模拟得到的日志可以统称为曝光日志，它可以评测一些非效果类指标，例如 推荐覆盖率，推荐失效率，推荐多样性等。关于这些指标具体含义，稍后再讲。 那是不是离线模拟测试就对效果一无所知、无法模拟呢？ 也并不是，有一种办法是，利用历史真实日志构造用户访问参数，得到带评测接 口的结果日志后，结合对应的真实反馈，可以定性评测效果对比。 比如，可以评测推荐结果的 TopK 的准确率，或者排序效果 AUC 。这些模型效 果类指标，虽然不能代表最终关注的商业指标，但是两者之间一般存在一定的相 关性。 通常来说 TopK 准确率高，或者 AUC 高于 0.5 越多，对应的商业指标就会越 好，这是一个基本假设。通过离线模拟评测每一天的模型效果指标，同时计算当 天真实的商业指标，可以绘制出两者之间的散点图，从而回归出一个简单的模型， 用离线模型效果预估上线后真实商业指标。 3. 在线对比测试 第三种测试方法就是真正的实战了，那就是 ABTest ，即在线对比测试，分流量 做真实的评测。这需要