企业官网建设流程全解析

时间序列预测这个方向，这两年变化特别快。以前大家做业务预测，基本就是Prophet、ARIMA、XGBoost三件套轮着上，后来深度学习那一波LSTM、TCN、Transformer陆续进场，再到近两年一批专门为时间序列设计的开源基础模型密集冒出来，整个技术栈的选型逻辑已经和三五年前完全不一样了。我前后在几个不同的业务场景里落地过销量预测、流量预测、设备指标预测这几类任务，踩过的坑不算少，最近又集中把主流的开源时间序列模型做了一轮系统性对比，从数据准备、训练调参到推理部署全流程跑了一遍，积累了一些比较实在的结论。这篇就把整个对比研究的过程、方法和结论完整拆开讲清楚，包括每个模型适合什么场景、参数怎么设、显存和延迟大概什么量级、哪些坑是共性的、哪些是模型特有的。不管你是刚接触时间序列预测的新手，还是已经在做模型选型的老手，应该都能从里面找到可以直接抄作业的部分。

1. 对比研究的整体设计与选型思路

1.1 为什么要做这次系统性对比

先说清楚动机。时间序列模型选型这件事，最怕的就是"拿锤子找钉子"——手上会什么就用什么，结果模型和业务场景根本不匹配。我见过太多团队在销量预测上硬套Transformer，训练慢、显存炸、效果还不如一个调好参的LightGBM；也见过在长周期电力负荷预测上死磕ARIMA，完全忽略了多变量和长依赖的建模需求。这些问题的根源不是技术能力不够，而是缺少一个横向的、基于统一评测标准的对比参照。

市面上关于时间序列模型的文章，要么是单模型的原理讲解，要么是论文里的benchmark表格，真正从工程落地角度、用同一套数据和同一套评测流程把主流模型拉齐对比的内容并不多。论文里的对比往往在标准数据集上跑，和真实业务数据的分布差异很大；而工程博客又常常只讲自己用的那一个模型，缺少横向视角。所以这次我决定自己搭一套统一的评测框架，把当前主流的开源时间序列模型都放进来，用同一批数据、同一套指标、同一套硬件环境跑一遍，得出一个可以直接指导选型的结论。

这次对比覆盖的模型类型包括：统计类方法（ARIMA、ETS）、梯度提升类（LightGBM、XGBoost的时间序列用法）、深度学习类（LSTM、TCN、N-BEATS、Informer、Autoformer、PatchTST、DLinear），以及近两年出现的时序基础模型（TimeGPT类的开源替代、TimesFM、Chronos、Moirai等）。这个覆盖面基本涵盖了从传统到前沿的完整光谱，能帮读者建立起一个全局的选型地图。

1.2 评测框架的设计原则

搭评测框架这件事，最核心的原则是"公平"。不同模型的输入输出格式、训练方式、超参空间都不一样，如果不做统一封装，对比结果就没有意义。我定的几条原则是这样的：

第一，统一数据接口。所有模型都接收同样的输入格式——一个形状为(batch, lookback_window, n_features)的张量，输出形状为(batch, horizon, n_features)的预测。对于不支持多变量的模型，把n_features固定为1单独跑。对于统计类方法，用滑动窗口的方式模拟批量预测，保证和深度学习模型在同样的测试集上评估。

第二，统一评测指标。主指标用MAE和MSE，辅助指标用sMAPE和MASE。MAE对异常值不敏感，适合业务解读；MSE对大误差惩罚重，能反映模型的稳定性；sMAPE是百分比误差，方便跨数据集比较；MASE是相对于朴素预测的归一化误差，能判断模型是否真的学到了东西。四个指标一起看，避免单一指标带来的误判。

第三，统一硬件和训练预算。所有深度学习模型都在同一张显卡上跑，训练轮数和早停策略统一，保证对比的是模型本身的能力而不是调参投入的差异。统计类方法不涉及GPU，单独标注。

