Chronos-2: 一个时间序列基础模型

标题：关于 Chronos-2 的时间序列基础模型的五个问题

URL 源：https://towardsdatascience.com/five-questions-about-chronos-2-the-time-series-foundation-model/

发布日期：2026-05-29T12:00:00+00:00

Markdown 内容： 我们首先在语言、视觉中看到了它们，现在也在视频和语音中看到了。到目前为止，食谱很熟悉：首先，使用足够大的数据集预训练一个大的神经网络，然后将模型应用于下游任务，无需针对每个任务进行调整。

对于许多工业应用来说，时间序列是一个关键的模态。我们经常需要使用不同种类的记录数据进行预测、异常检测和分类。当前的做法通常是对手头的具体问题建立专用模型。这可以工作，但会涉及大量的“重复造轮子”，如果当前问题的数据集较小，可能会 deliver 次优的性能。

自然，我们会想问：我们是否可以将同样的食谱应用到这里，即预训练一个大的时间序列基础模型，并将其用于任何下游任务，直接使用？

这就是时间序列基础模型（TSFM）背后的想法。

事实上，已经有很多工作走下了这条道路，我们现在看到了许多这样的模型：例如 Google 的 TimesFM、Salesforce 的 MOIRAI、Lag-Llama、TimeGPT，以及 AWS 的 Chronos 系列。

在这篇文章中，我们 examines Chronos-2 [1]，这是 Chronos 系列在 2025 年 10 月发布的新模型。我们将探讨在第一次遇到这个模型时可能会问的五个问题：

1. 时间序列基础模型是什么，它如何改变分析工作流程？
2. 为什么基础模型在时间序列上会起作用？
3. Chronos-2 具体是什么？
4. 我们实际上可以用 Chronos-2 做什么新事情？
5. 无监督学习什么时候会不够？

对于问题 4，我们将通过一个案例研究，使用一个合成的建筑电力需求数据集。

• * *

1. 时间序列基础模型是什么，它如何改变分析工作流程？

如其名称所示，TSFM 是在大量多样化的时间序列上预训练的单个神经网络。它的承诺与文本的 LLM 相同，即每次出现新的预测问题时，你不需要训练一个全新的模型，而是加载一个预训练模型并请求它进行预测。

这是一个很大的工作流程转变。

假设我们想对建筑物进行周前的能源需求预测。如果按照传统的工作流程，我们将从准备数据开始，然后选择预测模型，考虑 ARIMA/梯度提升树/LSTM、TCN、N-BEATS 等，然后将项目大部分时间用于训练、超参数调整和验证。输出是一个（希望）解决这个问题的数据集模型。

六个月后，一个新的预测任务 arrives，循环几乎从头开始。

现在使用 TSFM，上述大部分内容被压缩成一个单一的推理调用。工作流程现在变为：取历史序列（如果可用，也可以是相关的协变量，我们稍后会讨论），输入预训练的 TSFM，设置所需的预测范围，然后运行 TSFM 推理并返回预测。

另一个好处是，你不仅会得到一个点预测，通常还会得到 预测分位数，以量化不确定性。

那么这暗示了什么呢？

首先，这意味着尝试预测的成本降低了很多。如果有效，很好。如果无效，你只需花费十分钟就学到了一些有用的东西。

然后，冷启动不再是大问题。 过去，你可能因为“我们还没有足够的数据”而停止项目。使用预训练模型，那“少量数据”可能已经足以提供有意义的结果。模型已经看到了很多需求/流量/传感器类的模式。它带来了你的小数据集无法完全代表的先验知识。

最后，谁可以做这件事也发生了变化。 当然，TSFM 并没有使任何这些知识过时，但它意味着，具有一些 Python 知识的领域专家可以 credibly 获得预测，而不需要多年的 ML 背景。

当然，这一切都不是免费的。你

经验上，我们有具体的数字来支持这一观点：Chronos-2 目前在多个基准测试中零样本准确度方面处于领先地位。此外，最近的研究表明，Chronos-2 实际上在长周期内超越了经典统计基线和专门设计的深度学习架构，且无需任务特定调整 [2]。

