最近我把大部分精力都花在多元时间序列的长期预测上。预测窗口一旦拉到几百步很多模型就开始露馅短期的拟合非常漂亮但未来几段输出的形态完全走样。这个项目叫TimePro核心是用Mamba做主干通过变量与时间双感知的hyper-state专门处理长期预测里最让人头疼的多延迟问题。先说明一下这里的“多延迟”不是指序列长而是指同一段历史里不同变量、不同时间尺度的滞后相关是叠加在一起的今天的电力负荷既受两小时前气温的影响也受昨天同一时刻的用电习惯影响还可能受上周同期的工作日模式影响。这些延迟怎么同时建模直接决定了长窗口预测是“越走越稳”还是“越走越偏”。如果你是做时序预测、想引入状态空间模型或者正在被长期预测的多延迟问题折磨这篇内容应该能帮上忙。我会把TimePro的设计动机、原理拆解、复现细节以及我踩过的坑一次讲清楚。1. 长期预测的老大难多延迟问题为什么绕不过去1.1 我理解的“多延迟问题”到底是什么时间序列里“延迟”这个概念非常基础。X_t与X_{t-k}之间存在相关性k就是延迟阶数。对于小时级数据k1可能是上一小时的影响k24是一天前的周期性影响k168是一周前的强周期影响。这些不同k值的相关结构同时存在于同一段序列里就叫多延迟。长期预测难并不是难在输出长度翻了几倍而是预测步数越远未来点需要参考的历史延迟组合越多样。第1个未来步可能主要依赖近期延迟第10个未来步可能依赖某个固定周期第100个未来步甚至要参考几个月前的趋势背景。如果模型只把全部输入压成一个固定隐变量短期延迟会天然占据优势长周期信号会被稀释到几乎看不见。我见过不少模型在96步预测上表现不错一旦切到720步后半段预测基本变成直线或者重复一段历史本质就是多延迟没有处理好。更麻烦的是多元序列里“变量间延迟”会叠加在“时间延迟”上。气温对电力负荷的影响可能是滞后1到2小时电价对用户行为的响应可能接近即时而设备维护记录的变更对负荷的影响可能是以周为单位的。变量间谁领先谁、领先多久本身就是一张不断变化的网络。所以在我的定义里多延迟问题包括两条线一条是单个变量内部的时间延迟一条是变量之间的交叉延迟。这两条线交织在一起才是长期预测真正的难点。1.2 已有方案为什么总感觉差口气Transformer类模型是目前长期预测的主流基线。注意力机制确实能捕捉长距离依赖但它是把所有时间步之间的两两关系都视作平等候选最后注意力权重往往被近期相似片段主导。你让模型同时关注“两小时前”和“上周同期”它通常会更偏爱前者因为短期模式在数值上更接近。另一个现实问题是O(L^2)复杂度回看窗口一大显存和训练时间都扛不住。PatchTST这类方法通过切patch缓解了一部分效率和局部性问题但patch本身是单尺度的它没真正回答“不同延迟尺度如何共存”。RNN/LSTM这类递归模型的思路是把依赖压缩进隐状态。单变量序列上门控机制可以记住一定长度的历史但多变量、多尺度延迟叠加时单个隐状态很快变成一锅粥。梯度传播也会随延迟长度急剧衰减虽然LSTM用门控缓解了一部分但面对几百上千步的预测任务状态容量依然是硬瓶颈。直接多步预测、递归多步预测这些解码策略也解决不了根本问题误差累积掩盖了模型对延迟结构的学习能力。Mamba类时序模型流行起来后很多人直接把Mamba当作更强的RNN或者更快的Transformer来用输入序列过一遍SSM就出结果。这类做法在标准基准上能取得不错分数但很少主动处理一个问题Mamba的状态到底应该记住什么。TimePro的核心改变是把这个问题放到了台面上用变量与时间双感知机制来决定状态的内容和演化方式。2. TimePro的设计思路与核心原理双感知状态从哪来2.1 变量感知先分清“谁在影响谁”TimePro的第一路输入叫做变量感知编码。它的任务不是压缩时间信息而是把变量维度上的交互结构显式提取出来。做法上我给每个变量配一个可学习的身份嵌入相当于给序列的每一列一个名字。电力负荷、气温、电价各有各的嵌入模型不会再因为数值相似就把它们搞混。拿到身份嵌入后再对原始输入做一次独立的线性投影得到每个变量的时间特征。然后把这些特征沿着变量维度做一次轻量交互可以用一个小的MLP也可以用类似多头注意力的机制计算变量之间的影响系数。这一步的产物是一个变量关系权重它告诉后续模块当前时刻的气温对电力负荷的影响权重是0.3而电价对负荷的影响可能是0.1。这个权重不是固定的它会随输入片段动态变化所以本质上是一种变量级的动态路由。为什么不用传统的协方差矩阵或者全局注意力来做这件事因为那些方法把所有变量一视同仁交互复杂度和变量数成平方级增长。TimePro里我做了一个降维处理先通过变量身份嵌入把每个变量的信息聚合成低维描述再做交互计算变量数再多也不会让计算量爆炸。实验里我的感受是这一步对多元数据集帮助非常明显尤其是当不同变量取值范围差异很大的时候单独做线性投影并按变量归一化训练要稳定得多。2.2 时间感知把不同尺度的延迟拆开看时间感知这一路解决的是“同一变量内部不同延迟尺度如何共存”的问题。我没有用单一的token化方式而是用多尺度卷积把原始序列拆成几路。实践中我用三路卷积卷积核大小分别对应短延迟、中延迟、长延迟。举例来说小时级电力数据里短延迟对应1到6小时卷积核设为3中延迟对应24小时附近的日周期卷积核可以拉到13到27长延迟对应周周期或者更长的趋势卷积核至少要覆盖168步的语义范围实践中通过多层小卷积或者池化叠出来而不是真的放一个kernel size168的卷积否则参数太多。每路卷积输出的长度要保持一致内部做膨胀卷积或者下采样再上采样都行。之后把三路特征通过门控融合成一路时间感知特征。这一步的巧妙之处在于不同尺度的特征在融合前已经各自独立激活了对应的延迟模式。模型收到一个输入片段时短期分支负责“最近几小时发生了什么”长期分支负责“上周这两天是不是也有类似的负荷曲线”两者不会再抢同一个特征通道。同时我还会加入时间戳嵌入比如小时、星期、月份这些周期性信息。很多人会忽略这一点但星期几这个特征对长期预测的价值极大如果回看窗口是168步模型必须知道当前输入覆盖的是一个完整星期否则很难把第169步的预测对齐到正确的星期模式上。时间感知和变量感知两路输出最终拼接或者相加形成统一的序列特征这一切都发生在Mamba的SSM进入之前。2.3 hyper-state到底是什么一个状态装下两套信息Mamba的核心是状态空间模型每个时间步都有一个内部状态h_t负责在序列间传递信息。普通Mamba的h_t由一组固定维度的向量组成状态更新规则是A h_{t-1} B x_t。听起来很通用但在长期预测里这种固定规则有两个问题第一状态不知道当前数据里有几个关键变量、哪个变量在主导第二状态不知道当前输入里哪个时间尺度更重要。TimePro提出的hyper-state就是为了解决这两个问题而存在的。hyper-state不是某个中间层的普通隐藏状态而是“关于状态本身的状态”它由变量感知和时间感知两路输出联合生成负责给出SSM的初始状态并且动态调制后续状态转移矩阵。我的实现里hyper-state会生成三组调制量分别作用于Mamba的A矩阵、B矩阵和C矩阵。这样一来模型在不同的时间片段下可以有不同的状态演化规则。同样一个SSM块在气温快速波动时会增强对近期延迟的敏感度在进入平稳周期时会转向对长期周期模式的记忆。这个思想其实和hypernetwork一脉相承。普通网络是一次前向算出一组权重hyper-state相当于根据输入数据即时算出一组“状态规则的调整量”。打个比方普通SSM是一辆只能按固定路线开的车它知道发动机转速和当前挡位但不知道目的地hyper-state是一个实时导航员它结合了当前路况变量感知和剩余路程时间感知不断告诉你什么时候该踩刹车、什么时候该深踩油门。Mamba的A、B、C矩阵就是那个油门刹车。2.4 为什么偏偏选Mamba当骨干不用Transformer不是因为Transformer不行而是因为长期预测任务里回看窗口和输出窗口都越来越长注意力机制的计算量让人很难受。Mamba基于状态空间模型计算复杂度跟序列长度呈线性关系这一点在长窗口训练里优势非常明显。同时Mamba的选择性扫描机制允许状态根据输入动态决定“记住什么、忽略什么”这一点和长期预测的需求天然契合。但直接把Mamba搬过来并不够。Mamba的选择机制通常只受当前输入x_t的影响它不会主动知道当前时刻有哪些变量在交互、当前延迟尺度是什么。TimePro里的hyper-state相当于给Mamba装了一个全局视角的控制器把变量感知和时间感知的决策信息提前注入到状态转移规则里。所以用Mamba当骨干既保留了线性复杂度和长程记忆能力又弥补了它对多延迟结构建模不足的问题。3. 从想法到实验TimePro复现的关键细节3.1 核心网络结构怎么搭一份可跑的伪代码下面是一段简化版的TimePro结构示意。真实实现里还要考虑维度对齐、归一化、残差连接这些细节但这个骨架能直观展示数据流向。import torch import torch.nn as nn class TimePro(nn.Module): def __init__(self, n_vars, pred_len, d_model256, d_state64, n_layers2): super().__init__() self.var_enc VariableEncoder(n_vars, d_model) # 变量感知 self.time_enc MultiScaleTimeEncoder(d_model) # 时间感知 self.hyper_net HyperNetwork(d_model, d_state) # hyper-state生成 self.ssm_stack nn.ModuleList( [MambaSSMBlock(d_model, d_state) for _ in range(n_layers)] ) self.head nn.Linear(d_model, n_vars * pred_len) def forward(self, x): # x: (B, L, C) v self.var_enc(x) # (B, L, D) t self.time_enc(x) # (B, L, D) z v t # 双感知融合 h self.hyper_net(z) # (B, D_state) 初始状态 z z.transpose(1, 2) # (B, D, L) for block in self.ssm_stack: z, h block(z, h) # (B, D, L), (B, D_state) out z.transpose(1, 2) # (B, L, D) return self.head(out.reshape(out.size(0), -1))VariableEncoder的核心是给每个变量生成一个嵌入然后沿变量维做一次交互投影。我习惯先对每个变量做独立LayerNorm再通过一个共享的线性层把输入统一到d_model维度。变量间交互用一个简单的MLP就可以不必每次都上注意力。MultiScaleTimeEncoder则是三路卷积加时间戳嵌入融合卷积核大小根据数据采样率灵活调整。HyperNetwork比较轻量它对双感知特征做全局池化再通过两层MLP生成d_state维的初始状态以及每层SSM需要的一组调制参数。MambaSSMBlock可以直接复用开源Mamba实现也可以自己写一个简化版本。只要保留离散化后的状态更新规则并让A、B、C矩阵可以接收hyper-state调制就行。注意Mamba的原始实现里B矩阵的投影是按序列长度动态生成的TimePro里要让序列维度和变量感知特征对齐否则维度很容易对不上。3.2 训练配置与超参数我用下来的推荐值训练配置上我推荐先用经典长期预测基准跑通ETTh1、ETTh2、ETTm1、ETTm2、Electricity、Traffic、Weather。这些数据集的采样频率和变量数量差异够大能很快检验模型的多延迟建模能力。回看窗口我常用96或192预测长度看具体设置一般覆盖96、192、336、720四个档位。超参数方面有一个起始配置可以先用d_model设为256d_state设为64SSM层数保持2到4层。再往上加层数时模型容量增加明显但训练时长也会线性上升。batch size我建议在ETT这类小数据集上用64在Electricity、Traffic这些大体量数据上降到32甚至16。学习率用3e-4配合余弦退火前几个epoch做warmup。AdamW的weight_decay设1e-4到1e-3注意状态空间模型对正则化比Transformer更敏感过大的weight_decay会把A矩阵压得太小导致长期记忆丢失。损失函数用MSE和MAE的加权组合我平时MSE权重是1.0MAE权重是0.1。训练一开始直接优化MSE会让模型倾向拟合大误差样本加入MAE能稍微平衡一下中后期误差。混合精度方面要特别小心Mamba的选择性扫描在fp16下偶尔会出现数值异常我通常先在fp32下把基线跑稳再尝试bfloat16加速。3.3 评测与消融如何证明“双感知”真的有用评测长期预测模型不能只看全局MSE。我强烈建议把预测输出切成几段分别计算前段、中段、后段的误差。很多模型前段误差很低后段误差急剧升高这种信息会被全局MSE掩盖。TimePro的定位是改善长窗口预测所以后段误差才是真正的KPI。消融实验按四组做去掉变量感知、去掉时间感知、去掉hyper-state的调制部分、把SSM替换成同样层数的Transformer编码器。我跑下来的典型趋势是去掉hyper-state的调制退化最明显特别是在预测长度720的档位上去掉时间感知后周期性强的数据集ETTh、Weather性能下降明显去掉变量感知后Electricity、Traffic这类多变量数据集体验更差。从方法论上讲这三块是拧成一股绳的单拆任何一块都可能不至于崩盘但组合起来效果最好。如果想在真实数据之前更清楚地验证“多延迟建模”能力建议先做一个合成数据集生成一个包含短期AR项、一个周期项、一个变量间滞后项叠加的信号。比如X_t 0.6 * X_{t-3} 0.3 * Y_{t-8} sin(2πt/24) 噪声。这类数据延迟结构非常明确TimePro在这种测试上能明显比普通Mamba和Transformer学得更快、更稳因为你给它设计的变量感知和时间感知正好打在问题的结构上。4. 复现与调参实录我在TimePro上踩过的坑4.1 长窗口预测后段误差高多延迟没被真正学到这是我遇到过最常见的现象训练loss下降很快验证集前段MSE也正常但最后一段预测基本失真。根本原因多半不是模型能力不够而是loss函数把训练重点全压在了短延迟上。因为前段误差数值通常比后段小整体MSE最小化时会优先优化“容易的部分”。我试过两个有效手段。第一个是把预测窗口分段加权后段权重大一些比如四段输出权重按1:1:1.5:2来设这能让模型被迫把注意力放到长延迟模式上。第二个是增强时间感知分支里的长周期特征具体做法是把多尺度卷积中对应长期的分支特征通道加宽或者直接往输入里加入傅里叶特征让模型在进入SSM之前就能看到周期结构。这两个手段合在一起通常能把720步预测的后段MSE拉下来不少。还有一个细节容易被忽略数据归一化方式。多变量数据里不同变量量纲差距可以非常大如果只做全局z-score归一化很多变量实际上被压到了噪声级别。我建议先对每个变量单独归一化再输入模型。变量感知编码里的独立LayerNorm也是在处理这件事。4.2 Mamba实现的几个经典坑Mamba的官方实现依赖一些底层优化版本兼容性有时候会让人头疼。如果只是验证TimePro的思想完全可以用纯PyTorch实现一个简化版SSM块。关键是训练时千万别用Python for循环逐时间步展开要用并行扫描或者至少沿着序列维度的分段扫描否则训练速度慢到没法用反向传播的计算图和显存开销也大得离谱。维度对齐是我调试时遇到最多的地方。A矩阵的维度是d_state×d_stateB矩阵是batch×seq_len×d_in映射到d_stateC矩阵则是batch×seq_len×d_state映射回d_model。hyper-state调制A矩阵时要确保生成的调制张量能广播到A的维度上。我一开始图省事直接用线性层从d_state生成d_state×d_state的参数结果参数规模和内存一下暴涨后来改成低秩调制先生成一个小的调制向量再外积扩展效果相近但参数少很多。数值稳定性也值得单独说一下。A矩阵的初始化不能随便来太大会导致状态很快爆炸太小又会让序列记忆迅速衰减。S4里的HiPPO初始化是经过验证的或者至少把A矩阵初始值限制在负半平面让系统本身倾向于稳定。每次状态更新后加一个LayerNorm或者残差门控也能有效抑制训练中途的数值抖动。训练精度方面如果发现loss曲线时不时出现尖刺优先怀疑fp16导致的状态计算溢出换成fp32基本就稳了。4.3 超参选择中容易出现的反向直觉很多第一次用state space model的人会觉得d_state越大越好我一开始也是这么想的。但在TimePro里d_state并不是单纯代表记忆容量它更像是“并行状态通道数”。如果只是把d_state从32加到128缺少变量感知和时间感知的引导增加的通道大部分会被冗余信息占用反而出现过拟合。我的建议是先保持d_state在64左右优先把变量感知和时间感知调好再尝试增大d_state并观察最后一段预测误差如果后段没有明显改善就说明信息在进入状态之前已经被处理得不够结构化问题不在容量。多尺度卷积的窗口大小也要对着数据采样率来调。5分钟粒度的数据24小时就是288个步长周周期是2016步这种情况下kernel size27的卷积根本摸不到周期边界你得靠多层膨胀卷积把感受野堆上去。小时级数据相对简单24步日周期和168步周周期用多路卷积可以覆盖。做实验前最好先看一眼数据的自相关图看看几个显著延迟峰值在哪里再决定时间感知分支的卷积核怎么配。这个步骤很快但对最终效果的影响非常大。还有一个容易被忽略的点hyper-state调制幅度一开始不要太大。Mamba的状态转移规则在预训练前基本处于一个脆弱平衡如果hyper-state一上来就大幅改写A、B、C矩阵训练初期很容易震荡。我的做法是在调制输出上乘以一个较小的缩放系数比如0.01或者0.05然后随着训练步数慢慢放开。这个小技巧几乎立刻让训练曲线变平滑。多说一句我自己的体会。在跑通TimePro之前我先后试过把Mamba直接当作序列编码器也试过用各种注意力模块做变量交互总觉得隔着一层。最后发现关键思路是要想清楚模型的状态里到底应该放什么。多延迟问题的本质是信息结构问题而不是单纯的模型容量问题。TimePro的变量与时间双感知hyper-state本质上就是把变量维度和时间维度的结构先提炼出来再让状态去承载这些结构。如果你也在做类似的长期预测任务我建议先别急着上复杂模块用合成多延迟数据把“模型是否真的学到了滞后关系”这件事验证清楚再往真实数据上迁移整个过程会踏实得多。 TimePro：基于Mamba的双感知hyper-state解决长期预测多延迟问题
最近我把大部分精力都花在多元时间序列的长期预测上。预测窗口一旦拉到几百步很多模型就开始露馅短期的拟合非常漂亮但未来几段输出的形态完全走样。这个项目叫TimePro核心是用Mamba做主干通过变量与时间双感知的hyper-state专门处理长期预测里最让人头疼的多延迟问题。先说明一下这里的“多延迟”不是指序列长而是指同一段历史里不同变量、不同时间尺度的滞后相关是叠加在一起的今天的电力负荷既受两小时前气温的影响也受昨天同一时刻的用电习惯影响还可能受上周同期的工作日模式影响。这些延迟怎么同时建模直接决定了长窗口预测是“越走越稳”还是“越走越偏”。如果你是做时序预测、想引入状态空间模型或者正在被长期预测的多延迟问题折磨这篇内容应该能帮上忙。我会把TimePro的设计动机、原理拆解、复现细节以及我踩过的坑一次讲清楚。1. 长期预测的老大难多延迟问题为什么绕不过去1.1 我理解的“多延迟问题”到底是什么时间序列里“延迟”这个概念非常基础。X_t与X_{t-k}之间存在相关性k就是延迟阶数。对于小时级数据k1可能是上一小时的影响k24是一天前的周期性影响k168是一周前的强周期影响。这些不同k值的相关结构同时存在于同一段序列里就叫多延迟。长期预测难并不是难在输出长度翻了几倍而是预测步数越远未来点需要参考的历史延迟组合越多样。第1个未来步可能主要依赖近期延迟第10个未来步可能依赖某个固定周期第100个未来步甚至要参考几个月前的趋势背景。如果模型只把全部输入压成一个固定隐变量短期延迟会天然占据优势长周期信号会被稀释到几乎看不见。我见过不少模型在96步预测上表现不错一旦切到720步后半段预测基本变成直线或者重复一段历史本质就是多延迟没有处理好。更麻烦的是多元序列里“变量间延迟”会叠加在“时间延迟”上。气温对电力负荷的影响可能是滞后1到2小时电价对用户行为的响应可能接近即时而设备维护记录的变更对负荷的影响可能是以周为单位的。变量间谁领先谁、领先多久本身就是一张不断变化的网络。所以在我的定义里多延迟问题包括两条线一条是单个变量内部的时间延迟一条是变量之间的交叉延迟。这两条线交织在一起才是长期预测真正的难点。1.2 已有方案为什么总感觉差口气Transformer类模型是目前长期预测的主流基线。注意力机制确实能捕捉长距离依赖但它是把所有时间步之间的两两关系都视作平等候选最后注意力权重往往被近期相似片段主导。你让模型同时关注“两小时前”和“上周同期”它通常会更偏爱前者因为短期模式在数值上更接近。另一个现实问题是O(L^2)复杂度回看窗口一大显存和训练时间都扛不住。PatchTST这类方法通过切patch缓解了一部分效率和局部性问题但patch本身是单尺度的它没真正回答“不同延迟尺度如何共存”。RNN/LSTM这类递归模型的思路是把依赖压缩进隐状态。单变量序列上门控机制可以记住一定长度的历史但多变量、多尺度延迟叠加时单个隐状态很快变成一锅粥。梯度传播也会随延迟长度急剧衰减虽然LSTM用门控缓解了一部分但面对几百上千步的预测任务状态容量依然是硬瓶颈。直接多步预测、递归多步预测这些解码策略也解决不了根本问题误差累积掩盖了模型对延迟结构的学习能力。Mamba类时序模型流行起来后很多人直接把Mamba当作更强的RNN或者更快的Transformer来用输入序列过一遍SSM就出结果。这类做法在标准基准上能取得不错分数但很少主动处理一个问题Mamba的状态到底应该记住什么。TimePro的核心改变是把这个问题放到了台面上用变量与时间双感知机制来决定状态的内容和演化方式。2. TimePro的设计思路与核心原理双感知状态从哪来2.1 变量感知先分清“谁在影响谁”TimePro的第一路输入叫做变量感知编码。它的任务不是压缩时间信息而是把变量维度上的交互结构显式提取出来。做法上我给每个变量配一个可学习的身份嵌入相当于给序列的每一列一个名字。电力负荷、气温、电价各有各的嵌入模型不会再因为数值相似就把它们搞混。拿到身份嵌入后再对原始输入做一次独立的线性投影得到每个变量的时间特征。然后把这些特征沿着变量维度做一次轻量交互可以用一个小的MLP也可以用类似多头注意力的机制计算变量之间的影响系数。这一步的产物是一个变量关系权重它告诉后续模块当前时刻的气温对电力负荷的影响权重是0.3而电价对负荷的影响可能是0.1。这个权重不是固定的它会随输入片段动态变化所以本质上是一种变量级的动态路由。为什么不用传统的协方差矩阵或者全局注意力来做这件事因为那些方法把所有变量一视同仁交互复杂度和变量数成平方级增长。TimePro里我做了一个降维处理先通过变量身份嵌入把每个变量的信息聚合成低维描述再做交互计算变量数再多也不会让计算量爆炸。实验里我的感受是这一步对多元数据集帮助非常明显尤其是当不同变量取值范围差异很大的时候单独做线性投影并按变量归一化训练要稳定得多。2.2 时间感知把不同尺度的延迟拆开看时间感知这一路解决的是“同一变量内部不同延迟尺度如何共存”的问题。我没有用单一的token化方式而是用多尺度卷积把原始序列拆成几路。实践中我用三路卷积卷积核大小分别对应短延迟、中延迟、长延迟。举例来说小时级电力数据里短延迟对应1到6小时卷积核设为3中延迟对应24小时附近的日周期卷积核可以拉到13到27长延迟对应周周期或者更长的趋势卷积核至少要覆盖168步的语义范围实践中通过多层小卷积或者池化叠出来而不是真的放一个kernel size168的卷积否则参数太多。每路卷积输出的长度要保持一致内部做膨胀卷积或者下采样再上采样都行。之后把三路特征通过门控融合成一路时间感知特征。这一步的巧妙之处在于不同尺度的特征在融合前已经各自独立激活了对应的延迟模式。模型收到一个输入片段时短期分支负责“最近几小时发生了什么”长期分支负责“上周这两天是不是也有类似的负荷曲线”两者不会再抢同一个特征通道。同时我还会加入时间戳嵌入比如小时、星期、月份这些周期性信息。很多人会忽略这一点但星期几这个特征对长期预测的价值极大如果回看窗口是168步模型必须知道当前输入覆盖的是一个完整星期否则很难把第169步的预测对齐到正确的星期模式上。时间感知和变量感知两路输出最终拼接或者相加形成统一的序列特征这一切都发生在Mamba的SSM进入之前。2.3 hyper-state到底是什么一个状态装下两套信息Mamba的核心是状态空间模型每个时间步都有一个内部状态h_t负责在序列间传递信息。普通Mamba的h_t由一组固定维度的向量组成状态更新规则是A h_{t-1} B x_t。听起来很通用但在长期预测里这种固定规则有两个问题第一状态不知道当前数据里有几个关键变量、哪个变量在主导第二状态不知道当前输入里哪个时间尺度更重要。TimePro提出的hyper-state就是为了解决这两个问题而存在的。hyper-state不是某个中间层的普通隐藏状态而是“关于状态本身的状态”它由变量感知和时间感知两路输出联合生成负责给出SSM的初始状态并且动态调制后续状态转移矩阵。我的实现里hyper-state会生成三组调制量分别作用于Mamba的A矩阵、B矩阵和C矩阵。这样一来模型在不同的时间片段下可以有不同的状态演化规则。同样一个SSM块在气温快速波动时会增强对近期延迟的敏感度在进入平稳周期时会转向对长期周期模式的记忆。这个思想其实和hypernetwork一脉相承。普通网络是一次前向算出一组权重hyper-state相当于根据输入数据即时算出一组“状态规则的调整量”。打个比方普通SSM是一辆只能按固定路线开的车它知道发动机转速和当前挡位但不知道目的地hyper-state是一个实时导航员它结合了当前路况变量感知和剩余路程时间感知不断告诉你什么时候该踩刹车、什么时候该深踩油门。Mamba的A、B、C矩阵就是那个油门刹车。2.4 为什么偏偏选Mamba当骨干不用Transformer不是因为Transformer不行而是因为长期预测任务里回看窗口和输出窗口都越来越长注意力机制的计算量让人很难受。Mamba基于状态空间模型计算复杂度跟序列长度呈线性关系这一点在长窗口训练里优势非常明显。同时Mamba的选择性扫描机制允许状态根据输入动态决定“记住什么、忽略什么”这一点和长期预测的需求天然契合。但直接把Mamba搬过来并不够。Mamba的选择机制通常只受当前输入x_t的影响它不会主动知道当前时刻有哪些变量在交互、当前延迟尺度是什么。TimePro里的hyper-state相当于给Mamba装了一个全局视角的控制器把变量感知和时间感知的决策信息提前注入到状态转移规则里。所以用Mamba当骨干既保留了线性复杂度和长程记忆能力又弥补了它对多延迟结构建模不足的问题。3. 从想法到实验TimePro复现的关键细节3.1 核心网络结构怎么搭一份可跑的伪代码下面是一段简化版的TimePro结构示意。真实实现里还要考虑维度对齐、归一化、残差连接这些细节但这个骨架能直观展示数据流向。import torch import torch.nn as nn class TimePro(nn.Module): def __init__(self, n_vars, pred_len, d_model256, d_state64, n_layers2): super().__init__() self.var_enc VariableEncoder(n_vars, d_model) # 变量感知 self.time_enc MultiScaleTimeEncoder(d_model) # 时间感知 self.hyper_net HyperNetwork(d_model, d_state) # hyper-state生成 self.ssm_stack nn.ModuleList( [MambaSSMBlock(d_model, d_state) for _ in range(n_layers)] ) self.head nn.Linear(d_model, n_vars * pred_len) def forward(self, x): # x: (B, L, C) v self.var_enc(x) # (B, L, D) t self.time_enc(x) # (B, L, D) z v t # 双感知融合 h self.hyper_net(z) # (B, D_state) 初始状态 z z.transpose(1, 2) # (B, D, L) for block in self.ssm_stack: z, h block(z, h) # (B, D, L), (B, D_state) out z.transpose(1, 2) # (B, L, D) return self.head(out.reshape(out.size(0), -1))VariableEncoder的核心是给每个变量生成一个嵌入然后沿变量维做一次交互投影。我习惯先对每个变量做独立LayerNorm再通过一个共享的线性层把输入统一到d_model维度。变量间交互用一个简单的MLP就可以不必每次都上注意力。MultiScaleTimeEncoder则是三路卷积加时间戳嵌入融合卷积核大小根据数据采样率灵活调整。HyperNetwork比较轻量它对双感知特征做全局池化再通过两层MLP生成d_state维的初始状态以及每层SSM需要的一组调制参数。MambaSSMBlock可以直接复用开源Mamba实现也可以自己写一个简化版本。只要保留离散化后的状态更新规则并让A、B、C矩阵可以接收hyper-state调制就行。注意Mamba的原始实现里B矩阵的投影是按序列长度动态生成的TimePro里要让序列维度和变量感知特征对齐否则维度很容易对不上。3.2 训练配置与超参数我用下来的推荐值训练配置上我推荐先用经典长期预测基准跑通ETTh1、ETTh2、ETTm1、ETTm2、Electricity、Traffic、Weather。这些数据集的采样频率和变量数量差异够大能很快检验模型的多延迟建模能力。回看窗口我常用96或192预测长度看具体设置一般覆盖96、192、336、720四个档位。超参数方面有一个起始配置可以先用d_model设为256d_state设为64SSM层数保持2到4层。再往上加层数时模型容量增加明显但训练时长也会线性上升。batch size我建议在ETT这类小数据集上用64在Electricity、Traffic这些大体量数据上降到32甚至16。学习率用3e-4配合余弦退火前几个epoch做warmup。AdamW的weight_decay设1e-4到1e-3注意状态空间模型对正则化比Transformer更敏感过大的weight_decay会把A矩阵压得太小导致长期记忆丢失。损失函数用MSE和MAE的加权组合我平时MSE权重是1.0MAE权重是0.1。训练一开始直接优化MSE会让模型倾向拟合大误差样本加入MAE能稍微平衡一下中后期误差。混合精度方面要特别小心Mamba的选择性扫描在fp16下偶尔会出现数值异常我通常先在fp32下把基线跑稳再尝试bfloat16加速。3.3 评测与消融如何证明“双感知”真的有用评测长期预测模型不能只看全局MSE。我强烈建议把预测输出切成几段分别计算前段、中段、后段的误差。很多模型前段误差很低后段误差急剧升高这种信息会被全局MSE掩盖。TimePro的定位是改善长窗口预测所以后段误差才是真正的KPI。消融实验按四组做去掉变量感知、去掉时间感知、去掉hyper-state的调制部分、把SSM替换成同样层数的Transformer编码器。我跑下来的典型趋势是去掉hyper-state的调制退化最明显特别是在预测长度720的档位上去掉时间感知后周期性强的数据集ETTh、Weather性能下降明显去掉变量感知后Electricity、Traffic这类多变量数据集体验更差。从方法论上讲这三块是拧成一股绳的单拆任何一块都可能不至于崩盘但组合起来效果最好。如果想在真实数据之前更清楚地验证“多延迟建模”能力建议先做一个合成数据集生成一个包含短期AR项、一个周期项、一个变量间滞后项叠加的信号。比如X_t 0.6 * X_{t-3} 0.3 * Y_{t-8} sin(2πt/24) 噪声。这类数据延迟结构非常明确TimePro在这种测试上能明显比普通Mamba和Transformer学得更快、更稳因为你给它设计的变量感知和时间感知正好打在问题的结构上。4. 复现与调参实录我在TimePro上踩过的坑4.1 长窗口预测后段误差高多延迟没被真正学到这是我遇到过最常见的现象训练loss下降很快验证集前段MSE也正常但最后一段预测基本失真。根本原因多半不是模型能力不够而是loss函数把训练重点全压在了短延迟上。因为前段误差数值通常比后段小整体MSE最小化时会优先优化“容易的部分”。我试过两个有效手段。第一个是把预测窗口分段加权后段权重大一些比如四段输出权重按1:1:1.5:2来设这能让模型被迫把注意力放到长延迟模式上。第二个是增强时间感知分支里的长周期特征具体做法是把多尺度卷积中对应长期的分支特征通道加宽或者直接往输入里加入傅里叶特征让模型在进入SSM之前就能看到周期结构。这两个手段合在一起通常能把720步预测的后段MSE拉下来不少。还有一个细节容易被忽略数据归一化方式。多变量数据里不同变量量纲差距可以非常大如果只做全局z-score归一化很多变量实际上被压到了噪声级别。我建议先对每个变量单独归一化再输入模型。变量感知编码里的独立LayerNorm也是在处理这件事。4.2 Mamba实现的几个经典坑Mamba的官方实现依赖一些底层优化版本兼容性有时候会让人头疼。如果只是验证TimePro的思想完全可以用纯PyTorch实现一个简化版SSM块。关键是训练时千万别用Python for循环逐时间步展开要用并行扫描或者至少沿着序列维度的分段扫描否则训练速度慢到没法用反向传播的计算图和显存开销也大得离谱。维度对齐是我调试时遇到最多的地方。A矩阵的维度是d_state×d_stateB矩阵是batch×seq_len×d_in映射到d_stateC矩阵则是batch×seq_len×d_state映射回d_model。hyper-state调制A矩阵时要确保生成的调制张量能广播到A的维度上。我一开始图省事直接用线性层从d_state生成d_state×d_state的参数结果参数规模和内存一下暴涨后来改成低秩调制先生成一个小的调制向量再外积扩展效果相近但参数少很多。数值稳定性也值得单独说一下。A矩阵的初始化不能随便来太大会导致状态很快爆炸太小又会让序列记忆迅速衰减。S4里的HiPPO初始化是经过验证的或者至少把A矩阵初始值限制在负半平面让系统本身倾向于稳定。每次状态更新后加一个LayerNorm或者残差门控也能有效抑制训练中途的数值抖动。训练精度方面如果发现loss曲线时不时出现尖刺优先怀疑fp16导致的状态计算溢出换成fp32基本就稳了。4.3 超参选择中容易出现的反向直觉很多第一次用state space model的人会觉得d_state越大越好我一开始也是这么想的。但在TimePro里d_state并不是单纯代表记忆容量它更像是“并行状态通道数”。如果只是把d_state从32加到128缺少变量感知和时间感知的引导增加的通道大部分会被冗余信息占用反而出现过拟合。我的建议是先保持d_state在64左右优先把变量感知和时间感知调好再尝试增大d_state并观察最后一段预测误差如果后段没有明显改善就说明信息在进入状态之前已经被处理得不够结构化问题不在容量。多尺度卷积的窗口大小也要对着数据采样率来调。5分钟粒度的数据24小时就是288个步长周周期是2016步这种情况下kernel size27的卷积根本摸不到周期边界你得靠多层膨胀卷积把感受野堆上去。小时级数据相对简单24步日周期和168步周周期用多路卷积可以覆盖。做实验前最好先看一眼数据的自相关图看看几个显著延迟峰值在哪里再决定时间感知分支的卷积核怎么配。这个步骤很快但对最终效果的影响非常大。还有一个容易被忽略的点hyper-state调制幅度一开始不要太大。Mamba的状态转移规则在预训练前基本处于一个脆弱平衡如果hyper-state一上来就大幅改写A、B、C矩阵训练初期很容易震荡。我的做法是在调制输出上乘以一个较小的缩放系数比如0.01或者0.05然后随着训练步数慢慢放开。这个小技巧几乎立刻让训练曲线变平滑。多说一句我自己的体会。在跑通TimePro之前我先后试过把Mamba直接当作序列编码器也试过用各种注意力模块做变量交互总觉得隔着一层。最后发现关键思路是要想清楚模型的状态里到底应该放什么。多延迟问题的本质是信息结构问题而不是单纯的模型容量问题。TimePro的变量与时间双感知hyper-state本质上就是把变量维度和时间维度的结构先提炼出来再让状态去承载这些结构。如果你也在做类似的长期预测任务我建议先别急着上复杂模块用合成多延迟数据把“模型是否真的学到了滞后关系”这件事验证清楚再往真实数据上迁移整个过程会踏实得多。