第四，统一超参搜索空间。每个模型给相同的搜索预算，用同一套贝叶斯优化框架调参，避免"某个模型调得细、某个模型随便跑"导致的不公平。

提示：做模型对比时，最容易犯的错误是给熟悉的模型调参调得很细，给不熟悉的模型用默认参数跑一遍就下结论。这种对比结论基本没有参考价值。要么统一搜索预算，要么明确标注哪些是默认参数跑的。

1.3 数据集的选择与构造

数据集这块我选了三类，覆盖不同的业务特征：

第一类是单变量周期数据，用的是某业务系统的日活指标，长度约两年，有明显的周周期和节假日效应。这类数据用来测试模型对周期性的捕捉能力。

第二类是多变量相关数据，用的是某设备集群的多个传感器指标，变量之间有物理上的因果关系，长度约一年，采样频率是小时级。这类数据用来测试模型对变量间依赖的建模能力。

第三类是非平稳突变数据，用的是某业务线的流量数据，中间有明显的趋势转折和突变点，长度约一年半。这类数据用来测试模型对分布变化的适应能力。

三类数据都做了统一的预处理：缺失值用前向填充加线性插值处理，异常值用IQR方法识别后做截断，然后做标准化。训练集、验证集、测试集按时间顺序7:1:2切分，绝对不能用随机切分，否则会造成数据泄漏。

1.4 模型选型的核心考量维度

对比不只是看精度，工程落地还要看一堆别的维度。我列了一个选型考量清单，每个模型都按这个清单打分：

• 预测精度：四个指标的综合表现
• 训练成本：训练时间、显存占用、是否需要GPU
• 推理延迟：单次预测的耗时，尤其是批量推理时的吞吐
• 调参难度：超参数量、对超参的敏感程度
• 可解释性：能否输出特征重要性或注意力权重
• 部署复杂度：模型体积、依赖库、是否支持ONNX导出
• 长周期能力：预测步长拉长后的精度衰减情况
• 多变量支持：原生支持还是需要改造
• 冷启动表现：数据量少时的表现
• 社区活跃度：文档、issue响应、更新频率

这十个维度里，精度只是其中之一。实际选型时，部署复杂度和推理延迟往往比精度更关键，尤其是线上服务场景。

2. 主流开源时间序列模型逐个拆解

2.1 统计类方法：ARIMA与ETS的适用边界

ARIMA和ETS是时间序列领域的"老前辈"，很多人觉得它们过时了，其实不然。在这次对比里，ARIMA在单变量、短周期、数据量小的场景下表现依然稳健，尤其是数据只有几百个点的时候，深度学习模型根本训不起来，ARIMA反而能给出可用的结果。

ARIMA的核心是三个参数(p, d, q)：p是自回归阶数，d是差分阶数，q是移动平均阶数。d的确定比较直接，看数据平稳性，ADF检验不通过就差分，一般d取0或1。p和q通过ACF和PACF图判断，或者直接用auto_arima自动搜索。我实测下来，auto_arima配合AIC准则搜索，在大多数业务数据上都能找到不错的参数组合，搜索时间在分钟级。

ETS是指数平滑的推广，核心是三个分量：误差、趋势、季节性的组合方式，每个分量可以是加法或乘法。ETS的优势是模型形式直观，参数有明确的业务含义，比如平滑系数直接反映对近期数据的权重。在趋势平稳、季节性明显的数据上，ETS经常能打赢ARIMA。

但统计类方法的局限也很明显：一是原生不支持多变量，要建模变量间关系得用VARMAX，复杂度和调参难度陡增；二是对非线性关系的建模能力弱；三是长周期预测时误差累积快。所以我的建议是，数据量小于1000个点、单变量、周期性明显、需要快速出结果的场景，优先试ARIMA和ETS；数据量大、多变量、非线性明显的场景，直接上深度学习。

2.2 梯度提升类：LightGBM的时间序列用法

