别只押一个模型:Granite 集成预测的 4 模型与 2 种合并法

10 月 22 日,IBM Research 在 Hugging Face 发布 Granite Timeseries Ensemble,并给出了可直接调用的代码示例。现在值得关注,不只是因为它又提供了一种时间序列预测方法,而是因为它把“预训练模型该选哪一个”这个决策,包装成了一个可以比较、替换和扩展的集成方案。

下文将官方明确说明的内容称为“官方做法”;根据其机制和公开资料推导出的适用边界,会明确标为“判断”。文中的数字与功能均来自所列来源,不把推导写成官方结论。

从单模型选择转向四模型协作

预训练时间序列模型的优势,是不必先用自己的数据完成训练;但选模型的问题仍然存在。官方以工业信号、零售需求和长周期季节性为例说明:擅长平稳工业信号的模型,未必适合噪声较大的零售需求,而最终表现还取决于数据特征和预测任务。

Granite Timeseries Ensemble 的默认配方组合了四个 Granite 模型,分别是采用分片 Transformer(把连续时间序列切成片段后交给 Transformer 处理)的 Granite PatchTST-FM-r1、采用分片 Conformer 架构的 Granite PatchTST-FM-r2、状态空间模型 Granite FlowState-r1.1,以及基于 Tiny Time Mixers 多层感知机混合器的 Granite TTM-r3。

官方将这套方案定位为“不必重新训练,也不拟合集成权重”的默认起点。四个成员分别从趋势、季节性和局部变化等角度观察数据,理论上可以减少押错单一模型的风险。不过,官方也强调,成员质量与差异性仍然重要:四个模型只是结构不同,并不自动保证集成结果优于其中最好的成员。

对照项 官方默认做法 常见但需警惕的做法
模型组织 四个互补成员统一调用 手工逐个运行再拼接结果
合并规则 等权概率池化为默认 仅比较单模型均值或单一模型
输出 中位数点预测与分位数预测 只输出一个确定值
权重拟合 默认方案不拟合权重 每换一组数据就重新训练权重
首次使用 运行时下载四个成员检查点 忽略额外下载与推理成本

这张表最重要的并不是“集成一定更好”,而是 Granite 把选择过程从一次性的单模型押注,改成了可以继续验证的工程流程。另一位 Hugging Face 作者提出的实用测试计划也建议,把等权集成当作基线,再通过分场景回测判断其稳健性和校准表现是否足以覆盖四模型运行成本。

等权合并:默认方案省掉了权重训练

官方提供了“概率集成”,中文可理解为把多个模型在概率空间中的预测放在一起,再从合并结果提取所需分位数。四个成员在这里拥有相同影响力,不根据历史预测误差学习权重,也不要求为新数据集调整权重超参数。

这种做法借鉴了预测组合中的一个常见经验:简单的等权组合有时并不输给需要估计权重的复杂方法。Granite 将这一思路从点预测延伸到概率预测。用户最终获得两类结果:prediction_outputs 是点预测,quantile_outputs 是分位数预测;默认分位数覆盖 0.1 到 0.9,其中 0.1 和 0.9 可以组成名义覆盖率为 80% 的中心预测区间。

这让集成输出比单个数值更适合业务决策。例如,库存系统可以分别使用中位数安排基准补货,再根据上下分位数设置安全库存。但“覆盖区间”也不等于“真实概率保证”:名义覆盖率描述的是区间构造方式,模型是否在你的数据上真的达到这一覆盖率,仍要通过历史回测验证。

pip install "granite-tsfm>=0.3.11"

import pandas as pd
from tsfm_public.models.ensemble.modeling_ensemble import QuantileEnsembleForecaster

df = pd.read_csv(
    "https://raw.githubusercontent.com/zhouhaoyi/ETDataset/main/ETT-small/ETTh1.csv",
    parse_dates=["date"],
)

ensemble = QuantileEnsembleForecaster.from_pretrained(
    "ibm-granite/granite-timeseries-ensemble-r1"
)

result = ensemble(
    df.tail(1024),
    timestamp_column="date",
    target_columns=["OT"],
    context_length=1024,
    prediction_length=24,
)

print(result.prediction_outputs)  # 点预测
print(result.quantile_outputs)    # 分位数预测

