devgo.cn如果你在数据库里做过预测，大概率用过BigQuery的AI.FORECAST函数——以前它只能对单条时间序列做预测，比如只看过去30天的销量数字，然后外推未来7天。但真实世界的预测几乎都是多变量的：你想预测明天的客流量，不仅要看历史客流，还得分清是周末还是节假日、天气好不好、有没有促销活动。这些因素互相纠缠，只靠单序列的历史数据很难捕捉。Google Research最近在BigQuery发布的最新基础模型TimesFM 3.0，就是为了解决这个痛点——它支持原生多变量时间序列预测，而且你仍然只需要写SQL。这可能是把最前沿的时序预测能力嵌进你现有数据管道的最短路径。
TimesFM 3.0是个3.3亿参数的模型，在三个主流公开榜单GIFT-Eval、FEV-Bench和TIME上都排第一，目前是所有时序基础模型里零样本准确率最高的。它可以直接通过`AI.FORECAST`调用，用`model => 'TimesFM 3.0'`指定，现有单变量预测和异常检测流程也能无痛升级，因为它是向后兼容的。但最值得关注的是新增的多变量能力，下面用一个例子说明它是怎么在SQL里工作的。
文章用纽约Citi Bike公共数据集演示：预测每天的上班通勤骑行量（subscriber_trips）和休闲骑行量（casual_trips），预测未来7天。BigQuery要求一个单表输入，分为两种行：一种是历史观测行（从2016年1月1日到预测截止日6月1日），完全填充所有目标列、历史协变量和已知未来协变量；另一种是未来预测行（6月1日到6月7日），只填充已知的未来协变量，目标列和历史协变量设为NULL。这种输入组织方式本身就很巧妙，把复杂的多序列建模问题压缩成一张表。
TimesFM 3.0支持三个维度的多变量输入。第一个是相关目标列（target_cols）：把`TARGET_COLS => ['subscriber_trips', 'casual_trips']`传进去，就能同时预测两个指标，不再需要为每个指标单独跑模型。模型会自动捕捉两者之间的关联——比如共同受天气影响，但周末通勤少而休闲多，这种交叉动态是单变量模型看不见的。第二个是历史协变量（past_covariate_cols）：有些信号只有过去才有，比如平均骑行时长（avg_duration_min）、历史人流量或突发服务中断。把这些列传进去，模型能区分临时冲击和长期趋势，而不需要知道未来的该特征值。第三个是未来协变量（future_covariate_cols）：有些外部驱动因素是预先知道的，比如周末（is_weekend）、节假日或计划中的促销活动。把`FUTURE_COVARIATE_COLS => ['is_weekend']`传进去，并且从历史窗口到预测窗口的所有行都填上，模型就能根据未来的日历事件直接调整7天预测。
输出也很结构化：对`target_cols`里每个目标列，AI.FORECAST返回一个结构，包含点预测值（value）和预测区间的上下界。这意味着你既能看到最可能的估计，也能知道不确定性的范围，这对于业务决策很有价值。另外，BigQuery的Conversational Analytics还支持自然语言交互——你可以直接说"用两个月历史数据预测6月1日到7日的每日订阅和临时骑行量，把平均骑行时长作为历史协变量，周末指示作为未来协变量"，系统自动生成并执行SQL，返回结果摘要、带预测区间的交互式图表和关键洞察。这个能力让非SQL专家也能用上多变量预测。
最让我意外的是，这整套能力完全是零样本的——不需要自己训练模型，不需要特征工程管道，不需要单独部署推理服务。数据放在哪，预测就在哪做。对于已经用BigQuery的企业，这相当于把SOTA时序预测直接内嵌进了数据仓库。以后遇到复杂的预测需求，比如供应链多商品库存联动、零售多门店销量协同、物联网多传感器状态关联，都可以用同样一套SQL模式。
当然要注意几个坑：第一，单表输入格式要求你手动构造历史行和未来行，NULL填充规则要清楚，否则模型会误解；第二，历史协变量只能用于历史上下文，你不能把未来未知的东西当未来协变量传进去；第三，虽然模型很强，但零样本预测不等于万能，如果业务场景有强烈的领域特殊性，可能还是需要微调或后续校准（文章没提微调，但根据基础模型的一般用法，可以留意）。总的来说，TimesFM 3.0把多变量时序预测的门槛又往下压了一大截，值得你在下一个预测任务里直接试试。
内容与图片版权归原作者所有 · 原文: https://cloud.google.com/blog/products/data-analytics/bigquery-timesfm-3-0-with-multivariate-time-series-forecasting/