LightGBM本身不是时间序列模型，但通过特征工程可以把它改造成一个很强的预测器。核心思路是把时间序列预测转成监督学习：用过去N个点的值、滑动窗口统计量（均值、方差、最大最小值）、时间特征（小时、星期、月份、是否节假日）作为特征，预测未来一个点，然后递归或直接多步预测。

这种做法的优势非常明显：训练快、调参相对容易、可解释性强（能输出特征重要性）、对缺失值和异常值鲁棒。在这次对比里，LightGBM在中等数据量、特征工程做得好的场景下，精度经常能追平甚至超过深度学习模型，而训练成本只有后者的零头。

但它的短板也很清楚：一是递归多步预测时误差会累积，直接多步预测又需要为每个预测步单独训一个模型，模型数量随预测步长线性增长；二是对长依赖的建模能力弱，因为特征窗口是人为设定的，窗口外的信息完全丢失；三是无法原生处理多变量间的动态依赖，只能靠特征拼接。

实操上，我用LightGBM的经验是：lookback窗口设2到3个周期长度比较合适，比如日周期数据设14到21天；特征里一定要加滞后特征和滑动统计量；多步预测优先用直接多步而不是递归，虽然模型多但精度更稳。参数方面，num_leaves控制在31到127之间，learning_rate设0.05左右，配合early stopping，基本不用怎么调就能出不错的结果。

2.3 深度学习基础架构：LSTM、TCN与N-BEATS

LSTM是时间序列深度学习的入门款，门控机制让它能捕捉中长期依赖。但LSTM的训练慢、对超参敏感、长序列上梯度问题依然存在。在这次对比里，LSTM在中等长度序列（lookback 50到100）上表现尚可，但一旦序列拉长到几百步，精度就明显掉队，而且训练时间比后面的模型长不少。

TCN（时序卷积网络）用因果卷积加膨胀卷积来扩大感受野，训练比LSTM快，并行度高，长依赖建模能力也更好。TCN的膨胀系数一般按1、2、4、8这样指数增长，感受野随层数指数扩大。实测下来，TCN在大多数场景下都能稳定超过LSTM，训练速度还快2到3倍，是我比较推荐的一个基础架构。

N-BEATS是一个纯MLP的架构，通过残差堆叠和基函数分解来做预测，结构简单但效果出奇地好。它的核心思想是把预测分解成趋势项和季节项，每一层学习一个残差，最后累加。N-BEATS在单变量预测上经常能打赢复杂的Transformer类模型，而且训练快、参数少。缺点是原生只支持单变量，多变量需要改造。

这三个架构里，如果只选一个入门，我推荐TCN；如果追求单变量精度且想要简单结构，N-BEATS是黑马；LSTM现在更多是作为baseline存在，实际落地优先级不高。

2.4 Transformer系：Informer、Autoformer与PatchTST

Transformer进时间序列领域后，衍生出了一大批变体，核心要解决的是原始Transformer在长序列上O(L²)复杂度和精度衰减的问题。

Informer的核心创新是ProbSparse注意力，把注意力复杂度降到O(L log L)，同时用蒸馏机制逐层压缩序列长度。它在长序列预测上确实比原始Transformer快很多，但实测精度提升有限，而且对超参很敏感，调参成本高。

Autoformer用自相关机制替代注意力，通过序列分解把趋势和周期分离，在周期性强的数据上表现不错。它的序列分解模块是个亮点，可以单独拿出来用在其他模型上。

PatchTST是近两年比较受关注的方案，核心思路是把序列切成patch，每个patch当作一个token输入Transformer。这个思路借鉴了视觉领域的ViT，效果很好——在多个公开数据集上，PatchTST用更少的参数打赢了此前的SOTA。它的另一个优势是通道独立（channel-independent）设计，每个变量单独建模，避免了多变量间的噪声干扰，同时通过共享权重保持效率。

