简介：时间序列预测是数据分析中的重要课题，其核心在于利用历史观测值推断未来趋势，而电力负荷预测正是这一技术在能源领域的典型应用。负荷预测的原理基于用电需求的周期性、趋势性和随机性，通过构建可学习的数学模型，帮助调度人员提前掌握电网负载变化。该技术价值显著，既能优化发电计划、减少能源浪费，又能支撑售电公司制定更精准的购电策略，还能为电力市场交易提供决策依据。在实际应用中，短期负荷预测通常聚焦小时级或分钟级数据，服务于电网调度、需求响应和储能管理。由于传统统计方法难以刻画负荷数据的非线性与复杂外部影响，深度学习模型如LSTM凭借其出色的序列建模能力，成为主流解决方案。本文以一个完整的Python工程为例，系统梳理了负荷预测的LSTM建模流程，从数据清洗、时间特征编码到滑动窗口构造与模型训练调参，并重点剖析了特征工程对预测精度的关键作用，为电力时序预测实践提供了可落地的参考。
1. 项目概述：为什么要做电力负荷预测
电力负荷预测，说白了就是预估未来某个时间段内电网要承载多大的用电量。这个项目做的是基于深度学习的短期负荷预测，预测粒度通常定位到小时级或15分钟级，输入历史负荷数据和相关特征，输出未来几小时到几天的负荷曲线。用Python实现，附带完整的源码和文档说明。
这个项目解决的是电力系统里的一个经典问题：发电和用电必须实时平衡。电不能大规模储存，发多了浪费燃料、增加碳排放，发少了就会拉闸限电，影响生产生活。所以调度人员需要提前知道负荷大概是多少，才能安排机组启停、制定发电计划。对售电公司来说，准确的负荷预测也意味着更精准的购电策略和更小的偏差考核损失。
适合阅读这篇文章的朋友包括三类：一是电力专业的在校学生，课程设计或毕业论文正好需要一套能跑的预测代码；二是电网或发电企业的技术人员，想用深度学习方法替代传统的统计学预测方案；三是做时序预测的算法工程师，想看看负荷预测这个场景下有哪些容易踩的坑。项目源码我已经整理好，文档也写得比较细，从数据清洗到模型调参都有覆盖，照着跑就能出结果。
2. 方案设计：为什么选深度学习，以及整体思路
2.1 传统方法到底卡在哪里
在做负荷预测这个方向上，传统方法以ARIMA、指数平滑、多元线性回归为主。这些方法在负荷曲线平稳、规律明显的场景下表现还行，但有三个明显的短板。
第一，负荷数据本质上是非线性的，受天气、节假日、生产活动、突发事件等多重因素耦合影响。比如夏天一场暴雨，气温骤降，空调负荷瞬间掉下去一大块，ARIMA这种线性模型很难捕捉这种突变。第二，传统方法对特征的处理能力弱，想加入温度、湿度、星期类型这些外部变量，需要手工设计滞后项和交互项，工程量大且效果不稳定。第三，传统方法的预测步长拉长后误差会快速膨胀。
深度学习模型，尤其是LSTM（长短期记忆网络）和GRU（门控循环单元），天生就是为序列数据设计的。它们的记忆机制能捕捉负荷曲线中的长短期依赖——比如今天的负荷可能和昨天同一时刻、上周同一时刻有很强的相关性，这种周期性规律正是负荷预测中最有价值的信号。用CNN（卷积神经网络）做负荷预测也是一种方案，思路是把一段时间的负荷序列当成一维图像来提取局部特征，但纯CNN在捕捉超长周期依赖上不如LSTM自然，所以实际项目中LSTM用得最多。
2.2 整体技术链路与方案选型
这个项目的完整链路是：数据获取 → 数据清洗 → 特征工程 → 构造监督学习数据集 → 搭建模型 → 训练调参 → 评估对比 → 预测出图。每一步都有对应的Python代码，文档里也写清楚了每个文件的作用。
模型选型上，我用了两层LSTM加全连接输出层的结构。第一层LSTM设置64个隐藏单元，返回完整序列，第二层32个隐藏单元只返回最后一个时间步的输出，再接一个Dense层输出预测值。中间加Dropout防止过拟合。这套配置在中等规模的数据集上表现稳定，训练速度也快，单张普通显卡几分钟就能跑完一个epoch。
为什么不用更复杂的模型？原因很简单：负荷预测的数据量通常没有图像识别那么大，一个区域可能就几千天的历史数据，拆成滑动窗口样本也就几十万条，这个规模下Transformer相对LSTM的优势不明显，反而训练成本高、小样本下容易过拟合。GRU可以作为一个对比实验，它的参数比LSTM少，训练更快，在大规模数据上效果和LSTM接近，但LSTM在小数据集上通常更稳一些。
2.3 特征工程：负荷预测的胜负手
很多新手做负荷预测，直接拿历史负荷序列丢给LSTM就完事了，结果发现预测曲线总是滞后一天。这种情况的核心原因就是特征太单一，模型没法区分工作日和周末、没感知温度变化，只能把昨天的负荷平移过来。
我在项目里做了三组特征。第一组是历史负荷序列，也就是滑动窗口截取的前面若干个时刻的负荷值；第二组是时间特征，包括小时、星期几、是否节假日，其中小时用了正弦余弦编码，避免0点和23点在数值上相差太大而误导模型；第三组是气象特征，包括温度、湿度，如果数据源里有体感温度或气象预报字段也可以加进来。
需要特别说明的是，节假日特征对负荷预测影响极大。春节、国庆这种长假期间，工厂停工、商业负荷变化剧烈，很多学校放假，负荷曲线和普通工作日完全不是一个规律。不处理节假日，模型在这些日子的预测误差会非常难看。我在代码里用了一个简单的办法：把节假日置为1，其余时间置为0，同时把节假日前一天、后一天也单独标出来，因为负荷在这些边缘日期会有明显的转移效应。
2.4 评估指标：怎么判断预测准不准
负荷预测的评估指标我用三个：MAE（平均绝对误差）、RMSE（均方根误差）和MAPE（平均绝对百分比误差）。MAE直观反映平均偏差大小，适合业务人员理解；RMSE因为对大误差惩罚更重，能敏感地暴露某些时段预测崩溃的问题；MAPE用百分比表示，方便在不同量级的区域之间横向对比。
实操中，MAPE在负荷预测里有个陷阱：负荷值本身就低的时间段（比如凌晨3点）分母很小，一点绝对误差就会被放大成很大的百分比，导致MAPP指标被低估。所以我在代码里对MAPE做了一个下限保护，负荷低于某个阈值（比如最大负荷的10%）的样本不参与MAPE计算，或者在分母上加一个平滑项。这个细节在文档里有说明，否则你会在凌晨低谷段看到一些吓人的误差尖峰，误以为模型出问题了。
3. 核心代码实现：源码逐段拆解
3.1 数据读取与清洗
原始数据是CSV格式，包含时间戳、负荷值、温度、湿度几个字段。读取用pandas，这一步需要注意时间列的解析，务必指定时间格式，否则pandas会自动推断，不同环境下可能解析出不同的结果。
import pandas as pd import numpy as np from sklearn.preprocessing import MinMaxScaler from sklearn.model_selection import train_test_split df = pd.read_csv('load_data.csv', parse_dates=['datetime'], index_col='datetime') df = df.sort_index() # 处理缺失值：负荷数据一般用前向填充，避免引入未来信息 df['load'] = df['load'].ffill() # 按小时重采样，如果数据是15分钟粒度也可以保留，这里以小时为例 df = df.resample('H').mean()数据清洗我觉得最少要做两件事。一是处理缺失值，我的做法是前向填充，因为电力负荷是连续缓变的过程，前一个值通常是最近的合理估计；但如果缺失时间过长（超过数小时），建议用相邻几天的同一时刻取均值来填，否则会把偏差带入模型。二是处理异常值，比如某天某个时刻负荷突然变成0，这通常是采集设备故障或通信中断导致的，直接用前后时刻的中位数替换即可。千万别用均值替换，尖峰型的异常值会拉高均值，影响后续归一化。
3.2 特征构造与数据集切分
时间特征的正弦余弦编码是关键一步。我先把小时和星期的循环特性编码成二维向量，让0点和23点映射到单位圆上距离很近的点，这样模型不会因为数值大小而产生误解。
df['hour'] = df.index.hour df['weekday'] = df.index.weekday df['hour_sin'] = np.sin(2 * np.pi * df['hour'] / 24) df['hour_cos'] = np.cos(2 * np.pi * df['hour'] / 24) df['week_sin'] = np.sin(2 * np.pi * df['weekday'] / 7) df['week_cos'] = np.cos(2 * np.pi * df['weekday'] / 7)然后是构造监督学习的输入输出对。这里有一个核心参数：look_back，也就是滑动窗口大小。我建议在小时级数据上设为24的倍数，比如24（预测点与前24小时相关）、72或168（一周）。窗口太短模型信息不足，窗口太长会引入太多噪音且训练变慢。可以用实验对比不同窗口的验证集误差来选择，我在项目里默认用了168，也就是整整一周的历史数据来预测下一小时，效果比24好不少。
数据集切分这里必须强调：时序数据不能随机切分。用sklearn的train_test_split容易踩坑，因为默认shuffle=True会把时间顺序打乱，导致训练集里出现“未来”数据，模型相当于开卷考试。正确做法是按时间顺序切分，比如前70%训练，中间15%验证，最后15%测试。这一步做错的话，验证集误差会虚低，但实际上线一塌糊涂。
# 千万不要用 train_test_split 默认参数 # train_data = df.iloc[:int(len(df) * 0.70)] # val_data = df.iloc[int(len(df) * 0.70):int(len(df) * 0.85)] # test_data = df.iloc[int(len(df) * 0.85):]我实际做归一化有个地方要特意提一下：MinMaxScaler的fit操作必须只用训练集的数据，然后transform训练集、验证集和测试集。很多初学朋友会把整个数据集丢进去fit，这样验证集测试集的分布信息已经提前泄露给了归一化器，理论上也是数据泄漏。虽然在负荷预测中影响不大，但严谨的论文审稿人或面试官会注意到这个细节。
3.3 滑动窗口与训练样本生成
构造样本时，由于look_back=168意味着前168个点没有历史可参考，这部分数据会被丢弃，所以实际样本数约为总长度减去look_back。我用一个函数来生成输入和标签，标签是下一时刻的负荷值，对应单步预测模式。
def create_sequences(data, look_back=168): X, y = [], [] for i in range(len(data) - look_back): X.append(data[i:i + look_back]) y.append(data[i + look_back, 0]) # 标签取负荷列 return np.array(X), np.array(y)这里有个内存问题：如果数据量大，循环生成X、y会很慢，而且全部加载到内存可能爆掉。我自己实践下来，几十万样本量级直接循环没问题，但如果数据是分钟级、跨度几年，样本量可能到百万级，建议用tf.data.Dataset的window方法或PyTorch的Dataset类，避免一次性加载。
3.4 模型构建与训练配置
模型用Keras Sequential实现。LSTM输入的形状是(batch_size, look_back, feature_dim)，feature_dim是特征数。我的特征列包括负荷、温度、湿度、小时正余弦、星期正余弦、节假日标记，一共9个特征，所以input_shape=(168, 9)。
from tensorflow.keras.models import Sequential from tensorflow.keras.layers import LSTM, Dense, Dropout from tensorflow.keras.callbacks import EarlyStopping, ReduceLROnPlateau model = Sequential() model.add(LSTM(units=64, return_sequences=True, input_shape=(look_back, X_train.shape[2]))) model.add(Dropout(0.2)) model.add(LSTM(units=32, return_sequences=False)) model.add(Dropout(0.2)) model.add(Dense(units=16, activation='relu')) model.add(Dense(units=1)) model.compile(optimizer='adam', loss='mse', metrics=['mae'])激活函数和损失函数的选择有一点讲究。输出层我没有加激活函数，因为负荷预测是回归任务，需要输出任意实数，不能像分类一样用sigmoid限制到[0,1]。中间层用了relu保持非线性表达能力。损失函数用mse会让模型更关注大误差样本，如果用mae则对所有误差一视同仁，实践中mse收敛更平滑，mae对异常值更鲁棒。我默认用mse，如果发现预测曲线在某些尖峰处太过平滑，可以换成mae试试。
训练回调是关键。EarlyStopping监控验证集loss，patience设为15个epoch，防止跑太久过拟合。ReduceLROnPlateau在验证集loss连续不降时自动把学习率乘以0.5，避免后期loss震荡。训练时把epochs设大一点，比如100，反正有早停兜底。
early_stop = EarlyStopping(monitor='val_loss', patience=15, restore_best_weights=True) reduce_lr = ReduceLROnPlateau(monitor='val_loss', factor=0.5, patience=5, min_lr=1e-5) history = model.fit( X_train, y_train, validation_data=(X_val, y_val), epochs=100, batch_size=256, callbacks=[early_stop, reduce_lr], verbose=1 )batch_size我默认256，这个值取决于显存大小和样本量。显存不够就调小到128或64，样本量很小就调小，太大的batch_size会导致模型收敛到尖锐极小值，泛化性差，这也是一个值得注意的点。
3.5 预测与反归一化
模型预测出来的是归一化后的值，必须做逆变换还原成实际负荷值。这一步经常有人忘记。而且因为归一化是针对整个特征矩阵做的，反归一化时要注意取对应列。我的做法是：对prediction调用scaler.inverse_transform时需要把所有特征拼回去，或者单独对负荷列做一个scaler，这样反归一化更简单。
# 假设你单独对负荷列做了 scaler_y = MinMaxScaler() pred_scaled = model.predict(X_test) pred_inv = scaler_y.inverse_transform(pred_scaled.reshape(-1, 1)).flatten()单步预测的流程就是：输入前168个时刻的序列，输出下一个时刻的预测值。如果要做未来24小时的预测，有两种方式。一种是递归多步预测，把预测出的下一时刻值当作已知值拼到序列末尾，再预测下下时刻，这种方式简单但误差会累积，预测越远越不准。另一种是直接多步输出，把最后一层改成Dense(24)，每次输出24个预测值，训练时标签也要相应改成未来24小时序列。项目源码里两种都写了，文档里对比了它们的误差表现，实测直接多步在短期24小时内优势明显。
4. 训练中的常见问题与排查实录
4.1 预测曲线滞后一拍怎么办
这个问题的典型表现是：预测曲线形状和真实曲线几乎一样，但整体向右偏移了一个时间步，预测值好像是拿真实前一个值画出来的。原因我刚才提过，特征太单薄，模型没学到真正影响负荷的因素，只学到“下一时刻负荷和这一时刻差不多”。
排查思路依次是：确认特征里有没有时间特征和温度特征；确认节假日已经标记；最后可以考虑把预测目标从“预测下一时刻”改成“预测下一时刻相对当前时刻的变化量”，也就是差分目标，让模型学增量而不是绝对值，能明显缓解滞后。
我曾遇到过一个案例：某地区数据里春节假期特征没处理，模型在春节假期预测误差到了40%以上，而在普通工作日只有5%左右。加了节假日标记后，节假日误差降到15%以下。特征工程在负荷预测里的重要性，怎么强调都不过分。
4.2 训练集和验证集误差差很多
先看看是不是数据泄漏了。常见两个泄漏源：一是归一化时用全量数据fit，二是切分时用了shuffle。这两点我在前面强调了。如果确认没有泄漏，再看看是不是迭代次数不够，或者学习率太大导致loss震荡。
还有一种情况是数据分布漂移。比如训练集是春秋季数据，验证集是夏季高温数据，空调负荷激增，模型没见过这种模式，误差自然大。这个不是bug，是数据本身的分布问题。解决办法是让训练数据尽量覆盖全年各季节，或者做滚动训练，用最近一年的数据训练。
4.3 LSTM过拟合还是欠拟合？看loss曲线判断
判断方法很直接：训练loss持续下降但验证loss先降后升，这是过拟合；两者都高且下降缓慢，这是欠拟合。过拟合就加Dropout、调大正则化、减少模型容量、增加数据；欠拟合就增加LSTM层数或隐藏单元数、降低Dropout、增加训练轮数。
一个常见误区是以为LSTM层数越多越好。实际上负荷预测数据量通常不大，一层到两层LSTM已经足够，三层以上在小数据集上几乎必然过拟合。我做过对比实验：单层LSTM在相同数据上误差约5.8%，双层约5.2%，三层反而升到6.5%过拟合明显且训练时间翻倍。
4.4 测试集误差和验证集误差差别大
这说明模型对验证集“记住”了，但没学到一般规律，本质上还是过拟合，也可能是验证集和测试集分布差异较大。建议用K折交叉验证来稳定评估，但时序数据的K折不能随机切，要用时间序列交叉验证，也就是滚动地扩大训练集窗口，测试集始终在时间上靠后。我在文档中实现了这个逻辑，代码大概三十来行，跑完可以输出各折的平均误差和标准差，对判断模型稳定性很有帮助。
4.5 训练loss不下降的几个可能性
刚跑模型时loss卡在某个值不动，先检查归一化是否正确，尤其是负荷列有没有被归一化到合理范围；再检查学习率，默认0.001在Adam下一般没问题，但如果数据量小，可以降到0.0005试试；最后检查输入输出形状对不对，我踩过的一个坑是用squeeze或reshape时维度对不上，形状错误不会报错，因为numpy广播机制会自动调整，但结果完全错误。这种情况建议加断言assert来校验shape，或者打印几行数据看看数值合理性。
5. 从能跑到好用：扩展与落地实践
5.1 多步预测的代码实现
直接多步预测的标签构造方法是：对于输入序列X[i:i+168]，标签y[i]取未来24小时的负荷值，此时Dense输出维度改为24。这种方式的优点是预测速度快，一次推理出24个点；缺点是预测误差在24小时内是整体优化的，但不够灵活，因为预测长度是固定的。如果要预测长度可变，还是得用递归方式。
在文档里我建议把两种方式都跑一遍，至少在测试集上对比MAE和MAPE。我自己实测的结果是：递归多步在1-6小时的预测精度略高于直接多步，7-24小时直接多步误差更小。原因很简单，递归预测的误差会随步长累积，而直接多步模型在训练时是同时优化24个预测点的，不会让误差滚雪球。
5.2 模型上线部署的轻量化思路
训练好的模型导出为HDF5或SavedModel格式，线上推理可以用TensorFlow Serving或者用ONNX转成其他平台的格式。在电网调度这类实际场景中，推理频率通常是每15分钟或每小时一次，对延迟不敏感，主要是要稳定。
我实际部署时用过一个简单方案：用Flask包一个HTTP接口，输入当前最新的负荷、温度、湿度等特征，接口内部调用模型推理并返回未来24小时的预测曲线。这个方案代码量很小，一台普通服务器就能扛住整个省级电网负荷预测的调用量。文档里附了这个接口的完整代码，照着改就行。
数据更新方面，我个人的建议是周期性重新训练，比如每周用滚动窗口训练一次。这样模型能跟上季节变化和负荷结构的变化。你不需要把模型训练的频率提得太高，那样浪费计算资源，每周一次足够捕捉到稳定的变化趋势。
5.3 这个项目后续还能怎么扩展
负荷预测这个方向可以延伸出很多项目。一是把预测粒度从区域级细化到台区级或用户级，但要注意单户负荷的随机性远大于区域负荷，数据噪声大，可能要引入更多外部特征；二是加入电价信号做价格响应预测，这在电力市场交易场景下非常有用；三是把负荷预测的结果和储能调度策略结合起来，做一个“预测+决策”的一体化系统，那是完全另一个层次的价值。
如果对深度学习模型本身感兴趣，可以对比一下Transformer、Informer这些较新的模型在负荷预测上的表现，你会发现它们在大规模长序列预测上确实有优势，但小规模数据上LSTM依然能打。
6. 项目文件结构与使用说明
最后说一下源码包的目录结构，方便你拿到后快速上手。根目录下面分成data、src、notebooks、docs四个文件夹。data放原始数据和清洗后的数据；src下面按功能拆成了data_preprocess.py、build_features.py、train_model.py、evaluate_model.py、predict_api.py几个模块；notebooks里有一个完整的实验流程，从数据探索到模型训练、结果可视化，适合先跑通再读代码；docs里有详细的文档说明，包括环境搭建、每一行代码的注释、参数调整建议和常见报错解决方案。
环境依赖非常简单，Python 3.8以上，装tensorflow、pandas、numpy、scikit-learn、matplotlib这几个包就能跑。我测试用的是TensorFlow 2.x，代码不依赖任何GPU特性，CPU也能训练，只是慢一些。
跑通项目的第一步建议先用notebook，把数据可视化那一段看完，对数据的形状、缺失情况、日周期特性有个直观印象，再去看训练代码。这一点很重要，因为很多朋友一上来就训练，结果数据有脏值都没发现，模型效果差还以为是模型的问题。
我个人做这个项目最大的体会是：负荷预测里最值钱的部分不是模型结构，而是特征工程和对数据规律的深刻理解。同样的LSTM，有人预测误差8%，有人能做到4%，差别不在模型，而在谁更懂得把业务知识转化成了模型能读懂的特征。本篇只是我实践过程中的一个记录，希望能给正准备做这个方向的朋友节省一些摸索的时间。
本文还有配套的精品资源，点击获取
