大数据-训练/测试集：推荐系统里广泛使用的leave-one-out（留一法）把每个用户的最后一条交互留作测试，但不同用户的“最后一条”在全局时间轴上前后交错，这为什么构成时间泄漏，全局时间切分（Global Temporal Split）又该怎么设cutoff才不把最近行为全部排除在训练之外？

一、问题的提出：一条锯齿状的时间边界

先看一个具体的场景。某电商平台有100万活跃用户，交互日志覆盖2023年1月至2024年6月。团队按LOO切分：每个用户按时间排序，最后一条交互进测试集，其余进训练集。切完之后，训练集有约4.2亿条记录，测试集100万条。看起来比例合理、逻辑清晰。

但如果把每个用户"最后一条交互"的时间戳画在全局时间轴上，你会看到一条参差不齐的锯齿：重度用户可能昨天还下过单，最后一条落在2024年6月；轻度用户可能2023年8月之后就流失了，最后一条停在2023年8月。于是训练集里既有2023年1月的老行为，也有2024年6月的最新行为；而测试集里既有2024年6月的预测任务，也有2023年8月的预测任务。

核心矛盾：LOO保证了"同一用户"的训练行为早于测试行为，却没有保证"全局"的训练行为早于测试行为。前者是用户级因果，后者才是部署时真正面对的因果。

这就是本文要讨论的时间泄漏。它不是数据错位、不是标签污染那种一眼能看出来的脏数据问题，而是一种结构性的、协议层面的信息越界：模型在训练阶段接触到了测试阶段"尚未发生"的信息。对于时序敏感的模型（如基于序列的推荐、带时间衰减的协同过滤、任何使用了全局统计特征的模型），这种越界会被放大。

本文的分析主线是"时间边界一致性"：一个评估协议是否可信，取决于它构造的训练/测试边界，是否与线上系统在决策时刻所能获得的信息边界一致。LOO的问题不在于"用了最后一条"，而在于它构造出的边界在全局时间轴上不单调、不一致。理解了这条主线，cutoff怎么设、要不要做滚动评估、冷启动怎么补，都会变成同一问题的不同侧面。

二、LOO的起源、流行与它回答的问题

2.1 从评估协议谱系看LOO的位置

推荐系统的离线评估协议大致可以排成一条谱：随机留出（random holdout）、用户内留一（LOO）、用户内留最后N条、全局时间切分（GTS）、滚动时间窗（rolling window / sliding window）、以及更严格的在线A/B。这条谱从左到右，时间约束越来越强，与线上部署场景的相似度也越来越高。

LOO在学术界流行有其历史原因。早期协同过滤研究关注的是"给定用户历史，能否补全缺失评分"这一矩阵补全问题，用户内留一恰好对应"补全一个空缺"的任务形式，评估指标（HR@K、NDCG@K）也容易定义。经典工作如Herlocker等人关于协同过滤评估框架的讨论（Herlocker et al., 2004）、以及后续大量基于MovieLens、Amazon Reviews的论文，都沿用了这一范式。本文评述：LOO回答的是"用户兴趣建模得准不准"，而不是"系统明天上线能不能用"——这两个问题在学术上有价值差异，在工程上则有本质区别。

2.2 为什么它"看起来"很合理

LOO有三个讨喜的性质：一是每个用户都贡献一条测试样本，覆盖率100%，不会出现"某些用户完全不在测试集"的尴尬；二是训练集利用率高，只损失了1/N的交互；三是实现简单，groupby用户、按时间排序、取最后一条即可。对于交互稀疏的数据集（每个用户平均只有十几条记录），随机留出可能导致部分用户训练样本过少，LOO则缓解了这个问题。

但笔者认为，这三个优点都是"用户维度"的，它们没有回答"时间维度"的问题。覆盖率100%只说明测试集在用户上无偏，不说明在时间上无偏；训练集利用率高只说明数据没浪费，不说明数据用得对。

2.3 一个被忽视的前提假设

