大数据-训练/测试集：时序特征（滚动均值、滞后项、滑动窗口统计量）在划分之前就计算好了，这些特征天然包含了跨越训练/测试边界的信息，窗口越长泄漏越严重——到底该先划分再逐折计算，还是可以用“截至划分点”的窗口然后整体平移？

一、问题的真实面貌：一个被低估的工程事故

先还原一个几乎所有时序团队都遇到过的场景。数据表里有 100 万行、按天粒度的销售记录，工程师在 pandas 里写下 df['ma7'] = df['y'].rolling(7).mean()，然后 train_test_split 切出最后 20% 作为测试集。模型在测试集上 R² 高达 0.97，上线后第一周误差翻了三倍。问题不在模型，而在于 ma7 这一列在测试集起点附近的值，是用测试集自身前几天的真实值算出来的——模型在“偷看答案”。

这类事故之所以被低估，是因为它不像数据泄漏的经典案例（把标签列误当特征）那样显眼。滚动统计量本身是合法特征，泄漏藏在“计算顺序”里，而不是“列内容”里。Kaggle 上大量时序竞赛的公开讨论帖都反复提到同一现象：本地交叉验证分数漂亮、排行榜分数断崖，追问下去多半是特征在划分前被全局计算。国内外工业界的复盘文章也指向同一结论——泄漏往往不是模型问题，而是数据流水线的时序纪律问题。

笔者认为，把这个问题简单归为“先划分还是后划分”的二选一，是讨论的降维。真正需要回答的是一个更本质的问题：每一个特征值，在真实业务时间轴上，最早在哪个时刻可以被计算出来？这个问题一旦被清晰回答，“先划分”与“平移”之争就变成了实现细节的取舍。本文后续所有章节都围绕这个“信息时间戳”展开。

工程现场的经验法则：如果一个特征在“预测时刻 t”需要用到 t 之后的数据，它就不该出现在 t 时刻的特征向量里。滚动均值、滞后项、滑动窗口统计量，全部可以用这一条筛一遍。

二、分析主线：信息时间戳（Information Timestamp）

2.1 定义

对任意特征列 f 和样本行 i，定义其信息时间戳 IT(f, i) 为：计算 f 在第 i 行取值时，所依赖的全部原始数据中“最晚的那个观测时刻”。若 f 是原始列，IT 就是该行自身的时间戳；若 f 是 7 日滚动均值，IT 等于该行时间戳（因为窗口右端对齐当前行）；若 f 是“未来 3 天均值”，IT 就落在未来，属于非法特征。

这个定义看似平凡，却能统一解释本文要讨论的所有现象。泄漏的本质，就是存在某个样本 i 属于测试集，而它的某个特征满足 IT(f, i) 晚于训练/测试划分点，且该特征值在训练阶段被“提前算好”并参与了拟合或标准化。注意这里有两个条件：时间戳越界，以及越界值被训练流程消费。只满足前者不构成泄漏（比如测试集特征在测试阶段才计算），两者同时满足才是事故。

2.2 为什么用“时间戳”而不是“是否用了未来数据”

“是否用了未来数据”是一个是非判断，容易在边界上扯皮。时间戳是一个可计算的量，可以逐列、逐行审计。笔者建议在特征字典里为每一列显式登记三件事：窗口方向（左/右/居中）、窗口长度、锚点规则（右对齐/左对齐/居中）。这三件事决定了 IT 的分布形态，也决定了泄漏的严重程度。窗口越长，IT 越界后携带的“未来信息量”越大，这正是“窗口越长泄漏越严重”的机理来源——不是玄学，而是窗口右端跨越边界后覆盖的测试样本数随窗口长度线性增长。

2.3 本文评述

把泄漏问题形式化为时间戳审计，好处是它可以直接写进数据契约（data contract）。团队可以在 CI 里加一条断言：对每个特征列，检查其在验证折上的 IT 是否严格小于该折的验证起点。这条断言比“人工 review 特征工程代码”可靠得多。笔者认为，这才是把时序纪律从“个人经验”升级为“工程约束”的关键一步。

三、泄漏的三种形态与量化诊断

3.1 形态一：未来信息型泄漏

最直接的一种。特征定义本身就指向未来，例如“未来 7 天销量均值”“下月是否促销”。这类特征在训练集内部也会让模型学到不存在的因果方向。诊断方法很直接：对每列检查其窗口是否右对齐且右端超出当前行时间戳。若超出，标记为非法。

3.2 形态二：边界污染型泄漏

