简介：这是一份聚焦深度学习与交通大数据交叉应用的实战型电子书，面向交通工程专业人员、数据科学家及对时空序列预测感兴趣的研究者。全书系统梳理LSTM、AutoEncoder、ConvLSTM、Seq2Seq、CNN、GCN、ResNet、T-GCN等模型在交通速度预测、客流预测、共享单车与轨道交通流量预测、OD需求分析等场景中的具体用法，并配有参数详解与案例研究，适合希望将深度学习落地到智能交通场景的读者。压缩包共1个文件，为pdf格式，整体大小约17.93MB，内容完整，阅读体验清晰。目前已有311人学习下载。书中除模型原理外，还提供了动态时空相似性框架、多图卷积网络、注意力机制、时空同步图卷积等前沿方案，不仅覆盖交通预测，还可迁移至环境监测、能源消耗等大数据预测任务，兼具理论深度与工程参考价值。

1. 交通大数据深度学习实战：从清洗切片到模型部署的一次性通关

早高峰的环路拥堵预测不准，调度大屏上的红黄绿永远慢半拍，这是每一个做智能交通的人都绕不开的坎。你以为瓶颈在模型不够深，实际查下来多半是数据切片没对齐、节假日样本污染了训练集，或者多步预测时模型把上一帧真实值当成了输入。这套V2.0版实战资源真正解决的就是这类问题：它从某市快速路检测器原始数据出发，给你一条完整可跑的深度学习链路——数据清洗、特征工程、LSTM与注意力模型构建、多步预测评估，最后落到可部署的模型导出。适合刚接触交通时序预测的算法工程师，也适合想把手头流量预测项目从“能跑”做到“靠谱”的从业者，照着复现一遍就能绕开大多数玄学坑。

2. 交通数据挖掘第一课：把检测器脏数据切成可训练的监督样本

2.1 传感器数据源与字段语义拆解

交通大数据项目最先卡的往往不是模型，而是拿到的原始数据表根本没法直接喂给神经网络。V2.0这套资源配套的原始数据集来自城市快速路的断面检测器，采样周期以5分钟为基准，核心字段包括device_id（设备编号）、time_stamp（时间戳）、volume（断面车流量）、speed（平均车速）、occupancy（时间占有率）等。你可能还会碰到一些扩展字段，比如天气编码、工作日标记，但这些在基础版本里不是默认开启的。

第一步先把数据读进来，看一眼字段分布再决定怎么洗。常见做法是用 pandas 快速加载并做 dtype 压缩，避免把时间戳读成字符串后才发现没法做时间对齐：

# traffic_data_loader.py import pandas as pd df = pd.read_csv( "raw_traffic/20240901_detector.csv", parse_dates=["time_stamp"], # 直接解析成 datetime，省得后面再转 dtype={ "device_id": "category", # 设备编码用 category 省内存 "volume": "int16", # 车流量用 int16 足够 "speed": "float32", # 速度保留两位小数意义不大，float32 够了 "occupancy": "float32" }, na_values=["\\N", "NULL", ""] # 检测器常见缺省值 ) print(df.groupby("device_id").agg({"time_stamp": "min", "time_stamp": "max"}))

这段代码包含一个很多人会忽略的操作：na_values。交通检测器原始 CSV 里空值常被写成\\N，如果你不告诉 pandas 这是缺省标记，它会被当作字符串读进来，后面所有数值聚合全部翻车。我一般会在加载阶段同时打印每个设备的时间跨度，先确认每个断面是不是都有完整的24小时数据，再进入下游清洗。这个步骤价值极高——很多所谓“预测不准”其实是某台设备凌晨断传了3小时，把时序切成了缺口。

字段语义上还有一个容易踩的点：volume 是每5分钟累计通过该断面的车辆数，不是瞬时值。有些初学者把 volume 当瞬时流量直接做滑窗，忽略了累计口径，导致后续构造的标签偏离真实流量形态。这份资源里给到的字段说明文档专门标注了每个指标的统计口径，建模前建议先花10分钟读一遍，能省下后面一整天的排查时间。

2.2 数据清洗：缺失值、异常值、时间对齐三件套

检测器设备常年暴露在路侧，线圈老化、地磁漂移、雷击导致的数值跳变非常常见。V2.0 配套代码里有一套清洗管线，核心分三层：时间对齐层、缺失值插补层、异常值截断层。