LOO隐含了一个强假设：不同用户之间的行为在时间上可以视为相互独立、可交换的。在这个假设下，"用户A的3月"和"用户B的9月"没有本质差别，因为它们属于不同用户，互不影响。这个假设在静态矩阵补全的语境下勉强成立，但在真实的推荐系统中几乎必然被打破：物品热度随时间漂移、全局流行度特征跨用户共享、内容池不断更新、促销活动造成全局性行为脉冲。一旦模型使用了任何跨用户的全局统计量，用户间的"时间可交换性"就失效了。

三、时间泄漏的三种机理：特征、标签与评估

时间泄漏不是一个单点问题，它会沿着三条路径渗入评估结果。把这三条路径拆开看，才能对症下药。

3.1 特征侧泄漏：全局统计量把未来"搬"进了训练

最常见的特征是物品热度、用户活跃度、全局点击率这类聚合统计量。假设模型使用"物品在过去30天的点击量"作为特征。在LOO切分下，训练集里包含了用户A在2024年6月的交互，那么计算"物品在2024年5月的30天点击量"时，这个统计窗口里就混入了本应属于测试期的行为。更隐蔽的是，如果统计窗口是"截至当前的全量累计"，那么训练样本的特征值会直接包含测试期之后的信息。

这类泄漏在树模型和深度模型中都会被放大，因为模型会学到"高热度物品更容易被点击"这一在训练集上被未来信息强化过的规律，而线上部署时这个规律会打折扣。本文评述：特征侧泄漏的判别标准很简单——对任意一条训练样本，其特征计算所依赖的所有原始交互，时间戳都必须早于该样本的标签时间戳。这条"特征-标签时间单调性"是point-in-time正确性（point-in-time correctness）的核心，也是特征平台（如Feast、Tecton）反复强调的概念。

3.2 标签侧泄漏：负采样与全局物品池的越界

推荐系统的训练样本通常是"正样本+负采样"。负采样如果从全局物品池中抽，而这个物品池包含了测试期才上架的新物品，那么训练阶段模型就"见过"了未来才存在的物品ID。对于使用物品ID embedding的模型，这相当于提前分配了embedding，测试时这些embedding已经带着训练期的"预热"，评估结果会虚高。

另一个常被忽视的点是用户侧：如果测试集用户的注册时间晚于cutoff，而训练集里已经出现了该用户的行为（因为LOO把该用户的早期行为放进了训练），那么模型实际上是在"用未来用户的过去"训练，再去预测"未来用户的未来"，这在全局时间上是不自洽的。

3.3 评估侧泄漏：指标本身的乐观偏差

即使特征和标签都干净，LOO的评估指标本身也可能偏乐观。原因在于测试样本的"难度分布"与线上不一致。LOO的测试样本是每个用户的最后一条，而线上系统面对的是"任意时刻的下一条"。对于流失用户，其"最后一条"往往是流失前的低质量交互，预测难度高；对于活跃用户，其"最后一条"是最近的高频交互，预测难度低。两类样本混在一起，指标的方差被放大，且与线上真实分布不匹配。

更微妙的是，LOO测试集中"用户-物品"对的候选集构造方式，往往与线上召回-排序链路不一致。学术评估常用"全库排序"或"1正+99负"，而线上是"多路召回后精排"。这种评估协议与部署协议的不一致，本身就是一种广义的"评估泄漏"——它让离线指标与线上收益之间的相关性变弱。笔者认为，这一点比时间泄漏更根本：时间泄漏是"信息越界"，评估协议失配是"任务越界"，两者叠加会让离线评估彻底失去指导意义。

四、泄漏的量化：它到底能把指标抬高多少

定性分析之后，工程团队最关心的是量级。这里需要说明：不同数据集、不同模型、不同指标下，泄漏带来的虚高幅度差异很大，不存在一个普适的"抬高X%"的结论。下面给出的是基于公开数据集常见实验设置的模拟数据与文献中反复出现的定性规律，用于建立直觉，不作为任何具体系统的性能承诺。

4.1 模拟实验设置

