简介这份资源是面向电力负荷预测方向的Python深度学习实战源码包适合具备一定机器学习基础、希望将神经网络应用于时间序列预测的开发者与研究人员。它围绕多特征输入展开涵盖历史负荷、温度、湿度、风速及日期时间等变量的处理可用于智能电网资源规划与调度场景。压缩包共9个文件约795KB包含3个py源码文件、2个csv数据集、1个xlsx表格、2个md说明文档及1个license源码、数据与文档配套齐全便于直接运行与二次开发。目前已有72人学习下载。读者可从中获得完整的模型构建流程包括数据清洗、归一化、特征工程、网络结构定义、训练与评估等环节并参考MSE、RMSE、MAE等指标验证效果适合作为课程设计、毕业设计或科研项目的起步模板。1. 多特征电力负荷预测为什么单靠历史负荷曲线已经不够用如果你拿到的是一份python基于深度学习的多特征电力负荷预测源码.zip第一件该做的事不是急着pip install而是先想清楚为什么这个项目要强调「多特征」三个字。我见过太多人把电力负荷预测当成时间序列回归来做喂进去一列历史负荷套个 LSTMMAPE 卡在 5% 上下就再也下不去。问题往往不在模型而在输入——负荷曲线本身是被天气、日期类型、节假日、温度累积效应共同塑造的结果只给它自己的历史等于让模型蒙着眼睛猜。这个方向适合两类人一类是想找一个「数据规整、评价指标明确、能完整跑通深度学习流程」的实战项目练手电力负荷预测正好满足另一类是做能源、园区、楼宇能耗相关工作的从业者需要一套能落地、能解释、能迭代的预测基线。它解决的核心问题是在给定历史负荷、气象、日历等多源特征的前提下预测未来某段时间的负荷值为调度、购电、设备启停提供依据。接下来我会按「数据怎么组织 → 模型怎么搭 → 特征怎么选 → 坑在哪 → 怎么验证」的顺序把这份源码类项目该有的落地路径讲透。2. 多特征电力负荷预测的数据组织与特征工程2.1 负荷数据的三种时间粒度与对齐方式电力负荷预测的第一步永远是数据对齐这一步做错后面模型再花哨都是白搭。常见的时间粒度有三种15 分钟96 点/天、30 分钟48 点/天、1 小时24 点/天。源码类项目里最常见的是 15 分钟粒度因为它既能反映负荷的日内波动又不至于像分钟级那样噪声过大。对齐的核心是「时间戳统一」。负荷表通常长这样一列时间戳一列负荷值。气象表可能是每小时一条日历表是按天一条。你要做的是把这三张表按统一的时间索引合并。我一般会先把所有时间戳转成pandas的DatetimeIndex然后用resample统一到目标粒度气象数据用插值补齐日历特征用merge直接广播到每个时间点。import pandas as pd import numpy as np # 读取负荷数据假设是 15 分钟粒度 load pd.read_csv(load.csv, parse_dates[timestamp]) load load.set_index(timestamp).sort_index() # 气象数据是小时级重采样到 15 分钟并线性插值 weather pd.read_csv(weather.csv, parse_dates[timestamp]) weather weather.set_index(timestamp).sort_index() weather weather.resample(15min).interpolate(methodlinear) # 日历特征按天生成再广播到 15 分钟 calendar pd.read_csv(calendar.csv, parse_dates[date]) calendar[date] calendar[date].dt.normalize() load[date] load.index.normalize() load load.merge(calendar, ondate, howleft) # 合并气象 df load.join(weather, howleft) df df.dropna()这段代码的逻辑是先把负荷和气象都统一到 15 分钟索引再把按天的日历特征通过日期列合并进来。参数上要注意interpolate的方法温度这类连续变量用线性插值没问题但降水这种稀疏变量更适合用前向填充。dropna会丢掉边界上无法插值的点如果数据量紧张可以改成fillna(methodffill)。2.2 多特征到底该放哪些温度、湿度、日期类型与滞后特征「多特征」不是越多越好我见过有人把能拿到的列全塞进去结果模型过拟合验证集误差反而上升。电力负荷预测里真正有稳定贡献的特征大致分四类。第一类是气象特征核心是温度。温度对负荷的影响是非线性的夏天高温推高制冷负荷冬天低温推高制热负荷中间有一段「舒适区」负荷对温度不敏感。所以直接放原始温度不够通常要做分段或加平方项。湿度在南方夏季也有明显影响但贡献通常小于温度。第二类是日历特征包括星期几、是否周末、是否节假日、月份、季度。这里有个容易忽略的点节假日前后的「调休」效应。比如国庆前一天的负荷曲线往往和普通工作日不同如果日历表里没有标注调休模型会学偏。第三类是滞后特征也就是历史负荷的滑动窗口。常见做法是取前 1 天同一时刻、前 7 天同一时刻、前 1 小时、前 2 小时等。滞后特征本质上是给模型提供「惯性」信息但要注意不能引入未来信息否则就是数据泄漏。第四类是交互特征比如「温度 × 是否工作日」「温度 × 月份」。这类特征在树模型里可以自动学到但在神经网络里显式构造往往能加速收敛。# 构造滞后特征 for lag in [1, 2, 4, 96]: # 96 表示前一天同一时刻15分钟粒度 df[fload_lag_{lag}] df[load].shift(lag) # 温度分段特征 df[temp_high] (df[temperature] 28).astype(int) df[temp_low] (df[temperature] 5).astype(int) # 交互特征 df[temp_x_workday] df[temperature] * df[is_workday] # 去掉因 shift 产生的空值 df df.dropna()参数说明shift(96)对应 15 分钟粒度下的一天如果你用的是小时粒度这里应该是 24。temp_high和temp_low的阈值不是固定的要根据你所在地区的实际负荷-温度曲线来定我一般会先画散点图看拐点。交互特征是否有效可以用特征重要性或相关性快速筛一遍不显著的直接删掉别舍不得。3. 深度学习模型选型LSTM、TCN 还是 Transformer3.1 为什么 LSTM 仍是负荷预测的稳妥基线在电力负荷预测这个任务上LSTM 及其变体GRU、BiLSTM依然是大多数源码项目的默认选择原因很实际负荷序列有明显的时序依赖LSTM 的门控机制能捕捉长短期模式而且实现成熟、调参经验多、在小数据集上不容易崩。一个典型的 LSTM 预测网络结构是输入层接收(batch, seq_len, n_features)的张量经过一到两层 LSTM取最后一个时间步的隐藏状态接全连接层输出预测值。这里的关键参数是seq_len也就是用过去多少步预测未来一步。15 分钟粒度下我一般取 96 到 192也就是过去 1 到 2 天。import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, n_features, hidden_size128, num_layers2, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizen_features, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout ) self.fc nn.Sequential( nn.Linear(hidden_size, 64), nn.ReLU(), nn.Linear(64, 1) ) def forward(self, x): # x: (batch, seq_len, n_features) out, _ self.lstm(x) # 取最后一个时间步 out out[:, -1, :] return self.fc(out)逻辑说明batch_firstTrue让输入维度是(batch, seq_len, features)符合大多数人的直觉。num_layers2加dropout0.2是我在负荷数据上比较常用的组合层数再多容易过拟合。fc部分先降到 64 维再输出是为了给非线性变换留空间。如果你的数据量很大可以把hidden_size提到 256但要注意同步增大 dropout。3.2 TCN 与 Transformer 在负荷预测中的适用边界TCN时序卷积网络的优势是并行计算和可控的感受野。它用膨胀因果卷积堆叠能在不增加太多参数的情况下覆盖很长的历史窗口。如果你的负荷序列有明显的多尺度周期日周期、周周期TCN 的膨胀卷积结构天然适合。缺点是它对超长依赖的建模能力不如注意力机制而且感受野需要手动设计。Transformer 在负荷预测里的应用这两年多了起来核心是自注意力能直接建模任意两个时间步的关系。但它有两个现实问题一是对数据量要求高几千条样本上 Transformer 往往跑不过 LSTM二是位置编码对周期性负荷的表达能力有限需要额外设计时间特征嵌入。我的经验是数据少于 5 万条样本优先 LSTM 或 TCN数据充足且追求极致精度再考虑 Transformer 类结构。模型适用数据量训练速度调参难度典型 MAPE 区间LSTM1 万条以上中等低2% - 5%TCN2 万条以上快中等2% - 4.5%Transformer5 万条以上慢高1.5% - 4%这张表里的 MAPE 区间是基于我接触过的公开负荷数据集和实际项目经验具体数值会随数据质量、预测步长、地区差异波动。别把表里的数字当承诺它只是帮你判断「值不值得上更复杂的模型」。4. 训练流程与关键参数从数据划分到早停策略4.1 时序数据不能随机划分训练集、验证集、测试集的正确切法这是血泪经验里排第一的坑用train_test_split随机划分时序数据。随机划分会让未来信息泄漏到训练集验证集误差看起来很美上线就翻车。正确做法是按时间顺序切前 70% 训练中间 15% 验证最后 15% 测试。如果要做滚动预测还得用滑动窗口的方式逐步推进。def temporal_split(df, train_ratio0.7, val_ratio0.15): n len(df) train_end int(n * train_ratio) val_end int(n * (train_ratio val_ratio)) train df.iloc[:train_end] val df.iloc[train_end:val_end] test df.iloc[val_end:] return train, val, test参数说明train_ratio和val_ratio不是固定的数据量小的时候可以 80/10/10数据量大且分布稳定时 70/15/15 更稳妥。切完之后一定要检查三个集合的负荷分布如果测试集恰好落在极端天气周误差会偏高这是数据本身的问题不是模型的问题。4.2 归一化、损失函数与早停三个决定收敛质量的设置归一化方面负荷值我一般用 Min-Max 归一化到 [0,1]因为负荷有明确的物理上下界。气象特征用 Z-Score 标准化因为温度、湿度的分布更接近正态。注意归一化参数必须只用训练集计算然后应用到验证集和测试集否则又是泄漏。损失函数默认用 MSE但如果你更关心相对误差可以用 MAPE 或 SMAPE 作为监控指标训练仍用 MSE因为 MAPE 在负荷接近零时不稳定。早停策略我习惯设patience10监控验证集损失连续 10 个 epoch 不下降就停同时保存验证集最优的模型权重。from sklearn.preprocessing import MinMaxScaler, StandardScaler # 只用训练集拟合 scaler load_scaler MinMaxScaler() temp_scaler StandardScaler() train[load_norm] load_scaler.fit_transform(train[[load]]) val[load_norm] load_scaler.transform(val[[load]]) test[load_norm] load_scaler.transform(test[[load]]) train[temp_norm] temp_scaler.fit_transform(train[[temperature]]) val[temp_norm] temp_scaler.transform(val[[temperature]]) test[temp_norm] temp_scaler.transform(test[[temperature]])逻辑说明fit_transform只出现在训练集上验证集和测试集只用transform。这个细节看起来简单但我在代码审查里见过不止一次写反的。早停的实现可以用 PyTorch 的手动循环也可以用pytorch-lightning的EarlyStopping回调后者更省事但多一层依赖。5. 多特征负荷预测的避坑与排查清单5.1 现象验证集 MAPE 很低测试集突然翻倍原因最常见的是数据泄漏。检查滞后特征是否在划分之后才构造或者归一化是否用了全量数据。另一个可能是测试集包含了训练集没出现过的模式比如极端天气或特殊节假日。解决把特征构造放在划分之后确保每个集合的特征只依赖自身及之前的数据。对测试集做分布检查如果发现异常考虑在训练集中补充类似样本或者接受这个误差并在报告中说明。5.2 现象模型预测曲线整体平移形状对但幅值偏原因归一化的反变换出了问题或者损失函数对幅值不敏感。也有可能是滞后特征里混入了未来信息导致模型学到了错误的基线。解决检查inverse_transform是否用了正确的 scaler。如果用的是 MSE可以尝试在损失里加一项对峰值的惩罚。滞后特征的构造顺序要严格按时间推进shift的步数不能为负。5.3 现象训练损失下降但验证损失震荡原因学习率过大或者 batch size 太小导致梯度噪声大。多特征输入下不同特征的尺度差异也会加剧震荡。解决先把学习率降到 1e-4 试试或者用ReduceLROnPlateau调度器。batch size 建议不低于 64。检查所有特征是否都做了归一化没归一化的特征会让优化器在参数空间里走 Z 字形。5.4 现象节假日预测误差明显高于工作日原因节假日样本少模型学不到足够的模式。日历特征里如果只有「是否节假日」这一个二值特征表达能力不够。解决把节假日按类型拆分比如春节、国庆、周末、调休工作日分别编码。如果某类节假日样本极少可以考虑用相似日的方法做数据增强或者单独训练一个节假日模型。5.5 现象换一个地区的数据模型完全失效原因负荷模式有强烈的地域性温度敏感度、作息规律、产业结构都不同。在一个地区训练的模型直接迁移到另一个地区特征分布对不上。解决迁移时至少要做特征对齐把温度分段阈值、滞后步数按新地区重新调整。更稳妥的做法是用新地区数据做微调冻结底层 LSTM只训练全连接层。如果数据量足够直接重新训练。6. 验证预测效果别只看 MAPE这几个指标和技巧更实用MAPE 是最常被引用的指标但它有个致命缺陷当实际负荷接近零时MAPE 会爆炸。电力负荷虽然很少接近零但在某些轻载时段MAPE 仍然会给出误导性的高误差。我一般会同时看三个指标MAPE 看整体相对误差RMSE 看绝对误差的量级峰值误差看模型在最关键时段的表現。峰值误差的计算方式是取测试集中负荷最高的 5% 时间点单独算这些点的 MAPE。这个指标比整体 MAPE 更能反映模型在调度场景下的可用性因为调度最关心的就是高峰时段预测准不准。def peak_mape(y_true, y_pred, top_ratio0.05): threshold np.percentile(y_true, 100 * (1 - top_ratio)) mask y_true threshold return np.mean(np.abs((y_true[mask] - y_pred[mask]) / y_true[mask])) * 100 def evaluate(y_true, y_pred): mape np.mean(np.abs((y_true - y_pred) / y_true)) * 100 rmse np.sqrt(np.mean((y_true - y_pred) ** 2)) pmape peak_mape(y_true, y_pred) return {MAPE: mape, RMSE: rmse, Peak_MAPE: pmape}参数说明top_ratio0.05表示取最高的 5% 负荷点这个比例可以根据你的业务需求调整如果调度只关心最高的 1%就改成 0.01。peak_mape里的 mask 用的是真实值的分位数不是预测值的这一点别搞反。除了指标还有一个我常用的验证技巧画「预测 vs 实际」的散点图按小时着色。如果某个小时的散点明显偏离对角线说明模型在那个时段有系统性偏差可能是特征里缺少该时段的特殊信息比如早晚高峰的交通或生产活动规律。最后一个习惯每次调完参把验证集和测试集的指标、关键超参数、数据版本记在一个表格里。我吃过亏改了五六轮之后忘了哪组参数最好只能重跑。这个习惯看起来笨但能省下大量后悔药。希望帮到你。本文还有配套的精品资源点击获取 Python深度学习多特征电力负荷预测：从数据对齐到模型选型与避坑指南
简介这份资源是面向电力负荷预测方向的Python深度学习实战源码包适合具备一定机器学习基础、希望将神经网络应用于时间序列预测的开发者与研究人员。它围绕多特征输入展开涵盖历史负荷、温度、湿度、风速及日期时间等变量的处理可用于智能电网资源规划与调度场景。压缩包共9个文件约795KB包含3个py源码文件、2个csv数据集、1个xlsx表格、2个md说明文档及1个license源码、数据与文档配套齐全便于直接运行与二次开发。目前已有72人学习下载。读者可从中获得完整的模型构建流程包括数据清洗、归一化、特征工程、网络结构定义、训练与评估等环节并参考MSE、RMSE、MAE等指标验证效果适合作为课程设计、毕业设计或科研项目的起步模板。1. 多特征电力负荷预测为什么单靠历史负荷曲线已经不够用如果你拿到的是一份python基于深度学习的多特征电力负荷预测源码.zip第一件该做的事不是急着pip install而是先想清楚为什么这个项目要强调「多特征」三个字。我见过太多人把电力负荷预测当成时间序列回归来做喂进去一列历史负荷套个 LSTMMAPE 卡在 5% 上下就再也下不去。问题往往不在模型而在输入——负荷曲线本身是被天气、日期类型、节假日、温度累积效应共同塑造的结果只给它自己的历史等于让模型蒙着眼睛猜。这个方向适合两类人一类是想找一个「数据规整、评价指标明确、能完整跑通深度学习流程」的实战项目练手电力负荷预测正好满足另一类是做能源、园区、楼宇能耗相关工作的从业者需要一套能落地、能解释、能迭代的预测基线。它解决的核心问题是在给定历史负荷、气象、日历等多源特征的前提下预测未来某段时间的负荷值为调度、购电、设备启停提供依据。接下来我会按「数据怎么组织 → 模型怎么搭 → 特征怎么选 → 坑在哪 → 怎么验证」的顺序把这份源码类项目该有的落地路径讲透。2. 多特征电力负荷预测的数据组织与特征工程2.1 负荷数据的三种时间粒度与对齐方式电力负荷预测的第一步永远是数据对齐这一步做错后面模型再花哨都是白搭。常见的时间粒度有三种15 分钟96 点/天、30 分钟48 点/天、1 小时24 点/天。源码类项目里最常见的是 15 分钟粒度因为它既能反映负荷的日内波动又不至于像分钟级那样噪声过大。对齐的核心是「时间戳统一」。负荷表通常长这样一列时间戳一列负荷值。气象表可能是每小时一条日历表是按天一条。你要做的是把这三张表按统一的时间索引合并。我一般会先把所有时间戳转成pandas的DatetimeIndex然后用resample统一到目标粒度气象数据用插值补齐日历特征用merge直接广播到每个时间点。import pandas as pd import numpy as np # 读取负荷数据假设是 15 分钟粒度 load pd.read_csv(load.csv, parse_dates[timestamp]) load load.set_index(timestamp).sort_index() # 气象数据是小时级重采样到 15 分钟并线性插值 weather pd.read_csv(weather.csv, parse_dates[timestamp]) weather weather.set_index(timestamp).sort_index() weather weather.resample(15min).interpolate(methodlinear) # 日历特征按天生成再广播到 15 分钟 calendar pd.read_csv(calendar.csv, parse_dates[date]) calendar[date] calendar[date].dt.normalize() load[date] load.index.normalize() load load.merge(calendar, ondate, howleft) # 合并气象 df load.join(weather, howleft) df df.dropna()这段代码的逻辑是先把负荷和气象都统一到 15 分钟索引再把按天的日历特征通过日期列合并进来。参数上要注意interpolate的方法温度这类连续变量用线性插值没问题但降水这种稀疏变量更适合用前向填充。dropna会丢掉边界上无法插值的点如果数据量紧张可以改成fillna(methodffill)。2.2 多特征到底该放哪些温度、湿度、日期类型与滞后特征「多特征」不是越多越好我见过有人把能拿到的列全塞进去结果模型过拟合验证集误差反而上升。电力负荷预测里真正有稳定贡献的特征大致分四类。第一类是气象特征核心是温度。温度对负荷的影响是非线性的夏天高温推高制冷负荷冬天低温推高制热负荷中间有一段「舒适区」负荷对温度不敏感。所以直接放原始温度不够通常要做分段或加平方项。湿度在南方夏季也有明显影响但贡献通常小于温度。第二类是日历特征包括星期几、是否周末、是否节假日、月份、季度。这里有个容易忽略的点节假日前后的「调休」效应。比如国庆前一天的负荷曲线往往和普通工作日不同如果日历表里没有标注调休模型会学偏。第三类是滞后特征也就是历史负荷的滑动窗口。常见做法是取前 1 天同一时刻、前 7 天同一时刻、前 1 小时、前 2 小时等。滞后特征本质上是给模型提供「惯性」信息但要注意不能引入未来信息否则就是数据泄漏。第四类是交互特征比如「温度 × 是否工作日」「温度 × 月份」。这类特征在树模型里可以自动学到但在神经网络里显式构造往往能加速收敛。# 构造滞后特征 for lag in [1, 2, 4, 96]: # 96 表示前一天同一时刻15分钟粒度 df[fload_lag_{lag}] df[load].shift(lag) # 温度分段特征 df[temp_high] (df[temperature] 28).astype(int) df[temp_low] (df[temperature] 5).astype(int) # 交互特征 df[temp_x_workday] df[temperature] * df[is_workday] # 去掉因 shift 产生的空值 df df.dropna()参数说明shift(96)对应 15 分钟粒度下的一天如果你用的是小时粒度这里应该是 24。temp_high和temp_low的阈值不是固定的要根据你所在地区的实际负荷-温度曲线来定我一般会先画散点图看拐点。交互特征是否有效可以用特征重要性或相关性快速筛一遍不显著的直接删掉别舍不得。3. 深度学习模型选型LSTM、TCN 还是 Transformer3.1 为什么 LSTM 仍是负荷预测的稳妥基线在电力负荷预测这个任务上LSTM 及其变体GRU、BiLSTM依然是大多数源码项目的默认选择原因很实际负荷序列有明显的时序依赖LSTM 的门控机制能捕捉长短期模式而且实现成熟、调参经验多、在小数据集上不容易崩。一个典型的 LSTM 预测网络结构是输入层接收(batch, seq_len, n_features)的张量经过一到两层 LSTM取最后一个时间步的隐藏状态接全连接层输出预测值。这里的关键参数是seq_len也就是用过去多少步预测未来一步。15 分钟粒度下我一般取 96 到 192也就是过去 1 到 2 天。import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, n_features, hidden_size128, num_layers2, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizen_features, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout ) self.fc nn.Sequential( nn.Linear(hidden_size, 64), nn.ReLU(), nn.Linear(64, 1) ) def forward(self, x): # x: (batch, seq_len, n_features) out, _ self.lstm(x) # 取最后一个时间步 out out[:, -1, :] return self.fc(out)逻辑说明batch_firstTrue让输入维度是(batch, seq_len, features)符合大多数人的直觉。num_layers2加dropout0.2是我在负荷数据上比较常用的组合层数再多容易过拟合。fc部分先降到 64 维再输出是为了给非线性变换留空间。如果你的数据量很大可以把hidden_size提到 256但要注意同步增大 dropout。3.2 TCN 与 Transformer 在负荷预测中的适用边界TCN时序卷积网络的优势是并行计算和可控的感受野。它用膨胀因果卷积堆叠能在不增加太多参数的情况下覆盖很长的历史窗口。如果你的负荷序列有明显的多尺度周期日周期、周周期TCN 的膨胀卷积结构天然适合。缺点是它对超长依赖的建模能力不如注意力机制而且感受野需要手动设计。Transformer 在负荷预测里的应用这两年多了起来核心是自注意力能直接建模任意两个时间步的关系。但它有两个现实问题一是对数据量要求高几千条样本上 Transformer 往往跑不过 LSTM二是位置编码对周期性负荷的表达能力有限需要额外设计时间特征嵌入。我的经验是数据少于 5 万条样本优先 LSTM 或 TCN数据充足且追求极致精度再考虑 Transformer 类结构。模型适用数据量训练速度调参难度典型 MAPE 区间LSTM1 万条以上中等低2% - 5%TCN2 万条以上快中等2% - 4.5%Transformer5 万条以上慢高1.5% - 4%这张表里的 MAPE 区间是基于我接触过的公开负荷数据集和实际项目经验具体数值会随数据质量、预测步长、地区差异波动。别把表里的数字当承诺它只是帮你判断「值不值得上更复杂的模型」。4. 训练流程与关键参数从数据划分到早停策略4.1 时序数据不能随机划分训练集、验证集、测试集的正确切法这是血泪经验里排第一的坑用train_test_split随机划分时序数据。随机划分会让未来信息泄漏到训练集验证集误差看起来很美上线就翻车。正确做法是按时间顺序切前 70% 训练中间 15% 验证最后 15% 测试。如果要做滚动预测还得用滑动窗口的方式逐步推进。def temporal_split(df, train_ratio0.7, val_ratio0.15): n len(df) train_end int(n * train_ratio) val_end int(n * (train_ratio val_ratio)) train df.iloc[:train_end] val df.iloc[train_end:val_end] test df.iloc[val_end:] return train, val, test参数说明train_ratio和val_ratio不是固定的数据量小的时候可以 80/10/10数据量大且分布稳定时 70/15/15 更稳妥。切完之后一定要检查三个集合的负荷分布如果测试集恰好落在极端天气周误差会偏高这是数据本身的问题不是模型的问题。4.2 归一化、损失函数与早停三个决定收敛质量的设置归一化方面负荷值我一般用 Min-Max 归一化到 [0,1]因为负荷有明确的物理上下界。气象特征用 Z-Score 标准化因为温度、湿度的分布更接近正态。注意归一化参数必须只用训练集计算然后应用到验证集和测试集否则又是泄漏。损失函数默认用 MSE但如果你更关心相对误差可以用 MAPE 或 SMAPE 作为监控指标训练仍用 MSE因为 MAPE 在负荷接近零时不稳定。早停策略我习惯设patience10监控验证集损失连续 10 个 epoch 不下降就停同时保存验证集最优的模型权重。from sklearn.preprocessing import MinMaxScaler, StandardScaler # 只用训练集拟合 scaler load_scaler MinMaxScaler() temp_scaler StandardScaler() train[load_norm] load_scaler.fit_transform(train[[load]]) val[load_norm] load_scaler.transform(val[[load]]) test[load_norm] load_scaler.transform(test[[load]]) train[temp_norm] temp_scaler.fit_transform(train[[temperature]]) val[temp_norm] temp_scaler.transform(val[[temperature]]) test[temp_norm] temp_scaler.transform(test[[temperature]])逻辑说明fit_transform只出现在训练集上验证集和测试集只用transform。这个细节看起来简单但我在代码审查里见过不止一次写反的。早停的实现可以用 PyTorch 的手动循环也可以用pytorch-lightning的EarlyStopping回调后者更省事但多一层依赖。5. 多特征负荷预测的避坑与排查清单5.1 现象验证集 MAPE 很低测试集突然翻倍原因最常见的是数据泄漏。检查滞后特征是否在划分之后才构造或者归一化是否用了全量数据。另一个可能是测试集包含了训练集没出现过的模式比如极端天气或特殊节假日。解决把特征构造放在划分之后确保每个集合的特征只依赖自身及之前的数据。对测试集做分布检查如果发现异常考虑在训练集中补充类似样本或者接受这个误差并在报告中说明。5.2 现象模型预测曲线整体平移形状对但幅值偏原因归一化的反变换出了问题或者损失函数对幅值不敏感。也有可能是滞后特征里混入了未来信息导致模型学到了错误的基线。解决检查inverse_transform是否用了正确的 scaler。如果用的是 MSE可以尝试在损失里加一项对峰值的惩罚。滞后特征的构造顺序要严格按时间推进shift的步数不能为负。5.3 现象训练损失下降但验证损失震荡原因学习率过大或者 batch size 太小导致梯度噪声大。多特征输入下不同特征的尺度差异也会加剧震荡。解决先把学习率降到 1e-4 试试或者用ReduceLROnPlateau调度器。batch size 建议不低于 64。检查所有特征是否都做了归一化没归一化的特征会让优化器在参数空间里走 Z 字形。5.4 现象节假日预测误差明显高于工作日原因节假日样本少模型学不到足够的模式。日历特征里如果只有「是否节假日」这一个二值特征表达能力不够。解决把节假日按类型拆分比如春节、国庆、周末、调休工作日分别编码。如果某类节假日样本极少可以考虑用相似日的方法做数据增强或者单独训练一个节假日模型。5.5 现象换一个地区的数据模型完全失效原因负荷模式有强烈的地域性温度敏感度、作息规律、产业结构都不同。在一个地区训练的模型直接迁移到另一个地区特征分布对不上。解决迁移时至少要做特征对齐把温度分段阈值、滞后步数按新地区重新调整。更稳妥的做法是用新地区数据做微调冻结底层 LSTM只训练全连接层。如果数据量足够直接重新训练。6. 验证预测效果别只看 MAPE这几个指标和技巧更实用MAPE 是最常被引用的指标但它有个致命缺陷当实际负荷接近零时MAPE 会爆炸。电力负荷虽然很少接近零但在某些轻载时段MAPE 仍然会给出误导性的高误差。我一般会同时看三个指标MAPE 看整体相对误差RMSE 看绝对误差的量级峰值误差看模型在最关键时段的表現。峰值误差的计算方式是取测试集中负荷最高的 5% 时间点单独算这些点的 MAPE。这个指标比整体 MAPE 更能反映模型在调度场景下的可用性因为调度最关心的就是高峰时段预测准不准。def peak_mape(y_true, y_pred, top_ratio0.05): threshold np.percentile(y_true, 100 * (1 - top_ratio)) mask y_true threshold return np.mean(np.abs((y_true[mask] - y_pred[mask]) / y_true[mask])) * 100 def evaluate(y_true, y_pred): mape np.mean(np.abs((y_true - y_pred) / y_true)) * 100 rmse np.sqrt(np.mean((y_true - y_pred) ** 2)) pmape peak_mape(y_true, y_pred) return {MAPE: mape, RMSE: rmse, Peak_MAPE: pmape}参数说明top_ratio0.05表示取最高的 5% 负荷点这个比例可以根据你的业务需求调整如果调度只关心最高的 1%就改成 0.01。peak_mape里的 mask 用的是真实值的分位数不是预测值的这一点别搞反。除了指标还有一个我常用的验证技巧画「预测 vs 实际」的散点图按小时着色。如果某个小时的散点明显偏离对角线说明模型在那个时段有系统性偏差可能是特征里缺少该时段的特殊信息比如早晚高峰的交通或生产活动规律。最后一个习惯每次调完参把验证集和测试集的指标、关键超参数、数据版本记在一个表格里。我吃过亏改了五六轮之后忘了哪组参数最好只能重跑。这个习惯看起来笨但能省下大量后悔药。希望帮到你。本文还有配套的精品资源点击获取