第二名解决方案

恭喜获得第一名的赢家以及所有的参赛者。感谢竞赛组织者举办这场有趣的比赛。这是我队友 @paweljankiewicz 和我的解决方案。

wht1996 的解决方案

我在召回产品候选集方面做得不是很好。起初，我尝试了 itemCF 等召回方法，但后来发现效果甚至不如直接选择热门产品。因此，我的解决方案是直接为每个用户选择约 600 个最热门的产品（会有一些非常简单的策略参考用户的历史记录）。然后训练一个 lgb 模型，根据模型分数为每个用户选择 130 个候选者，然后将用户在历史中购买的所有产品添加为最终候选。

之后，训练另一个 lgb 模型以获得最终结果。与召回阶段的 lgb 模型相比，特征会更加复杂，特征主要分为以下几组：

• 用户基本特征：包括数量、价格、sales_channel_id。
• 产品基本特征：基于产品每个属性的统计，包括次数、价格、年龄、sales_channel_id、FN、Active、club_member_status、fashion_news_frequency、上次购买时间、平均购买间隔。
• 用户产品组合特征：基于产品每个属性的统计，包括数量、时间、sales_channel_id、上次购买时间和平均购买间隔。
• 年龄产品组合特征：每个年龄段下的产品流行度。
• 用户产品复购特征：用户是否会复购产品以及产品是否会被复购。
• 高阶组合特征：例如，预测用户下次何时购买该产品。
• itemCF 特征：通过 itemCF 计算每个项目的相似度，然后计算用户是否会购买该产品的分数。

单模型在排行榜上的分数是 0.0355，加入 @paweljankiewicz 的候选者后可以提升到 0.0362，集成分数为 0.0368。

@paweljankiewicz 的解决方案

我主要遵循了帖子中的建议。我很高兴我的直觉是正确的。总体而言，在与 wht1996 合并之前，我专注于生成多样化的召回策略。解决方案中最有趣的部分不是逻辑，而是我用 Rust 编写了特征工程部分，并创建了一个用于并行特征提取的迷你框架。我认为这样我可以处理更复杂的规则，而且速度仍然很快。

候选策略

我使用了各种各样的计数器来衡量不同组中项目的流行度：

• 客户属性：不同的组合（显著提高我分数的是包含了 postal_code）。
• 商品属性：不同的组合，然后与客户历史记录相交——如果客户购买了具有某些属性的商品，我会寻找具有相同属性的热门商品。计数器用于不同的时间范围，如：1、3、7、30、90 天。

我还使用了：

• 使用 MobileNet 嵌入的图像相似度。
• 共现（篮子内和篮子外 = 篮子对篮子）。
• 在项目-用户图上的随机游走。

特征：

• 客户/商品属性。
• 各种基于相似度的度量，例如我计算了项目与客户购买的项目的平均相似度。
• 连续购买序列——这是受到之前一些竞赛帖子的启发——对于许多商品属性，我计算了连续购买序列，衡量客户连续购买产品、类别、部门等的次数。

最后，我为每个客户准备了 1000 个候选者，这实在太多了。我很难突破 0.0340，但在 wht1996 的帮助下，我设法将单模型提升到了 0.0348。

建模

我设法为 LGBMRanker 编写了一个 lambdarankmap 目标函数（主要是通过复制 XGBoost 的代码），它比 lambdarank（使用 NDCG 目标）稍好一些。在整个竞赛过程中，我使用 2-3 个月的交易数据进行训练，并使用最后一周进行验证。

什么没有奏效

深度学习模型——我尝试了几种 recbole 模型，但效果并不好。

如何改进此类竞赛

竞赛的很大一部分是关于预测不同 postal_code 的产品可用性。我认为这在某种程度上是伪装成推荐系统竞赛。对于未来的竞赛，我建议：

• 提供商品的状态——哪些是可用的以及在哪里可用。
• 为了尽量减少提交所需的计算量，我建议提供在提交