当然，这并不意味着它总是有效。某些领域与预训练混合中的内容完全不同。我们将在问题 5 中讨论这一点。但有一个需要记住的是：TSFM 零样本现在是需要超越的基线，而不是相反。

• * *

3. Chronos-2 究竟是什么？

在本节中，我们将简要讨论 Chronos-2 的重要方面：推理时如何使用、如何构建、训练了什么以及一些实际规格。更多详细的技术讨论，请参阅原论文 [1]。

3.1 它在推理时如何使用？

实践者通常最关心如何实际使用模型。所以让我们先从这一点开始。

Chronos-2 提供了多种推理时的使用模式。好消息是：你不需要为不同的推理任务选择不同的配置。相反，你通过组织输入来让模型知道该做什么。

关键机制是“组 ID”。

在 Chronos-2 框架中，“组”是一个用于表示相关性的概念。输入给 Chronos-2 的每个时间序列都应该属于一个“组”，由一个 ID 标识。根据你在推理时如何分配这些 ID，你可以有以下四种模式：

• 单变量预测：当你想预测单个目标时。每个序列分配一个独立的组 ID，Chronos-2 将独立处理每个序列。
• 多变量预测：当你想同时预测多个目标，因为它们可能一起移动或你希望它们的预测相互告知。要实现这一点，你需要给所有相关序列分配一个共享的组 ID。
• 协变量信息预测：当你有额外的时间序列影响你的目标。这些额外的序列通常称为协变量，它们在过去的值是已知的，通常在未来的值也是已知的。要进行协变量信息预测，你需要将目标及其协变量分配到相同的组 ID，将目标标识为要预测的序列，其他提供为已知上下文。
• 交叉学习：当你有许多相关的时间序列，并希望一个序列的预测能从其他序列中的模式中受益。这种场景与协变量信息预测不同，因为组中的每个序列本身都是一个目标。它们是互为补充的，不是像协变量那样的辅助输入。此外，这种场景在语义上也不同于多变量预测。在多变量预测中，组中的序列通常是同一问题的不同目标维度（例如，不同的负载成分）。在交叉学习中，分组的序列是同级的（不同建筑的总负载）。然而，底层机制是相同的：所有相关序列分配相同的组 ID，使组注意力允许信息在序列之间流动。

所以，同一个模型，同样的配置。唯一改变的是输入如何组织。

图 1. 组 ID 如何定义 Chronos-2 的预测模式：单变量、多变量、协变量信息和交叉学习。（图由作者提供）

3.2 它是如何构建的？

Chronos-2 是一个只有 1.2 亿参数的无编码器 Transformer，按照今天的 LLM 标准来看，这相当小。这里突出的几个设计选择值得强调：

_1. Chronos-2 使用连续的补丁嵌入，而不是离散的词汇标记._

如果你了解过最初的 Chronos，你可能会记得 Chronos 通过首先缩放时间序列值，然后将它们量化到一个 bin 中来编码时间序列。这些 bin 自然地被视为“标记”。

然而，Chronos-2 放弃了这种方法。

它通过将连续的观测值分组成一个“补丁”并直接嵌入为一个连续向量来工作。如果你熟悉视觉变换器（ViT），你会立即看到相似之处。通过这样做，模型可以处理每个序列的项目更少，从而推理速度更快，并且没有量化引入的精度损失。

_2. 在编码器内部，Chronos-2 有两种注意力机制，并在每一层交替使用它们._

Chronos-2 具有时间注意力和组注意力机制。

对于时间注意力，顾名思义，其目的是让每个序列关注自己的过去，从而捕捉时间结构。

对于组注意力，它在序列之间进行。具体来说，意味着在每个时间位置，所有共享组 ID 的序列可以相互关注。

如果将输入视为一个矩阵，其中行是时间序列，列是时间，那么时间注意力发生在单个行内，而组注意力发生在单个列内。

两种注意力机制在每一层交替出现。结果是，信息最终在每个序列内部和组内流动。

