做了好几年气象AI算法落地我越来越觉得AI气象预报真正难的不是把模型跑出多高的评分而是怎么把数值模式输出、雷达观测、自动站报文这些零散信息和短临预警业务缝成一个能稳定上线的系统。这次要分享的项目就是围绕“数值模式融合短临预警”做的一次完整工程实践目标很直接让分钟级更新、公里级分辨率的降水预警不再停留在试验报告里而是真正能在业务环境中跑起来。整条链路覆盖多源数据处理、时空对齐、模型训练、推理部署和预警发布适合正在做气象AI应用、算法落地或者智能预报平台的同学参考。1. 整体设计思路为什么不能只靠雷达外推1.1 短临预警的行业痛点和AI切入点短临预警通常指未来0到6小时内的天气预警尤其是强降水、雷暴大风、冰雹这类中小尺度灾害性天气。传统做法里雷达外推是主力拿过去几帧雷达反射率图用光流法或相关法推算回波未来的移动和演变。这个方法在系统性强降水里表现尚可但一到对流新生、快速增强、地形触发这些场景就抓瞎因为光流法本质上假设回波是“平移”的它没有物理约束也不知道云内外的大气环境正在发生什么。数值模式呢理论上包含完整的大气物理过程能预报未来几小时到几天的环流场但受限于计算资源和初始场误差对暴雨的落区和强度经常有空间偏差时间上也很难做到分钟级更新。真正做预报业务的人都清楚一个尴尬局面雷达外推能跟上“现在”但看不清“马上”数值模式看得远却不一定看得准“眼下十分钟”。AI在这里能切入的点就是把数值模式提供的环境场信息和雷达观测这种高频遥感信息揉在一起让模型自己去学“什么环境下回波容易发展”“什么风场配置会造成列车效应”。这和单纯做图像外推是两码事更像是在给预报员配一个自动化的“数值释用助手”。我们在项目立项时就把目标定成用AI把数值模式的空间预报能力与雷达的时序观测特征做深度融合输出未来2小时内逐10分钟的降水概率和定量降水估计最终给短临预警系统直接供数。1.2 数值模式、雷达观测与AI融合的架构选择架构层面第一件事就是明确数据流和依赖关系。我们不是把AI模型黑箱一样塞进业务流程而是做成三个环节输入特征工程、融合模型推理、预警规则转换。输入特征工程负责把所有原始数据统一到一个时空网格上。雷达反射率拼图、自动站降水、数值模式地面和高空物理量都要插值到同一套经纬度网格、同一套时间切片上。这一步在工程上最烦但也是整个项目的地基。模型推理采用一个多模态神经网络雷达数据走卷积编码器模式场走另一个编码器中间用注意力机制做融合。预警规则转换则干脆把模型输出交给一套后处理规则让预报员能看懂、能干预而不是直接全市发警报。选型时我们对比过两条路线一条是端到端直接让AI输出预警等级另一条是AI输出中间物理量再人工定阈值。最后选了后者原因很实际短临预警业务需要可解释性和风险等级可调整。如果模型直接输出“红色预警”万一判断错了复盘时很难定位是模型问题还是特征问题。先输出降水概率和定量降水估计再由规则模块根据阈值、累计雨量、持续时间转换成预警等级每条预警都能回溯到具体概率和阈值预报员也更容易接受。这种架构还有个好处就是模型可以独立迭代预警规则也可以独立调整。模型精度上来了规则不动业务口径变了模型不用重训。对气象台站来说这种“互不绑架”的模块化设计落地阻力会小很多。2. 数据基建模型吃的是规则不是文件2.1 多源数据接入与统一时空坐标系气象AI项目里流传一句话清洗数据的时间一定比调模型的时间长这话在这个项目里体现得淋漓尽致。我们接的数据源包括每6分钟一帧的雷达组合反射率拼图、逐小时的自动站降水观测、数值模式逐3小时输出的多个物理量场还有地形高程用于空间特征。每个数据源的投影坐标、时间分辨率、缺测标记都不一样。雷达是极坐标扫描转换后的等经纬度网格模式是高斯网格或本来就在经纬度上但分辨率不同自动站则是散点。第一步不是急着训练而是把所有数据统一到一个标准时空坐标系。我们选了预报区域中心点的兰勃特投影网格空间分辨率设为1公里时间切片是10分钟。雷达数据直接重投影到目标网格模式场则做双线性插值先到目标网格再做时间线性插值保证每个预测时刻都有对应的模式环境场。自动站降水没有网格化我们先用反距离权重插值到1公里网格然后把它当作“地面真值”标签的来源。这套统一坐标的东西看起来不复杂但工程实现里坑特别多。比如雷达拼图的边界会出现非矩形区域插值后边界外会有明显的条带伪影模式场因为原始分辨率太粗插值到1公里后看起来像打了马赛克直接喂给卷积网络会造成空间纹理的假象。我们后来在训练时把模式场原始分辨率作为附加信息一起输入让模型知道哪些纹理是真的、哪些是插值出来的平滑感。还有时间对齐也容易出错。雷达是每6分钟一帧自动站是逐小时累加降水模式是3小时一次。如果不做时间窗口对齐模型会学到错误的时间相关性。我们最终把输入设定为过去1小时内的6帧雷达序列、过去1小时和未来2小时的模式场按目标时间插值、过去1小时自动站累积降水增量统一以预测起点时间为基准对齐。2.2 质量控制和标签生成的工程细节数据质量控制往往被算法工程师忽略但在气象业务里错一个报文、缺一个雷达仰角都可能让模型学到系统性偏差。我们用了一套带规则的数据清洗流程核心是过滤明显异常值。雷达反射率常见的异常包括地物杂波、速度模糊、距离折叠虽然业务软件已经做过初步处理但拼接图里偶尔还会有零散的强回波点。我们用中值滤波加回波连续性检测来剔除孤立的强回波点。模式场的检查相对简单主要查极端温度和风场突变这些往往是模式积分发散导致的非物理值。自动站降水则要做空间一致性检查如果一个站点降水量比周围站点高出一个数量级但附近的雷达回波并不强这条记录会被标记为可疑不参与标签生成。标签生成环节我们一开始直接使用自动站插值后的降水场作为训练目标结果模型学会了“把降水抹平”——因为空间插值本身会平滑掉降水极值模型输出总是低估强降水中心。后来改成“标签用雷达定量降水估计(QPE)与自动站观测融合”的方案先用雷达Z-R关系反演降水强度再用自动站站点值做偏差订正得到一张既保留空间细节又贴近地面实况的降水标签场。这个思路牺牲了一点纯粹性但训练出的模型在强降水中心的表现明显更好。标签的另一个关键设计是同时输出“降水概率”和“定量降水估计”。直接回归降水值的问题在于强降水样本太少模型会倾向输出保守的中小值导致强降水漏报。我们采用分类和回归混合输出先让模型判断“未来10分钟这个格点是否会发生降水以及是否超过中雨/大雨/暴雨阈值”再在发生降水的条件下回归定量降水值。这样既保留了概率的判别能力又提供了具体的量级信息。3. 模型选型与训练策略融合不是把特征拼在一起3.1 骨干网络与多模态融合方案模型结构上我们最开始实验过直接拿U-Net做多通道输入把雷达序列和模式场拼成一个张量喂进去。效果不是不行但有个明显问题雷达的高频细节和模式的低频环境场挤在同一组卷积核里模型很难平衡两者的贡献训练过程中经常是回波特征主导模式场几乎没起作用。后来改成双编码器结构。雷达分支用三维卷积处理过去1小时的雷达序列提取回波的移动和演变特征模式分支用二维卷积处理多个模式物理量侧重捕获大气环境的空间分布。两个分支的输出通过一个跨模态注意力模块融合再送入解码器生成未来2小时逐10分钟的降水概率和定量降水估计。为什么用跨模态注意力当时考虑的是不同天气系统里雷达和模式的重要性是动态变化的。普通对流降水雷达过去演变信息权重高而地形触发的新生对流局地可能还没有明显回波模式里的风向、湿度场反而更关键。注意力机制可以让模型根据当前输入自动调整融合权重而不是静态地固定一个比例。这个设计在后来的个例分析里确实有效一些新生雷暴的预警提前量比纯雷达外推多了10到20分钟。模型骨干我们用了ConvLSTM结合U-Net的混合结构时序信息用ConvLSTM建模空间细节用U-Net的跳跃连接保持。参数量大概在30M左右单张A100上训练一个epoch大约需要40分钟。推理速度后面会用TensorRT压缩实际在业务服务器上单帧预测延迟能控制在100毫秒以内这个后面单独说。3.2 损失函数、训练技巧与不确定性输出损失函数是这次模型调优里收益最大的点。最开始用MSE直接回归降水值学出来的结果一片模糊强降水中心很弱。后来采用分位数损失和加权交叉熵的组合定量降水估计用分位数损失让模型输出多个分位点既给均值也给不确定性区间降水概率分类用加权交叉熵对大雨和暴雨样本提高权重。权重表是根据训练集里各类降水的频率统计出来的暴雨样本的权重是弱降水样本的8倍左右。这里有个特别值得说的技巧我们把样本权重和雷达回波强度一起做损失加权而不是只看降水类别。因为同样是小雨如果雷达回波很强意味着可能存在强对流云但地面还没降水这种样本对未来发展很重要。于是我们设计了一个动态损失权重损失权重 类别权重 × 回波强度系数。折腾下来模型对突发性强的个例敏感度提升了不少。训练时还用了课程学习策略先让模型在前2个epoch只学习未来10分钟的预测然后逐阶段加入未来30分钟、1小时、2小时的目标。这样做的好处是模型先掌握了短时演变的基本规律再去拟合更长时效的空间不确定性收敛稳定很多。如果不做课程学习模型常常为了降低2小时后的误差把前10分钟的预测也抹平了。不确定性输出方面模型不是只输出一个降水值而是输出10%、50%、90%三个分位点。业务里用的主要是50%分位作为最可能值同时把90%分位和10%分位的差值当作置信度用于预警规则里的最低信心门槛。这个设计在发布临近预警时非常实用比如某片区域的50%分位降水已经达到大雨级别但置信区间极宽这种情况下我们会提高到橙色预警但不会直接发红色等确认回波持续增强后再升级。4. 短临预警上线从模型输出到业务动作4.1 预警阈值设计和风险分级模型输出是逐格点的概率和定量降水估计但预警发布不能只看单点。我们和预报员一起把预警规则拆成了三层格点风险、区域风险、预警事件。格点风险层对每个格点根据降水概率和分位数判断当前时刻是否达到中雨、大雨、暴雨的“候选”状态。这里有个经验阈值未来20分钟内降水概率超过60%且50%分位降水超过8毫米/小时就标记为大雨候选概率超过50%50%分位降水超过16毫米/小时标记为暴雨候选。这些阈值不是拍脑袋定的而是对历史漏报和误报做ROC分析后挑选的平衡点。区域风险层把格点风险聚合成预警区域。我们会计算每个候选区域的总面积、最大雨强、移动速度、持续时间四项指标然后映射到蓝、黄、橙、红四级预警。比如黄色预警要求区域面积超过50平方公里且最大雨强达大雨级别橙色预警要求至少有30%的格点达到暴雨候选且区域形状呈线状或带状因为线状回波往往意味着列车效应持续性强降水风险更高。预警事件层则是真正的业务动作。系统生成预警事件后会附带一张“决策支撑图”图上标出触发预警的格点、未来1小时移动路径、各分位降水曲线以及过去30分钟回波演变。这些信息全部打包推送到短临预警平台预报员可以在平台上人工确认后发布。这个流程我们没有做成全自动核心原因是气象预警涉及公共安全必须保留人工复核环节。AI负责把“哪里有风险、风险有多大”讲清楚最终决定还是交给预报员。4.2 推理性能优化与监控告警短临预警对延迟的要求很严格。我们的目标是从新的雷达数据到达服务器到模型推理完成并生成预警事件整个过程不超过2分钟。雷达拼图每6分钟到一批也就是说我们必须在一个扫描周期内跑完所有任务。最先优化的是数据预处理管线。我们之前用了Python的pandas做格点数据操作慢得不行后来全部改成xarray配合dask并行计算并把插值操作预先计算好索引表避免每次运行都重新算坐标变换。这套优化把预处理时间从40多秒压到8秒左右。模型推理部分我们用TensorRT把PyTorch模型转成了FP16精度并对卷积层做了算子融合。原来一次全区域推理要600毫秒压缩后降到80到120毫秒。这个速度对业务完全够用甚至还能腾出资源跑多模型对比。如果未来区域范围扩大我会优先考虑切成多个子区域并行推理而不是盲目堆算力。监控告警是整个系统中很容易被忽略的一环。模型在业务里跑久了数据分布会变比如雷达系统升级、模式版本更换都会导致推理结果偏离训练时分布。我们做了两套监控一是数据质量监控实时统计输入数据的缺测率、雷达回波面积、模式场均值一旦指标偏离基线会触发告警二是预报表现监控每天对比模型预测与自动站实况计算降水概率的Brier分数和定量降水估计的误差如果连续三天恶化自动通知算法团队排查。这套监控在系统上线第四周就立功了发现了一次由于雷达拼图软件升级导致的反射率系统性偏低及时避免了一轮大范围漏报。5. 典型问题与排查实录5.1 雷暴单体移动速度过快导致漏报项目测试期遇到最典型的问题是快速移动的雷暴单体经常漏报。明明过去30分钟回波很强模型输出的未来20分钟降水概率却偏低。后来逐个例分析发现是输入雷达序列的时间窗口太短只有1小时而这类快速移动单体的演变周期通常在40到60分钟模型只看得到最近一段抓不住单体进入“强盛期”之前的增长趋势。处理办法有两个。第一把雷达输入序列从过去1小时延长到过去1.5小时同时保持10分钟间隔这样模型能看到更长时间的发展趋势。第二在输入中增加一个“回波面积变化率”通道统计过去30分钟内超过一定阈值的回波面积变化这相当于给模型一个显式的趋势提示。改完之后快速移动单体的命中率提升了大约15个百分点漏报率明显下降。这里面有个工程判断增加输入序列意味着模型参数和训练成本都要涨不能无脑加。我们先用消融实验确认了新增时刻的边际收益确定过去1.5小时之后再加信息收益已经不大才定下这个窗口。5.2 静默期误报偏多与样本不均衡处理另一个问题正好相反在天气平静期模型频繁出现小范围的弱降水预警虽然等级不高但预报员被频繁打扰几次后就会对系统失去信任。排查后发现两个根因一是训练数据里静默期样本占比太高模型学到的“无降水”先验过强导致对弱回波噪音过度敏感二是我们在损失加权时只提高了强降水的权重却没有惩罚“无降水区域内的微小输出”。改进思路是重采样加课程阈值。重采样方面把静默期样本比例压低到总样本的40%避免模型总是倾向于输出“无降水”。课程阈值方面在训练早期设置一个输出门槛模型只有当预测概率超过0.3时才计算分类损失低于这个值默认预测为无降水把模型精力聚焦在关键事件上。随着训练进行这个门槛逐步降低到0.1让模型慢慢学会区分细微回波和真实降水。上线后静默期误报率下降了六成预报员反馈明显改善。5.3 模式更新频率低导致的时滞问题数值模式每3小时才更新一次而短临预警每10分钟就要出结果。如果模式场是3小时前的遇到天气系统快速演变的情况模型输入和真实大气环境可能已经严重不一致。这个问题的解法不是单纯提高模式刷新频率而是设计了一个“模式时滞编码”把模式场的有效时间戳和雷达观测的最新时间戳之间的间隔作为一个附加特征输入模型让模型自己学会“当模式信息陈旧时要多依赖雷达观测”。这个特征加进去之后系统在模式空缺期的预报稳定性提高了很多。之前模型会在模式切换的整点时刻出现预报跳跃因为插值后的模式场突然更新导致输出突变。加了时滞编码后模型对这种更新有了预期输出变化平缓多了。5.4 问题排查速查表我把日常运维中容易遇到的现象、排查方向和应对措施整理成一张速查表给团队新同学用起来非常方便。异常现象可能原因排查方向处理措施强降水中心预报强度偏低标签场空间平滑查看训练标签极值分布改用雷达QPE与站点融合标签静默期频繁弱预警样本不均衡或弱回波过拟合检查损失权重和样本比例重采样压低无降水样本加输出门槛预报结果出现明显条带插值边界或模式原始分辨率过低对比输入特征纹理增加模式分辨率标识通道整点时刻预报跳变模式场更新导致输入突变查看时滞特征变化加入模式时滞编码平滑输入变化推理延迟突增数据预处理阻塞或GPU显存不足打点分析各环节耗时预计算插值索引TensorRT优化连续几天评分变差上游数据分布漂移检查雷达拼图软件或模式版本变更建立每日预报表现监控及时告警6. 影响范围与后续扩展整套系统上线后对短临预警业务的改变不是简单的“多了一个工具”而是在工作流里真正切进去了一段自动化环节。过去预报员每6分钟就要盯着雷达图做主观外推现在系统自动给出未来2小时的逐10分钟预警建议预报员更多时间用来分析天气情势、评估模式不确定性、与上级台沟通。尤其在城市内涝、大型活动保障这类对时间敏感的场景提前10到20分钟的有效预警能争取到非常宝贵的处置窗口。后续扩展方向上我目前在做两件事。第一是把区域数值模式升级到公里尺度快速更新循环让模式场本身的空间分辨率不再成为瓶颈同时继续优化时滞编码让融合算法对模式更新节奏更鲁棒。第二是引入更多非传统观测数据比如闪电定位、卫星云顶温差、雨滴谱仪这些数据对强对流的新生和增强有很好的指示作用。多模态的含义不应该停留在算法结构上数据源的丰富程度往往是模型上限的真正决定因素。在工程组织上我们也开始尝试用AI编程工具辅助数据管线的代码开发和调试把一些重复性的插值、批处理脚本交给智能体生成再人工审查。实测下来纯手工写的管线代码缩水了大约30%但质量门槛一点不能降所有生成代码都要过完code review才允许合入。这个节奏对我们这种小团队比较友好。另外模型本地部署方面也在探索模型轻量化方案考虑用蒸馏和量化把模型压到适合在边缘节点运行的水平方便在地市一级的服务器上做私有化部署。回到最开头那句话AI气象预报的工程实践真正的门槛其实在统筹。你需要同时懂一点气象、懂一点深度学习、懂一点数据工程还要知道怎么和预报员沟通业务需求。这个项目走到现在最大的收获不是模型指标涨了多少而是团队所有人都意识到模型只是决策链路的一环数据、阈值、监控、人机协同哪个环节掉链子整个系统都会翻车。如果你也在做类似的预报预警项目我的建议是先把数据和监控做扎实再谈模型这个顺序永远错不了。