第5名解决方案

大家好，我想和大家分享我的解决方案。

首先，我要感谢 Kaggle、主办方和所有参与者，特别是 @kneroma 和 @kailex 的 kernel 贡献。此外，还要感谢由 @kyakovlev 的 kernel 引发的关于“魔法乘数”的讨论。

1) 特征工程

A) 日历特征

我根据事件的剩余天数创建了特征。每个事件对应一列，该列的值指的是事件临近程度的“强度”，上限为 30。

在此方面，还创建了一个新变量，即所有这些“力”的总和。如果该列的值较高，则表示附近有一个或多个事件。

还使用了一些变量来指示季节性。例如，指示距离月底还有多少天、一年中的第几周、一周中的星期几等。

B) 价格特征

我决定在模型中移除商品的当前价格。取而代之的是，我计算了当周价格与前几周价格之间的百分比差异，从而创建了一些与价格差异相关的列。我认为那一周价格的下跌或上涨对于更通用的预测更有意义。

C) 历史序列

这里感谢 @kkiller 和 @kxx 的 kernel，使用了以下变量：
['lag_7', 'lag_28', 'rmean_7_7', 'rmean_28_7', 'rmean_7_28', 'rmean_28_28']。

还插入了一些其他变量，如商品 ID 和商店 ID 作为类别变量。

2) 模型

我使用了带有早停机制的 LGBM 模型，目标函数为泊松分布，针对每个部门训练一个模型，总共 7 个模型。这让我更容易避免内存溢出，并且能够使用更多过去的数据。

我还利用预测值来预测下一个值（例如 lag_7）。

3) 后处理：魔法乘数

大约 1.03 的魔法乘数确实改善了结果，但我对此并不自信。

于是我分析了每个商店和部门的真实值与预测值之间的差异。我们得到了像下面这样的图表：

有些商店/部门显示预测值“持续低于”（当然有很多噪音）真实值。而其他商店/部门显示预测值“持续高于”真实值。然后我决定根据上周（验证集）为每个商店/部门创建一个平均修正因子。我们得到了像下面这样的矩阵：

也就是说，~0.92 代表 FOODS_1/CA_1 的特定因子，因为在验证集中，真实值平均是预测值的 92%。

通过这种方式，我推测验证集的历史修正因子在评估集中会有类似的表现。

总结这一项，我没有使用单一的魔法乘数，而是为每个商店/部门使用了一个魔法乘数。在这里，我不担心结果过拟合。情况可能会更糟，我可以通过为每个商品创建一个因子来更加过拟合，但那样做得太过了。所以，这是在整个结果上只创建一个魔法乘数和为每个商品创建一个魔法乘数之间的折衷方案。

4) 简单流程图

该解决方案在 Public 榜单上远未获胜，但 Private 分数与 Public 分数保持接近。

最后，我希望能为下一个挑战的讨论做出