从零开始的otto推荐系统竞赛体验与总结

写在开头

本人为推荐小白，虽然很早之前在某音做过一段时间的算法实习，但是对整体的推荐流程也只有简答的概念印象，kaggle最近推出了一个推荐系统的竞赛：OTTO – Multi-Objective Recommender System，https://www.kaggle.com/competitions/otto-recommender-system ，正好借此机会熟悉推荐系统。

任务目标与数据集介绍

otto数据集是一个用于多目标推荐研究的大规模数据集，来源于otto网站和程序中的匿名行为日志，主要包含用户（session）与物品（aid）之间的交互行为，我们需要根据用户历史行为数据，预测用户之后会对哪些物品进行click（点击）、cart（添加购物车）、order（下订单）三种类型的操作。

otto数据集总共包含1200万的匿名用户（session），180万个不同物品（aid），以及2.2亿规模的事件（click、cart、order），原始数据由jsonl格式数据存储。

任务目标：对每个位于测试集中的待预测用户，对于每个推荐目标（click、cart、order），我们需要分别返回20个物品作为提交。
评价指标：多目标召回率加权平均，click、cart、order权重占比分别为0.1、0.3、0.6。

解决方案

总体来讲，方案整个流程可以分为以下几部分：

1. 数据集划分（划分训练和验证集，构建稳定可靠的本地CV）
2. 候选物品召回（为每个用户召回超过20个，例如50/100/200个候选物品）
3. 用户特征和物品特征生成（从事件中建构多个维度的特征用于模型训练）
4. ranker模型训练（对召回的物品结合生成的特征进行二次训练，得到更优的排序结果）
5. 推理和模型集成（获得更优的推荐结果）

数据集划分

整个可用于训练的数据集包含4个星期的用户行为时间，按照每个事件的时间戳，可以将前3个星期作为训练集（train），后1个星期作为验证集（val），另外待测试数据集以test表示，对于原始的jsonl数据，通过处理可以得到以下类型的dataframe数据：

session	aid	ts	type
用户id	物品id	发生时间	类型，即click/cart/order

注意：在这个竞赛中，数据使用不当很容易发生信息泄露问题，train和val两个数据集的用户不可以存在交集，test数据集用户和train以及val数据集用户本身没有交集，

候选物品召回

对于召回，竞赛论坛上主流的召回方法分为两种：word2vec和co-visitation，获得aid2aid的列表，这样可以得到每个aid以及和它关联度最高的若干个aid。

1.对于word2vec，是把某个用户在历史过程中进行交互的aid组成sentence，然后使用word2vec训练学习sentence，训练完成后，模型可以得到每个aid的特征向量，然后根据相似度度量方法，对每个aid获得和它关联程度最高的若干个aid。

2.对于co-visitation，则是通过统计每个用户历史行为中所有aid组合对数量，筛选高频出现的(aid,aid)组合来获得每个aid以及和它关联度最高的若干个aid。

这样，我们就可以根据用户的历史交互数据，得到每个用户潜在的候选aid列表。

然后在此基础上，我们还能通过手工规则，如:用户最近访问的aid、被用户多次访问的aid、受欢迎的aid…进行重新排序，得到更为高质量的候选aid列表。
过程可以参考：https://www.kaggle.com/code/cdeotte/candidate-rerank-model-lb-0-575

注意，我们需要分别对验证集（val）和测试集各生成一个候选物品集

特征生成

为了进一步优化召回结果的排序（即真实发生交互的aid排在前面），可以在召回结果的基础上，使用模型进一步训练，因此也需要构建有效的特征用于训练。特征一般分为三类：用户特征、物品特征、交互特征。

1. 用户特征：用户会话的长度、用户历史交互的aid、用户历史交互的类型统计…
2. 物品特征：物品被访问的次数、物品被多少用户访问过、物品发生交互的类型统计…
3. 交互特征：物品在候选集中的排序、多种co-visitation中的aid统计次数、用户和物品的相似度（通过word2vec）…
   根据后续的实验结果来看，交互特征对模型训练的提升效果最大，也是最为重要的特征。

ranker模型训练和推理

在划分好数据集的基础上，完成候选物品召回以及特征生成之后，我们就可以开始ranker模型的训练。常用的ranker模型有LGBM Ranker和XGBoost Ranker。

首先我们需要对验证集（val）中的用户完成候选物品和特征进行拼接，得到类似下列的dataframe：

session	aid	user_feat1	user_feat2	item_feat1	item_feat2	inter_feat1	inter_feat2	labels
用户id	物品id	用户特征1	用户特征2	物品特征1	物品特征2	交互特征1	交互特征2	标签（0或1）

构建完成之后，拥有特征以及标签，我们便可以进行ranker的训练。

对于没有做过推荐系统的同学来说，可能会有一个疑问，不拿训练集去训练模型，反而拿验证集训练？在这里提到训练集，它主要是在候选集生成以及特征生成中起到了帮助作用，而当我们在训练ranker模型的时候，利用的是训练集（和验证集）得到候选集以及特征，来帮助验证集去构建可用于ranker的训练数据，在此基础上，我们在验证集中可以按照用户ID构建如5-fold ranker去得到可靠的CV结果。

在完成ranker的训练之后，我们同样对测试集（test）的用户完成候选物品和特征进行拼接，得到类似下列的dataframe：

session	aid	user_feat1	user_feat2	item_feat1	item_feat2	inter_feat1	inter_feat2
用户id	物品id	用户特征1	用户特征2	物品特征1	物品特征2	交互特征1	交互特征2

相比于验证集，测试集中没有标签，需要我们通过ranker模型推理得到。当把测试数据输入ranker模型后，模型会为每一行数据预测一个得分，我们根据每个用户的候选物品得分进行排序，筛选出前20个物品，然后整合成成竞赛要求的格式便可进行提交。

LGBM Ranker样例参考：https://www.kaggle.com/code/radek1/polars-proof-of-concept-lgbm-ranker
XGBoost Ranker样例参考：https://www.kaggle.com/code/radek1/training-an-xgboost-ranker-on-the-gpu

模型集成

如果我们通过模型迭代生成了一系列的提交结果，如何整合这些结果呢，因为对于每个提交结果，我们都为每个用户生成20个候选物品，一个简单的方法就是，对这些候选物品进行投票，选出票数高的物品进行提交，进一步，还可以根据不同提交结果的CV或者LB分数，设置不同的投票权重，来进一步提升召回指标。

写在结尾

总结一下，这个竞赛对于资源的开销还是很大的，主要是内存开销，特别是在一些groupby操作时候，由于数据量比较大，容易OOM，需要注意数据的类型，不要使用默认的float64，尽量都改成float32或者开销更少的类型。

另外polars的速度比pandas快很多，但是语法有差异，需要花时间去读文档，不过要是polars用得熟练，效率会比pandas高不少。