融合峰谷感知与多任务学习的综合能源多输出预测框架

前段时间在做综合能源系统的短期负荷与光伏功率预测，甲方给的数据除了历史负荷、温度、光照、电价，还有多个用能节点的用能曲线。刚开始我按老套路，目标变量单独建模，负荷一个模型、光伏一个模型、电价一个模型，每个模型都跑一遍同样的特征工程，最后发现不仅开发效率低，而且预测结果在峰时段误差特别大。后来我改成了基于自适应峰谷感知多头注意力多任务学习框架（APVP-MHA-MTL），把多变量多输出预测整合到一个模型里，峰时段的预测误差明显下降。这篇文章就把这套方案的完整思路、关键代码和踩坑记录分享出来，适合正在做电力综合能源预测、想用多任务学习提升多输出预测效果的同行。

1. 这个综合能源预测任务到底难在哪：需求拆解与问题定义

1.1 综合能源场景为什么需要多变量多输出

综合能源系统跟普通电力负荷预测不一样，它的数据面板是“多变量”的。除了负荷曲线，还要同时看光伏出力、风电出力、实时电价、温度、湿度、辐照度，甚至储能系统的充放电状态。这些变量不是孤立的：气温升高导致空调负荷上升，同时光伏辐照条件变好、出力增加；电价升高时会刺激用户调整用能策略，反过来又影响负荷曲线。如果只用单一变量建模，等于把系统里这些复杂的耦合关系全部扔掉。

更关键的是，实际调度和优化需求通常不是“预测一条曲线”，而是“预测一组曲线”。比如做日前调度，我需要未来24小时的负荷、光伏出力、电价曲线同时给到优化模块，才能计算储能充放电策略、冷热电联供机组出力分配。如果每个变量单独训练一个模型，就要维护三套甚至更多套模型，特征工程和超参调优都重复做，上线后的推理延迟也被成倍放大。

所以这个任务的本质是“多变量多输出时间序列预测”：输入过去一段时间的多个变量观测值，一次性输出未来多个目标变量的多个时间步预测值。这也是我在项目里最先明确下来的问题边界。

1.2 传统预测方案卡在哪几个环节

最早我试过两种常见做法，效果都不太理想。

第一种是最省事的单任务串联：把负荷、光伏、电价拆开，每个变量分别训练一个LSTM或Transformer。好处是模型简单，每个目标单独调优也容易；坏处也很明显，一是工程量变成三倍，二是每个模型只能看到自己的历史序列，变量之间的耦合关系被彻底忽略。光伏和负荷在晴天的反向关系、电价对负荷的反馈效应，全都没有体现。

第二种是伪多输出：把多个目标变量在输出端拼成一个向量，比如未来24步的负荷和未来24步的光伏拼成一个48维向量，直接让模型回归。乍一看是一个模型多输出，但问题是不同变量的数值尺度差异很大，负荷峰值可能是几千千瓦，电价只有几毛钱，训练时梯度被大尺度变量主导，小尺度变量的预测精度会急剧下降。更麻烦的是，拼成一个向量等于强制让不同任务共享同一个输出头，但不同任务需要的特征抽象层次并不完全一样。

这两类方案还有一个共同的硬伤：对峰谷时段的捕捉能力不足。负荷曲线的预测误差往往集中在中午和傍晚的尖峰段，普通注意力机制对所有时间步的依赖关系是一视同仁的，不会主动把计算资源放在峰值突变附近。体现到预测结果上，就是整体MAE看起来还行，但峰值时刻经常被削平，实际调度时会出现备用不足或切负荷风险。

1.3 我们的改进思路概览：APVP-MHA-MTL三件套

针对上面这些问题，我最后确定的做法是三个模块的融合：

第一个是自适应峰谷感知模块（APVP，Adaptive Peak-Valley Perception），它在注意力打分阶段加入峰谷调制因子，让模型在时间序列的局部极值区域分配更高注意力权重，解决峰值预测被平滑的问题。

第二个是标准的多头注意力编码器（MHA，Multi-Head Attention），用多个注意力头从不同表示子空间捕捉负荷、光伏、电价之间的复杂依赖。

第三个是多任务学习输出层（MTL，Multi-Task Learning），共享底层编码器，然后为每个目标变量单独设置一个预测头，既保留任务间的共享特征，又允许不同任务学习自己的映射关系。