模拟设置如下：取一个中等规模公开交互数据集（如Amazon Reviews的一个子类，或MovieLens-1M），按时间排序，构造两种切分——(a) LOO；(b) GTS，cutoff取全局时间轴的80%分位。模型选两类：一类是纯用户历史的矩阵分解（无全局特征），一类是带物品热度特征的GBDT排序模型。指标用HR@10与NDCG@10。重复5次随机种子取均值。

模拟结果呈现出一个稳定的规律：纯用户历史模型在两种切分下的指标差异较小（通常在个位数百分比以内），而带全局统计特征的模型在LOO下的指标显著高于GTS。这与第3.1节的机理分析一致——泄漏主要通过全局特征这条路径起作用。需要强调，这是模拟数据，具体数值会随数据集稀疏度、时间跨度、特征设计而变化，读者应在自己的数据上复现这一对比，而不是引用某个具体数字。

4.2 为什么"差异小"不等于"没问题"

有人会说：既然纯用户历史模型差异不大，那LOO也没那么糟。笔者认为这个推论是危险的。第一，现代推荐系统几乎不可能不用全局特征，物品侧、内容侧、上下文侧的特征天然是跨用户聚合的；第二，即使指标绝对值差异小，LOO下的模型排序也可能被扭曲——A模型比B模型更依赖全局特征，LOO就会系统性地偏爱A，导致选型错误；第三，离线指标的用途是指导线上决策，任何系统性偏差都会在长期迭代中累积。

判断泄漏严重程度，不要只看"指标涨了多少"，要看"模型排序是否被改变"和"离线-线上相关性是否被削弱"。前者影响选型，后者影响整个迭代闭环的可信度。

五、全局时间切分：cutoff该怎么设

GTS的思路很直接：选一个全局时间点T作为cutoff，T之前的交互进训练，T之后的进测试。这样训练集的所有行为在时间上都早于测试集，时间边界单调一致。但"选一个T"说起来简单，做起来有一堆坑。本节给出可操作的设定路径。

5.1 第一原则：cutoff必须对齐线上决策时点

cutoff不是随便取个80%分位就完事。它应该对应一个真实的业务决策时点：模型在某天上线，上线时刻能拿到的数据就是训练数据，上线之后产生的数据才是测试数据。因此cutoff的选择应当由"模型多久重训一次""特征回溯窗口多长""数据管道延迟多大"共同决定。如果模型每天重训、特征用T-1的数据，那么cutoff就应该设在测试期开始的前一天，且训练集的特征计算必须严格使用cutoff之前的数据。

本文评述：把cutoff理解为"模拟上线时刻"是最不容易出错的思维模型。你可以问自己：如果我在T时刻把模型推上线，它当时能看到哪些数据？答案就是训练集的上界。

5.2 第二原则：给"最近行为"留出训练空间

这是用户问题里点出的关键矛盾：如果cutoff设得太靠后（比如95%分位），测试期很短，评估方差大；如果设得太靠前（比如60%分位），最近的大量行为被划进测试集，训练集就"看不到近期趋势"，模型上线后面对的是它没学过的分布。两种极端都不可取。

实践中常用的折中是"训练-验证-测试"三段式：cutoff1之前训练，cutoff1到cutoff2验证（用于调参和早停），cutoff2之后测试。三段的比例不必是固定的6:2:2，而应根据业务周期调整——如果业务有明显的周周期，测试段至少覆盖一个完整周；如果有月度促销，测试段应覆盖一次促销。业界公开的技术分享中（如Airbnb、Netflix、美团等团队关于离线评估的工程文章），普遍强调测试窗口要覆盖至少一个完整的业务周期，这一点值得借鉴。

5.3 第三原则：cutoff之后的新用户与新物品要单独处理

GTS会自然产生一批"测试期才出现"的用户和物品。它们不能进训练集（否则就是标签侧泄漏），但也不能简单丢弃（否则测试集就只剩老用户老物品，评估结果偏乐观）。正确的做法是把它们作为冷启动子集单独评估，报告"整体指标"和"冷启动子集指标"两组数字。这样既保证了时间边界干净，又能观测模型在新分布上的表现。

5.4 操作步骤：一份可直接执行的cutoff设定流程

