谷歌TimesFM 3.0实测：零样本预测够用吗？

从ARIMA到基础模型：时间序列预测的范式转变

大多数企业的时间序列预测仍然沿袭着传统路径：为每一条需要追踪的序列单独训练一个模型，用ARIMA或梯度提升树拟合，调参，再换下一条序列重复整个过程。如果你管理着一千家门店，理论上就需要维护一千个独立模型。语言、代码、图像领域早已被基础模型重塑，而预测团队却还在用"手工作坊"的方式运转。

谷歌研究院推出的TimesFM系列试图打破这一局面。它是一个仅解码器（decoder-only）的Transformer，完全在时间序列数据上训练，最大的卖点是零样本预测——不需要在你的业务数据上做任何训练，直接给出预测结果。最新的TimesFM 3.0在超过一万亿个时间点上完成了预训练，这些数据既包含真实序列，也包含大量合成数据。

这个模型的核心思路并不复杂。它把你的历史数据切成32个时间步的"补丁"（patch），每个补丁视为一个token，然后像语言模型预测下一个词那样预测下一段图表走势。用视频作者的话说，这就是"图表的自动补全"。与语言模型不同的是，它输出的不是一条线，而是每天的中位数预测加上一个不确定性区间，让你同时看到最可能的情况和下行风险。

ARIMA（自回归积分滑动平均模型）是时间序列预测的经典统计方法，由自回归（AR）、差分（I）和滑动平均（MA）三部分构成。AR项用过去若干期的值预测当前值，MA项用过去若干期的预测误差修正当前预测，差分则用于消除趋势和季节性使序列平稳。ARIMA要求序列满足平稳性假设，通常需通过ACF/PACF图或信息准则（如AIC）确定阶数，且对非线性关系和外部协变量的处理能力有限。梯度提升树（如XGBoost、LightGBM）则通过集成多棵弱决策树逐步拟合残差，能自动捕捉非线性与交互效应，在特征工程充分时表现优异。但两者共同的根本局限是：每个模型只针对单条序列或单一任务训练，无法跨序列迁移知识，因此企业不得不为成千上万条序列重复建模调参。这正是基础模型试图用预训练加零样本泛化来取代的“手工作坊”模式。

3.0版本的关键升级：把协变量装进模型内部

TimesFM 2.5发布于前一年，它的工作方式相对简单：每次只根据历史值预测一条序列。如果你想考虑未来已知的事件——比如即将到来的假日或计划中的促销——需要在模型外部单独做一步回归拟合，然后让TimesFM去预测回归没有解释的残差部分。这个流程能跑通，但盘根错节的外部环节增加了工程复杂度。

3.0版本把整个机制搬到了模型内部。你可以同时喂入多条相关序列及其历史值，也可以直接传入未来的协变量输入。在Transformer内部，每个token会"向前看"那些即将到来的输入信号，所以在预测某一周之前，模型已经知道那周有假日或促销。此外，3.0一次性生成整个预测窗口，而不是逐块生成（chunk-by-chunk），推理速度因此显著提升。

谷歌在论文中声称3.0在三个公开预测基准上排名基础模型第一。但这个说法需要用真实数据来检验。

协变量（covariate）指在预测目标之外、可能影响目标走势的辅助变量。按时间可得性分为两类：历史协变量（如过去的营销支出、天气）在预测时点已知历史值；未来协变量（如已排定的假日日历、计划中的促销和定价）在预测时点的未来取值已确定。传统ARIMA可通过ARIMAX扩展引入协变量，梯度提升树则直接把协变量作为特征。TimesFM 2.5采用两阶段法：先外部回归拟合协变量对序列的影响，再让模型预测残差。3.0改为在Transformer注意力机制中让每个时间步token直接“看到”未来协变量token，实现端到端联合建模——这既减少了工程环节，也避免了外部回归误差向预测结果的传播。但需注意，模型只能学习训练数据中出现过的协变量与目标之间的映射关系，对历史中从未变动过的变量无法推断其弹性。

纽约地铁实测：零样本能打，但两个版本分歧明显

视频作者用纽约地铁的每日客流量作为测试数据，覆盖地铁、公交和通勤铁路共七项服务。选择这个数据集的关键原因是：3.0的训练数据截止到八月底，所以九月份的数据不可能出现在训练集中——真正的样本外测试。