这三个模块放在同一个模型里，输入是历史多变量窗口，输出是未来多个目标变量的多步预测。后面我会把每个模块的设计理由和实现细节逐一拆开。

2. 自适应峰谷感知（APVP）模块：让注意力学会“看清楚”负荷尖峰

2.1 峰谷感知的直觉理解：注意力到底缺什么

做时间序列预测的人应该都有这种感觉：大部分模型在平稳段表现都不差，真正拉开差距的是突变点。温度骤降那天的电热负荷、突然来了一片云的辐照下降、午间光伏午睡式的出力波动，这些“非平稳”时刻才是调度的难题。

普通Transformer里的自注意力计算的是“查询和键的相似度”，它关注的是某个位置与其他位置的匹配程度，但没有任何机制告诉模型“这个位置是不是一个局部峰值”。哪怕Q和K计算得再精确，模型也不知道应该在尖峰附近加强信息交互。我一度尝试过给模型增加绝对位置嵌入，但那是时间位置的信息，不是幅值大小与局部极值的信息。

所以最直接的想法是：算attention score的时候，显式加入一个“峰谷敏感度”调制项，让接近局部分位数峰值的时刻获得更高的注意力响应。

2.2 APVP的实现细节：峰值锚点、谷值锚点与权重调制

我实现的APVP模块分三步。

第一步是在每个训练样本内部，沿时间维度计算该样本的峰谷参考点。这里我用分位数而不是全局最大值最小值，为了抗噪。具体来说，取时间维的0.95分位数作为峰值锚点（P），取0.05分位数作为谷值锚点（V）。分位数的好处是某个极端离群点不会把锚点拉跑，比如负荷偶尔出现一个数据异常的毛刺，不会影响整段曲线的峰谷判定。

第二步是计算每个时间步的峰谷位置系数： _m_t = (x_t - V) / (P - V + eps)

其中eps是一个很小的常数，避免分母为零。这里的x_t是时间维上做归一化后的特征向量。这个系数的语义很直观：当x_t越接近峰值锚点，_m_t越接近1；越接近谷值锚点，_m_t越接近0。如果一个时间步既不是峰也不是谷，比如处于上升段的中间位置，系数就是某个中间值。

第三步是把系数变成注意力分数的调制因子。我在计算完QK点积后，把原始attention score乘上这个调制因子。这样峰值附近点对之间的注意力权重会被放大，模型在计算未来某个峰值预测时，能够更强烈地参考历史上类似峰值的模式。代码示意如下：

import torch import torch.nn as nn import math class APVPSelfAttention(nn.Module): def __init__(self, d_model, n_head, peak_percentile=0.95, valley_percentile=0.05): super().__init__() self.d_model = d_model self.n_head = n_head self.d_k = d_model // n_head self.W_q = nn.Linear(d_model, d_model) self.W_k = nn.Linear(d_model, d_model) self.W_v = nn.Linear(d_model, d_model) self.fc = nn.Linear(d_model, d_model) self.peak_percentile = peak_percentile self.valley_percentile = valley_percentile def forward(self, x, mask=None): # x: [batch, seq_len, d_model] B, T, C = x.shape Q = self.W_q(x).view(B, T, self.n_head, self.d_k).transpose(1, 2) K = self.W_k(x).view(B, T, self.n_head, self.d_k).transpose(1, 2) V = self.W_v(x).view(B, T, self.n_head, self.d_k).transpose(1, 2) scores = torch.matmul(Q, K.transpose(-2, -1)) / math.sqrt(self.d_k) # APVP调制：沿时间维计算峰谷系数 peak_value = torch.quantile(x, self.peak_percentile, dim=1, keepdim=True) # [B,1,C] valley_value = torch.quantile(x, self.valley_percentile, dim=1, keepdim=True) # [B,1,C] range_val = (peak_value - valley_value).clamp(min=1e-6) modulation = (x - valley_value) / range_val # [B,T,C] modulation = modulation.mean(dim=-1, keepdim=True) # [B,T,1] scores = scores * modulation.unsqueeze(1) # [B,n_head,T,T] if mask is not None: scores = scores.masked_fill(mask == 0, -1e9) attn = torch.softmax(scores, dim=-1) out = torch.matmul(attn, V) out = out.transpose(1, 2).contiguous().view(B, T, self.d_model) return self.fc(out)

实际用的时候，我还会在调制系数后面接一个可学习的缩放参数，让网络自己决定峰谷调制的力度。前面的代码是简化版，但核心思想一致。

