流感预警这件事难点从来不在“发现”而在“提前”。我在复现某区域流感预警Demo系统时核心目标只有一个在流感监测曲线还没来得及明显抬头之前用AI气象数据融合的方式提前两周给出区域风险判断。很多人问我流感监测数据明明已经有了为什么还要融合气象因为真正的预警必须在数据变红之前发声而气象是少数能在感染链条形成之前就出现变化的“先行变量”。这个系统适合公共卫生相关团队、医院感染管理科室、时序预测算法的同学也适合所有想搞懂“多源数据融合到底怎么落地”的开发者。这篇文章就是我完整跑通一次这个项目后的经验记录从数据设计、模型选型、训练验证到上线后踩过的坑全部摊开讲。1. 项目背景流感预警的难点与气象数据的价值1.1 流感监测为什么总是慢半拍很多做时序预测的同行一听到“流感预警”第一反应是这不就是把流感监测数据喂给LSTM嘛有什么可做的真上手之后才发现恰恰是“监测数据”这几个字藏了最大的坑。流感监测的源头是哨点医院和实验室检测。从患者出现症状、到医院就诊、样本送检、结果上报、再到统计部门汇总一级一级走下来系统里能看到的最新周数据反映的其实是两周前甚至三周前的感染情况。也就是说等ILI%流感样病例占门诊就诊百分比曲线开始明显抬头的时候这一波风险实际已经在社区里传播了一圈。这个延迟不是哪一层环节偷懒而是上报机制本身决定的——背后有采样周期、审核流程、数据清洗多重步骤。更要命的是监测数据在疫情初期往往存在“漏报窗口”。很多人症状比较轻根本不会去医院真实传播规模被低估。等到就诊人数暴增数据曲线才陡峭起来但这时候再去调配疫苗、药物、床位已经晚了。所以我们需要一个不和监测数据同步延迟、反而能提前暴露风险的信息源而这正是气象数据能发挥作用的地方。1.2 气象变量与流感传播的物理联系我一直觉得气象数据能被用来做流感预警靠的不是大数据玄学而是几个非常扎实的物理机制。第一是病毒体外存活率。流感病毒在低温、低绝对湿度的环境里附着在飞沫或者气溶胶表面的存活时间会明显拉长感染性维持得更久。这里要特别提醒绝对湿度比相对湿度更关键。空气里实际水汽含量低的时候飞沫蒸发更快剩下的小颗粒更容易长时间悬浮在空气中增加吸入感染的概率。第二是人体防御机制。冷空气刺激会让鼻黏膜血管收缩纤毛摆动变慢呼吸道局部的免疫清除能力随之下降。相当于身体给病毒临时开了一扇门。第三是行为因素。气温低、日照弱的天气里聚集在室内密闭空间的活动变多空气流通变差病毒扩散阻力更小。这个链条虽然不像前两个那么“硬核”但对真实的流行病传播影响很大。第四是紫外线。冬春季日照时间短紫外线对病毒表面的灭活作用减弱环境中的病毒存活时间进一步延长。这四个机制叠在一起使得气象变量——尤其是温度和绝对湿度——成为流感传播链条里可以被提前观测的先行指标。气象预报系统本身已经能比较准确地预测未来一到两周的温度、湿度和降雨趋势把这个预测能力接进流行病预警模型就相当于给流感预警装了一个“前向传感器”。1.3 “提前两周”具体意味着什么预警提前两周到底价值在哪算一笔时间账就明白了。流感从感染到发病平均约2天从发病到重症或者去就诊中间还要几天哪怕哨点数据是实时更新疫情上升信号出现时个体层面已经来不及通过接种疫苗来获得保护了。而提前两周意味着还有时间做几件真正有效的事提醒高危人群尽快完成接种、调节医院发热门诊和抗病毒药物的储备、在重点场所启动通风和环境消毒提醒、给公众发布风险提示。两周不是一个拍脑袋的数字它的上限来自气象预报能力的边界——预报超过两周以后可信度快速衰减下限来自流感传播周期——太短了则根本来不及执行任何干预动作。所以我在这类系统里通常把预测窗口切成两段近两周输出“风险等级”更远的输出“趋势方向”而不是强行给出一个精确病例数。精确病例数的预测误差太大反而会让业务方失去信任风险等级加趋势方向既有可执行性又有稳定性。2. 整体架构设计从数据到预警的完整链路2.1 数据分层标签、特征与辅助信号这个Demo把数据分成三层角色完全不同处理方式也不同。第一层是标签数据也就是要预测的目标每周ILI%百分比序列、实验室流感阳性检出率、医院发热门诊量。这三个指标其实是对同一波疫情的不同观测角度我建议以ILI%为主、阳性率作为校正项不要全部塞进模型当并列输入。第二层是气象特征日平均温度、昼夜温差、相对湿度、绝对湿度可以用温度和相对湿度计算得到、风速、降雨量、日照时数。其中绝对湿度、平均温度、日照时数是优先级最高的三个变量。第三层是辅助数据空气质量指数、重点场所人群热力指数、药品销量指数等等。辅助数据的价值不是“多一个特征”而是帮助模型排除短期波动干扰。比如一场普通降温也可能让门诊量增加如果此时药品销量指数没有联动上升就可以判断不是流感暴发主导。很多人一开始就把几十个变量胡乱拼在一起结果模型可解释性很差预测也不稳定。数据分层的作用就是让标签数据决定模型学什么、气象特征决定提前预测的依据、辅助数据负责消减误报。2.2 时空对齐这块处理不好模型分数再高也是假的我见过不少项目模型效果特别好提交结果时预测曲线和真实曲线几乎重叠结果一查发现是时空对齐出了问题。最基本的一点气象数据通常是天级或者小时级流感监测数据通常是周级两边必须统一时间标尺。流感监测周通常从周一开始气象数据按自然日汇总的话周一对应的周标签就可能错位。空间上更麻烦流感数据按行政区域统计气象数据按网格发布直接把一个网格套到整个区域上人口分布不均匀的问题就被忽略了。我们当时的处理思路是先把研究区域按行政边界切分然后对每一个行政区取区内气象网格值的面积加权平均。这比简单取中心点更合理计算量也完全可控。时间滞后特征的构造也不能忽略。温度和绝对湿度对未来疫情的影响不是同步的通常要滞后一到三周。建议在建模之前先做互相关分析画出每个气象变量与ILI%在不同滞后周数上的相关系数再根据峰值确定滞后期而不是凭感觉把所有变量一股脑塞进模型。2.3 为什么“融合”比单一数据强有人会问既然加入了气象特征为什么不干脆做个纯气象模型答案是流感监测序列里包含了很多气象之外的“真实行为信息”比如节假日人口流动、疫苗接种进度、学校开学时间表但纯监测序列模型又会在疫情真正暴发前毫无反应因为序列本身还没有开始变化。气象数据和监测数据的价值是互补的监测序列提供“现状基线”气象数据提供“变化的前瞻信号”。两者融合模型才能在曲线还平的时候提前做出方向性判断。这个逻辑和我们平时出门穿衣服类似——你既看今天实际冷不冷也看未来几天的天气预报。只看温度计会被突然降温打得措手不及只看预报又可能忽略了当下的特殊情况两个信息一起看判断才准。3. 核心实现模型选型、训练与验证3.1 模型选型从回归到双通道时序网络这个任务本质上是一个多变量时序预测问题不是图像问题也不是简单分类问题。经典回归模型比如线性回归、随机森林用滑窗特征也能做但缺点很明显无法刻画疫情序列的长期依赖也很难利用气象序列本身的演化趋势。SARIMA虽然适合单变量周期序列但加入外部协变量时需要手工处理季节项和滞后结构扩展性不好。常规的LSTM单通道模型效果会比回归好但它把气象特征和流感历史拼在一个输入向量里模型很难真正学到“气象变化如何传导到疫情”的因果结构。到后面测试下来我发现最稳的方案是双通道序列模型一个通道吃过去六到八周的ILI%历史序列另一个通道吃过去一到两周的气象特征序列两个通道分别用LSTM或GRU编码最后把隐状态拼起来映射到未来两周的输出。这个结构的直观解释是流感通道负责“现在的基础水平”气象通道负责“未来的推动力”。3.2 训练验证里的时间边界问题这个任务最大的验证陷阱是时间泄漏。一定不能用随机划分训练集和验证集必须按时间先后切。我们用滚动验证假设历史数据有三年先拿前两年训练在第三年第一周做预测然后逐步把验证窗口向前推每次都保证训练集只包含验证窗口之前的数据。标准化也必须在训练集上拟合再应用到验证集。如果整个数据集一起归一化模型分数会被高估现实中根本达不到那个效果。评估指标上我一般同时看RMSE、MAE、方向命中率、峰值误差和暴发识别F1。RMSE和MAE衡量数值偏差但公共卫生预警更关心拐点方向对不对、峰值时间有没有偏。所以在一套预警系统里方向命中率和F1往往比RMSE更敏感。模型在数值上差零点几可能不致命但方向判断错了会直接导致决策失误。3.3 核心代码骨架下面这个骨架完全可以在小规模数据上跑通。它省略了很多工程细节但保留了我认为最重要的双通道结构。输入是过去7周的流感序列和过去7天的气象特征输出是未来两周的风险评分0到1后续再接阈值判断。import torch import torch.nn as nn class FluRiskNet(nn.Module): def __init__(self, meteo_dim, hidden_size64): super(FluRiskNet, self).__init__() self.flu_lstm nn.LSTM(1, hidden_size, batch_firstTrue) self.meteo_lstm nn.LSTM(meteo_dim, hidden_size, batch_firstTrue) self.head nn.Sequential( nn.Linear(hidden_size * 2, hidden_size), nn.ReLU(), nn.Dropout(0.3), nn.Linear(hidden_size, 14) ) def forward(self, flu_seq, meteo_seq): _, (h_flu, _) self.flu_lstm(flu_seq) _, (h_meteo, _) self.meteo_lstm(meteo_seq) feat torch.cat([h_flu[0], h_meteo[0]], dim-1) return self.head(feat) # 输出未来14个时间点输出维度是14对应未来两周每一天或每一周的风险评分。实际使用时不直接拿原始回归值而是对14个输出做统计汇总比如取最大值、均值再映射成风险等级。这个骨架刻意做得比较简单好处是稳定、好调、不容易过拟合。如果数据量很大可以在气象通道后面加一层注意力机制让模型自己学哪些天气变量对未来疫情影响更大。3.4 关键超参数与训练技巧历史窗口长度是影响效果最明显的超参数。流感通道取六到八周比较合适太短学不到季节性趋势太长容易引入无关的历史噪声。气象通道通常取一到两周因为气象对传播的影响时效性很强三周以前的天气对当前疫情几乎没有解释力。训练时我用早停法验证集损失连续五轮不下降就停止。学习率从1e-3开始配合余弦退火调度。Dropout设置在0.3左右太高会让模型欠拟合太低则有训爆风险。另一个容易忽略的点是模型输出的不是“未来两周每一天的独立预测”而是“基于当前状态未来两周的变化趋势”。所以在构造训练样本时我采用的是多步滑动窗口每个样本的标签是从当前周开始的未来两周风险强度而不是单个时间点的预测值。这样训练出来的模型更贴近预警业务的需求。4. 实操过程从数据清洗到模型上线的完整记录4.1 从原始数据到可训练样本我选择以周尺度作为训练尺度主要有两个原因流感监测数据天然是周粒度把气象日数据重采样到周能抹掉短期随机波动也更方便复现和解释。第一步从公开气象接口拿过去三年每日气象数据重采样成周计算周平均温度、周平均绝对湿度、周平均风速、周累计日照时数。第二步把流感监测数据按监测周对齐计算ILI%周序列。第三步对缺失周做向前填充然后构造滞后特征比如T-1周的绝对湿度、T-2周的昼夜温差。第四步把三个样本集合严格按时间顺序切分。这里有一个关键细节所有特征标准化都在训练集上完成验证集和测试集的标准化参数从训练集继承。如果重新计算验证集的均值和标准差就会无意中把验证集的信息泄漏给模型。from sklearn.preprocessing import StandardScaler scaler StandardScaler() train_meteo_scaled scaler.fit_transform(train_meteo) valid_meteo_scaled scaler.transform(valid_meteo) test_meteo_scaled scaler.transform(test_meteo)就这么三行代码看起来简单但能避免一个非常隐蔽的坑。同样的逻辑适用于缺失值填充如果验证集缺失周用全序列均值填充那也是泄漏。4.2 风险等级与预警阈值的设定模型输出的风险评分只是中间产物真正对接业务的是风险等级。我参考了很多区域的做法以历史同期非流行季节的ILI%均值作为基线当预测值超过基线1.5个标准差判定为低风险超过3个标准差判定为高风险而一旦预测连续两周上升且上升幅度超过20%直接触发“趋势预警”标记。这些阈值不是拍脑袋定的而是用过去三年数据做过模拟回溯后确定的。具体做法是把历史数据切到当前周之前模型只利用当时能获得的信息进行预测然后对比预测结果和真实疫情曲线统计误报和漏报数量反复调整阈值直到误报漏报的加权损失最小。注意阈值不是每个区域都一样的。不同气候特点的区域内流感季节形态差异很大统一阈值会导致误报率两极分化。所以我的习惯是给每个聚集区域单独标定一套阈值外层再做一个全局一致性校验防止相邻区域出现等级跳变。4.3 预警输出的可解释信息预警不能只给一个红灯绿灯否则用户根本不知道要不要行动。在预警卡片上我放了三个信息风险等级、主要贡献因子、置信区间。主要贡献因子是解释模型为什么会给出这个判断。实现上可以采用简单特征归因方法比如对输入的气象特征逐一置零观察输出变化量排序后取前三名。这样业务方看到的是“低温、低湿度、近两周ILI%上升趋势”这类人类能理解的原因而不是模型内部的抽象向量。置信区间来自多次Dropout推断同一个样本跑二十遍取预测分布的5%和95%分位数。这个操作成本很低但价值很高能够过滤掉模型在数据不足时的“糊弄式预测”也可以让决策者在置信度不够高时选择只提醒、不干预。4.4 上线前必须经历的并行验证期系统上线不是一跑了之。我当时采取的模式是新模型和旧规则模型并行运行两周双方输出一致就用新模型的结论双方不一致的时候人工介入核查看看差异出在哪些区域、哪些日期。并行验证期的意义不在于测试模型代码有没有bug而在于建立业务方对新系统的信任。另一个必须做的兜底措施是给预警加一个数据新鲜度标记。当输入数据更新链路中断超过24小时系统自动在预警卡片上标注“数据延迟”并把风险等级自动下调一档。这个设计非常朴素但能防止因为数据断供导致预警长期停在“高风险”状态消耗业务方的耐心。5. 常见问题与排查经验实录5.1 模型频繁闪烁报警最常遇到的问题就是预警等级在低风险和高风险之间来回跳。排查下来通常原因是输入的气象变量噪声太大比如某一天的温度骤降就被模型解读为疫情风险信号。处理方法是把气象特征做7天移动平均或者对预测结果做时序平滑比如采用指数加权平均把当日输出和前几日的输出融合起来。模型本身是可持续的但输出的后处理也真的很重要。这里有一个细节平滑不能只用当日和前一日权重衰减太慢会让预警变得迟钝太急又无法消除抖动。我用的是半衰期约三天的指数平滑即前三天的权重约为当日的一半。5.2 疫情真的来了模型反而反应迟钝这种问题最让人头疼也最容易引发对系统的信任危机。根因往往有两个第一训练数据里从来没有出现过类似强度的疫情模型外推能力本来就不行第二过度依赖气象信号的模型在气候条件没有明显变化时宁可维持在低风险。对策是设置一个独立的快变量通道当流感监测序列最近一周ILI%环比上升超过50%直接用规则触发高风险不再等模型预测结果。这是一个看起来很土、但很有效的兜底机制。规则触发的同时在预警卡片上注明“由快变量规则触发”方便业务方判断。5.3 数据缺口导致预测漂移节假日、医院系统切换、报告渠道异常都会导致某周数据缺失或异常偏低。一旦本周ILI%数据没有更新模型会把缺失值当作数值0处理预测立刻被打低。解决办法是保存历史同期均值作为基础值缺失时用基础值加一个小幅随机噪声填充并打上缺失标记作为额外特征。让模型学习到“数据缺失时自动降低权重”比简单填零要可靠得多。5.4 数据泄漏的隐蔽形式这里必须单独把数据泄漏拎出来说因为它是预警系统里最隐蔽的坑。除了前面说的标准化泄漏还有三种隐蔽形式滚动特征用了未来的值、缺失值用未来真实值填充、验证集用于特征筛选。这些泄漏很难在现场一眼看出来所以我在工程中坚持用流水线封装数据处理把fit和transform分开从不手写特征拼接步骤。为了验证有没有泄漏我还会做一个破坏性测试把标签序列随机打乱后重新训练如果模型分数仍然很高那大概率是有泄漏。5.5 排查速查表下面这个表是我在实际操作中一点一点攒出来的排查问题的时候按图索骥一般都能在半天内定位问题。现象可能原因快速定位方法修复方案预警等级频繁翻转气象特征噪声过大画出输入特征的周内波动曲线气象特征做7天移动平均疫情暴发但模型无动作训练集缺少类似极值样本查看模型对历史最大峰值的预测误差增加快变量规则触发通道某周预测值突然暴跌ILI%数据缺失被填零检查数据新鲜度标记是否触发用历史同期均值缺失标记填充验证指标和线上差距大数据处理发生时间泄漏打乱标签做破坏性测试用严格流水线隔离fit/transform区域间预警差异过大阈值没有分区标定按区域分别绘制误差分布分区标定阈值并做一致性校验6. 我的几点实际体会与后续扩展6.1 预警系统最重要的是让使用者敢信做这类模型最难的不是提升几个点的F1而是让使用者敢在预警发出后真的采取行动。如果系统十天里有七次误报再精准的技术也白搭。现在我做完一版模型第一件事不是看指标而是把历史预测结果和真实曲线画在同一张图上请业务方在图上找误报和漏报。这样能暴露很多指标无法反映的问题比如某些区域系统总是慢半拍、某些区域总是容易偏高然后再针对性做区域级阈值校准。6.2 从融合气象到融合行为数据气象数据是很好的开端但远期价值有限因为真正影响传播的还有行为因素。我现在在实验里已经开始叠加脱敏后的移动热度、重点场所人流密度、口罩佩戴率这类行为代理变量。注意这些变量的时效性更强滞后窗口更短通常只留一周以内否则会把预警信号带偏。做这类融合遵循一个原则宁可变量少也不要盲目堆特征时刻保持对模型因果链条的可解释性。变量一多每个特征的贡献就被稀释归因解释也就失去意义。6.3 一个容易忽略的细节训练频率这类模型绝不是训练一次就能一直用。气象季节性结构和流感流行谱都会逐年漂移我现在的节奏是每周增量更新一次模型每个月做一次全量重训练每个季度重新评估一次特征有效性。单纯做增量更新时学习率要打得比初始训练小很多否则旧知识会被新样本冲掉。这个细节听起来不起眼但有一次我偷懒没调整学习率模型在两周内就把季节性特征忘光了输出曲线变成一条直线。从那以后我每次训练都会写清楚学习率衰减计划并记录模型每次更新前后的预测漂移量。希望这个细节对正在探索类似系统的人有帮助。
流感预警这件事难点从来不在“发现”而在“提前”。我在复现某区域流感预警Demo系统时核心目标只有一个在流感监测曲线还没来得及明显抬头之前用AI气象数据融合的方式提前两周给出区域风险判断。很多人问我流感监测数据明明已经有了为什么还要融合气象因为真正的预警必须在数据变红之前发声而气象是少数能在感染链条形成之前就出现变化的“先行变量”。这个系统适合公共卫生相关团队、医院感染管理科室、时序预测算法的同学也适合所有想搞懂“多源数据融合到底怎么落地”的开发者。这篇文章就是我完整跑通一次这个项目后的经验记录从数据设计、模型选型、训练验证到上线后踩过的坑全部摊开讲。1. 项目背景流感预警的难点与气象数据的价值1.1 流感监测为什么总是慢半拍很多做时序预测的同行一听到“流感预警”第一反应是这不就是把流感监测数据喂给LSTM嘛有什么可做的真上手之后才发现恰恰是“监测数据”这几个字藏了最大的坑。流感监测的源头是哨点医院和实验室检测。从患者出现症状、到医院就诊、样本送检、结果上报、再到统计部门汇总一级一级走下来系统里能看到的最新周数据反映的其实是两周前甚至三周前的感染情况。也就是说等ILI%流感样病例占门诊就诊百分比曲线开始明显抬头的时候这一波风险实际已经在社区里传播了一圈。这个延迟不是哪一层环节偷懒而是上报机制本身决定的——背后有采样周期、审核流程、数据清洗多重步骤。更要命的是监测数据在疫情初期往往存在“漏报窗口”。很多人症状比较轻根本不会去医院真实传播规模被低估。等到就诊人数暴增数据曲线才陡峭起来但这时候再去调配疫苗、药物、床位已经晚了。所以我们需要一个不和监测数据同步延迟、反而能提前暴露风险的信息源而这正是气象数据能发挥作用的地方。1.2 气象变量与流感传播的物理联系我一直觉得气象数据能被用来做流感预警靠的不是大数据玄学而是几个非常扎实的物理机制。第一是病毒体外存活率。流感病毒在低温、低绝对湿度的环境里附着在飞沫或者气溶胶表面的存活时间会明显拉长感染性维持得更久。这里要特别提醒绝对湿度比相对湿度更关键。空气里实际水汽含量低的时候飞沫蒸发更快剩下的小颗粒更容易长时间悬浮在空气中增加吸入感染的概率。第二是人体防御机制。冷空气刺激会让鼻黏膜血管收缩纤毛摆动变慢呼吸道局部的免疫清除能力随之下降。相当于身体给病毒临时开了一扇门。第三是行为因素。气温低、日照弱的天气里聚集在室内密闭空间的活动变多空气流通变差病毒扩散阻力更小。这个链条虽然不像前两个那么“硬核”但对真实的流行病传播影响很大。第四是紫外线。冬春季日照时间短紫外线对病毒表面的灭活作用减弱环境中的病毒存活时间进一步延长。这四个机制叠在一起使得气象变量——尤其是温度和绝对湿度——成为流感传播链条里可以被提前观测的先行指标。气象预报系统本身已经能比较准确地预测未来一到两周的温度、湿度和降雨趋势把这个预测能力接进流行病预警模型就相当于给流感预警装了一个“前向传感器”。1.3 “提前两周”具体意味着什么预警提前两周到底价值在哪算一笔时间账就明白了。流感从感染到发病平均约2天从发病到重症或者去就诊中间还要几天哪怕哨点数据是实时更新疫情上升信号出现时个体层面已经来不及通过接种疫苗来获得保护了。而提前两周意味着还有时间做几件真正有效的事提醒高危人群尽快完成接种、调节医院发热门诊和抗病毒药物的储备、在重点场所启动通风和环境消毒提醒、给公众发布风险提示。两周不是一个拍脑袋的数字它的上限来自气象预报能力的边界——预报超过两周以后可信度快速衰减下限来自流感传播周期——太短了则根本来不及执行任何干预动作。所以我在这类系统里通常把预测窗口切成两段近两周输出“风险等级”更远的输出“趋势方向”而不是强行给出一个精确病例数。精确病例数的预测误差太大反而会让业务方失去信任风险等级加趋势方向既有可执行性又有稳定性。2. 整体架构设计从数据到预警的完整链路2.1 数据分层标签、特征与辅助信号这个Demo把数据分成三层角色完全不同处理方式也不同。第一层是标签数据也就是要预测的目标每周ILI%百分比序列、实验室流感阳性检出率、医院发热门诊量。这三个指标其实是对同一波疫情的不同观测角度我建议以ILI%为主、阳性率作为校正项不要全部塞进模型当并列输入。第二层是气象特征日平均温度、昼夜温差、相对湿度、绝对湿度可以用温度和相对湿度计算得到、风速、降雨量、日照时数。其中绝对湿度、平均温度、日照时数是优先级最高的三个变量。第三层是辅助数据空气质量指数、重点场所人群热力指数、药品销量指数等等。辅助数据的价值不是“多一个特征”而是帮助模型排除短期波动干扰。比如一场普通降温也可能让门诊量增加如果此时药品销量指数没有联动上升就可以判断不是流感暴发主导。很多人一开始就把几十个变量胡乱拼在一起结果模型可解释性很差预测也不稳定。数据分层的作用就是让标签数据决定模型学什么、气象特征决定提前预测的依据、辅助数据负责消减误报。2.2 时空对齐这块处理不好模型分数再高也是假的我见过不少项目模型效果特别好提交结果时预测曲线和真实曲线几乎重叠结果一查发现是时空对齐出了问题。最基本的一点气象数据通常是天级或者小时级流感监测数据通常是周级两边必须统一时间标尺。流感监测周通常从周一开始气象数据按自然日汇总的话周一对应的周标签就可能错位。空间上更麻烦流感数据按行政区域统计气象数据按网格发布直接把一个网格套到整个区域上人口分布不均匀的问题就被忽略了。我们当时的处理思路是先把研究区域按行政边界切分然后对每一个行政区取区内气象网格值的面积加权平均。这比简单取中心点更合理计算量也完全可控。时间滞后特征的构造也不能忽略。温度和绝对湿度对未来疫情的影响不是同步的通常要滞后一到三周。建议在建模之前先做互相关分析画出每个气象变量与ILI%在不同滞后周数上的相关系数再根据峰值确定滞后期而不是凭感觉把所有变量一股脑塞进模型。2.3 为什么“融合”比单一数据强有人会问既然加入了气象特征为什么不干脆做个纯气象模型答案是流感监测序列里包含了很多气象之外的“真实行为信息”比如节假日人口流动、疫苗接种进度、学校开学时间表但纯监测序列模型又会在疫情真正暴发前毫无反应因为序列本身还没有开始变化。气象数据和监测数据的价值是互补的监测序列提供“现状基线”气象数据提供“变化的前瞻信号”。两者融合模型才能在曲线还平的时候提前做出方向性判断。这个逻辑和我们平时出门穿衣服类似——你既看今天实际冷不冷也看未来几天的天气预报。只看温度计会被突然降温打得措手不及只看预报又可能忽略了当下的特殊情况两个信息一起看判断才准。3. 核心实现模型选型、训练与验证3.1 模型选型从回归到双通道时序网络这个任务本质上是一个多变量时序预测问题不是图像问题也不是简单分类问题。经典回归模型比如线性回归、随机森林用滑窗特征也能做但缺点很明显无法刻画疫情序列的长期依赖也很难利用气象序列本身的演化趋势。SARIMA虽然适合单变量周期序列但加入外部协变量时需要手工处理季节项和滞后结构扩展性不好。常规的LSTM单通道模型效果会比回归好但它把气象特征和流感历史拼在一个输入向量里模型很难真正学到“气象变化如何传导到疫情”的因果结构。到后面测试下来我发现最稳的方案是双通道序列模型一个通道吃过去六到八周的ILI%历史序列另一个通道吃过去一到两周的气象特征序列两个通道分别用LSTM或GRU编码最后把隐状态拼起来映射到未来两周的输出。这个结构的直观解释是流感通道负责“现在的基础水平”气象通道负责“未来的推动力”。3.2 训练验证里的时间边界问题这个任务最大的验证陷阱是时间泄漏。一定不能用随机划分训练集和验证集必须按时间先后切。我们用滚动验证假设历史数据有三年先拿前两年训练在第三年第一周做预测然后逐步把验证窗口向前推每次都保证训练集只包含验证窗口之前的数据。标准化也必须在训练集上拟合再应用到验证集。如果整个数据集一起归一化模型分数会被高估现实中根本达不到那个效果。评估指标上我一般同时看RMSE、MAE、方向命中率、峰值误差和暴发识别F1。RMSE和MAE衡量数值偏差但公共卫生预警更关心拐点方向对不对、峰值时间有没有偏。所以在一套预警系统里方向命中率和F1往往比RMSE更敏感。模型在数值上差零点几可能不致命但方向判断错了会直接导致决策失误。3.3 核心代码骨架下面这个骨架完全可以在小规模数据上跑通。它省略了很多工程细节但保留了我认为最重要的双通道结构。输入是过去7周的流感序列和过去7天的气象特征输出是未来两周的风险评分0到1后续再接阈值判断。import torch import torch.nn as nn class FluRiskNet(nn.Module): def __init__(self, meteo_dim, hidden_size64): super(FluRiskNet, self).__init__() self.flu_lstm nn.LSTM(1, hidden_size, batch_firstTrue) self.meteo_lstm nn.LSTM(meteo_dim, hidden_size, batch_firstTrue) self.head nn.Sequential( nn.Linear(hidden_size * 2, hidden_size), nn.ReLU(), nn.Dropout(0.3), nn.Linear(hidden_size, 14) ) def forward(self, flu_seq, meteo_seq): _, (h_flu, _) self.flu_lstm(flu_seq) _, (h_meteo, _) self.meteo_lstm(meteo_seq) feat torch.cat([h_flu[0], h_meteo[0]], dim-1) return self.head(feat) # 输出未来14个时间点输出维度是14对应未来两周每一天或每一周的风险评分。实际使用时不直接拿原始回归值而是对14个输出做统计汇总比如取最大值、均值再映射成风险等级。这个骨架刻意做得比较简单好处是稳定、好调、不容易过拟合。如果数据量很大可以在气象通道后面加一层注意力机制让模型自己学哪些天气变量对未来疫情影响更大。3.4 关键超参数与训练技巧历史窗口长度是影响效果最明显的超参数。流感通道取六到八周比较合适太短学不到季节性趋势太长容易引入无关的历史噪声。气象通道通常取一到两周因为气象对传播的影响时效性很强三周以前的天气对当前疫情几乎没有解释力。训练时我用早停法验证集损失连续五轮不下降就停止。学习率从1e-3开始配合余弦退火调度。Dropout设置在0.3左右太高会让模型欠拟合太低则有训爆风险。另一个容易忽略的点是模型输出的不是“未来两周每一天的独立预测”而是“基于当前状态未来两周的变化趋势”。所以在构造训练样本时我采用的是多步滑动窗口每个样本的标签是从当前周开始的未来两周风险强度而不是单个时间点的预测值。这样训练出来的模型更贴近预警业务的需求。4. 实操过程从数据清洗到模型上线的完整记录4.1 从原始数据到可训练样本我选择以周尺度作为训练尺度主要有两个原因流感监测数据天然是周粒度把气象日数据重采样到周能抹掉短期随机波动也更方便复现和解释。第一步从公开气象接口拿过去三年每日气象数据重采样成周计算周平均温度、周平均绝对湿度、周平均风速、周累计日照时数。第二步把流感监测数据按监测周对齐计算ILI%周序列。第三步对缺失周做向前填充然后构造滞后特征比如T-1周的绝对湿度、T-2周的昼夜温差。第四步把三个样本集合严格按时间顺序切分。这里有一个关键细节所有特征标准化都在训练集上完成验证集和测试集的标准化参数从训练集继承。如果重新计算验证集的均值和标准差就会无意中把验证集的信息泄漏给模型。from sklearn.preprocessing import StandardScaler scaler StandardScaler() train_meteo_scaled scaler.fit_transform(train_meteo) valid_meteo_scaled scaler.transform(valid_meteo) test_meteo_scaled scaler.transform(test_meteo)就这么三行代码看起来简单但能避免一个非常隐蔽的坑。同样的逻辑适用于缺失值填充如果验证集缺失周用全序列均值填充那也是泄漏。4.2 风险等级与预警阈值的设定模型输出的风险评分只是中间产物真正对接业务的是风险等级。我参考了很多区域的做法以历史同期非流行季节的ILI%均值作为基线当预测值超过基线1.5个标准差判定为低风险超过3个标准差判定为高风险而一旦预测连续两周上升且上升幅度超过20%直接触发“趋势预警”标记。这些阈值不是拍脑袋定的而是用过去三年数据做过模拟回溯后确定的。具体做法是把历史数据切到当前周之前模型只利用当时能获得的信息进行预测然后对比预测结果和真实疫情曲线统计误报和漏报数量反复调整阈值直到误报漏报的加权损失最小。注意阈值不是每个区域都一样的。不同气候特点的区域内流感季节形态差异很大统一阈值会导致误报率两极分化。所以我的习惯是给每个聚集区域单独标定一套阈值外层再做一个全局一致性校验防止相邻区域出现等级跳变。4.3 预警输出的可解释信息预警不能只给一个红灯绿灯否则用户根本不知道要不要行动。在预警卡片上我放了三个信息风险等级、主要贡献因子、置信区间。主要贡献因子是解释模型为什么会给出这个判断。实现上可以采用简单特征归因方法比如对输入的气象特征逐一置零观察输出变化量排序后取前三名。这样业务方看到的是“低温、低湿度、近两周ILI%上升趋势”这类人类能理解的原因而不是模型内部的抽象向量。置信区间来自多次Dropout推断同一个样本跑二十遍取预测分布的5%和95%分位数。这个操作成本很低但价值很高能够过滤掉模型在数据不足时的“糊弄式预测”也可以让决策者在置信度不够高时选择只提醒、不干预。4.4 上线前必须经历的并行验证期系统上线不是一跑了之。我当时采取的模式是新模型和旧规则模型并行运行两周双方输出一致就用新模型的结论双方不一致的时候人工介入核查看看差异出在哪些区域、哪些日期。并行验证期的意义不在于测试模型代码有没有bug而在于建立业务方对新系统的信任。另一个必须做的兜底措施是给预警加一个数据新鲜度标记。当输入数据更新链路中断超过24小时系统自动在预警卡片上标注“数据延迟”并把风险等级自动下调一档。这个设计非常朴素但能防止因为数据断供导致预警长期停在“高风险”状态消耗业务方的耐心。5. 常见问题与排查经验实录5.1 模型频繁闪烁报警最常遇到的问题就是预警等级在低风险和高风险之间来回跳。排查下来通常原因是输入的气象变量噪声太大比如某一天的温度骤降就被模型解读为疫情风险信号。处理方法是把气象特征做7天移动平均或者对预测结果做时序平滑比如采用指数加权平均把当日输出和前几日的输出融合起来。模型本身是可持续的但输出的后处理也真的很重要。这里有一个细节平滑不能只用当日和前一日权重衰减太慢会让预警变得迟钝太急又无法消除抖动。我用的是半衰期约三天的指数平滑即前三天的权重约为当日的一半。5.2 疫情真的来了模型反而反应迟钝这种问题最让人头疼也最容易引发对系统的信任危机。根因往往有两个第一训练数据里从来没有出现过类似强度的疫情模型外推能力本来就不行第二过度依赖气象信号的模型在气候条件没有明显变化时宁可维持在低风险。对策是设置一个独立的快变量通道当流感监测序列最近一周ILI%环比上升超过50%直接用规则触发高风险不再等模型预测结果。这是一个看起来很土、但很有效的兜底机制。规则触发的同时在预警卡片上注明“由快变量规则触发”方便业务方判断。5.3 数据缺口导致预测漂移节假日、医院系统切换、报告渠道异常都会导致某周数据缺失或异常偏低。一旦本周ILI%数据没有更新模型会把缺失值当作数值0处理预测立刻被打低。解决办法是保存历史同期均值作为基础值缺失时用基础值加一个小幅随机噪声填充并打上缺失标记作为额外特征。让模型学习到“数据缺失时自动降低权重”比简单填零要可靠得多。5.4 数据泄漏的隐蔽形式这里必须单独把数据泄漏拎出来说因为它是预警系统里最隐蔽的坑。除了前面说的标准化泄漏还有三种隐蔽形式滚动特征用了未来的值、缺失值用未来真实值填充、验证集用于特征筛选。这些泄漏很难在现场一眼看出来所以我在工程中坚持用流水线封装数据处理把fit和transform分开从不手写特征拼接步骤。为了验证有没有泄漏我还会做一个破坏性测试把标签序列随机打乱后重新训练如果模型分数仍然很高那大概率是有泄漏。5.5 排查速查表下面这个表是我在实际操作中一点一点攒出来的排查问题的时候按图索骥一般都能在半天内定位问题。现象可能原因快速定位方法修复方案预警等级频繁翻转气象特征噪声过大画出输入特征的周内波动曲线气象特征做7天移动平均疫情暴发但模型无动作训练集缺少类似极值样本查看模型对历史最大峰值的预测误差增加快变量规则触发通道某周预测值突然暴跌ILI%数据缺失被填零检查数据新鲜度标记是否触发用历史同期均值缺失标记填充验证指标和线上差距大数据处理发生时间泄漏打乱标签做破坏性测试用严格流水线隔离fit/transform区域间预警差异过大阈值没有分区标定按区域分别绘制误差分布分区标定阈值并做一致性校验6. 我的几点实际体会与后续扩展6.1 预警系统最重要的是让使用者敢信做这类模型最难的不是提升几个点的F1而是让使用者敢在预警发出后真的采取行动。如果系统十天里有七次误报再精准的技术也白搭。现在我做完一版模型第一件事不是看指标而是把历史预测结果和真实曲线画在同一张图上请业务方在图上找误报和漏报。这样能暴露很多指标无法反映的问题比如某些区域系统总是慢半拍、某些区域总是容易偏高然后再针对性做区域级阈值校准。6.2 从融合气象到融合行为数据气象数据是很好的开端但远期价值有限因为真正影响传播的还有行为因素。我现在在实验里已经开始叠加脱敏后的移动热度、重点场所人流密度、口罩佩戴率这类行为代理变量。注意这些变量的时效性更强滞后窗口更短通常只留一周以内否则会把预警信号带偏。做这类融合遵循一个原则宁可变量少也不要盲目堆特征时刻保持对模型因果链条的可解释性。变量一多每个特征的贡献就被稀释归因解释也就失去意义。6.3 一个容易忽略的细节训练频率这类模型绝不是训练一次就能一直用。气象季节性结构和流感流行谱都会逐年漂移我现在的节奏是每周增量更新一次模型每个月做一次全量重训练每个季度重新评估一次特征有效性。单纯做增量更新时学习率要打得比初始训练小很多否则旧知识会被新样本冲掉。这个细节听起来不起眼但有一次我偷懒没调整学习率模型在两周内就把季节性特征忘光了输出曲线变成一条直线。从那以后我每次训练都会写清楚学习率衰减计划并记录模型每次更新前后的预测漂移量。希望这个细节对正在探索类似系统的人有帮助。
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
