深度学习新冠疫情预测实战：从数据清洗到LSTM时间泄漏避坑-北京尧图网络

最近接到一个有点特殊的小任务用深度学习做新冠人数预测。乍一听很像那种“拿个时间序列套个LSTM”的入门项目真做起来才发现这活儿比想象中要脏、要细、要磨人。从数据清洗、特征构造、模型选型到验证集设计每一步都有不少坑而且这些坑和普通的时间序列预测项目还不太一样尤其是“时间泄漏”这个问题简直防不胜防。这篇文章我打算完整记录这个预测项目的全过程。不是只讲怎么跑通代码而是把我在实操过程中踩过的坑、验证过的方案、最后留下来的可行路径都拆开讲清楚。适合三类人看想做深度学习时序项目的初学者、已经有基础但想系统梳理预测流程的人以及需要快速做出一版可解释预测结果的产品或运营同学。1. 先搞清楚一件事疫情数据不是拿来就能用的很多教程拿到数据就直接df[cases].plot()然后开始滑动窗口训练。真这么干后面基本都会在验证阶段翻车。疫情数据有它自己的脾气第一关就是把这份数据“捋顺”。1.1 原始数据长什么样我当时拿到的数据来自某个公开的疫情仓库字段大概是日期、地区、累计确诊、新增确诊、累计死亡、新增死亡、治愈数可能还有一些诸如“密接人数”之类的辅助字段。听起来挺规整的但打开之后全是惊喜。第一个问题是日期不连续。周末有时候不上报或者某天的数据延迟补录导致时间轴上出现空洞。对于时间序列模型来说日期连续性是命根子。所以第一步就是重新生成一个完整的日期范围把缺失日期找出来再用插值或者前向填充补齐。第二个问题是累计值和新增值之间的不一致。累计确诊明明应该是前一天的累计加当天新增但手工录入的时候经常出现偏差。我当时的处理方式是重新构造一列新的累计数等于上一日累计加当日新增如果对不上优先修正累计数那一列。新增数一般不要动因为后面预测的核心目标大概率是新增值新增的原始口径要比累计值更重要。第三个问题是地区粒度。不同地区的上报节奏、统计口径完全不一样如果你拿的是一个“全国汇总”数据那趋势相对平滑模型好做不少如果拿的是某个城市的细分数据那波动会大得多并且会受到局部筛查、密接追踪等因素的突然冲击。不要一上来就想着把所有地区揉成一个序列我最后选择的是先做单个地区的单序列跑通之后再考虑多地区联合建模。1.2 特征工程不仅有时间序列还有干预因素只看“新增确诊”这一条序列做预测理论上是可以的但效果通常很一般。原因是疫情数据不是一个“自然形成”的时间序列它强烈受政策干预影响——封控、全员核酸、隔离政策调整都会让曲线出现肉眼可见的拐点。这些干预信息不会自己出现在数据里。所以我做了两件比较关键的事。第一件是加入了“干预标记”特征。我把政策调整的关键日期做一个0/1特征或者用更丰富的离散值表示不同的管控等级。比如从正常到加强检测、到局部封控、到全面封控分别编码成0、1、2、3。这个特征会让模型在拐点附近更容易学到“为什么在这里突然上升或下降”。注意这个编码是我根据公开新闻整理的其中不可避免存在主观判断所以后来我在测试时也专门对比过“带干预特征”和“不带干预特征”的差异结论是有干预特征的结果会晚一步但更稳没有干预特征的结果在趋势上更平滑但在拐点处完全失灵。第二件事是构造了7日移动平均和差分特征。新增确诊这种数据具有很强的星期效应周末上报人数少周初又会积压所以原始值里面充满了周期性噪声。我做了两种衍生序列一种是新增确诊_7日均值另一种是新增确诊_7日差分。前者用来帮助模型理解趋势后者用来帮助模型捕捉加速度变化。import pandas as pd df[date] pd.to_datetime(df[date]) df df.sort_values(date).reset_index(dropTrue) # 关键完整填充日期范围 full_date pd.date_range(startdf[date].min(), enddf[date].max(), freqD) df df.set_index(date).reindex(full_date).reset_index() df[daily_new] df[daily_new].interpolate(limit_directionboth) # 构造衍生特征 df[new_7d_avg] df[daily_new].rolling(7, min_periods1).mean() df[new_7d_diff] df[daily_new].diff(7)这一段代码看起来不复杂但做好之后后面模型的输入质量就完全不一样了。千万别跳过这步直接进模型。1.3 数据版本切分训练/验证/测试要按时间走普通机器学习项目喜欢train_test_split(random_state42)随机打乱但时序预测项目绝对不要这么干。疫情数据有强时间依赖如果训练集里混入了未来信息模型在验证集上的表现会被严重高估。我采用的是严格的时间顺序切分训练集用最后一段时间的60%数据验证集用接下来20%测试集用最后20%。这里有个很容易忽略的细节验证集和测试集不能紧贴着训练集后面切。因为疫情曲线的波动非常剧烈如果验证集正好包含了某个政策拐点那么模型在这个窗口上的误差会很大你可能会误以为模型不行。我当时留了一个“过渡缓冲带”也就是在训练集结束和验证集开始之间加了一段既不参与训练也不参与评估的数据大概7天左右。这样做的好处是让模型在预测时不会遇到“刚训练完就要预测完全没见过的突变”这种场景损失函数曲线和验证指标也会更稳定。2. 模型选型为什么我最终选了LSTM而不是ARIMA或Transformer确定好数据之后接下来就是选模型。在动手写代码之前我花了大概一天时间做对比分析。这里不打算把论文搬出来而是直接从实操角度说说我在几类模型之间的取舍。2.1 传统时序模型在这组数据上为什么不够用最开始我试的是ARIMA因为它足够简单而且很多人的直觉是“疫情人数看起来就是个随机波动的时间序列”。ARIMA的强项在于捕捉线性自相关结构但疫情数据至少有两个特征让它很难受第一是高波动性和突变性政策干预一出来序列的自相关系数结构直接崩掉第二是外部特征不好加ARIMA是一个纯粹的序列模型你很难把“管控等级”“检测能力”这些0/1特征自然地加进去虽然可以用外生变量的ARIMAX但实操中经常遇到参数根本不收敛的情况。我也试过LightGBM这类树模型把过去N天的新增人数、移动平均、差分、干预标记都作为特征丢进去做回归。效果其实不差单从指标上看甚至在某些区间优于LSTM。但它有个致命问题预测未来多天时你没法逐日滚动因为第T1天的预测值不会变成第T2天的输入特征只能把所有未来时间步当作独立样本一次性预测这会丢掉时间依赖。这类型让我最终放弃了树模型作为主模型。2.2 LSTM的基本原理和本项目中的输入输出形态LSTM是循环神经网络的一种它的核心思想是给网络加了一条“记忆线”让信息可以跨过多个时间步传递。你不需要懂太多数学细节只要理解它在处理序列时会维护一个隐藏状态和一个细胞状态每个时间步都读取当前输入同时结合上一步的记忆然后输出新的预测。在我们这个项目里输入形态是过去14天每天的“新增确诊、7日均值、7日差分、干预标记”输出是第15天的新增确诊。你可以把它理解成给模型看两周的走势让模型“感觉”一下现在处于什么阶段然后猜下一天的数字。import torch import torch.nn as nn class CovidLSTM(nn.Module): def __init__(self, input_size, hidden_size, num_layers, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout ) self.regressor nn.Sequential( nn.Linear(hidden_size, 32), nn.ReLU(), nn.Dropout(dropout), nn.Linear(32, 1) ) def forward(self, x): out, _ self.lstm(x) # out shape: (batch, seq_len, hidden_size) last out[:, -1, :] # 取最后一个时间步 return self.regressor(last).squeeze(-1)这里是标准的PyTorch LSTM回归结构。input_size就是特征维度hidden_size我设的是64num_layers用2层。它和很多把整条序列作为输入、把全部时间步输出做分类的模型不一样回归任务取最后一个时间步的隐状态就够了。2.3 和更复杂的Transformer对比值不值得上最近Transformer在时序预测上很火很多文章都说Transformer可以替代LSTM。我也试着搭了一个简单的时间序列Transformer用位置编码加自注意力层来建模。结果很有意思在短序列14天窗口上它的表现并没有比LSTM好训练时间却长得多而且更容易过拟合。我的理解是Transformer的自注意力机制擅长在长序列中捕捉全局依赖但疫情数据本身就比较短且具有很强的近期依赖——前一天的数值对第二天的影响才是最关键的。这时候LSTM的归纳偏置反而成了优势它天然地按时间顺序处理信息不会像Transformer那样可以“跳过”前面的时间步。如果你后续要做非常长的序列预测比如预测60天以上可以认真考虑Transformer但如果只是预测未来一周到两周LSTM加精心设计的特征组合性价比更高。3. 搭一个能复现的预测Pipeline数据窗口化到训练模型结构定下来后最耗时间的其实是数据pipeline。这一步非常机械但每一个细节都直接影响训练结果。3.1 滑动窗口的构造与超参选择我用了过去14天预测第15天的窗口配置。这个14不是拍脑袋拍的而是基于对数据尺度的判断两周刚好能覆盖一个完整的周期既能看到趋势又不会引入太远古的信息。你可以用类似原则如果数据有明显季节性比如7天周期那么窗口至少要7天窗口越大信息越多但噪声也越多。窗口构造的代码大概是这样的def make_dataset(data, feature_cols, target_col, seq_len14): X, y [], [] for i in range(len(data) - seq_len): X.append(data[i:i seq_len][feature_cols].values) y.append(data[i seq_len][target_col]) return torch.tensor(X, dtypetorch.float32), torch.tensor(y, dtypetorch.float32)注意我这里没有对数据做shuffle因为时间序列的样本天然有序。批次采样时我采用顺序采样器每批包含相邻的样本。如果你的库默认会shuffle记得关掉。3.2 归一化和反归一化的坑这个坑我踩得很深必须重点说。LSTM对输入特征的尺度很敏感不归一化很容易梯度爆炸或者收敛极慢。我用的方法是对每个特征分别做MinMax归一化把数值映射到0到1之间。但关键是MinMaxScaler只能fit在训练集上不能fit在验证集或测试集上。原因很简单如果你用全量数据的最大值和最小值那等于把未来信息泄漏到了训练过程中。我当时犯的错误是先把全部特征scaler.fit_transform再做切分。结果训练集和验证集都用了同一个全局scaler模型确实“看过”了未来数据的范围。后来我在最终的评估阶段发现预测值始终偏小排查了很久才发现是这个原因。纠正之后验证集的MAE立刻下降了大概15%。反归一化也有讲究。如果你想输出真实的新增确诊人数需要在预测结束后对预测目标列单独做一次反变换。这里别用整个特征矩阵的scaler去反变换而是只对目标列使用独立的scaler。否则不同特征的不同量纲会把预测结果带偏。3.3 PyTorch训练代码骨架下面是我最终用的训练循环骨架它经过了多次调整已经去掉了很多不必要的装饰。from torch.utils.data import TensorDataset, DataLoader X_train, y_train make_dataset(train_df, feature_cols, daily_new) X_val, y_val make_dataset(val_df, feature_cols, daily_new) train_loader DataLoader(TensorDataset(X_train, y_train), batch_size32, shuffleFalse) val_loader DataLoader(TensorDataset(X_val, y_val), batch_size32, shuffleFalse) model CovidLSTM(input_sizelen(feature_cols), hidden_size64, num_layers2, dropout0.2) criterion nn.MSELoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.ReduceLROnPlateau( optimizer, modemin, factor0.5, patience5 ) best_val_loss float(inf) patience_counter 0 for epoch in range(100): model.train() epoch_loss 0.0 for X_batch, y_batch in train_loader: optimizer.zero_grad() pred model(X_batch) loss criterion(pred, y_batch) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() epoch_loss loss.item() model.eval() val_loss 0.0 with torch.no_grad(): for X_batch, y_batch in val_loader: pred model(X_batch) val_loss criterion(pred, y_batch).item() val_loss / len(val_loader) scheduler.step(val_loss) if val_loss best_val_loss: best_val_loss val_loss torch.save(model.state_dict(), best_model.pt) patience_counter 0 else: patience_counter 1 if patience_counter 15: break几个容易被忽视的点梯度裁剪clip_grad_norm_LSTM训练中特别容易梯度爆炸裁剪到1.0可以稳住训练学习率调度器用的是ReduceLROnPlateau它会等验证损失不再下降的时候把学习率减半这比固定学习率效果好很多早停用的15个epoch的耐心值避免在验证集上过拟合。3.4 训练中的loss震荡和早停训练时我注意到即使数据集不大一年多的数据滑窗后大概几百个样本loss曲线依然会有明显的抖动。这不是一个好消息也不是坏消息而是正常的。loss抖动主要来自相邻batch的数据分布不一致。疫情曲线在上升期的时候某一段窗口内都是快速增长的样本loss天然偏高到了平台期loss又迅速回落。所以不要因为一个batch的loss飙升就觉得模型崩了重点要看验证集loss的趋势。我自己的经验是前20个epoch验证集loss下降得很快20到50个epoch之间波动50个epoch之后开始出现缓慢上升的迹象这时候早停就起作用了。4. 我踩过最深的坑时间泄漏和验证集设计这一节我觉得是全文最有价值的一部分。时间泄漏这个问题几乎每个做过时序预测的人都会遇到但它非常隐蔽排查起来很费功夫。4.1 随手shuffle导致的时间泄漏我第一次跑pipeline的时候图省事直接用了sklearn的train_test_split还设置了shuffleTrue。结果模型在验证集上表现好得惊人MAE只有个位数我当时心里还美滋滋的。后来冷静下来一想这完全不合理因为新增确诊人数每天波动即便很小也大概率不可能是这个误差量级。我检查后发现由于训练集和验证集来自同一个全局池验证集中某些样本的输入窗口实际上包含了和训练集重叠的时间段。说得更直接一点模型见过和验证样本高度相似的连续序列它只需要把上一天的输出“平移”过来就能得到非常准的预测。这种泄漏不会让模型变聪明只会让评估曲线失真。修复方式很简单——严格按时间顺序切分且切分前不打乱。4.2 归一化算到测试集上的泄漏这个问题我在前面已经提到过一次但它值得单独展开。很多教程里的MinMaxScaler都是直接在全量数据上调用fit_transform这在纯分类问题上可以在时间序列上就是泄漏。原因在于MinMaxScaler需要计算全局最小值和最大值而测试集里的数据一旦参与了最小/最大值的计算模型在做特征缩放时就已经接触到了未来数值的“边界”这会轻微改善测试集上的数值稳定性。虽然很多时候这个影响不如shuffle那么致命但它会让你的基线指标虚高不利于后续判断特征工程和模型调参带来的真实提升。正确的姿势是from sklearn.preprocessing import MinMaxScaler feature_scaler MinMaxScaler() target_scaler MinMaxScaler() # 只对训练集做fit然后transform训练集/验证集/测试集 train_encoded feature_scaler.fit_transform(train_df[feature_cols]) val_encoded feature_scaler.transform(val_df[feature_cols]) test_encoded feature_scaler.transform(test_df[feature_cols])同理目标变量的scaler也只能用训练集的y来fit。4.3 L2正则化和多任务loss调整的经验L2正则化在LSTM里不是直接加在损失函数上的而是通过weight_decay参数加到优化器里。我试过几组值发现weight_decay1e-4比不加要稳但再大比如1e-2模型会出现欠拟合预测曲线变得非常平。如果你同时要预测新增确诊、新增死亡等多个目标就会遇到多任务loss的问题。虽然我这个项目最后只保留了新增确诊主任务但在中间版本里确实尝试过同时预测两个目标。那时最头疼的就是要不要把两个loss直接相加。实测下来直接相加的结果是数量级大的任务会主导梯度模型会专注优化新增确诊而新增死亡的预测几乎学不到东西。我一个直观的方案是给每个loss加可学习权重让模型自己调整任务的重要程度。也可以用更工程化的办法先固定训练几个epoch观察两个任务的loss量级然后按量级反比设置一个静态权重比如新增确诊loss是新增死亡loss的20倍那就把新增死亡的权重设成20。如果你不想引入太多复杂度这个静态方案已经够用了。5. 预测结果怎么看曲线和不确定性模型训练完了不是画一张漂亮的图就结束了。最重要的问题是怎么解读预测曲线什么时候该相信它什么时候必须警惕5.1 预测新增人数的解读方式我在测试集上做了两种预测一种是用真实历史窗口做“一步预测”也就是给模型真实的过去14天预测未来第15天另一种是“多步滚动预测”用模型自己的输出作为下一步输入连续预测未来7天。一步预测的意义在于评估模型学到了多少时序模式多步滚动预测的意义更接近真实应用。我在最终展示给业务方的就是多步滚动结果。要注意的是多步滚动的误差会累积预测到第7天的时候误差通常是第1天的两倍甚至三倍。不是说模型不好这是时序预测的天然属性。5.2 误差落在什么范围算正常我对比了几个指标训练集MAE、验证集MAE、测试集一步MAE、测试集多步MAE。最终得到的地方训练集MAE大概是测试集一步MAE的60%左右说明模型没有严重过拟合测试集一步MAE为个位数但多步MAE明显抬升。不要只盯着MAE一个指标我同时参考了RMSE因为RMSE对异常值更敏感能反映预测在拐点处的偏差程度。疫情数据中往往存在一些异常尖峰RMSE会明显高于MAE这个差异本身就是信息如果RMSE比MAE大很多说明模型在尖峰处表现不好你需要去检查是不是数据里存在未处理的异常值或者干预特征没有覆盖到。5.3 这个项目的边界为什么不能直接用于决策我只强调一件事模型预测的是“在给定干预特征和历史数据下最可能的新增人数”它完全无法判断将来某一天会不会出台新政策。如果政策在预测窗口内发生了重大变化模型给出的预测基本会失效。我遇到过最典型的情况测试集里包括一个周末后的数据因为周末上报延迟周一新增确诊大幅反弹模型从历史模式中学到了“周一可能会反弹”但它无法预判反弹的幅度会不会因为一次全员核酸而翻倍。所以我在给团队的交付文档里专门写了模型局限性章节建议只把预测结果用于“提前准备资源”的大致参考而不是作为精确判断依据。6. 还能怎么做从单步到多步从单模型到集成如果只是想完成一个入门项目前面五节的内容已经够了。但如果你想把这个预测项目做得更扎实下面这些方向值得继续挖。6.1 多步预测的两种方案第一种是递归预测也就是传说中的“自回归”。把第T1天的预测结果作为输入的一部分继续预测T2循环到目标长度。这种方法实现简单但误差会逐日累积尤其是拐点处很容易偏离方向。第二种是直接多步预测把模型的最后一层改成多个输出节点一次输出未来7天或14天的预测值。好处是不会累积误差坏处是模型一次要学的东西更多数据量不够时容易学不充分。我实测过在当前数据量下直接多步预测的短期效果不如递归预测但当预测长度超过7天时直接多步的优势开始显现。一个可用的折中做法是用递归预测生成未来7天然后把这7天的预测值合并成新的历史窗口继续往后递归但每递归一步都用验证集误差对预测做一次轻量校准。6.2 把外部特征接进来从纯序列到混合输入前面提过“干预标记”特征这其实是一种最简单的外部特征。更进一步你还可以加入人口流动指数、检测数量、密接人数等数据。这样做可以让模型在政策变化上有更细腻的感知。但引入外部特征的前提是这些特征在预测时也是已知的或者至少你有可靠的预估。比如检测数量如果预测的是未来7天那么未来7天的检测数量是未知的你需要单独做一个预测检测数量的模型或者用历史均值替代。这种“特征本身也要预测”的问题在实际业务场景中很难处理。我的建议是优先选择那些有政策滞后性的特征比如“管控等级”在短期内不会天天变这种特征对未来预测是有意义的。6.3 部署和自动化的小建议如果你要把这个模型部署成一个每天自动更新预测的服务而不是一次性实验那有几个细节要提前想清楚。第一是数据源和格式要稳定最好写一个独立的fetch_data()函数每天固定时间拉取最新数据自动做插值和特征构造。第二是模型要每天重训因为疫情趋势变化很快用两个月前的模型预测今天的情况几乎必挂。重训的频率可以是每天一次训练时间通常也就在几分钟到十几分钟。第三是要保存好当前scaler和模型权重并且记录每次训练用的数据版本。我建议至少保留最近30天的backtest结果这样能随时检查模型是否在一个合理范围内而不是上线后突然失效。我在实际部署这个预测服务时还遇到过一个很烦的问题原始数据源某天突然改了字段名导致pipeline直接报错而调度任务没有重试机制结果当天没有生成预测结果。后来我加了数据源schema校验和失败重试机制顺便加了异常告警这才算真正稳定下来。这些看起来和深度学习关系不大但在真实项目中能不能稳定产出预测结果往往比模型本身更重要。最后如果你也准备做一个类似的深度学习预测项目我给一个最核心的建议把验证集当作“敌人”永远不要让模型以任何方式接触验证集的信息。数据切分、特征缩放、窗口滑动、超参选择每一步都要假设验证集是未来。做到这一点你的模型不一定是最聪明的但一定是最诚实的。

深度学习新冠疫情预测实战：从数据清洗到LSTM时间泄漏避坑

相关推荐

Python机器学习电商商品分析与预测实战指南

查询每个用户最新一条记录？SQL分组取最大行的5种写法与避坑指南

跨平台壁纸设置实战：macOS、Windows与GNOME实现解析

更多资讯

基于PCA9422与PIC18F47Q10的便携设备电源管理方案详解

基于HTML的品优购电商项目实现：页面骨架、交互与localStorage存储

论文省心了！2026最新AI论文工具测评与推荐

正则匹配嵌套标签内容思路

基于PLC的校园照明控制系统设计与实践全解析

CSP-J/S初赛1000页资料集高效使用指南：从知识模块到错题归因

今日更新

再见，SSE！你好，Streamable HTTP！轻松开发 Streamable HTTP MCP Server 并接入 TaoToken

工业软件标准化路线图：国产替代的落地施工图

VCMI安卓版实操指南：原生运行英雄无敌3的3步技术落地

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？