DeepMind WeatherNext:数据驱动气旋预报的评估与落地指南 DeepMind 的 WeatherNext 模型在气旋预报上带来的进展值得做气象 AI、防灾预警和数据分析的人认真看一遍。过去做热带气旋预报主流程是数值天气预报用超级计算机求解大气运动方程组耗时高、成本高在路径突变和强度快速增强时往往不够及时。WeatherNext 这类数据驱动模型换了一条路直接基于历史再分析数据和观测学习大气状态如何随时间演化在更短时间里给出下一步天气场再从中提取气旋路径、强度和生成信号。对读者来说最关键的不只是“准确率提升”这种话而是它把预报链条拆成了可复现、可验证的几个环节数据、模型、追踪、评估。下面按实际落地顺序拆一遍。1. 先判断它到底是在预报什么气象场、气旋路径还是强度1.1 数据驱动天气模型到底在做什么很多刚接触 AI 气象预报的人会误以为WeatherNext 这类模型的输出就是“明天某个坐标会生成气旋”“路径会往哪走”。实际上不是。数据驱动天气模型的原始输出通常是一组未来多个时刻的气象场变量比如 10 米风场、海平面气压、不同气压层的位势高度、温度、湿度和风。模型先学习“当前大气状态如何演变成未来大气状态”气旋路径、强度、生成这些结论都需要在预测出的气象场里进一步提取。这一点决定了你后面怎么做验证。如果只把模型输出的某个区域最小值当作气旋中心路径误差会很大。更稳妥的做法是先看模型对海平面气压场和风场是否给出合理的大尺度结构再用追踪算法从预测场里找气旋中心然后连成路径、估算强度。如果材料里只给了一个“突破”标题没有说明实验设计你需要先搞清楚这个突破到底来自“中间气象场更准”还是“下游追踪模型更好”两种来源的含金量和可复用性不一样。1.2 气旋预报为什么比普通降水预报更挑模型热带气旋在不同海域有不同的叫法西北太平洋叫台风大西洋和东北太平洋叫飓风印度洋和南太平洋叫气旋但物理本质是同一类强对流系统。这类系统体积小、能量集中、变化快对模型的时空分辨率非常敏感。气旋预报的难点集中在几个地方中心定位气旋中心在海平面气压场和风场里有明确特征但网格分辨率不够时中心容易被平滑掉。路径变化路径主要受大尺度引导气流影响72 小时以内通常可预测但出现转向、减速、登陆前突变时误差会迅速放大。强度变化强度预报比路径更难尤其是快速增强过程往往在 24 小时内最大风速大幅上升AI 模型如果训练目标偏向平滑误差很容易低估这种极端变化。生成预报一个热带扰动什么时候发展成气旋是概率问题需要很多个例才能验证。所以评估 AI 天气模型不能只看全局平均误差。一个模型在温带大尺度天气上表现很好不代表它在气旋个例上可靠。标题里强调“气旋预报”说明实验很可能针对热带气旋做了单独验证这一点比普通天气指标更重要。1.3 适合谁读、需要什么基础这篇内容适合三类读者做气象 AI 算法的人想理解如何从论文走到可评估的实验流程。做气象数据产品或防灾预警系统的人想知道 AI 预报结果怎么和业务对齐。想做复现实验的学生或研究工程师需要一套从数据准备到评估的稳妥路径。基础要求不算高。你不需要成为数值天气预报专家但要熟悉经纬度网格、netCDF 或 GRIB 格式、Python 基本操作以及知道气旋不是天气场里的单点而是从气象结构中识别出来的系统。如果你没有这些基础建议先把数据读取、画图、切片这些基本功过一遍否则后面很容易卡在数据维度上。2. 想验证模型能力先把数据源和评估口径搞对2.1 再分析数据从公开的再分析数据开始AI 天气模型训练和验证最常用的数据是再分析数据。再分析数据是观测资料和数值模式通过数据同化融合出的历史大气状态常见的有欧洲中期天气预报中心的再分析产品。它不像实时观测那样有大量缺测时间连续、变量丰富适合做模型输入和验证基准。实际使用时要特别注意几点空间范围先不用下载全球。做气旋实验可以先按目标海域划一个子区域减少存储和读取开销。时间范围根据你要验证的气旋个例只下载起报时间之前和验证时间段内的数据。变量范围至少要包含海平面气压、10 米风分量以及模型要求的多个气压层的位势高度、温度、湿度、风。时间分辨率最好是 6 小时间隔。这不仅匹配多数最佳路径数据的记录频率也方便逐 6 小时追踪气旋路径。再分析数据的版本会随时间更新不同版本之间数值有差异。材料里没有给出固定版本所以落地时先确认你用的数据版本和模型训练数据版本是否一致不一致时结果可能有偏差。2.2 气旋最佳路径和强度记录验证气旋预报不能只靠再分析数据里的最大风速。气象界有专门整理的历史气旋最佳路径数据比如 IBTrACS。它记录了每个历史气旋逐 6 小时的中心位置、最大风速、中心气压、生成时间和消散时间是全球多个机构资料的综合产品。使用 IBTrACS 时有几个细节不同机构对同一气旋的强度估计经常不一致最大风速可能差 10 到 20 节。评估时最好固定使用同一机构的数据作为基准。IBTrACS 里的中心位置和再分析数据里的最低气压中心并不总是完全重合因为观测和网格投影存在误差。如果你只验证西北太平洋的台风可以用区域性的最佳路径数据但要注意字段命名和经纬度精度。我建议把最佳路径数据单独存一个表格包含时间、纬度、经度、最大风速、中心气压。后面批量评估时直接按时间匹配模型输出避免反复解析原始数据。2.3 变量、空间分辨率和时间步长模型输入通常是一组按固定顺序拼接的变量。不同项目对变量名、单位、层级的要求不一样但核心变量基本一致10 米经向风、10 米纬向风、海平面气压、多个气压层的位势高度、温度、相对湿度、纬向风和经向风。做气旋评估时我最在意的两个变量是海平面气压和 10 米风。海平面气压用来找低气压中心。10 米风用来估计气旋强度和风圈范围。如果时间步长是 6 小时一次 120 小时的预报就需要连续推理 20 步。每一步都会引入一点误差最后一步的误差是累积的。评估时不要只报“120 小时路径误差”要分 24、48、72、96、120 小时分别看才能知道误差是在前期快速放大还是稳定增长。2.4 提前时效和验证窗口气旋预报的核心价值在于“提前量”。48 小时的路径预报和 5 天的路径预报对防灾决策的意义完全不同。评估时一定要把结论按提前时效拆分不能混在一起算一个平均值。还有一个容易被忽略的问题数据泄漏。AI 天气模型是用历史再分析数据训练的如果你拿训练时间段内的气旋个例去做验证模型相当于见过答案结果虚高。正确做法是先确认模型的训练数据截至时间再把验证个例选在训练时间范围之外或者至少说明这个限制。如果材料没有给训练时间范围你要自己去查模型说明不要默认所有时间段都安全。3. 从架构上理解 WeatherNext 这类模型为什么能用于气旋预报3.1 用图神经网络或 Transformer 处理球面网格气象数据天然在球面经纬度网格上但普通卷积神经网络处理这种网格有问题经纬度网格在赤道附近接近均匀越靠近极点相邻网格点的实际距离越不均匀。如果直接把它当普通图片处理高纬度地区会被过度拉伸卷积核无法保持“空间平移一致性”。解决思路大致有几类图神经网络把网格上的点当作节点按球面距离连接相邻节点在图上做信息聚合。GraphCast 等模型是这类思路的代表已经在中期天气预报上表现出很强的效果。Transformer把网格点当作 token用注意力机制捕捉远程依赖。扩散生成模型从噪声开始逐步生成未来天气场适合做概率预报。像 WeatherNext 这类模型核心是一个“从当前大气状态映射到未来大气状态”的神经网络不管具体用哪种主干输入输出都是完整气象场。气旋预报真正依赖的是这个映射的质量。3.2 编码-处理-解码结构很多数据驱动天气模型采用类似的结构编码器把输入气象场压缩到潜在表征空间降低原始分辨率带来的算力压力。处理器在潜在空间里做多次迭代更新模拟大气状态的时间推进。解码器把潜在表征恢复到原始气象网格输出预测的气象场。这种结构有一个实际价值推理速度快。传统数值天气预报每推进一步都要重新计算物理方程组的数值解计算量大。数据驱动模型在推理阶段只是在做神经网络前向计算单次推理时间可以控制在秒级到分钟级。对气旋预警来说这意味着可以更频繁地滚动更新预报或者在同样时间内跑更多个例。3.3 训练方式与输入输出训练时模型看到的是多个时刻的再分析数据。比如给前 4 个时刻的气象场预测下一个时刻。训练目标通常是比较预测场和真实再分析场之间的误差。推理时如果要做多天预报就把上一步的预测结果当作下一步的输入不断自回归。自回归推理有一个天然问题误差累积。第一步预测的误差会进入第二步的输入后面每一步都会在已有误差上继续放大。不同模型对误差累积的抑制能力不同这就是为什么不能只看单步预测效果要看连续多步预报的稳定性。气旋路径中期预报需要多次自回归推理所以模型每步的微小误差都可能被放大成路径偏差。你在评估时要特别关注“多步滚动预报后气旋中心是否还保持清晰”如果预测几小时后中心被平滑掉后续路径追踪就会失效。3.4 低推理成本的价值WeatherNext 这类模型最值得重视的不是“它比所有模式都准”而是它在算力成本上有明显优势。传统中期预报模式要在超级计算机上跑数小时AI 模型只需要一块或几块 GPU 就能在较短时间内完成一次预测。低推理成本带来的是流程改变可以更频繁更新比如每小时滚动一次预报。可以跑更多扰动成员构建集合预报。可以在有限的资源里测试更多历史气旋个例。但不要把“单次推理快”等同于“整个评估流程快”。数据加载、变量拼接、气旋追踪、结果存档都可能成为瓶颈。我遇到过模型推理只要 5 秒但数据读取和追踪算法跑了 3 分钟的情况。评估时要把全链路时间都算进去。4. 单条样例先跑通从官方示例到指定气旋个例4.1 先准备环境、权重和依赖如果你拿到的项目是公开代码库第一步不是直接改参数而是把官方示例完整跑一遍。环境准备注意几点# 示例创建虚拟环境并安装依赖 python -m venv weatherenv source weatherenv/bin/activate # Windows 下用 weatherenv\Scripts\activate pip install -r requirements.txt依赖版本很关键。很多 AI 项目在 PyTorch、NumPy 版本变化后行为会不一样。如果发现问题先看 requirements.txt 里的版本和当前环境做对比。权重文件下载后要检查大小和完整性不要只看路径存在。GPU 不是必需但多步自回归推理最好有 GPU。气旋 120 小时预报如果按 6 小时一步要跑 20 次前向计算纯 CPU 很可能要等很久。如果你的机器显存不大先把输入分辨率或区域裁剪调小能跑通再说。4.2 用标准输入验证模型输出先用项目自带的示例输入测试。这一步不关心业务效果只验证一件事模型能加载、能推理、能写出正确维度的输出文件。判断标准很明确进程不报错。输出文件存在。输出数组的形状和预期一致。数值范围合理比如海平面气压在 900 到 1050 hPa 之间10 米风速不会出现天文数字。变量名、单位、层级顺序没有错误。如果这一关没过不要急着下载气旋数据。很多项目跑不通不是模型问题而是输入格式不对比如变量顺序按训练时约定你按自己的习惯拼接必然报shape mismatch。4.3 选定气旋个例和起报时间示例跑通之后再选一个真实气旋做验证。我建议第一个个例不要选强度快速增强的极端台风因为这类系统误差通常很大很难判断是模型问题还是气旋本身难报。选一个路径相对完整、移动比较规律、持续 5 天以上的历史气旋。比如西北太平洋某次有完整观测记录的台风或者大西洋一次中强度飓风。从 IBTrACS 里读出它的时间范围确定一个合适的起报时间最好选在气旋已经成型、还没开始大幅转向的阶段。准备输入数据时要注意时间对齐。起报时间之前的时刻能不能都有数据变量是否完整区域范围是否覆盖气旋后续移动路径这些都要提前检查。4.4 如何判断输出是否合理做出第一次预报后不要只看数字。把预测的海平面气压场和 10 米风场画出来看低气压中心是否清晰。我一般看 3 个点每个预报时刻的低气压中心是否存在。中心位置是否随时间连续移动而不是跳来跳去。中心气压和最大风速是否在合理范围内。如果模型把气旋中心平滑没了后面的路径追踪大概率失败。这不一定是模型没有能力可能是输入分辨率太低、变量没有包括风场或者区域裁剪把气旋的一部分切掉了。先调整输入再判断模型本身。如果 24 小时预报看起来方向对但位置偏了 100 公里这不算异常。AI 气象模型在单例上存在误差很正常。只有把多个个例放在一起统计才能判断模型有没有参考价值。5. 多时刻、多成员的回算评估气旋预报的稳定性5.1 为什么不能只看一个时刻单个气旋个例只能证明“模型能跑”不能证明“模型可靠”。气旋预报的难点在于不同个例差异巨大有的路径笔直有的突然转向有的强度缓慢增强有的 24 小时快速增强有的在登陆后迅速消散有的还在近海维持强度。要评估一个模型是否取得“突破”至少需要 10 到 20 个历史气旋组成回算集并且覆盖不同海域、不同强度、不同季节。数量越多越好样本太少时一个极端个例就能把平均值拉得很高或很低。回算集设计可以参考这张表维度建议覆盖范围原因海域至少两个有明显差异的海区不同海域的引导气流和海洋热力条件不同强度Saffir-Simpson 1 到 5 级都要有强台风和弱热带风暴的误差特征差异大路径形态直线型、转向型、近海型都要有转向个例最容易暴露追踪算法问题季节覆盖主台风季和过渡季节检验模型对大尺度环境场的适应性提前时效24h 到 120h 分档统计避免跨时效误差平均掩盖问题5.2 批量任务的输入列表和输出命名批量评估最容易乱在文件管理上。建议用一个 CSV 文件记录每个个例case_id,storm_name,basin,init_time,data_start,input_dir,output_dir T20220901,某台风,WP,2022-09-01T00:00:00,2022-08-30T00:00:00,/data/raw/...,/output/...输出文件命名必须带足够信息。我习惯的格式是forecast_{case_id}_f{lead_time_hours:03d}.nc例如forecast_T20220901_f024.nc表示这个个例起报后 24 小时的预测场。文件名里一定要有起报时间和有效时效否则后面统计时很难对应。不要一开始就全量跑。先跑 2 到 3 个个例确认输出完整、追踪算法能处理再放开批量。并发数不要一上来拉满先看 GPU 显存和内存占用逐步增加。5.3 集合成员和概率预报单次确定性预报只能给出“气旋可能走哪条路”不能给出“有多大概率走这条路”。业务上更常用集合预报用多个初始扰动或多个模型成员生成一组路径再用路径集合的离散度表示不确定性。AI 气象模型如果想做集合预报有两种常见方式用不同的初始场扰动生成多个成员。如果模型本身是生成式模型可以直接采样多个未来状态。但要注意能生成多个成员不代表概率信息可靠。判断概率质量要看可靠性图、Brier 分数、连续排位分数等指标。如果模型成员之间过于集中风险可能被低估如果过于分散预报没有参考价值。5.4 对比基线和显著性评估一个 AI 气旋预报模型必须和基线对比。常用的基线至少有三种持续法假定气旋按当前移动方向和速度继续移动简单直接。气候法用历史同类气旋的平均路径作为参考。传统数值模式比如业务中心发布的气旋路径数据。最推荐的做法是把 AI 模型输出和传统数值模式放到同一批个例、同一提前时效下比较计算路径直接位置误差和强度误差。不要只看平均值可以看误差分布、中位数、多少个例上 AI 更好。如果只是自己复现实验最终结果要和项目官方结果有差异这是正常的。评估口径不同、追踪算法不同、数据版本不同都会导致差异。你要在记录里写明自己的评估条件而不是直接声称“模型达到官方水平”。6. 跑模型常见问题数据、维度、资源和结果差异6.1 数据下载和磁盘问题做 AI 气象实验数据下载是最容易卡住的地方。全球再分析数据动辄几百 GB如果整球、全变量、多层级下载你的硬盘很快会被占满下载时间也会拖很久。解决办法是缩小范围只下载目标海域的子区域。只下载模型要求的变量。只下载起报时间前后需要的时间段。下载前先计算文件大小留足磁盘空间。下载脚本最好支持断点续传和完整性校验。我遇到过下载到 90% 中断文件看似存在但无法读取的情况。用校验和或者直接尝试打开数据文件能提前发现损坏。6.2 维度顺序、变量名和归一化不匹配这类问题在 AI 气象模型中非常常见报错信息可能是KeyError: u10 RuntimeError: shape mismatch ValueError: expected input to have 4 dimensions, but got 5遇到这些报错先不要怀疑模型坏了按顺序排查输入变量名是否完全一致比如u10和u_10m不是一个字段。变量顺序是否和模型要求一致有些模型要求u10, v10, sp, t2m你按自己习惯排了另一套。维度顺序是否一致是(time, level, lat, lon)还是(level, time, lat, lon)。单位是否一致风速是m/s还是knots气压是Pa还是hPa。归一化参数是否和训练时一致如果模型训练时做了标准化推理时也要用同一组均值和方差。我在调试时一定会先打印输入数组的形状和数值范围再和模型要求的输入对比。这一步能解决大部分启动失败。6.3 显存不足和推理太慢显存不足时第一选择是把 batch size 降到 1。如果还不足就缩小空间区域或降低输入分辨率。但降低分辨率会影响气旋中心定位精度评估时要固定分辨率不能调和不同分辨率的结果。推理太慢不一定只怪 GPU。常见原因有数据加载每次重复读大文件没有做缓存。每步推理后都写一个文件到磁盘IO 反而成了瓶颈。CPU 和 GPU 之间数据拷贝太多。建议先分析一次完整推理的时间分布数据读取多少秒、模型前向多少秒、后处理多少秒。先针对性优化最慢的部分再决定是不是要换更大显存的卡。6.4 复现论文数据差异很大时的排查顺序当你发现自己的评估结果和论文或官方报告差距很大时不要急着调模型参数。按照这个顺序排查先看输入数据时间范围、起报时间、变量集合是否一致。再看区域范围论文评估的是全球还是某海域你选的区域是否覆盖完整。再看评估方法论文用的气旋追踪算法是什么追踪器不同路径误差可以相差几十公里。再看验证样本论文选了哪些个例你是否用了相同时间段最后看模型权重版本是否相同预处理是否一致。很多时候差异来自评估口径。比如论文可能用 IBTrACS 的多个机构平均作为基准你只用了一个机构论文可能把中心位置做平滑你用的是原始网格最低点。这些都会造成结果不同。6.5 气旋自动识别和目标追踪的偏差从预测场里找气旋中心最简单的方法是找海平面气压最低点。但在近海和地形复杂区域最低压点可能不是气旋中心。气压场可能有两个相近的低压中心风场中心也可能和气压中心不重合。更稳妥的做法是在海平面气压场上找局部极小值。在 10 米风场上找风速极大值或环流中心。下一时刻搜索时限制在上一个中心一定半径内避免错误跳到相邻扰动。对路径做平滑但不掩盖明显突变。追踪算法会直接影响评估结论。在做 A/B 对比时必须保证所有模型用同一个追踪算法否则指标差异无法归因于模型好坏。7. 从实验到业务气旋预报真正落地还要解决什么7.1 预警阈值和“部分正确”预报的取舍AI 模型输出的是一张预测气象场不是一份可以直接发布的预警。预警要考虑路径是否进入警戒区域、强度是否达到阈值、影响时间是否在预测窗口内。实际业务中模型路径偏差 50 公里不代表不需要预警因为气旋影响范围往往远大于中心位置误差。具体落地时先定义规则。比如预测路径中心进入海岸线 300 公里警戒区就触发关注。最大风速有 60% 以上概率达到台风级别就启动应急流程。路径集合的 70% 分位数覆盖到某城市就发布预警信息。这些规则需要根据当地防灾要求调整。模型只能提供概率和路径集合是否预警是人定的决策规则。7.2 和传统数值模式结合现阶段比较稳健的做法不是让 AI 模型完全替代传统数值模式而是把它作为第二个预报源。AI 模型推理快适合高频滚动更新数值模式物理约束强适合提供长时间基准和初始场。两者结合时要避免给出互相矛盾的预警信息。可以先做一段时间的平行运行比较 AI 模型和业务模式在同一批个例上的表现再决定以谁为主。业务系统里最怕的不是某个模型偶尔不准而是不知道什么时候该相信哪个模型。7.3 版本更新和可复现性天气模型迭代速度很快。今天跑出结果的模型过几个月可能就有新权重、新预处理方式。如果不记录版本半年后回看统计结果你很难判断指标变化是模型改进、数据变化还是评估代码变化。建议在项目里建立配置文件记录model_version: 2025-06-01 dataset_version: era5_2024 tracker_version: v2 normalization: era5_stats_2025 eval_start: 2015-01-01 eval_end: 2024-12-31每个批量任务的结果目录里放一份这样的配置保留关键输出文件。这样任何一次评估都能追溯到当时的环境。7.4 业务部署的资源评估从实验到业务算力只是第一步。真正部署时还要考虑数据管道新观测数据多久能到达模型输入。推理耗时一次完整预报从数据读取到结果输出要多久。故障恢复任务卡住、显存耗尽、数据缺失时要能自动重试或告警。存储增长每天跑多个成员、多个时效输出文件会快速增长。如果每天要发布多次更新先用少量个例做压测统计单次全链路时间再估算全天负载。别只看模型前向那一小段数据准备和后处理经常占用更多时间。如果只是学习用公开示例跑通一两次理解架构和评估指标就可以了。如果要拿来做业务参考最该盯住的不是“叫什么天气模型”而是输入数据版本、评估口径、追踪算法和失败重试。踩过几次之后会发现很多问题不是模型能力不够而是前置数据和评测流程没有对齐。