LSTM时序预测实战：从数据预处理到模型调参全攻略

1. 为什么直到今天，我依然劝你先从LSTM入手做时序预测

很多朋友一上来就问：「现在不都是Transformer了吗，还有必要学LSTM做时间序列预测吗？」这其实是把两件事搞混了——做研究和做工程落地是两码事。我在这几年实际处理过的时序项目里，不管是电力负荷、流量监控、销售预测还是传感器数据，LSTM依然是投入产出比最高的模型之一。它的训练成本比Transformer低一个量级，对数据量的要求也友好得多，而且只要结构设计得当，精度完全不输给那些花里胡哨的大模型。

先说清楚LSTM在这里的定位：它适合做中等长度序列的回归预测，也就是根据过去N个时刻的观测值，预测未来M个时刻的值。比如用过去24小时的电量数据预测未来1小时，用过去7天的销量预测明天，用过去30帧的传感器读数预测下一个读数。这些场景的共同特征是序列长度有限、样本量在几千到几十万之间、数据有明显的时间依赖关系。在这个区间，LSTM天然有优势——它的门控机制就是为了捕捉长期依赖设计的，不需要像Transformer那样承载海量预训练知识和极高的算力开销。

有人说LSTM在长序列上不如Transformer，这话对，但也没完全对。LSTM的梯度路径被门控结构缩短了，理论上确实能处理上百步甚至上千步的依赖；实践中问题往往不出在模型容量，而出在数据太短、噪声太大、窗口切得不对。我在多个项目上对比过LSTM和Transformer在中等长度数据上的表现，结论很稳定：**在样本量不超过10万、序列长度不超过512的场景里，LSTM把超参数调好，精度差距基本在5%以内，但训练时间和部署成本能差出一个数量级。**所以如果你是第一次做时序预测，或者公司的数据条件很常规，我建议你先老老实实把LSTM跑通。

还有一个现实原因：LSTM的调试路径非常成熟。网上能查到的踩坑案例、可复现的代码、成熟的工程组件都比新架构多得多。你需要的是先把「数据怎么喂」「维度怎么对齐」「损失怎么收敛」这些基本功打扎实，这些能力在LSTM上学到，换到任何模型上都是通用的。反而是上来就搞大模型，一旦出问题，排查链条长到你根本不知道是数据的问题、注意力机制的问题还是位置编码的问题。

这篇内容我会按一条完整项目线来讲：从数据预处理讲到模型搭建，从训练配置讲到踩坑排查，最后说评估和落地。每一步都会给出可以直接复用的代码和经验参数。建议你跟着跑一遍，哪怕数据集很简单，也比只看不练强十倍。

2. 滑动窗口、归一化和数据顺序：数据准备里的三件要命小事

时序预测的数据准备和普通机器学习有个本质区别：数据之间存在顺序关系。普通回归任务里，样本独立同分布；时序任务里，每一条样本都是历史片段，一旦你的处理方式破坏了时间和因果顺序，模型再高级也是白搭。我见过不少项目死在这一步，后面再怎么调参都救不回来。

2.1 滑动窗口宽度怎么选：周期、滞后期和数据量的平衡

LSTM做预测，第一步是把原始的一维数组拆成「输入窗口 + 预测目标」的样本对。窗口宽度（seq_len）的选择直接影响模型能看到的视野和训练样本的数量。经验上，窗口宽度至少要覆盖一个完整的最小周期。比如数据有明显的24小时日周期性，窗口就不能小于96个15分钟采样点；如果按小时采样且关心周周期，就考虑拉到168。窗口太小，模型看不到周期模式；窗口太大，训练样本数量骤减，模型也容易学到噪声。

除了周期，还要考虑滞后期的影响。你预测的目标如果和过去的某个已知事件强相关，比如预测天气时数值模式的输入变量有72小时滞回，那窗口就要包含这个滞后期。一个简单有效的做法是：先做几个候选窗口宽度（比如12、24、48、96）的对比实验，用验证集损失选最好的。别一上来就拍脑袋定数字。

