简介面向高校学生与期末大作业场景一套基于 Python 深度学习的多特征电力负荷预测课程设计项目覆盖从数据预处理、特征构造、LSTM 模型训练到预测结果可视化的完整流程也适合深度学习入门者进行项目实践。压缩包仅 8 个文件包含 3 个 Python 脚本、2 个 CSV 数据文件、1 个 Excel 文件、1 个 Markdown 说明和 1 个使用说明 txt整体约 831KB结构清晰下载后无需修改即可直接运行。目前已有 481 人学习适合作为课程设计或期末考核的高分参考。具体来看项目提供 data_processing.py 数据预处理、lstm_predict.py 负荷预测主程序、data_show.py 可视化脚本并配套 raw_data.csv、power.csv 等原始数据以及 README 和使用说明文档便于快速理解多特征怎么构造、数据如何清洗、模型怎样搭建与评估。对想要快速完成并拓展深度学习电力预测任务的学习者这是一份可直接复用的完整实践。1. 电力负荷预测不是玄学这类课程设计源码包到底能帮你省多少事「电力负荷预测」课程设计压缩包打开后一般是一套 python 代码加一份 CSV 数据。拿到这类包的人多半卡在毕设或课设中段知道深度学习能预测负荷但不清楚多特征怎么拼进网络更怕训练完画出的预测曲线是一条平直线。这个方向的本质不复杂把历史负荷和气象、日期、节假日等外部变量一起喂给神经网络让它学会未来一段时间的负荷走势。它适合电力相关专业的学生、刚入门的能耗预测工程师以及想尽快拿到一份可复现基线的人。源码包的价值不在跑通而在给你一条能改、能讲、能应对答辩的完整链路数据对齐、滑窗构造、模型训练、指标评估每一步都值得自己重写。下面按我做负荷预测的顺序把这个方向拆开讲清楚。2. 先把数据集看明白负荷数据的时间尺度和多特征对齐决定模型上限2.1 电力负荷数据的三种时间尺度15 分钟、1 小时、1 天怎么选很多人翻车不是模型选错而是没先问一句这份 CSV 里的负荷是多长时间采一个点。采样密度直接决定你能预测多远、窗口该设多长、特征怎么对齐。15 分钟采样一天有 96 个点适合短时调度和需求响应窗口设 96 就能覆盖一整天但缺测和异常点也更密。1 小时采样一天 24 个点是课程设计最常见的选择窗口 24 或 48 就能覆盖日周期训练快、特征对齐也容易。日采样一年才 365 个点样本量太小深度学习优势发挥不出来用传统时序方法往往更贴合除非你有多年数据。我拿到数据后不急着建模先用 pandas 按时间列排序检查采样间隔有没有跳变。间隔跳变比缺测更隐蔽——如果某天少了两个 15 分钟点直接按行切窗口会把不同时刻的数据错位拼到同一行。另一个常见问题是时区CSV 里时间如果是北京时间但天气数据用的是世界标准时间两者对不上预测结果会整体偏移一小时。这种问题在曲线图上很难一眼看出来因为形状是对的只有按小时聚合误差时才会暴露。数据粒度常见窗口长度常见预测步长典型场景15 分钟961 天1-16 个点短时调度、需求响应1 小时24-1681-24 小时课程设计主流配置1 天30-3651-7 天月度规划样本量少需谨慎表格里的窗口长度是经验值不是硬性规定。关键判断标准是窗口至少要覆盖一个完整日周期也就是 24 个点或 96 个点如果数据有明显的工作日/周末差异窗口再拉长到一周效果更好。但窗口每翻一倍样本量会相应减少训练时间也会变长课程设计里不建议一上来就追长窗口。2.2 多特征对齐的四个边界缺测、异常尖峰、节假日、滑动窗口切割多特征在负荷预测里通常指这几类历史负荷本身、温度、湿度或风速、时刻编码小时序号、星期几、是否节假日。它们的采样频率经常不一样——气象站数据往往是小时级负荷可能是 15 分钟级对齐时要么重采样到同一频率要么把低频特征前向填充。低频特征不能直接后向填充因为天气预报本质上只知道过去和当前时刻的值未来时刻的天气在真实场景里是预报值不能拿实测值来填否则又是一种数据泄漏。import pandas as pd import numpy as np # 读入原始数据负荷与气象分开是常态 df_load pd.read_csv(load.csv, parse_dates[time]) # 负荷: time, load_kw df_weather pd.read_csv(weather.csv, parse_dates[time]) # 气象: time, temp, hum # 1) 统一重采样到小时级取均值是为了压掉采样噪声 df_load df_load.set_index(time).resample(1h).mean().reset_index() df_weather df_weather.set_index(time).resample(1h).ffill() # 气象缺测用前向填充 # 2) 时间特征小时序号 星期几 节假日标记 df pd.merge(df_load, df_weather, ontime, howleft) df[hour] df[time].dt.hour df[weekday] df[time].dt.weekday df[holiday] df[time].dt.date.isin(holiday_dates).astype(int) # holiday_dates 需自行维护 # 3) 处理异常尖峰超过 3 倍滚动标准差的位置替换为前后均值 roll_mean df[load_kw].rolling(24, centerTrue).mean() roll_std df[load_kw].rolling(24, centerTrue).std() mask np.abs(df[load_kw] - roll_mean) 3 * roll_std df.loc[mask, load_kw] roll_mean[mask] print(df.describe())这段脚本解决的是对齐问题而不是建模问题。重采样到 1 小时意味着你放弃了 15 分钟粒度的高频信息换来的是气象特征能直接对齐前向填充处理缺测是保守做法如果缺测段超过 6 小时我会直接删掉而不是填充。异常尖峰的阈值 3 倍滚动标准差是基于负荷数据的经验值工业负荷在换班或设备启停时会产生尖峰不处理会让模型为了拟合尖峰而牺牲整体曲线形状。节假日特征值得单独说。法定节假日调休带来的「周末上班、工作日放假」模式让负荷曲线和普通星期几完全不同。如果你不想维护一个完整节假日列表至少要把「是否周末」放进特征想效果好一点就加上节前一天和节后一天的标记。很多课程设计数据只给了两三年节假日样本本身很少模型很难自己学出来显式特征比让网络隐式学习靠谱得多。2.3 滑动窗口怎么切预测步长先于窗口长度决定切窗口时有个顺序容易搞反先想清楚要预测未来 1 小时还是未来 24 小时再回头定窗口长度。预测步长由题目要求决定窗口长度是为这个目标服务的。预测未来 1 小时用过去 24 小时作为窗口通常够了预测未来 24 小时一般需要过去一周的负荷形态。多特征场景下窗口内每个时间点都包含全部特征而不是只把负荷拼在一起这一点新手特别容易漏。def make_samples(df, feature_cols, target_col, window24, horizon1): X, y [], [] data df[feature_cols].to_numpy() target df[target_col].to_numpy() for i in range(len(data) - window - horizon 1): X.append(data[i:iwindow, :]) # 窗口内的所有特征 y.append(target[iwindow:iwindowhorizon]) # 未来 horizon 个点的负荷 return np.array(X), np.array(y) # 使用示例window24, horizon1预测未来 1 小时 X, y make_samples(df, feature_cols, load_kw, window24, horizon1) print(X shape:, X.shape) # (样本数, 窗口长度, 特征数) print(y shape:, y.shape) # (样本数, 预测步长)逻辑说明X 的第一个维度是样本数第二个维度是窗口长度第三个维度是特征数深度学习模型的输入张量就是这个三维结构。y 取的是窗口之后 horizon 个点的真实负荷值要特别注意这里不要让窗口包含 y 所在的时间段否则就是数据泄漏。参数上 window 和 horizon 是两个独立参数horizon 设为 24 时y 的形状会变成 (样本数, 24)这对应多步预测如果只想预测下一个点horizon 保持 1 就能让任务简单很多。切完窗口后我习惯随机抽几个样本人工检查窗口内第一个时间点是否确实是前一行的下一小时。这个检查只需要一分钟但能避免很多后续训练时的怪象。尤其是跨年数据如果 12 月 31 日最后一段被硬拼进 1 月 1 日的窗口模型会学到一条根本不存在的负荷曲线。3. 模型选型LSTM、TCN 还是 Transformer多特征负荷预测的取舍3.1 为什么 LSTM 是这类课程设计的默认答案负荷序列有典型的日周期和周周期LSTM 这类循环网络天然适合按时间步展开把上一个时刻的隐状态传给下一个时刻能捕捉这种规律。相比 TCN 和 TransformerLSTM 在样本量几千到几万的小数据集上更容易训练可控不容易出现注意力矩阵学偏的问题。所以课程设计源码包里最常见的主模型就是 LSTM 或它的变体 BiLSTM。选 LSTM 还有一个现实理由代码短。一个两层的 LSTM 加一个全连接输出层PyTorch 里 30 行以内能写完调试时想看中间隐状态也方便。TCN 的膨胀卷积需要调 kernel size、dilation、padding 一堆参数对新手不友好Transformer 则需要位置编码和更长的训练轮次才能在负荷预测上超过 LSTM。课程设计的核心目标是在有限时间内拿出一套完整方案而不是追求零点几个百分点的指标提升。3.2 把多特征喂进 LSTM输入张量的 shape 与滑窗构造LSTM 的输入是三维张量形状为 (batch_size, sequence_length, input_size)。其中 sequence_length 是窗口长度input_size 是每个时间点的特征数。很多人第一次跑通源码后想自己加特征结果在 shape 上报错就是因为没理解第三个维度是「特征数」而不是「样本数」。加了温度、湿度、节假日之后input_size 从 1 变成 5 甚至 10模型本身不用改只要把输入张量的最后一维对好就行。import torch import torch.nn as nn class MultiFeatureLSTM(nn.Module): def __init__(self, n_features, hidden_size64, num_layers2, horizon1): super().__init__() self.lstm nn.LSTM( input_sizen_features, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropout0.2 ) self.fc nn.Linear(hidden_size, horizon) def forward(self, x): # x: (batch, window, n_features) out, _ self.lstm(x) # out: (batch, window, hidden_size) out out[:, -1, :] # 取最后一个时间步的隐状态 return self.fc(out) # (batch, horizon) model MultiFeatureLSTM(n_features5, hidden_size64, num_layers2, horizon1) print(model)这里 n_features5 对应一个简化多特征配置负荷、温度、湿度、小时序号、是否周末。hidden_size64 是课程设计级别的常见选择再大容易过拟合num_layers2 能学到稍复杂的非线性关系到 3 层以上在小数据集上收益很小。取最后一个时间步的隐状态而不是所有时间步的输出是因为要预测的是未来负荷只需要模型读完整个窗口后的综合信息。如果你做多步预测可以在 fc 层把输出维度改成 horizon而不是在 LSTM 里循环预测。如果你要冲高分可以试试 BiLSTM。双向结构让模型同时看窗口内「之前」和「之后」的负荷变化对捕捉早晚高峰的对称形状有帮助。要注意的是BiLSTM 要求整个窗口完整输入后才能输出不适合在线滚动预测课程设计里预测未来一段时间的离线任务完全可以用但如果演示的是实时预测单向 LSTM 更合适。多步预测也有两种做法直接多步是把全连接层输出维度设为 horizon一次吐出未来 24 小时的预测值滚动多步是用预测值喂回输入继续预测下一步误差累积更严重负荷场景里我一般不推荐后者。3.3 三行配置对比单序列基线、多特征 LSTM、Transformer 的参数量与效果边界为了让你对选型有直观感受这里给一张常用配置对比说明各自的适用边界而不是抬杠谁一定最好。方案输入特征参数量量级训练时长小时级数据适用边界单序列 LSTM仅历史负荷约 1-2 万几分钟适合拖底基线、Debug 用多特征 LSTM负荷气象日期约 2-4 万十几分钟课程设计主推性价比高Transformer同多特征约 5-10 万半小时以上数据量大10 万 样本才有优势Transformer 在负荷预测上不是不能打但它的 attention 需要大量样本才能学出「每周一上午负荷偏高」这种规律。课程设计的数据集往往只有几千到几万条跑 Transformer 常常出现训练集损失降得很漂亮、验证集波动很大的现象也就是过拟合。我一般会把它放在「改进方向」里提一句而不是作为主模型。从工程角度看多特征 LSTM 兼顾了可解释性和训练速度你可以做特征消融——把温度、湿度依次去掉看指标变化也能在 CPU 上十分钟内完成一轮训练。真到了需要把预测结果接到调度系统里的生产场景LSTM 的推理时延也远低于 Transformer。4. 训练与验证用 7:2:1 切分还是按时间滚动别把未来数据漏进训练集4.1 时间序列切分的特殊性随机打乱是翻车第一步普通机器学习里随机划分训练集和测试集是标准操作但时间序列不行。相邻时刻的负荷高度相关如果随机打乱模型会「偷看」到未来一段时间的信息测试集就失去了意义。最常见的翻车现场是模型在一个随机划分的数据集上 MAPE 只有 2%看起来很漂亮但老师要求按时间顺序预测未来一周结果曲线完全跟不上真实负荷。推荐的切分方式是按时间顺序前 70% 训练、中间 10% 验证、后 20% 测试。验证集用来挑轮次和调参测试集只在最终评估时用一次。如果你把测试集也用来调参最后的指标就是自欺欺人——答辩时老师只要问一句「这个误差是在哪个数据集上算的」就会露馅。更严格的做法是滚动切分每训练一轮把测试窗口往后移模拟真实预测场景但课程设计里 7:2:1 已经足够。提示如果数据带有明显的季节趋势只按前 70% 连续切分可能让测试集与训练集的季节分布差异过大常见做法是再做一次滚动评估来交叉验证结论。4.2 复现训练脚本损失函数、学习率、早停与归一化反算训练脚本通常是这个结构先归一化再构造 DataLoader然后进入训练循环每个 epoch 结束在验证集上评估一次验证损失下降才保存模型。下面这份脚本可以直接抄到你的项目里但要注意几个顺序问题。import torch import torch.optim as optim from torch.utils.data import DataLoader, TensorDataset # 归一化要在切分之后做只用训练集的统计量 mean X_train.mean(axis(0, 1)) # 按特征维度算均值 std X_train.std(axis(0, 1)) 1e-8 X_train_norm (X_train - mean) / std X_val_norm (X_val - mean) / std y_mean, y_std y_train.mean(), y_train.std() y_train_norm (y_train - y_mean) / y_std y_val_norm (y_val - y_mean) / y_std train_loader DataLoader(TensorDataset(torch.tensor(X_train_norm, dtypetorch.float32), torch.tensor(y_train_norm, dtypetorch.float32)), batch_size64, shuffleTrue, drop_lastTrue) model MultiFeatureLSTM(n_featuresX_train.shape[2], hidden_size64, num_layers2, horizon1) optimizer optim.Adam(model.parameters(), lr1e-3) scheduler optim.lr_scheduler.ReduceLROnPlateau(optimizer, factor0.5, patience5) criterion nn.MSELoss() best_val float(inf) for epoch in range(60): model.train() for xb, yb in train_loader: optimizer.zero_grad() pred model(xb) loss criterion(pred.squeeze(), yb) loss.backward() optimizer.step() model.eval() with torch.no_grad(): val_pred model(torch.tensor(X_val_norm, dtypetorch.float32)) val_loss criterion(val_pred.squeeze(), torch.tensor(y_val_norm, dtypetorch.float32)) scheduler.step(val_loss) if val_loss best_val: best_val val_loss torch.save(model.state_dict(), best_model.pt) if epoch % 10 0: print(epoch, loss.item(), val_loss.item())这段代码有几个容易被忽略的点。归一化必须放在切分之后并且只能使用训练集的 mean 和 std否则验证集的信息会通过统计量泄漏进训练过程y 也要单独做归一化不能直接用 X 的统计量因为它们的尺度完全不同。batch_size64 是常见值数据量小时可以用 32shuffleTrue 在训练时是允许的——这里打乱的是样本之间的顺序样本内部的窗口仍然按时间排列所以不构成时间泄漏。学习率用 ReduceLROnPlateau验证损失连续 5 个 epoch 不降就减半这比固定学习率更省心。模型每轮验证一次只在验证损失变好时保存权重这样即使后续轮次过拟合手里仍有最佳版本。这就是我常说的后悔药训练到第 60 轮时验证集飘了但你不需要重新跑直接加载 best_model.pt 即可。训练轮次 60 对小时级数据通常够用如果数据量大可以按验证损失早停不必死等 60 轮。4.3 评价指标MAE、RMSE、MAPE 在负荷预测里的解读训练结束要算三个指标MAE、RMSE、MAPE。它们看问题的角度不一样MAE 是平均绝对误差单位与负荷一致最直观RMSE 放大尖峰误差适合评估最坏情况MAPE 是百分比误差便于在不同数据集间对比但负荷接近零时会被放大到离谱的值。from sklearn.metrics import mean_absolute_error, mean_squared_error def evaluate(y_true, y_pred): y_true y_true * y_std y_mean # 反归一化回真实负荷值 y_pred y_pred * y_std y_mean mae mean_absolute_error(y_true, y_pred) rmse mean_squared_error(y_true, y_pred, squaredFalse) nz_mask y_true 0.05 * y_mean # 低负荷时刻不参与 MAPE mape np.mean(np.abs((y_true[nz_mask] - y_pred[nz_mask]) / y_true[nz_mask])) * 100 return mae, rmse, mape mae, rmse, mape evaluate(y_val.numpy(), val_pred.squeeze().numpy()) print(fMAE{mae:.2f} kW, RMSE{rmse:.2f} kW, MAPE{mape:.2f}%)反归一化是新手最容易漏的一步。模型训练时用的是归一化后的数值预测出来的也是归一化值必须乘以训练时保存的 y_std 再加 y_mean 才能得到真实负荷。MAPE 加了一个保护条件只对大于 5% 平均负荷的样本计算这是行业里的常见做法因为凌晨低负荷时段绝对误差很小但百分比误差会非常大把整体 MAPE 拉得很高不能真实反映模型质量。指标算出来怎么用如果 MAE 相对平均负荷在 5% 以内说明模型抓到了主要模式RMSE 明显大于 MAE 说明存在少数预测得很差的尖峰样本MAPE 偏大而 MAE 正常多半是低负荷时段拖累。答辩时能把这三个指标的关系讲清楚比堆一堆花哨曲线更能让老师认可。5. 避坑与调试5 个让新手最容易翻车的细节这几条是我在帮学生调这类课程设计项目时最常碰到的按出现频率排序。每条都按现象、原因、解决三个层次写方便对照。5.1 数据泄漏滑窗里混进了未来值现象训练集指标非常好验证集也不差一到测试集就崩或者做滚动预测时误差越来越大。这类泄漏在气象特征上尤其隐蔽因为天气数据如果用了实测值而不是预报值相当于模型提前知道了未来天气。原因最常见的泄漏有两种。一是归一化统计量把测试集信息混进去了——先用全部数据算 mean 和 std 再切分等于让模型偷看了未来的分布二是滑窗构造时把预测目标也放进了窗口特征列特征里包含「下一时刻负荷」标签也是「下一时刻负荷」模型直接抄答案验证和测试当然对不上。解决我的固定流程是先切分再只对训练集 fit 归一化统计量验证集和测试集仅 transform构造窗口时让 y 的起始位置严格等于窗口末尾的下一个时间点。保险起见加一行断言assert np.all(X[:, -1, load_col] y[:, 0])确保窗口最后时刻不晚于预测目标时刻。这一行断言能拦住大部分粗心导致的泄漏。5.2 归一化范围不对导致预测是平直线现象预测曲线是一条几乎水平的直线数值接近训练集均值完全没有早晚高峰的形状。很多人在这一步就开始怀疑模型坏了其实问题多半出在数据处理。原因最常见的是只归一化了 X 没归一化 y或者归一化 y 时用错了统计量。另一个原因是特征尺度差异过大——负荷数值是几千温度只有几十模型把所有注意力都放在负荷上输出自然趋于保守的平均值。最后一层激活函数也可能导致这个问题如果输出层接了 sigmoid 或 tanh输出被限制在 [0,1] 或 [-1,1] 区间而标签没压缩到这个范围反归一化后只能落在均值附近。解决X 按特征维度归一化y 单独归一化同时检查输入特征是否包含温度这种小尺度变量必要时对每个特征分别标准化而不是统一用一个 scaler。输出层直接接线性层不加激活函数回归任务不需要把输出压到某个区间。画预测曲线时如果验证集上是一条平直线先查这两处比调模型参数快得多。5.3 日期特征没编码成周期性节假日预测全偏现象周一到周五的预测误差小周末误差大或者长假期间预测严重偏离实际。负荷曲线在节假日的形状和普通工作日完全不同但模型好像完全没有意识到这一点。原因小时序号和星期几是周期变量直接当整数喂进模型会学出「0 点和 23 点差异 23」这种错误关系。节假日被简单地当作 0/1 标志但节假日前后一天的负荷形态与平时完全不同单靠一个二值特征表达不了这种过渡。解决小时序号和星期几用正弦余弦编码比如sin(2πh/24)和cos(2πh/24)保留周期性节假日特征扩成三列节前 1 天、节假日当天、节后 1 天让模型能区分调休和平时的边界。这个改动一般能明显改善节假日样本的误差而且实现成本很低就是在特征工程里多构造两列。5.4 GPU 显存不足时 batch 与 window 怎么取舍现象一跑训练就报错提示 CUDA out of memory。这在课程设计里大多发生在窗口设成 168 且特征数超过 10 的情况下。原因窗口长度 168、特征数 20、batch_size 64 的组合会让 LSTM 在反向传播时占用大量显存尤其是 num_layers 较大时。LSTM 的反向传播需要保存每个时间步的中间状态窗口越长、隐层越大显存占用成倍上涨。解决先把 batch_size 降一半从 64 降到 32再考虑缩短窗口到 72 或 48最后才是减少特征数。注意缩短窗口会牺牲模型对长期周期的记忆能力所以优先降 batch。如果你还在 CPU 上跑干脆把 hidden_size 降到 32训练速度能快不少。显存问题本质上是用空间换时间课程设计的数据量不大CPU 上多等几分钟通常可以接受。5.5 源码跑通但数字对不上随机种子与框架版本现象同一个人、同一份数据第一次跑 MAPE4.2%第二次跑变成 4.8%排错半天找不到原因。更头疼的是你换一台机器跑别人的源码指标对不上也不知道是代码问题还是环境问题。原因深度学习训练有随机性参数初始化、DataLoader 打乱顺序、dropout都会带来运气的成分。框架版本差异也会影响结果PyTorch 1.x 和 2.x 在 LSTM 的底层实现上有数值差异同一份代码可能跑出略微不同的指标。解决在训练脚本开头固定随机种子random.seed(42)、np.random.seed(42)、torch.manual_seed(42)并在 DataLoader 里设置 generator。多个实验对比时所有模型必须在同一随机种子和同一框架版本下跑否则你比较的不是模型能力而是运气。这个习惯养成后「数字对不上」的排查时间能少一半。6. 把课程设计变成可展示的项目一份能自圆其说的 README 与三张图源码跑通只是第一步课程设计评分看的是你能不能把自己的工作讲清楚。我会建议你在项目里补三样东西一份结构清晰的 README、两张预测效果图、一张误差分布图。README 按这个顺序写问题定义预测未来 1 小时负荷输入哪些特征、数据处理流程重采样、对齐、滑窗、模型结构LSTM 几层、hidden 多大、训练配置切分比例、学习率、早停、结果表MAE/RMSE/MAPE 三个指标、复现命令一行python train.py。不要写大段原理介绍老师更关心你做没做、结果多少。每一节控制在三五句话能让人照着跑通就算合格。三张图怎么选第一张是测试集某连续 7 天的真实负荷与预测负荷对比曲线能直观看到早晚高峰拟合得如何第二张是 24 小时误差分布按小时聚合 MAE能看出凌晨是否更差第三张是特征消融的柱状图把温度特征去掉后 MAPE 上升了多少。有这三张图答辩时每张图都能讲出两分钟的内容。我自己的习惯是跑完基线后先画误差分布图而不是直接调模型。因为按小时聚合后的误差会告诉你该往哪个方向改进——如果凌晨误差最大优先检查低负荷时段的归一化处理如果午间误差最大就该看温度特征是否对齐正确。这个习惯帮我在不少项目里省掉了无效调参的时间。记住源码包只是起点你把数据理解、模型选型和误差分析讲清楚这门课就稳了。希望帮到你。本文还有配套的精品资源点击获取