RecSys2023 | 重新审视推荐中的评估方案

张小磊

发布于 2023-09-27 12:31:40

1690

发布于 2023-09-27 12:31:40

文章被收录于专栏：机器学习与推荐算法机器学习与推荐算法

TLDR: 本文从评估的视角重新审视了推荐系统。特别的，重新调研了常用的数据划分方式及其影响，并讨论了在评估过程中容易被忽略的两个概念，即数据泄露和过度简化。最后提出了一些关于推荐系统评估的新观点。

论文：arxiv.org/abs/2308.15980

推荐系统已经成为信息检索领域的一个重要研究领域。因此，评估推荐模型的性能成为了该领域的一个传统研究课题。受最近研究中的一些反直觉观察的启发（比如，在系统当中活跃的用户的推荐性能竟然比冷启动用户的推荐性能还差），因此这篇观点型论文从评估的角度重新审视了推荐系统。

具体来说，重新调研了常用的训练/测试数据划分策略及其结果。首先介绍常见的数据划分方法，如随机划分或留一划分，并讨论为什么在这种划分下基于流行度的基线模型的定义是不正确的。

首先看一个实际的案例。下表总结了五种常用设置从尽可能接近模拟在线过程的理想设置(设置1)到最简化的设置(设置5)。显然，对在线评估过程的模拟越逼真，可以使离线评估得到的结果更具指导性。

通过对文献进行统计分析，下表给出了以下结果，即34%采用了随机划分（设置5），随后是25%的论文采用了留一法（设置4），19.5%采用了单时间点的方法，剩余的17%采用模拟在线的方法和4.5%采用时间窗来进行划分。

从这个案例可以看到，收集的论文中有59.1%遵循设置4和5。也就是说，他们的离线评估不能很好地模拟在线过程，并且没有维护跨用户的全局时间线。我们还观察到，尽管17%的论文利用了基于模拟的在线设置，但采用的原因不是由于推荐研究问题的要求，而是由于他们的解决方案中使用的算法，例如强化学习。基于强化学习的推荐不是本文的讨论重点。接下来，我们将回顾流行度基线（Popularity），以说明为什么维护全局时间轴是至关重要的。

随后，本文从真实的例子出发（《纽约时报》畅销书）讨论了基于流行度的方法应该包含2个必要条件。首先流行度的统计是动态更新的，而不是一成不变的；其次需要在短时间内进行统计流行度，比如一天、一个月等，而不是在整个数据集上。基于以上两点考虑，给出的结论是当前的流行度方法来测试推荐性能是不科学的。

然后探讨了在评估期间忽略全局时间线的两个概念:数据泄漏（data leakge）和用户偏好建模的过度简化（ oversimplification）。

对于数据泄露，下图提供了关于全局时间线的三个示例用户的留一数据划分的说明。注意𝑢1的测试实例发生在𝑡𝑥1时间。如果我们将时间𝑡𝑥1视为当前时间𝑡𝑐，那么推荐者可以从𝑡𝑥1中学到的所有历史交互应该是𝑢1的三次交互和𝑢2的一次交互。推荐模型永远无法访问未来将发生的关于时间点𝑡𝑥1的交互，如𝑢2的两次交互，以及用户𝑢3的所有交互。通过强制流行基线使用所有训练数据，流行度方法可能会向𝑢1推荐一些在未来非常流行的项目。显然，通过使用未来发生的频率计数来推荐未来流行的物品是不现实的。

到目前为止关于忽略全局时间线的讨论没有解释为什么用户交互越多，推荐效果越差?对这个问题的假设答案是在于当前模型中学习用户偏好的过度简化造成的。

上图展示了一个示例场景，其中三个用户𝑢1、𝑢2和𝑢3分别在不同的时间点𝑡1、𝑡2和𝑡3购买了同一部手机。我们可以进一步考虑，𝑡1是这款手机发布的第一天，𝑡3是这款手机停产的最后几天之一，𝑡2是中间的时间。我们也可以考虑这款手机的升级版本已经在𝑡2和𝑡3之间发布。在这种情况下，三个决策可能会非常不同，因为在𝑡1、𝑡2和𝑡3这三个时间点可供选择的备选手机型号将非常不同，而且在这些时间点可供选择的型号的受欢迎程度也会非常不同。这同样适用于销售周期相对较短的其他产品(从发布日期到停用日期)。简而言之，即使两个用户与同一个物品交互，如果两次交互发生在非常不同的时间点，则两种决策的上下文可能会非常不同。

最后，提出了推荐系统的新视角，包括评估更准确反映现实场景算法性能的技术（比如对基线方法的评估按照时间线来进行设置，以及适用合理的按照时间窗进行的时间线方式），以及在用户偏好建模中考虑决策上下文的可能方法等。