第39名 - 解决方案概述与代码

我想趁我现在还在排行榜比较靠前的位置时发布我的解决方案概述，这个位置可能维持不了多久。我的解决方案基于一个简单的MLP（多层感知机），包含一些我之前未见其他人发布的元素，包括一些特征工程、目标工程以及后处理中依赖权重的投票机制。

1. CV策略（交叉验证）

对我来说，这是迄今为止最重要的部分——鉴于数据中存在大量的噪声，如果没有一个像样的CV策略，其他一切都将无法评估。

我花了大量时间试图找到一种能给出至少一致且合乎逻辑结果的验证方法。最终我决定使用类似于我在这里发布的平均OOF（Out-of-Fold）效用分数。从一开始，我就决定不使用公共LB（Leaderboard，排行榜），只用来检查代码是否运行且不超时——否则，过拟合公共LB的诱惑将难以抵挡。

我使用所有数据进行训练和验证，基于GroupKFold按日期分组进行拆分——这是一个冒险的决定，因为我假设训练日期和验证日期之间没有泄漏。我有几个理由认为这种泄漏确实不是问题：

首先，这似乎是一场HFT（高频交易）比赛——正如@gregorycalvez在这个优秀的notebook中注意到的，NaN模式表明数据包含一些滚动日内特征。这并不意味着没有其他覆盖多天的滚动特征，但在我看来，这确实使其可能性/重要性降低。
我尝试将数据分成连续天数的组——从一组1天到100天不等。如果存在泄漏，您可以预期1天一组的结果会比100天一组更好，因为训练数据和验证数据之间可能存在更多的交互。但在进行了大量实验后，我并没有看到这种效果。在实际训练中，我使用了50个连续天数的组。
起初，我尝试完全随机地拆分数据，即在同一日期同时使用交易数据进行训练和验证。在这种设置下，日内泄漏是明显的，但即便如此，我的模型也需要运行很多个epoch才能捕捉到这些信息，验证分数甚至在数百个epoch后仍在提高。我在使用GroupKFold时没有观察到这种行为。

2. 特征工程

关于feature_0的含义（买/卖，做多/做空？）有很多讨论。我不知道正确答案是什么——我的假设是它是由一个单独的JS模型生成的，该模型选择交易机会。如果这是真的，那么它的近期历史可能预示着某种市场状况。这给了我一个想法，基于feature_0构建一系列滚动“滞后”特征，这导致CV分数有了适度但明显的提升。

我还添加了一些基于“时钟”feature_64的其他特征，这些特征共同提高了CV分数：

代表交易日部分的二元特征（午餐前/后）
JS算法今天早些时候（当天的第一部分）或午餐后（当天的第二部分）建议的交易数量——这里的直觉是，与“时钟”一起，该特征也可以代表市场状况（例如，更多的交易机会 = 更高的波动性）
feature_64相对于时间戳的“梯度”——直觉与前一点类似

3. 目标工程

像许多其他人一样，我注意到将此任务视为多标签分类比尝试仅预测一个标签——resp——能带来更好的结果。与大多数公共notebooks相比，我做了一些调整：

我没有使用resp_4——当我尝试添加它时，我的CV总是下降。这可以在一定程度上解释为（推测？）resp_4的时间范围比resp更长。
相反，我添加了resp、resp_1、resp_2和resp_3的平均值作为单独的目标，这确实提高了CV分数。这可以被视为整个resp时间范围内收益总体方向的代理。

4. 模型与训练

架构方面没有什么有趣的——非常基础的带有批归一化和Dropout的3层MLP。

在优化方面，我使用了带有Lookahead的LAMB——根据论文，LAMB应该在大批量大小下表现良好，而且它似乎胜过了我尝试过的其他优化器。

5. 推理与后处理

我不喜欢调整阈值的想法——除了0.5以外的值似乎很人为，缺乏任何直观意义。相反，在比赛的大部分时间里，我使用了“合格”多数