一个天气模型靠不靠谱最直观也最难回答的问题就是它过去说过的话到底兑现了多少。看到 Show HN 上这个项目的标题——Ranking weather models by how their forecasts turned out——我第一反应是它做了一件看起来很朴素、实际上很多人想做却没坚持做下去的事情把模型过去发布的预报和后来真实发生的气象实况对一下账然后按兑现程度给模型排名。这个思路本身不难理解。但真正做过气象数据处理的人都知道从“生成一份预报”到“证明这份预报值得信赖”中间隔着的不是公式而是大量容易被忽略的数据工程问题。这篇文章我想沿着这个标题展开既说说这类排名项目为什么值得关注也聊聊如果你想自己搭一套类似验证流程最容易踩坑的地方在哪。1. 按结果给天气模型排名背后其实是一套“预报检验”逻辑1.1 这个项目到底在做什么先明确一下项目要解决的问题。气象领域有大量数值天气预报模型它们每天都在生成对未来几天、十几天的天气模拟。但模型之间差异很大有的擅长温度有的擅长降水有的在大尺度环流上更稳有的对局地天气更敏感。普通用户不会去看模型原始输出看到的是各家天气 App 加工后的结果。问题在于怎么知道哪个模型更值得信最直接的办法就是回访。把模型几天前发布的预报拿出来和实际观测到的天气做比较计算偏差、命中情况然后按不同变量、不同时效、不同区域统计成绩形成排名。这个项目做的工作本质上就是把“预报验证”这件事自动化、公开化、持续化。比起一次性研究论文它更像一个持续运转的评价系统每隔一段时间就更新一次“哪个模型近期表现更好”。这背后的方法论在气象业务里有一个正式名字叫预报检验也就是 forecast verification。它不是简单的“准/不准”二分法而是一整套用于量化预报质量的技术体系。1.2 为什么说“按结果排名”不是一件天然容易的事看到这里你可能会想天气预报准不准等天气发生了对比一下不就知道了吗实际没有这么简单。原因至少有三个。第一天气本身不是只有一个“真相”。同一个时刻不同观测站测得的数据不同雷达观测、卫星反演、气象站自动观测、再分析资料可能给出略有差异的“实况”。你拿哪套实况来对会直接影响排名结果。第二预报并不总是单点确定值。现代模型越来越多地使用集合预报也就是给出多条可能的天气演变路径。这种情况下“准不准”不再是“报 25 度实际 24 度”这种一个点对一个点的问题而是要问模型的概率分布是否和实际发生的频率一致。第三时效不同、变量不同模型的强弱可能完全不同。一个模型可能在第 1 到 3 天表现优秀到了第 7 天就明显漂移可能在温度上很准在降水落区上却系统性偏西。如果不做拆分只看一个综合排名信息会被稀释。所以一个真正有价值的天气模型排名背后必须有一套完整的统计口径和工程流程。这个项目之所以值得关注不是因为“排名”这个点子新鲜而是它尝试把一套复杂的检验逻辑做成一个普通人也能看懂、也能定期更新的系统。2. 为什么“昨天准不准”不能简单用一句话回答2.1 确定性预报的常用评价方式最常见的天气预报形式是给出一个确定值比如“明天最高气温 28 度”。评价这种预报基础指标是误差也就是预报值和实况值的差。但把误差直接平均会出现正负抵消的问题。比如一段时间内第一天预报偏高 2 度第二天偏低 2 度简单平均下来误差是 0看起来完美实际上两天都不准。所以气象业务中常用均方根误差RMSE或平均绝对误差MAE这类非负指标。RMSE 对大误差更敏感如果某一天预报偏差特别大RMSE 会明显升高MAE 则更接近普通人对“平均差多少”的直觉。对于分类类预报比如“有没有降水”“是否出现大风”则需要看命中率、空报率、漏报率和 TS 评分等指标。假设预报有雨实际也下了雨叫命中预报有雨实际没下叫空报预报没雨实际却下了叫漏报。单独看命中率不够因为一个“永远预报下雨”的模型命中率可能很高同时空报率也极高。要综合衡量就要用到在业务里很常见的 TS 评分Threat Score它同时惩罚空报和漏报。任何一个“天气预报准不准”的问题背后都可以拆解成这些具体指标。排名榜单如果只显示“第 1 名某个模型”却不说明它是在哪个指标、哪个时效、哪个变量上赢的那这个榜单的参考价值就有限。2.2 集合预报和概率预报的检验逻辑现在的数值天气预报尤其是中长期预报越来越多地采用集合预报。它不再只给出一条确定的天气路径而是给出几十条带有扰动的模拟路径然后统计概率。比如某个模型有 20 个成员其中 15 个成员预测明天有雨那么模型给出的降雨概率大约是 75%。评价这种预报需要回答两个问题可靠性当模型说概率是 75% 时实际真的下了雨的比例是不是也接近 75%分辨率模型能否把“大概率下雨”和“小概率下雨”的情况有效区分开最常用的一个指标是 Brier Score布里尔评分它计算概率预报和实际发生结果的平方差。概率越接近 0 或 1说明越确定如果模型的判断和实际结果一致分数就越低。Brier Score 还可以进一步分解为可靠性、分辨率和不确定性三个部分能看出一个模型到底是因为“不够自信”得分差还是因为“过度自信”得分差。所以当你看到某个项目声称“按实际结果给天气模型排名”时真正值得关注的是它用什么口径去做这个比较。如果只比较确定性预报维度相对简单如果连概率预报也纳入进来那这个项目的复杂度就上升了一个量级。3. 如果你想自己搭一套模型验证看板先解决这四个工程问题假如你也想做一个类似的项目或者在公司内部搭建一套预报模型评价系统我的建议是不要从评分公式开始而是先把数据流转和口径对齐搞定。公式是现成的数据才是最容易出错的地方。3.1 数据时序永远不要用“未来观测”去验证过去的预报这个点听起来像废话但实际做的时候特别容易出错。模型预报文件通常包含“起报时间”和“预报时效”。比如 2025 年 6 月 1 日 00 时起报预报时效 24 小时那么它预报的是 6 月 2 日 00 时的天气。验证它的时候必须用 6 月 2 日 00 时的实况而不能用 6 月 1 日 00 时的实况。更隐蔽的错误出现在数据处理环节。有些数据源的文件名里同时包含起报时间和时效如果你在合并数据时搞混了“文件名时间”和“文件内字段时间”就会出现用同一天数据验证同一天预报的问题。这种错误会导致验证分数异常好看因为模型“看到”了未来数据。我自己做类似验证时第一步永远是先随机抽取几条记录人工核对“起报时间 时效 验证时间”这个等式。如果等式不成立后面的一切评分都没有意义。注意没有时间对齐的验证分数越高越可疑。遇到异常优秀的模型先检查是不是把实况和预报的时间弄重复了。3.2 空间对齐格点预报不能直接和站点实况比数值模型的输出是格点数据全球模型通常以几十公里甚至一百多公里为分辨率。而地面观测站是离散的点。把格点预报和站点观测放在一起比较必须先解决插值问题。常见做法有三种双线性插值把站点周边四个格点的值加权平均得到站点位置的预报值。最近邻点直接用距离站点最近的格点的预报值。简单但在地形复杂区域误差大。面平均以站点为中心取一个小网格区域做面平均再和站点观测比。能平滑掉部分局地噪声但也可能掩盖真实差异。还有一类更隐蔽的问题地形。在山地或沿海区域模型格点的平均海拔和观测站点实际海拔往往差别很大。一个格点的海拔是 800 米站点实测海拔是 200 米温度直接对比就会出现系统性偏差。这不是模型“不准”而是对比口径不对。所以一个排名系统如果要覆盖多个区域最好在排名详情里注明“该区域模型已做地形订正”或“未做订正”否则用户会很容易被表面数字误导。3.3 模型版本和滚动窗口排名的“记忆”要多长天气预报模型不是一成不变的。全球模型会定期升级改了物理参数、提高了分辨率、更新了同化方案。模型一升级旧版本的历史成绩和新版本的成绩可能就不具备直接可比性。排名系统因此要回答一个很现实的问题排名窗口是滚动 30 天、90 天还是从模型发布以来累积计算短窗口的优势是反映近期模型变化劣势是样本少一次极端天气事件就可能显著拉低某个模型的分数。长窗口样本更稳定但可能会掩盖新版本的真实表现。更合理的做法是同时提供短窗口和长窗口的成绩让用户自己判断。我建议至少同时展示三组数过去 30 天过去 90 天全部历史如果项目还能标记出模型的版本切换时间那就更完整了。关注排名的人除了看名次也要看这个模型是否刚经历过升级、统计区间是否跨越了版本切换。3.4 样本分布不能把所有天气“一视同仁”模型可能在晴好天气下很准在强对流天气下偏差很大。如果验证期间正好赶上连续的晴天排名会普遍偏高如果赶上几次台风或强冷空气某几个模型的分数会明显拉低。更严格的验证应该按天气过程或环流型分层。比如单独统计“有系统性降水过程的日子”和“无降水过程的日子”或者按高空环流型分类。这样做的好处是能回答一个更细致的问题这个模型到底在什么场景下更值得信赖。不过按天气过程分层需要额外的标注数据实现成本较高。如果项目刚开始做我建议先用“区域 变量 时效”三个维度做最基础的拆分天气类型分层可以放到第二阶段。4. 最小可行验证流程从“手工对比”进化到“自动评分”如果你准备自己动手搭一个类似的天气模型评价流程不用一开始就做成完整的公开网站。可以先按最小可行验证的路径走一遍把链路跑通再逐步增加功能。4.1 四步走选模型、拿实况、算指标、做展示第一步确定你要评价哪些模型和时间范围。不需要一上来就覆盖全球所有模型。可以只挑 2 到 3 个设定一个未来 30 天的滚动验证区间。第二步确定实况数据源。常见选择包括气象站点观测数据、卫星反演产品、再分析资料如 ERA5 这类公开再分析数据集。不同的实况数据源会得出不同的排名结果建议固定一个主要来源至少保证对比口径一致。第三步选指标。如果是确定性温度预报用 MAE 和 RMSE 就足够起步如果是降水预报建议同时计算命中率、空报率、漏报率和 TS 评分如果模型是概率预报再增加 Brier Score。第四步做展示。不需要花哨。一个简单的表格行是模型名列是指标再加上时间窗口和样本数已经比大多数“我觉得 xx 模型挺准”的说法负责很多。这四步走完你就拥有了一套最小闭环的模型验证流程。此后无论是增加模型、增加变量、接入更多实况源还是把每日更新自动化都是在已有框架上做增量。4.2 一个通用处理骨架不是项目源码下面这个示例描述的是这类验证流程的通用逻辑不是某个项目的实际实现。你可以把它当作梳理自己代码结构的起点。循环遍历每个模型 循环遍历每个起报时间 从模型输出目录中读取预报文件 根据“起报时间 预报时效”定位对应时刻的实况数据 对实况和预报做空间匹配插值或最邻近格点 计算该样本的误差指标并记录 汇总该模型在验证窗口内的平均指标 输出各模型对比表这里的核心步骤只有一个在时空匹配之前先建立一个全局索引让每条预报记录能快速找到对应时刻、对应位置的实况。实际项目中我会先把所有预报文件扫描一遍生成一个“时间 空间 变量”清单再去匹配实况。这样后续处理会省很多时间。4.3 如果排名结果不对劲按这个顺序排查预报验证项目里异常情况几乎一定会出现。比如某个模型连续 30 天成绩全线碾压其他模型或者某个模型突然从第一名掉到最后一名。遇到这种情况先不要急着下结论“这个模型变强/崩了”按这个链路排查先看数据是否完整。检查文件是否有缺失、近期模型是否还在更新、某个起报时间是否漏了数据。再看时间对齐。随机抽取 3 到 5 条记录人工核对“起报时间 时效”是否等于验证实况时间。再看空间匹配。检查插值是否越界、站点是否在模型格点覆盖范围内、高海拔区域是否出现异常对比值。再看指标口径。确认统计范围一致比如是否一个模型统计了全部 96 次起报另一个模型只统计了其中 50 次。再看极端事件。排除是否有极端天气拉低或拉高整体分数。把最大误差的那几天单独抽出来看看。这个顺序不是按重要性排列的而是按排查成本排列的。先看数据有没有再看时间对不对最后再怀疑模型本身。统计上看起来异常的模型成绩绝大多数时候都是数据链路上的问题而不是模型真的突然变好了或变差了。5. 这套打法真正改变的是什么把模型选择权交给实况5.1 适合谁不适合谁这类排名系统最大的受益者是三类人。第一类是气象服务或天气类应用的开发者。当你在自己的产品里接入天气数据源时面对多个模型不能只看数据源的采样频率和价格还要看它在你最关注的区域、变量和时效上到底表现如何。一个持续更新的验证看板能让模型选型从“拍脑袋”变成“看数据”。第二类是认真研究天气、但不想直接碰原始模型输出的爱好者。通过公开的实时排名可以快速判断当前哪个模型更值得关注在台风、强降水、冷空气等关键过程来临时应该优先参考哪一家的输出。第三类是气象业务人员。即便业务系统内部有自己的检验流程一个外部公开的第三方排名也能提供交叉验证的视角帮助发现内部验证可能遗漏的盲区。不适合谁呢如果你想用一个排名数字来决定“今天出门带不带伞”那这个系统并不能直接给你答案。排名反映的是统计意义上的长期表现无法替代针对单次天气过程的逐日判断。某一个模型排在第一名不代表它明天的预报一定是对的只代表它最近一段时间整体上更接近实况。5.2 长期维护这个系统还需要补哪些工程能力从“跑通一次”到“能每天自动更新”中间还隔着不少工程问题。如果这篇文章影响着你你也打算认真做类似系统下面这些能力会是瓶颈数据自动获取。模型输出和实况数据是否按时到达是否需要重试机制如果某一天数据没到排名是补跑还是跳过存储和版本管理。预报文件通常很大实况数据也在持续产生需要设计合理的存储目录和文件命名规范。异常警报。当某个模型连续 N 天没有新数据或者排名中出现异常跳变系统需要能主动告警而不是等用户发现。刷新频率。完全实时更新每天的排名需要消耗持续的计算资源。初期建议每天跑一次离线任务在凌晨低峰期完成重算。结果可解释性。光给一个排名不够每个模型名下方最好能展开显示样本数、天气类型结构、区域拆分这样才能防止用户过度解读。这套系统做到后期核心价值已经不只是“谁排第一”而是“为什么这个模型更好在什么条件下好这种好是否稳定”。5.3 回到一个更底层的判断天气模型是一个不断进化的系统。每个模型都会经历升级、参数调整、数据同化方案改进排名也会随之变化。正因如此单靠一次研究论文或一次评测榜单根本无法回答“那个模型更可靠”这个问题。只有持续地、公开地、按统一口径追踪模型的历史表现才能让模型生态里的参与者包括开发者、业务人员和用户都站在更客观的信息基础上做判断。这个 Show HN 项目给我最大的启发不是它用了多么复杂的算法而是它选择了一个足够朴素但足够重要的标准把预报结果拉出来和实际发生的事对账。对账的次数多了模型到底行不行就不需要靠宣传、靠口碑、靠记忆数据自己会说话。如果你也想做类似的事情不必把它想得多宏大。先从一两个模型、一个变量、一个区域开始把数据对齐做实把指标算对再慢慢扩展。天气预报的结论每天都在更新模型的真实水平也在持续变化。能长期把这个对账过程坚持下来的系统哪怕界面再简陋价值也比一次性评测报告高得多。