这三个里，PatchTST是我目前最推荐的Transformer类方案，精度和效率平衡得最好。Informer和Autoformer更多是学术价值，工程落地时调参成本偏高。

2.5 线性模型逆袭：DLinear与NLinear

DLinear和NLinear是2023年引起不小讨论的工作，核心结论是：一个简单的线性层，在很多时候能打赢复杂的Transformer。DLinear的做法是把序列分解成趋势和季节两部分，各自过一个线性层，然后相加。NLinear则是先减去最后一个值，过线性层后再加回来，用来处理分布偏移。

这两个模型结构极简，参数量可能只有Transformer的百分之一，训练快、推理快、几乎不用调参。在多个公开数据集上，它们的精度和PatchTST互有胜负，但训练成本低一个数量级。这次对比里，DLinear在趋势明显、周期性规律的数据上表现非常好，在突变多的数据上稍弱。

这个结果其实给了一个很重要的提醒：不是模型越复杂越好，很多时候简单的线性模型加上合理的序列分解，就能达到很好的效果。选型时不要一上来就上Transformer，先用DLinear跑个baseline，如果它已经够用，就没必要上更复杂的。

2.6 时序基础模型：TimesFM、Chronos与Moirai

时序基础模型是近两年最热的方向，思路是把大模型那套"预训练+微调/零样本"的范式搬到时间序列上。这类模型在大量时间序列数据上预训练，然后可以直接零样本预测，或者用少量数据微调。

TimesFM是其中一个代表，基于解码器架构，在大量公开时序数据上预训练，支持零样本预测。Chronos把时间序列离散化成token，用类似语言模型的方式建模，思路很巧妙。Moirai则强调多变量和协变量支持，适合复杂业务场景。

这类模型的优势是零样本能力——不用训练就能给出还不错的预测，对冷启动场景非常友好。但局限也明显：一是对领域数据的适应性不如专门训练的模型，尤其是业务数据分布和预训练数据差异大时；二是推理成本高，模型体积大；三是可解释性差，基本是黑盒。

我的建议是，时序基础模型适合两类场景：一是完全没有历史数据、需要快速冷启动的；二是需要频繁切换预测目标、不想为每个目标单独训模型的。如果有一个稳定的、数据量充足的预测任务，专门训练的轻量模型往往比基础模型更划算。

3. 统一评测框架的实操搭建

3.1 数据管道的统一封装

评测框架的第一块是数据管道。我写了一个统一的Dataset类，核心是把原始时间序列切成(lookback, horizon)的样本对。关键参数有三个：lookback长度、horizon长度、stride步长。

lookback长度的选择要看数据的周期性。经验法则是至少覆盖2到3个完整周期。比如日周期数据，lookback至少14天；周周期数据，至少4到8周。horizon长度看业务需求，一般预测未来1到3个周期。stride控制样本重叠程度，训练时用stride=1增加样本量，测试时用stride=horizon避免重叠。

import numpy as np import torch from torch.utils.data import Dataset class TimeSeriesDataset(Dataset): def __init__(self, data, lookback, horizon, stride=1): # data: (T, n_features) self.data = torch.FloatTensor(data) self.lookback = lookback self.horizon = horizon self.stride = stride self.indices = list(range(0, len(data) - lookback - horizon + 1, stride)) def __len__(self): return len(self.indices) def __getitem__(self, idx): start = self.indices[idx] x = self.data[start:start + self.lookback] y = self.data[start + self.lookback:start + self.lookback + self.horizon] return x, y

这个封装的好处是所有模型都用同一套数据接口，切换模型时只改模型定义，数据部分不动。标准化要特别注意：均值方差只能用训练集算，然后应用到验证集和测试集，否则就是数据泄漏。我见过有人在全量数据上算标准化参数，测试集精度虚高，上线后直接崩。

3.2 训练循环与早停策略

