[第三名] 解决方案

感谢 Kaggle 和 ASHRAE 举办了这次比赛。

鉴于缺乏复杂性，我的解决方案可能会让你们中的一些人感到失望。

我花了大部分时间（可能太多了）尝试特征工程，试图寻找与公共 LB（Leaderboard）相关的 CV 分割（没发生），试图找到一种能在本地 CV 和公共 LB 上给我带来提升的神经网络架构（没发生），以及浏览与地铁能源预测相关的研究论文。

我对网络抓取一窍不通，但还是要感谢 @gunesevitan 指明了道路并在此过程中教会了我很多。

鉴于我在比赛期间进行了不同 CV 方案的多样化实验，我决定简单地将我得到的所有结果（超过 30 个）通过皮尔逊相关性选择后，使用简单的平均方法合并为一个提交结果（在私人 LB 上排名第 6）。
在过去三周的两个实例中，我使用了这些实验中无泄漏的子集，并利用泄漏对它们进行集成，但我放弃了，因为尽管本地 CV 更好，但公共 LB 表现很差，我认为这是过拟合。然而，当我选择此方法作为我的替代方案时，结果证明这是最终私人 LB 上最好的方法。

预处理：

由于缺乏时间，我只使用了一些优秀公共内核的想法和代码。

我还编写了一个运行了几个小时的脚本，当这些 0 出现在同一站点、同一时期且跨越所有仪表时，我消除了同一时期所有的 0。@ganfear 在这里写了一个很好的可视化。我的目标是消除最大数量的“垂直”线，特别是当它们同时出现时。我相信这是让我获得优势的技巧。在顶级公共内核中使用这种预处理后的数据总是能给我更好的 LB 分数，所以我走对了路。

特征工程：

• 来自训练/测试、天气元数据和建筑元数据的行特征。
• 计数特征和特征组合（参见 IEEE 竞赛的优秀文章）。
• 行特征的滞后，但似乎只有温度特征滞后实际上是有用的。
• 公共内核中提到的特征，如 RH（相对湿度）、体感温度和其他仪表的存在似乎有边际收益。
• 我在最后几天的另一次提交中才包含的一个特征，是在一篇研究论文中发现的，对 meter==1 效果很好：

latitude_dict = {0 :28.5383,
1 :50.9097,
2 :33.4255,
3 :38.9072,
4 :37.8715,
5 :50.9097,
6 :40.7128,
7 :45.4215,
8 :28.5383,
9 :30.2672,
10 :40.10677,
11 :45.4215,
12 :53.3498,
13 :44.9375,
14 :38.0293,
15: 40.7128,}

train_df['latitude'] = train_df['site_id'].map(latitude_dict)
train_df['solarHour'] = (train_df['hour']-12)*15 # 待移除
train_df['solarDec'] = -23.45*np.cos(np.deg2rad(360*(train_df['doy']+10)/365)) # 待移除
train_df['horizsolar'] = np.cos(np.deg2rad(train_df['solarHour']))*np.cos(np.deg2rad(train_df['solarDec']))*np.cos(np.deg2rad(train_df['latitude'])) + np.sin(np.deg2rad(train_df['solarDec']))*np.sin(np.deg2rad(train_df['latitude']))

train_df['horizsolar'] = train_df['horizsolar'].apply(lambda x: 0 if x < 0 else x)
    

这应该是计算进入建筑物的太阳水平辐射。

模型：

我在不同版本的清洗数据、各种特征选择（包括移除 building_id）上训练了 Keras CNN（@aerdem4 风格）、LightGBM 和 Catboost —— 但遗憾的是从未击败过无泄漏的最佳内核。

我在本地 CV 上使用决策树的仪表级模型比在同一个决策树模型中使用所有仪表取得了更好的成功。Catboost 和 Lightgbm 显然使用了不同的特征选择进行分割，所以它们非常互补。