2.3 为什么叫“自适应”：跟固定阈值法的本质区别

有人会问，你直接判断“负荷超过1000千瓦就当成峰值”不就行了吗？为什么搞这么复杂。这里的问题在于峰谷的概念是相对的，不是绝对的。

夏天午峰负荷可能是3000千瓦，冬季晚间峰负荷可能是3500千瓦，但春秋两季的大峰可能只有2000千瓦。固定阈值很难覆盖所有场景，而且不同目标变量的物理尺度也不一样，光伏峰值和电价峰值完全不是一个量级。

APVP模块用样本内分位数来动态确定峰谷锚点，相当于每个预测样本都有自己的“局部峰谷标尺”。这样不管是工作日还是周末，晴天还是阴天，序列的相对峰谷位置总能被重新标定到0到1的区间，注意力调制也始终保持稳定。这也是它比我最初用的固定阈值方案效果更好的主要原因。

3. 多头注意力与多任务学习的融合设计：一个模型同时输出多个预测

3.1 多头注意力（MHA）在时序预测里的定位与调整

多头注意力这一块我没有做太多“魔改”，重点是把标准Transformer里的MHA搬到多变量输入上。输入特征先做一步线性映射，把不同变量的原始值投影到统一的d_model维度。比如输入有6个变量，每个变量过去96个时间步，我先在特征维度拼接成一个[B, 96, 6]的张量，然后通过Linear变成[B, 96, 128]。

MHA的head数我取了8。为什么是8而不是16？因为综合能源数据量通常不像NLP那么大，头太多容易把注意力分布切得太碎，训练数据不够时反而过拟合。在96步的输入窗口下，8个头已经能让不同头分别关注“短时突跳”“日周期相似段”“天气变化带来的缓变趋势”等不同模式。

位置编码我用的是可学习的相对位置编码，而不是固定正弦编码。综合能源时间序列的周期性强，但周期长度会随季节和天气变化，固定正弦编码的泛化能力不如在数据里自己学出来的位置表示。

3.2 多任务学习（MTL）的共享层和任务特定分支怎么搭

模型主体是一个共享的MHA编码器，后面分出三个任务头。共享编码器负责提取所有目标变量共同依赖的时间特征，比如“最近三小时的温度上升趋势”“前一天的同一时间段光伏模式”等。每个任务头是一个两层MLP，输入共享编码器的输出特征，输出对应目标变量的horizon步预测值。

这种设计的直觉是：负荷和光伏都受温度、辐照影响，底层特征可以共享；但负荷的绝对量级变化规律和光伏的午间钟形曲线显然不同，所以顶部必须分叉。如果强行共享一个输出头，任务之间会互相干扰，就像让同一个学生用同一套答题技巧去应对物理和英语，效果一定不如分开。

实现上，我只是在模型里保存一个nn.ModuleList，每个目标变量对应一个任务头，推理时循环调用即可：

class MTLPredictor(nn.Module): def __init__(self, encoder, task_heads): super().__init__() self.encoder = encoder self.task_heads = nn.ModuleList(task_heads) def forward(self, x): feat = self.encoder(x) # [B, T, d_model] # 取最后一步特征作为序列摘要 feat_last = feat[:, -1, :] # [B, d_model] outputs = [head(feat_last) for head in self.task_heads] return outputs # 每个元素为 [B, horizon]

在实际代码里，我有时候会取最后一步特征，有时候会对特征做时间维平均池化，取决于输入窗口和预测任务。如果预测的是未来24个15分钟点（6小时），最后一步特征信息足够；如果预测更长，我会把编码器输出的整条序列压平后接Attention Pooling，效果更稳。

3.3 多任务损失函数如何平衡：动态权重方案

多任务学习里最常见的问题就是不同任务损失量级不一致。直接相加会让梯度被大数任务主导，比如负荷的RMSE小的也有几十千瓦，电价的RMSE可能只有几分钱，如果都套用同样的权重反向传播，模型会把几乎所有容量用来拟合负荷，电价预测退化到接近均值。

我一开始就是直接相加，结果电价预测曲线几乎平了。后来尝试两种解决办法。

第一种是标准化输出，把所有预测目标都缩放到0~1区间再算loss，这样量级问题能缓解不少，但不同任务的方差和难度差异依然存在。

第二种是用不确定性加权。简单说，为每个任务引入一个可学习的噪声参数σ_i，损失函数写成：