_3. 对于输出，Chronos-2 使用直接分位数回归头部，而不是自回归标记生成._

在 Chronos-2 中，预测不是自回归进行的。相反，它是一个回归头部，一次输出所有 21 个分位数水平的预测，覆盖整个预测范围。

综合这些选择，使 Chronos-2 既快又具有概率性。

3.3 它是训练了什么？

对于时间序列基础模型，训练数据是关键成分。

由于现实世界的语料库通常非常稀缺，Chronos-2强烈依赖大量合成数据。它们分为两个轨道：

对于单变量预测，合成序列由三个生成器生成：高斯过程曲线（KernelSynth，继承自Chronos-1）、趋势/季节性/不规则性的随机组合（TSI）以及从随机时序因果图中采样的序列（TCM）。

对于多变量（及协变量驱动）设置，所有训练数据都是合成的。Chronos-2团队开发了一种名为“多变量器”的工具，它从上述生成器中获取多个单变量序列，并在它们之间施加依赖关系，如同时相关性或时间偏移相关性（领先-滞后，协整）。

事实上，论文中最重要的发现是合成数据几乎足够：只在合成数据上训练的变体比最终模型仅略微逊色。

3.4 实用规格

最后，如果你想要使用这个模型，有以下几个实用规格：

• 其最大上下文长度为8192步。
• 其最大预测范围为1024步（超过每天的数据或每周的小时数据）。
• 其许可证为Apache-2.0。
• 支持CPU和GPU推理。

这就是Concept上的Chronos-2。

• * *

4. 我们可以用Chronos-2做什么新事情？

在本节中，我们将动手做一些实际的预测。

这里，我们考虑一个合成的建筑电力需求预测小案例。具体来说，我们希望进行一周的小时级电力需求预测。对于大多数建筑，我们有45天的最近记录数据。对于一个新上线的建筑，只有几天的数据可用。这使我们能够测试冷启动设置。

对于这个案例研究，我们使用物理模拟数据。主要目标是总需求，即基础负荷、插销负荷、照明负荷和 HVAC 负荷之和。物理上，插销和照明负荷遵循工作日的占用模式，而 HVAC 负荷响应于户外温度和建筑的热动力学特性。有关详细的数据模拟和生成，请参阅文末我附上的笔记本。

图2. 所有建筑的总负荷时间序列。所有建筑都有45天的历史记录， except建筑06只有3天的记录。（作者供图）

4.1 设置Chronos-2模型

在工具方面，我们将通过chronos-forecasting Python包消费Chronos-2模型。我们需要PyTorch、Pandas以及通常的科学Python栈：

pip install chronos-forecasting pandas numpy matplotlib 模型权重托管在Hugging Face上，路径为amazon/chronos-2。你可以通过以下代码实例化管道：

from chronos import Chronos2Pipeline
pipeline = Chronos2Pipeline.from_pretrained("amazon/chronos-2", device_map="cuda")  # 或 device_map="cpu"

第一次from_pretrained调用会将权重下载到你的本地Hugging Face缓存（~/.cache/huggingface/），后续调用则从磁盘加载。模型占用约478 MB的磁盘空间。

Chronos-2可以运行在CPU上，但通常更喜欢GPU推理。

我使用的是带有NVIDIA RTX 2000 Ada（8GB VRAM）的个人笔记本电脑。对于本笔记本的工作负载（小时级数据，45天的上下文，168小时的预测范围，8座建筑），单变量预测（8个序列）耗时约0.07秒，多变量预测（8座建筑×4个目标=32个序列）耗时约0.22秒，协变量驱动的预测耗时约0.27秒。推理过程中，GPU内存峰值保持在1GB以下。生产环境在不同规模（例如，更多序列、更长的上下文长度/预测范围等）的工作负载将完全不同。

4.2 单变量预测

_Chronos-2能否零-shot预测建筑需求？_

我们首先尝试的最简单设置是：我们将每座建筑的最近需求历史数据交给Chronos-2，并要求进行一周的预测。仅此而已，没有花哨的技巧。