本文讨论的主角。特征本身是因果的（右对齐滚动窗口、滞后项），但因为在划分前对全表统一计算，导致测试集前若干行的窗口“吃进”了训练集末尾的数据，或者反过来训练集末尾的窗口“吃进”了测试集开头的数据。后者更隐蔽：训练集最后几行的滚动均值用到了测试集最初几天的真实值，模型在训练时就提前看到了测试期的分布。边界污染的污染半径恰好等于窗口长度减一（对右对齐窗口而言），这就是“窗口越长泄漏越严重”的定量表述。

3.3 形态三：目标编码型泄漏

滑动窗口统计量如果作用在标签列上（例如“过去 30 天转化率均值”作为特征），而该统计量在划分前计算，则测试集样本的统计量里混入了训练集标签信息。这与经典的 target encoding 泄漏同源，只是披了时序的外衣。诊断方法是检查统计量的输入列是否包含标签，以及计算时机。

3.4 量化诊断：泄漏敏感度指标

笔者建议引入一个简单的诊断量：泄漏敏感度 LS = |Score_泄漏版 − Score_干净版| / Score_干净版。做法是对同一模型、同一数据，分别用“划分前全局计算特征”和“划分后逐折计算特征”跑两遍，比较验证分数。LS 越大，说明该特征集的泄漏风险越高。下表给出一组基于公开时序数据集（M5 与 Rossmann 的公开子集，模拟数据，仅用于演示量级）的示意结果：

注：上表为模拟数据，用于说明泄漏敏感度随窗口长度与统计量类型变化的相对趋势，不代表任何真实业务系统的绝对性能。M5 数据集原始说明见 Makridakis 等（2022），Rossmann 数据见 Kaggle 竞赛页面。

从表中可以读出两个规律：其一，滞后项的泄漏几乎可以忽略，因为窗口长度为 1，污染半径为零；其二，标签类滚动统计量的 LS 最高，因为污染的是标签信息本身。这提示我们，泄漏治理的优先级应当是：标签类统计量 > 长窗口统计量 > 短窗口统计量 > 滞后项。

四、路线一：先划分，再逐折计算

4.1 核心思想

把时间轴切成互不重叠的若干段，每一段作为验证集时，其所有特征只允许用该段起点之前的数据计算。训练集同理。这样任何特征的信息时间戳都不会越过所在折的起点，泄漏在结构上被消除，而不是靠人工检查。

4.2 标准流程（可直接照做）

1. 按时间排序，确定切分点 t_split（单次划分）或滚动窗口的多个切分点（时间序列交叉验证）。
2. 对每个折，取训练段 [t0, t_split)，在训练段内部计算所有滚动/滞后特征，窗口不得越过 t_split。
3. 验证段 [t_split, t1) 的特征，用“截至 t_split 的历史 + 验证段内已发生的因果历史”计算。注意验证段内部的前几行需要用训练段末尾数据做窗口预热，这是合法的，因为预热数据的时间戳早于验证行。
4. 标准化、缺失值填充等所有依赖统计量的变换，同样只在训练段拟合，再 transform 验证段。
5. 重复以上步骤，直到所有折跑完。

4.3 优点与代价

优点是安全、可审计、与 sklearn 的 Pipeline 语义天然契合。代价是计算量随折数线性增长，且实现上需要把特征工程封装成“可 fit/transform 的时序对象”，不能再用一行 pandas 全局计算。笔者认为这个代价是值得的：它把泄漏风险从“依赖工程师自觉”转移到了“依赖流水线结构”，而结构比人可靠。

4.4 常见误区

误区一：只对特征做逐折计算，忘了标准化。均值和方差如果在全表上算，同样构成泄漏，只是量级较小。误区二：验证段特征完全不用训练段数据，导致验证段开头出现大量 NaN，模型性能被低估。正确做法是允许“向后看”的预热，禁止“向前看”的借用。误区三：把时间序列交叉验证当成普通 KFold 打乱，这会让未来折的信息进入过去折，属于更严重的泄漏。

五、路线二：截至划分点窗口 + 整体平移

5.1 这个方案到底在说什么

很多团队不想逐折重算，于是提出一个折中：特征仍然在全表上算，但每个窗口的锚点固定在划分点 t_split，窗口只向过去看；算完之后，把整列特征沿时间轴“平移”到对应行。听起来像是既省事又安全，实际上这里藏着本文最想强调的陷阱。

5.2 正确的平移方案长什么样

