简介：本资源是一项面向计算机、人工智能及气象信息相关专业学生的高分毕业设计成果，聚焦雷达回波序列的短期降水预测任务，采用Transformer架构实现端到端的时空特征建模与外推。资源适用于课程设计、毕设参考及AI气象交叉方向入门与进阶学习，尤其适合希望掌握时序建模在遥感数据中落地应用的实践者。压缩包共31个文件，含26个Python源码（覆盖模型定义、训练/推理流程、数据预处理与评估模块）、2个Shell脚本（一键启动训练与推理）、1个README说明文档、1个requirements依赖清单及1个.gitignore，整体仅26KB，轻量易部署。项目已通过完整调试与答辩验证（评审分98分），提供从数据加载、模型构建（含GSTA等改进模块）、训练配置到结果可视化的一站式实现，目录结构清晰，模块职责分明，便于理解核心逻辑并在此基础上拓展新功能。 真正开始琢磨雷达回波外推这个方向，是去年帮几个学弟学妹看毕设的时候。他们拿到的课题清一色是“基于深度学习的短临降水预测”，但大多数人一上来就卡在同一个地方：数据怎么处理、模型怎么选、跑出来的结果为什么糊成一团。我那时候就在想，如果有一套完整的、能直接跑通的项目源码，配套清楚的项目文档，再加上整理好的数据集，这个方向完全可以成为计算机视觉、深度学习方向最容易出成果的高分毕设之一。今天这篇就把Transformer做雷达回波外推这件事从头到尾拆开讲清楚，涵盖数据、模型、训练、评估、文档整理这些方方面面，希望能帮正在做相关课题的同学省下大量踩坑时间。
这个方向的核心任务，用一句话说就是：给模型看过去一段时间（比如过去1小时）的雷达回波图序列，让它预测未来一段时间（比如未来1小时）的雷达回波图序列，从而推断降水落区和强度变化。这在气象上叫作临近预报（Nowcasting），时间尺度一般在0到6小时，比数值天气预报（NWP）短得多，但恰恰是最考验“外推”能力的一段窗口。过去气象台用光流法做外推，本质是假设降水回波团做匀速平移，简单但不擅长处理回波增强、衰减、新生、分裂这类非线性变化。深度学习方法大火之后，这个问题被重新定义为一个时空序列预测问题，模型从大量历史雷达图中学习回波的演进规律，对未来做逐帧预测。Transformer在这里的角色，正是替代或者增强原有ConvLSTM系列模型的特征提取和时序建模能力。
我要聊的内容比较长，但每部分都有明确的落点。如果你是刚拿到这个课题、什么都不太清楚的状态，建议按顺序读；如果你已经跑通了一版模型，可以直接跳到训练和评估那一章，大概率能解决你“loss很低但预测图很模糊”的困惑。
1. 用Transformer外推雷达回波：这个毕设到底在解决什么问题
1.1 短临降水预测为什么需要“外推”
先理清一个概念：什么叫外推。外推和你熟悉的图像分类、目标检测都不一样，它属于时空序列预测。输入不是一张静态图，而是一串带时间顺序的图，输出也是一串未来时刻的图。雷达回波图每个像素代表的是该位置上空的反射率强度，单位是dBZ，数值越高说明降水粒子越多、降水强度越强。但雷达观测到的只是“当前状态”，决策者真正关心的是“未来会不会下雨、下多大、什么时候到我家门口”。所以模型的任务就是根据过去若干个时刻的状态，推演未来的状态。
这件事难在哪呢？难在降水系统的演变既受大尺度天气系统驱动，又有很强的局部非线性特征。举个例子，两个强回波单体相遇后可能合并增强，也可能互相削弱，这个过程受温度、湿度、风场等多个因素影响，光靠“像素平移”是模拟不出来的。而神经网络尤其是带时序建模能力的深度学习模型，可以从大量样本中隐式学习这些演变规律，这就是它比传统光流法强的地方。
1.2 为什么用Transformer而不是ConvLSTM
学术界做雷达回波外推，早期最经典的工作是ConvLSTM，后来又有TrajGRU、PredRNN、E3D-LSTM等一堆变体。它们的共性是用卷积来提取空间特征，用RNN结构来建模时间依赖。这套方案在很长一段时间里是主流，我实际复现过ConvLSTM，效果确实能用，但有几个问题很让人头疼：一是RNN的逐步递归结构训练慢，长序列上梯度传播容易出问题；二是卷积的感受野有限，一个卷积核盖住的区域之外发生了什么，模型“看不见”，而强对流单体之间的远距离相互作用恰恰很重要。
Transformer就刚好避开了这两个痛点。自注意力机制天然支持序列内任意两个位置之间的信息交互，放在雷达图上就是任意两个图像块之间可以直接建立关联，不受卷积核大小限制。空间上的远距离依赖，在物理上对应的是对流系统不同区域之间的相互作用，比如强回波单体A和远处的单体B，虽然相隔几百公里，但它们可能同属一个锋面系统，未来演变高度相关。Transformer能捕捉到这种关系，这是它在这个任务上的本质优势。另一方面，Transformer支持的并行训练比RNN的逐步递归高效太多，在同样硬件条件下实验迭代速度快很多。
1.3 这个项目的完整交付边界
这个课题做下来，交付的东西通常是四件套：可运行的Python源码、项目文档教程、整理好的数据集、实验分析报告。源码部分包含数据加载、模型构建、训练评估、可视化脚本；文档教程要能让人按步骤从零跑通；数据集则是预先清洗切分好的雷达回波序列样本。从毕业设计角度看，这四样东西刚好对应任务书里“完成一个系统”的要求，也方便答辩时演示。
用一句话总结这个项目的价值：它用深度学习里最火的Transformer架构，解决了气象预报里一个真实且重要的问题，而且结果可以直观可视化。形式上有模型设计、有对比实验、有评估指标分析，内容上兼顾了算法创新和工程落地，这种项目在毕设里属于典型的“高分胚子”。
2. 数据是命脉：雷达回波数据集的构建与预处理细节
2.1 雷达回波数据的常见来源与格式说明
很多同学拿到这个课题，第一反应是去网上找数据集，这思路没错。雷达回波外推领域最常用的公开数据集是HKO-7，由香港天文台发布，样本是从2009年到2015年期间香港周边雷达观测数据中提取的，输入是过去10帧雷达回波图，输出是未来10帧雷达回波图，帧间隔6分钟，每帧大小在495x495像素左右。数据格式一般是numpy数组或者HDF5文件，反射率值已经做了量化处理，加载起来非常方便。做中文环境下的研究，也可以关注气象部门公开的雷达拼图数据，或者自己从天气雷达基数据做解析，后者工程量大，我一般不建议毕设阶段自己从零做。
如果是自己处理原始雷达数据，最需要注意的一点是：雷达扫描的原始数据是极坐标格式（方位角、距离库），需要先做坐标转换插值成笛卡尔坐标下的格点场。换到规则网格之后，还要做退模糊、噪声抑制这些质量控制。HKO-7这些公开数据集把这些脏活都做完了，这也是我推荐大家优先用公开数据集的原因。自己处理数据不是不行，但耗费的时间可能比写模型还多，对毕设来说性价比不高。
2.2 预处理里最容易踩的五个坑
这里说一下我实际处理雷达数据时遇到的坑，每个都是真实踩过之后才总结出来的。
第一个坑是反射率裁剪。dBZ值理论上范围很宽，但雷达的观测动态范围一般在-10到70dBZ之间，超过这个范围的值基本都是噪声或者地物回波。我见过有人不做裁剪，直接把原始值喂给模型，结果就是模型花大量容量去拟合异常大值，小到-30dBZ的弱回波被模型忽略。正确做法是先裁剪到合理范围，再归一化到[0,1]或者做标准化。
第二个坑是无效值处理。雷达扫描范围之外是空的，有些数据文件里用NaN表示，有些用0表示。如果不加区分地把这些位置当成真实观测值，模型会学到“边界外大片区域永远是0”这种错误知识。我用的方案是准备一张和二值掩膜，标注哪些像素是有效观测，在计算损失的时候把无效区域排除掉，只在有效区域上计算。
第三个坑是样本切分的时间泄漏。雷达数据是强时序数据，相邻时间的样本高度相关。如果随机打乱数据再切分训练集和测试集，那训练集里某个样本的“未来帧”很可能就出现在测试集里，评估结果虚高，完全不能反映真实泛化能力。正确做法是按时间顺序切分，比如前80%的时间段作为训练集，中间10%作为验证集，最后10%作为测试集，切分完之后再做滑窗采样。
第四个坑是数据增强的方向性。图像分类常用的水平翻转、随机裁剪，在雷达外推里可以用，但有一个细节要注意：雷达回波的演变在时间和空间上是有物理方向的，时间方向不能做逆序增强。你不能把一段回波演变倒过来当成另一段训练样本，因为真实天气过程不可逆。空间翻转和随机裁剪相对安全，但也要在理解物理含义的前提下使用，比如裁剪区域不能太小，否则强回波单体被截断，样本失去意义。
第五个坑是滑窗采样的帧对齐。构建训练样本时要用一个滑动窗口切出“输入帧+输出帧”的组合。这里要保证窗口内的所有帧在时间上是严格连续的，不能有跳帧；还要注意样本之间的重叠不能太大，否则训练集内部高度冗余，模型很容易过拟合。我一般在样本构建时设置一个步长，比如窗口每滑动3-5帧才取一个样本，既保证样本数量，又不至于全是一次性重叠。
2.3 滑窗样本构建与数据加载器设计
具体到代码实现上，滑窗构建样本的逻辑不复杂。假设原始数据是一个时间序列的数组，形状是(T, H, W)，输入帧数设为INPUT_LEN=10，输出帧数设为OUT_LEN=10。从时刻t开始取[t, t+INPUT_LEN)作为输入，取[t+INPUT_LEN, t+INPUT_LEN+OUT_LEN)作为输出，就能得到一个样本。每滑动一定步长重复这个过程，最后把所有样本存成npy文件或者做在线加载。
我在数据加载器里做了一件后来觉得很值得的事：线上做随机裁剪。训练时把每帧图随机裁剪成更小的尺寸，比如从495x495裁剪到256x256，相当于做了数据增强，而且能显著降低显存消耗。测试时在原始尺寸上做中心裁剪或者直接整图推理。需要注意的是，输入帧和输出帧的裁剪位置必须完全一致，也就是所有帧共用同一个裁剪偏移量，否则输入和输出的空间位置对不上，模型学到的东西就乱了。数据加载器还需要把处理好的数据转成PyTorch的Tensor，并保证输出形状是(B, INPUT_LEN, C, H, W)这种五维格式，C一般等于1（单通道反射率）。
3. Transformer模型如何落进雷达外推任务：架构选型与关键设计
3.1 输入输出结构和整体框架选择
雷达回波外推里最常见的建模框架有两种：Encoder-Decoder结构和Encoder-Forecaster结构。Encoder-Decoder的思路是，编码器把输入的雷达回波时空序列压缩成一个潜在表征，解码器从这个表征逐步解码出未来的回波图。这种结构在机器翻译、图像生成里很常见，但用在像素级的视频预测上有天然劣势：编码器压缩信息的时候会把细节丢掉，而雷达回波预测对细节非常敏感，尤其是强回波的中心位置和强度，差一个像素、差一个dBZ都可能导致漏报强降水。
我在项目里更推荐Encoder-Forecaster结构。具体来说，输入序列先经过空间编码器（一系列卷积层把每帧图像转成特征图），然后由Transformer模块对特征序列做时空建模，最后通过预测头（Forecaster）逐帧生成未来的回波图。这个结构里Transformer输出的还是特征图序列，空间细节经过了特殊保留，预测头只需要做上采样和卷积细化，信息损失比Encoder-Decoder小得多。这也是目前主流视频预测模型的通用做法。
3.2 空间编码：Patch Embedding与窗口注意力的取舍
如果直接把每帧雷达图当成一个整体做全局自注意力，会立刻撞上计算复杂度的墙。假设一张回波图256x256像素，展平后是65536个token，标准的自注意力复杂度是O(N²)，一次注意力计算就有几十亿次操作，显存直接爆炸。解决方案大致分成两条路线。
第一条路线是像ViT那样把图像分成固定大小的patch，比如每个patch 16x16像素，256x256的图就变成16x16=256个token，数量大大减少，再在这256个token上做标准全局自注意力，计算开销就可控了。这条路线实现简单，但patch太大会丢掉局部细节，太小计算量又上去，需要平衡。
第二条路线是借鉴Swin Transformer的窗口注意力（Window Attention），在特征图的局部窗口内做自注意力，再用移位窗口实现跨窗口信息交互。窗口注意力在雷达回波外推任务里效果通常更好，原因是它既控制了计算量，又保留了对局部回波结构的精细刻画能力。我实测下来，256x256输入、8x8窗口、4层Transformer编码器的配置，在单张24G显存的卡上能跑得很稳；如果没有大显存，把输入裁剪成128x128也能得到不错的效果。
我自己最终采用的是混合方案：先用两层卷积下采样把输入缩到合适尺寸，再在特征图上做窗口注意力，最后用转置卷积上采样回来。卷积负责低层局部特征提取，Transformer负责高层全局关系建模，两者分工明确，比单用其中一种效果都好。这个设计也是我在论文里重点分析的贡献点之一。
3.3 时间建模：位置编码与帧间注意力
雷达外推输入是连续的多帧图，简单的做法是把每一帧分别做patch embedding，然后拼接成一个长序列送进Transformer。但这里有个绕不开的问题：序列中的每个token必须知道它来自哪一帧、位于空间哪里，否则自注意力分不清不同时刻同一位置的回波是什么关系。
位置编码就需要同时考虑空间和时间两个维度。空间位置编码可以采用标准ViT或者Swin里的相对位置偏置，这是空间维度的锚点；时间维度上我额外加了一个帧索引编码（Frame Index Embedding），把当前帧在整个输入序列中的序号变成一个可学习的向量，加到该帧所有token的特征上。这么做的效果非常明显：去掉时间编码之后模型输出会出现帧间闪烁，加了之后序列连续性明显改善。
更进一步的做法是显式设计帧间注意力。比如让每一帧的特征先经过空间自注意力，再做和相邻帧之间的交叉注意力，这样模型能明确学习“上一帧的强回波中心，在这一帧移动到了哪里”。不过在我的实验里，只要位置编码设计合理，普通的全局时空自注意力已经能学到帧间对应关系，复杂机制带来的收益有限，反而增加训练难度。毕设阶段建议先把基础方案跑通，再考虑帧间注意力的改进。
4. 训练、评估与迭代：那些代码跑通之后真正决定成败的细节
4.1 损失函数：为什么纯MSE会把预测变成“一团糊”
这是整个项目里最经典的一个坑，也是我每次带人都要重点强调的。很多同学第一版模型用MSE（均方误差）做损失函数，训练时loss下降得很漂亮，但看预测出来的回波图，会发现强回波中心全被抹平了，整个画面灰蒙蒙一片，该下暴雨的地方变成毛毛雨。原因在于MSE假设误差在空间上均匀分布，而雷达回波数据是极度不平衡的：大部分像素是零回波（无降水），只有少部分像素是强回波。模型为了最小化MSE，最优策略就是“预测一个温和的平均场”，因为求平均能同时降低所有像素的误差，就算把暴雨漏报掉，整体loss的损失也不大。
解决这个问题的方向有两个。第一个是给损失函数加权重，对强回波区域（比如dBZ大于30的区域）加权，让模型更重视这些关键像素。第二种是采用阈值感知的损失设计，把回归损失和分类损失结合在一起，比如先用一个二分类损失判断某个位置“未来是否有降水”，再用回归损失精确预测降水强度。后者更贴近业务评估指标的逻辑，我实际测试下来效果更好。
我用的最终损失函数是加权MSE加上一个辅助的对抗式结构一致性约束，但结构一致性约束实现复杂，毕设阶段可以不做，直接用加权MSE就能解决大部分模糊问题。具体做法是：对每个像素赋予权重w，dBZ大于等于35的像素权重设为5，dBZ在20到35之间设为2，其余设为1，然后计算加权后的MSE。做完这个改动，预测图里的强回波中心立刻变得清晰很多。
4.2 评估指标：CSI、POD、FAR才是真正要说的话
模型训练过程中看loss，但评价模型好坏绝对不能只看loss，这一点在答辩时尤其重要。雷达回波外推领域有一套标准的分类式评估指标，核心思想是把每个像素的预测结果和真实结果做阈值比较，划分为“命中”“空报”“漏报”和“正确否定”四类，再计算CSI、POD、FAR这些值。
CSI（Critical Success Index）是最常用的综合指标，可以理解为交集除以并集，相当于考虑了命中和误报、漏报的综合得分。POD（Probability of Detection）衡量的是“真实降水区域里，模型预测出来多少”，对应着漏报率；FAR（False Alarm Rate）衡量的是“模型预报有降水的位置里，多少是空的”，对应着空报率。这三个指标要结合实际场景一起看：防灾场景更看重POD，因为漏报一场暴雨的代价比空报大得多；一般场景则希望CSI和FAR保持平衡。
实际评估时要对不同的dBZ阈值分别计算指标，我习惯用20dBZ（对应中雨）、35dBZ（对应大雨）、45dBZ（对应暴雨）三档来做分层评估。答辩时能展示出分阈值指标表格，比单放一张loss曲线有说服力得多。
4.3 训练策略与显存优化技巧
训练配置上，我用的优化器是AdamW，初始学习率2e-4，配合余弦退火调度器和前几个epoch的warmup，这是Transformer类模型的标配配置。batch size取决于显存，一般来说，每帧256x256、输入输出各10帧、batch size为4的情况下，大约需要12GB显存。如果显存不够，优先把输入分辨率降到128x128，或者把输入输出帧数从10压缩到6，效果依然能接受。
混合精度训练是我强烈建议开的。PyTorch的torch.autocast和GradScaler可以无缝支持，训练速度提升大概30%-50%，显存也省很多。我在项目里还加了梯度裁剪，max_norm设为1.0，防止训练早期loss异常时梯度爆炸。
另外一个大坑是训练时间和早停策略。雷达外推模型往往要训练50到100个epoch才收敛，但验证集CSI通常在前20个epoch就基本定型。我一般用验证集CSI作为早停依据，连续10个epoch没有提升就停掉，然后取验证集上表现最好的模型做测试集评估。这样既能保证模型泛化性能，又能省下大把实验时间。
4.4 可视化分析：用什么图一眼看出模型好坏
代码跑通之后，最加分的是可视化分析。我每次做实验都会存三类图。
第一类是逐帧对比图：把某个测试样本的“真实未来帧”和“模型预测帧”按时间顺序排成两行，一眼就能看出模型对回波位置、强度的预测误差有多大。多做几个样本之后就能总结出模型在什么天气类型下表现好、什么情况不行。
第二类是误差空间分布图：把预测帧和真实帧逐像素做差，画成热力图。误差图能暴露模型系统性偏差，比如是不是总是低估强回波强度，或者是不是在回波边缘产生位置偏移。
第三类是序列动画，把预测的时间序列拼成GIF。这个在答辩演示时效果最好，评委一眼就能看懂模型在干什么。我前面提到的逐帧对比和误差图都可以做成tensorboard的log，训练过程中实时查看。
5. 把代码整理成高分毕设：文档、实验记录与答辩准备
5.1 源码目录结构与配置管理
项目源码的组织方式直接影响评审老师的第一印象。我通常推荐的目录结构是这样的：
project_root/ ├── config.py # 全局超参数配置 ├── data_loader.py # 数据集加载与预处理 ├── models/ │ ├── convlstm.py # 基线模型 │ ├── transformer.py # 主模型 │ └── modules.py # 公共组件 ├── train.py # 训练脚本 ├── evaluate.py # 评估脚本 ├── visualize.py # 可视化脚本 ├── utils/ │ ├── metrics.py # 评估指标实现 │ └── logger.py # 训练日志 └── README.md # 项目说明config.py里把所有超参数集中管理，包括输入输出帧数、图像尺寸、patch大小、Transformer层数、头数、学习率、batch size、训练epoch等等。我强烈建议每次实验前都记录一份配置文件，同一个实验跑两遍结果要完全可复现，这是学术规范的基本要求，也是答辩时被追问“你这个结果怎么来的”时最有底气的回答方式。
5.2 项目文档教程：老师想看到什么
项目文档不是代码注释的堆砌，而是一份完整的研究报告，一般包含五个部分：需求分析、数据说明、模型设计、实验分析、使用手册。需求分析要讲清楚“雷达回波外推是什么、为什么要做、现有方法有什么不足”。数据说明要写清楚数据来源、预处理流程、样本构建方式。模型设计是核心，要写清楚整体架构图、每个模块的作用、为什么这么设计。实验分析部分要包含对比实验和消融实验：Transformer对比ConvLSTM基线模型，有具体指标差异；再通过消融实验证明你模型的每个改进点都有实际增益。
评审老师最喜欢看到的是“这个参数为什么这么设、这个设计为什么有效”的推导过程。比如你写了“时间位置编码提升了CSI 0.03”，还要进一步分析“这是因为自注意力需要区分不同时刻的信息，没有帧索引时模型混淆了时序”。这种分析和结论比单纯罗列数字有价值得多。
5.3 高频答辩问题与应对思路
根据我带毕设的经验，这个课题答辩时老师最常问的问题集中在四个方向：
第一个方向是模型选型对比，典型问法是“Transformer比ConvLSTM好在哪，代价是什么？” 回答思路是要点出自注意力的全局建模能力、并行训练效率，同时坦诚承认Transformer计算复杂度更高、需要更多数据和调参技巧才行。第二个方向是网络结构细节，比如“你的时间位置编码是怎么做的？为什么有效？”要能现场画出结构图并解释原理。第三个方向是评估指标，比如“为什么不直接用MSE评估？”这正是你展示对领域理解的地方，可以展开讲MSE的模糊化问题和CSI、POD、FAR的业务意义。第四个方向是局限性分析，比如“你的模型在强对流快速增强时表现如何？”我建议提前做一两个失败案例分析，搞清楚模型在什么情形下失效，这反而比吹嘘效果更能体现科研素养。
5.4 我最后想强调的一点“额外加分项”
如果你还有余力，建议在毕业论文里加一节“未来工作展望”，把注意力机制在雷达外推上的延伸方向写一写，比如结合卫星云图做多模态输入、加入光流场做物理约束、用扩散模型替代自回归生成等等。这几个方向都是目前学术界的前沿热点，写出来会让老师觉得你对领域有宏观认知，而不只是把别人的代码跑了一遍。
答辩前强烈建议把可视化脚本准备好，直接现场展示几个测试样本的预测效果，让评委直观地看到模型输出。这比我前面提到的任何口头解释都更有说服力，也是我接触过的高分毕设里最常见的共同点——他们不一定代码写得最漂亮，但都特别会展示自己的工作。这个项目的核心价值就在于，它把深度学习前沿架构、真实气象业务问题、完整工程化交付这三件事很好地结合在了一起，每一步都有充分的“为什么”可以讲，每一个实验结论都有数据和可视化支撑，这种做实事、讲门道的项目，就是拿高分最扎实的底气。
本文还有配套的精品资源，点击获取
