在2018年，我们的团队传统上参加了RecSys Challenge 。 这是作为RecSys会议的一部分举行的年度推荐系统竞赛。 它不像Kaggle的比赛那么大，但被认为是推荐系统中最负盛名的比赛之一。 这次的任务是音乐性的-有必要建立一个自动连续播放列表的系统。 在这篇文章中，我将详细讨论我们的决定。 我邀请你养猫。

关于比赛

今年，比赛数据由音乐流服务Spotify提供（不幸的是，该服务尚未在俄罗斯联邦正式提供）。 推荐是Spotify产品最重要的部分之一，可让用户根据自己的喜好查找新音乐，创建播放列表或收听广播。

竞赛参与者需要创建自动播放列表连续算法。 百万播放列表数据集（其名称不言而喻）被作为培训数据呈现。 除了有关播放列表中包含哪些曲目的信息之外，还提供了有关曲目的元信息：艺术家，标题，持续时间，专辑名称。

您可以在此处阅读有关比赛的更多信息。

比赛挑战

比赛的任务是推荐系统的经典任务：在知道用户行为历史的情况下为用户生成前K条推荐，但此处显示的是播放列表轨迹，而不是通常的用户条目。 用更正式的术语来说，测试数据中列出了播放列表的某些部分（以下简称种子），并且有几种不同的形成方式。 当K =（5，10，25，100）时，有种子的前K个轨道和K个轨道随机选择。 也有第一首曲目的种子，只包含播放列表的名称。 必须预测保留中未包含的曲目。 对于每个播放列表，准确地需要500个预测。

指标

竞赛的特征之一是该度量标准不是大多数竞赛中惯用的一种，而是多种。 下面我将介绍它们中的每一个。

R精度

该指标显示了我们猜到的相关曲目的比例。

$$$R-precision = \ frac {| G \ cap {} R_ {1：| G |} |} {| G |}$

NDCG

这是经典的排名质量指标，例如，您可以在此处阅读

点击次数

Spotify有一种继续播放列表的机制（您可以在本文开头的屏幕快照中看到它）：它提供了几条可用于扩展播放列表的曲目，如果没有出现，则可以单击刷新按钮并获得下一批建议。 首选的此类更新次数是“点击次数”指标。 更简单地说，第一个相关建议的位置（在这种情况下，除以10）。

接下来，为团队分配每个指标的等级。 然后，根据Borda Count选举策略方案汇总等级。 如果 $$$p$是参与者的数量，那么排名为1的团队将获得 $$$p-1$点，排名为2的团队获得 $$$p-2$点等等。

解决方案

验证方案

为了进行训练/测试拆分，我们将原始数据集分为三部分：第一部分包含980k播放列表，第二和第三部分各包含10k。 然后，将第二部分和第三部分中的每个播放列表分为种子部分和保留部分，并以与提供的测试集中相同的方式选择种子部分的大小，其余曲目归入保留部分。

选择候选人

推荐的系统通常使用两阶段方法：首先，使用更简单的模型（例如， 矩阵分解 ），从整个项目集中选择候选者，然后根据更复杂的模型（例如， 梯度增强 ）对更广泛的属性集对候选者进行排名。 首先，由于计算资源有限，必须选择候选对象：如果我们将整个可用曲目集用作候选对象，那么对于一个播放列表，我们将必须通过该模型驱动大约一百万个对象。

使用矩阵分解选择候选人

矩阵分解是构建推荐系统的最常用方法之一。 该方法的主要思想是以两个较小维度的矩阵（U和I）的乘积形式表示用户和项目之间的稀疏交互矩阵。 然后，我们可以通过将矩阵U中的向量乘以矩阵I来获得针对用户的推荐。

对于矩阵分解，我们使用具有WARP（加权近似秩对）损失的LightFM库。 我们还具有两种不同的模型-一种用于具有非空种子的播放列表，另一种用于仅具有名称的播放列表（冷启动）。

WARP损失

此损失函数在排序任务方面比其他函数更好。 它可以使用三元组（user，positive_item，negative_item），并且具有一个非常重要的功能-否定示例的选择不是偶然发生的，而是通过选择的否定示例“打破”模型的当前排名，即 高于正面例子。