时间对齐层处理的是设备上报延迟。比如某设备在 09:03 上报了原本属于 09:00 的聚合值，如果不做对齐，这条数据会被当成一个独立时间点参与训练，让序列出现虚假的密集采样。常见做法是以5分钟为 bucket 做 resample，把错位点压回正确的时间槽：

# data_cleaning.py def align_and_fill(df: pd.DataFrame, device_id: str) -> pd.DataFrame: device = df[df["device_id"] == device_id] device = device.set_index("time_stamp").sort_index() # 重采样到标准5分钟频率，错位数据被并入所属槽位 aligned = device.resample("5min").agg({ "volume": "sum", # 累计量求和 "speed": "mean", # 速度均值 "occupancy": "mean" }) # 缺失槽位先做线性插值，超过连续3个空位的才标记待处理 filled = aligned.interpolate(method="linear", limit=3) return filled

这里必须注意volume用的聚合函数是sum而不是mean。因为它是累计值，重采样到标准槽位后必须把错位数据合并求和，否则日均流量会被平均操作人为拉平。速度字段则用均值，更符合断面通过车辆的平均行驶状态。limit=3是一个工程上的妥协值：连续缺失3个槽位（15分钟）可以用插值补，但如果某个设备连续断传1小时，插值出来的数据就完全是编造的，这时应该直接丢弃该片段，而不是强行填充。这些边界条件是资源里清洗模块带注释讲清楚的，也是它和网上零散代码最大的区别——不是能跑就行，而是每一层的选择都有现场工程理由。

异常值截断层更直接。交通流数据里最经典的异常是速度字段瞬间跳到 150km/h 又掉回 20km/h，或者某时段 volume 突变为平时的10倍（大概率是检测器故障或者偶发拥堵溢出）。资源里用的是IQR 分位数法 + 物理阈值双约束：

# anomaly_threshold.py Q1, Q3 = speed.quantile(0.25), speed.quantile(0.75) IQR = Q3 - Q1 lower_bound = max(0, Q1 - 1.5 * IQR) # 物理下限不能小于0 upper_bound = min(120, Q3 + 1.5 * IQR) # 快速路速度上限约120km/h speed = speed.clip(lower_bound, upper_bound) # 截断而不是删除

为什么截断而不是直接删除异常点？因为在交通流量序列里，异常点携带信息——比如突发拥堵本来就是我们要预测的目标之一。直接删掉会造成序列断裂，后续插补反而引入更大的噪声。截断保住了速度的物理语义，又避免了极端离群值主导 loss。这个思路在专门的教科书里很少被强调，但做真实项目的人都会理解：交通数据清洗的目标不是得到“干净的理想数据”，而是得到“不误导模型的数据”。

2.3 构建监督学习样本：滑窗特征与标签序列

清洗完之后，要做深度学习最关键的一步：把时间序列切成(X, y)监督样本。V2.0 给出的做法是历史窗口预测未来多步，具体参数是window_size=12（过去1小时）预测horizon=6（未来30分钟）。切片时要注意两个坑：跨天切片和泄露切片。

跨天切片指的是午夜00:00的数据会拼上前一天深夜的片段，这本身没问题，但如果你的样本直接从 23:55 滑到 00:00，节假日和工作日的特征边界会被揉在一起。资源里的处理是保留日期特征列（星期几、是否节假日）作为模型输入的一部分，而不是物理切掉跨天样本。

泄露切片则是新手最常见的翻车点：在构造监督样本时，如果同一时刻的真实值既出现在特征窗口里又出现在标签窗口里，模型训练时会“偷看答案”。比如你要预测 t+1 到 t+6，特征窗口必须严格截止在 t 时刻及之前。资源里的切片函数强制要求特征和标签完全不重叠：

# sample_builder.py def build_samples(series, window_size=12, horizon=6, step=1): xs, ys = [], [] for i in range(0, len(series) - window_size - horizon, step): x = series[i : i + window_size] y = series[i + window_size : i + window_size + horizon] xs.append(x) ys.append(y) return np.array(xs), np.array(ys)

step=1意味着相邻样本之间有11个时间步重叠，会引入严重的样本冗余，模型训练时收敛速度快但验证指标虚高。资源里在训练模式用step=1（数据量小，加速收敛），在最终评估时切换为step=6（样本间隔拉大，验证更接近真实部署环境）。这个细节虽然不起眼，但它是决定你评估指标可不可信的关键。

中间章的实操段落必须到达能直接抄作业的程度。到这里，数据管线已经完整跑通，下一步是模型怎么接住这批样本。