数据量方面有个粗略的参考：样本总数最好在模型参数量的10倍以上。比如你的LSTM隐藏层是64、两层，参数大概在3万上下，那样本数至少要有30万才比较稳。样本数其实很容易算：总长度减去窗口宽度再减预测步长，就是最大样本数。

2.2 归一化的顺序陷阱：先fit训练集，再transform整个流程

归一化是时序项目里最容易出错的地方。很多人直接写scaler.fit_transform(data)，把全量数据一次性归一化——这在普通机器学习里没什么问题，但在时序预测里是典型的数据泄漏。因为你把未来的统计量（均值、方差）用在了训练样本上，训练时模型等于偷看了未来数据的分布，测试集结果会虚高，换到真实业务数据就现原形。

正确做法是：先用训练集部分做scaler.fit()，再分别对训练集、验证集、测试集做transform()。这样所有缩放参数都只来自历史数据，模拟的是真实预测时的场景。用代码说就是：

from sklearn.preprocessing import StandardScaler scaler = StandardScaler() # 只对训练部分fit train_data_normalized = scaler.fit_transform(train_data.reshape(-1, 1)) # 验证和测试集只用transform val_data_normalized = scaler.transform(val_data.reshape(-1, 1)) test_data_normalized = scaler.transform(test_data.reshape(-1, 1))

注意：transform完别忘了 reshape 回来。我见过有人在这行代码上核对了半小时，最后发现形状从(N,1)变成了(N,)，后面喂给 LSTM 的时候维度怎么都不对。

缩放器的选择也有一点讲究。标准归一化（Z-score）适合大多数场景；如果数据有明显趋势且幅度变化很大，比如流量从几百到几万跳动，可以考虑对数缩放或者分位数缩放。但别在项目初期把精力花在这儿——Z-score 跑通流程，后面再回来优化。

2.3 划分数据集：千万别用random_split

构建完样本对之后，划分训练集、验证集、测试集必须按时间顺序切，绝对不能随机打乱。train_test_split(shuffle=True)在分类任务里是标准操作，但在时序任务里直接踩雷：模型会看到「未来时间」的数据参与训练，相当于考试前就拿到了答案。

我的习惯是按比例连续切：前70%做训练，接下来15%做验证，最后15%做测试。验证集的作用是选超参数和早停，测试集只在最后评估一次。记得在构建窗口之前就把原始数组切好，千万别先构建窗口再切——那样窗口会跨边界把未来信息带到训练集里。

一个容易忽略的细节：如果数据是逐日记录并有月度、季度的周期，单纯按比例切可能让某些季节只落在测试集里。这时建议按业务周期对齐切分，比如保证训练集覆盖至少两个完整周期。这在处理销量数据时特别重要——只拿冬季数据训练，模型永远不会懂夏天的规律。

2.4 一个可以直接用的数据集构建类

这里给一份我实际项目里经常改改就用的PyTorch Dataset代码。我习惯用torch.utils.data.Dataset包一层，方便后面配合DataLoader做batch训练：

import torch from torch.utils.data import Dataset class TimeSeriesDataset(Dataset): def __init__(self, data, seq_len=24, pred_len=1): # data: 归一化后的numpy数组，shape为 (N, num_features) self.data = torch.FloatTensor(data) self.seq_len = seq_len self.pred_len = pred_len def __len__(self): return len(self.data) - self.seq_len - self.pred_len + 1 def __getitem__(self, idx): x = self.data[idx : idx + self.seq_len] # 输入窗口 y = self.data[idx + self.seq_len : idx + self.seq_len + self.pred_len, 0] # 预测目标 return x, y

这里有几个设计点：pred_len留成参数，方便以后从单步预测扩展成多步预测；取目标时只取第0列，对应你要预测的主变量。如果你的数据是多变量的，x会是(seq_len, num_features)，这也是后面模型定义时input_size的由来。

最后提醒一句：构建好数据集之后，一定先打印几个样本看看窗口内容和目标值是否符合直觉，特别是确认窗口的最后一个时间点确实紧贴着目标值的第一个时间点。这一步花不了两分钟，能省掉后面排查数据错位的巨大痛苦。