对测试段第 j 行（时间 t_j），其滚动均值应当等于 [t_j − L + 1, t_j] 区间内真实值的均值。若我们只允许用截至 t_split 的数据，那么当 t_j − L + 1 < t_split 时，窗口左端会伸进训练段，这是合法的（训练段数据在 t_j 时刻已可见）；当 t_j 本身大于 t_split 时，窗口右端就是 t_j，也合法。换句话说，正确的做法不是“把划分点的窗口平移”，而是“对每一行用其自身时间戳作为右锚点、窗口长度 L、只向过去看”。这本质上就是逐行因果计算，只是实现上可以向量化。

如果非要“整体平移”，正确的语义是：先算好全表的因果滚动特征（右对齐、只向过去），然后按行时间戳对齐，训练段用训练段的值、测试段用测试段的值，中间不做任何跨段的窗口重算。这种方案与“先划分再计算”在数学上等价，前提是滚动计算本身是因果的、且没有使用未来信息做填充。

5.3 错误平移的三种典型翻车

本文评述：这三种翻车的共同根源，是把“平移”理解成了“位置调整”，而它真正的语义是“时间对齐”。位置调整是几何操作，时间对齐是因果操作，两者只在窗口完全因果且锚点正确时才重合。一旦窗口本身不因果，任何平移都是徒劳。

六、两条路线的等价性证明与反例

6.1 等价性条件

设特征为右对齐滚动统计量，窗口长度 L，锚点为当前行时间戳。则“先划分再逐折计算”与“全表因果计算后按行对齐”在每一行上的取值完全相同，因为两者都只依赖该行及其之前 L−1 行的原始数据，与划分点无关。等价性的充要条件是：窗口因果、锚点正确、无跨段填充、无全局标准化。四个条件缺一不可。

6.2 反例：标准化打破等价性

假设滚动特征本身因果，但标准化用了全表均值。此时测试段每一行的标准化值都依赖全表统计量，信息时间戳被拉到了全表末尾，等价性被打破。这个反例说明，泄漏治理不能只盯特征列，还要盯所有“拟合型变换”。实践中，标准化、目标编码、缺失值填充、PCA、甚至某些特征选择步骤，都属于拟合型变换，都必须放进逐折流程。

6.3 反例：窗口预热打破等价性

如果实现时对测试段单独做 rolling，且没有把训练段末尾数据拼进去预热，那么测试段前 L−1 行会是 NaN 或被错误填充。此时两条路线结果不同，但差异来自“预热缺失”而非“泄漏”。这说明等价性讨论必须区分“泄漏差异”和“实现差异”，前者是错误，后者是工程细节。笔者建议在单元测试里同时断言两件事：逐折结果与全表因果结果在非预热行上一致；预热行数等于 L−1。

七、工程落地：代码模板与检查清单

7.1 因果滚动特征的向量化实现

import pandas as pd
import numpy as np

def causal_rolling(df, col, window, stats=("mean", "std")):
    """右对齐、只向过去看的滚动统计量。
    信息时间戳 = 当前行时间戳，天然因果。"""
    s = df[col]
    out = {}
    r = s.rolling(window=window, min_periods=1)
    if "mean" in stats:
        out[f"{col}_ma{window}"] = r.mean()
    if "std" in stats:
        out[f"{col}_sd{window}"] = r.std()
    return pd.DataFrame(out, index=df.index)

def lag_features(df, col, lags=(1, 7, 28)):
    """滞后项：信息时间戳 = 当前行时间戳 - lag。"""
    return pd.DataFrame(
        {f"{col}_lag{k}": df[col].shift(k) for k in lags},
        index=df.index,
    )

注意 min_periods=1 会让序列开头产生不完整窗口，这在训练段是可接受的，但在测试段开头需要预热。预热的正确做法是把训练段末尾 L−1 行拼到测试段前面一起 rolling，算完再切掉预热部分。这样既不泄漏，也不产生 NaN。

7.2 逐折流水线骨架

from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler

class TimeSeriesFeatureBuilder:
    def __init__(self, windows=(7, 28), lags=(1, 7)):
        self.windows, self.lags = windows, lags

    def fit(self, train_df, y=None):
        # 只记录需要的信息，不消费验证数据
        self.last_ts_ = train_df.index.max()
        return self

    def transform(self, df, warmup_df=None):
        base = pd.concat([warmup_df, df]) if warmup_df is not None else df
        feats = [causal_rolling(base, "y", w) for w in self.windows]
        feats.append(lag_features(base, "y", self.lags))
        X = pd.concat(feats, axis=1)
        return X.loc[df.index]  # 切掉预热部分

# 每个折：fit 只在训练段，transform 时把训练段末尾拼进来预热

7.3 上线前检查清单