3. 模型体系与训练循环：从LSTM基座到注意力融合网络的完整落地

3.1 为什么基线选LSTM而不是Transformer

交通流量预测的本质是多元时序建模，市面上的方案无非是 LSTM、GRU、TCN、Transformer 这几类。V2.0 资源里基线模型选用的是双向LSTM + 注意力机制的组合，而不是一上来就上Transformer，这个选型是有实际工程理由的。

交通数据有几个特性直接影响了模型选型。第一，单断面流量序列通常只有几百到几千个时间步，Transformer 的自注意力机制需要大量数据才能发挥优势，数据量不够时反而容易过拟合。第二，LSTM 的时序归纳偏置天然适合交通流这种强周期、缓变化的信号，不需要额外做位置编码。第三，推理延迟的要求不同：部署到路侧边缘设备时，LSTM 的推理开销远低于 Transformer，这对实时调度场景很关键。

基线模型结构在资源里定义得很清楚：第一层是双向 LSTM（隐藏维度 64），第二层是时间维度的注意力池化，第三层是两层全连接输出多步预测。这是「深度挖掘」交通时序特征的标准套路，也是工业落地最成熟的组合。

# traffic_lstm_model.py import torch import torch.nn as nn class TrafficLSTM(nn.Module): def __init__(self, input_dim: int, hidden_dim: int, horizon: int, num_layers: int = 2): super().__init__() # 第一层：双向LSTM捕捉过去和未来的上下文（双向只在训练时用） self.lstm = nn.LSTM( input_dim, hidden_dim, num_layers, batch_first=True, bidirectional=True, dropout=0.2 ) # 第二层：时间注意力权重 self.attn = nn.Linear(hidden_dim * 2, 1) # 第三层：输出未来 horizon 步 self.head = nn.Sequential( nn.Linear(hidden_dim * 2, 64), nn.ReLU(), nn.Linear(64, horizon) ) def forward(self, x): # x: [batch, seq_len, input_dim] out, _ = self.lstm(x) # [batch, seq_len, hidden*2] attn_weights = torch.softmax(self.attn(out).squeeze(-1), dim=1) context = torch.sum(out * attn_weights.unsqueeze(-1), dim=1) return self.head(context)

bidirectional=True带来的好处是每个时间步的隐状态同时包含了前向和反向上下文，对捕捉早高峰前后流量攀升的趋势特别有效。代价是推理时双向LSTM需要完整看到整个输入窗口才能输出，所以它只能用于窗口预测模式，不能用在线流式模式。如果你的部署场景是每5分钟滚动预测一次，这个限制是可以接受的；如果是逐秒更新的实时状态估计，就得换成单向LSTM或者改用因果卷积。资源里对这两种模式的切换场景做了对比说明，这也是它比一般 Demo 代码完整的原因——不仅给你模型，还告诉你什么场景下不能用。

注意力层的作用是让模型自动学习哪些历史时间步对预测未来更关键。早高峰场景下，过去15分钟的流量攀升斜率通常比过去1小时的平均水平更有信息量，注意力权重会自动聚焦到这些关键帧上。这个机制比单纯地把LSTM最后一步输出接全连接层效果更稳定，尤其是预测 horizon 拉长到6步（30分钟）时。

3.2 多源特征融合：外部变量怎么进模型

交通预测不能只看流量本身，天气、节假日、上下游断面状态都会显著影响结果。V2.0 资源里把外部特征分成了三类，每类的融合方式不一样：

逐点特征：比如天气编码、星期几、是否节假日。这类特征跟时间点一一对应，直接拼到每个时间步的输入向量尾部即可。LSTM 的输入维度变成原始流量特征维度 + 外部特征维度。

区间特征：比如过去1小时上下游断面的平均车速。这类特征跟整个窗口相关，不能直接拼进每一步，常见的做法是单独过一个线性层压缩维度和 LSTM 输出拼接，或者在注意力池化之后拼到上下文向量上。

事件特征：比如临时交通管制、大型活动散场。这类特征没有历史规律可循，标准做法是做成事件embedding，在最后全连接层之前拼进去。

资源里给的 baseline 实现是第一种和第二种种结合，事件特征留了接口但默认不启用，因为大部分城市的数据集不包含结构化事件记录。这个“留接口但不启用”的设计很实用——你的项目里如果拿得到事件数据，直接在self.head前面拼一个 embedding 向量就行，不需要改前面的特征处理逻辑。

3.3 完整训练循环：早停、学习率调度与验证集切分