3. 从input_size到hidden_size：LSTM模型结构的维度演算与调参准则

代码写完之后，新手第一个卡住的地方几乎都是维度问题。PyTorch的LSTM对张量形状有严格要求，稍不小心就报RuntimeError。更麻烦的是，维度对了也不代表结构合理——隐藏层大小、层数、是否设batch_first，每个选择都影响训练效果。这一节我把维度演算彻底讲透。

3.1 先把batch_first这件事搞明白

PyTorch LSTM的默认输入形状是(seq_len, batch, input_size)，但绝大多数人在NLP里习惯了(batch, seq_len, features)。所以我每次定义LSTM都会直接加batch_first=True：

self.lstm = nn.LSTM(input_size=num_features, hidden_size=hidden_size, num_layers=2, batch_first=True, dropout=0.2)

加了之后，输入形状变成(batch, seq_len, input_size)，输出是(batch, seq_len, hidden_size)。这点小小的设置能让你少死无数脑细胞。输出有两个：一个是全部时间步的输出序列，另一个是最后时间步的隐藏状态(h_n, c_n)。取最后一个时间步的预测时，可以直接用output[:, -1, :]，比h_n直观——后者在多层LSTM里还要手动取最后一层，容易搞错层级。

h_n的形状是(num_layers * num_directions, batch, hidden_size)。如果你用了双向LSTM（后面会说到），每个方向的hidden state会拼接，取最后一步时要小心处理。初学者在这一步踩坑的密度最高，我强烈建议你写代码时先在输入处打印一次shape，输出处再打印一次，亲眼确认形状对齐，再继续往下写。

3.2 单变量 vs 多变量：input_size这个坑藏在数据里

input_size指的是每个时间步的特征数量。单变量预测时，每个时间步只有一个值，input_size=1；多变量时，每个时间步包含多个特征，比如温度、湿度、风速一起预测未来的温度，input_size=3。这个看似简单，但很多人把窗口宽度和特征数量搞混，把seq_len当成input_size传进去——模型直接训练不起来或者loss奇大。

我建议项目中把特征选择放在数据准备阶段确认好：先用print(x.shape)查看数据集的输出形状，(batch, seq_len, num_features)中的最后一个数字就是input_size。代码里可以写动态获取，避免硬编码出错：

num_features = x.shape[-1]

模型输出的维度通常只对应你真正要预测的那个变量，所以最后接的全连接层是从hidden_size映射到pred_len。如果要做多变量同时预测，那就把全连接输出改成pred_len * num_target_features，并按需reshape。

3.3 hidden_size、层数和Dropout：没有玄学，只有逻辑

隐藏层大小的选择，本质上是在模型容量和泛化能力之间找平衡。hidden_size太小，模型学不到复杂模式，欠拟合；太大，参数量爆炸，小数据集直接过拟合。我的一般起点是64，然后按倍数试探：32、64、128。判断标准很简单——训练loss和验证loss的差距。差距越大，越接近过拟合那一端；两边都高，说明容量不够。

层数方面，我强烈建议从1层开始，验证效果不够再加到2层。两层LSTM在绝大多数中小型时序项目里已经足够。三层以上带来的提升非常有限，而训练时间和过拟合风险会双双上升。为什么？因为层数增加会指数级扩大参数量，而且每层的梯度传播都会引入更多非线性变换的误差累积。除非你的数据极其复杂、样本量极大，否则没必要追求深度。

Dropout的位置也很有讲究。PyTorch在LSTM层内部设置dropout=0.2只对非最后一层的输出生效，这意味着你还需要在全连接层前手动加一个dropout层，才能在最后一步也做正则化：

self.lstm = nn.LSTM(input_size=num_features, hidden_size=hidden_size, num_layers=2, batch_first=True, dropout=0.2) self.fc = nn.Sequential( nn.Dropout(0.2), nn.Linear(hidden_size, pred_len) )

Dropout在LSTM里的作用比在CNN里更微妙。时序模型的过拟合往往表现为「记住训练集的波动形态」，Dropout能强迫模型学习更稳健的依赖关系。但注意，训练时开Dropout、测试时自动关闭，这是PyTorch的默认行为，不需要你手动处理。

