简介：基于深度学习的多任务空气质量预测模型设计与实现项目包，完整覆盖数据预处理、模型搭建、训练验证与预测推断的深度学习应用全流程，面向环境数据分析、智慧城市和深度学习交叉领域的开发者与学习者。压缩包共46个文件，以36个csv数据文件、7个py脚本和3个md说明文档为主，整体仅5.08MB；csv包含历史空气质量监测数据与特征样本，py脚本涵盖数据清洗、模型定义、训练、评估及预测等关键环节，md文档负责解释项目结构、依赖环境和运行流程。已有142人参与学习下载。项目采用多任务学习框架，通过共享底层特征与多个预测分支，可同时输出PM2.5、PM10、二氧化硫、氮氧化物等污染物浓度；同时涉及缺失值处理、特征选择、CNN或RNN等时序网络结构、早停法以及MSE/MAE等评估策略，可直接作为课题研究和毕业设计落地的完整参考。
1. 多任务预测在空气质量场景的价值：为什么单个模型经常不够
空气质量预测这件事，单拎出来看是个标准的时间序列回归问题，输入过去几天的气象和污染物浓度，输出未来的 PM2.5 或 PM10。但实际落地时你会发现，环保部门要的不是一个数，而是一组数——同一天既要报 PM2.5、PM10、O₃，还要报 AQI 等级和首要污染物。如果为每个目标单独训练一个模型，五个模型就是五套训练流程、五个推理接口、五份维护成本，而且每个模型都只看到了污染物之间的耦合关系的一小部分。这里的关键洞察是：PM2.5 和 PM10 的浓度在物理形成机制上高度相关，O₃ 的二次生成又和温度辐射强相关，把这些预测目标放进同一个模型里做多任务学习，共享底层的特征提取器，往往比单独训练效果更好，尤其在小样本站点上提升明显。
这个标题里的.zip意味着它是一个完整的可交付项目，不是一篇论文或一套公式。也就是说，读者拿到的是一份包含数据预处理、模型定义、训练脚本、评估脚本的工程代码。本文就按这个预期来写，带着你把多任务空气质量预测模型的每个环节拆开，从数据任务设计到模型结构、loss 平衡、训练调参、避坑，一路说到评估落地。
2. 从数据到任务定义：污染物浓度预测怎样被拆成多任务学习问题
2.1 多任务方案到底该拆哪几个任务：物理相关性是分组的唯一依据
多任务学习的第一件事不是选模型，而是确定任务边界。以空气质量预测为例，常见的选择有三种：第一种是把 PM2.5、PM10、SO₂、NO₂、CO、O₃ 六项全拆成六个回归任务；第二种是预测 AQI 数值加首要污染物分类，形成回归加分类的组合；第三种是预测多个站点的同一污染物，形成空间多任务。从工程经验看，第一种最常用，但六个任务之间不是等权重的——O₃ 和 PM2.5 的生成机制完全不同，O₃ 是光化学反应产物，高温强辐射下浓度升高，而 PM2.5 主要是一次排放和二次气溶胶生成，低温高湿条件下更容易累积。如果强行让它们共享太多底层特征，反而可能互相干扰。
我一般会把任务分成两组或三组：颗粒物组（PM2.5、PM10）共享一套底层特征，气态污染物组（SO₂、NO₂、CO）共享另一套，O₃ 单独处理或者只和气象特征共享浅层。这样在模型结构上做分支，既保留了多任务学习的参数共享优势，又避免了任务间冲突。还有一类做法是把预测时效也当成任务维度，比如同时预测未来 1 小时、6 小时、24 小时的浓度值，三个时效的任务共享同一个编码器，不同时效使用不同的预测头。这样做的合理性在于：短期预测更多依赖污染物浓度的自相关性，长期预测更多依赖气象条件的演变趋势，底层特征提取可以共享，但回归头的复杂度必须不同。
# 任务分组配置示例：以配置文件的方式管理多任务定义 task_config = { "pm_group": { "targets": ["PM2.5", "PM10"], "task_type": "regression", "weight": 1.0 }, "gas_group": { "targets": ["SO2", "NO2", "CO"], "task_type": "regression", "weight": 0.8 }, "o3_task": { "targets": ["O3"], "task_type": "regression", "weight": 0.6 } }这段配置的逻辑是：把六个污染物按物理生成机制分成三组，每组的 loss 权重不同。颗粒物是核心指标，权重最高；气态污染物次之；O₃ 单独一组且权重最低。分组的好处是，后续如果你想给某个任务单独加 loss 项，不需要改模型代码，只改配置就行。权重不是一拍脑袋定的，先全部设为 1.0 跑一轮，观察各自 validation loss 的量级，再按weight_i = 1 / loss_i的逆比方式粗调，后续再微调。
2.2 时间窗口和数据预处理：预测未来 24 小时需要多长的历史序列
确定了任务，下一步是构造样本。空气质量预测最常用的做法是滑窗采样：用过去 72 小时的逐小时数据预测未来 24 小时的浓度值。72 小时窗口的意义在于覆盖了三天的完整气象周期，同时让模型能看到污染物浓度的日变化规律。如果窗口太短，比如 24 小时，模型只能学到日内变化，学不到跨日累积效应；如果太长，比如 168 小时，数据量会急剧膨胀，而且模型很难捕捉长期依赖。
数据预处理是这里最容易翻车的地方。空气质量数据天生带缺失——传感器故障、通信中断、校准维护都会产生空值。常见的处理方式有三种：线性插值、前向填充、删除整段。前向填充最简单，但在长时间缺失时会产生平台期，导致模型学到假的平稳段。线性插值在缺失不超过 6 小时时效果最好。还有一种做法是把缺失标记当成一个额外特征输入模型，让模型自己学到缺失时段如何处理，这个技巧在真实数据集上往往比插值更稳，因为模型能感知到数据质量的差异。
import pandas as pd import numpy as np def preprocess_airquality(df, window_size=72, horizon=24): """ 空气质量数据预处理：缺失处理 + 滑窗采样 df: 原始数据，索引为时间，列为站点/污染物/气象特征 """ # 1. 缺失处理：6小时以内线性插值，超过6小时标记为缺失特征 df_interp = df.interpolate(method='linear', limit=6) missing_mask = df.isna().astype(int) # 2. 构造缺失标记特征 for col in missing_mask.columns: df_interp[f'missing_{col}'] = missing_mask[col].values # 3. 滑窗采样：生成 (样本数, 窗口长度, 特征数) 的输入 X, y = [], [] features = df_interp.values for i in range(window_size, len(features) - horizon + 1): X.append(features[i - window_size:i, :]) y.append(features[i:i + horizon, :6]) # 只预测6个污染物 return np.array(X), np.array(y)参数说明：limit=6表示只对连续缺失 6 小时以内的段做线性插值，超过这个阈值就保留 NaN 并由缺失标记特征来承载信息。滑窗采样从第 72 行开始，每次取 72 行作为输入，取接下来的 24 行中的前 6 列作为预测目标。注意这里预测的是序列值而不是单点值——输出形状是(batch, 24, 6)，24 个时间步、6 个污染物通道。如果你的场景只关心未来 24 小时的平均浓度，可以在最后对时间维做 average pooling，但保留序列输出可以让模型先学会逐小时变化，再聚合得到日均值，效果通常更好。
2.3 站点维度要不要进模型：一个容易被忽略的坑
多站点数据是空气质量预测项目的常见形态。很多时候你手里的数据不是单个站点，而是全市几十个国控站点。这时有个决策直接影响模型设计：站点是作为类别特征做 embedding，还是每个站点单独建模？我的经验是：站点数量少（比如 10 个以内）时，用站点 embedding 放进模型，让模型学到站点间的空间相关性；站点数量多且分布广时，先按区域聚类，再在每类内部做多任务。
# 站点embedding的PyTorch实现片段 class StationEmbedding(nn.Module): def __init__(self, num_stations, embed_dim=8): super().__init__() self.embedding = nn.Embedding(num_stations, embed_dim) def forward(self, station_ids): # station_ids: (batch,) return self.embedding(station_ids) # (batch, embed_dim)这个设计的核心理由是：站点之间的污染物浓度存在空间传播关系，比如上风向站点的 PM2.5 会在一段时间后影响下风向站点。如果完全忽略站点信息，模型把不同站点当成同一个分布，很容易在区域差异大的数据上学偏。给每个站点一个可学习的向量，相当于让模型自行发现站点间的相似性和差异，比人为指定距离权重更灵活。
3. 模型结构设计：共享编码器加任务分支的三种常见架构
3.1 硬共享与软共享：选错结构会让多任务变成负迁移
多任务模型最经典的架构是硬参数共享：底层几层全连接或卷积网络是所有任务共用的，靠近输出的位置分出多个分支，每个分支对应一个任务。这种结构参数少、训练简单，但有个显著问题——如果两个任务的相关性很低，硬共享会把任务特定的噪声也强加到共享层里，造成负迁移。空气质量场景里的典型例子是 PM2.5 和 O₃：前者在冬季高、夏季低，后者正好相反。如果让它们完全共享底层特征，模型会在冬季把 O₃ 的预测往上推，因为共享层学到了 PM2.5 的季节性趋势。
解决思路是软共享，也叫交叉共享：每个任务有自己的专属底层网络，但通过正则项约束不同任务网络的参数保持接近。常见的实现是使用 L2 距离惩罚项，比如loss_total = loss_1 + loss_2 + λ * ||W_1 - W_2||²。这里的 λ 控制共享强度，一般从 0.01 开始调。软共享的代价是参数量上升、训练变慢，但换来了任务间的独立性。我的经验是：如果只有两个任务且相关性明确，硬共享就够了；任务超过三个且相关性参差不齐，直接上软共享更稳。
3.2 序列模型怎么搭：Conv1D 降维还是 LSTM 直接上
空气质量数据是典型的多变量时间序列，模型的主干部分通常用 LSTM 或 Temporal Convolutional Network（TCN）来做序列特征提取。LSTM 的优势是能显式建模长期依赖，但训练慢、容易过拟合。TCN 用因果卷积加膨胀因子扩大感受野，训练快、梯度稳定，近年来在时间序列任务上表现更好。我个人的偏好是：数据量小于 5 万样本时用 LSTM 加 dropout，数据量更大时用 TCN。
另一个关键的结构选择是编码器-解码器形式。如果你预测的是未来 24 小时的浓度序列，用 seq2seq 结构——编码器读入过去 72 小时，解码器逐步生成未来 24 小时的预测。这里有个容易被忽略的细节：解码器的输入除了上一时刻的预测值，还应拼上预测时段的气象预报值（温度、风速、风向、湿度），因为污染物浓度对未来气象条件非常敏感。如果只用预测值自回归，误差会逐时间步累积，出现预测曲线越来越平的问题。
import torch import torch.nn as nn class MultitaskAirQualityModel(nn.Module): def __init__(self, input_dim, hidden_dim=64, num_layers=2, num_tasks=3, horizon=24): super().__init__() # 共享编码器：两层LSTM self.encoder = nn.LSTM(input_dim, hidden_dim, num_layers, batch_first=True, dropout=0.2) # 三个任务分支，每个分支独立回归头 self.task_heads = nn.ModuleList([ nn.Sequential( nn.Linear(hidden_dim, 32), nn.ReLU(), nn.Linear(32, horizon) # 输出未来24小时 ) for _ in range(num_tasks) ]) def forward(self, x): # x: (batch, seq_len=72, input_dim) _, (h_n, _) = self.encoder(x) # 取最后一层最后一个时间步的隐状态作为共享特征 shared_feat = h_n[-1] # (batch, hidden_dim) outputs = [head(shared_feat) for head in self.task_heads] return torch.stack(outputs, dim=1) # (batch, num_tasks, horizon)这个结构里，num_tasks=3对应前面配置里的三个分组，每个分支输出 24 个时间步的预测值。LSTM 的隐状态就是共享特征，三个任务分支从这个共享特征出发各自回归。注意h_n[-1]取了最后一层的隐状态，而不是把每层都拿出来——因为不同层的特征抽象层次不同，最顶层最接近任务语义，直接用它做共享特征最合理。这里没有用 attention，因为空气质量预测的输入输出长度固定，attention 带来的收益不明显，反而增加训练开销。
3.3 残差连接和多任务分支怎么结合：给每个任务一个辅助输入
进阶的做法是给每个任务分支额外的辅助输入。比如 O₃ 的光化学生成高度依赖温度和太阳辐射，所以在 O₃ 分支的输入端，除了共享特征，再拼上当天温度、辐射的预报值。这样做的好处是：任务分支可以自己学到气象条件的非线性影响，而不需要让共享层来承担这个任务——共享层一旦承担了，就会影响其他任务。
# O3任务分支带气象辅助输入的实现 class O3Head(nn.Module): def __init__(self, shared_dim, aux_dim, horizon): super().__init__() self.fc = nn.Sequential( nn.Linear(shared_dim + aux_dim, 32), nn.ReLU(), nn.Linear(32, horizon) ) def forward(self, shared_feat, aux_meteo): # shared_feat: (batch, shared_dim) # aux_meteo: (batch, aux_dim) # 温度、辐射、风速等 combined = torch.cat([shared_feat, aux_meteo], dim=-1) return self.fc(combined)这个设计的另一个好处是给模型提供了一条"捷径"——任务分支可以直接使用关键气象特征，不需要绕道共享编码器，这让梯度更顺畅地流向分支自身的参数，减少了对共享层的压力。实际训练中你会发现，加了这个辅助输入后，O₃ 的验证损失下降速度明显加快，而且共享层的输出在可视化时更加"干净"——不再包含明显的温度波动信息。
4. 训练策略：多任务 Loss 权重怎么调、学习率怎么设
4.1 多任务 Loss 权重：从固定值到自适应，为什么要动态调整
多任务训练最棘手的问题就是多个 loss 之间的比例。六个污染物任务的 loss 量级天然不同——PM2.5 的浓度数值可能是 0~500，而 SO₂ 只有 0~50，在 MSE loss 下，PM2.5 任务的梯度会主导整个模型，SO₂ 任务根本学不到东西。常见的做法是标准化每个任务的目标值，把浓度转化到 0~1 之间，然后再设固定权重。但标准化的尺度只是解决了量级问题，任务间学习难度的差异依然存在——有的任务就是更难学，loss 降不下去。
更实用的做法是用不确定性加权（Kendall 等提出的方式），把每个任务的噪声方差作为可学习参数，模型自动学习每个任务的权重。但这个方法的实现稍复杂，而且对噪声方差的初始化敏感。我一般用的是更朴素的方案：前 10 个 epoch 用固定权重让模型稳定下来，之后每 5 个 epoch 计算一次各任务在验证集上的 loss，按w_i = 1 / (loss_i_avg)更新权重，再做一次归一化。这个方法没有花哨的理论支撑，但在多个项目里都稳定有效。
def update_task_weights(val_losses, previous_weights, alpha=0.5): """ 根据验证损失动态调整任务权重 val_losses: 各任务的验证loss列表 previous_weights: 上一轮的权重 alpha: 平滑系数，防止权重突变 """ # 逆loss加权：loss大的任务给更大的权重 inv_losses = np.array([1.0 / max(loss, 1e-6) for loss in val_losses]) raw_weights = inv_losses / np.sum(inv_losses) # 指数滑动平均，保持权重稳定 smoothed_weights = alpha * raw_weights + (1 - alpha) * np.array(previous_weights) return smoothed_weights / np.sum(smoothed_weights)这段代码的逻辑很直白：验证损失越大的任务，说明模型对它拟合得越差，就越需要提高权重来让梯度更多地关注它。alpha=0.5是平滑系数，数值越大，权重更新越快。如果权重波动太剧烈导致训练不稳定，把 alpha 降到 0.3 或 0.2。注意一个细节：1.0 / loss之前要对 loss 做下限保护，否则某个任务一旦收敛得很好，loss 接近 0，权重会爆炸到接近 1，其他任务全部被忽略。
4.2 学习率与优化器：AdamW 加 warmup 是最不容易翻车组合
多任务模型的训练比单任务更容易出现 loss 震荡，因为多个任务的梯度方向可能不一致，导致优化器在参数空间里来回摆动。我的默认配置是 AdamW（权重衰减解耦），learning rate 设为 0.001，warmup 10 个 epoch 线性升到目标值，之后用 cosine annealing 衰减到最小值的 1/10。为什么不用 Adam？AdamW 把权重衰减和梯度更新解耦，能有效抑制过拟合。Warmup 的作用是让模型在前几个 epoch 里用较小的学习率先找到一个大致的"盆地"，避免一开始就走偏。
optimizer = torch.optim.AdamW(model.parameters(), lr=0.001, weight_decay=0.01) # warmup 10 epochs + cosine annealing 到 1e-4 def lr_lambda(epoch): if epoch < 10: return (epoch + 1) / 10.0 else: progress = (epoch - 10) / (total_epochs - 10) return 0.5 * (1 + np.cos(np.pi * progress)) scheduler = torch.optim.lr_scheduler.LambdaLR(optimizer, lr_lambda=lr_lambda)weight_decay=0.01是 L2 正则化的实现，在多任务场景下尤其重要——任务分支的参数如果过大，会主导输出，挤压共享层的作用。如果你发现某个任务分支学得特别快而其他任务几乎没有进展，先检查是不是该分支的权重范数过大。可以给每个任务分支单独加一个正则项，比如loss += 0.001 * ||head_weight||²，这比全局 weight decay 更精准。
4.3 训练过程监控：tensorboard 怎么用才能定位到具体问题
多任务模型训练时，只看总 loss 是远远不够的。总 loss 从 5.0 降到 3.0，可能是 PM2.5 任务从 4.0 降到 2.0，而 O₃ 任务从 1.0 没动。所以要记录每个任务的单独 loss，每 200 个 step 打印一次，同时用 tensorboard 记录每个任务的验证集指标——不仅包括 MSE，还包括 MAE 和 R²。
这个图展示的是典型的多任务训练曲线：三个任务的 loss 同时下降，但下降速度不同，说明权重设置合理。如果出现某个任务 loss 先降后升的 U 型曲线，大概率是权重失衡——它被其他任务压制了。如果出现锯齿状剧烈震荡，可能是学习率太大或者数据批次里有异常值（比如沙尘暴当天的 PM10 浓度异常高）。定位到具体任务后，修改方法通常有两种：调整该任务的权重，或者检查该任务的数据预处理是否合理。
5. 避坑与排查：空气质量多任务模型的 5 个真实踩坑记录
5.1 数据泄漏：训练集和验证集时间重叠导致准确率高到离谱
现象：模型在验证集上 R² 达到 0.95，但部署后效果一塌糊涂，甚至不如简单的历史均值。原因：滑窗采样时，训练集和验证集按"随机抽样"划分，而不是按时间顺序划分。由于滑窗之间存在重叠，验证集里的样本窗口包含了训练集里出现过的时间步，模型相当于"见过"了答案。解决：严格按时间顺序切分，前 80% 的时间段做训练，后 20% 做验证，并且保证切分点前后至少间隔一个窗口长度（72 小时）。
按时间顺序切分后，R² 从 0.95 掉到 0.82，这个数字才是真实的模型能力。数据泄漏是空气质量预测项目里最隐蔽也最致命的坑，它不报错、不出 warning，只是让你的模型给人一种"完美"的错觉。
5.2 特征标准化方式不对：用全局统计量还是逐站统计量
现象：模型在 A 站点预测效果好，在 B 站点效果差。原因：标准化时用了全站点的均值方差，而 A、B 两个站点的浓度分布差异太大（A 在市区，B 在郊区）。标准化后，郊区站点的浓度被压缩到一个很小的区间，模型很难分辨。解决：按站点分别做标准化，每个站点保存自己的均值方差参数用于反归一化。这个坑在前 3 个 epoch 内不会有明显表现，但到训练后期，loss 降不下去、验证集指标波动大的时候才能察觉到。检查方法很简单：分别打印每个站点的预测值和真实值的分布，如果真实值范围是 0~30，而预测值范围是 0~60，大概率是标准化出了问题。
5.3 气象特征缺未来的数据：预测未来 24 小时需要未来 24 小时的气象预报
现象：训练时使用了"未来时刻"的气象观测值，模型表现得非常好；部署时只能用气象预报值，误差显著增大。原因：这个问题本质上是数据泄漏的一种——气象观测值是事后才有的，预测时刻是用不到观测值的。解决：训练时气象特征统一使用气象预报值（或者用历史观测值模拟预报误差），而不是时刻对齐的观测值。这一步做对了，模型的验证表现会下降一些，但部署后的真实表现会更接近验证值。这个坑在时间序列项目里太常见了，处理不好会让你的模型永远只活在实验室里。
5.4 AQI 预测用分类还是回归：类别不平衡怎么处理
现象：AQI 等级预测模型在轻度污染以上类别上 F1 分数极低。原因：AQI 等级分布严重不平衡——大多数天数"优"或"良"，轻度以上污染只占 5%~10%。模型学到"永远预测良"就能拿到 90% 以上的准确率，但毫无实用价值。解决：回归到数值再映射等级比直接分类更稳定，或者对少数类做上采样。我的做法是：先训练浓度回归模型，再根据浓度到 AQI 的换算规则计算 AQI 数值和等级。这样物理意义明确，也避免了类别不平衡问题。如果你一定要直接训练分类模型，务必使用带权重的 cross entropy，权重设为各类别样本数的倒数。
5.5 多个任务互相打架：共享层被某一任务劫持
现象：训练到中间阶段，PM2.5 任务继续下降，O₃ 任务开始回升，总 loss 几乎不变。原因：共享层的梯度被 PM2.5 任务主导，O₃ 任务分支虽然能学到一部分特征，但共享层的更新方向对它越来越不利。解决：给 O₃ 任务单独加梯度缩放，或者增加软共享的权重系数 λ。具体操作上，我在backward()之前对 O₃ 分支的 loss 乘一个大于 1 的系数（比如 1.5），让它的梯度对共享层的影响恢复到正常水平。这个方法简单粗暴，但非常有效。另一种做法是梯度裁剪时对不同任务设置不同阈值，但实现起来要更精细。
6. 从模型到部署：评估指标选什么以及推理落地技巧
模型训练完成后不能直接交付。先要跑一组完整的评估，选对指标很关键。空气质量预测的惯用指标是 MAE 和 RMSE，MAE 反映平均误差水平，RMSE 对异常值更敏感。如果在沙尘暴或重污染天气下预测偏差大，RMSE 会明显高于 MAE，说明模型对极端事件的响应不足。另外，分时效评估非常重要——分别计算未来 1 小时、6 小时、12 小时、24 小时的预测误差。你会发现误差随时间步长递增，但递增的斜率能反映模型的质量：好的模型 24 小时误差大约是 1 小时误差的 2 倍左右，如果超过了 3 倍，说明模型在长期预测上能力不足，可能需要引入更长期的气象特征。
部署时，我习惯把标准化参数（均值和方差）、模型权重、任务权重配置打包成一个目录，推理时用torch.jit.save或 ONNX 导出，避免部署环境缺少 PyTorch 版本兼容问题。对于定时预测任务，常见的是每小时跑一次推理，输入过去 72 小时数据，输出未来 24 小时的逐小时浓度。推理速度不是瓶颈——LSTM 模型在 CPU 上预测 24 小时序列也就几十毫秒，真正的瓶颈是数据的时效性和质量。
# 推理脚本核心逻辑 def predict(model, recent_data, station_id, scaler_params): """ recent_data: 过去72小时的特征数据 (72, feature_dim) """ model.eval() with torch.no_grad(): # 标准化 + 增加batch维度 x = (recent_data - scaler_params['mean']) / scaler_params['std'] x_tensor = torch.tensor(x, dtype=torch.float32).unsqueeze(0) # 多任务输出 preds = model(x_tensor) # shape: (1, num_tasks, horizon) # 反标准化并返回字典格式 results = {} for task_name, task_pred in zip(['PM2.5', 'PM10', 'O3'], preds[0]): results[task_name] = task_pred.numpy() * scaler_params['std'][task_name] \ + scaler_params['mean'][task_name] return results推理脚本的关键点在于标准化参数的传递要准确，而且要注意训练时各个任务可能使用了不同的标准化方式。如果某个任务单独标准化过，推理时也要分别反归一化，不能用一个全局参数统一处理。我曾经因为简化了这个步骤，导致部署后的 PM10 预测值整体偏高了 20 微克每立方米，排查了半天才发现是标准化反算时用了 PM2.5 的参数。
最后说一个我的个人习惯：每次训练完，我会把最优模型在最近一个月的真实数据上做一次"时间穿越测试"——假装今天是上个月的某一天，只用那天之前的数据做预测，然后和实际观测值对比。这个测试能暴露所有数据泄漏和特征时序错位问题，是模型上线前的最后一道防线。多任务空气质量预测做到这一步，你交付的就不是一个能跑通的 Demo，而是一个经得起真实业务检验的预测系统。希望帮到你。
本文还有配套的精品资源，点击获取