1. 统计全量交互的时间分布，画出日粒度交互量曲线，识别业务周期与异常脉冲（促销、故障）。
2. 确定模型重训频率与特征回溯窗口，倒推出"上线时刻可见数据"的最晚时间戳。
3. 在时间轴上选cutoff2（测试起点），确保测试段覆盖至少一个完整业务周期，且不跨越数据管道重大变更。
4. 在cutoff2之前再选cutoff1（验证起点），验证段长度建议为测试段的1~2倍，用于调参与早停。
5. 用cutoff1、cutoff2把数据切成三段，检查每段的用户数、物品数、交互量是否满足最小样本要求。
6. 对训练段做特征-标签时间单调性审计，确保所有特征只依赖cutoff1之前的交互。
7. 把测试段中首次出现的用户/物品标记为冷启动子集，单独报告指标。
8. 固定这套切分，作为后续所有模型对比的基准协议，避免"换模型就换切分"的隐性作弊。

六、多cutoff滚动评估与冷启动补偿

6.1 单cutoff的局限

单一切分只能回答"在某个时间点上模型表现如何"，无法回答"模型表现随时间是否稳定"。推荐系统的数据分布漂移是常态，一个在2023年Q4表现优秀的模型，可能在2024年Q2因为用户兴趣迁移而退化。单cutoff评估对漂移完全不敏感。

6.2 滚动时间窗：把评估变成时间序列

滚动评估的做法是：设定多个cutoff（如每月一个），每个cutoff做一次训练-测试，得到一条指标时间序列。这条序列的均值反映平均表现，方差反映稳定性，趋势反映模型对漂移的适应能力。工程上可以用"扩展窗口"（训练集随cutoff前移而增长）或"滑动窗口"（训练集固定长度）两种方式。扩展窗口更接近"数据越积越多"的真实场景，滑动窗口更适合"只关心近期分布"的场景。

本文评述：滚动评估的代价是训练成本乘以cutoff数量，对于大模型不现实。折中方案是"全量滚动+抽样滚动"：用轻量模型做全量滚动监测漂移，用重模型在少数关键cutoff上做精细评估。这与持续评估（continuous evaluation）的工程思想一致。

6.3 冷启动补偿：让近期行为"合法地"进入训练

回到用户的核心疑问：GTS会不会把最近行为全部排除在训练之外？答案是——如果cutoff设得合理，不会"全部"排除，但确实会排除cutoff之后的近期行为。要缓解"模型学不到最新趋势"的问题，有三条合法路径：

• 时间衰减加权：在训练段内部，对越接近cutoff的样本给越高权重，让模型更关注近期模式，同时不越界。
• 增量/在线学习：把cutoff之后的数据用于模型的热更新（如在线学习、近线更新），但这部分更新必须在评估协议中明确标注，不能混入"离线训练"。
• 特征侧的近期统计：允许特征使用截至预测时刻的近期统计（这是合法的，因为线上也能拿到），但要严格保证统计窗口不跨越标签时间戳。

需要强调的是，这三条路径都建立在"时间边界一致"的前提下。时间衰减加权不改变边界，增量学习明确区分了离线与在线，特征侧统计遵守point-in-time原则。它们不是对GTS的"打补丁"，而是GTS框架内的合法优化。

七、工程落地：一份可执行的检查清单

理论讲完，落到工程。下面这份清单可以直接贴到团队的评估规范文档里，作为上线前的自检项。

7.1 数据层检查

• 所有交互记录是否有可靠的时间戳？时区是否统一？是否存在回填、补录导致的时间戳失真？
• 训练集的最大时间戳是否严格小于测试集的最小时间戳？用一条SQL就能验证。
• 物品/用户的首次出现时间是否已登记？测试期新出现的实体是否已隔离？

7.2 特征层检查

• 每个特征是否有明确的"计算窗口"定义？窗口右端点是否不超过标签时间戳？
• 是否存在"累计全量"类特征？如果有，是否在训练时按cutoff做了截断？
• 特征平台是否支持point-in-time join？如果不支持，是否用离线快照模拟？

7.3 评估层检查

