简介GEFCOM14-EPFL能源负荷预测资源是一套面向电力行业数据科学学习者、研究人员及R语言实践者的竞赛数据集与知识梳理聚焦基于历史负荷数据构建小时级预测模型这一典型场景。资源以zip压缩包形式提供体积约111.53MB平台暂未返回文件类型明细文件总数因未同步而显示为0具体清单建议下载后核对。学习浏览人数达1425人。内容围绕GEFCOM2014多地区小时级负荷数据展开系统介绍R中的时间序列对象与分解decompose/stl、ARIMA及状态空间模型、随机森林/SVM/神经网络等机器学习方法并涉及温度、节假日等特征工程以及MSE/RMSE/MAE/R²等评估指标对交叉验证、网格搜索调参和bagging/boosting/stacking集成学习也有详细梳理配套ggplot2可视化思路可直观比较预测误差。读者可借此建立从数据清洗、特征构建到模型对比与优化的完整实践路径适合作为课程设计、论文复现或竞赛备战的参考资料。1. GEFCOM2014-Load Forecasting一个2014年的竞赛题为什么到今天还值得你复现做负荷预测的同行应该都听过 GEFCOM2014 这个名字全称是 Global Energy Forecasting Competition 2014由某高校团队牵头组织。这个竞赛在负荷预测圈子里几乎是“世界杯”级别的存在——它第一次把全球模型的思路推到台前让参赛者用一个大模型同时预测多个地区的负荷而不是像以前那样一个地区训练一个模型。如果你正在做园区级、省级甚至跨区域的电力负荷预测复现这个竞赛的价值不在于拿到当年的名次而在于把竞赛里的数据组织方式、评估口径、特征处理思路直接搬到你自己的项目里。这篇笔记我会按数据→特征→模型→评估→避坑的顺序把整个预测 pipeline 讲透每一段都有可以照抄的命令和代码。适合正在做负荷预测建模、或者想把手头模型换成全局模型架构的从业者。2. 读懂 GEFCOM2014 赛制两个 track、两种评估口径和一次方法论转向2.1 Global 预测 vs Local 预测赛制背后推动的建模范式转变GEFCOM2014 的赛制对后来影响最大的不是数据量而是“Global”这个提法。在 2014 年之前绝大多数参赛队伍的做法是 Local 预测每个地区单独训练一个模型各地区之间互不共享信息。这样做的好处是模型简单、调参直接坏处也很明显——如果一个地区的训练样本只有两年遇到极端天气或节假日规则变化模型几乎没有泛化空间。GEFCOM2014 把训练数据扩到了多个地区并且允许参赛者选择是分别建模还是合并建模最后获奖方案里 Global 模型取得了压倒性优势这也是后来很多工业级负荷预测系统改用它作为默认架构的起点。你可能要问Global 模型到底赢在哪里我拆开讲。第一个赢点是样本量。假设你有 15 个地区的 3 年小时级负荷数据Local 方案每个地区只有约 26000 个样本而 Global 方案直接把样本池扩到 39 万树模型和神经网络在这种量级下能把节假日、气温、季节的交互模式学得更稳尤其是那些在单个地区出现次数很少的特殊日期模式——比如某国特有的假日放到 Global 里就有其他地区类似事件的样本可以借鉴。第二个赢点是正则化。Global 模型天生的偏差会大一点但方差小得多你在验证集上看到的精度更接近真实上线后的表现。但 Global 模型不是没有代价这也是你要在复现时做权衡的地方。如果各个地区的负荷曲线形态差异极大——比如一个地区是重工业负荷另一个地区是纯商业负荷——Global 模型容易被大地区带偏小地区的误差反而比 Local 模型更大。我一般会先看一眼各地区负荷曲线之间的相关系数如果两两相关性平均值低于 0.4我会优先做 GlobalLocal 混合而不是纯 Global。另外要注意的是GEFCOM2014 的 Global 任务和 Local 任务在数据上是同一份只是评估口径不同这个细微差别很容易被忽略下面专门展开。2.2 评估指标的三个细节NSE 不是 RMSELocal 的 TN 精度才是赢家分水岭GEFCOM2014 的评估指标和很多竞赛不太一样它没有用 MAPE也没有用 RMSE而是用了 NSENash-Sutcliffe Efficiency和 TNTotal Normalized精度两个口径。NSE 的定义是 1 减去预测误差方差除以真实值方差数值越接近 1 越好它本质上衡量的是模型是否捕捉到了负荷的波动形态而不是绝对误差水平。这个指标有一个特点如果模型只预测一个平滑的季节均值RMSE 可能不算太差但 NSE 会接近 0 甚至为负因为你的预测没有跟着真实波动走。TN 精度则是把预测值和真实值标准化后再比精度尤其在 Local track 里这个指标对短时尖峰特别敏感。当年很多队伍的 NSE 分数很接近最后名次就是靠 TN 精度拉开的。我复现时的经验是如果你的模型在 NSE 上已经做到 0.95再往上抠很难但 TN 精度还有提升空间因为它更多的惩罚是那些局部时段的偏差——比如某个工作日下午 3 点的负荷尖峰你没有跟上。这意味着你在调参时不能只看总体误差要去分时段拆误差尤其是工作日上午和傍晚高峰这两个时段往往是 TN 精度的主要失分点。这里还要提醒一个细节GEFCOM2014 的评估是分地区、分日期分别计算指标再取平均而不是把所有预测误差揉在一起算一个总指标。这个口径差异会让“样本少的地区”和“节假日日期”在总分中的权重上升。如果你复现时直接用全局 RMSE 来调参你会把模型的注意力过多放到样本量大的地区最后提交的分数会吃亏。我在做复现时是把评估函数先写出来每 10 个 epoch 打印一次分地区分指标的表现矩阵然后才去调超参数而不是盯着一个总 loss 盲目调。3. 从原始负荷序列到可用训练集节假日日历、气温特征与滞后变量3.1 先把节假日日历做对固定移动特殊缺失与偏移的两种处理做负荷预测的人常有一句口头禅模型可以换日历不能错。GEFCOM2014 的训练数据里节假日的影响极其明显节假日的负荷水平比普通工作日低 15% 到 30%如果你把节假日当成普通工作日去建模模型会系统性地高估节假日负荷这个误差在 TN 精度上的打击是灾难性的。我的习惯是先建立三个层级的节假日日历第一级是固定日期假日比如元旦、劳动节直接用公历日期第二级是移动假日比如农历新年或某些宗教假日需要按年份推算第三级是特殊日比如政府临时宣布的调休日或大型活动日这类日期在历史数据里可能只出现一两次需要单独标注。接下来是特征编码方式。我见过不少人把节假日直接做成一个二值变量1 表示是节假日0 表示不是然后丢给模型。这个做法在 LightGBM 这类树模型里勉强可行但在线性模型里效果很差因为节假日前一天和后一天的负荷形态也是特殊的——很多人提前放假或返程负荷不是断崖式下跌而是渐变。我一般会做三列特征is_holiday 二值、holiday_week当前日期距离节假日开始的天数负表示节前、after_holiday节假日结束后第几天。这三个特征合在一起才能让模型学到“节前一天的傍晚负荷开始下降”这种规律。日历缺失的情况也要处理。GEFCOM2014 提供的数据是小时级但某些地区在个别小时有缺失或异常置零。我的建议是缺失的小时不急着填充先看是不是整个地区的某一天都缺失如果是这一天直接剔除如果只是零星几个小时缺失我一般用前后 24 小时同星期类型的小时均值填充而不是用线性插值——因为线性插值会把峰值削平造成 TN 精度假性提升。注意填充逻辑必须在训练集上完成后再做归一化顺序反了会让填充值影响归一化参数。3.2 特征工程的最小可跑版本用滞后、滑动均值与温度交互撑起基线在我复现 GEFCOM2014 的早期版本中我把特征工程分成了三类时间特征、滞后特征、天气特征。时间特征包括小时、星期几、月份、是否周末、是否节假日这些直接构造即可。比较关键的是滞后特征。负荷序列有很强的自相关性同一时刻的负荷和昨天同一时刻、上周同一时刻的负荷相关性极高。我用的滞后项是 load_lag_24、load_lag_168以及 load_lag_24_rolling_mean过去 24 小时的滑动均值。在代码里是这样组织的import pandas as pd def build_features(df, target_colload): # 时间特征 df[hour] df[timestamp].dt.hour df[dow] df[timestamp].dt.dayofweek # 周一0 df[month] df[timestamp].dt.month df[is_weekend] (df[dow] 5).astype(int) # 滞后特征注意按地区分组避免跨地区串数据 df df.sort_values([zone_id, timestamp]) df[lag_24] df.groupby(zone_id)[target_col].shift(24) df[lag_168] df.groupby(zone_id)[target_col].shift(168) # 滑动均值 df[rolling_24_mean] df.groupby(zone_id)[target_col].transform( lambda x: x.rolling(24, min_periods1).mean() ) # 温度交互 df[temp_load_interact] df[temperature] * df[load].shift(1) return df这段代码里有几个地方要重点说明。第一个是 groupby(‘zone_id’) 之后再做 shift这个顺序不能错尤其是 Global 模型下如果不分组直接 shift会拿 A 地区的上一小时负荷去预测 B 地区当前小时这个泄漏会让验证分数变得异常高但线上直接翻车。第二个是 rolling_24_mean 的数字选的是 24对应的是过去全天的小时数如果你做的是 15 分钟级数据这里要改成 96。第三个是温度交互特征我加这个特征是因为夏季负荷对温度的响应是高度非线性的单纯把温度作为连续变量丢进树模型它学到的是一段段的置信区间而不是真实的空调负荷响应曲线。还有一个细节是滞后项缺失值的处理。训练数据的前 168 个小时是不可能有 lag_168 的因为前面没有数据。我在代码里用的是 shift 之后自然形成 NaN然后在训练前用 DataFrame.dropna() 直接删掉这些行。注意不要用 0 填充因为 0 会被模型当成一个真实的低负荷值造成预测值偏小。这一步看似简单但很多人在这里翻过车。3.3 数据集切分与交叉验证让验证窗口对齐竞赛的评估窗口数据切分是另一个容易被低估的地方。GEFCOM2014 的评估方式是给定前几年的数据预测最后一年的负荷这是典型的滚动预测场景。我在复现时没有直接用随机打乱的 K 折交叉验证因为负荷序列有强时间相关性随机切分会让训练集里出现未来的信息验证分数虚高。我的做法是按时序切分取前 80% 的时间段做训练最后 20% 做验证并且验证集的最后 N 天要保留完整的滞后链。如果你觉得单次切分不够稳可以用多折滚动切分比如用第 1-2 年训练预测第 3 年再用第 1-3 年训练预测第 4 年。这种方法能让你看到模型在不同规模训练数据下的稳定性。有一点要特别注意验证集必须包含完整的节假日与季节周期如果你的切分点刚好把验证集切到了某两个月份模型的泛化表现会被低估或高估。我在做切分时一般会强制让验证集至少覆盖一个整年的周期这样才能和竞赛的最终评估对齐。# 按时间切分保留完整年份 def time_split(df, val_years1): last_year df[timestamp].dt.year.max() train df[df[timestamp].dt.year (last_year - val_years 1)] val df[df[timestamp].dt.year (last_year - val_years 1)] return train, val这段切分代码的运行逻辑很直白按年份切分训练集和验证集之间没有时间重叠。但你要知道它的一个局限——如果最后一年的数据本身有特殊事件比如某个地区发生过长时间的停电验证分数会偏低这是数据本身的问题不是模型的锅。我在实际项目中会额外看一眼验证集和训练集的负荷分布直方图如果差异太大我会把特殊时段剔除再评估一次。4. 从基线到能打的预测模型OLS、Ridge 与 Gradient Boosting 的递进路径4.1 基线带哑变量的岭回归15 分钟搞定一个可提交的预测很多人一上来就上 Transformer 或 LightGBM我反而建议先跑一个带哑变量的岭回归作为基线。原因有三个第一岭回归在负荷预测上表现其实不差尤其在样本量不大的 Local 模型下它能给后续复杂模型提供一个对照底线第二它训练快几十秒就能跑完方便你快速验证数据 pipeline 有没有问题第三它的系数是可解释的你可以直接看到工作日对负荷的贡献是多少节假日又把负荷拉低多少这些信息能帮你发现特征工程里的逻辑错误。import numpy as np from sklearn.linear_model import Ridge from sklearn.preprocessing import OneHotEncoder def train_ridge_baseline(train_df, val_df): # 特征列 feature_cols [hour, dow, month, is_weekend, lag_24, lag_168, rolling_24_mean] # 对小时和星期几做哑变量编码 encoder OneHotEncoder(sparse_outputFalse) for col in [hour, dow]: train_enc encoder.fit_transform(train_df[[col]]) train_df pd.concat([train_df.reset_index(dropTrue), pd.DataFrame(train_enc)], axis1) # 模型训练 model Ridge(alpha10.0) model.fit(train_df[feature_cols], train_df[load]) val_pred model.predict(val_df[feature_cols]) return model, val_pred这里 Ridge 的 alpha 我一般设为 10.0这个值在负荷预测场景下对共线性特征比较友好。如果你用的是原始小时特征alpha1 也行但加了滞后项后特征之间相关性高alpha 太小会让系数方差变大。关于哑变量编码还要补充一句小时和星期几分开放进模型会让岭回归自动学到“下午 5 点 工作日”这种交互吗答案是带一定水平的可以因为连续特征和哑变量的乘性结构本身就是一种隐式交互但纯粹靠线性模型捕捉复杂交互还是吃力所以这个基线我只看它的 NSE 有没有达到 0.85 以上——如果连 0.85 都不到说明前面的特征工程一定有问题先去查滞后列再去查节假日日历。4.2 进阶Gradient Boosting 处理非线性交互从 NSE 0.85 到 0.95 的跳跃当你确认了线性基线的错误率在可接受范围再上树模型才是有意义的。我复现 GEFCOM2014 的主力模型是 LightGBM 和 XGBoost 的对比最后用的是 LightGBM——它训练快且对带时间类的周期性特征有比较好的内置支持。树模型的优势在于它能自动处理温度与负荷之间的非线性关系比如在 20 度以下的时候负荷随温度下降而上升、20-25 度之间是平稳区、25 度以上负荷随温度急剧上升这种分段式关系用线性模型很难表达树模型天然擅长。import lightgbm as lgb def train_lgb(train_df, val_df, features): params { objective: regression, metric: mae, learning_rate: 0.03, num_leaves: 127, min_child_samples: 50, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, verbose: -1, } dtrain lgb.Dataset(train_df[features], labeltrain_df[load]) dval lgb.Dataset(val_df[features], labelval_df[load], referencedtrain) model lgb.train( params, dtrain, num_boost_round2000, valid_sets[dval], callbacks[lgb.early_stopping(100)] ) return model这里面的参数设置是有讲究的。learning_rate 设 0.03 而不是默认的 0.1因为我发现负荷序列的噪声比较大学习率太高会导致验证曲线锯齿状波动early stopping 停下来的点位反而不稳定。num_leaves 设 127 是配合浅树大叶数的思路让模型能记住一天内不同时段的形态组合。min_child_samples 设 50 是为了防止树在小样本的节假日类型上学到极端值。另外metric 我用的 mae 而不是 rmse因为 GEFCOM2014 的 TN 精度更接近 MAE 的惩罚逻辑——它对局部大偏差的惩罚不像 MSE 那么激进所以在竞赛场景下用 MAE 做 early stopping 的指标提交分数往往更稳。这也是我在之前某个项目里学到的经验模型的训练指标要跟着最终评估指标的口径走不能只看默认的 loss。训练完成后我一般会画一个特征重要度图重点检查 lag_24 和 temperature 是不是排在前两位。如果 lag_24 不在前三说明你的数据清洗有问题——序列自相关性是负荷预测最稳定的规律如果模型没学到这个去找滞后列是不是被 fillna 污染了。如果 temperature 重要度是 0去看温度数据是不是有大量缺失被填充成了同值。4.3 多模型加权融合让全局模型和局部模型各司其职在 GEFCOM2014 的复现中我最后提交的版本不是单个模型而是全局模型和局部模型的加权融合。全局模型用所有地区的数据训练擅长捕捉共性的季节性规律局部模型按地区分别训练擅长捕捉本地特有的负荷形态。融合的方式不是简单地取平均而是按地区和时段分别算权重。这里有一个经验公式def fuse_predictions(global_pred, local_pred, val_errors_global, val_errors_local): # 权重与验证误差成反比 w_global val_errors_local / (val_errors_global val_errors_local) w_local 1 - w_global fused w_global * global_pred w_local * local_pred return fused权重算出来通常会是某个地区的局部模型误差更小那这个地区的最终预测就以局部模型为主反之如果某个地区的样本量太少导致局部模型过拟合权重会倒向全局模型。这个策略的收益不算大通常能提升 1% 到 3% 的精度但竞赛里名次就是这么拉开的。注意计算权重时要在验证集上算不要用训练集否则局部模型因为拟合了训练集噪声而看起来误差更小权重会失真。树模型的融合还有个顺序问题。我先训练全局模型再训练局部模型然后把两者预测值做融合。如果在训练全局模型后直接做残差学习——拿全局模型的预测残差去训练局部模型——这种融合方式也是可行的但实现时要小心不能把残差直接当目标而要保留一个输出层。我更推荐预测值加权融合简单直接效果也稳定。5. 避坑指南GEFCOM2014 复现中最容易翻车的 4 个环节5.1 归一化泄漏fit 在测试集上的错误做法现象验证集上的 NSE 达到 0.97提交后分数直接掉到 0.88差距大得离谱。原因在我早期的版本中先对整个数据集做 MinMaxScaler然后再切分训练集和验证集归一化的统计量最小值、最大值提前看到了验证集的信息验证分数虚高。解决必须先切分数据再用训练集 fit 归一化器验证集只做 transform。这个错误在竞赛里很隐蔽因为你不会得到任何报错分数的异常要到提交阶段才暴露。from sklearn.preprocessing import MinMaxScaler # 正确顺序先切分再 fit 归一化器 scaler MinMaxScaler() train_x scaler.fit_transform(train_df[feature_cols]) val_x scaler.transform(val_df[feature_cols])另一个相关但容易被忽略的点是归一化的维度。如果你按特征维度分别做归一化要保证不同地区的同一特征在同一个归一化器下处理而不是每个地区单独 fit。我在 Global 模型早期踩过这个坑每个地区单独 fit 归一化器后模型的输入分布被强行拉齐了等于抹掉了地区间的水平差异预测结果整体偏平。正确做法是所有地区共享一个归一化器。5.2 节假日修正失真特殊日期被“平均”吞掉现象春节和国庆期间的预测值比真实值高 20%但工作日的预测很准。原因模型把节假日当成了普通日期的变体被平均效应拉向中间值。解决对节假日样本单独加权让模型在训练时更重视节假日。我在 LightGBM 里会给节假日样本加权重weight 设为 2.0普通工作日设为 1.0。另一个方案是直接用节假日计数器特征而不是只用二值特征。如果你用的是神经网络可以把节假日向量单独 concat 进 embedding 层。还要注意的是移动假日的边界。五一劳动节如果在星期三很多公司会调休周六变成工作日周日变成休息日这种“调休日”在历史数据里是真实出现的但模型如果只靠星期几特征学不到调休的规律。我的做法是在节假日日历文件里手动标记调休日并开放调休日当天的实际负荷曲线。这个工作看起来繁琐但往往能影响 1%-2% 的精度。5.3 评估口径错位用 NSE 代替 TN 精度选模型现象模型在 NSE 指标上提升了 0.01提交后排名不升反降。原因我在调参时只看 NSE但竞赛的最终排名由 TN 精度决定NSE 的提升可能来自对平滑段的拟合优化而 TN 精度更看重尖峰时段的得失。解决建立双重评估体系训练时看 NSE 用来排除明显错误模型选型时只看 TN 精度。具体做法是把预测值和真实值按小时分组分别计算每个小时的 TN 精度你会发现上午 8 点和下午 6 点的 TN 精度最低然后针对这两个时段调整特征或模型结构。我在复现中经历过一次印象挺深的翻车某个版本加了温度二阶多项式特征后NSE 提升了 0.008但 TN 精度反而下降了 0.01原因是这个特征让模型对温度变的过拟合极端温度天预测值偏移更大而 NSE 对这种偏移的惩罚相对温和。从那之后我的默认评估函数就直接把分时段的 TN 精度自动打印出来。5.4 过拟合的沉默信号验证窗口与提交窗口不一致现象验证误差一直在下降但提交分数远差于验证分数。原因验证集的日期窗口比如 3 月到 6 月与提交窗口比如 7 月到 12 月的季节分布不一致模型在验证集上体现的是春季和初夏的预测能力而你提交的是夏秋季的预测结果。解决强制验证集的日期范围覆盖完整的一年或者至少覆盖提交窗口所包含的季节。如果做不到退一步的做法是验证集里至少包含高温月和低温月的数据。这个坑在时间序列预测里很典型因为很多人默认随机切分或简单按比例切分忘了评估窗口本身是有业务含义的——竞赛评估的是一整年的滚动表现如果你在验证时只看了半年甚至一个季度你的模型选择决策就是盲人摸象。我现在的习惯是每次训练前先打印训练集和验证集的月份分布如果发现某个月份完全不存在于验证集我会手动调整切分点。6. 把模型用在生产滚动重训与残差监控6.1 滚动重训不要等模型彻底失效才更新竞赛环境里你只需要提交一次预测但实际生产系统里模型面对的是每天都在变的负荷模式。季节交替、新园区接入、用电政策调整都会让模型的误差逐渐放大。我的做法是把 GEFCOM2014 的复现代码直接封装成一个每日滚动重训的任务每天凌晨 2 点拉取前一天的真实负荷数据更新训练集重新训练模型输出当天的 24 小时预测。LightGBM 的全量重训大概在几分钟内能完成这个成本是可以接受的。滚动重训需要注意的一个细节是模型更新的频率和滞后特征的更新是同步的。如果你的预测起点是每天零点那么滞后 24 小时的特征就是昨天零点到 24 点这段真实的负荷数据。如果数据管道延迟了——比如真实数据要中午才入库——你的凌晨预测用的滞后值就是空值预测结果会整体偏移。所以我在生产环境里会额外做一个数据就绪检查脚本预测任务启动前先检查滞后特征字段有没有 NaN有就触发告警。6.2 残差监控与阈值告警把预测系统变成可运维的系统模型上线后光看 RMSE 是不够的。我一般会用一个滚动残差监控按小时统计过去 7 天的预测残差均值和标准差如果某一天的残差均值超过 3 倍标准差立刻触发告警。这个监控的唯一目的是发现“突发的新规律”——比如某个地区突然开启了大型临时用电项目或者气温传感器故障导致特征值异常。残差监控的告警阈值不宜过紧否则会被正常的节假日波动误报我的经验是 3 倍标准差加一个绝对下限比如残差超过该地区峰荷的 5%双条件触发。还有一个习惯值得分享每次重训后我都会把旧模型预测的残差序列保留下来按周做一次对比分析。这样能直观看到模型精度有没有因为季节变化而下降以及哪个时段的下降最明显。如果你用的是 LightGBM可以顺便记录一下验证集的 NSE 变化趋势一旦发现连续三周 NSE 下降超过 0.02说明模型结构可能需要调整而不是只靠重训能解决的。这个习惯在 GEFCOM2014 的复现过程中被验证过多次模型的精度退步通常是有先兆的只是很多人不看历史趋势等出了问题才慌。希望这些经验能帮到你少走几趟我当年踩过的弯路。本文还有配套的精品资源点击获取