训练循环统一封装，核心是早停和模型保存。早停的patience设10到20个epoch，监控验证集loss。这里有个细节：验证集loss用MAE还是MSE要统一，我一般用MAE，因为它对异常值不敏感，更能反映真实业务表现。

def train_model(model, train_loader, val_loader, epochs=100, patience=15, lr=1e-3): optimizer = torch.optim.Adam(model.parameters(), lr=lr) scheduler = torch.optim.lr_scheduler.ReduceLROnPlateau(optimizer, patience=5) criterion = torch.nn.L1Loss() best_val = float('inf') wait = 0 for epoch in range(epochs): model.train() for x, y in train_loader: optimizer.zero_grad() pred = model(x) loss = criterion(pred, y) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() model.eval() val_loss = 0 with torch.no_grad(): for x, y in val_loader: val_loss += criterion(model(x), y).item() val_loss /= len(val_loader) scheduler.step(val_loss) if val_loss < best_val: best_val = val_loss torch.save(model.state_dict(), 'best.pt') wait = 0 else: wait += 1 if wait >= patience: break model.load_state_dict(torch.load('best.pt')) return model

梯度裁剪这步别省，时间序列模型尤其是Transformer类，梯度爆炸是常见问题。clip_grad_norm_的阈值设1.0基本够用，如果训练不稳定可以降到0.5。

3.3 评测指标的统一计算

四个指标的计算要统一封装，避免每个模型各算各的导致口径不一致。MASE的计算需要特别注意，分母是训练集上的朴素预测误差，不是测试集的，否则指标会失真。

def compute_metrics(y_true, y_pred, y_train, seasonality=1): # y_true, y_pred: (N, horizon, n_features) mae = np.mean(np.abs(y_true - y_pred)) mse = np.mean((y_true - y_pred) ** 2) smape = np.mean(2 * np.abs(y_true - y_pred) / (np.abs(y_true) + np.abs(y_pred) + 1e-8)) # MASE分母：训练集上的朴素预测MAE naive_errors = np.abs(y_train[seasonality:] - y_train[:-seasonality]) mase_denom = np.mean(naive_errors) mase = mae / (mase_denom + 1e-8) return {'MAE': mae, 'MSE': mse, 'sMAPE': smape, 'MASE': mase}

sMAPE的分母加了个极小值防止除零，这个细节在实际数据上很重要，尤其是某些点接近零的时候。MASE小于1说明模型比朴素预测好，大于1说明还不如直接用上一个周期的值，这个判断标准很直观。

3.4 超参搜索的统一配置

超参搜索用Optuna，每个模型给相同的trial预算，比如50次。搜索空间按模型类型定义，但预算一致。这样对比的是"在相同调参投入下各模型能达到的最好水平"，而不是"我调得最细的那个模型"。

import optuna def objective(trial, model_name, train_loader, val_loader): if model_name == 'dlinear': lookback = trial.suggest_int('lookback', 48, 336, step=24) lr = trial.suggest_float('lr', 1e-4, 1e-2, log=True) # ... 构建模型、训练、返回验证集MAE elif model_name == 'patchtst': patch_len = trial.suggest_int('patch_len', 8, 32, step=8) d_model = trial.suggest_categorical('d_model', [64, 128, 256]) n_heads = trial.suggest_categorical('n_heads', [4, 8]) # ... return val_mae study = optuna.create_study(direction='minimize') study.optimize(lambda t: objective(t, model_name, train_loader, val_loader), n_trials=50)

搜索空间的设计要合理，不能给某个模型特别大的空间。比如lookback对所有模型都开放同样的范围，学习率都用对数均匀分布。这样出来的最优结果才有可比性。

4. 对比结果与选型决策矩阵

4.1 精度对比：不同数据场景下的表现

三类数据上的精度对比结果，我整理成了表格。数值是四个指标的综合排名（1最好，数值越小越好），这样比单看某个指标更直观。

