简介这是一份聚焦深度学习与交通大数据交叉应用的实战型电子书面向交通工程专业人员、数据科学家及对时空序列预测感兴趣的研究者。全书系统梳理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(methodlinear, limit3) return filled这里必须注意volume用的聚合函数是sum而不是mean。因为它是累计值重采样到标准槽位后必须把错位数据合并求和否则日均流量会被平均操作人为拉平。速度字段则用均值更符合断面通过车辆的平均行驶状态。limit3是一个工程上的妥协值连续缺失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_size12过去1小时预测horizon6未来30分钟。切片时要注意两个坑跨天切片和泄露切片。跨天切片指的是午夜00:00的数据会拼上前一天深夜的片段这本身没问题但如果你的样本直接从 23:55 滑到 00:00节假日和工作日的特征边界会被揉在一起。资源里的处理是保留日期特征列星期几、是否节假日作为模型输入的一部分而不是物理切掉跨天样本。泄露切片则是新手最常见的翻车点在构造监督样本时如果同一时刻的真实值既出现在特征窗口里又出现在标签窗口里模型训练时会“偷看答案”。比如你要预测 t1 到 t6特征窗口必须严格截止在 t 时刻及之前。资源里的切片函数强制要求特征和标签完全不重叠# sample_builder.py def build_samples(series, window_size12, horizon6, step1): 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)step1意味着相邻样本之间有11个时间步重叠会引入严重的样本冗余模型训练时收敛速度快但验证指标虚高。资源里在训练模式用step1数据量小加速收敛在最终评估时切换为step6样本间隔拉大验证更接近真实部署环境。这个细节虽然不起眼但它是决定你评估指标可不可信的关键。中间章的实操段落必须到达能直接抄作业的程度。到这里数据管线已经完整跑通下一步是模型怎么接住这批样本。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_firstTrue, bidirectionalTrue, dropout0.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), dim1) context torch.sum(out * attn_weights.unsqueeze(-1), dim1) return self.head(context)bidirectionalTrue带来的好处是每个时间步的隐状态同时包含了前向和反向上下文对捕捉早高峰前后流量攀升的趋势特别有效。代价是推理时双向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_norm5.0) # 梯度裁剪 optimizer.step()max_norm5.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*100minute不能是字符串。资源里在数据管线阶段就把时间编码转成minute_of_day数值列方便这一类按小时窗口的评估切分。高峰时段单独评估这个做法实战价值很高。交通调度人员关注的核心指标就是高峰期误差如果模型整体MAE不错但早高峰预测偏差很大那这个模型在业务上是不合格的。资源里还给了 95 分位误差P95 error作为鲁棒性参考用于判断模型是否存在偶发的大偏差——这个问题比平均误差更大因为偶发大偏差会直接导致调度误判。4.2 超参数实验隐藏维度、滑窗长度与批大小交通时序模型的超参数选择有一个典型的“三变量互相牵制”的关系滑窗长度、LSTM层数、隐藏维度。你单独调任何一个都可能变差因为它们共同决定了模型能感知的时间范围。资源附带的调参记录给出了一个经验范围window_size在 6-24 之间对应30分钟-2小时隐藏维度在 32-128 之间LSTM 层数 1-2 层。常见的做法是固定层数为2先扫 window_size再扫隐藏维度。下面是资源里给出的参考实验配置参数推荐值说明window_size121小时覆盖最近两个完整周期半小时周期horizon630分钟常规短时交通预测场景hidden_dim64平衡表达能力和过拟合风险num_layers21层欠拟合3层在数据量小时过拟合batch_size64时序样本短批大小可以适当加大dropout0.2双向LSTM层间dropout学习率1e-3 余弦退火前期快速收敛后期精细调优batch_size64这个取值在一个简单数据集上略显激进但优势是训练速度快配合梯度裁剪不会崩。如果你的设备数据量很大比如超过50万样本建议把 batch_size 提到128并用混合精度训练处理速度几乎翻倍但注意 LSTM 的混合精度支持不如CNN成熟容易踩数值稳定性的坑建议先跑纯FP32验证没问题再开AMP。4.3 多步预测的两种策略直接预测与递归预测horizon6 意味着模型一次输出未来6个时间步的预测值。实现上有两种完全不同的策略V2.0 资源默认用直接多步预测模型头部输出维度horizon而不是递归多步预测模型每步输出一个值再把自己的预测值当作输入继续预测下一步。直接多步预测的好处是误差不会累积——每个目标步都是独立输出训练时不会像递归预测那样把错误预测喂回模型输入端。代价是输出层需要独立建模每个未来步之间的关联如果未来走势有明显拐点直接预测往往会把曲线预测得过于平滑。递归预测的好处是模型可以复用单步预测的能力未来步之间是隐式相关的更符合时间序列的演化逻辑。但它的致命伤在训练和推理的不一致训练时用的是真实历史值做下一步输入Teacher Forcing推理时用的是上一步预测值两者分布不一致导致误差随 horizon 快速累积。常见做法是训练时随机混合真实值和预测值让模型适应两种输入分布但实现复杂度明显提高。资源里给了一个折中方案直接多步预测为主最后一步第6步输出后接一个残差修正层。残差修正层输入是前5步的预测序列输出是一个修正量加到第6步预测上。这个设计直观地想很合理——未来30分钟的第6步最不稳定用前面几步的预测趋势做二次校正实际效果在验证集上确实比纯直接预测低5-8%的MAE。5. 交通时序实战排查数据泄露、节日污染与收敛异常的四个典型案例5.1 早高峰预测整体滞后KPI却虚高现象模型在验证集上 MAE 不错但可视化预测曲线时发现预测曲线永远比真实曲线慢一个时间步——早高峰开始爬升时模型还在按平峰流量输出等到真实流量已经到顶模型才开始爬坡。KPI好看是因为滞后了一步误差本身不大但业务上完全不能用。原因这是最常见的时间序列对齐错误。检查样本构造代码发现特征窗口x[i : iwindow]和标签y[iwindow : iwindowhorizon]中间没有错位。如果标签起点和特征终点之间差一个时间步比如特征窗口包含 t 时刻标签从 t 时刻开始算模型相当于提前看到了一步真实值学会了“复制最近值”这个偷懒策略。解决强制要求特征窗口严格截止于 t 时刻之前。正确的索引是特征x[i-window : i]标签y[i : ihorizon]。写完后用一行 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之后整个模型参数损坏只能从头重训。查看梯度范数发现最后几层梯度已经膨胀到1e8级别。原因双向 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_size12 训练的输入长度一旦变化注意力权重的分布会整体偏移预测精度肉眼可见地下降。所以我一般会在导出前用torch.jit.script或者 ONNX 固定输入形状并在导出后做一个对齐测试用训练时的最后一个样本和新导出的模型做推理对比输出是否完全一致。这个测试就是后悔药——等上线到生产环境再发现输出对不上排查成本高一个数量级。最后是把预测结果接入调度大屏时的一个实战小技巧输出平滑。模型预测的6步结果通常有轻微抖动直接展示会让调度员觉得系统不稳定。常见做法是对预测序列做一次 3 点 Savitzky-Golay 滤波只保留趋势信息不影响峰值幅度。这个后处理不属于模型范畴但价值不亚于调参——工程师做的东西要让人觉得“靠谱”平滑处理往往能让整个系统的可信度上一个台阶。这套流程走完你就会意识到交通预测项目的核心难点根本不在模型选型而在于从数据清洗到评估闭环的每一步是否都做对了。从那以后我每次接到类似的流量预测需求都会强制自己先按这套流程走一遍完整的数据切分和指标定义再讨论模型结构。希望帮到你。本文还有配套的精品资源点击获取