气象和AI结合这两年确实是个热点但外面大部分文章要么在讲理论要么在炒概念。今天我打算把这半年多在一个实际项目中踩过的坑、趟出来的路以及最终跑通的方案拿出来做一个偏工程视角的复盘。项目核心就三件事怎么把传统数值模式的结果用起来怎么让AI模型补上短临预报这一棒以及怎么把这两者融合到一个能扛住生产环境压力的系统里。先交代一下背景。我们做的这个项目目标区域覆盖范围不算小对时效性的要求极高——尤其是0到2小时的短临预警基本要求分钟级更新否则就没有实用价值。传统的雷电、暴雨预警要么靠预报员的经验要么靠单一数值模式的输出前者主观、后者滞后。我们想做的是在这两者之间插入一个AI引擎把雷达、卫星、地面观测和数值模式输出当成多源输入用深度学习模型直接生成未来两小时的降水概率和落区分布并在这个基础上自动生成预警消息。整个项目做下来我最想分享的不是某个模型有多厉害而是工程落地上那些看不见摸不着却决定成败的细节。比如数据清洗比如标签怎么打比如模型推理延迟怎么压比如融合策略为什么宁可保守也不能激进。下面我按实际项目推进的顺序把这些内容拆开来讲。1. 短临预警到底难在哪先看清问题的边界再谈模型短临预警在气象业务里的时间窗口一般定义是0到6小时其中0到2小时又叫临近预报。它的核心挑战不是“能不能算出未来下雨”而是“未来几十分钟内这场雨的落区会怎么移动、会不会增强”。传统数值模式在短临这个区间表现其实很尴尬。模式起转需要时间边界层物理过程又复杂等模式跑出结果一场已经在雷达上成形的强对流可能已经发展好几个生命周期了。这就给了AI方法一个明确的切入点把雷达这种观测数据的“当前时刻”信息用机器学习的方式往前推。但AI也不是万能的。我们最开始的想法很天真想直接用雷达回波做外推让模型学习过去一小时的回波演变预测未来两小时。跑完基线发现一个问题晴空回波下面、雷暴刚刚酝酿的阶段模型会因为缺少强信号而表现极其保守漏报率很高。后来我们把地面自动站的温度、湿度、风场和边界层高度都加进去情况才改善。这里我总结了一个关键认知短临预报不是单一模型能搞定的事它的本质是“观测驱动”与“模式驱动”的结合问题。雷达能告诉你现在发生了什么但无法告诉你接下来会不会触发新单体数值模式能给出未来大尺度环境场的演变趋势但在局地精细尺度的表达上又不够准。两者的融合才是短临预报的真正解法。具体到工程上这就意味着数据接入层一开始就要考虑到多源异构数据的时间对齐问题。雷达是6分钟一个体扫卫星是10分钟一个时次地面站是5分钟上传一次数值模式是逐小时输出的格点场。这些数据到达系统的时间有先后质量也参差不齐如何在“当前时刻”把它们对齐成一个统一的特征张量是数据管线里第一个需要认真设计的模块。2. 数值模式的输出怎么从“参考场”变成“特征场”很多做AI气象的人容易忽略的一点是数值模式的原始输出不能直接当特征喂给模型。模式输出的格点数据和观测数据性质完全不同它有自己的系统性偏差比如特定区域温度系统性偏高、某些地形下的降水被过度估计。这些偏差如果不处理模型学到的会是一个“带偏见的映射”而不是真正的物理规律。我们项目中使用的数值模式数据是区域模式3公里分辨率的逐小时输出包含十几个物理量。起初我们直接把这些物理量按高度层堆叠作为额外通道和雷达特征拼接发现模型训练损失降到一定程度就下不去了验证集上的表现也很不稳定。排查了很久最后定位到两个问题。第一个问题是量纲和分布差异。雷达反射率基本在-10到75dBZ之间而温度可能是290K比湿可能是十几这些量在数值尺度上差了好几个数量级模型在梯度回传时会被大数值量主导小数值量的特征几乎学不进去。解决办法是分别做标准化不是统一的z-score而是按物理量的气候统计值做极值归一化让每个通道的分布都落在0到1的合理区间。这个改动很基础但对收敛效果的提升立竿见影。第二个问题是空间分辨率不匹配。雷达XY方向分辨率是1公里数值模式是3公里两者的格点无法直接对齐。我们试过最粗暴的双线性插值把模式数据重采样到1公里结果在山地附近出现了明显的“栅格感”边界处不连续模型推理出来的降水场也带着这种假纹理。后来改成先对模式场做保守重映射在模式原始格点上先做一层平滑再降采样到目标网格效果明显改善。做完预处理之后模式数据从“参考场”变成了真正能跟雷达特征配合使用的“特征场”。这一步看起来不起眼但它是整个AI预报系统能否收敛的基石。如果特征场本身有系统性偏差或者空间错位后面无论用什么花哨的网络结构都很难补回来。2.1 融合时的通道权重设计在特征拼接阶段我们还遇到一个问题观测特征和模式特征的贡献权重如何在网络中自动学习。如果只是简单拼接网络虽然理论上能自适应学习权重但在训练早期可能会让模式特征梯度主导导致模型过早收敛到一个次优解。我们的做法是加了一个轻量的注意力模块在通道维度上对雷达特征和模式特征分别做全局平均池化再经过两层全连接得到通道权重加权之后再进行拼接融合。这样做的效果是在晴空区域模式特征权重更高在强回波区域雷达特征权重更高模型自动学会“什么时候该信谁”。测试下来这个模块让CSI评分提升了约3%而这个增益在极端降水事件里更明显大概有5%到6%的提升。3. 模型怎么选在“预报时效”和“空间细节”之间找平衡模型选型这件事我们先后试过三种路线纯卷积U-Net、卷积LSTM、以及基于ViT的时序模型最后真正用起来的是一条混合路线。我想把这部分的思路捋一捋因为很多团队容易在模型选型上被人带偏追复杂结构结果能力和业务场景根本不匹配。第一种纯卷积U-Net结构简单训练快推理极快但它是纯空间模型没有时序记忆。用它做单帧外推还好一旦要预测未来2小时、每10分钟一帧一共12帧它就要么把前一帧的结果当成输入递归推理导致误差迅速累积要么直接预测全序列但这样学习难度会急剧上升。第二种卷积LSTMConvLSTM当时是很多短临预报论文的标配它把LSTM的门控机制搬到卷积特征图上能同时建模空间和时间。我们实验室阶段用ConvLSTM跑的效果确实比纯U-Net好尤其是回波的运动连续性上自然很多。但它的短板也很明显训练时间长收敛慢而且由于时间步是逐步迭代的推理延迟随预测帧数线性增长。而我们的业务场景对推理延迟有硬上限这就很难受了。第三种是基于Transformer的时序模型表征能力强但需要大量训练数据在小规模区域数据上容易过拟合。而且原始ViT的复杂度对高分辨率输入的友好度不高我们试过把输入切成patch来降低计算量效果还是比不上ConvLSTM稳定。最后我们落地的方案是**“编码器-时序模块-解码器”的混合结构**用U-Net风格的编码器把雷达和模式特征压缩到潜空间中间用ConvGRU做时序演化再用解码器逐步重建未来每一帧的降水场。这个结构比ConvLSTM少了输出侧的循环解码同时能利用U-Net的跨层连接保持空间细节推理时只需要一次前向过程延迟可控。实际测试下来这个混合结构在2小时预测时效内降水落区的位置误差比单用雷达外推降低了30%左右强对流单体的漏报率下降了14%。更重要的是推理延迟从ConvLSTM的每帧平均400多毫秒压缩到了整体300多毫秒满足了秒级预警的工程要求。3.1 训练数据的标签策略降水场怎么定义监督学习就得有标签气象预报的标签设计其实是个容易被低估的问题。我们的标签不是简单地把未来时刻的雷达回波拿来用因为雷达回波和实际降水量之间还有一层转换关系。我们用了两层标签策略第一层是反射率直接外推的回归目标即未来时刻的雷达反射率场。这一层负责让模型学会回波的运动和强度变化是对空间结构约束最强的监督信号。第二层是降水等级分类目标。把反射率通过Z-R关系转换成降水强度再离散成无雨、小雨、中雨、大雨、暴雨、大暴雨六个等级。这层信号让模型输出更贴合业务关注的风险等级而不是盲目追求像素级回归精度。训练时我们对两层损失做了加权组合回归用MSE分类用交叉熵两个损失的权重比大概调到0.6比0.4的时候效果最好。这个比例不是拍脑袋出来的我们做了消融实验发现如果分类权重太高模型会趋向于保守出暴雨导致误报增加如果回归权重太高边界的锐利度又不够。4. 从模型到预警工程系统里那些“看不见”的环节模型在离线实验里指标再好看放到生产环境里跑不起来也是白搭。我们这套系统的总体架构可以分成五层数据接入层、特征工程层、推理引擎层、后处理层、预警发布层。每一层都有坑我挑几个最有价值的点来说。4.1 推理引擎的延迟与并发设计我们的预警服务要求覆盖全域的格点预报每个时次输出的数据量大概在几千万个格点而系统需要支持多路并发请求包括不同城市的定制化预报。一开始我们用Python Flask直接加载模型做推理单路请求延迟还行并发一上来就崩。后来做了三方面的改造。第一把模型用ONNX导出绕开PyTorch的动态图开销推理延迟直接降了40%。第二把推理服务做成独立进程用消息队列接收预报请求模型GPU常驻避免每次请求都重新加载权重。这个改动带来的延迟下降比换模型结构还明显。第三批处理优化。多个城市的请求会在一个时间窗口内被合并成一个batch用CUDA的流并行处理整体吞吐量提升了近3倍。4.2 后处理从“模型输出”到“预警等级”模型直接输出的降水场是连续数值场不能直接当成预警发出去。我们需要经过一套业务化的后处理逻辑。首先是空间平滑。模型输出的降水场在边界处会有破碎的噪声斑块直接用会大量产生“虚警格点”。我们用了一个基于连通域分析的方法把面积小于设定阈值的孤立降水单体合并或者滤除破碎的噪声被清掉同时保留真正的强对流单体。这个后处理步骤让误报率降低了9%左右。其次是等级映射。根据降水强度、持续时间、影响面积三个维度把连续预报转换成分级预警信号。这里还接入了人口密度和地形数据比如同样的降水强度落在城区和落在无人山区预警级别会做差异化调整这是纯粹从业务需求出发模型本身不会关心这些。最后是概率化输出。我们没有直接输出“未来一小时会下暴雨”这种确定性结论而是输出“未来一小时某区域出现暴雨的概率超过70%”这样的概率表达。这样下游的决策系统可以自己设定阈值适配不同场景的敏感程度。4.3 融合策略宁可保守也不能激进融合数值模式和AI预报的输出时我们一开始设计的加权规则是动态的想让AI预报在短时效占据主导数值模式在长时效逐渐接管。但实测下来发现一个尴尬的情况在2小时边界附近AI预报的误差已经比较大数值模式也还没完全进入稳态两边都在“乱说话”。后来我们改成了保守的突出置信度的融合策略计算每个格点上两种预报的置信度只有当AI预报的置信度高于某个阈值时才让它主导否则回退到两者的加权平均。这个阈值的选择我们是通过验证集上的POD命中率和FAR误报率权衡之后定的。牺牲了大约4%的高降水预报命中率换来了23%的误报削减对于预警业务来说这个交换完全值得。毕竟预警发多了会“狼来了”一次误报造成的信任损失远大于一次漏报。5. 踩过的几个具体坑排查链路与修复过程工程系统的价值往往体现在踩坑之后的修复速度上。我挑三个印象最深刻的坑把完整的排查过程写出来供后来者参考。5.1 雷达数据的时间戳偏差第一个坑出在数据接入层。我们的雷达数据接入和格点化处理模块上线后有一次模型在连续两天的验证集上表现大幅波动一开始我们怀疑是模型过拟合后来逐步排查发现部分雷达站的数据时间戳存在最多约40秒的随机偏差。单独看每帧数据这个偏差不影响单帧使用但当多部雷达拼网的时候不同雷达之间会有最多2到3分钟的对不齐窗口拼出来的回波场在交界处会出现明显的“双核结构”。排查链路是验证集指标回退一帧一帧对比模型输出与真实观测发现交界处回波强度异常偏高然后回溯到格点化模块打印每部雷达的输入时间戳发现偏差。修复方案是在数据接入层增加基于交叉相关的时间对齐校验以中心雷达为基准把边缘雷达的时间戳对齐到统一参考系。修复之后验证集指标立刻恢复到正常水平。这个坑给我的教训是在AI气象项目里数据质量问题的排查优先级永远高于模型调参。很多指标异常根因根本不在模型而在数据管线上。5.2 格点坐标的投影不一致第二个坑更隐蔽。我们有一个分析模块用到了不同来源的静态数据包括高程数据、土地利用类型、人口密度它们的空间投影参数据说都是统一的Web Mercator。直到有一次看到模型在特定山区出现了持续30小时、落区固定的虚警我们才开始怀疑空间对齐。排查发现那个区域的雷达反射率格点是用Lambert投影生成的而高程数据是EPSG:4490的经纬度投影跟雷达格点的Web Mercator混在一起用。虽然数值上偏差只有几十米到几百米在低分辨率下看不出来但在山区地形梯度大的区域几百米的错位就能导致模型把地形特征和降水特征错误关联产生固定位置的虚警。修复过程是重写了静态数据的投影转换模块统一转成雷达格点的投影和分辨率并在数据版本更新时增加投影一致性校验。这个过程也提醒了我做多源数据融合的项目必须把投影转换当作数据接入的一部分而不能依赖“应该是对的”这种假设。5.3 模型漂移与定期重训第三个坑发生在系统上线运行两个月后模型的预报评分开始缓慢下滑。一开始以为是季节变化导致的数据分布漂移因为从春季到夏季降水系统的性质确实在变。后来仔细对比发现除了季节外的确还有一层问题我们的观测数据源有一批自动站设备在两个月内陆续升级了传感器回传数据质量和技术参数有微妙变化。这些变化导致整体训练数据分布发生偏移但模型不会自动感知。修复方案是建立了一个自动化监控流程每天对比模型预测值和实况观测的误差分布一旦发现连续多日误差超过阈值就触发增量重训练。增量训练用最近三十天的数据加之前的基础数据做混合既保证对最新分布的学习又不会完全遗忘旧的物理规律。目前这个流程已经稳定运行了几个月模型的长期漂移问题基本被控制住了。6. 这套方案实际跑起来效果到底怎么样项目上线至今我们对自己的系统做了一次较为全面的效果评估。评估期横跨一个完整的强对流多发季跟传统的光流法雷达外推基准做了对比这里列几个有代表性的数字。在0到1小时预报时效内我们的模型对强降水的CSI评分比光流法基准提升了18%1到2小时时效内提升了26%。从空间位置误差来看2小时时效的降水落区中心平均位置误差比基准减少了大约3.2公里。对于短临预警业务来说这个差距就意味着从“知道这片要下雨”到“知道这片大概在什么时候下、下多大”的区别。在预警服务层面我们实现了分钟级自动化预警生成。从雷达数据到达、模型推理完成、后处理生成预警文本到推送到相关平台全链路耗时平均在1分钟以内相比过去依赖预报员手工分析的做法时效提升了大约一个数量级。还有一个在业务方那边反馈比较好的点概率化输出带来的灵活性。他们对接了不同场景的阈值策略比如大型户外活动对暴雨风险比较敏感会把概率阈值设低一些宁可多预警几次而电力巡检对这种预警比较被动会设更高的阈值避免频繁出动。同一个模型输出因为有了概率维度能够适配不同的决策偏好。这点在设计之初没有被充分预见到算是意外收获。7. 补充一点实操经验数据版本管理和实验记录我不太清楚你们的团队现在是怎么管理数据和实验的但在这个项目里数据版本管理差点成了我们的短板。早期我们经历过一次非常惨痛的教训跑了一周的模型训练结果调模型调了半天发现之前的数据集在预处理时被人改了一个参数整个评估过程全部作废。我们后来搭建了一套轻量化的版本管理方案所有进入训练管线的数据文件都带一个内容哈希标识数据集的构成用一个专门的配置清单文件描述。任何人要改预处理逻辑或者数据源必须先改配置清单系统会检测到版本变化并且对训练日志自动打上版本号。这样每次实验都能追溯到具体的数据版本和代码版本复现和排查的效率提升特别明显。实验记录方面我们用的是最基础但非常有效的套路每个实验跑完自动记录包括数据版本、模型结构、超参数、损失曲线、验证指标、推理延迟、显存占用在内的完整信息并按照实验日期和目的生成编号。到项目后期这个实验库成了团队决策的依据很多争论最后都是靠翻实验记录来解决的比靠记忆靠谱得多。8. 下一步还能往哪走融合的深度与更细粒度的落地这套系统跑通以后团队内部也经常讨论后续的演进方向。我个人比较看好的一个是把预报的细分环节进一步拆开比如在极端降水场景下单独做强度订正另一个是在局地气候特征明显的小区域做模型微调让通用模型适配特定区域的天气系统特点。气象问题的一个特点是全局最优解和局部最优解往往不一致通用模型和区域专用模型的结合比一个模型打天下的效果更好。还有一个方向是把更多新型观测数据引入融合框架比如闪电定位数据、风廓线雷达、GNSS水汽观测这些数据的时间分辨率和物理意义各有侧重跟现有数据源形成互补。如果数据接入和特征工程做得足够扎实这些数据预计会显著改善强对流触发时刻的预报而那恰恰是当前短临预警中最困难的环节。对我们项目本身来说我目前最想优化的是融合策略里置信度判定的精细程度。现在的置信度是模型不确定性估计加启发式规则未来如果能把集合预报的不确定性也引入进来实现三源融合我有信心在维持低误报率的前提下把漏报率再往下压一压。这些想法项目里已经在开始验证了等有阶段性成果我再单独写一篇来分享。