• 测试集候选集的构造方式是否与线上召回-排序链路一致？
• 是否报告了冷启动子集的单独指标？
• 是否做了多cutoff的稳定性检验？指标方差是否在可接受范围？
• 离线指标的提升是否与历史线上A/B的方向一致？如果不一致，优先怀疑评估协议。

7.4 一个最小可复现的代码骨架

import pandas as pd

# 假设 df 含 user_id, item_id, ts
df = df.sort_values('ts')

# 1) 选 cutoff（示例：按分位数，实际应按业务周期调整）
cutoff1 = df['ts'].quantile(0.70)
cutoff2 = df['ts'].quantile(0.85)

train = df[df['ts'] < cutoff1]
valid = df[(df['ts'] >= cutoff1) & (df['ts'] < cutoff2)]
test  = df[df['ts'] >= cutoff2]

# 2) 时间边界单调性断言
assert train['ts'].max() < test['ts'].min()

# 3) 冷启动子集标记
seen_users = set(train['user_id'])
seen_items = set(train['item_id'])
test_cold = test[~test['user_id'].isin(seen_users) |
                 ~test['item_id'].isin(seen_items)]
test_warm = test[test['user_id'].isin(seen_users) &
                 test['item_id'].isin(seen_items)]

# 4) 特征侧：所有统计窗口右端点 <= 标签时间戳
#    建议用特征平台做 point-in-time join，避免手写窗口出错

这段骨架只演示了切分与断言，真正的工程实现还需要接入特征平台、负采样器、指标计算模块。但它的价值在于把"时间边界单调性"变成了一个可执行的assert——任何一次数据管道变更，只要这个assert挂了，就说明切分出了问题。

八、前沿预判与开放问题

8.1 从"切分"到"因果"：评估协议的理论化

近年推荐系统评估的研究正在从"经验性切分"走向"因果化表述"。把训练/测试切分看作一次干预（intervention），把模型在测试集上的表现看作潜在结果（potential outcome），可以用因果推断的语言严格定义"什么是泄漏"：泄漏就是训练阶段的信息集包含了测试阶段干预之后的信息。这一视角与本文的"时间边界一致性"主线是同一件事的两种表述。笔者认为，未来几年离线评估的规范化，很可能会沿着"信息集显式化"的方向走——每个评估协议都要声明它在每个时刻可见的信息集，就像特征平台声明point-in-time一样。

8.2 大模型时代的评估挑战

基于大语言模型的推荐（LLM4Rec）给评估带来了新问题。LLM的预训练语料本身可能包含测试期的公开信息，这使得"时间边界"在模型层面就已经被打破——你无法保证模型的参数里没有测试期的知识。这对GTS提出了更高要求：不仅要切分数据，还要审计模型的知识边界。目前这仍是一个开放问题，公开的解决方案有限，工程上能做的是尽量使用与预训练语料时间窗错开的测试期，并明确声明这一局限。

8.3 离线-线上相关性：终极检验

无论切分方案多精巧，最终的检验标准只有一个：离线指标的提升能否预测线上A/B的提升。业界公开的讨论中，离线-线上相关性弱是一个普遍痛点。时间泄漏是削弱这一相关性的重要原因之一——泄漏让离线指标虚高，虚高的部分在线上无法兑现，相关性自然被稀释。因此，修好时间边界不仅是"让离线更准"，更是"让离线更有用"。

九、结语

回到最初的问题：LOO为什么构成时间泄漏？因为它在全局时间轴上构造了一条不单调的边界，让训练集混入了测试期的未来信息，而这条信息会通过全局特征、全局物品池、评估难度分布三条路径污染结果。GTS该怎么设cutoff？核心是三原则——对齐线上决策时点、给近期行为留出合法训练空间、把cutoff后的新实体隔离为冷启动子集；再加一套多cutoff滚动评估来监测漂移。

笔者认为，这场讨论的真正价值不在于"LOO该不该用"，而在于它逼着我们回答一个更根本的问题：你的离线评估，到底在模拟哪个时刻的哪个决策？想清楚这个问题，切分方案自然就出来了。想不清楚，换多少种切分都只是换个地方踩坑。