模型结构定义好后，训练循环反而是最容易翻车的地方。交通时序数据有强烈的昼夜周期，如果你直接把全量数据随机切分成 train/test，那么同一时刻的样本会同时出现在训练集和验证集里，评估指标会好看得离谱，上线后立刻打回原形。

V2.0 的训练脚本强制要求按时间顺序切分，前70%训练、后20%验证、最后10%测试：

# train_loop.py train_ratio, val_ratio = 0.7, 0.2 train_end = int(len(dataset) * train_ratio) val_end = int(len(dataset) * (train_ratio + val_ratio)) train_ds = TrafficDataset(samples[:train_end]) val_ds = TrafficDataset(samples[train_end:val_end]) test_ds = TrafficDataset(samples[val_end:])

为什么测试集必须是最后10%？因为交通预测的部署场景是“用现在的数据预测未来”，而按时间乱序的切分方式相当于在考试时偷看了未来试卷。很多公开代码为了追求验证集上的漂亮数字，用random_split切分时间序列，这在学术基准上还能解释，在工程落地上就是自欺欺人。资源里的训练脚本从头到尾用的都是时序切分，这对实战项目来说是必须守住的底线。

训练循环要注意的三个点：梯度裁剪、学习率衰减、早停监控。LSTM 类模型在长序列上梯度范数很容易爆炸，尤其是双向层堆叠之后，所以训练循环里必须加梯度裁剪：

# train_step.py optimizer.zero_grad() loss = criterion(model(x_batch), y_batch) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=5.0) # 梯度裁剪 optimizer.step()

max_norm=5.0是经验值，太小会导致收敛过慢，太大起不到防止梯度爆炸的作用。早停的 patience 一般设为 10-15 个 epoch，监控指标是验证集 MAE，而不是训练集 loss。学习率调度我用的是 CosineAnnealingLR，初始学习率1e-3，最小学习率1e-5，比固定学习率稳定得多。

4. 参数调优与多步预测评估：把误差压到可接受范围

4.1 评价指标选型：MAE、RMSE、MAPE 各看什么

交通流量预测的评价指标不能一概而论。流量绝对值在不同时段差异极大，凌晨时段流量只有几十辆/5分钟，早高峰能达到几百辆/5分钟。用 RMSE 的后果是模型只管把高峰拟合好，凌晨预测误差完全不敏感；用 MAPE 的后果相反——凌晨流量基数小，一点点绝对误差就会换算成巨大的百分比误差，导致模型为了降低 MAPE 疯狂优化低流量时段。

V2.0 资源的默认评估策略是MAE + RMSE 双指标同时看，另外提供一个peak_hour_mae指标专门评估早高峰时段的精度：

# evaluate_metrics.py def evaluate_model(model, test_loader, peak_hour=(7, 9)): mae_sum, rmse_sum, peak_sum, cnt = 0.0, 0.0, 0.0, 0 peak_cnt = 0 for batch_x, batch_y, batch_time in test_loader: pred = model(batch_x) diff = pred - batch_y mae = torch.mean(torch.abs(diff)) rmse = torch.sqrt(torch.mean(diff ** 2)) # 只统计早上7-9点范围内的样本 peak_mask = ((batch_time >= peak_hour[0]) & (batch_time < peak_hour[1])) peak_mae = torch.mean(torch.abs(diff[peak_mask])) mae_sum += mae.item(); rmse_sum += rmse.item(); peak_sum += peak_mae.item() cnt += 1 peak_cnt += 1 return { "MAE": mae_sum / cnt, "RMSE": rmse_sum / cnt, "PeakHour_MAE": peak_sum / peak_cnt }

peak_mask用的布尔索引是 PyTorch 里做条件筛选的高效方式，注意batch_time必须是数值型时间编码（比如hour*100+minute），不能是字符串。资源里在数据管线阶段就把时间编码转成minute_of_day数值列，方便这一类按小时窗口的评估切分。

高峰时段单独评估这个做法，实战价值很高。交通调度人员关注的核心指标就是高峰期误差，如果模型整体MAE不错但早高峰预测偏差很大，那这个模型在业务上是不合格的。资源里还给了 95 分位误差（P95 error）作为鲁棒性参考，用于判断模型是否存在偶发的大偏差——这个问题比平均误差更大，因为偶发大偏差会直接导致调度误判。

4.2 超参数实验：隐藏维度、滑窗长度与批大小

