企业官网建设流程全解析

做了好几年气象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 问题排查速查表

我把日常运维中容易遇到的现象、排查方向和应对措施整理成一张速查表，给团队新同学用起来非常方便。

6. 影响范围与后续扩展

整套系统上线后，对短临预警业务的改变不是简单的“多了一个工具”，而是在工作流里真正切进去了一段自动化环节。过去预报员每6分钟就要盯着雷达图做主观外推，现在系统自动给出未来2小时的逐10分钟预警建议，预报员更多时间用来分析天气情势、评估模式不确定性、与上级台沟通。尤其在城市内涝、大型活动保障这类对时间敏感的场景，提前10到20分钟的有效预警能争取到非常宝贵的处置窗口。

后续扩展方向上，我目前在做两件事。第一是把区域数值模式升级到公里尺度快速更新循环，让模式场本身的空间分辨率不再成为瓶颈，同时继续优化时滞编码，让融合算法对模式更新节奏更鲁棒。第二是引入更多非传统观测数据，比如闪电定位、卫星云顶温差、雨滴谱仪，这些数据对强对流的新生和增强有很好的指示作用。多模态的含义不应该停留在算法结构上，数据源的丰富程度往往是模型上限的真正决定因素。

在工程组织上，我们也开始尝试用AI编程工具辅助数据管线的代码开发和调试，把一些重复性的插值、批处理脚本交给智能体生成，再人工审查。实测下来，纯手工写的管线代码缩水了大约30%，但质量门槛一点不能降，所有生成代码都要过完code review才允许合入。这个节奏对我们这种小团队比较友好。另外，模型本地部署方面也在探索模型轻量化方案，考虑用蒸馏和量化把模型压到适合在边缘节点运行的水平，方便在地市一级的服务器上做私有化部署。

回到最开头那句话，AI气象预报的工程实践，真正的门槛其实在统筹。你需要同时懂一点气象、懂一点深度学习、懂一点数据工程，还要知道怎么和预报员沟通业务需求。这个项目走到现在，最大的收获不是模型指标涨了多少，而是团队所有人都意识到：模型只是决策链路的一环，数据、阈值、监控、人机协同，哪个环节掉链子，整个系统都会翻车。如果你也在做类似的预报预警项目，我的建议是先把数据和监控做扎实，再谈模型，这个顺序永远错不了。