相信每个做过时序预测的人都遇到过这种场景：明天就是平台大促，今天的销量预测模型给出的数字却跟日常持平。不是模型笨，而是它根本不知道"明天有活动"这件事。更麻烦的是，就算你把促销信息作为特征硬塞给模型，它依然会在非平稳的时间段里失灵——均值突然跳升、方差剧烈抖动、连历史相关性都变了。这种"明明有外部事件在刺激序列，模型却感知不到、或者感知到了也稳不住"的问题，正是 EVENTTSF 这类事件感知的非平稳时序预测要解决的核心命题。
我在复现和调试这类方法时最大的感触是：事件感知不是给模型多加一个特征列那么简单。它背后牵涉到事件如何编码、如何与序列的平稳化处理协同、如何在训练和推理时避免数据泄漏，以及最重要的——如何验证模型是真的学到了事件影响，而不是在死记硬背。这篇文章把我从零搭建 EVENTTSF 类模型的完整思路、关键实现细节和踩过的坑全部摊开来说。
1. 先聊清楚：非平稳时序预测的痛点到底在哪
1.1 平稳性是"常态假设"，现实偏偏不平稳
绝大多数经典时序模型，从 ARIMA 到早期的 LSTM，底层都默认序列是平稳或近似平稳的。所谓平稳，说白了就是序列的统计性质——均值、方差、自相关结构——在时间上基本不变。但现实里的序列几乎从不听从这套假设：销售数据逢年过节暴涨、流量数据被热点事件冲出一个尖峰、风电功率跟着一场雨云剧烈波动。这些外部干扰把序列的"常态"打得粉碎，模型一遇到分布变化就容易彻底跑偏。
这里要区分一个问题：非平稳到底是"内生"的还是"外生"的。内生的非平稳，比如一个缓慢上升的购买趋势，本质上来自系统自身的演化，可以通过差分、趋势项分解来处理。外生的非平稳则不同，它由外部事件触发——大促、政策、突发新闻、极端天气。这类非平稳的特点是：时间点可识别，影响幅度大，而且往往带有明显的"事件前后不对称性"。EVENTTSF 的处理重点就落在这类"事件驱动的非平稳"上，因为它最需要显式建模，也最容易通过事件信息来补救。
1.2 直接硬上模型，大概率会翻车
很多人面对非平稳序列的第一反应是"把差分做了不就行了吗"。差分的本质是去掉局部均值，让序列在短窗口内看起来平稳。可问题在于，事件冲击不仅改变均值，还改变序列的方差、甚至改变序列与外部变量之间的相关性。你差分掉了均值，尖峰依然在；你做了归一化，模型依然会错误地把"事件日的跳升"当成常态趋势的一部分向外延拓。
我在实际对比中发现，直接在原始序列上训练一个标准 Transformer 预测模型，遇到事件日时预测误差平均要比平常高出一倍以上。就算把事件标签作为普通数值特征拼进输入，效果提升也很有限。原因有两个：第一，事件信息是稀疏的、离散的，需要专门的编码方式才能被模型有效吸收；第二，事件影响不是恒定的，一天前的双十一和一天前的普通打折，对今天销量的作用完全不同，普通特征拼接根本表达不了这种动态强度。这就需要把"事件感知"从附加特征升级为建模的一等公民。
2. 把"事件"当成一等公民：EVENTTSF 的建模视角
2.1 事件分类：先分清哪些能预测、哪些只能感知
建模事件前，我建议先把事件按"可预见性"分成两类。因为这两类在训练和推理时的处理逻辑完全不一样：可预见事件在预测开始时就已经确定会发生，熟悉事件（节假日、大促排期、体育赛事日程）可以在推理阶段作为未来已知信息直接输入；不可预见事件（突发舆情、设备故障、极端天气）在预测时你只知道它"已经发生"，只能利用它的滞后效应来修正近期预测，不能提前注入。
| 事件类型 | 典型例子 | 可预见性 | 建模方式 |
|---|---|---|---|
| 日历型事件 | 春节、双十一、黑五 | 高，提前数周可知 | 可作为未来外生变量输入 |
| 排期型事件 | 新品发布、平台促销排期 | 高，业务侧可提前提供 | 可作为计划变量输入 |
| 规则型事件 | 月末结算、每周补货 | 高，周期性出现 | 可纳入日历特征或事件字典 |
| 突发型事件 | 负面舆情、极端天气 | 低，只能事后感知 | 利用发生后若干期的冲击/滞后修正 |
| 隐性事件 | 竞品调价、消费热潮 | 低，无显式记录 | 需从残差中挖掘再反哺模型 |
这个分类直接决定了数据集怎么标注、特征怎么构造、评估怎么分层。我见过不少项目把不可预见的事件也当成未来特征喂进模型，结果在验证集上分数漂亮得离谱，一上真实环境就失效——因为真实预测时你根本拿不到那些未来事件的标签。
2.2 事件的三个效应：冲击、滞后和衰减
事件对序列的影响远不是简单的一个"加法"或"乘法"能描述的。我总结下来，至少有三个效应必须建模：
第一个是直接冲击效应。大促当天销量可能达到平常的 5 倍，这种即时冲击跟事件强度强相关，但很难从历史序列本身推断出来，必须靠事件本身的属性去估计。
第二个是滞后效应。很多事件的影响不会当天就结束。比如一场大型演唱会结束后，周边餐饮的客流会连续两三天维持高位；台风过境后，配送延误会滞后 12-24 小时才反映在签收率上。建模时需要用事件发生时刻到预测时刻的时间差来换算影响强度。
第三个是衰减效应。随着时间推移，事件记忆逐渐模糊，影响随之减弱。这里最常见也最好用的衰减函数是指数衰减——事件发生后的第k天，影响强度按 exp(-λk) 递减。λ 的取值对结果影响很大，我一般会拿验证集去搜索，而不是拍脑袋定。
2.3 为什么普通协变量不够，要单设事件通道
有人会问：节假日、促销这些信息，我当成 one-hot 特征拼进模型不行吗？行，但效果天花板很低。普通协变量（比如星期几、月份、温度）是连续的、平稳的、跟序列之间关系相对稳定的；而事件信息是稀疏的、突发的、强度剧烈变化的。把两者混在一个特征通道里，模型很容易被高频的星期信息主导，事件信息被淹没。
我的做法是把事件单独拉出一个模态，用独立的事件编码器处理，然后在深层通过融合模块跟序列主干做交互。这样做的优势在于：事件特征可以在自己的空间里做非线性变换（比如衡量不同事件之间的相似度），序列主干则专注提取序列本身的趋势和周期性，两者分工明确，最后再统一决策。这也正是 EVENTTSF 这个名字的含义——EVENT 负责事件感知，TSF 负责非平稳时序预测，两者各司其职。
3. EVENTTSF 的核心结构：从事件编码到平稳化预测
3.1 整体架构思路
整个框架可以拆成四段：输入层、事件编码器、时序主干、融合输出。输入层把历史窗口内的序列数据和事件数据分别整理成两个分支；事件编码器把事件映射成时间对齐的embedding序列；时序主干处理序列的平稳化与趋势提取；融合输出则把事件信息注入主干表征，最终生成预测。
这个架构里最关键的决策是"事件信息在哪个阶段注入"。我试过三种方案：在输入端拼接事件embedding和序列embedding、在注意力层做事件感知的key/value调制、在输出端用门控加权融合。实测下来，输入端拼接简单但信息容易稀释，注意力调制强但训练不稳定，门控融合效果最稳，也最容易调试。所以我的基础版本选择门控融合，后续如果数据量大、场景复杂，再逐步升级到注意力调制。
3.2 事件编码器：事件字典、嵌入与时间衰减
事件在输入模型前，需要被数字化。第一步是维护一个事件字典，把每一类事件映射到一个独立索引，同时为每类事件维护一个"先验强度值"。比如"大型促销"先验强度 3.0，"普通节日"先验强度 1.5，"突发负面舆情"先验强度 -2.0。这个先验强度可以来自业务经验，也可以从历史数据中统计得到。
第二步是对每个时间步构造一个事件向量。我的做法是：把窗口内发生的所有事件按时间衰减累加，得到该时间步的事件强度向量。假设事件e在t0时刻发生，强度为m，在当前时刻t的贡献就是 m · exp(-λ·(t-t0))。把所有事件的贡献按事件类型累加，就得到一个长度等于事件类型数的向量。这个向量再过一个可学习的线性层，就变成了该时间步的事件embedding。
这里有个细节：衰减系数λ需要区分"可预见事件"和"不可预见事件"。大促的滞后效应通常衰减快，几天内就消退；但大型政策调整的影响可能持续数周。对两类事件分别设置衰减系数，会让模型更灵活。
3.3 平稳化预测主干：RevIN 与去平稳注意力
事件编码解决的是"知道有事情发生"，平稳化主干解决的则是"序列本身别失控"。我最常用的基础主干是带 RevIN（可逆实例归一化）的 Transformer 编码器。
RevIN 的思路非常直白：在输入模型之前，对每一条样本做一次实例归一化——减去该样本的均值、除以标准差；模型输出预测后，再反向加上均值、乘回标准差。这样做的好处是让模型每一层看到的都是"相对变化"，而不是被不同尺度的绝对数值带着跑。更重要的是，测试时如果这条样本的均值方差跟训练分布不一致，RevIN 能先把它拉回一个标准尺度，让模型不至于直接崩掉。
如果场景里的非平稳更剧烈，我会换成 Non-stationary Transformer 提出的去平稳注意力机制。它的核心洞察是：标准的 softmax 注意力会把查询和键的差异过度抹平，导致序列中真正重要的非平稳信息被注意力层"正则化"掉。去平稳注意力的做法是把训练和测试时序列的平稳性差异（用均值方差度量）显式编码进注意力分数，相当于让模型在计算相关性时主动补偿分布偏移带来的影响。这个模块我建议只加在靠近输出的层，前面的层保持常规注意力即可。
3.4 融合输出：门控加权与残差连接
事件embedding和序列主干输出怎么融合，直接决定了事件感知能否真正生效。我采用的方案是：把事件embedding和序列表征分别过一层线性变换，然后用 sigmoid 门控计算一个0到1之间的权重，表示"当前时刻预测在多大程度上应该受人事件影响"。
公式可以简单理解为：融合表征 = (1-g) · 序列表征 + g · 事件表征。这里的 g 是条件门控，它由事件embedding和序列表征共同计算得出。如果一个时间步没有事件发生，g 会自然收敛到接近0，相当于退化为纯时序模型；如果事件强度很高，g 会接近1，预测主要由事件主导。
残差连接放在最后。也就是说：最终输出 = 融合表征 + 主干预测。我自己调试时发现，加上这个残差能让模型在小规模事件数据上更快收敛，因为它给了模型一个"什么都不改也行"的退路，避免事件信息稀疏时模型强行扭曲预测。
4. 数据构造与训练技巧：事件很稀疏，但别放弃
4.1 事件特征如何对齐到时间网格
时序预测的数据是等间隔的（日、小时、15分钟），而事件发生时间是离散的不规则时间戳。第一步就是把事件对齐到模型的时间网格上。我常用的方式是为每个时间步构造"事件影响向量"，这个过程的核心是防止数据泄漏。训练时，某个时间步 t 只能使用 t 之前已经发生的事件信息，绝对不能混入 t 之后的事件。
下面这段伪代码展示了事件强度特征的构造逻辑，关键是只用event_date < t的事件，并对时间差做衰减处理：
import numpy as np def build_event_features(events, ts_index, num_event_types, window=7, decay_lambda=0.5): # events: list of (date, event_type_idx, magnitude) # ts_index: 预测范围内的所有日期 features = [] for t in ts_index: feat = np.zeros(num_event_types) for date, type_idx, magnitude in events: dt = (t - date).days # 只看过去且落在窗口内的事件，防止泄漏 if 0 < dt <= window: feat[type_idx] += magnitude * np.exp(-decay_lambda * dt) features.append(feat) return np.stack(features)推理阶段要区分两类事件：可预见事件（大促、节假日）可以直接生成未来的事件特征序列；不可预见事件则没有未来信息，只能把"已经发生了的事件"作为当前的额外输入，用于修正近期预测。所有推理代码都要显式传"已知未来事件"和"不可知未来事件"两个列表，避免误用。
4.2 事件稀疏怎么办：增强与重加权
真实业务里，有事件的日期往往只占全部日期的 5% 到 15%。模型天然会被大量无事件样本主导，导致事件权重学习不足。我的做法有三招：
第一招是事件样本过采样。对包含事件的样本，在训练时以更高概率重复抽样，让模型在每轮 epoch 中更频繁地见到事件样本。
第二招是事件强度重加权。对损失函数按事件强度加权，强度高的样本分配更大权重。这样模型会优先拟合那些影响剧烈的场景，而不是把精力浪费在弱事件上。
第三招是可控的事件合成。训练到中期，我会在无事件样本上随机注入若干"合成事件"，事件类型和时间位置随机，强度取真实事件的分布范围。这一步相当于数据增强，能让模型对"哪里突然冒出事件"这件事更鲁棒，不至于一遇到没见过的事件类型就完全失灵。合成事件只参与训练，评估时要在真实事件测试集上验证。
4.3 损失与评估：不能只看整体指标
评估事件感知模型，最忌讳的就是只看整体 MAE 或 RMSE。因为无事件样本占比高，模型即使完全没有捕捉到事件影响，整体误差也可能因为无事件样本的"稀释效应"而显得还可以。我的建议是分层评估：把测试集拆成"有事件日子集"和"无事件日子集"，分别计算指标。
再做一层细化，把有事件的日子按事件类型分组，看每一类事件下的预测偏差。这样你能清楚地知道模型到底对哪些事件敏感、对哪些事件失效。我见过一个项目，整体指标已经相当好，但拆开一看，模型对"突发负面事件"几乎零响应——因为这种事件样本太少，被完全淹没在了正常样本里。不做分层评估，这个问题可能永远发现不了。
这里也建议把"事件日前后的预测偏差曲线"画出来，看模型在事件前、事件当天、事件后1-3天的误差轨迹。理想情况下，事件当天的误差会有一个峰值，但事件后应该迅速回落。如果事件后误差迟迟不降，说明模型的衰减建模出了问题，多半是λ设太小或者门控退化不彻底。
5. 踩坑实录：常见问题与排查方法
5.1 数据泄漏是第一大坑
事件感知模型最容易犯的错误，就是把未来事件信息混进训练特征。比如你预测今天的需求，却把今天下午要上的热搜事件作为特征放了进去——这在离线训练时数据都在同一个表里，一不留神就会发生。排查方法很简单：检查特征构造函数里有没有对时间戳做严格过滤，以及验证集里是否存在"使用未来事件预测过去"的样本。
我还遇到过一种隐蔽泄漏：事件字典的构建用了全量数据统计，包括测试集的标签信息。比如用测试期的销量均值去反推某个事件的先验强度，这等于把答案泄露给了模型。正确做法是先验强度只在训练集上统计，测试集事件只用训练集学到的先验。
5.2 内生事件和外生事件要分清
事件跟序列可能是"内生"关系而非"外生"关系。举个例子，某天的销量异常增高，你把它标记为"爆款事件"并作为特征建模，但真实原因是序列自身的一个长期趋势上穿。这种内生事件如果被当成外生事件建模，模型学到的其实是"序列自己对自己的未来做预测"，本质上是在偷看未来。
判断方法是看事件的因果方向：事件发生在序列跳升之前，还是序列跳升伴随事件同时出现。只有前者才适合作为外生事件注入。如果事件和序列突变同时发生，说明事件可能只是序列跳跃的共现标签，应该谨慎对待。
5.3 事件embedding过拟合怎么办
事件类型少的时候（比如只有十几类），embedding 层很容易过拟合，模型直接把事件embedding当成了"记忆桶"，而不是学到事件之间的语义关系。我的缓解方法有几种：给embedding加 dropout、把embedding维度压到 8-16 维、用事件属性（类别、强度、时间）拼出的特征替代纯 look-up embedding。
更有效的是引入事件相似度正则：对语义相近的事件，在 embedding 空间里约束它们的距离。比如"电商平台大促"和"店铺周年庆"本质上都是促销事件，正则会让它们的表征靠近，模型就能在小样本事件上借助相似事件的知识，而不是从零开始学。
5.4 常见问题速查表
| 现象 | 可能原因 | 排查/解决方法 |
|---|---|---|
| 事件日预测偏低 | 事件强度先验设置太小 | 检查事件字典先验强度，按业务实际影响上调 |
| 事件后几天误差持续高位 | 衰减系数λ过小 | 对事件后误差曲线做拟合，搜索合适的λ |
| 整体指标好，事件日指标差 | 样本不平衡 | 启用事件样本过采样和损失重加权 |
| 模型对突发类事件无响应 | 突发样本太少被淹没 | 单独对突发类型做合成增强，或提高权重 |
| 验证集好、线上差 | 训练时混入了未来事件信息 | 严格按时间过滤特征，审查事件字典构建过程 |
| 门控权重几乎恒定为0 | 融合模块退化 | 检查门控初始化，适当调低序列分路的初始权重 |
| 事件embedding崩溃（输出NaN） | 事件强度累加数值过大 | 对事件强度向量做归一化，限制最大累加值 |
6. 一点个人体会与可扩展的方向
我个人在落地这类模型时最深的体会是：事件感知的真正价值不在于让模型"记住"哪几天有活动，而在于让模型具备一种"面对未知冲击时的稳态能力"。哪怕有一天来了一类完全没见过的事件，只要事件编码和门控机制设计得当，模型至少不会崩溃式地乱预测，而是会谨慎地调整输出幅度。这种鲁棒性，比把已知事件的误差压到0更有意义。
调试过程中的另一个心得是：别一上来就上复杂架构。先把"事件衰减特征 + RevIN + 门控融合"这个最简版本跑通，确认分层指标确实有提升之后，再逐步引入去平稳注意力、事件相似度正则这些进阶模块。我在很多次实验里发现，性能瓶颈往往不在模型结构，而在事件字典的质量和衰减系数没调好——数据侧的工作，永远比模型侧的炫技更值得先做。
如果你想在这个方向继续深挖，我建议关注三个扩展点：第一是多粒度事件融合，把分钟级事件和天级事件同时建模；第二是事件演化向量，把同一事件在不同阶段的影响建模成一条演化曲线，而不是一个静态强度；第三是事件因果图，把多个事件之间的相互影响——比如大促和物流延误之间的联动——用图结构表达出来。这三个方向每个都能单独撑起一个课题，但在动手之前，先把基础框架里的事件字典、衰减和门控做扎实，比什么都重要。