我们首先生成合成数据：

full_df = make_dataset() 数据看起来如下：

building           timestamp  ...  solar_irradiance  is_weekend
0      Building 01 2025-03-01 00:00:00  ...               0.0           1
1      Building 01 2025-03-01 01:00:00  ...               0.0           1
2      Building 01 2025-03-01 02:00:00  ...               0.0           1
3      Building 01 2025-03-01 03:00:00  ...               0.0           1
4      Building 01 2025-03-01 04:00:00  ...               0.0           1
...            ...                 ...  ...               ...         ...
32635  Building 08 2025-08-17 19:00:00  ...               0.0           1
32636  Building 08 2025-08-17 20:00:00  ...               0.0           1
32637  Building 08 2025-08-17 21:00:00  ...               0.0           1
32638  Building 08 2025-08-17 22:00:00  ...               0.0           1
32639  Building 08 2025-08-17 23:00:00  ...               0.0           1

[32640 rows x 11 columns]

该数据集包含以下列：

['building', 'timestamp', 'total_load_kw', 'hvac_load_kw', 'plug_load_kw',
 'lighting_load_kw', 'indoor_temp_c', 'outdoor_temp_c', 'occupancy',
 'solar_irradiance', 'is_weekend']

building列是组ID列；total_load_kw是目标列，是我们要预测的。

然后，我们可以准备历史上下文并使用predict_df API进行预测：

history_df = full_df[
    (full_df["timestamp"] >= context_start_date)
    & (full_df["timestamp"] < cutoff_date)
].copy()

context_univariate = history_df[["building", "timestamp", "total_load_kw"]]

pred_univariate = pipeline.predict_df(
    context_univariate,
    prediction_length=168,            # 一周的小时级预测
    quantile_levels=[0.025, 0.5, 0.975],   # 95%置信区间
    id_column="建筑",
    timestamp_column="时间戳",
    target="总负荷_kw",
)

以下是pred_univariate的样例：

建筑           时间戳  ...         0.5       0.975
0     建筑 01 2025-07-14 00:00:00  ...  175.027161  194.386108
1     建筑 01 2025-07-14 01:00:00  ...  177.673050  198.921997
2     建筑 01 2025-07-14 02:00:00  ...  175.633270  199.574677
3     建筑 01 2025-07-14 03:00:00  ...  167.960052  192.789505
4     建筑 01 2025-07-14 04:00:00  ...  154.674759  178.479599
...           ...                 ...  ...         ...         ...
1339  建筑 08 2025-07-20 19:00:00  ...  103.391228  164.987076
1340  建筑 08 2025-07-20 20:00:00  ...  116.543739  185.808151
1341  建筑 08 2025-07-20 21:00:00  ...  135.177704  202.919937
1342  建筑 08 2025-07-20 22:00:00  ...  150.139679  216.866089
1343  建筑 08 2025-07-20 23:00:00  ...  160.572784  219.451172

[1344行 x 7列]

包含以下列：

['建筑', '时间戳', '目标名称', '预测', '0.025', '0.5', '0.975'] 中位数预测存储在预测中，请求的分位数列（0.025, 0.975）分别对应每个（建筑，小时）的0.025和0.975。

为可视化结果，我们以建筑03为例：

图3. 建筑03的单变量预测。（作者供图）

我们可以看到，在没有微调的情况下，预测值很好地捕捉到了日常占用周期和工作日/周末的节奏，仅凭45天的上下文窗口。图中还显示了95%的置信区间，我们发现它们大部分覆盖了真实值。

注意，我们刚才做的实际上是所有八个建筑的批量预测。在这八个建筑中，零-shot Chronos-2产生了加权绝对百分比误差（WAPE）8.4%。这在特定数据集上肯定不是最好的性能，但投入很少努力的情况下是可信的。

4.3 多变量预测

_Chronos-2可以同时预测多个目标吗？_

接下来，我们使用Chronos-2来预测需求的各个组成部分，即 HVAC、插座和照明。在当前设置中，这些组成部分共享潜在的驱动因素，并且它们是相关的。一个模型如果将它们作为系统来处理，可以利用这些相关性来提供更准确的预测。