因此，使用WARP损失训练模型的过程大致如下：

1. 对于一对 $$$（用户，正\ _item）$我们将在所有其他项目中选择一个随机的否定示例（很重要的一点是，只有选择一个实际上会是肯定的否定示例的可能性很小的情况下，才值得这样做）。 计算对预测 $$$（用户，正\ _item）$和 $$$（用户，负\项）$如果没有障碍（即模型预测的阳性样本得分较高），那么我们将继续对阴性样本进行抽样，直到违规发生为止。
2. 如果我们在第一次尝试中遇到违规，那么我们可以采取较大的梯度步骤，因为这意味着目前该模型通常会将负面示例置于正面示例之上，并且有必要大力更新其权重。 如果我们必须长时间寻找合适的负面例子，那么我们可以走一小步-该模型已经过良好的训练。

有关WARP丢失的更正式描述可以在原始文章中或在这篇文章中找到 。

Lightfm

该模型的第一个版本仅使用协作信息：播放列表playlist_id中track_id轨道的存在，以二进制稀疏矩阵表示。 许多矩阵对应于播放列表，轨道对应于一列。

$$$分数（p，t）= b_t + b_t + <q_p，q_t>$

LightFM +文字功能

此模型使用来自播放列表名称而不是playlist_id的单词嵌入。 播放列表的嵌入是他的单词嵌入的总和。

$$$分数（p，t）= b_p + b_t + <q_p，q_t>$
$$$b_p = \ sum_ {i \ in {f_p}} {b_i}$， $$$q_p = \ sum_ {i \ in {f_p}} {q_i}$，
在哪里 $$$f_p$-这些是播放列表名称中的单词。

因此，我们解决了冷启动的问题-我们可以为仅具有名称的播放列表提供更好的建议。

比赛组织者还提供了有关播放列表隐藏部分中有多少首曲目的信息。 如果隐藏的部分是 $$$k$跟踪，然后我们选择 $$$最大值（k * 15，k + 700）$候选人。 这些数字的性质是一种简单的启发式方法，它是从以下考虑因素中得出的：我们希望有足够的候选者用于较小的播放列表（因此 $$$k + 700$），并且出于性能原因，我们还希望最终的数据集在时间和内存方面具有大约1000万行（例如，因此k 15，而不是k 50）。

排名

选择候选者之后，我们可以考虑将建议构建为二进制分类问题的任务：对于所选候选者中的每个曲目，我们将学习预测该曲目是否确实在播放列表中。

在我们的训练数据集中，每一行将包含该对的符号（播放列表，曲目），如果播放列表中有曲目，则标签将为1，否则为0。

作为标志，使用了几个不同的组。

基于LightFM模型的功能

如上所述，在LightFM模型中，我们得到了向量 $$$q_p，q_t$和标量 $$$b_p，b_t$。
作为标志，我们将使用 $$$b_p，b_t$，< $$$q_p，q_t>$播放列表p的所有候选项中的曲目t的排名（排名由公式计算 ）。 这四个属性来自LightFM和LightFM Text模型。

基于跟踪共现的标志

让 $$$n_ {i，j}$包含曲目的播放列表的数量吗 $$$我$和 $$$j$也在一起 $$$n_i$-包含曲目的播放列表数 $$$我$。 这些值是在由所有种子部分组成的一组固定播放列表上计算的。

让播放列表 $$$p$由曲目组成 $$$t_1，t_2，...，t_n$。 对于轨道 $$$t$计算值 $$$n_ {t，t_1}，n_ {t，t_2}，...，n_ {t，t_n}$对于他们，我们将计算各种统计数据：最小值，最大值，平均值和中位数。 然后我们为数量计算相同的统计量 $$$\ frac {n_ {t，t_1}} {n_ {t_1}}，\ frac {n_ {t，t_2}} {n_ {t_2}}，...，\ frac {n_ {t，t_n}} { n_ {t_n}}$。 在第一种情况下，我们仅观察目标轨道与播放列表中的轨道相遇的频率，在第二种情况下，我们还将其标准化为其他轨道的出现频率。 规范化有助于模型避免对流行曲目进行重新训练，并更准确地提取有关曲目真正相似的信息。

