转载于：原创 Clarmy Clarmy吱声 2023-07-24 19:45 发表于美国

根据华为盘古气象模型团队在 nature 发表的论文显示，其模型准确率已经超越了 ECMWF 的 IFS 模型，但是这些论文中的检验结果都是在人工构造的理想化气象场中（ERA5）进行的，而 ERA5 与真实观测场又是有差距的，盘古在真实观测场中的表现如何，一直以来都缺乏一些实测的报告或者文章介绍。得益于盘古气象模型团队将其模型开源，使我可以在自己个人电脑上搭建盘古气象模型进行预报检验具有了可操作性。因此我专门花了一点时间，来做了一个对盘古气象模型在真实观测场中预报的小检验，以观察其在真实气象观测场中的预报效果。

本测评的代码已在 Github 开源，任何人都可以根据仓库的说明文档在自己本机跑通，仓库地址（文末原文链接）：https://github.com/Clarmy/pangu-weather-verify

数据来源

本次测评的所有数据均来源于互联网上的公开数据集，且数据获取的方式合理合法、公开透明。本次测评抓取的数据跨度约 5 天，抓取的时间点为 ECMWF 的逐 3 小时预报点对应的时间点。

SURF 观测站数据

本测评将使用中国大陆地区在中央气象台网站(http://www.nmc.cn/)上公布的2000多个站点的观测数据作为检验的真值。观测站点信息来自于中国气象数据网(http://data.cma.cn/Market/Detail/code/A.0012.0001/type/0.html)，原始站点表格下载地址(http://image.data.cma.cn/static/doc/market/China_SURF_Station.xlsx)，在测评中站点列表（csv文件）对原始列表做了一些经纬度表示方法的转换，主要是将度分秒表示法转换为十进制表示法，以便于后续处理。数据获取方式是以爬虫的方式抓取中央气象台网站上的观测站点数据，受网络环境影响，在实际运行中抓取的数据无法保证100%完整，会有个别站点数据缺失，属于正常现象。

ERA5 再分析数据

我们使用的 ERA5 再分析数据作为盘古模型推理的原始输入数据。由于本次测评是以真实业务化运行的标准，而非实验室中的理想化场景来进行的，因此我们作为初始场输入盘古做推理的 ERA5 数据实际上是距离观测时间点向前推大约 5 天前的数据。

ECMWF 预报数据

ECMWF 的预报产品有多种品类，本项目使用的是其中对外免费公开的实时预报数据集，获取渠道可以参考ECMWF的文档说明(https://confluence.ecmwf.int/display/DAC/ECMWF+open+data:+real-time+forecasts)。本项目中 ECMWF 的实时预报数据作为盘古模型的对比预报数据（陪跑），用于对比盘古模型的预报效果。由于该数据集的空间分辨率为0.4°。因此在最终计算检验指标时，我们将其插值到与其他数据集一致的 0.25° 的空间分辨率。

GFS 预报数据

我们使用 0.25 度分辨率的 GFS 预报数据作为另一个陪跑的对比预报，GFS 的数据下载地址：https://nomads.ncep.noaa.gov/gribfilter.php?ds=gfs_0p25_1hr

测评指标

RMSE

RMSE(Root Mean Square Error)即均方根误差，是一种常用的预测结果误差评估指标。RMSE反映预测值与实际值偏差的均方差，它能很好地反映预测的整体准确性。RMSE值越小，表示预测结果整体误差越小，预测效果越好。

RMSE具有非负值、同量纲等特点，易于理解和解释。它既可以用于连续型预测，也可用于分类预测的误差评估。RMSE是机器学习中回归模型及时间序列预测常用的评估指标之一。总体来说，RMSE是一个简单直观而有效的预测误差评价指标。

误差阈值准确率

对于非二值化的预报要素，可以通过误差阈值过滤的方式来定义“准确”与“不准确”，进而再进行准确率的统计计算。误差准确率是对于误差在允许范围内计为“预报准确”，然后计算“预报准确”样本数与观测总样本数之间的比值。本次测评使用以下几个指标：

1、1°C准确率：气温预报与观测之间偏差在 1°C 以内的样本数占总观测样本数的比例。

2、2°C准确率：气温预报与观测之间偏差在 2°C 以内的样本数占总观测样本数的比例。

3、3°C准确率：气温预报与观测之间偏差在 3°C 以内的样本数占总观测样本数的比例。

4、1ms准确率：风速预报与观测之间偏差在 1m/s 以内的样本数占总观测样本数的比例。

5、2ms准确率：风速预报与观测之间偏差在 2m/s 以内的样本数占总观测样本数的比例。

6、3ms准确率：风速预报与观测之间偏差在 3m/s 以内的样本数占总观测样本数的比例。

风级偏强率/偏弱率

风级偏强为风力等级预报偏强次数与风力等级预报总次数的百分比。预报风力所在的检验等级大于实况风力所在的检验等级,则为风力等级预报偏强。同理，风级偏弱率为风力等级预报偏弱次数与风力等级预报总次数的百分比。预报风力所在的检验等级小于实况风力所在的检验等级，则为风力等级预报偏弱。

风速评分

风速评分是衡量预报风级与观测风级之间匹配程度的分值。其算法为：若预报与观测处于同一风级，则记1分；若二者为相邻风级，则记0.6分；若二者风级相差2级，则记0.4分；其余情况不得分，累加所有样本的评分后取算数平均值即为样本的风速评分。

风向评分

风向评分是衡量风向准确率的一个指标，风向评分使用风向方位（而非风向角度）作为基准进行评估。

·对于 8 分位风向，预报和观测风向方位完全匹配得 1 分，二者风向方位相差 1 个方位得 0.6 分，其余情况得 0 分。

·对于 16 分位风向，预报和观测风向方位完全匹配得 1 分，二者风向方位相差 1 个方位得 0.8 分，相差 2 个方位得 0.6 分，其余情况得 0 分。

本测评采用 8 分位风向进行评估。

测评结果

气温

盘古在气温上的测评结果相比于其他两个预报系统来说，具有比较明显的优势。具体来看，盘古气温的 RMSE 总体上是略优于 ECMWF 的，且比较稳定地优于 GFS。

1°C 准确率方面，盘古的结果相对于 ECMWF 有一个比较明显的优势，并且较为稳定地优于 GFS。但在 2°C 和 3°C 准确率方面，盘古相对于 ECMWF 的优势逐渐缩小，二者呈现一种势均力敌的状态，但稳定地优于 GFS。

风

盘古在风的预报方面就不那么尽如人意了，首先我们来看风速的 RMSE：

可以看到，盘古风速的 RMSE 在三个预报系统中基本是垫底的（越高越差），而 ECMWF 和 GFS 的却难分秋色，这一点似乎打破我们一直以来认为 ECMWF 稳定优于 GFS 的固有认知。

再来看 1m/s、2m/s、3m/s 误差阈值下的准确率：

可以看出，盘古的结果都还是比较明显地比 ECMWF 和 GFS 要差一些。

从风级的准确率来看，盘古的结果还是逊色于其他两个预报系统的。

再看风速和风向评分，盘古的结果依旧是不敌其他两个系统。

从风级的偏强和偏弱率来看，盘古应该是对风速倾向于低估，而 GFS 倾向于高估。

总结

总体来说，盘古的预报相对于 ECMWF 和 GFS 在气温上具有比较明显且稳定的优势，而在风相关的预报效果基本上全面逊色于其他两个系统，但其预报效果与其他两个系统也已经相当接近。另一个可能比较颠覆我们认知的是，一直以来认为 ECMWF 稳定优于 GFS 的认知似乎正在发生变化：GFS 在风预报上的表现已经与 ECMWF 不相上下了。

对盘古的一些主观评价

虽然依据上述的测评，在真实观测场中并没有重现盘古全面优于 ECMWF 的效果。但我们也要知道这是在盘古使用的是 5 天前的 ERA5 数据作为初始场的条件下得到的结果。也就好比说是百米赛跑，ECMWF 和 GFS 先跑 40 米，结果最后三个人几乎同时撞线，这也侧面反应了盘古恐怖的实力。以下是初始场与观测场时间间隔对比图：

由于我是从一个实用角度出发进行的这个测评，所以不可能像论文里做的那样排除所有数据时效性问题，在完全理想化的情况下做测评。从某种程度上来说我的测评可能对盘古来说是不公平的，但这却是具有现实意义和可操作性的。如果把盘古比作在学校里是一个超级大学霸，那么它早晚有一天需要走出校园面对真实的世界，而这真实的世界绝不可能处处公平一样。

虽然盘古在真实观测场中的预报效果并没有论文中那么完美，但我认为盘古具有非常大的工程价值：

1.运行效率高，我在做这个测试时，用个人电脑 CPU 跑单次推理大概 4 分钟，由于是 5 天前的初始场，所有需要迭代推理大概 7-8 次左右（例如 115 小时时间间隔的推理过程：24 -> 24 -> 24 -> 24 -> 6 -> 6 -> 6 -> 1），一共消耗约 30 分钟左右。如果是做业务化运行，我们可以通过一些排列组合的技巧把推理过程并行，例如我先用一个初始场跑出未来 24 小时的预报场，用这 24 个预报场同时使用 24 小时模型进行逐日推理，那么在核数足够的情况下理论上每 4 分钟就可以预报出1天24小时的预报。未来 10 天的逐小时预报用 40 分钟左右就能生成，当然如果再使用 GPU 对单次推理加速，那么速度可以更快。如果真的像论文中那样用顶配来做推理，把速度压榨到极限那么就可以在 2 分钟之内做出 10 天逐小时预报，并且预报效果还不比数值预报差太多。

2.运行环境搭建极其简单。盘古模型的运行是真的非常傻瓜式，不需要很多的配置，一个对 Python 熟练的开发人员完全可以在半个小时内就搭建一个可以跑通的盘古预报系统。相比于 WRF 那种极其复杂的环境配置来说，盘古简直就是工程师的福音。

3.没有预报上限。盘古的推理机制是使用上一次推理的输出作为下一次推理的输入，因此理论上可以无限推理下去，而不像 ECMWF 和 GFS 那样只能预报有限时长。这种特点对于工程师的一个极大的好处是，可以解决“预报焦虑”，也就是说盘古可以作为一个可靠的兜底预报在其他预报产品不可用的时候随时顶上，它可以顶替短时预报、短期预报、中期预报和长期气候预测。也就是它可以作为一种全周期的兜底预报产品来保证产品的可用性，这种特性对于长期忍受上游数据稳定性折磨的天气类 APP 来说简直就是救世主一样的存在了。

4.可以做集合预报，生成大量成员。盘古的灵活推理机制结合其高效的运算效率，允许你做大量扰动预报，比如说我们不遵循官方推荐的先长后短的推理过程，用一种随机的组合方式进行推理迭代，那理论上就可以生成大量扰动预报结果，基于这些结果我们可以做一些集合预报的统计分析，比如说做概率预报等。此外，我们还可以不遵循官方推荐的 ERA5 作为初始场，使用 GFS 的初始场作为输入，也可以生成新的预报成员。当然，如果有条件的话，还可以使用中国自己的 CRA-40 再分析场作为输入，这样就可以生成更多的预报成员了。

5.可以作为模式后订正的基本场。现在模式后订正几乎是每一个气象工程师的必修课了，市面上大量的“自主研发”预报产品其实绝大多数都是这一类模式后订正的产品。过去的后订正会非常依赖 ECMWF、GFS 这种数值预报作为订正的基本场，但是有了盘古的加入，就可以又多一个用于研究后订正的基本场了。 虽然盘古模型在工程上能给行业带来上面这些诸多的好处，但是目前来说盘古模型的应用还是有一些局限性的：

1）.预报变量少，地面预报只有气温、海平面气压、风这三个连续性要素，缺少降水，甚至连湿度都没有，高空预报的输出倒是挺多，但是高空的要素对于终端用户来说并没有什么太大作用，对于预报员辅助预报倒是可能会有一些帮助，但是如果盘古不是设计用于端到端预报的话，那它的意义也就不大了。

2）.开源协议限制，盘古模型的开源协议是 CC BY-NC-SA 4.0，这种协议禁止商用（NC: No Commercial）。并且这种协议对于衍生作品也有一定的限制，如果你想基于盘古模型做一些衍生的工作，那么你的衍生作品也必须遵循同样的协议，这对于大部分商业公司来说是不可接受的。所以如果气象科技公司都严格遵守盘古的开源协议，那么盘古气象模型在商业市场几乎就没有立足之地了。 我觉得盘古最难能可贵的是，研发团队敢于把模型开源出来让大家使用、测试和检验，体现了他们的自信和开源精神，值得肯定和学习。

FAQ

1.为什么不用 ECMWF/GFS 的初始场作为盘古的输入场而是用 5 天前的 ERA5 作为输入？

最开始我是想用 ECMWF 每次预报的初始场作为推理的初始场的，但是 ECMWF 公开的数据集中每次预报的初始场并不能满足盘古初始场的维度要求，盘古的初始场高空最高达到 50 hPa，而我能拿到的公开的 ECMWF 的初始场最高只到 200hPa，如果使用外推插值我认为会对结果产生不利影响，因此选择牺牲时效性来保证准确性。而至于为什么不用 GFS，因为根据盘古研发团队的建议应该使用 EC 系的数据才能体现盘古的优势，所以一开始就排除了使用 GFS 作为初始场的选项。

2.中央气象台网站上的气象数据，不是根据省市县查询的吗？为什么能和气象站号对应上？

中央气象台网站后台的 API 系统的规则是用气象站号来查询的，在抓包的时候只需要知道气象站号即可查询，详细的过程可以参考开源仓库：https://github.com/Clarmy/pangu-weather-verify。

3.如果检验的时间点是按照 ECMWF 的逐 3 小时预报点来的，那么盘古的预报时间点是怎么对齐的？

由于我并不想因为时间插值引入更多的误差，因此虽然 GFS 和盘古都是（或可以是）逐小时预报，但我还是以 ECMWF 公开的 3 小时预报作为基准。这个时候对于盘古来说会有一个情况，也就是说在这 3 小时间隔中，ERA5 会有新的时次的数据发布出来，因此盘古可以在三小时中做三次不同结果的预报。出于一种现实最差情况的模拟，我使用的是盘古第一次做的预报结果来做的评估，而 3 小时间隔中新补充的 ERA5 的预报是被我舍弃的。