• ✅ 每个特征列在特征字典里登记了窗口方向、长度、锚点规则。
• ✅ 所有拟合型变换（标准化、填充、编码）都在逐折流程内，未使用全表统计量。
• ✅ 时间序列交叉验证未打乱顺序，验证折严格晚于训练折。
• ✅ 测试段开头的预热行数等于最大窗口长度减一，且预热数据来自训练段。
• ✅ 存在一条自动化断言：验证折上任意特征的信息时间戳 < 验证折起点。
• ✅ 泄漏敏感度 LS 已测量，且低于团队设定阈值（建议 2%）。
• ✅ 标签类滚动统计量单独审查，确认未在划分前计算。

关于时间序列交叉验证的实现细节，可以参考 scikit-learn 官方文档中 TimeSeriesSplit 的说明；关于 pandas 滚动窗口的边界语义，官方 Window 用户指南 有完整示例；Kaggle 上关于时序泄漏的公开讨论可参考 Kaggle Discussions 中的相关帖子。

八、回测协议与评估指标的正确姿势

8.1 滚动回测而非单次划分

单次训练/测试划分只能回答“模型在某一段上的表现”，无法回答“模型在时间推移中的稳定性”。滚动回测（rolling-origin evaluation）让切分点沿时间轴滑动，每次只用切分点之前的数据训练、之后的一段验证，能同时暴露泄漏与漂移。这与 Makridakis 等人在 M 系列竞赛中倡导的评估协议一致，也是工业界时序模型上线的标准动作。

8.2 指标选择

R² 对泄漏非常敏感，因为泄漏会人为压低残差方差，导致 R² 虚高。建议同时报告 MAE、RMSE、以及按预测步长分组的误差曲线。若某一步长的误差异常低，往往提示该步长附近的特征存在边界污染。笔者习惯把“误差随步长的衰减速度”作为泄漏的辅助信号：正常模型的误差随步长上升，泄漏模型的误差在边界附近会出现不自然的凹陷。

8.3 与在线指标对齐

离线回测的分数必须能与线上 A/B 的指标对话。若离线 R² 0.97、线上 MAE 翻倍，第一反应应是查泄漏，而不是调模型。建议在回测报告里固定放一栏“离线-线上偏差”，并把它纳入模型上线评审。

九、前沿走向：因果特征工程与在线学习

9.1 因果特征工程

近年因果推断与时间序列的结合越来越紧密。核心思路是把“特征是否因果可用”从工程约定上升为因果图上的可识别性条件：只有那些在因果图中位于预测时刻之前的变量，才允许进入特征集。本文评述：因果图的价值不在于给出新算法，而在于给“信息时间戳”提供理论背书——它把工程直觉变成了可证明的约束。相关讨论可参考 Pearl 的因果图框架与近年时间序列因果发现综述。

9.2 在线学习与特征实时计算

当模型从离线批训练转向在线学习，特征必须在预测时刻实时计算，泄漏在架构上被天然抑制——因为系统根本没有“全表”可算。这提示一个反直觉的结论：在线学习架构本身就是一种泄漏防护机制。但代价是工程复杂度上升，且需要处理特征存储（feature store）的一致性问题。国内外主流特征平台（如 Feast、Feathr）都在文档中强调 point-in-time join，其本质正是信息时间戳对齐。

9.3 基础模型时代的时序泄漏

时序基础模型（time-series foundation model）在预训练阶段见过大量公开数据，评估时若测试集与预训练语料重叠，会引入一种新型泄漏——语料泄漏。它与本文讨论的窗口泄漏不同源，但同样会让离线分数虚高。笔者认为，未来时序模型的评估协议需要同时声明“窗口因果性”和“语料独立性”，两者缺一不可。

十、结论与行动建议

回到标题的问题：到底该先划分再逐折计算，还是可以用“截至划分点”的窗口然后整体平移？本文的答案是：两者在满足四个条件时数学等价，但对绝大多数团队，先划分再逐折计算是默认安全解；平移方案只有在具备时间戳审计能力、且实现严格因果时才可启用。因为平移方案的失败模式更隐蔽——它看起来做了防护，实际上可能什么都没防住。

具体行动建议分三步：第一步，为现有特征字典补登窗口方向、长度、锚点，形成信息时间戳清单；第二步，在 CI 中加入“验证折信息时间戳不得越界”的断言，并测量泄漏敏感度 LS；第三步，把特征工程封装成可 fit/transform 的时序对象，逐步替换全局 pandas 计算。这三步不需要推翻现有架构，却能堵住时序项目里最常见、也最昂贵的一类事故。

十一、主要参考文献