几个关键结论：PatchTST综合表现最好，在单变量和多变量上都排第一，非平稳数据上排第二。DLinear作为极简模型，精度紧追PatchTST，性价比极高。TimesFM在非平稳突变数据上排第一，说明基础模型的零样本泛化能力在分布变化场景下有优势。ARIMA和ETS只在单变量小数据场景有竞争力，多变量直接出局。LSTM和Informer表现垫底，性价比不高。

4.2 成本对比：训练时间与显存占用

精度之外，成本是选型的另一个关键维度。下表是在同一张显卡上、相同数据量下的实测数据。

DLinear和LightGBM在成本上优势巨大，训练时间和显存都只有Transformer类的零头。PatchTST在Transformer类里成本控制得最好，精度还最高，这就是它值得推荐的原因。Informer和Autoformer成本高、精度还不占优，性价比确实一般。基础模型零样本不用训练，但推理时显存占用大，适合没有训练资源的场景。

4.3 选型决策矩阵：按场景给建议

把精度和成本综合起来，我整理了一个按场景的选型建议表，可以直接对照使用。

这个表不是绝对的，实际选型还要结合团队的技术栈、部署环境、维护成本。但作为一个起点，它能帮你快速缩小选择范围，避免在明显不合适的模型上浪费时间。

4.4 长周期预测的精度衰减对比

长周期预测是很多业务的刚需，比如预测未来一个季度的销量。我把horizon从24逐步拉到336，看各模型的精度衰减情况。

数值是MASE，小于1表示优于朴素预测。可以看到，PatchTST和TimesFM在长周期上衰减最慢，horizon=336时MASE还在1附近。DLinear在短周期表现好，但长周期衰减明显，horizon=336时已经不如朴素预测。Informer和LSTM长周期衰减最快，horizon超过96就基本不可用了。

这个结果说明，长周期预测场景下，模型的长依赖建模能力是关键。DLinear虽然简单高效，但它的线性结构决定了它在超长序列上的表达能力有限。PatchTST的patch机制和TimesFM的预训练范式，在长依赖上更有优势。

5. 实操中的常见问题与排查技巧

5.1 训练不收敛与梯度问题

时间序列模型训练不收敛，最常见的原因有三个：学习率太大、梯度爆炸、数据没标准化。

学习率方面，Transformer类模型对学习率特别敏感，1e-3经常太大，建议从1e-4开始试，配合warmup。我一般用前10%的step做线性warmup，然后余弦退火，这套组合在大多数模型上都能稳定收敛。

梯度爆炸在LSTM和Transformer上很常见，表现是loss突然变成nan。解决办法就是梯度裁剪，clip_grad_norm_阈值设1.0，如果还炸就降到0.5。另外检查一下数据里有没有极端值，标准化前一定要处理异常值，否则一个离群点就能让梯度炸掉。

数据标准化这块，我踩过的坑是：有人只对输入做了标准化，忘了对输出也做，结果模型学的是标准化后的输入到原始输出的映射，loss一直下不去。输入输出必须用同一套标准化参数，预测完再反标准化回来。

注意：如果训练loss正常下降但验证loss一直很高，大概率是过拟合或者数据泄漏。先检查数据切分是不是按时间顺序，再检查标准化参数是不是只用了训练集算。

5.2 预测结果偏移与分布漂移

预测结果整体偏移，是业务落地时最常见的问题。表现是预测值系统性地偏高或偏低，MAE看起来还行但业务上没法用。

原因通常是训练集和测试集的分布不一致。时间序列数据天然有分布漂移，训练集是过去的数据，测试集是未来的数据，如果中间发生了趋势变化或突变，模型就会偏移。解决办法有几个：一是用NLinear那种减最后值的技巧，让模型学习相对变化而不是绝对值；二是定期用新数据微调模型；三是用集成方法，把多个模型的预测平均，降低单模型的偏移风险。