其他标志

计算该对的所有特性。 $$$（p，t）$。

• 播放列表中独特艺术家的数量 $$$p$。
• 播放列表中唯一专辑的数量 $$$p$。
• 播放列表中曲目的数量和百分比 $$$p$与专辑相同的专辑/歌手 $$$t$。
• 赛道相遇了多少次 $$$t$在所有播放列表中。
• 艺术家/专辑追踪了多少次 $$$t$在所有播放列表中。
• 播放列表的种子部分和保留部分中的曲目数 $$$p$。

推荐模型

为了建立最终建议，我们使用了XGBoost 。 该模型在 $$$II_ {候选人}$，选择了超参数 $$$III_ {候选人}$通过ROC AUC指标。 选择该度量标准是因为它是分类问题的经典度量。 并非所有功能都同样有用，因此查看模型的功能重要性值将很有趣。

可以看出，同现归一化均值的符号与其他符号明显不同。 这意味着有关轨道共现的信息会给出非常强的信号，通常这并不奇怪。 而且，此功能可以代替LightFM模型用作候选选择，这不会使结果恶化。

其他

铁

所有型号均在服务器上使用Intel Xeon E5-2679 v3（28核，56线程），256Gb RAM进行了培训。 学习最终的管道大约需要100个小时，在高峰时消耗200 Gb的内存，并且有很大一部分（大约90％）的时间花在了训练候选选择模型上。 排名模型的训练非常快-大约两个小时（不包括对超参数的选择）。

失败

不是没有失败。

在比赛的倒数第二天，我们决定安排一场小型黑客马拉松，最后我们收集了所有东西：基于同现选择候选人，一系列新的提升功能，看来这可能发生了吗？
但是验证速度确实提高了一点，因此我们将提交的信息弄瞎了，然后发送出去，计划还剩一天的时间来修复门框。 在发送提交后，他们了解到这不是倒数第二天，而是最后一天。 而且新提交的速度远远低于我们最好的提交速度。 由于没有时间弄清楚为什么会发生这种情况，因此我们破坏了最佳提交，但仍排在第三位。

同样在最后一天，我们了解到种子有两种不同类型：前K个跟踪和随机跟踪，在验证过程中，我们总是选择随机跟踪，但这对排行榜影响不大。
竞赛的一天，排行榜上所有团队的R-Precision指标的价值急剧上升。 我们对此没有任何重视，但是在比赛结束时，我们发现组织者在该指标中增加了一个组成部分-田径艺术家的比赛。 这也可以添加到验证指标中，并可能提高速度。

代号

我们的解决方案以Jupyter-膝上型电脑的形式设计，可以通过顺序启动它们来进行复制（！）。 仅为此，您需要一台具有200Gb + RAM和几天时间的计算机。

其他参与者的决定

赢得第一名的团队还定期参加RecSys挑战赛并获得高分。 他们的解决方案与我们的解决方案相似，但是使用Java实现 。

第二个决赛入围者有一个非常有趣的方法-他们使用Denoising Autoencoder从他们的部分恢复播放列表 。

结论

如果您查看最终的排行榜，那么我们的团队在排名指标（R-Precision和NDCG）中排名第六和第四，在“点击次数”指标中排名第一。 怎么发生的？ 之所以如此，是因为使用LightFM Text模型可以很好地解决冷启动问题。 当我们从播放列表中猜不到单个曲目时，对“点击次数”指标的罚款会更加严厉。 使用LightFM Text模型可以将平均点击次数指标从2.2提高到1.78。

在构建top-K推荐的经典问题中，使用更简单的模型选择候选者并使用更复杂的模型进一步排名的方法仍然是最成功的方法之一。 但是同时，正确构建验证方案非常重要，这样才能比较候选选择模型和排名模型。

另外，该方案非常适合生产系统-您可以在矩阵分解的基础上开始构建推荐系统，然后通过添加第二阶段对其进行改进。

如果您对本文有任何疑问，请随时在评论中提问：）

PS我们在RecSys会议上为研讨会写了一篇更详细的文章。 该站点上她资料的访问受到限制，因此，如果您有兴趣了解有关我们解决方案的更多详细信息，请写信给我。