时序预测模型失效？忽略上下文窗口是元凶

你给时序基础模型喂了一年的小时级数据，它返回的预测曲线看似合理。部署后却错过了每一个尖峰。模型没坏，数据也没问题——问题出在上下文窗口上。

时序预测与上下文窗口

静默截断：最危险的失败模式

像 Mistral 的 Timestral 这类时序基础模型，以固定上下文窗口处理输入。窗口定义了模型一次能关注的 token 数量。当序列长度超过窗口，模型会直接丢弃最旧的 token。

整个过程不报错、不警告、不记日志。预测照常运行——只是跑在数据的尾部。输出看起来依然合理，因为这类模型擅长从任何输入生成形状可信的曲线。

这不是模型的 bug，而是数据长度与模型上下文容量之间的错配。模型无法知道序列中哪部分对你最重要，只有你的代码能强制执行这个约束。

危险之处在于截断在两端都不可见：请求成功、响应可解析、曲线平滑。唯一的信号是生产指标逐渐漂移——而那时错误预测早已上线。

上下文窗口是时序基础模型（以及所有基于 Transformer 的模型）一次前向计算能够处理的最大 token 数量，由模型架构中的位置编码和注意力机制的复杂度共同决定。对于时间序列模型，每个时间步通常被编码为 1 个或多个 token，具体取决于特征维度和数值分箱策略。窗口大小是训练时固定的超参数，推理时无法扩展——输入超过窗口的部分会被直接截断，而非分块处理或报错。这解释了为什么 Timestral 等模型对超长序列“默默”只使用尾部数据：截断发生在 tokenization 之后、模型计算之前，属于框架的默认行为，而非模型本身的缺陷。理解这一点是识别静默截断风险的前提。

先度量，再建模

调用任何时序模型之前，先估算序列会消耗多少 token。多数时序模型将每个时间步编码为一个或多个 token，具体取决于特征数量和数值精度。同样行数的单变量小时序列与多变量分钟级序列，token 数量可能天差地别。

import numpy as np

def estimate_tokens(series, features_per_step=1, bytes_per_value=4):
    # 粗略估计：每个值编码后约对应 1 个 token
    total_values = series.shape[0] * features_per_step
    return int(total_values * bytes_per_value / 3)

data = np.random.randn(8760, 1)  # 一年小时级数据
print(f"预计 token 数: {estimate_tokens(data)}")

这只是估算，不是保证。不同模型和提供商的 tokenization 方案各异。把它当作数量级检查。接近上限时，查阅提供商文档确认精确规则，或发送一个小型探测序列，从响应中读取实际 token 用量。

如果估算值超过模型的上下文窗口，必须降采样或分块。这一步不能跳过。

分块还是压缩？取决于信号特性

实践中两种策略有效，选择依据是信号是否平稳——即统计特性是否随时间大致恒定。

方法	适用场景	代价
滑动窗口	信号有重复模式	丢失长期趋势
降采样	信号嘈杂或高频	丢失精细细节

对于有日周期的小时级数据，24 步滑动窗口通常能保留足够上下文。对于年度趋势，降采样到日均值能保持形状，但会掩盖日内尖峰。

选择比看起来更重要。如果你降采样了尖峰才是关键信号的序列，等于把想预测的东西平均掉了。如果你对有缓慢趋势的序列做分块，每个块从不同基线出发预测，输出在块之间会不一致。

滑动窗口保留最近 N 步，丢弃更早的数据：

def sliding_window(series, window_size):
    if len(series) <= window_size:
        return series
    return series[-window_size:]

recent = sliding_window(data, 24)
print(f"保留 {len(recent)} / {len(data)} 步")

窗口长度至少要不短于你希望模型捕捉的季节周期。 小时级数据上的 24 步窗口覆盖一天，但捕捉不到周模式。窗口要匹配周期，而不是匹配预测步长。

信号平稳性（stationarity）指时间序列的统计特性——均值、方差、自相关结构——不随时间推移而改变。平稳序列的局部模式可以代表全局，因此滑动窗口切分不会引入系统性偏差；非平稳序列（如带趋势或季节漂移的数据）在不同时间段的基线不同，分块后各块独立预测可能导致输出在拼接处跳变。实践中常用差分或去趋势来近似平稳化，再判断采用滑动窗口还是降采样。对时序基础模型而言，平稳性还影响模型能否将窗口内的模式泛化到预测步长——非平稳输入即使上下文长度足够，也可能因为分布偏移而失效。

用守卫包裹调用

生产环境永远不要直接调用时序模型。加一层包装，让截断可见：

import requests

def forecast_with_context_check(series, max_context=8192):
    token_count = estimate_tokens(series)
    if token_count > max_context:
        raise ValueError(
            f"序列需要 {token_count} tokens，模型仅接受 {max_context}。"
            "调用前请降采样或分块。"
        )
    # 实际模型调用
    return {"status": "ok", "tokens_used": token_count}

try:
    result = forecast_with_context_check(data)
except ValueError as e:
    print(f"已拦截: {e}")

max_context 应来自提供商当前文档，而非记忆。上下文限制随模型版本变化，硬编码的过期值要么拦截合法请求，要么再次悄悄允许截断。

这个守卫把静默截断变成响亮的失败。你在预发环境修复它，而不是在生产环境。异常是刻意的——基于部分数据的预测比没有预测更糟，因为它看起来可信。

上下文正确，这些坑依然存在

即使上下文长度正确，基础模型仍难应对分布偏移。如果你的训练数据止于一月，却要预测七月，模型从未见过那种状态。它会自信地插值，然后错得离谱。

上下文长度保护不了你。更长的窗口给模型更多历史，但当未来行为与过去不同时，历史帮不上忙。

始终在真实数据的最近窗口上验证：留出序列最后一段，做预测，与真实值比较，然后再信任模型对新数据的输出。不要信任一个没见过你当前条件的模型。

分布偏移（distribution shift）指模型推理时遇到的数据分布与训练时所见不同，典型形式包括协变量偏移（输入特征分布变化）和概念偏移（输入到输出的映射关系变化）。时序基础模型在大规模多领域数据上预训练，但面对特定业务场景中从未出现过的状态（如节假日效应、政策突变、极端天气），模型只能基于历史模式外推，容易产生看似合理却系统性偏离的预测。上下文窗口再长也无法弥补这一缺陷，因为历史数据本身不包含未来新状态的信息。缓解手段包括：在近期数据上做滚动回测、引入外生变量、或对模型输出做在线校准；但根本措施是建立监控机制，当预测残差分布显著变化时触发人工复核或模型更新。