还有一个容易被忽略的点是标准化方式。如果用全局标准化，分布漂移时标准化参数就失效了。改用滚动窗口标准化，每个预测窗口用最近一段数据的统计量做标准化，能显著缓解偏移问题。我实测下来，滚动标准化在突变数据上能把MASE降低10%到20%。

5.3 多变量建模的坑

多变量时间序列建模，最大的坑是变量间的噪声干扰。把所有变量一股脑输入模型，如果某些变量和预测目标关系不大，反而会拖累精度。

PatchTST的通道独立设计就是针对这个问题——每个变量单独建模，共享权重，避免了变量间的噪声干扰。实测下来，通道独立在变量相关性弱的数据上优势明显，在变量相关性强（比如物理上有因果关系）的数据上，通道混合可能更好。

我的建议是，先做变量相关性分析，把和目标相关性低的变量剔除。然后用通道独立和通道混合两种方式各跑一遍，看哪个效果好。不要默认多变量一定比单变量好，很多时候把目标变量单独拎出来预测，效果反而更好。

5.4 部署与推理优化

模型训好了，部署到线上又是另一回事。几个实操要点：

第一，模型导出。PyTorch模型导出ONNX能显著降低推理延迟，尤其是DLinear、TCN这类结构简单的模型，ONNX推理比原生PyTorch快2到3倍。Transformer类模型导出ONNX要小心，某些算子可能不支持，需要测试。

第二，批处理。线上推理时把多个请求攒成batch一起推理，吞吐能提升好几倍。但要注意延迟和吞吐的权衡，batch太大延迟会上去。

第三，缓存。如果预测请求有重复（比如多个用户查同一个指标的预测），加一层缓存能大幅降低计算量。

第四，降级策略。线上服务一定要有降级方案，模型推理超时或失败时，退回到朴素预测（用上一个周期的值），保证服务可用。

5.5 常见问题速查表

这张表是我踩坑踩出来的，基本覆盖了时间序列建模80%的常见问题。遇到问题先查表，能省不少时间。

6. 从对比研究到落地的一些个人体会

跑完这一整轮对比，有几个体会比较深，分享出来。

第一个体会是，模型选型没有银弹，只有匹配。PatchTST综合最强，但不是所有场景都该用它。数据量小的时候它训不起来，延迟要求高的时候它太重，可解释性要求高的时候它是黑盒。真正好的选型是理解每个模型的适用边界，然后按场景匹配。

第二个体会是，简单模型被严重低估了。DLinear和LightGBM在这次对比里的表现，让我重新审视了"复杂模型崇拜"。很多时候，一个调好参的LightGBM加上合理的特征工程，就能达到Transformer类90%以上的精度，而成本只有十分之一。选型时先用简单模型跑baseline，如果够用就别上复杂的，这个原则能省下大量算力和维护成本。

第三个体会是，基础模型值得持续关注。TimesFM和Chronos在零样本和分布漂移场景下的表现，展示了预训练范式的潜力。虽然现在它们在专门任务上还打不过专门训练的模型，但随着预训练数据规模和模型能力的提升，这个差距在缩小。对于预测目标频繁变化、不想为每个目标单独训模型的团队，基础模型是个值得投入的方向。

第四个体会是，评测框架本身比对比结果更有价值。这次搭的统一评测框架，后续换新模型、换新数据都能直接复用，省去了重复搭环境的时间。建议每个做时间序列的团队都搭一套自己的评测框架，把数据管道、训练循环、指标计算、超参搜索都封装好，这样每次选型都是一次配置而不是一次重写。

最后分享一个实操小技巧：做模型对比时，先固定一个强baseline（我一般用DLinear或LightGBM），所有新模型都和它比。如果新模型打不赢baseline，先别急着调参，想想是不是场景不匹配。很多时候，模型打不赢baseline不是模型不行，而是这个场景本来就不需要那么复杂的模型。这个思路能帮你快速过滤掉大量无效尝试，把精力集中在真正有潜力的方向上。