L = Σ_i (1/(2σ_i^2)) · L_i + log σ_i

σ_i越大代表该任务噪声越大，权重自动降低。这个权重是跟着训练一起学出来的，不需要手动调。

实测下来不确定性加权比手工调权重更省心，尤其是在任务数量少（3个左右）的时候，训练稳定性和收敛速度都有改善。

4. 多变量多输出预测的工程实现：从数据窗口到Python代码

4.1 数据预处理与窗口构造：关键参数和细节

这个项目的输入窗口我用了96个时间步，输出步长是24个时间步，时间分辨率是15分钟，所以对应的是“过去24小时预测未来6小时”。窗口太大，模型容易被早期信息干扰；窗口太小，日周期性特征抓不完整。96步是一个性能和精度的折中。

数据归一化是这里最容易踩坑的地方。对于多变量时间序列，我建议每个变量单独做标准化，不要把所有变量混在一起归一化。标准化的均值方差只从训练集统计，保存下来后给验证集和测试集用。否则一旦测试集的分布漂移，离线评估结果会假性偏高，上线后立刻打回原形。

滑动窗口切分时要注意相邻样本之间高度重叠。如果按常规随机切分训练集和验证集，会造成严重的数据泄漏：验证样本和训练样本可能是同一时刻附近截出来的，模型等于提前见过了答案。我按时间顺序切分，前80%作为训练集，中间10%作为验证集，最后10%作为测试集，并且在训练时用时间块而不是随机批采样。

4.2 模型主体代码骨架：APVP-MHA-MTL怎么落到PyTorch

这里给出一个可以跑的简化模型结构，核心是展示三个模块怎么组合。编码器用两层APVP注意力加前馈网络，任务头是两个MLP。

class FeedForward(nn.Module): def __init__(self, d_model, d_ff=256, dropout=0.1): super().__init__() self.net = nn.Sequential( nn.Linear(d_model, d_ff), nn.ReLU(), nn.Dropout(dropout), nn.Linear(d_ff, d_model) ) def forward(self, x): return self.net(x) class EncoderLayer(nn.Module): def __init__(self, d_model, n_head): super().__init__() self.attn = APVPSelfAttention(d_model, n_head) self.ff = FeedForward(d_model) self.norm1 = nn.LayerNorm(d_model) self.norm2 = nn.LayerNorm(d_model) def forward(self, x, mask=None): x = x + self.attn(self.norm1(x), mask) x = x + self.ff(self.norm2(x)) return x class APVPMHASeq2Seq(nn.Module): def __init__(self, n_input, d_model, n_head, n_layers, horizon, n_out_vars): super().__init__() self.input_proj = nn.Linear(n_input, d_model) self.encoder = nn.ModuleList( [EncoderLayer(d_model, n_head) for _ in range(n_layers)] ) # 多任务输出头 self.task_heads = nn.ModuleList([ nn.Sequential( nn.Linear(d_model, 128), nn.ReLU(), nn.Dropout(0.1), nn.Linear(128, horizon) ) for _ in range(n_out_vars) ] def forward(self, x): # x: [B, T, n_input] x = self.input_proj(x) for layer in self.encoder: x = layer(x) feat = x[:, -1, :] return [head(feat) for head in self.task_heads]

注意这个代码里我省略了位置编码，实际项目一定要加。可以用nn.Parameter初始化一个[1, T, d_model]的可学习位置向量，或者用相对位置编码。

4.3 训练循环和多任务评估指标：不只是算一个loss

训练的时候，我把每个任务头的输出分别和对应目标序列算损失，然后按不确定性加权求和。优化器用Adam，初始学习率1e-3，batch size 64，训练200个epoch。早停策略是盯验证集上的平均MAPE，连续20个epoch不下降就终止。

评估阶段我做了两件事。第一是每个目标变量单独算RMSE、MAE、MAPE，避免只看平均loss。第二是额外计算峰时段误差：把每天按照小时排序后，取最高20%时刻的预测误差单独统计，这是业务方最关心的指标。因为综合能源调度的备用容量主要就体现在这些峰值时段上。

5. 实验对比与结果分析：APVP模块带来的提升有多大

5.1 实验配置：数据、基准模型、训练参数

为了验证这套方案，我用手上脱敏后的某园区综合能源数据做了对比实验。数据包含负荷、光伏、电价三个输出目标，输入侧额外加了温度、辐照度、湿度三个辅助变量，一共6个输入变量，时间跨度3个月，15分钟分辨率。