代码与单变量版本几乎相同，只是目标参数从字符串变为列表。此外，每个建筑的四个目标共享一个组ID，因此模型可以在每个时间位置 attends 到它们。

目标列 = ["总负荷_kw", "空调负荷_kw", "插座负荷_kw", "照明负荷_kw"]
context_multivariate = history_df[["建筑", "时间戳"] + 目标列]

pred_multivariate = pipeline.predict_df(
    context_multivariate,
    prediction_length=168,
    quantile_levels=[0.025, 0.5, 0.975],
    id_column="建筑",
    timestamp_column="时间戳",
    target=目标列,           # 现在是一个列表
)

生成的pred_multivariate如下：

建筑           时间戳  ...         0.5       0.975
0     建筑 01 2025-07-14 00:00:00  ...  170.219849  185.517609
1     建筑 01 2025-07-14 01:00:00  ...  175.033524  191.951599
2     建筑 01 2025-07-14 02:00:00  ...  175.106644  193.513306
3     建筑 01 2025-07-14 03:00:00  ...  169.450287  189.806625
4     建筑 01 2025-07-14 04:00:00  ...  159.008575  177.918198
...           ...                 ...  ...         ...         ...
5371  建筑 08 2025-07-20 19:00:00  ...   19.697739   24.007296
5372  建筑 08 2025-07-20 20:00:00  ...   19.775898   23.811647
5373  建筑 08 2

从实际应用的角度来看，拥有一个单一的 `predict_df` 调用，可以返回整个负荷分解的预测结果，并且处理方式一致，这非常有用。这在许多下游操作中非常有用，因为操作员不仅知道需求量，还知道需求来自哪里。这可以指导制定有效的 HVAC 调度、照明控制和峰谷削峰策略。

### 4.4 使用已知未来协变量的预测

> _ Chronos-2 能不能使用已知的未来天气和操作时间表？_

许多现实世界预测问题都带有我们已经知道的未来信息。对于我们的建筑需求问题，我们已经知道未来的天气和操作时间表。因此，我们应该将这些信息提供给 Chronos-2 模型，以使其做出更准确的预测。

这是 Chronos-2 的协变量信息模式，如第 3.1 节所述。这里，目标和协变量共享相同的组 ID，但只有目标被预测，协变量需要为历史窗口和预测范围提供值，以便模型学习它们与需求的关系，并根据已知的未来值进行条件预测。

