Chronos-2时间序列基础模型：从零样本预测到生产流水线

时间序列预测这件事我做了不少年头最大的感受是模型本身从来不是最难的部分难的是每个序列都要单独伺候。一条 SKU 一个 ARIMA一个门店一个 Prophet参数调到天亮换一批数据又得重来。后来大家转向深度模型PatchTST、TFT、DeepAR 这一类确实把精度拉上去了但代价是要准备足量的训练数据、要设计网络结构、要调学习率和窗口长度中小团队根本吃不消。时间序列基础模型这条路线就是冲着这个痛点来的在海量异构序列上预训练一个通用模型下游任务零样本直接预测或者拿少量数据微调一下就能用。Chronos-2 就是这条路线上的一个代表性模型它在初代缩放加量化再交给序列模型的思路基础上把多变量、协变量、概率输出和上下文长度这几个工程上最要命的点往前推了一步。这篇内容我想讲清楚三件事它到底解决了什么问题、学习它该按什么顺序看哪些资料、以及怎么把它真正塞进一条能跑的生产流水线。适合已经会用 pandas 和 PyTorch、被传统预测方法折磨过、想认真评估基础模型能不能落地的同学也适合刚接触时间序列、想抄一份完整作业的新手。1. 先搞清楚 Chronos-2 到底在解决什么问题1.1 从一个序列一个模型到一个模型一堆序列传统统计模型的假设很明确序列是平稳的、或者差分后平稳的、残差是白噪声。这个假设在教科书数据上很漂亮但真实业务数据几乎从不满足——促销会让方差突变节假日会让周期性错位新品上市会让历史长度为 0。所以每换一个序列你就得重新判稳、重新定阶、重新做残差检验工作量随序列数量线性甚至超线性增长。我见过一个团队维护三千多条序列的预测光调参脚本就有两千多行任何人离职这块就没人敢动。深度学习的思路是让模型自己学模式确实绕开了人工定阶但引入了新的成本你需要为每个数据集训练一个模型序列之间的知识无法迁移。冷启动序列历史只有几周基本没救因为训练样本不够。基础模型的核心价值就在于跨序列的知识迁移——它在预训练阶段见过成千上万种形态的序列包括各种周期、趋势、突变、噪声水平这些先验被压缩进参数里下游拿到一条从没见过的序列模型也能给出一个像样的预测。这个范式转变的意义类比一下就是从每个病人单独配药变成有一个见过百万病例的通用医生。通用医生不一定比专科医生在每个细分领域都强但它能在你还没来得及做全套检查的时候就给出一个不算离谱的判断而且边际成本几乎为零。对业务方来说五秒钟给出一个 85 分的预测往往比两周后给出一个 92 分的预测更有价值——因为预测是要驱动决策的决策有时效性。1.2 Chronos-2 相对初代动了哪些关键地方要理解 Chronos-2得先理解初代的做法。初代的流程可以拆成四步均值缩放、均匀分箱量化、序列模型编解码、采样还原。第一步把序列除以自身的绝对值均值让不同量级的序列落到同一个数值区间这一步很重要否则模型会被量级差异带偏第二步把连续的实数值映射到固定数量的离散桶里相当于把23.7 摄氏度这样的连续读数按刻度尺切成有限个格子用格子编号代替原始数值第三步把 token 序列送进一个编解码结构的序列模型第四步推理时做多次采样把采样得到的多条路径还原回原始量级用这些路径的经验分位数作为预测区间。这个设计的好处是概率预测是天然的——你不是预测一个点而是采样出一堆可能的未来轨迹取中位数当点预测取 10% 和 90% 分位数当区间。坏处是自回归解码慢一步一步往前推预测 100 步就要解码 100 次批量推理时开销很吓人。后来的改进版本用 patch 化加直接多步输出的方式把速度提上来了把序列切成片段一次性输出整个片段的预测值避免了逐步累积误差。Chronos-2 我理解主要在这几个维度往前走支持多变量联合建模也就是不再把每个维度当成独立序列而是让模型在同一时间步上看到多个相关变量利用它们之间的相关性支持协变量输入包括未来可知的协变量比如已经排好的促销日历、已知的节假日和历史协变量上下文长度拉长能容纳更长的历史窗口这对季节性很长的场景比如年度周期、月度周期叠加周内周期非常关键推理效率进一步优化组注意力之类的结构让多变量场景下的计算量不至于爆炸。注意上面这些能力的具体实现和参数规模一定要以官方模型卡和仓库里的说明为准。基础模型迭代很快接口和默认值经常变我见过不少人拿着半年前的博客代码去跑新版本报错报了一下午。养成先读模型卡再写代码的习惯能省掉大量时间。1.3 什么场景该用它什么场景别硬上这里我想说得直白一点不是所有预测问题都适合上基础模型。场景特征建议方案原因序列数量多、单个序列历史短优先用基础模型零样本跨序列先验在冷启动上优势最大序列数量少、单序列历史极长且规律稳定传统统计模型或简单深度模型足够基础模型的先验优势用不上反而引入不确定性需要多步概率区间、决策依赖分位数基础模型优势明显采样式输出直接给分布不用额外假设强依赖外部因果变量价格、库存、竞品动作需要协变量支持并做特征工程纯历史外推学不到因果数据完全不可外传、只能本地部署开源权重可以本地跑但要评估算力权重可下载推理成本需自担对延迟要求极高毫秒级在线打分建议蒸馏或缓存别直接上大模型大模型推理有固定开销我自己的判断标准是先看序列的信息密度。如果一条序列只有 30 个历史点你想预测未来 7 天传统方法基本废掉这时候基础模型的先验就是救命的。反过来如果你有一条十年的日频序列规律极其稳定用 ETS 三行代码就能拿到很好的结果那就没必要上大模型给自己找麻烦。2. 资料清单按学习路径分层的阅读顺序2.1 第一层模型卡和快速上手示例先跑通再理解我的建议是先跑通再回头理解原理不要一上来就啃论文。原因很现实论文里的符号体系和代码里的接口是两套语言你先建立这个东西能跑出结果的体感后面读论文时才有锚点。这一层你要找的资料很明确模型卡Model Card通常会写清楚模型支持的输入形态、上下文长度上限、输出格式、推荐的使用方式仓库里的 README 一般会给一个最小示例几行代码加载模型、传入一条序列、输出预测如果有 notebooks 目录里面的示例通常覆盖了单变量、多变量、协变量、批量推理这几种典型用法这是最快的上手路径。读模型卡的时候重点看三个地方输入的形状要求是 [batch, context_length] 还是 [batch, variate, context_length]、上下文的长度限制超了会被截断很多人不知道这一点以为模型能看到全部历史、输出的组织方式是返回采样矩阵还是直接返回分位数。这三条搞清楚了后面百分之八十的报错都能避免。我踩过的一个坑是早期版本的接口对输入张量的维度顺序有隐含假设我传了一个 [1, 512] 的張量进去模型把它当成 512 条长度为 1 的序列输出了 512 条预测我还纳闷为什么结果全是平的。后来才发现是自己维度搞反了。所以第一次跑通之后一定要打印一下输入的 shape 和输出的 shape确认符合预期。2.2 第二层技术报告重点看这几节跑通之后再去读技术报告效率会高很多。读的时候不用逐字逐句我一般按这个顺序挑着看数据与预处理部分。这部分决定了模型的世界观。看它用了哪些公开数据集、怎么做的归一化、怎么处理的缺失值、怎么构造的训练样本。这部分看完你就知道模型的适用边界在哪——比如如果训练语料里几乎没有间歇性需求大量零值的序列那你在备件、低频商品这类场景上用它效果可能会让你失望。Tokenization 与模型结构部分。理解量化分箱的作用理解为什么要做缩放理解编码器和解码器各自负责什么。这部分不需要抠每个公式但要知道为什么这么设计。比如均值缩放解决了量级问题分箱量化把回归变成分类从而绕开了输出分布的假设这些都是有明确动机的设计选择。实验与消融部分。这部分信息量最大。看它在哪些基准上赢了、在哪些基准上输了、输了的原因是什么。消融实验尤其值得看它会告诉你哪个设计是关键的、哪个是锦上添花的。我特别关注去掉某个模块之后性能掉了多少这类表格因为它直接告诉你这个模块在你的场景里值不值得复现。局限性与失败案例部分。这部分很多人直接跳过我觉得是最大的浪费。作者自己承认的局限往往就是你在生产环境里最先撞上的墙。2.3 第三层源码与评测基准动手改起来看懂原理之后就该看代码了。我建议至少把推理路径的代码读一遍重点关注几个函数预处理函数归一化和分箱在这里、前向传播模型的输入输出结构、后处理函数反归一化和分位数计算。这三个函数决定了你能不能做自定义改造。比如你想用自己的归一化方式比如对数变换后再送进去就得知道预处理在哪一步、能不能替换比如你想改变分位数的取法用 5% 和 95% 而不是 10% 和 90%就得知道后处理是怎么组织的。这些改动看起来小但在实际业务里非常常见。评测基准这块公开的时间序列评测集合值得关注。这类基准通常包含大量来自不同领域的真实序列覆盖不同预测长度和不同频率。拿自己的业务数据在这个基准上做一次对照实验是判断这个模型到底适不适合我最有效的方法。我会把基准里的几个典型数据集下载下来用自己准备上线的模型配置跑一遍再和自己的数据对比看相对排名是否一致。2.4 第四层周边生态决定能不能上生产这一层经常被忽略但它决定了项目能不能真正落地。推理加速相关模型量化int8、bf16、批处理、缓存机制、导出成通用推理格式。如果要做在线服务这些是必选项。可视化与诊断预测区间的可视化、残差分析、分位数校准图预测的 90% 区间是否真的覆盖了 90% 的实际情况。这个校准检查非常重要我见过太多人直接拿模型输出的区间去做库存决策从来没验证过区间是否可靠。回测框架滚动预测、多折交叉验证、指标计算。这部分建议自己写不要依赖现成的因为业务口径往往和通用框架不一致。数据管道缺失值填充、异常值处理、序列对齐。基础模型对输入的脏数据容忍度比想象中低尤其是长序列里夹杂几个极端异常值会显著影响预测结果。3. 环境搭建与最小可运行示例3.1 环境与依赖选型先说硬件。这个模型在 CPU 上能跑但只能做小规模验证。实际使用强烈建议上 GPU显存需求取决于模型规模和批大小。我的经验是小尺寸模型在 8G 显存上跑批推理没问题中等尺寸建议 16G 以上大尺寸模型要 24G 起步。Python 环境建议用独立虚拟环境核心依赖是 PyTorch 和模型仓库本身。版本匹配这块要特别注意PyTorch 版本和 CUDA 版本不匹配是最常见的启动失败原因。python -m venv chronos-env source chronos-env/bin/activate pip install --upgrade pip pip install torch --index-url https://download.pytorch.org/whl/cu121 pip install transformers accelerate pandas numpy matplotlib提示如果你在离线环境部署先把权重文件完整下载到本地目录然后用本地路径加载不要指望运行时再去联网拉取。我见过线上服务因为模型文件没缓存好容器重启后卡在下载环节二十分钟的案例。3.2 第一个零样本预测三十行代码跑通下面是跑通零样本预测的最小流程。模型标识这里用占位名实际使用请替换成官方仓库里给出的标识。import numpy as np import pandas as pd import torch from chronos import ChronosPipeline # 1. 加载模型 pipeline ChronosPipeline.from_pretrained( chronos-2-model-id, # 以官方仓库为准 device_mapcuda, # CPU 环境改成 cpu torch_dtypetorch.bfloat16, # CPU 上用 torch.float32 ) # 2. 准备上下文序列 # 假设手里是一列按时间排序的销量数据 values df.sort_values(ds)[y].to_numpy(dtypenp.float32) context torch.tensor(values[-1024:]) # 取最近若干点别超过上下文上限 # 3. 零样本预测 forecast pipeline.predict( contextcontext, prediction_length28, # 预测未来 28 步 num_samples100, # 采样路径数越大越稳但越慢 ) # 4. 取分位数 samples forecast[0].numpy() # 形状 [num_samples, 28] q10, q50, q90 np.quantile(samples, [0.1, 0.5, 0.9], axis0) result pd.DataFrame({ step: np.arange(1, 29), p10: q10, p50: q50, p90: q90, }) print(result.head())这段代码里有几个参数值得单独说。上下文长度。截取多少历史点直接决定预测质量。理论上越长越好但有两个约束一是模型本身有上下文上限超了会被截断二是过长的历史可能包含已经失效的旧模式比如两年前的促销策略和现在完全不同反而干扰预测。我的经验是日频数据取最近 4 到 8 个完整周期周频数据取最近 2 到 4 个完整周期同时不超过模型上限。num_samples。这个参数控制采样路径数量。20 条路径时区间估计的抖动很明显100 条时基本稳定500 条以上边际收益递减但耗时线性增长。生产环境我一般用 100 到 200。prediction_length。预测步长越长不确定性越大这是不可避免的。如果业务需要预测 90 天但模型在 30 步之后就明显发散那更靠谱的做法是分段预测或者对长周期的输出做保守收缩。3.3 输出结果该怎么解读很多人拿到预测结果第一反应是看 p50然后就结束了。这是不对的。概率预测的价值恰恰在于区间。先做一件事把 p10 和 p90 画出来和实际历史数据叠在一起看。如果你发现区间宽得离谱比如预测值是 100区间是 20 到 500那说明模型对这条序列的不确定性评估很高这时候把 p50 单独拿出来做决策是危险的。接着做一个校准检查拿历史数据做回测统计实际值落在 p10 到 p90 之间的比例。如果这个比例远低于 80%说明区间偏窄模型过于自信如果远高于 80%说明区间偏宽模型过度保守。这个检查我每上一个新场景都会做一次它比看 MAE 更能反映模型的可信度。还有一个容易忽略的点预测分布的形态。采样得到的分布可能是双峰的这种情况下 p50 可能落在一个概率很低的空档里。所以除了分位数我还会简单看一下样本的直方图确认分布形态是否合理。3.4 这一段最容易踩的坑说几个我实际遇到过的问题。第一个坑是 dtype 不匹配。模型权重是 bfloat16输入张量是 float32某些环境下会直接报错或者输出垃圾值。解决方式是显式转换输入张量的 dtype与模型保持一致。第二个坑是 NaN 处理。序列里有缺失值是常态但不同的处理方式对结果影响巨大。直接填 0 会让模型误以为出现了需求断崖前向填充会让模型误以为需求平稳插值在长缺口上会产生虚假的平滑趋势。我的做法是短缺口连续少于 3 个点用线性插值长缺口用同周期同位置的历史中位数填充。第三个坑是异常的尖峰。原始数据里如果有一个比正常值大两个数量级的点比如系统故障导致的重复计数均值缩放会被严重带偏整条序列的预测都会被拉高。所以预处理阶段必须做异常检测我一般用分位数截断或稳健 z-score 处理。4. 实战示例把模型接进一条完整的预测流水线4.1 场景设定与数据准备假设我们要做一个零售场景的需求预测数据是若干门店若干商品的日销量需要预测未来 28 天并且给出 80% 和 95% 两个区间的上下界。这个场景的难点在于新商品没有历史、促销有明确日历、商品之间有替代关系。数据准备阶段我会做这几件事。先把原始表按item_id和store_id组合成唯一序列键按日期排序补齐缺失的日期不是每个商品每天都有销量记录没记录不等于销量为零但对日频预测来说按零处理是合理近似。然后构造协变量表是否促销、是否节假日、是否周末、是否有陈列资源。这些是未来可知的协变量因为促销日历是提前排好的。import pandas as pd import numpy as np # 主表日期、序列键、销量 df pd.read_csv(daily_sales.csv, parse_dates[ds]) df df.sort_values([item_id, store_id, ds]).reset_index(dropTrue) # 补全日期网格缺失填 0 full_idx ( df.groupby([item_id, store_id])[ds] .agg(lambda s: pd.date_range(s.min(), s.max(), freqD)) .explode() .reset_index(nameds) ) df full_idx.merge(df, on[item_id, store_id, ds], howleft) df[y] df[y].fillna(0.0) # 协变量表未来可知 cal pd.read_csv(promo_calendar.csv, parse_dates[ds]) df df.merge(cal, onds, howleft) df[[is_promo, is_holiday, is_weekend]] ( df[[is_promo, is_holiday, is_weekend]].fillna(False).astype(int) )这里有个细节值得说补全日期网格这一步看似简单但如果用reindex而不注意多级索引的构造很容易把不同商品的日期搞混。我一般会先构造完整的键组合再合并这样不容易出错。4.2 多变量预测和协变量的正确用法多变量的意义在于利用同一时间点上的相关性。举个直观的例子同一门店里的可乐和雪碧销量走势高度相关如果某天可乐突然暴涨大概率是促销模型看到这个信号对雪碧的预测也应该相应调整。单变量模型完全看不到这层关系。协变量分两类用错了会出大问题。未来可知协变量是那些在预测期开始前就确定的值比如促销排期、节假日、已经签好的合同量、天气预报。这类协变量可以直接喂给模型作为条件信息。历史协变量是那些只在历史上可观测、预测期未知的量比如当天的实际客流、实际气温。这类变量在预测期没有值只能通过模型自己对未来的推断来处理。注意把未来未知的量当成已知协变量喂进去是时间序列建模里最隐蔽也最致命的错误。它会让离线评估的效果好得离谱上线之后直接崩盘。我做任何特征工程之后都会问一句这个特征在预测时刻真的能拿到吗接口层面不同版本对协变量的传法不完全一样有的通过独立的参数传有的要求把协变量拼在输入张量里。写代码前先看示例别凭感觉试。4.3 回测设计与评估指标选择评估这块我想多花点篇幅因为大多数人在这里做得不够严谨。回测的基本结构是滚动原点选定一系列历史切点每个切点用之前的数据做上下文、预测之后若干步、和真实值比对。切点之间的间隔要和生产环境的更新频率一致——如果是每天跑一次预测切点间隔就是 1 天如果是每周跑一次间隔就是 7 天。def rolling_backtest(series, pipeline, context_len, horizon, n_windows, step): results [] n len(series) for i in range(n_windows): end n - horizon - i * step if end - context_len 0: break ctx torch.tensor(series[end - context_len:end], dtypetorch.float32) truth series[end:end horizon] fc pipeline.predict(contextctx, prediction_lengthhorizon, num_samples100) q np.quantile(fc[0].numpy(), [0.1, 0.5, 0.9], axis0) results.append({ window: i, mase: mase(truth, q[1], series[:end], seasonality7), wql: weighted_quantile_loss(truth, q, [0.1, 0.5, 0.9]), coverage80: np.mean((truth q[0]) (truth q[2])), }) return pd.DataFrame(results)指标这块我建议至少看三个。MASE平均绝对标度误差是点预测的主指标它的好处是做了季节性朴素预测的归一化跨序列可比。计算方式是用预测误差的绝对值均值除以训练段上季节性朴素预测的误差均值。分母如果用错了季节性周期MASE 会虚高或虚低日频数据一般取 7周频数据取 52 或者 4看业务周期。def mase(y_true, y_pred, y_train, seasonality7): naive_err np.mean(np.abs(y_train[seasonality:] - y_train[:-seasonality])) if naive_err 0: return np.nan return np.mean(np.abs(y_true - y_pred)) / naive_errWQL加权分位数损失是概率预测的主指标它同时对多个分位数的准确性打分比分位数分别算再平均更合理。区间覆盖率是校准指标检查实际值落在预测区间内的比例是否接近名义水平。指标衡量什么参考阈值什么时候会失真MASE点预测相对季节性朴素法的改进小于 1 说明优于朴素法序列长期平稳时区分度低WQL分位数预测的整体质量越小越好需横向对比极端值多时被放大覆盖率区间是否可信80% 区间覆盖率应在 75%~85%样本太少时波动大sMAPE相对百分比误差小于 20% 算可用真实值接近 0 时爆炸4.4 微调还是零样本一个成本收益的判断零样本先跑一遍看指标能不能接受。如果能就别微调——微调会引入训练成本、过拟合风险和版本管理复杂度。如果零样本明显不行先别急着微调先检查这三件事上下文长度是否合理、预处理是否把信号破坏了、评估口径是否公平比如你的业务存在大量零销量而 MASE 的分母被拉得很小。我遇到过的模型不行的案例里大概有七成是数据准备的问题不是模型的问题。确实需要微调的话我的建议是数据量少于几百条序列时不要全参数微调用轻量的适配方式比如只训练最后几层或者加低秩适配层学习率设得比正常训练小一到两个数量级早停耐心值设小一点。验证集一定要按时间切分不能随机切分否则会严重高估效果。# 微调时的时间切分示例 train_end int(len(series) * 0.75) val_end int(len(series) * 0.9) train series[:train_end] val series[train_end:val_end] test series[val_end:]4.5 批量推理的性能优化生产环境通常要一次性预测几千条序列逐条跑会慢到无法接受。我实测下来几个优化手段叠加能把耗时降一个数量级。批处理是第一步。把多条序列拼成一个 batch 送进去GPU 利用率能直接拉满。难点在于序列长度不一致需要 padding。padding 值选 0 还是 NaN 会影响结果我一般用序列自身的均值填充减少分布偏移。def make_batches(sequences, batch_size, context_len): seqs [np.pad(s[-context_len:], (max(0, context_len - len(s)), 0), constant_valuesnp.nanmean(s)) for s in sequences] tensor torch.tensor(np.stack(seqs), dtypetorch.float32) for i in range(0, len(tensor), batch_size): yield tensor[i:i batch_size]长度分桶是第二步。把长度相近的序列分到一组能显著减少 padding 浪费。如果序列长度分布很分散比如从 30 到 3000 都有分桶带来的收益非常可观。混合精度是第三步。GPU 上用 bfloat16 或 float16显存占用减半速度提升明显。注意 CPU 上不要用半精度很多算子不支持会退化成极慢的实现。推理模式别忘了。用torch.inference_mode()包住推理代码能关掉梯度追踪省下不少开销。这个改动一行代码收益稳定。5. 常见问题与排查实录5.1 预测结果太平了怎么办这是最高频的问题表现形式是历史数据明明有很强的周期波动预测出来却是一条接近直线的平缓曲线。原因通常有三个。第一是上下文里包含了太多低信息量的部分比如序列开头有一大段零值或者常数模型把这段当成主要模式学走了。解决办法是裁掉开头的无效段或者只用最近的有效区间。第二是归一化被异常值带偏一个极端大的值把均值拉高整条序列缩放后都挤在很小的区间里模型分辨不出波动。解决办法是预处理阶段做稳健缩放用中位数或分位数而不是均值。第三是采样次数太少分位数估计噪声大看起来像平的。增加到 100 以上通常就稳了。还有一种情况是模型本身对这条序列的信心不足输出的分布很宽p50 自然就趋于平滑。这时候应该看 p10 和 p90 的宽度——如果区间很宽说明这是模型在表达不确定性不是 bug。业务上可以考虑对这种情况人工介入或者切换到备用模型。5.2 显存和内存问题怎么排查显存爆炸的原因基本可以归成三类排查顺序建议从简单到复杂。批太大是最常见的。先试着把 batch size 减半如果问题消失就是它。上下文太长排第二注意上下文长度对显存的影响是线性的但注意力计算可能是平方级的长度翻倍显存可能翻四倍。采样数太多排第三num_samples 影响的是输出张量的大小1000 条采样在长预测步长下会占很多显存。现象可能原因排查动作一开始推理就 OOM模型加载占满显存减小批大小检查是否同时加载了多个模型副本前几条正常后面 OOM显存泄漏或缓存累积检查是否有张量被意外保留用 inference_mode显存够但速度极慢数据在 CPU 和 GPU 之间频繁搬运检查 dataloader提前把张量搬到设备上CPU 内存爆炸一次性读入全部序列改成分块读取或用生成器5.3 长周期预测和短周期预测的不同策略预测 7 天和预测 180 天是两件不同的事。短周期7 到 30 天我一般直接用模型一次性输出配上 100 到 200 条采样。这个区间内模型的先验比较可靠结果通常直接用就行。长周期90 天以上建议分两段走。第一段用模型直接预测前 30 到 60 天这段相对可靠第二段用预测值当作历史再喂回去的滚动方式继续推但要做好心理准备——误差会累积越往后越不可信。我一般会给长周期的预测加一个保守收缩系数或者在超过某个步长之后直接退化成去年同期加趋势修正的简单方法。还有一个技巧是多尺度输入。如果你要预测 90 天不要只喂日频数据可以把历史聚合成周频或者月频一起喂进去让模型同时看到短期波动和长期趋势。这个做法在季节性很强的业务上效果明显。5.4 一份可直接对照的排查速查表报错或异常大概率原因处理方式张量维度不匹配输入形状与模型期望不符打印输入 shape对照模型卡确认维度顺序dtype 报错输入与权重精度不一致输入转为与模型相同的 dtype输出全是同一个值上下文含大量常数或全零检查上下文区间剔除无效段区间覆盖率为 0 或 1反归一化错误确认分位数计算在原始量级上进行预测值量级离谱缩放因子被异常值污染做异常截断改用稳健缩放单条快、批量慢batch 内长度差异过大按长度分桶减少 padding结果每次都不一样采样随机性设置随机种子或增大采样数取均值节假日预测偏低缺少协变量信息补充节假日和促销协变量我自己最常回头查的是第一条和第六条。维度问题在于不同版本的接口约定不一样我经常在切换环境时栽跟头批量性能问题则往往被忽略直到线上延迟告警才想起来。6. 我个人的几点实操体会模型选型这件事我现在的做法是三个一起跑。同一个业务场景我会同时准备传统统计方法、一个轻量深度模型、一个基础模型用同一套回测口径跑一遍。三个结果摆在一起看往往能发现一些单看一个模型发现不了的东西——比如基础模型在大部分序列上明显更好但在少数几条上特别差那这几条序列大概率有特殊结构值得单独分析。预处理的重要性被严重低估了。我做过一个粗略统计同一批数据只是把缺失值填充方式从填零改成同周期中位数MASE 就能差出 15% 以上。基础模型的先验再强也架不住喂进去的数据本身就有问题。所以在调模型之前先花时间把数据管道理顺投资回报率高得多。还有一点是别迷信零样本。零样本的卖点是开箱即用但能用和好用之间差着一整个特征工程的距离。我现在的做法是零样本先跑出基线然后针对性地补协变量、调上下文长度、做序列筛选通常能再提升一截。这个过程比微调便宜得多效果也更可控。最后分享一个判断模型是否真的学到了东西的小技巧把上下文序列做一次相位平移比如整体往前挪 7 天如果预测结果的形态也跟着平移了说明模型确实在依赖近期模式如果预测几乎不变说明它可能只是在输出一个接近均值的保守估计这时候就该回头检查输入了。这个方法我在好几个场景里用过比看指标更快能定位问题。