3.4 完整模型定义与最后的输出头设计

下面是一份可以直接跑通的LSTM模型结构，注释里标注了每个维度的来源：

import torch.nn as nn class LSTMPredictor(nn.Module): def __init__(self, input_size=1, hidden_size=64, num_layers=2, pred_len=1, dropout=0.2): super().__init__() self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, batch_first=True, dropout=dropout if num_layers > 1 else 0 ) self.fc = nn.Sequential( nn.Dropout(dropout), nn.Linear(hidden_size, hidden_size // 2), nn.ReLU(), nn.Linear(hidden_size // 2, pred_len) ) def forward(self, x): # x: (batch, seq_len, input_size) out, _ = self.lstm(x) # 取最后一个时间步: (batch, hidden_size) last_out = out[:, -1, :] return self.fc(last_out)

我见过很多人直接在LSTM后面接一个Linear就完事，也能跑，但我加了中间层之后，稳定性和收敛速度都有明显改善。原因是LSTM输出的隐藏向量直接线性映射到预测值，会导致模型很难学到非线性的映射关系；加一个带ReLU的中间层，给了模型同时调整隐藏表达和预测头的空间。

再补充一个容易忽略的点：预测长度pred_len大于1时，上面的结构默认是直接输出多步预测值（多输出）。另一种做法是递归预测，把上一步的输出作为下一步的输入循环解码。直接多输出训练更快，但误差会在不同步长之间共享；递归预测更灵活，但误差会累积。我的经验：短预测长度（1到5步）用直接多输出，长预测长度（10步以上）优先考虑序列到序列结构，也就是用另一个LSTM做解码器。这部分可以等基础模型跑通之后再折腾。

4. 训练阶段的核心决策：损失函数、优化器配置与早停机制

模型结构定了，训练过程才是真正决定成败的地方。损失函数的选择、优化器的配置、学习率的调度、早停的策略，每一项都直接影响收敛质量和最终效果。这一节不只给代码，还讲清楚每个选择背后的理由。

4.1 损失函数不是只有MSE：什么时候换Huber，什么时候换MAPE

回归任务里最常见的损失是MSELoss()，也就是均方误差。MSE对大误差的惩罚是平方级别的，这意味着它能非常有效地让模型避免「离谱的大错」，但也意味着它对异常值极端敏感——数据里哪怕只有几个坏点，训练方向都会被带偏。

如果你的时序数据里有明显的异常尖峰（比如电商大促、服务器突刺），我建议换HuberLoss。Huber在误差小于某个阈值时表现得像MSE，大于阈值时表现得像MAE（线性惩罚），天然对异常值鲁棒：

criterion = nn.SmoothL1Loss() # 即HuberLoss，delta默认1.0

再补充一个业务层面的思路：如果预测结果最终用于库存规划、排产这类场景，欠预测和过预测的代价往往不同。这种不对称场景下可以考虑加权损失，比如对负误差乘以一个大于1的系数，强迫模型更谨慎地避免欠预测。做法很简单：

def asymmetric_loss(pred, target, over_penalty=1.0, under_penalty=2.0): error = target - pred weights = torch.where(error > 0, under_penalty, over_penalty) return (error ** 2 * weights).mean()

别一上来就搞复杂损失。先把MSELoss跑通，确认数据链路没问题，再按业务需求逐步替换。损失函数的复杂度应该跟着项目阶段走。

4.2 优化器选型和学习率的启动范围

LSTM训练默认选择是AdamW，而不是普通的Adam。Adam的权重衰减实现方式在有L2正则需求的模型上表现不佳，AdamW把解耦后的权重衰减做得更干净，泛化效果通常更好。学习率的起点我一般设在3e-4到1e-3之间。注意，LSTM对学习率比CNN更敏感——学习率太大，loss直接发散成NaN；太小，收敛慢到怀疑人生。

一个实用的排查办法：第一次跑训练时，固定只训练几个batch，观察loss变化趋势。如果前20个batch之内loss没有明显下降，大概率是学习率太小；如果loss上下乱跳完全无规则，大概率是学习率太大或者输入数据有问题。这个「跑几步试水温」的习惯能帮你省掉大量等待时间。

梯度裁剪对LSTM来说几乎是标配。LSTM在时间轴上展开后，梯度范数容易爆炸，尤其序列较长的时候。加一行代码能挡住大多数训练发散的情况：

torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0)

我习惯把max_norm设在0.5到1.0之间。太大等于没裁，太小会影响正常更新。裁剪本身不会降低模型精度，它只是限制梯度的上界，防止单次更新步子迈得太大。

4.3 早停和模型保存：验证集的作用在这一步显现

训练LSTM最忌讳的就是「死训到固定epoch」。一方面训练epoch太多必然过拟合；另一方面，不同项目的最佳epoch可能差出去几十轮，固定值根本不现实。正确姿势是监控验证集loss，连续N轮不下降就早停，并保存验证loss最优的模型。

我通常这样写训练循环：

best_val_loss = float('inf') patience = 15 trigger = 0 for epoch in range(max_epochs): train_loss = train_one_epoch(model, train_loader, optimizer, criterion) val_loss = evaluate(model, val_loader, criterion) print(f'Epoch {epoch}: train_loss={train_loss:.4f}, val_loss={val_loss:.4f}') if val_loss < best_val_loss: best_val_loss = val_loss trigger = 0 torch.save(model.state_dict(), 'best_model.pth') else: trigger += 1 if trigger >= patience: print('Early stopping triggered.') break

这个逻辑里有个细节值得说明：我是在每个epoch结束时计算验证loss并决定是否保存，而不是等全部训练完了再回看。因为验证集就是你用来选模型的「模拟考试」，整个过程模型会经历好多次内部参数的调整，只有验证loss最好的那次才是真正值得保留的。

另外，patience的值要看你的训练规模。小数据集建议10到20，大数据集可以放宽到30甚至50，因为验证loss本身波动大，太小patience容易在正常波动中被提前掐断。

4.4 学习率调度的实际策略：余弦退火与ReduceOnPlateau

我常用的调度器有两个。如果训练轮数固定，用CosineAnnealingLR让学习率从初始值余弦下降到接近0，对收敛稳定性很有帮助；如果配合早停使用，ReduceLROnPlateau更自然——它会在验证loss滞涨时自动把学习率乘以一个衰减因子（默认0.1）：

scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau( optimizer, mode='min', factor=0.5, patience=5 ) # 每epoch结束后： scheduler.step(val_loss)

注意ReduceLROnPlateau的step()接收的是验证loss，和CosineAnnealingLR的step()不同，后者不需要传参。我用的时候经常忘记加参数导致报错，记一笔。

关于学习率还有一个经验：如果训练集loss降到很低但验证集loss不降，先别急着调模型结构，试着把学习率降一个量级再训几轮。很多「过拟合」其实是因为模型在最优解附近反复震荡，降低学习率让更新步长变小，验证loss往往就能继续下降。

5. 实战踩坑：预测滞后、验证集震荡和测试集「假高分」的完整排查链路

这一节是全文最接近真实项目经验的部分。我遇到的LSTM时序预测问题，翻来覆去就是那几类：预测曲线滞后、验证集loss下不去、测试集分数异常好但业务上用不起来。下面按排查链路来写，不是我直接给答案，而是还原当时一步步的思考过程，这样你下次遇到能自己走一遍。

5.1 预测结果整体滞后一个相位：先怀疑评估方式，再怀疑模型

在单步预测场景里，一个几乎必现的现象是：预测曲线比真实曲线「慢半拍」，看起来模型只是在复制上一时刻的值。很多人第一反应是模型不行，实际上一大半可能出在评估方式上。

单步递归评估的滞后是结构性的。你预测t时刻时，输入是真实的t-1到t-seq_len；你预测t+1时，输入里混入了t时刻的预测值，之后每一步都在用预测值当输入，误差会逐步累积。这种评估方式本身就会让预测曲线看起来像滞后版本。如果项目的最终需求是未来多步预测，我建议改用直接多步输出的评估方式，或者用「教师强制」评估——每一步都用真实历史值做输入，衡量模型每一单步的预测精度，而不是评估连续递归的累积效应。

如果确认了是真实多步预测且滞后仍然严重，那多半是序列的可预测性有限。一个有效验证手段是计算自相关系数：如果滞后1阶的自相关系数接近0.99，而滞后5阶掉到0.2，说明序列本身几乎是随机游走，任何模型的长期预测都会快速退化到「最近值」。这时候别过度调模型，回到特征工程：加入外部变量、构造差分特征、或者降低预测步长，都比继续调LSTM有效。

5.2 测试集结果奇好、业务数据却失效：八成是数据泄漏

这是我见过最坑的一个问题，而且特别隐蔽。有个项目，测试集的RMSE低得让人不敢相信，团队一度以为模型已经达到上线标准。结果部署到业务环境，预测效果直接崩盘。排查到最后发现：数据预处理时有人用整个数据集（包括未来部分）计算了均值方差做归一化，测试集自然就「提前知道了」全局统计信息。

数据泄漏的常见来源，按出现频率排序：

1. 归一化时fit用了全量数据而不是只fit训练集；
2. 构建窗口前就做了差分、平滑或降噪处理，处理过程用了未来信息；
3. 特征构造时用了目标变量的未来值（比如用当天的真实销量当特征去预测当天的销量）；
4. 验证集用于反复调参后，又用同一份验证集评估最终效果，导致分数虚高。

排查技巧其实很简单：把任何一个输入特征的「时间戳」拿出来，看它是否晚于目标时间戳。凡是使用了目标时刻之后的信息做输入，都是泄漏。最典型的例子是用未来销量做特征；没那么明显的是用全局统计量归一化，虽然感觉是「小操作」，危害却一点不小。

5.3 验证集loss震荡、训练集loss正常：分开看是数据问题还是模型问题

训练loss稳步下降，验证loss却上下大幅震荡，这是最让人头疼的情况之一。我会按下面的次序排查：

第一步，确认验证集取batch的方式没问题。时序验证集不能随机打乱，如果DataLoader里设了shuffle=True，模型会在验证时看到和训练样本「相邻时间」的数据，序列相似度高，loss会有异常的尖峰或低谷。这一步检查只需要几秒钟，但能排除一半问题。

第二步，看验证集的样本量。如果验证集只有几百个样本，且这些样本恰好分布在几个高波动片段，loss天然就会上下跳动。我的经验是验证集样本量至少要有2000以上，否则随机波动会淹没真实信号。这时候可以增加验证集比例，或者改用K折时间序列验证。

第三步，检查输入窗口里有没有未来信息的「影子」。这是针对多变量输入的情况——某个辅助特征在训练时表现得很好，在验证时突然失效，很有可能是这个特征在训练和验证阶段的数据分布差异太大。用scaler分别对训练/验证做统计对比，能很快定位是哪个特征出了问题。

第四步，如果以上都没问题，那就是模型复杂度过高。加Dropout、减小hidden_size、减一层，通常能缓解验证集震荡。我见过不少项目在hidden_size=128时验证loss乱跳，降到64之后稳定了下来，效果反而更好。

5.4 训练不收敛：从loss曲线形状快速定位原因

最后讲讲训练阶段的快速诊断。我把常见的loss曲线形态和对应原因整理成表，方便你对照自查：

「完全不掉」这个情况我特别说一下。有一次项目里loss一直恒定在一个值，死活不动。排查了半天，发现模型输出的预测值和目标值形状对不上——一个维度是(batch, pred_len)，另一个是(batch,)，PyTorch广播机制自动把小的那个广播开了，loss有值但模型根本没学到东西。所以第一个动作永远是打印pred.shape和target.shape，确认维度完全一致再加loss代码。

6. 判断模型是否真的有效：评估指标、基线与工程落地的经验

训练完模型只是完成了第一步，真正决定项目能不能交付的是评估方法和工程化细节。这个章节讲的是：怎么看清楚模型到底好到什么程度，以及从「能跑」到「能用」之间还需要做什么。

6.1 指标选对，才能证明模型真的有用

评估时序预测常用的指标有MSE、RMSE、MAE、MAPE和R²。MSE和RMSE其实是一回事，RMSE最直观，因为它和预测目标同一量纲；MAE更稳健，不会被极端值带跑；MAPE是相对误差，适合汇报业务方，但目标值接近0时直接爆炸。

我的建议是：至少同时报告RMSE和MAE两个指标。RMSE偏高、MAE偏低，说明模型在少数点上有大误差，可能对异常值敏感；两个指标接近，说明误差分布比较均匀。只看一个指标会漏掉关键信息。

另外强烈建议计算R²或与之等效的「相对MSE」。时序数据本身有很强的自相关性，一个什么都不学的模型也能通过预测均值获得不错的绝对指标。相对MSE能告诉你模型相对「无脑基线」提升了多少：

ss_res = ((y_true - y_pred) ** 2).sum() ss_tot = ((y_true - y_true.mean()) ** 2).sum() r2 = 1 - ss_res / ss_tot

6.2 没有基线的评估都是耍流氓

做时序预测，至少要和两个基线比较：一个是「最近值外推」（也就是用上一时刻的真实值作为预测值），另一个是「移动平均外推」。这两个基线成本为零，但能非常直观地凸显模型的价值。

我有一次做一个客流预测项目，LSTM的RMSE看起来只有基线的一半，团队挺高兴。结果一计算，那个「基线」是随机猜测的平均值，真正的业务基线是最近值外推——LSTM只赢了它10%。后来靠增加外部节假日特征才把差距拉开。这个故事说明：基线选对了，模型的价值才能被正确评估，否则辛苦做出来的项目可能只是自嗨。

6.3 残差分析和置信带：看到隐藏模式的最后一步

如果模型真正捕捉到了数据的规律，残差（真实值减预测值）应该看起来接近白噪声——没有明显的自相关结构，均值接近0。如果残差曲线仍然有清晰的周期性摆动，说明模型漏掉了某个重复模式，这时候就该回头检查数据里有没有其他周期性特征。

残差的自相关性可以用np.corrcoef简单计算，也可以直接画图目测。更高级的做法是计算残差和各个输入特征的相关性——如果某个特征和残差显著相关，说明模型没学会利用这个特征，这是一个极好的「特征工程指引」。

对于单步预测，可以画预测线的置信带。方法是：训练多个不同随机种子的模型，取预测结果的分位数作为上下界。这能直观展示模型对预测的稳定性。多个模型的结果越挤在一起，说明预测越稳定；越分散，说明模型本身方差越大。这个信息对业务决策非常有用，值得花时间做。

6.4 工程落地：从PyTorch模型到稳定推理的实践建议

模型评估通过之后，工程落地还有几个坑。第一，推理阶段必须和训练阶段用完全一样的数据预处理流程，包括滑窗构建、归一化参数、特征顺序。我建议把数据预处理逻辑封装成一个类或模块，训练和推理共用同一份代码，而不是复制粘贴然后手工对齐。

第二，PyTorch模型在CPU上的推理速度通常足够，但如果有高并发需求，推荐用torch.compile或者导出ONNX加速。ONNX导出时LSTM也能正常支持，只是需要固定输入形状，动态轴需要额外配置。我建议除非真的有性能瓶颈，否则先用PyTorch原生的model.eval()配合torch.no_grad()，加上批量推理一次处理多条时间序列，大多数场景已经够用。

第三，模型上线后必须加监控和回滚机制。时序数据背后是真实世界，分布随时可能漂移——今天预测的是正常客流，明天可能就碰上突发活动。建议记录每次预测时的输入数据分布，定期和训练集分布做对比，发现偏移了就要重新训练。这个习惯可能比调模型参数更值钱，因为模型最大的风险不是算得不对，而是环境变了它还蒙在鼓里。

我在实际项目里最大的体会是：LSTM时序预测的核心难点从来不在模型本身，而在数据链路的稳定性、评估方式的科学性、和对「模型局限」的清醒认知。把这些基本功打牢，你用什么框架、什么模型结构，都能做出可靠的预测结果。