基准模型选了四类：

• 单任务LSTM：负荷、光伏、电价各训练一个独立LSTM。
• 单任务Transformer：同样三个独立Transformer，但每个模型都用相同输入。
• 多输出Transformer：共享编码器，但只有一个输出头直接回归所有目标拼成的多维向量。
• APVP-MHA-MTL：就是本文的完整方案。

所有模型的输入输出结构一致，训练轮数和优化器也保持一致。这样对比的相对提升才有意义。

5.2 结果对比表格与关键结论

评估指标选RMSE，单位分别为kW、kW、分/度，测试集结果如下：

从结果看，完整方案在三个目标变量上都取得了最低误差。最明显的是峰时段负荷MAPE从8%以上降到5.2%，说明APVP模块确实在峰值区域发力了。

多输出Transformer的结果很有意思，负荷误差比单任务Transformer低，但电价误差反而更高。这正好印证了前面说的“简单拼接多输出向量”的问题：任务间梯度互相干扰。而MTL的任务分支设计避免了这种干扰。

5.3 峰谷时段样本的专项分析：改进点到底作用在哪

我还单独挑了一天中午光伏大发、下午迎峰的时间段，对比APVP-MHA-MTL和单任务Transformer的预测曲线。后者在负荷快速爬坡时明显滞后，预测值比实际值低了一截，而加了APVP的模型在爬坡段和峰值段都能保持较好的跟随。

进一步做消融实验：只去掉APVP模块，负荷峰时段MAPE从5.2%回到6.6%；只去掉MTL改成单一输出头，电价RMSE从28.4上升到33.9。这说明APVP和MTL分别在不同维度上做贡献：前者提升对非平稳峰谷区域的敏感度，后者解决多任务之间的共享与干扰问题。

6. 踩坑与调参经验：多任务时间序列预测里我最想告诉你的几件事

6.1 多任务损失平衡的坑：梯度主导问题

前面说了不确定性加权，但实际操作中还是有几个细节需要注意。σ参数的初始值不能太大也不能太小，我一般初始化为1.0左右。初始化太大会让所有任务权重都偏低，模型在最开始几个epoch学不进去；初始化太小会让权重在早期震荡剧烈，同样的loss在相邻两步之间跳来跳去。

另外，如果某个任务包含明显的NaN或异常样本点，这个任务的梯度会异常放大。我的解决方法是训练前对每个任务的目标变量单独做异常值截断，比如超过0.99分位数或低于0.01分位数的样本在训练循环里过滤掉。

6.2 峰谷感知模块的初始化与峰值锚点稳定性

APVP模块的峰值锚点来自当前batch的样本分位数，batch size很小时会抖动得很厉害。有一阵子我把batch size从64降到16给模型做资源优化，结果验证集误差不降反升。排查之后发现是APVP的调制因子在不同batch之间尺度不稳定，同一个峰值样本这次调制因子是0.8，下次就变成0.5了。

我的解决办法是给峰谷锚点做指数滑动平均：每个batch用当前batch的分位数和上一个batch的EMA值做加权平均，这样锚点是全局相对稳定的，又不至于完全脱离近期样本的滑动窗口。这个改动之后训练曲线平滑了很多。

6.3 数据泄露与未来信息污染：窗口拼接时必须注意的点

最后想说一个最隐蔽的坑。你可能会为了充分利用数据，在构造样本时让验证集的某个样本包含测试集时间段的观测值。比如测试集是第90天到第100天的数据，但验证集最后一个样本的输入窗口跨过了第90天，那验证集里就偷偷混进了测试信息。模型在早停时选出的参数其实是偷看过测试集的，到真正上线部署时才露馅。

我的经验是：构造窗口时一定要设定一个“保护间隔”，训练集和验证集之间、验证集和测试集之间至少留出和目标预测长度相同的空白时段（这里是24步）。这样能防止任何未来信息通过重叠窗口泄漏，评估结果才可信。

最后再分享一个小技巧：APVP的调制因子可以直接可视化，画出每个时间步的峰谷感知系数，对比预测值和真实曲线，往往能很直观地看到模型把注意力集中在哪些关键尖峰上。拿这个图去给业务方解释模型行为，比讲一堆注意力分数解释性强得多。如果你们也正被多变量多输出预测的峰值精度问题困扰，可以试试把峰谷感知和多任务分支结合起来，大概率会比我最初的单任务方案省心不少。