实验设计是给两个版本同样的历史数据（截止八月底），要求预测未来四周，重点关注劳动节（Labor Day）那一周。只用历史数据预测时，两个模型都预测了一个"正常的周一"，因为近期数据里没有任何信号提示假日即将到来。当把假日日历作为未来输入传入后，预测值立刻在劳动节当天出现了下降。

跨六个截止日期和七项服务的系统测试显示，两个版本在零样本条件下都将预测误差相对季节性基线降低了约25%。加入假日日历后，两个模型进一步改善。你可能没注意到，在这组数据上，2.5版本对额外输入的利用略好，不确定性区间也更可靠；而3.0版本的推理速度要快好几倍。

商业场景压力测试：预测准≠决策对

延续已有模式是一回事，用预测做商业决策是另一回事。作者构建了一个名为Lumen的多区域软件业务模拟，包含近四年的每日试用和收入数据，以及营销支出、促销、定价和假日等计划变量。由于是模拟环境，可以知道任何计划下的真实结果，从而公平评分。

基础预测能力的测试结果相当亮眼：在一个不含九、十月份数据的数据库分支上，TimesFM 3.0在不到一秒内完成未来两个月的预测，收入偏差在2%以内。作者还搭建了夜间流水线，由定时的Neon函数排队执行任务。一个季度后回评10月31日的预测，3.0的收入偏差仍然在6%以内，两个版本都没有超出各自的不确定性区间。

基础精度过关后，作者把真实的规划问题交给了Gemini智能体：营销团队有两个方案，方案A加深黑色星期五的折扣，方案B保持黑五不变但将一月份营销预算翻倍；同时财务想知道1月1日提价会有什么影响。每个方案在独立的Neon分支上运行，不触碰生产数据。

结果暴露了零样本模型的软肋。提价问题上，智能体表现正确：它检查历史数据后发现四年间定价从未变动过，于是告诉财务不要信任任何提价预测。但在营销预算问题上，两个版本给出了截然相反的答案——3.0对一月份预算翻倍几乎无反应，2.5则预测收入大幅跳升。智能体选择信任3.0，推荐了方案A，而真实结果是方案B带来更多收入。三轮测试中智能体选错了两轮。

作者进一步排除了数字格式的干扰，用四种不同的营销支出编码方式测试3.0的反应，结论一致：模型对超出历史范围的大幅变动缺乏可靠的响应能力。

Neon是一个Serverless Postgres平台，其核心特性是数据库分支（branching）：可以像Git分支一样从生产数据库瞬间创建数据副本，用于测试、模拟或what-if分析，而完全不触碰生产数据。在本文的Lumen模拟中，作者的夜间流水线通过定时触发的Neon函数排队执行预测任务，每个营销或定价方案都在独立分支上运行，因此可以安全地并行比较多种假设场景。这种“分支+定时函数”的组合让零样本预测模型能够以低成本嵌入真实业务流程——预测任务按计划自动运行，结果写入隔离分支供智能体或分析师读取。需要区分的是，数据库分支解决的是数据隔离与编排问题，并不提升模型本身的预测能力；模型对超出历史分布的方案是否可靠，仍取决于训练数据覆盖的变异范围。

上生产前必须知道的四个限制

第一，模型只能外推你历史中真正动过的杠杆。 如果定价这类变量在历史数据中从未变化，任何零样本模型都无法知道你的客户价格弹性。这不是基础模型独有的问题，传统机器学习模型同样受限于此，解法是做小规模受控实验。

第二，警惕大幅超出分布的变动。 当方案把预算或促销推到远超历史范围的水平时，2.5和3.0可能严重分歧。用what-if预测做决策之前，应该拿历史活动的实际提升幅度来做合理性检验，而不是让单一模型版本替你选择赢家。

第三，校准不确定性区间。 在纽约地铁数据上，3.0的置信区间偏窄。上生产前务必在历史数据上做回测，检查实际值落在区间内的频率是否符合预期。

第四，注意许可证差异。 TimesFM 3.0自行部署属于非商用许可，商用访问需通过Google Cloud路由；而2.5在Apache 2.0下开源。

结论：延续模式可以信任，战略推演不行

回到核心问题：一个从未见过你数据的模型，预测得够不够可靠？对于延续已有模式，答案是肯定的——两个版本零样本击败经典基线，一个季度后仍在预测区间内，3.0速度优势明显。但对于what-if规划决策，时间序列模型的上限取决于你数据中存在过的历史变异。正如视频作者所言，一个自信的预测可能让你付出真金白银的代价。