交通时序模型的超参数选择有一个典型的“三变量互相牵制”的关系：滑窗长度、LSTM层数、隐藏维度。你单独调任何一个都可能变差，因为它们共同决定了模型能感知的时间范围。

资源附带的调参记录给出了一个经验范围：window_size在 6-24 之间（对应30分钟-2小时），隐藏维度在 32-128 之间，LSTM 层数 1-2 层。常见的做法是固定层数为2，先扫 window_size，再扫隐藏维度。下面是资源里给出的参考实验配置：

batch_size=64这个取值在一个简单数据集上略显激进，但优势是训练速度快，配合梯度裁剪不会崩。如果你的设备数据量很大（比如超过50万样本），建议把 batch_size 提到128并用混合精度训练，处理速度几乎翻倍，但注意 LSTM 的混合精度支持不如CNN成熟，容易踩数值稳定性的坑，建议先跑纯FP32验证没问题再开AMP。

4.3 多步预测的两种策略：直接预测与递归预测

horizon=6 意味着模型一次输出未来6个时间步的预测值。实现上有两种完全不同的策略，V2.0 资源默认用直接多步预测（模型头部输出维度=horizon），而不是递归多步预测（模型每步输出一个值，再把自己的预测值当作输入继续预测下一步）。

直接多步预测的好处是误差不会累积——每个目标步都是独立输出，训练时不会像递归预测那样把错误预测喂回模型输入端。代价是输出层需要独立建模每个未来步之间的关联，如果未来走势有明显拐点，直接预测往往会把曲线预测得过于平滑。

递归预测的好处是模型可以复用单步预测的能力，未来步之间是隐式相关的，更符合时间序列的演化逻辑。但它的致命伤在训练和推理的不一致：训练时用的是真实历史值做下一步输入（Teacher Forcing），推理时用的是上一步预测值，两者分布不一致导致误差随 horizon 快速累积。常见做法是训练时随机混合真实值和预测值，让模型适应两种输入分布，但实现复杂度明显提高。

资源里给了一个折中方案：直接多步预测为主，最后一步（第6步）输出后接一个残差修正层。残差修正层输入是前5步的预测序列，输出是一个修正量，加到第6步预测上。这个设计直观地想很合理——未来30分钟的第6步最不稳定，用前面几步的预测趋势做二次校正，实际效果在验证集上确实比纯直接预测低5-8%的MAE。

5. 交通时序实战排查：数据泄露、节日污染与收敛异常的四个典型案例

5.1 早高峰预测整体滞后，KPI却虚高

现象：模型在验证集上 MAE 不错，但可视化预测曲线时发现：预测曲线永远比真实曲线慢一个时间步——早高峰开始爬升时，模型还在按平峰流量输出，等到真实流量已经到顶，模型才开始爬坡。KPI好看是因为滞后了一步，误差本身不大，但业务上完全不能用。

原因：这是最常见的时间序列对齐错误。检查样本构造代码，发现特征窗口x[i : i+window]和标签y[i+window : i+window+horizon]中间没有错位。如果标签起点和特征终点之间差一个时间步（比如特征窗口包含 t 时刻，标签从 t 时刻开始算），模型相当于提前看到了一步真实值，学会了“复制最近值”这个偷懒策略。

解决：强制要求特征窗口严格截止于 t 时刻之前。正确的索引是特征x[i-window : i]，标签y[i : i+horizon]。写完后用一行 assert 检查两个切片没有任何重叠：assert x[-1] != y[0]。从那以后我每次构造完监督样本都会先画出预测曲线的滞后情况，这个可视化检查比任何指标都直观。

5.2 节假日预测失效，模型无法识别周期切换

现象：工作日测试集上预测精度正常，一旦到了国庆假期，预测流量直接高出实际流量一大截，偏差超过60%。

原因：节假日和工作日完全不在一个流量分布上。如果特征里只有hour_of_day和day_of_week，模型无法区分“周一工作日”和“周一节假日现场”，因为 day_of_week 在这个场景下没有区分力。更隐蔽的问题是训练集里节假日样本占比过低，模型直接把它们当噪声忽视了。

解决：必须显式加入节假日特征列。资源里的做法是构造一个is_holiday二进制特征，配合days_since_last_holiday连续特征（距离上一个节假日的天数），让模型感知长假前后流量的渐变过程。实战经验是这类特征能降低节假日时段的 MAE 约 30%，建议单独把节假日和节假日前一天切一个测试集来验证模型行为的改善。另外，如果你接入的是节假日调休机制复杂的城市，光靠二进制特征是不够的，至少要把“节前最后一天”“节后第一天”单独编码，因为它们和平常的周末完全不是一种流量形态。