这段示例使用公开的 ETTh1 数据:读取最后 1024 个时间点作为上下文,预测未来 24 步。代码还揭示了一项容易被忽略的部署成本:配方文件本身不包含合并后的权重,首次运行会下载四个成员检查点,因此需要为首次启动预留额外时间和存储空间。示例数据可通过原始 CSV 文件复核。

IQR 合并:区间越窄,成员话语权越大

第二种方案是 IQR Ensemble,即四分位距集成。它根据每个成员预测区间的宽窄分配影响力:区间越窄,获得的权重越高。官方实现会根据最接近第 25 和第 75 百分位的可用分位数,近似估计成员的四分位距。

与固定等权相比,这种方法的权重会随着样本、目标变量和预测步长变化;但它同样不依据历史预测误差拟合权重。这里的四分位距可以理解为预测分布中间一半数据的宽度:区间窄,代表该成员给出的中心区间更集中;区间宽,则代表它对结果的描述更分散。

按官方机制推导,IQR 合并实际是在奖励“更自信”的成员。如果某个成员因为过度自信而给出过窄区间,它在合并结果中的影响力可能反而更大。因此,IQR 不应仅凭区间更漂亮就认定为更准确,必须和等权方案同时比较点预测误差及区间覆盖率。这是根据合并规则推导出的风险判断,不是官方发布的评测结论。

两个方案怎么选:先比较稳定性,再看区间

对普通用户而言,最实用的选择方式不是先争论哪一种“更高级”,而是建立一组容易复算的基线。

验证问题 等权概率集成 IQR 集成 应观察的结果
点预测是否更稳 检查不同时间段的误差 检查误差是否受窄区间成员主导 平均误差之外,还要看最差时段
区间是否可信 检查实际覆盖率 单独检查窄区间是否过度自信 覆盖率与区间宽度应一起看
运行成本 四个成员都要参与 四个成员都要参与 延迟、显存与首次下载
换数据后是否稳定 不需重新拟合权重 不需重新拟合权重 不应因换数据集而重调权重
成员是否值得保留 查看成员分歧 查看窄区间成员的影响 删除重复成员是否省成本且不降质

官方在发布文章中建议先采用概率集成,再比较自适应的 IQR 方案,并允许通过同一接口加入兼容预测器。按这一方向推导,合理的第一轮测试应至少保留三个维度:点预测误差、预测区间覆盖率、运行成本。只看平均误差,可能掩盖集成在少数关键时段明显退化;只看区间宽度,又可能奖励过度自信的模型。

另一个边界是数据粒度。代码把上下文长度和预测长度直接交给接口,但官方没有声称固定为 1024 和 24 的组合适合所有场景。短上下文可能截断季节信息,长上下文则可能增加计算量;小时级数据与日级数据也不能直接共用同一套长度设置。因此,这两个数字更适合作为可运行的复现起点,而不是通用参数建议。

集成方案适合谁,又有哪些代价

这套方案最适合三类场景:第一,已经拥有历史数据,却不想为每个预测任务重新训练模型;第二,业务需要分位数或预测区间,而不只是一个点值;第三,希望用统一接口比较不同架构,并通过回测决定是否值得保留某个成员。

反过来,如果系统已经通过滚动训练验证了某个专用模型,而且该模型在延迟、成本和误差上都明显占优,切换到四模型集成未必划算。集体会把选择风险变成运行成本:成员需要被下载、执行并合并,成员之间不一致时,收益也可能被额外复杂度抵消。

这里还有一个容易误读的许可问题。官方称,集成配方和默认 Granite 成员采用宽松许可,但“模型权重可宽松使用”不代表数据、部署环境和商业流程的全部风险都消失。企业仍需分别检查依赖包、数据来源、输出责任和现有平台的资源限制。

最终可以把 Granite Timeseries Ensemble 理解为一个省去权重训练的起点,而不是无需验证的终点。先用等权方案建立基线,再检查分位数覆盖和分段回测,最后才评估 IQR 是否带来净收益。这样带走的不只是四个模型名称,而是一套从默认组合、可复算实验到上线取舍的判断路径。

参考来源

评论区

0 条评论

登录后可评论。

云间 56 阅读