制造业用电量数据LSTM负荷预测实战：预处理与训练基线

简介面向制造行业电力负荷预测的学习者这套资料围绕LSTM时间序列建模展开适合已具备Python与深度学习基础、希望完整跑通“数据预处理—模型构建—训练监控—结果对比”流程的读者。包内共106个文件以59个csv数据与预测结果、24张jpg可视化图、7个py脚本为主另含pth模型权重、xlsx训练损失记录、xml与iml等项目配置及日志文件压缩包约4.57MB。目录保留了不同预测步长下MSE与SmoothL1损失的对照实验输出便于观察误差变化与模型表现。已有1527人学习下载。读者可据此理解LSTM门控机制在用电量季节性、周期性与趋势捕捉中的作用参考训练损失曲线判断过拟合与较优迭代轮次并借助预测结果和图表复盘实验设置形成可复用的电力消耗分析与预测思路。1. 从一堆没人动的抄表记录到一条可训练的用电量曲线上个月帮一个做能源管理的开发者看园区电费单三十多块表15 分钟一采一年下来四十多万行全躺在 Excel 里没人动过。这份用电量数据分享就是从这个场景里长出来的脱敏后的制造业表计负荷曲线、配套的字段说明加上一套能直接跑的 LSTM 训练脚本你不必再从“怎么造样本”开始折腾拿到就能练一条真实负荷预测的基线。它不适合当教科书看。数据覆盖产线、辅助设备、办公区三类负荷粒度 15 分钟跨完整一年工作日与周末、班次切换、季节性空调负荷都真实存在。适合两类人想做电力负荷预测、能耗异常检测的算法同学拿它跑通端到端流程以及在制造业里做能源管理的开发想知道自己厂里的表计数据到底能挖出什么。2. 数据与目录先看清这份用电量数据集长什么样拿到一份时序数据我一般不看 README先head几行、画一张原始曲线图。原因很简单用电量数据里的坑八成在预处理之前就已经埋好了——单位是 kWh 还是 kW、读数是区间值还是累计值、有没有换表导致的跳变这些问题光看字段名看不出来。2.1 表结构、采样粒度与脱敏口径数据集按“一行一个采集点”组织最常见的字段口径大致如下具体列名以你下载到的文件为准写脚本时先跑一遍df.columns对齐字段类型含义建模时怎么处理timestampdatetime采集时间15 分钟一个点设为索引asfreq对齐到固定频率meter_idstring表计编号已脱敏成 M001 这类单表建模先过滤多表建模当分组键energy_kwhfloat区间用电量若为累计值需先差分active_power_kwfloat区间平均有功功率与 energy_kwh 交叉校验约为其 4 倍shiftstring班次早/中/夜one-hot 或周期编码temperature_cfloat环境温度与空调负荷强相关建议保留is_holidayint节假日/停产标记0/1预测峰值时很关键粒度统一是 15 分钟意味着一天 96 个点、一年约 35040 个点。这个量级对 LSTM 来说是舒服的单表一年数据足够训一个中等规模的网络又不会大到单机跑不动。有两个口径必须自己确认。第一energy_kwh是区间量还是累计量。工业表计很多是累计读数只增不减直接喂进模型LSTM 会学到一条单调上升的直线预测意义为零必须先做diff()。第二active_power_kw和energy_kwh应该满足energy_kwh ≈ active_power_kw × 0.25如果差得离谱多半是某段时间的采集有重复上报或者时钟漂移这类脏数据在原始文件里非常常见。脱敏方面表计编号被替换成匿名 ID产线名称做了泛化但时间戳和数值本身保留原样——这点很关键因为负荷曲线的形态特征早高峰、午休下凹、夜班平台全都依赖真实时间对齐一旦时间被打乱数据就只剩统计意义了。2.2 目录组织与依赖环境工程结构我一般按“数据—源码—配置—产物”四层切避免脚本和数据混在一起power-lstm/ ├── data/ │ ├── raw/ # 原始 CSV只读任何脚本都不许改写 │ │ └── meter_2023.csv │ └── processed/ # 清洗后的 parquet读得快 ├── src/ │ ├── config.py # 路径、窗口长度、超参集中在这 │ ├── preprocess.py # 重采样、缺失填补、异常裁剪 │ ├── dataset.py # Dataset 与滑窗构造 │ ├── model.py # LSTM 网络定义 │ ├── train.py # 训练循环 早停 │ └── evaluate.py # RMSE / MAPE / 峰值命中率 ├── outputs/ │ ├── ckpt/ # 权重 │ └── figures/ # 预测对比图 └── requirements.txt依赖不需要多复杂pandas、numpy、torch、matplotlib、scikit-learn这五个就够跑通全流程。我习惯把版本钉死因为pandas在 2.x 之后对asfreq和interpolate的默认行为有过调整老脚本换环境后插值结果会变。python -m venv .venv source .venv/bin/activate pip install pandas2.1.* numpy1.26.* torch2.1.* \ scikit-learn1.3.* matplotlib3.8.*提示torch装 CPU 版就够单表 3.5 万个点的 LSTM 在笔记本上十几分钟能训完一轮完整实验没必要一开始就上 GPU。2.3 跑通 demo一条命令看到原始曲线在动任何预处理代码之前先让数据“可见”。这一步很多新手会跳过结果后面模型不收敛根本分不清是网络结构问题还是数据本身有问题。# src/preprocess.py 里先放一个最小可用的探查函数 import pandas as pd import matplotlib.pyplot as plt def peek(csv_path: str, meter_id: str, days: int 7): df pd.read_csv(csv_path, parse_dates[timestamp]) df df[df[meter_id] meter_id].sort_values(timestamp) # 只截前 N 天画全量图在 15 分钟粒度下会糊成一团 head df.head(days * 96) fig, ax plt.subplots(figsize(14, 4)) ax.plot(head[timestamp], head[energy_kwh], lw0.8) ax.set_title(f{meter_id} first {days} days) ax.set_ylabel(energy_kwh / 15min) fig.savefig(outputs/figures/raw_peek.png, dpi120, bbox_inchestight) return head.describe()days * 96是把天数换算成 15 分钟点数的固定系数改采样粒度时这个 96 要跟着改最好抽成POINTS_PER_DAY常量。describe()的返回值重点看min和max如果min是负数说明数据里混了累计读数的回退或者换表清零如果max比75%分位数高出十倍大概率是单点跳变。跑完这一步你会对数据有个基本判断曲线是否连续、有没有整段空白、峰值出现在几点。这三件事决定了后面预处理要写多重的逻辑。3. 预处理流水线把原始抄表记录变成 LSTM 能吃的张量LSTM 本身不挑数据但负荷预测的精度七成取决于预处理。同一份数据滑窗怎么切、缺失怎么补、归一化在哪一步做最后的 MAPE 能差出好几个百分点。这一章把流水线拆成四步每一步都给出可抄的代码。3.1 重采样与缺失值填补工业现场的数据缺失有两个来源通信中断造成的整段丢点和个别时刻的重复上报。前者要补后者要去重处理顺序不能反。import numpy as np import pandas as pd FREQ 15min POINTS_PER_DAY 96 def clean_meter(df: pd.DataFrame, meter_id: str) - pd.DataFrame: df df[df[meter_id] meter_id].copy() df[timestamp] pd.to_datetime(df[timestamp]) df df.sort_values(timestamp).set_index(timestamp) # 1) 去重同一时刻重复上报只留第一条 df df[~df.index.duplicated(keepfirst)] # 2) 对齐到固定频率缺失时刻自动补成 NaT/NaN df df.asfreq(FREQ) # 3) 累计读数差分得到区间用电量 if df[energy_kwh].is_monotonic_increasing: df[energy_kwh] df[energy_kwh].diff() df.loc[df[energy_kwh] 0, energy_kwh] np.nan # 换表/清零 # 4) 短缺口按时间线性插值长缺口保留 NaN df[energy_kwh] df[energy_kwh].interpolate( methodtime, limit8, limit_areainside ) return dflimit8是这套流程里最值得琢磨的参数8 个点等于 2 小时短于 2 小时的缺口用插值补不会引入太大偏差超过 2 小时的缺口说明这一天多半停产或者表计离线硬插值会造出一段“完美平坦”的假数据模型会把它当成真实负荷学进去。limit_areainside保证只补中间的空洞首尾的 NaN 不动。is_monotonic_increasing这个判断是后悔药级别的真实文件里经常出现“大部分表是区间量、个别表是累计量”的混合情况写死diff()会把区间量算成噪声。宁可多写一行判断。3.2 异常点剔除3σ 和 IQR 都不够用的地方负荷数据的异常检测比常规时序难因为“高”不一定异常——夏天下午的空调尖峰本来就应该高。直接对全序列算 3σ会把正常的峰全裁掉。我一般按小时分组算稳健统计量用 MAD 而不是标准差避免异常值自己把阈值拉高def clip_by_mad(df: pd.DataFrame, col: str energy_kwh, k: float 4.0): out df.copy() # 按小时分组早高峰和夜班的分布完全不同不能混在一起算 grouped out.groupby(out.index.hour)[col] med grouped.transform(median) mad grouped.transform(lambda s: (s - s.median()).abs().median()) # 1.4826 是把 MAD 折算成正态标准差的经验系数 sigma 1.4826 * mad upper med k * sigma lower (med - k * sigma).clip(lower0) # 电量不可能为负 out[col] out[col].clip(lowerlower, upperupper) return outk4.0比常规的 3 更松因为负荷曲线天然厚尾卡太紧会把真实的爬坡段削平。裁掉而不是删掉是为了保持时间轴的连续性——删行会让asfreq之后的索引对不上。裁剪的数量建议打印出来看一眼超过全量 1% 就说明阈值有问题得回头查采集。注意这一层只处理单点毛刺。像“整条产线停了一天又突然恢复”这种结构性异常裁剪是处理不了的得靠业务侧的停产标记is_holiday显式告诉模型。3.3 滑动窗口与周期特征LSTM 吃的是三维张量(batch, seq_len, features)所以要把一张二维表切成样本。这里有两个参数决定了一切lookback和horizon。lookback96是 24 小时正好覆盖一个完整的日周期模型能看到前一天同一时刻的负荷水平horizon4是未来 1 小时做短期调度够用做日计划就要拉到 96。窗口切分必须严格按时间顺序任何一次 shuffle 都是在把未来信息泄漏进训练集。import torch from torch.utils.data import Dataset def add_calendar_features(df: pd.DataFrame) - pd.DataFrame: idx df.index df[hour_sin] np.sin(2 * np.pi * idx.hour / 24) df[hour_cos] np.cos(2 * np.pi * idx.hour / 24) df[dow_sin] np.sin(2 * np.pi * idx.dayofweek / 7) df[dow_cos] np.cos(2 * np.pi * idx.dayofweek / 7) return df class WindowDataset(Dataset): def __init__(self, frame, feat_cols, target_col, lookback96, horizon4): x frame[feat_cols].to_numpy(dtypefloat32) y frame[target_col].to_numpy(dtypefloat32) n len(frame) - lookback - horizon 1 # 用 stride_tricks 做零拷贝视图比 for 循环 append 快两个数量级 self.x np.lib.stride_tricks.sliding_window_view( x, window_shapelookback, axis0)[:n] self.y np.stack([y[i lookback:i lookback horizon] for i in range(n)]) def __len__(self): return len(self.x) def __getitem__(self, i): return torch.from_numpy(self.x[i]), torch.from_numpy(self.y[i])周期特征用 sin/cos 编码而不是直接塞 0~23 的整数是因为整数编码会让模型认为 23 点和 0 点差得很远而实际上它们是相邻的。hour_sin/hour_cos是负荷预测里最便宜也最有效的两组特征几乎必加。滑窗用sliding_window_view而不是列表推导主要是内存考虑3.5 万个点、96 步窗口直接 append 会复制出几个 G 的数组用视图只占一份内存的零头。3.4 归一化fit 在训练集transform 全量这是最容易出错的一步。MinMax 的min/max必须只用训练集算出来再用同一组参数去变换验证集和测试集。用全量数据 fit等于提前告诉了模型测试期的峰值范围指标会好看到失真。from sklearn.preprocessing import MinMaxScaler def split_and_scale(frame, feat_cols, target_col, train_ratio0.7, val_ratio0.15): n len(frame) i_train, i_val int(n * train_ratio), int(n * (train_ratio val_ratio)) scaler_x MinMaxScaler().fit(frame[feat_cols].iloc[:i_train]) scaler_y MinMaxScaler().fit(frame[[target_col]].iloc[:i_train]) scaled frame.copy() scaled[feat_cols] scaler_x.transform(frame[feat_cols]) scaled[target_col] scaler_y.transform(frame[[target_col]]) return scaled, scaler_y, (i_train, i_val)按 7:1.5:1.5 切是因为制造业负荷有明显的季节性测试集至少要覆盖一个完整的季度否则冬季采暖负荷根本没进过测试集指标没有说服力。把scaler_y一起返回是因为预测完必须做逆变换否则 MSE 是在 0~1 区间上算的跟业务方没法交代。4. LSTM 模型与训练循环网络结构到底怎么搭数据准备好了模型部分反而不复杂。负荷预测用的 LSTM 结构很固定两层、隐藏维度 64 左右、最后一层接全连接输出多步。真正影响效果的是训练策略和评估口径。4.1 网络定义为什么只取最后一步import torch.nn as nn class PowerLSTM(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, horizon4, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, # 输入必须是 (B, T, F)忘了这行必翻车 dropoutdropout if num_layers 1 else 0.0, ) self.head nn.Sequential( nn.LayerNorm(hidden_size), nn.Linear(hidden_size, horizon), ) def forward(self, x): out, _ self.lstm(x) # (B, T, H) last out[:, -1, :] # 只取时间维最后一步 return self.head(last) # (B, horizon)batch_firstTrue是 LSTM 最常见的坑PyTorch 默认输入布局是(T, B, F)跟 pandas 处理出来的形状差一个维度忘了写这一行会静默算错loss 看着在降结果完全是乱的。只取out[:, -1, :]而不是对时间维做平均池化是因为负荷序列的最后一步对预测未来最相关池化会把几小时前的信息混进来稀释掉。LayerNorm放在全连接前是为了稳住 LSTM 输出在不同 batch 之间的尺度漂移尤其是多表计混训的时候。4.2 数据划分与 DataLoader训练集、验证集和测试集必须按时间先后切不能随机采样。时间序列的随机划分是另一个经典泄漏点——如果训练集里混进了测试期的样本模型实际上见过未来指标会虚高很多。from torch.utils.data import DataLoader def build_loaders(scaled, feat_cols, target_col, i_train, i_val, lookback96, horizon4, batch_size64): tr WindowDataset(scaled.iloc[:i_train], feat_cols, target_col, lookback, horizon) va WindowDataset(scaled.iloc[i_train - lookback:i_val], feat_cols, target_col, lookback, horizon) te WindowDataset(scaled.iloc[i_val - lookback:], feat_cols, target_col, lookback, horizon) # 验证/测试集切片的起点回退 lookback保证第一个窗口有完整历史 mk lambda ds, sh: DataLoader(ds, batch_sizebatch_size, shufflesh, drop_lastsh) return mk(tr, True), mk(va, False), mk(te, False)shuffleTrue只在训练集开验证和测试必须保持顺序这样才能画出连续的预测曲线做目视检查。drop_last只对训练集生效是为了避免最后一个不满的 batch 把 BatchNorm 类的统计量带偏虽然这里用的是 LayerNorm但在多表计方案里会换成 BatchNorm提前统一习惯。4.3 训练循环与早停LSTM 的梯度容易在长序列上爆掉梯度裁剪不是可选项。def train_epoch(model, loader, opt, loss_fn, clip1.0): model.train() total 0.0 for xb, yb in loader: opt.zero_grad() pred model(xb) loss loss_fn(pred, yb) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), clip) # 必须 opt.step() total loss.item() * xb.size(0) return total / len(loader.dataset) # 主循环里的早停逻辑 best, patience, bad float(inf), 8, 0 for epoch in range(120): tr_loss train_epoch(model, train_loader, opt, loss_fn) va_loss evaluate(model, val_loader, loss_fn) if va_loss best - 1e-5: best, bad va_loss, 0 torch.save(model.state_dict(), outputs/ckpt/best.pt) else: bad 1 if bad patience: breakclip1.0是按范数裁剪把整组梯度的 L2 范数限制在 1 以内。patience8配合ReduceLROnPlateau一起用效果更稳验证 loss 连续 4 轮不降就把学习率砍半再撑 8 轮不降才停。这套组合在负荷数据上比固定学习率省心得多因为不同表计的收敛速度差异很大。4.4 评估指标别只看 MSEMSE 在归一化空间里算业务方看不懂。要同时看三个数指标计算方式关注点RMSE逆变换后开方整体误差量级单位 kWhMAPE绝对百分比误差均值白天可用夜间分母接近 0 会炸峰值命中率预测峰与真实峰在 ±1 小时内重合负荷预测最该看的业务指标MAPE 在夜间低负荷时段会飙到几百这是方法论本身的问题不是模型坏了。稳妥做法是只在负荷大于日均 30% 的时段算 MAPE或者干脆换成 WAPE总绝对误差除以总电量后者对零值不敏感。峰值命中率反而是最值得盯的——电网侧和能源管理侧真正关心的是“明天下午两点会不会冲高”而不是全天平均误差。5. 排查清单用电量预测里最容易翻车的五件事这类项目跑不通九成不是模型结构的问题而是数据或者评估环节出了偏差。下面五条是我在类似数据集上真踩过的按“现象→原因→解决”整理。5.1 训练 loss 一路降验证 loss 从第一轮就往上走现象训练集 MSE 稳定下降验证集第一轮就到最低点再没低过预测曲线几乎是一条水平线。原因绝大多数是归一化泄漏或者划分泄漏。用全量数据 fit 了 MinMaxScaler或者用train_test_split(shuffleTrue)切了时序模型在训练中见过验证期的统计特征验证集自然失去参考价值。解决先打印 scaler 的data_min_/data_max_确认它们只来自前 70% 的数据再把数据集切片的前后时间戳打出来肉眼确认没有重叠。这两个检查我一般写进训练脚本开头的断言里。5.2 模型输出恒等于历史均值现象预测曲线非常平滑几乎贴着均值走峰值完全预测不出来但 loss 看起来还不算太差。原因energy_kwh是累计读数没有差分或者特征全是慢变量温度、日历模型找不到任何能解释峰谷的信号只能学成均值回归。解决检查df[energy_kwh].is_monotonic_increasing是 True 就必须差分。同时确认lookback覆盖了完整的日周期96 是最低要求短于这个值模型看不到“昨天同一时刻”的水平。5.3 形状报错或者报错都没报但结果是乱的现象Expected input batch_size (64) to match target batch_size (96)或者训练不报错但预测值完全对不上。原因nn.LSTM漏了batch_firstTrue。默认布局是(T, B, F)PyTorch 会把时间步当成 batch 维度静默算下去形状“碰巧”能过。解决网络定义里显式写batch_firstTrue并且在 forward 开头加一句assert x.dim() 3。更好的习惯是在 Dataset 的__getitem__里就断言形状是(lookback, n_features)。5.4 节假日和检修日预测全部爆表现象工作日的误差很正常一到长假或者计划检修日预测值远高于实际误差翻好几倍。原因这类日期在训练集里样本极少模型没见过“连续三天负荷掉到 20%”的模式只能按常规工作日外推。解决把is_holiday和检修计划作为显式特征喂进去而不是指望模型从数据里自己发现。样本太少的话可以对这类日期做单独的损失加权或者干脆在评估里把这几天剔除先看清常规日的模型质量。5.5 夜间 MAPE 动辄上百但曲线看着挺准现象白天 MAPE 只有 4%夜间飙到 200%可把两条曲线叠在一起看几乎重合。原因夜间负荷基数小分母接近零几个 kWh 的绝对误差就能算出巨大的百分比。这是 MAPE 的固有缺陷不是模型问题。解决换成 WAPE或者只在负荷高于阈值比如日均的 30%的时段统计 MAPE。同时补一个 RMSE 做交叉验证——如果 RMSE 在正常范围而 MAPE 离谱基本可以确认是分母问题。6. 二次开发从单表计预测到多厂区联合建模跑通单表计的 LSTM 之后真正有价值的是往外扩。我一般按三个方向改优先级从低到高。改造方向改动量收益主要风险加日历/温度/产量特征改feat_cols和add_calendar_features峰值预测明显改善特征缺失时段要单独处理多表计混训加 meter embedding改 Dataset 与模型输入层小表计样本不足的问题解决不同表计量级差异大需分表归一化换模型TFT / PatchTST / N-BEATS替换model.py长周期预测更稳训练成本上升调参周期变长第一个方向最省事feat_cols里加进去就行但有个细节温度数据往往比电表数据晚到或者有缺我习惯在预处理阶段就把温度和电量对齐到同一个asfreq索引上缺的部分统一插值别等到 Dataset 里再 merge。第二个方向是真正的分水岭。多表计时不能共用一个 MinMaxScaler量级差十倍的表计混在一起小的会被完全淹没。做法是按meter_id分组归一化再把meter_id转成 embedding 拼到 LSTM 输出上class MultiMeterLSTM(nn.Module): def __init__(self, n_meters, input_size, hidden_size64, horizon4, emb_dim8): super().__init__() self.emb nn.Embedding(n_meters, emb_dim) # 表计身份向量 self.lstm nn.LSTM(input_size, hidden_size, num_layers2, batch_firstTrue, dropout0.2) self.head nn.Linear(hidden_size emb_dim, horizon) def forward(self, x, meter_idx): out, _ self.lstm(x) h torch.cat([out[:, -1, :], self.emb(meter_idx)], dim-1) return self.head(h)emb_dim8是个经验值表计数量在几十块以内够用上千块表就要拉到 16 甚至 32。这个改法的好处是新接入一块表时只要它有几百个点embedding 就能借助其它表学到的共性快速收敛。第三个方向我不太建议一上来就做。LSTM 在 15 分钟粒度、4 步预测的设定下其实不弱先把这个基线的 WAPE 压到 5% 以内再考虑换模型不然你无法判断指标提升是来自模型还是来自更好的特征。最后一个实操技巧把训练脚本改成一个按天跑的批处理任务每天凌晨用过去 90 天的滚动窗口重训一次预测当天的 96 个点写回数据库。滚动窗口比全量重训快得多也能自动跟上季节切换。我做这类项目时有个固定习惯——每次改动预处理逻辑都先把新老两版的训练集分布画出来对比一遍确认差异是预期的再往下训。这个动作花五分钟能省掉一整天“为什么指标突然掉了”的排查。希望帮到你。本文还有配套的精品资源点击获取