5.3 训练 loss 周期性抖动，无法收敛

现象：训练过程中 loss 曲线呈现明显的周期性震荡，每个周期大约对应数据中的一天（288个时间步），loss 时高时低，模型始终无法收敛到稳定水平。

原因：这和模型结构无关，问题在数据加载顺序。批量随机采样时，虽然样本本身按时间顺序构造，但每个 batch 加载的样本来自不同时间段，导致同一轮 epoch 内模型交替看到“凌晨低流量样本”和“晚高峰高峰值样本”，梯度的方向在两者之间左右横跳。

解决：资源里提供了按时间分组采样器：先把数据按所属小时段分成24组，训练时每个 batch 从同一组内采样，保证同一个 batch 内的样本流量水平相近。这样同一个 batch 的梯度方向更一致，模型收敛稳定性显著提升。代价是每个 batch 内样本多样性下降，因此要在训练过程中打乱组顺序，并配合较低的学习率。如果不想改采样逻辑，另一个可用的做法是先把 total loss 按时间窗口做平滑，用平滑后的曲线做早停判断——至少不会因为日周期震荡而过早触发早停。

5.4 梯度爆炸导致 loss 变成 NaN

现象：训练到第 20 轮左右，loss 突然跳到nan，之后整个模型参数损坏，只能从头重训。查看梯度范数发现最后几层梯度已经膨胀到1e+8级别。

原因：双向 LSTM 在多层堆叠时，反向传播路径长度翻倍，梯度在这个路径上累积放大的概率很高。加上学习率调度使用的是 CosineAnnealingLR，在循环初期学习率较大，更易触发梯度爆炸。日志里可以看到 loss 在爆炸前一个 epoch 已经出现异常的上升趋势——这就是前兆，但当时没有及时拦截。

解决：训练循环里加上梯度裁剪（如前面代码所示），并把max_norm从默认的 1.0 调整到 5.0——裁剪阀值太小会限制模型表达能力，尤其在双向 LSTM 上要留出足够余量。同时把 LSTM 层间 dropout 提高至 0.3，相当于给梯度传播路径增加随机扰动，能进一步降低爆炸概率。另外强烈建议开启 PyTorch 的 anomaly detection 做一次快速诊断：torch.autograd.set_detect_anomaly(True)，这样第一个产生 NaN loss 的操作位置会打印出来，直接定位是 LSTM 内部还是输出层的问题，而不用靠猜。

6. 部署前的最后一公里：模型导出、精度回放与伪回归检查

模型训练完成后，直接打包上线是不够的。交通预测系统的上线流程里，有一个经常被跳过但价值极高的步骤：预测结果回放与基线伪回归对比。拿最近30天的历史数据重新跑一遍模型推理，把预测结果逐小时画出来，和真实曲线做叠图比对。这个动作能暴露所有你在验证集上看不出来的问题——比如模型在特定天气模式下系统性偏置、特定路段意外失效。

另一个容易被忽略的是模型导出时的序列长度固化。很多框架在导出时会把输入序列长度做成动态维度，导致部署端可以传入任意长度的窗口。交通预测模型是基于固定 window_size=12 训练的，输入长度一旦变化，注意力权重的分布会整体偏移，预测精度肉眼可见地下降。所以我一般会在导出前用torch.jit.script或者 ONNX 固定输入形状，并在导出后做一个对齐测试：用训练时的最后一个样本和新导出的模型做推理，对比输出是否完全一致。这个测试就是后悔药——等上线到生产环境再发现输出对不上，排查成本高一个数量级。

最后是把预测结果接入调度大屏时的一个实战小技巧：输出平滑。模型预测的6步结果通常有轻微抖动，直接展示会让调度员觉得系统不稳定。常见做法是对预测序列做一次 3 点 Savitzky-Golay 滤波，只保留趋势信息，不影响峰值幅度。这个后处理不属于模型范畴，但价值不亚于调参——工程师做的东西要让人觉得“靠谱”，平滑处理往往能让整个系统的可信度上一个台阶。

这套流程走完，你就会意识到交通预测项目的核心难点根本不在模型选型，而在于从数据清洗到评估闭环的每一步是否都做对了。从那以后我每次接到类似的流量预测需求，都会强制自己先按这套流程走一遍完整的数据切分和指标定义，再讨论模型结构。希望帮到你。

本文还有配套的精品资源，点击获取