WeatherNext 抬高预测产品门槛:给 AI 产品创始人的“预测到行动”合同
WeatherNext Cyclones 发布后,创始人如何把概率预测连同校准、送达、行动阈值、人工责任与回退机制一起验收上线。
Google DeepMind 在 Nature 论文与一个完整飓风季的业务证据之外,又开放了 WeatherNext 2 和 WeatherNext Cyclones 的代码与权重。这次最醒目的结果很强:在 2023 至 2024 年历史气旋评估中,系统对路径、强度和风圈结构的三日预测,大致达到了领先替代方案两日预测时的误差水平。它的专用版本还在 2025 年以实时指导信息的形式进入了美国国家飓风中心的工作流程。
这不代表每场风暴从此都能固定多出一天。它表达的是:在相同误差水平下,平均有效提前量有所增加。它也不代表一个应用可以直接把 1,000 种模型情景变成自动疏散、进货、保险决策或客户通知。国家飓风中心把这套系统当作专家判断和正式预警流程中的一项输入,而不是自动发布预警的主体。
这个区别远不只适用于天气。小团队正在给 AI 产品加入需求、流失、欺诈、配送延误、设备故障、现金流和用户意图预测。模型可能很准,产品仍会失败:预测送达太晚,概率被错误理解,行动阈值没有依据,或者根本没人对最终决定负责。
本文面向正在把不确定预测变成真实行动的非技术创始人、AI 应用构建者和小型产品团队。你将得到清晰术语、三层证据模型、一个完整的物流场景、失败测试、一份可复用的“预测到行动”合同,以及分阶段上线决策。核心判断只有一句:预测、送达承诺、行动规则和回退机制必须作为同一个产品版本发布。
WeatherNext 改变了什么,又没有改变什么
Google DeepMind 的发布说明称,WeatherNext Cyclones 用一套系统共同预测风暴的路径、强度和风圈结构。它在 2023 至 2024 年的历史气旋上接受了评估。Google 报告称,在相同误差水平下,它平均增加了超过 24 小时的提前量;2026 年系统还可以生成包含 1,000 个成员的集合,以呈现可能路径和局部风速概率。一套有用的气旋系统,需要同时表达风暴可能去哪里、会增强到什么程度、破坏性大风覆盖多大范围,以及这些结果有多不确定。地图上一条漂亮的路线不够。
这条证据链也不止是厂商自己做历史回测。国家飓风中心 2025 年预报验证报告覆盖了 AI 指导首次进入其实时流程的飓风季。当前的 NHC 模型说明表以 GDMN/GDMI 标识列出 Google DeepMind 集合均值,预报参数包括路径、强度和风圈半径。此前 NOAA 已公开双方的正式合作:Google 提供近实时预测,NOAA 负责常规评估。
但三条边界没有消失。
第一,平均提前量不等于对每个事件、地区、预测时长和误差类型的保证。第二,模型预测只是指导;NHC 明确要求用户以正式预报和预警为准,而不是单独依赖原始模型输出。第三,在真实产品里,可用性也是准确性的一部分。即使迟到的结果后来证明正确,只要它错过决策时限,就没有帮助。
对创始人而言,WeatherNext 最清楚地展示了预测质量与产品可靠性之间的距离。
在承诺结果前先把术语说清楚
团队经常把“准确”“有信心”和“提前”混成同一件事。它们不是。
预测目标是系统要预测的具体事件或数值。“坏天气”不是目标;“未来 72 小时内,A 仓库出现达到指定阈值的持续大风”才更接近一个目标。换到别的产品,也可以是“发票到期 14 天后仍未付款”。 提前量是预测发布时刻与事件或决策截止时间之间的间隔。只有当预测仍然足够有用、可以改变行动时,更长的提前量才有价值。 相同误差水平下的提前量增益比较的是:一套系统能够提前多久达到另一套系统在更晚时刻才达到的误差水平。WeatherNext 所说的“多一天”属于这种平均比较,不是每场气旋都能恰好早 24 小时报准。 确定性预测给出一个结果或一个最佳估计;概率预测给出多种可能结果的分布;集合预测则用一组合理的模型演变来估计这个分布。1,000 个集合成员不是对现实进行的 1,000 次独立观测。 校准考察的是:在明确的人群、事件和时间范围内,系统给出的概率是否与实际发生频率一致。如果大量可比样本中,被标为 20% 的事件大约五次发生一次,这个概率区间才算校准良好。校准总是依赖样本、时长、版本和事件定义。 区分度考察系统能否有意义地区分高风险和低风险案例。假设某类事件的基础发生率是 10%,一个永远输出 10% 的系统可能在总体上显得校准,却无法告诉团队该优先处理谁。 决策阈值把预测映射为行动。它属于产品和业务选择,不是模型自带的通用属性。显示规划提示的阈值,可以低于取消一批货运的阈值。 运行可用率指每个应发布的预测周期中,有多少能在决策截止时间前完整、有效地到达。它覆盖上游数据、模型运行、结果转换、产品发布和用户端展示。这些定义能防止团队因为买到更好的模型,就在没有测量整条产品链的情况下承诺更好的决策。
模型能力不等于产品价值
一个预测产品至少有四个互相连接的层次:
- 模型估计未来可能出现的状态;
- 产品把这些状态转换成一个定义明确的用户事件概率;
- 决策策略根据概率、时间和后果选择行动;
- 人或系统执行行动并记录结果。
Google 自己的 WeatherNext 用途与限制说明就说明了这种转换难题。模型以全球业务分析资料为目标,不等于某个地点的地面实测;局部应用可能需要偏差修正;部分变量并不提供;降水目标与细尺度结果也存在限制。快速生成全球预测,不会自动产生可靠的本地产品。
流失预测也是同样的逻辑。一个优秀的账户风险分数,并不能告诉客户成功经理今天该联系谁、允许给什么优惠,或者这次联系是否真的改变了留存。欺诈分数不会自动定义谁能冻结付款、用户能看到什么证据、如何申诉。需求分布也不会替团队判断积压成本和缺货成本哪个更高。
即使模型来自可信厂商,缺失的产品层仍由创始人负责。
不要只看一个基准评测,要有三类证据
预测功能应依次通过三层证据。跳过任何一层,都容易产生虚假的安全感。
第一层:历史能力
历史回测要回答:如果只使用当时真正可获得的信息,当前模型和当前处理链当时会给出什么结果?比较必须固定基线、事件定义、预测时长和具有代表性的评估时间窗。特征、后处理、标签和人工修正都不能泄露未来信息。
概率产品不能只剩一个准确率。应检查校准、区分度、产品候选阈值下的误报和漏报,以及重要分组上的表现。关于概率预测校准与尖锐度的原始研究解释了一个关键原则:预测分布应在保持与实际结果统计一致的前提下,尽可能集中。WMO 的预报验证指南也把准确性、偏差、可靠性、区分度和尖锐度分别检查。
历史能力只能回答“这个信号当时是否可能有帮助”,不能证明今天的生产链会把它按时送到。
第二层:实时运行可靠性
让新预测先与现有流程并行进行影子运行,不改变真实行动。记录每个预期周期是否按时到达、字段是否完整、用户与位置映射是否正确,以及重试或上游部分故障时是否仍能保持一致。比较真正交给产品的结果,不要比较分析师事后重新整理的完美版本。
NHC 的证据之所以重要,一部分原因正是 WeatherNext 指导在一个完整季节里遇到了真实的发布时间、初始资料和人工预报员。验证材料也提到部分 AI 指导存在及时性问题。如果产品不主动测量送达,干净的基准评测会把这类失败全部隐藏掉。
第三层:决策价值
最后要检验预测是否真正改善了用户决定。衡量避免的损失、不必要行动、决策耗时、审核负担、客户理解和可逆性。比较新旧决策策略,而不只是比较新旧模型。
一个稍弱但能稳定按时送达、行动协议清楚的预测,可能比一个分数更高却经常迟到的模型创造更多价值。
在展示百分比前,先把集合转换成用户事件
集合是一组可能的未来。用户需要的是针对一个明确事件的概率,产品必须定义二者如何转换。
假设 1,000 个气旋情景中有 250 个显示某仓库附近会出现热带风暴级大风。“风险 25%”仍不完整。“附近”对应哪些坐标?风速阈值是多少?时间窗是 24、48 还是 72 小时?每个集合成员是否有效并以相同方式计入?是否做过偏差修正?这个百分比是指时间窗内任一时刻达到阈值,还是持续一段时间?它来自哪个模型版本和哪次初始化?
任何字段变化都会改变这个数字的含义。每次预测都要保存不可变的事件定义。产品还应保留原始概率,而不是只展示“低、中、高”。标签可以帮助理解,但不能抹掉概率、阈值、预测时长、发布时间和失效时间。
英国气象局的集合预测决策指南明确指出了行动层:用户需要按照自身场景,在告警与误报之间选择概率阈值。这个选择取决于用户承担的后果,不能从模型卡照抄。面向客户的每个概率,都应该在不依赖隐藏说明的情况下回答五个问题:
- 预测的究竟是什么事件?
- 地点在哪里,时间窗有多长?
- 当前系统给出的概率是多少?
- 预测何时发布,何时失效?
- 产品建议或允许采取什么行动?
复用这份“预测到行动”合同
下面这份模板把模型、产品承诺和运行响应写入同一个版本。字段需要团队自己填写,示例值不是可照抄的默认设置。
forecast_release:
id: depot-wind-risk-v1
owner: operations-product
intended_user: regional-logistics-manager
user_job: decide whether to reroute tomorrow's inbound deliveries
forecast:
provider: named-model-and-version
event: sustained_wind_at_or_above_defined_threshold
geography: depot-service-polygon-v3
horizon: 72h
issuance_schedule: every_6h
probability_method: documented_ensemble_to_event_transform
valid_until: next_successful_cycle_or_expiry
evidence:
backtest_window: fixed-and-documented
baseline: current-operating-process
required_segments: [region, season, horizon, risk_band]
calibration_report: versioned-link
shadow_cycles_required: team-defined
decision_policy:
monitor: probability_below_review_threshold
review: probability_at_or_above_review_threshold
act: official_warning_plus_named_human_approval
prohibited_actions: [public_safety_warning, automatic_evacuation]
delivery_slo:
deadline_after_source_cycle: team-defined
completeness: required-fields-list
stale_after: team-defined
unavailable_behavior: show_stale_state_and_use_official_source
receipt:
store: [model_version, issue_time, event_definition, probability,
threshold_version, recommendation, approver, final_action, outcome]
rollback:
trigger: calibration_or_delivery_stop_condition
fallback: official_guidance_only
owner: named-person
这份合同会逼团队说清楚仪表盘容易隐藏的决定。产品必须有明确的用户任务,而不是笼统的“洞察”;事件定义和地理范围必须可版本化;阈值策略要区分观察、审核和行动;禁止事项要把权限边界写在明处;送达服务等级目标(SLO)要让迟到与残缺可以被观测;决策回执则把系统当时知道的内容与人最终做的事连起来。
模型、事件转换、阈值、送达节奏或回退方案中的任何一项变化,都应视为一次发布变更。即使 API 没变,后面的模型升级也可能创造出一个新产品。
完整场景:一款不冒充气象机构的物流应用
HarborLane 是一家虚构的五人团队,为区域食品经销商开发运营应用。客户需要决定第二天的进货卡车应该进入沿海仓库,还是改走内陆备用点。HarborLane 想加入基于 WeatherNext 的大风概率,因为一条确定性路线会掩盖重要的不确定性。
较弱的做法是:只要任何模型成员靠近仓库,就显示红色横幅。产品没有事件定义和发布时间,也不区分内部规划提示与正式预警。一个后果严重但概率很低的情景可能引发不必要的改线;某次模型缺测又可能让横幅悄悄消失;用户还可能误以为 HarborLane 正在发布安全建议。
更稳健的做法,是把用户事件定义为:在仓库已记录的服务多边形内、固定 72 小时时间窗中,出现达到指定阈值的持续大风。界面展示原始概率、发布时间、预测时长、数据状态和当地权威气象来源链接。模型可以把案例从日常观察提升为运营审核,但不能发布公共预警或下令疏散。
发布前,HarborLane 只使用每个模拟发布时刻真正可见的数据,重放两个历史季节,并把新处理链与团队原来的权威预报流程比较。它按地区和预测时长检查不同概率区间,而不是只看平均误差。随后,新系统进行六周影子运行,不改变客户运营。每个六小时周期只允许落入一种状态:准时、延迟、残缺、无效或缺失。
团队发现,模型信号在 48 至 72 小时段很有用,但对某个沿海多边形高估了风险。它修正转换,再重新跑保留评估。团队还发现,经理并不想要自动改线;他们需要的是一项审核任务,其中包含供应商截止时间、受影响库存、改线成本和最新正式预警。
因此 HarborLane 先以上线辅助模式收尾。预测可以创建审核任务,但行动由具名经理决定。回执记录概率、正式指导状态、受影响货运、批准人和最终结果。一个季节之后,团队才能判断:更早发起审核是否减少了紧急改线,又没有产生不可接受的误报。
这个虚构场景展示的是把高质量预测变成诚实产品功能所需的工作,并不能证明 WeatherNext 一定适合 HarborLane。
从行动后果选择阈值,不要从“高信心”形容词选择
“高信心”不是行动规则。阈值必须考虑漏掉事件的成本、误报成本、行动所需时间、行动能否撤销,以及人工审核容量。
先按后果划分行动,再选择数字:
| 产品行动 | 不必要行动的成本 | 漏掉事件的成本 | 可逆性 | 合适的发布方式 |
|---|---|---|---|---|
| 显示规划提示 | 低 | 低 | 可立即撤销 | 基础验证后自动展示 |
| 创建内部审核任务 | 低至中等 | 中等 | 容易 | 自动创建并保留回执 |
| 建议改线或调整库存 | 中等 | 高 | 有时间限制 | 人工批准 |
| 取消服务或限制用户 | 高 | 高 | 难 | 具名负责人加完整证据 |
| 发布生命安全指令 | 极高 | 极高 | 往往不可逆 | 不属于普通应用权限 |
对于便宜、可逆的审核任务,较低阈值可能合理;同一个阈值用来触发昂贵或影响权利的行动,就可能很危险。如果行动后果升级,不要只把概率数字调高。还要加入更强证据、更窄权限、独立来源,以及更好的申诉或撤销路径。
在保留时间段上测试阈值,并报告它会产生多少实际行动。15% 看起来很谨慎,但如果每天制造 400 个审核任务,而团队只能处理 20 个,这个阈值就无法运行。容量属于策略的一部分。队列溢出时必须有明确行为,不能悄悄批准或丢弃案例。
只有理由清楚时才让不同分组使用不同阈值。每次出现引人注目的事件就临时改阈值,会让策略过拟合于故事。每次修改都要版本化,并重新评估相关时长和分组。
把送达当成一等验收项
预测产品会过期,因此运行检查格外重要。
每个预期周期都要记录源数据可用时间、模型开始与完成时间、转换完成时间、产品发布时间、通知送达时间,以及用户首次查看时间。发布前验证位置标识、单位、预测时长、集合成员数、概率范围和事件定义版本。
产品应给用户展示五种明确状态:
- 当前有效:预期周期完整到达并通过验证;
- 延迟:正常时间已过,但还没有错过决策截止时间;
- 已过期:上一次有效预测已超过批准时效;
- 部分可用:部分字段、地区或集合成员缺失;
- 不可用:产品无法产生有效预测。
团队还应提前设置送达方面的发布停止条件,例如错过决策截止时间的周期比例超过可接受范围。具体数字取决于任务,但必须在看到上线数据前确定,否则团队很容易因为模型结果好看而为故障找理由。
保留真实人工权力,不要制造审批表演
只有审核人面对一个真实选择,拥有充分背景,并有权反对系统建议时,人工审核才有价值。
审批界面应展示事件定义、当前概率、上次预测、变化方向、权威或独立来源、受影响对象、行动成本、截止时间与恢复方式。它不应只放一个绿色的“AI 建议批准”按钮,把证据藏到页面深处。
至少要给四类责任指定负责人:
- 模型与数据质量;
- 事件转换与产品呈现;
- 决策策略与业务后果;
- 事故响应与用户沟通。
高后果决策应要求独立证据或权威来源。NOAA 与 Google 的合作方式很有启发:Google 提供近实时模型输出,NHC 把它放入更大的技术与专家流程中评估。这种业务关系没有消除机构自身的责任。
测试基准评测看不到的失败
以下测试必须覆盖完整产品,而不是只打模型接口。
“相同误差多一天”误读测试
让十位目标用户解释“多一天”是什么意思。如果他们把它理解为每个事件的保证,测试就失败。任何使用这个说法的地方,都要同时给出确切样本、指标、平均比较方式和限制。
过期数据归零测试
阻断一次定时预测。如果界面显示 0% 风险、在不标发布时间的情况下重复旧值,或者继续自动行动,测试失败。正确结果必须是延迟、过期、部分可用或不可用之一。
阈值替换测试
保持模型不变,只修改审核阈值。确认发布系统会识别出新的产品策略版本,重新计算行动量,并要求具名负责人批准。
地理与单位测试
故意改变多边形、时区或单位换算。如果一个看似合理的概率被挂到错误地点、时间段或阈值上,而验证没有拦住,测试失败。语义上“看起来合理”的错误尤其危险,因为用户不容易发现。
尾部风险测试
构造一个概率低但后果严重的集合分支。确认产品不会把它藏进平均值,也不会把它展示成最可能结果。界面应把它连接到与后果相称的审核规则。
权限边界测试
尝试用该功能执行合同外行动,例如发布公共安全指令。产品应阻断或重新引导,而不是只显示一个可以忽略的警告。
回滚重建测试
抽取一项历史决策,重建当时的模型版本、概率、事件定义、阈值、建议、批准人、最终行动和观察结果。如果团队不能复原决策记录,就无法可靠调查伤害或改进策略。
避免五种很诱人的误读
“开源就代表生产就绪。” 公开代码和权重有助于检查与试验,却不会自动提供你的本地校准、送达 SLO、支持流程或权限模型。WeatherNext 代码仓库是一项重要发布物,不是产品验收的替代品。 “1,000 个情景会让小概率变得精确。” 更多集合成员有机会更丰富地表达尾部,但它们共享数据、架构和假设。模型依赖、事件转换与现实观测不足依然存在。 “一个著名成功案例就验证了整个系统。” 飓风 Melissa 是有意义的业务案例,NHC 风暴报告也帮助确认预报员当时观察与决定了什么。但一个令人印象深刻的成功,不能替代跨事件、跨地区验证。 “概率是客观的,所以行动也是客观的。” 事件定义、阈值、错误成本与行动权限都是人作出的选择。把它们藏在分数后面不会消除判断,只会让判断更难审计。 “加入人工就完成了责任转移。” 如果审核人没有时间、背景、替代选项或反对权限,人工就不是有效控制。应测量撤销率、审核时间、被跳过的证据和最终结果,而不是统计批准点击数。什么时候适用,什么时候不适用
当 AI 功能预测未来事件或数值,而且结果可能改变用户行为时,适合使用“预测到行动”合同。典型场景包括需求计划、配送风险、流失干预、欺诈审核、设备维护、现金流告警、预约爽约、容量规划和受天气影响的运营。
如果预测只提供信息、用户忽略它的成本很低、标识清楚且不会触发自动后果,可以使用轻量版本。仍要定义目标、发布时间、预测时长和过期状态,但权限与回滚流程可以更简单。
不要用这套框架来证明普通 AI 产品可以充当天气、医疗、法律、信贷、就业、保险或公共安全的正式权威。这些领域可能要求合格专业人员、明确监管、经过验证的工具、程序权利与可问责机构。一张通用产品清单不会创造这种权限。
产品如果根本不在预测,也不该套用这套框架。摘要工具需要证据忠实度与完整性测试;编码智能体需要变更与执行控制;图片生成器需要声明、无障碍和视觉验收。把所有模型输出都叫作预测,只会让术语失去价值。
创始人的 48 小时启动流程
前四小时,写清一个用户任务、一个预测目标、一个预测时长、一个决策截止时间和一项禁止行动。确定当前基线流程,并指定对产品承诺负责的人。
八小时内完成“预测到行动”合同。列出模型输出到用户事件概率之间的每一步转换。定义当前有效、延迟、过期、部分可用和不可用五种状态。
第一天,建立一个严格保留历史信息边界的小型评估。针对正在考虑的实际阈值,报告校准与行动量;并按那些可能改变用户后果的分组拆分结果。
第二天,启动影子送达。记录每个预期周期并生成回执,但不改变用户行动。执行过期归零、地理、阈值、尾部风险、权限和重建测试。在看到第一批实时结果之前,先写下停止条件。
不要只凭 48 小时设置就承诺正式上线日期。这个流程的目标,是尽快建立证据管线。影子运行需要多长时间,取决于事件频率、季节性、行动后果,以及历史资料在多大程度上真正代表实时环境。
明确作出发布决定
只使用四种发布状态:
| 决定 | 所需证据 | 产品行为 |
|---|---|---|
| 辅助上线 | 历史能力、可接受校准、实时送达通过、审核人已训练 | 预测创建建议或审核任务,由人负责行动 |
| 限制上线 | 信号有价值,但分组或季节证据不完整 | 限制用户、地区、预测时长或只允许低后果行动 |
| 暂缓 | 校准不清、阈值不稳、错过时限或权限模糊 | 保持影子模式,修复已命名的缺口 |
| 拒绝 | 相对基线无实用提升、伤害不可接受、无可行回退或用途被禁止 | 移除功能或重新定义用户任务 |
“模型更好”不属于发布决定。发布记录要写明允许用途、排除用途、证据时间窗、未解决风险、下次复查日期和回滚负责人。
WeatherNext 值得关注,是因为它把严肃研究结果、开放产物和真实运行证据放在了一起。它最值得迁移的经验,不是每个小团队都应该运行天气模型,而是:只有不确定性通过经过测试的策略,在决策前到达正确的人,同时边界可见、权限可问责时,预测才真正有价值。
先把这条链路建好,再设计那个代表“信心”的徽章。
参考资料
- Google DeepMind:WeatherNext Cyclones 发布说明
- Alet 等:Operational tropical cyclone forecasting with AI,Nature
- Google DeepMind:WeatherNext 开源仓库
- Google for Developers:WeatherNext 模型指南
- Google for Developers:WeatherNext 用途与限制
- 美国国家飓风中心:2025 年预报验证报告
- 美国国家飓风中心:路径与强度模型说明
- 美国国家飓风中心:飓风 Melissa 报告
- NOAA:与 Google 合作研究气旋预测
- Gneiting、Balabdaoui 与 Raftery:概率预测、校准与尖锐度
- 世界气象组织:水文预报验证指南
- 英国气象局:如何用集合预测支持决策