![Image 5](https://contributor.insightmediagroup.io/wp-content/uploads/2026/05/03_known_future_covariates-1024x588.png)

图 5. 已知协变量包括户外温度、占用时间表和太阳辐射。（图由作者提供）

上图显示了我们为建筑 03 条件预测的已知未来信号（即户外温度、占用时间表和太阳辐射）。此外，`is_weekend` 也作为分类协变量包含在内。

在实际部署中，这些信息可能来自天气服务和建筑管理系统。在这里，我们使用与生成需求历史相同模拟器来生成这些信息。

代码需要两个改变：历史上下文现在包括协变量列（以及目标），`future_df` 参数保存预测范围的协变量值。

future_truth_df = full_df[ (full_df["timestamp"] >= cutoff_date) & (full_df["timestamp"] < cutoff_date + pd.Timedelta(hours=168)) ].copy() future_covariates_df = future_truth_df[ ["building", "timestamp", "outdoor_temp_c", "occupancy", "solar_irradiance", "is_weekend"] ].copy()

known_future_columns = ["outdoor_temp_c", "occupancy", "solar_irradiance", "is_weekend"] context_with_covariates = history_df[["building", "timestamp", "total_load_kw"] + known_future_columns]

`context_with_covariates` 的一个具体行：

building timestamp total_load_kw outdoor_temp_c occupancy solar_irradiance is_weekend Building 01 2025-05-30 190.671989 30.232122 0.000553 0.0 0

`future_covariates_df` 的一个具体行：

building timestamp outdoor_temp_c occupancy solar_irradiance is_weekend Building 01 2025-07-14 30.669441 0.000553 0.0 0

注意我们向 API 提供了两个数据框：

pred_with_covariates = pipeline.predict_df( context_with_covariates, future_df=future_covariates_df, # 预测范围的协变量值 prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="building", timestamp_column="timestamp", target="total_load_kw", # 仍然是单个字符串 —— 单个目标 )

`pred_with_covariates` 的前几行：

building timestamp target_name predictions 0.025 0.5 0.975 Building 01 2025-07-14 00:00:00 total_load_kw 169.025482 156.235291 169.025482 183.735748 Building 01 2025-07-14 01:00:00 total_load_kw 174.691132 161.001785 174.691132 190.913406 Building 01 2025-07-14 02:00:00 total_load_kw 174.087845 158.777023 174.087845 191.526764 Building 01 2025-07-14 03:00:00 total_load_kw 170.675781 155.457169 170.675781 188.504807 Building 01 2025-07-14 04:00:00 total_load_kw 160.536011 145.712753 160.536011 177.670593 Building 01 2025-07-14 05:00:00 total_load_kw 154.637436 140.687515 154.637436 170.052383 Building 01 2025-07-14 06:00:00 total_load_kw 155.766968 141.554367 155.766968 170.922150 Building 01 2025-07-14 07:00:00 total_load_kw 167.152252 152.965271 167.152252 182.419205

下图显示了建筑 03 的新预测结果：

![Image 6](https://contributor.insightmediagroup.io/wp-content/uploads/2026/05/03_known_future_covariate_forecast-1024x364.png)

图 6. 建筑 03 预测：使用 vs 不使用协变量。（图由作者提供）

我们可以看到，当 Chronos-2 模型可以访问有用协变量时，预测准确性明显提高。在所有八个建筑中，WAPE 从 8.4% 降低到 **4.2%**。

实际 takeaway 是：当可靠的未来信息可用时，将其提供给模型。

### 4.5 交叉学习

> _ 新-metered 建筑能从相关建筑中学习吗？_

我们最后研究的场景是 TSFM 最有可能处理的情况：**冷启动**。

想象一下，建筑 06 刚刚连接到监测平台，因此我们只有三天的-metering 历史数据。通常情况下，三天的数据不足以拟合一个合理的建筑特定模型。但是现在我们有了一个 TSFM，一个自然的问题是：其他七个建筑，每个建筑有 45 天的历史数据，能帮助预测建筑 06 吗？

这是 Chronos-2 的交叉学习模式，我们在第 3.1 节中讨论过。实现方面，所有八个建筑应共享一个组 ID。模型不需要被告知建筑之间是相关的；它自然会通过组注意力在序列之间 pickup 可用模式。此外，在本研究中，我们故意放弃未来协变量，所以没有未来的天气或时间表被传递。这样，我们就能知道任何改进都必须来自同龄历史数据。

short_building = "建筑06" short_history_start = cutoff_date - pd.Timedelta(days=3) context_univariate = history_df[["建筑", "时间戳", "总千瓦时"]].copy()

cold_context = pd.concat( [ context_univariate[context_univariate["建筑"] != short_building], context_univariate[ (context_univariate["建筑"] == short_building) & (context_univariate["时间戳"] >= short_history_start) ], ], ignore_index=True, ).sort_values(["建筑", "时间戳"])

cold_context_new_only = cold_context[cold_context["建筑"].eq(short_building)].copy()

以下是 `cold_context` 的前几行：

建筑 时间戳 总千瓦时 建筑01 2025-05-30 00:00:00 190.671989 建筑01 2025-05-30 01:00:00 181.611690 建筑01 2025-05-30 02:00:00 177.875806 建筑01 2025-05-30 03:00:00 166.297421 建筑01 2025-05-30 04:00:00 154.846159 建筑01 2025-05-30 05:00:00 151.078626 建筑01 2025-05-30 06:00:00 157.557114 建筑01 2025-05-30 07:00:00 155.563899

以下是各个建筑的数量：

建筑 建筑01 1080 建筑02 1080 建筑03 1080 建筑04 1080 建筑05 1080 建筑06 72 建筑07 1080 建筑08 1080

以下是 `cold_context_new_only` 的前几行：

建筑 时间戳 总千瓦时 建筑06 2025-07-11 00:00:00 101.528455 建筑06 2025-07-11 01:00:00 117.270784 建筑06 2025-07-11 02:00:00 111.178600 建筑06 2025-07-11 03:00:00 110.586007 建筑06 2025-07-11 04:00:00 98.715046 建筑06 2025-07-11 05:00:00 100.550960 建筑06 2025-07-11 06:00:00 114.863499 建筑06 2025-07-11 07:00:00 125.766400

我们进行了以下 A/B 测试：

隔离：仅建筑06的3天历史

pred_isolated = pipeline.predict_df( cold_context_new_only, prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="建筑", timestamp_column="时间戳", target="总千瓦时", cross_learning=False, )

跨学习：建筑06的3天历史 + 7个兄弟的45天历史

pred_cross = pipeline.predict_df( cold_context, # 包含所有8个建筑 prediction_length=168, quantile_levels=[0.025, 0.5, 0.975], id_column="建筑", timestamp_column="时间戳", target="总千瓦时", cross_learning=True, # 跨组学习 )

以下是结果：

![Image 7](https://contributor.insightmediagroup.io/wp-content/uploads/2026/05/04_cross_learning_cold_start-1024x633.png)

图7. 建筑06的跨学习结果。 (作者制图)

下图显示了两个预测结果以及真实值。 "隔离预测"是 Chronos-2 仅使用3天数据作为上下文的结果。我们可以看到，它设法捕捉到了每天的周期，但错过了每周的节奏并低估了峰值。跨学习版本则有效地从其他建筑中学习到了工作日/周末的形状和峰值幅度，从而产生了更好的需求预测。在 WAPE 指标方面，它从隔离学习策略的 22.2% 降低到了 16.7%。

注意，我们这里的跨学习并不是模型偷看了其他建筑的未来，因为只有历史数据在模型的上下文中。模型所做的是在上下文中学习：它看到了组合中的七个建筑，然后交叉检查建筑06这三天显示的模式，并最终 accordingly 投影。

* * *

## 5. 零-shot 在哪里不再是足够的？

在看到前面案例研究中 Chronos 的新功能之前，我们应该始终记住以下几点：**零-shot 是一个很好的默认选项；它并不是通用的答案。**

那么，零-shot 在哪里不再是足够的？我认为以下四个信号是重要的：

1.   您的数据与预训练混合中的内容大不相同。例如，专业的科学信号或利基传感器类型。
2.   您有很多干净的历史数据而没有使用。 Chronos-2 不会关注超过上下文窗口的历史数据。如果这种历史数据存在并且包含 Chronos-2 没有看到的模式，您可能需要微调来明确编码它。
3.   您看到了模型不断重复的系统性错误。对于这类问题，没有多少上下文工程可以解决。您需要针对问题进行特定的适应。
4.   您需要的行为零-shot 目标不优化。如果您的下游成本是不对称的，例如，需求低估的代价是需求高估的十倍，那么使用特定损失函数进行微调可能是解决问题的方法。

这就是第二部分的开始！在下一篇中，我们将讨论如何微调 Chronos-2。

> _您可以在这里找到完整的笔记本：[https://github.com/ShuaiGuo16/chronos-2-forecasting/blob/main/01\_chronos2\_zero\_shot\_building\_demand\_demo.ipynb](https://github.com/ShuaiGuo16/chronos-2-forecasting/blob/main/01\_chronos2\_zero\_shot\_building\_demand\_demo.ipynb)_

* * *

## 参考文献

[1] [Chronos-2：从单变量到通用预测](https://arxiv.org/abs/2510.15821)，arXiv，2025。

[2] [时间序列基础模型作为 Transportation Forecasting 的强大基线：大规模基准分析](https://arxiv.org/pdf/2602.24238)，arXiv，2026。