简介这是一份面向深度学习开发者和电力负荷预测研究者的技术文档围绕能源需求预测实战场景系统讲解基于 PyTorch 的时间序列建模方法。文档从时间序列基础与传统 ARIMA 模型切入重点剖析 LSTM 的门控机制与 Transformer 的多头注意力、位置编码等核心组件并给出 LSTMTransformer 融合模型的完整构建、训练与调优路径。内容覆盖数据预处理、特征工程、归一化、训练集划分、损失函数与优化器选择、超参数调优等落地环节帮助读者建立从数据处理到模型评估的完整认知。资源为单个 PDF 文档大小 2.34MB共计 62 页支持目录章节跳转与阅读器大纲定位文字、图表显示完整适合对照学习或用作教学参考。已有 126 人学习适合具有一定 Python 基础、希望使用 PyTorch 开展电力负荷预测或拓展时序建模能力的读者。1. 能源需求预测实战为什么“会跑LSTM”不等于“会做电力负荷预测”很多工程师第一次做电力负荷预测会直接拿 LSTM 跑公开数据集。训练损失下降得很漂亮换到真实负荷曲线上却翻车早晚高峰的预测值总是偏低节假日完全跟不上实际曲线。问题不在于模型本身而在于电力负荷是日周期、周周期和季节趋势叠加的多尺度信号。靠循环网络把长距离依赖保留到输出时刻很吃力Transformer 的自注意力让任意两个时间步直接建立联系正好补上这一环。在能源需求预测场景里LSTMTransformer 已经成为提前几小时到几天负荷预测的主流方案。这篇笔记用 PyTorch 把两条路线完整走一遍从数据处理和滑窗构造到模型代码、训练验证和参数调整再到避坑排查。适合有 Python 和深度学习基础、想直接动手做电力负荷预测的工程师参照复现。2. 电力负荷数据预处理滑窗、归一化和防泄漏2.1 负荷数据的周期性与滑窗构造电力负荷数据是典型的多周期叠加信号。以最常见的 15 分钟采集粒度为例一天有 96 个采样点一周有 672 个。负荷曲线在日内呈现明显的双峰形态早高峰出现在上午工作时段晚高峰出现在傍晚工作日与周末的负荷形态完全不同再加上空调、取暖带来的季节趋势整个序列是由多个频率成分混叠在一起的。如果直接把原始数值喂给模型模型很难区分当前时刻在一周中的哪个位置预测自然不准。所以第一步不是搭模型而是把原始序列切成监督学习样本。基本参数有三个输入窗口长度、预测窗口长度和滑动步长。对于短期负荷预测未来 6 小时我一般用过去 96 步预测未来 24 步如果预测目标是未来一天输入窗口至少要拉到 7 天让模型有机会看到完整的周周期。import numpy as np def create_sequences(data, input_len96, pred_len24, step1): 把一维负荷序列切成监督学习样本。 参数 data长度 N 的一维负荷序列 input_len输入窗口步数96 表示 15 分钟粒度下的一天 pred_len预测步数24 表示未来 6 小时 step滑窗步长1 表示逐点滑动 返回 X形状 (样本数, input_len) y形状 (样本数, pred_len) X, y [], [] for i in range(0, len(data) - input_len - pred_len 1, step): X.append(data[i:i input_len]) y.append(data[i input_len:i input_len pred_len]) return np.array(X), np.array(y) # 用法示例 # X, y create_sequences(load_1d, input_len96, pred_len24, step1)代码的关键在切片索引。range的上界减掉input_len pred_len是为了让最后一个样本既取到完整输入窗口又留有完整预测窗口。逐点滑动会让相邻样本高度重叠信息冗余大当数据量超过十万时建议把 step 设为 4 或 8训练速度能提升几倍精度损失很小。如果样本总共只有几千条step 就保持 1并考虑缩短输入窗口否则有效样本数会严重不足。如果除了负荷还想加入温度、湿度或节假日标记data 改为形状(N, feat_dim)的二维数组切片后得到的 X 自然就是(样本数, input_len, feat_dim)这时 y 仍然只保留负荷对应的那几列就行。我习惯先跑通单变量模型确定数据链路没有问题时再逐步往特征里加外部变量。2.2 归一化MinMax 还是 Z-score负荷数据的量级通常在几十到几千 MW直接喂给神经网络梯度尺度会非常不均匀。用 MinMaxScaler 把负荷压缩到 [0,1] 区间是工程默认做法因为负荷数据没有重尾分布个别异常尖峰少MinMax 的尺度受异常点影响不大预测完反归一化就能得到实际负荷值调试时很直观。from sklearn.preprocessing import MinMaxScaler # 先切分原始序列再分别归一化 train_raw raw[:int(len(raw) * 0.7)] val_raw raw[int(len(raw) * 0.7):int(len(raw) * 0.85)] test_raw raw[int(len(raw) * 0.85):] scaler MinMaxScaler() train_scaled scaler.fit_transform(train_raw.reshape(-1, 1)) val_scaled scaler.transform(val_raw.reshape(-1, 1)) test_scaled scaler.transform(test_raw.reshape(-1, 1))注意fit_transform只能用在训练集上验证集和测试集只能用transform。如果先对整个数据集做fit_transform再切分测试集的极值会参与 min/max 统计等于把未来的尺度信息泄漏到了训练过程。这种问题在验证集上很难察觉损失曲线依然平滑但模型上线后会频繁出现预测结果落在历史区间之外的情况。反归一化时同样只能用最开始那个 scaler 对象用scaler.inverse_transform(pred.reshape(-1, 1))把预测值还原成负荷单位。如果反归一化时重新 new 了一个 MinMaxScaler因为新对象没有 fit 过inverse_transform 会直接报错或者返回完全错误的结果。另一个要注意的是如果预测目标是未来多个时刻反归一化要把二维数组整体传给 inverse_transform而不是逐个点还原。2.3 训练/验证/测试划分的顺序问题时间序列的划分不能随机 shuffle这是基本共识。但有一个更隐蔽的顺序坑如果先对整个序列做滑窗再按比例切分样本训练集末尾和验证集开头的样本会共用一段输入窗口隐式泄漏就此产生。正确的顺序是先在原始序列层面切区间再对每个区间分别构造样本。# 正确顺序先划分原始序列再分别做滑窗 train_raw raw[:int(len(raw) * 0.7)] val_raw raw[int(len(raw) * 0.7):int(len(raw) * 0.85)] test_raw raw[int(len(raw) * 0.85):] X_train, y_train create_sequences(train_raw, 96, 24, step1) X_val, y_val create_sequences(val_raw, 96, 24, step1) X_test, y_test create_sequences(test_raw, 96, 24, step1)这里要注意val_raw 的第一条样本需要前 96 个点作为输入而这 96 个点在 val_raw 区间外所以验证集的样本数会比理论值少约 input_len 个这是正常现象。如果验证样本确实太少可以让训练集的切分点左移 input_len 个点让训练和验证边界处有一段只用于构造验证输入的重叠但测试集与训练集的边界必须严格切割测试集的输入窗口绝不能包含训练区间的数据点。还有一种情况经常被忽略数据从数据库读出来后顺序不一定按时间排好甚至可能存在重复采样。在建滑窗之前先按时间戳排序并去重否则滑窗会把乱序的点当成一条连续曲线来建模。处理完这些之后再把样本封装成 PyTorch 的 Dataset 和 DataLoaderfrom torch.utils.data import DataLoader, TensorDataset import torch X_train_t torch.FloatTensor(X_train).unsqueeze(-1) # (N, 96, 1) y_train_t torch.FloatTensor(y_train) # (N, 24) train_ds TensorDataset(X_train_t, y_train_t) train_loader DataLoader(train_ds, batch_size256, shuffleTrue)这里的unsqueeze(-1)把二维样本扩展成(样本数, 输入长度, 特征数)对应 PyTorch 中 LSTM 和 Transformer 要求的输入格式。训练阶段建议打开 shuffle让每个 batch 的样本分布更均匀验证和测试阶段保持shuffleFalse固定数据顺序便于对比结果。3. PyTorch 搭 LSTM 基线从输入形状到训练循环3.1 为什么先用 LSTM 做基线引入 Transformer 之前先搭一个 LSTM 基线是必要的。一方面LSTM 通过输入门、遗忘门和输出门把历史信息做选择性保留在中等长度的负荷序列上已经能取得不错的效果另一方面它的参数量和计算量远小于 Transformer训练一轮只需要几十秒很适合用来验证数据处理链路、归一化方式和评估指标是否可靠。如果 LSTM 跑出来的结果明显低于预期问题多半出在数据侧而不是模型侧。PyTorch 中 LSTM 的输入是三维张量形状是(batch_size, seq_len, input_size)但它的构造函数默认batch_firstFalse也就是说如果不显式设置PyTorch 会按(seq_len, batch_size, input_size)来解析输入。这不会导致运行时报错但维度全部错位模型输出完全不可解释。这类问题极其隐蔽等发现时往往已经浪费了几天调参时间。3.2 LSTM 模型代码与维度理解import torch import torch.nn as nn class LSTMPredictor(nn.Module): LSTM 全连接回归头用于电力负荷多步预测。 def __init__(self, input_size1, hidden_size64, num_layers2, output_len24, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout if num_layers 1 else 0.0 ) self.regressor nn.Sequential( nn.Linear(hidden_size, 32), nn.ReLU(), nn.Dropout(dropout), nn.Linear(32, output_len) ) def forward(self, x): # x: (batch_size, seq_len, input_size) out, _ self.lstm(x) # out: (batch_size, seq_len, hidden_size) last out[:, -1, :] # 取最后一个时间步的隐藏输出 return self.regressor(last) model LSTMPredictor(input_size1, hidden_size64, num_layers2, output_len24) x torch.randn(32, 96, 1) pred model(x) print(pred.shape) # torch.Size([32, 24])这里最关键的是batch_firstTrue。设置后LSTM 返回的输出张量第一维才是 batch倒数第二维是序列长度。out[:, -1, :]取的是最后一个时间步的隐藏状态这个向量融合了整个输入窗口的信息再通过回归头映射为 24 个未来时刻的预测值。如果不设batch_firstTrue要么在 forward 里先x x.transpose(0, 1)要么在调用 LSTM 时隐式交换维度我更推荐直接设成 True避免后续代码里到处做转置降低出错概率。另一个常见疑问是h_n和out的区别h_n的维度是(num_layers, batch, hidden)包含每一层最后一个时间步的状态out[:, -1, :]只取最后一层最后一步等价于h_n[-1]。两者用途一样但用out更容易理解。3.3 训练循环、损失函数与学习率负荷预测是回归任务MSE 是最常用的损失函数。它会放大较大误差的梯度正好压制峰值时刻的预测偏差缺点是容易受异常点影响训练数据里有脏数据时损失曲线容易剧烈波动。对于电力负荷场景我通常在数据清洗干净后用 MSE如果怀疑数据质量一般就改用 HuberLossimport torch.optim as optim model LSTMPredictor() optimizer optim.Adam(model.parameters(), lr1e-3) criterion nn.MSELoss() # 数据质量一般时换 nn.HuberLoss(delta1.0) for epoch in range(50): model.train() total_loss 0.0 for xb, yb in train_loader: optimizer.zero_grad() pred model(xb) # (batch, 24) loss criterion(pred, yb) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0) optimizer.step() total_loss loss.item() * xb.size(0) model.eval() with torch.no_grad(): val_pred model(X_val_t) val_loss criterion(val_pred, y_val_t) print(fepoch {epoch:02d} | train {total_loss/len(train_ds):.4f} f| val {val_loss.item():.4f})训练循环里两个细节值得反复确认clip_grad_norm_对 LSTM 尤其重要序列较长时反向传播的梯度很容易超过 1不裁剪会造成 loss 突然变成 nanmodel.eval()必须在验证前调用否则 Dropout 层还在随机丢弃神经元验证结果永远是抖动的。学习率方面Adam 配lr1e-3是稳妥起点。如果 loss 一开始就不降先把 lr 降到 3e-4 试如果降得太慢则加大到 3e-3。电力负荷数据的尺度相对平稳1e-3 通常能正常收敛。训练到 30 到 50 轮时验证损失可能开始回升这时可以引入学习率调度scheduler optim.lr_scheduler.ReduceLROnPlateau( optimizer, modemin, factor0.5, patience5 ) # 每个 epoch 结束后 scheduler.step(val_loss)ReduceLROnPlateau会监控验证损失连续patience个 epoch 没有下降就把学习率乘以factor。这个调度器在时序预测里几乎不会翻车比固定步长衰减省心得多。还有一个容易忽略的点保存模型时不要只保存state_dict把 scaler 的 min/max、输入输出长度、特征顺序一起保存否则换环境推理时模型和数据对不上。4. Transformer 模型实现自注意力如何建模电力负荷4.1 为什么负荷预测也需要 TransformerLSTM 处理负荷序列时信息要经过一个时间步一个时间步的递归传递序列越长梯度路径也越长。虽然门控减轻了梯度消失但让模型记住“三天前同一个时段”的负荷形态代价依然很高。Transformer 的自注意力机制则完全不同它把每个时间步的输入和整个窗口内的所有其他时间步直接计算关联任意两个位置之间都只有一步距离。对电力负荷来说这种能力尤其有价值。凌晨低谷和前一天凌晨低谷、工作日晚高峰和上周工作日晚高峰这些远距离的相似模式可以被注意力层直接捕捉。Transformer 在训练时还能并行计算整个序列不像 LSTM 必须逐步展开训练速度上有明显优势。但 Transformer 也不是没有代价。它没有内置的顺序概念必须依赖位置编码告诉模型每个时刻的位置信息它的参数量更大在小样本场景下更容易过拟合。所以在负荷预测任务里我从不把 Transformer 当成 LSTM 的替代品而是把它们当成两条可以对照的路线先用 LSTM 建立基线再上 Transformer 看能否继续压低误差。4.2 Transformer 编码器代码PyTorch 的nn.TransformerEncoder把多头自注意力、前馈网络、层归一化和残差连接都封装好了直接搭模型不需要从零实现注意力公式。下面是一个适用于单变量负荷预测的最小实现class TransformerPredictor(nn.Module): Transformer 编码器 线性回归头用于电力负荷多步预测。 def __init__(self, d_model64, nhead4, num_layers2, dim_feedforward128, output_len24, dropout0.1, seq_len96): super().__init__() self.input_proj nn.Linear(1, d_model) # 用可学习参数作为位置编码 self.pos_encoder nn.Parameter(torch.randn(1, seq_len, d_model) * 0.02) encoder_layer nn.TransformerEncoderLayer( d_modeld_model, nheadnhead, dim_feedforwarddim_feedforward, dropoutdropout, activationgelu, batch_firstTrue ) self.transformer nn.TransformerEncoder(encoder_layer, num_layersnum_layers) self.decoder nn.Linear(d_model, output_len) def forward(self, x): # x: (batch_size, seq_len, 1) x self.input_proj(x) self.pos_encoder x self.transformer(x) last x[:, -1, :] return self.decoder(last)关键点在input_proj和pos_encoder。input_proj把单维负荷特征映射到d_model维pos_encoder是形状(1, seq_len, d_model)的可学习参数加到每个时间步的输入上。这里乘了 0.02 是为了让初始编码幅度远小于特征投影否则模型一开始就被位置信息主导训练很不稳定。如果输入序列长度和训练时不一致可学习位置编码会直接报错推理时需要先把输入切到seq_len。nn.TransformerEncoderLayer内部默认使用batch_firstFalse所以必须在构建时显式指定batch_firstTrue和 LSTM 那节的建议保持一致。dim_feedforward是前馈网络中间层维度一般取d_model * 2或d_model * 4不必单独设置太大。activationgelu是 Transformer 原论文后的常用配置对负荷预测这类回归任务比 ReLU 略稳。4.3 d_model、head 数和层数的直觉选择Transformer 的三个核心超参是d_model、nhead和num_layers。d_model决定每个时间步嵌入向量的宽度也是多头注意力里每个头拼接后的总维度nhead必须能整除d_model常用搭配是 d_model64 配 nhead4d_model128 配 nhead8。层数方面负荷预测通常不需要太深2 到 4 层足够电力负荷序列的规律性远没有自然语言复杂堆太多层只会增加过拟合风险。当数据量只有几万条时我建议从 d_model32、nhead4、num_layers2 起步先把整体流程跑通再逐步加大 d_model。d_model 翻倍意味着参数量约翻四倍训练时间和显存占用都会明显上升。用一个小实验对比不同配置的验证损失通常能发现 d_model 从 64 涨到 128 带来的收益已经很小这时就停在 64。另一个容易忽视的是 dropout 的位置。TransformerEncoderLayer 自带 dropout会作用在注意力权重和前馈网络输出上。训练时打开验证时model.eval()会自动关闭。预测阶段如果忘记调用model.eval()或者干脆用训练状态来做推理输出会有明显的随机波动这在负荷预测里最容易导致“明明和测试集一样的数据每次预测结果却不一样”。Transformer 对学习率比 LSTM 敏感得多。Adam 加 1e-3 在 LSTM 上稳定换到 Transformer 上经常出现训练前几步 loss 就冲到 nan。常见做法是先预热再衰减def adjust_lr(optimizer, epoch, warmup5, base_lr1e-3): if epoch warmup: lr base_lr * (epoch 1) / warmup else: lr base_lr * 0.5 ** ((epoch - warmup) // 10) for group in optimizer.param_groups: group[lr] lr # 在 epoch 循环开头调用 # adjust_lr(optimizer, epoch)预热期让位置编码和输入投影的梯度先稳定下来再逐步加大学习率到 1e-3之后按 epoch 衰减。这个简单的策略在大多数负荷数据上比直接恒定的 1e-3 好Transformer 训练不再动不动变成噪声。对 LSTM 基线我基本不用预热直接 Adam 加 1e-3 一路跑到底这两类模型的学习率敏感度差异本身就值得记录下来。5. LSTMTransformer 负荷预测避坑5 个常见问题与排查5.1 归一化泄漏验证集很漂亮上线就崩现象训练曲线和验证损失都很好看但把模型部署到新数据上预测值整体偏离甚至频繁超出训练数据的取值范围。原因最常见的原因是对整个数据集做了 scaler.fit或先做滑窗再切分样本导致测试和上线数据的尺度信息在训练时已经被模型间接看到。新数据一旦超出历史 min/max 范围归一化后的输入就会被压缩在 [0,1] 之外模型从未见过这个区间预测自然失真。解决先按时间顺序在原始序列层面切分训练、验证、测试集再分别对三段数据调用 scaler.fit_transform / transform。上线时把训练集的 scaler 持久化保存加载模型时同步恢复新数据进来直接用 transform。排查时可以在训练脚本里加一行断言如果np.max(test_scaled) 1.0 or np.min(test_scaled) 0.0打印告警说明测试集有超出训练范围的点。5.2 验证时忘了 model.eval()预测结果忽高忽低现象同一个测试样本连续跑两次预测结果不完全相同在测试集上评估的误差也明显大于训练集。原因模型里的 Dropout 层在训练模式下会随机屏蔽部分神经元验证或推理时如果不切换到 eval 模式dropout 仍然生效输出自然有随机性。对 Transformer 来说dropout 在注意力层和前馈层里都有影响甚至比 LSTM 更大。解决验证和推理时固定调用两件套model.eval()配上with torch.no_grad():。在脚本里封装一个 predict 函数内部统一处理模式切换不要在外部依赖调用顺序。这类问题最坑的地方是它的表现很像模型没有收敛会让你反复调结构、调学习率最后发现只是少了这一行。5.3 LSTM 隐状态残留跨 batch 的状态污染现象把数据切成多个 batch 后训练 loss 正常下降但验证集 loss 始终偏高如果把 batch_size 从 256 改成 32验证 loss 又明显降低。原因LSTM 的隐状态 h 和细胞状态 c 是跨时间步传递的。PyTorch 的 nn.LSTM 在没有显式传入初始状态时默认把 h0 和 c0 初始化为零。但如果在代码里手动维护了某个模块的状态并跨 batch 复用或者误把上一个 batch 的输出状态传给下一个 batch就会引入跨样本污染。另外batch_size 改变时最后一个不完整的 batch 需要重新初始化状态否则状态长度对不上。解决最简单可靠的做法是完全不手动维护隐状态让 nn.LSTM 每次调用都从零初始化。out, _ self.lstm(x)里的_直接丢弃不给 h0 传参。如果确实需要跨 batch 传递状态比如做在线流式预测要确保只在同一段连续序列内传递不同用户的负荷序列之间绝对不共享同一份状态。5.4 Transformer 训练不收敛学习率和位置编码的锅现象Transformer 训练前几步 loss 就变成 nan或者 loss 在小范围内剧烈震荡换 LSTM 用同样的数据就一切正常。原因一是学习率太大Transformer 对 lr 的敏感度比 LSTM 高一个数量级常见做法是从 2e-4 或 1e-4 起步二是位置编码的初始幅度过大导致 positional embedding 在训练初期完全压过数据特征三是数据没有归一化注意力权重计算出的数值尺度相差悬殊softmax 之后几乎变成 one-hot梯度无法有效传播。解决先把 lr 降到 2e-4 并保证数据已经归一化然后用预热学习率。位置编码的初始幅度控制在 0.01 到 0.02或者直接用正弦固定编码而不是可学习参数减少一个需要调的东西。如果还出现 nan检查输入里有没有 nan电力负荷数据常有缺失值被填充成 0 或 9999这种极端值在注意力计算中会把梯度放大到不可收拾建议在数据预处理时加入缺失值检测显式把缺失段标记出来或用插值填好。5.5 PyTorch/CUDA 环境问题装对了还是跑不起来现象在 Ubuntu 或 Windows 上按教程装完 PyTorch 后import torch 正常但训练时 GPU 不工作或者直接报错 CUDA driver version is insufficient / runtime API 版本不匹配。很多时候不是代码的问题而是环境问题。原因PyTorch 会捆绑自己的 CUDA 运行时NVIDIA 驱动有一套 API 版本PyTorch 编译时参考的 CUDA 版本跟驱动支持的版本不一致满足不了要求就会出现这类报错。解决建议在 conda 里重新配置环境先创建独立环境再根据nvidia-smi显示的驱动版本去 PyTorch 官网选择对应的安装命令。不建议在系统 Python 里直接 pip 装 pytorch依赖容易跟其他项目冲突。装好后跑一个小脚本验证import torch # 能打印 True 说明 PyTorch 能用 GPU print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0) if torch.cuda.is_available() else CPU mode)如果torch.cuda.is_available()返回 False先不用重装检查 conda 环境是否激活、驱动是否正常、PyTorch 版本是否是 CPU 版本在 Anaconda 里装错成 cpu 版很常见。核对这些之后再把训练脚本里的.to(cuda)或.to(device)统一抽到一个变量里管理避免在代码里写死设备。6. 进阶先用正弦数据验证模型再用滚动验证评估6.1 先用正弦数据把链路跑通每次搭完 Transformer我第一件事不是拿电力负荷跑而是生成一段正弦序列用过去 96 个点预测未来 24 个点。正弦数据是完美的测试集因为周期确定、无缺失、无季节扰动。如果模型在正弦数据上预测曲线都很奇怪说明代码里有 bug如果正弦数据预测正常再切换到真实负荷数据就能把代码问题和数据问题分离开。这个习惯帮我省了无数次排查时间。t np.arange(0, 2000) sine (np.sin(t * 2 * np.pi / 96) 1) / 2 # 周期 96 步的归一化正弦 X_sin, y_sin create_sequences(sine, 96, 24, step1) # 用同样的 Transformer 模型训练 20 个 epoch观察预测曲线是否贴合正弦6.2 多步预测的两种策略直接多步输出让模型一次输出未来 24 个点实现简单电力负荷的强周期信号用这个策略最稳递归预测每次只预测一步把预测值拼回输入窗口再预测下一步误差会随步数累积预测步数一长就不可靠。对电力负荷这种强周期信号预测步数不超过 48 时我推荐直接多步输出。只有当预测步数很短比如 6 步以内时才考虑递归策略。如果后续要上线把训练好的模型用torch.onnx.export导出配合 onnxruntime 做推理几乎不需要改动逻辑。6.3 滚动验证与峰值误差单次切分测试集容易受偶然性影响我最后总是用滚动验证检查模型稳定性把测试集按时间切成长度相等的多个区间从第一个区间开始用训练集加上已验证的区间继续微调模型再预测下一个区间。这样模拟了模型在实际部署中不断吸收新数据的过程。另外别只看整体 MSE单独统计早晚高峰时段的 MAE 往往更说明问题。Transformer 和 LSTM 的差距通常不明显体现在平均误差上而是藏在峰值时刻Transformer 对远距离相似模式的捕捉能让高峰时段的预测偏差明显更小。把每次实验的模型结构、输入窗口、学习率和峰值 MAE 记到一张表里数据一换对照历史记录就能判断是模型退化还是数据变化。如果 Transformer 在特定场景只比 LSTM 提升 5% 以内我通常保留 LSTM 基线把精力放在特征和数据处理上。电力负荷预测里数据和评估方式往往比模型更决定效果的上限。希望帮到你。本文还有配套的精品资源点击获取
