我做了个小工具，读取降雨预报并生成可转发的预警消息

朋友阿努卡和她的家人要用博卡拉附近卡斯基的一条路。雨季里，实际的问题是未来几天这条路值不值得走。因为季风，她没能赶去祖父家过重要的节日。她给作者发了一条消息，于是有了这个工具。

它读取降雨预报，生成一段可以转发到 Viber 或 WhatsApp 的短消息，英文和尼泊尔语各一份。选一个区，按下「检查未来 3 天」，接下来三天每天给出一个风险百分比，比如「风险：68%（1000 个预报情景中有 680 个）」。

1000 个情景是怎么跑出来的

这个数字来自 122 个集合成员（ECMWF 51 个、GFS 31 个、ICON 40 个），把它们汇入一条降雨规则，跑出 1000 个降雨情景。风险百分比就是这些情景中越过「与已报告滑坡相关联的雨量线」的比例。

它不等于滑坡发生的概率。在 2022 至 2024 年的季风季，规则触发的那些天里，卡斯基有 35% 的日子报告了滑坡（23 天中的 8 天），而全部季风日子的这一比例是 9%。

消息下方还有一条兜底链：短信、Viber 群、社区志愿者、警报器或旗帜。一个「网络可用？」开关，关掉后只显示这条链，供手机没信号时使用。页脚固定写着：这不是官方预警，请遵循 DHM 和当地政府。

三条规则，谁也没赢

作者把三条降雨规则与尼泊尔 BIPAD 门户上卡斯基报告的滑坡日做了对比。第一条是累计 3 天降雨，第二条是前期降水（API），第三条是发表在 Kanti Roadway 的强度—历时（I-D）线。每条都按原样或加一个简单阈值试过，也试过只用训练年份调参的版本（2015 至 2021 年季风季，854 天，41 个滑坡日）。全部在 2022 至 2024 年季风季上评分（366 天，33 个滑坡日）。需要说明的是，Kanti 那项研究来自巴格马蒂省，不是卡斯基。

结果是没有哪种方法胜出。置信区间全部重叠，在 33 个滑坡日上大约从 0.00 到 0.49。77 毫米那条规则的分数被高估了，因为它的阈值是在测试年份上选的；改用训练年份调参后掉到 0.13，把阈值从 183 毫米挪到 186 毫米，F1 就从 0.17 变成 0.13。

已发表的 I-D 线在卡斯基约 28% 的季风日触发，而且一场大风暴之后会持续约两周，所以作者对它做了重新校准。应用里的版本约在 6% 的季风日触发。选它是因为误报更少，不是因为分数更高。

那个看起来会赢的模型，赢在一年

TabPFN v2 用上更丰富的特征（前期降雨、土壤湿度、滞后降雨）后，名义 F1 最高，0.33，一度看起来就是赢家。但这个胜利是一年的假象：它的 F1 在 2022 年是 0.00，2023 年是 0.11，2024 年是 0.58，整个结果都来自 2024 年。它在训练年份内部的交叉验证 AUC 是 0.45，低于随机水平；而且上线时它需要的土壤湿度来源与训练时不同。因为这些原因，它没有进入应用。作者用的是 TabPFN v2，更新版本的许可接受没有在他的账号上生效，所以没有使用。

规则和消息层跑在一台笔记本上

降雨数据和集合预报来自 Open-Meteo，不需要密钥。英文消息由 Gemma 3 4B 通过 Ollama 在同一台机器上生成，没有任何数据离开设备。尼泊尔语消息是固定模板，因为在测试中 Gemma 的尼泊尔语不可靠，会造词、写错月份名。界面是本地 Streamlit 原型。

获取预报需要联网，所以这个工具在山里不能离线工作。离线的部分是兜底清单里那条人的链条：当手机和应用都失效时，能接力把预警传下去的人。

它只看雨，而且只在淡季测过

它只看降雨。八月那起事件是冰岩崩，降雨模型本来就不是用来预测这个的。事件数据是 BIPAD 上已报告的事件，不是每一场滑坡；卡斯基 124 个滑坡日里有 8 天落在 6 至 9 月之外，被排除。测试集只有 33 个滑坡日，作者没有为应用的实时输出计算置信区间。

降雨数据是区中心附近约 1615 米格点的再分析数据，不是雨量计数据，也不是那条路的数据。集合离散度很可能低估了真实预报误差：在作者检查的时段里，提前一天的预报与再分析数据平均每天相差约 5 至 8 毫米。

这个应用只在淡季（十月）的实时预报上测过，也在合成和强制的高风险案例上测过，因为现在不是季风季。其他区复用卡斯基的模型，没有经过验证，应用里也这么写了。

英文（Gemma 3 4B）和尼泊尔语（固定模板）都没有经过母语者审阅。早期 Gemma 的英文出过错，包括编造和颠倒风险百分比。现在应用只在 Gemma 的英文风险百分比与屏幕上的数字完全一致、以准确的免责声明结尾、且不超过 60 个词时才接受它；否则就显示固定模板。最后大约十几次测试调用通过了，但样本很小，措辞仍可能生硬。

这不是官方预警，请遵循 DHM 和当地政府。