大数据-训练/测试集：异常检测任务里训练集只有正常样本、测试集里混着异常，随机划分会把一部分异常也放进训练集，导致“无监督”变成“有监督的泄漏”——这种场景下划分到底该按标签分层，还是必须模拟“训练时完全没有异常”的部署条件？

一、问题的提出：一次随机划分如何毁掉一次评估

设想一个再普通不过的场景：你手上有 10 万条设备传感器日志，其中约 2% 被标注为异常（故障、入侵、欺诈等）。你打算用无监督异常检测模型（如 Isolation Forest、AutoEncoder、One-Class SVM）来建模。为了评估，你调用了 train_test_split(X, y, test_size=0.3, random_state=42)，训练集 7 万条、测试集 3 万条，然后开始训练。

问题就藏在这一行代码里。随机划分并不区分标签，2% 的异常率会被大致等比例地"摊"到训练集和测试集中——训练集里因此混进了约 1400 条异常样本。如果你在训练时把 y 丢掉、只用 X 去 fit，代码层面确实是"无监督"的，但数据层面模型已经接触过异常样本的分布特征。更糟的是，如果你的模型是半监督或自监督的（例如用训练集正常样本拟合重构误差分布），这些混入的异常会污染"正常性"的基线，让阈值估计失真。

本文评述：很多团队把"训练时不看标签"等同于"无监督"，这是一个概念偷换。无监督的严格定义是训练数据分布与部署时模型可见的数据分布一致，而不是"代码里没传 y"。划分阶段一旦让异常进入训练集，后续无论怎么强调"我没用标签"，泄漏都已经发生。

这类问题在工业界并不罕见。笔者在与多个做设备预测性维护、金融反欺诈、网络入侵检测的团队交流中反复听到类似困惑：离线指标 AUC 0.95，上线后掉到 0.7 出头。排除特征穿越、时间泄漏等因素后，划分方式往往是"隐形元凶"之一。学术界对此也早有警觉，Chandola 等人在综述中明确指出异常检测评估对数据划分高度敏感^[1]；Campos 等人在 2016 年的 JMLR 论文里系统比较了多种无监督方法，并特别强调训练集纯净性对结果的影响^[2]。近三年，随着自监督异常检测（如基于对比学习、掩码重建的方法）兴起，训练集是否含异常对表征学习的影响被进一步放大^[3][4]。

所以问题不是"要不要小心"，而是"到底该怎么切"。这就是本文要回答的核心。

二、泄漏机理剖析：从"见过异常"到指标虚高

2.1 三种泄漏路径

把"随机划分导致异常入训"的后果拆开看，至少有三种独立的泄漏路径，它们叠加起来才造成指标虚高。

路径一：分布泄漏。训练集混入异常后，模型拟合的"正常分布"实际上是"正常+少量异常"的混合分布。对于密度估计类方法（KDE、GMM、Normalizing Flow），这会让正常区域的密度被拉低、异常区域的密度被抬高，决策边界整体偏移。测试时，原本应该被判定为异常的样本，因为训练时"见过类似的"，得分反而没那么极端。

路径二：阈值泄漏。很多工程实现会用训练集上的分数分布来定阈值（例如取 99 分位数）。训练集含异常时，这个分位数会被异常样本"顶高"，阈值定得偏松，测试集上召回率虚高、误报率被低估。更隐蔽的是，如果阈值在含异常的训练集上反复调参，等于用异常信息做了模型选择。

路径三：表征泄漏。自监督/对比学习方法在训练时会学习"什么算相似"。若异常样本参与表征学习，模型可能学到区分正常与异常的隐含特征，尽管没有显式标签，但这已经是一种"弱监督"。Pang 等人 2021 年的综述把这类现象归为"训练目标与评估目标不一致"^[5]。

2.2 一个可复现的量化示意

为了把"虚高"讲清楚，这里给出一个基于公开数据集思路的模拟实验设计（数据为模拟生成，仅用于说明机理，非真实测量）。构造二维数据：正常样本服从均值 (0,0)、协方差为单位阵的高斯分布，共 9500 条；异常样本服从均值 (4,4)、协方差为 1.5 倍单位阵的高斯分布，共 500 条，异常率 5%。用 Isolation Forest（默认参数，n_estimators=100）做检测，比较两种划分：

划分方式	训练集异常数	测试集 AUC（模拟）	测试集 Recall@FPR=5%
随机划分（泄漏）	约 350	0.94	0.81
纯净训练集（仅正常）	0	0.88	0.72
分层划分（按标签等比例）	约 350	0.94	0.81

表格里最值得玩味的是第三行：分层划分（stratified split）在"训练集只应含正常样本"的设定下，与随机划分一样有害。因为分层的目的恰恰是"保证训练集里异常比例与总体一致"，这在分类任务里是对的，在纯净训练集异常检测里是反的。这个反直觉的结论，正是本文要重点澄清的。

本文评述：分层划分不是"更严谨的随机划分"，它有明确的适用前提——训练分布应与评估分布同构。异常检测的部署条件恰恰要求"训练分布 = 纯正常分布"，与总体分布不同构。把分类任务的最佳实践无脑迁移到异常检测，是很多泄漏的源头。

三、两条路线的正面交锋：分层划分 vs 纯净训练集模拟

3.1 支持分层划分的理由，以及它们为何站不住脚

支持在异常检测里用分层划分的观点通常有三条：其一，分层能保证训练/测试的类别比例一致，评估更稳定；其二，现实数据无法保证训练集绝对纯净，分层更贴近"真实噪声"；其三，分层便于做交叉验证和超参搜索。这三条在分类语境下都成立，但放到"训练集只应含正常样本"的异常检测里，需要逐条审视。

第一条的问题在于混淆了"评估稳定性"和"训练纯净性"。评估稳定性应该靠测试集的充分采样和多次重复评估来解决，而不是靠往训练集里塞异常。用污染训练集换取评估方差下降，是拿偏差换方差，得不偿失。

第二条有一定现实合理性。工业场景里"正常"数据往往夹带未标注的异常（label noise），完全纯净的训练集是理想化的。但正确的应对是在纯净假设下建模，再单独评估噪声鲁棒性，而不是一开始就把异常当正常喂进去。Goldstein 与 Uchida 在 2016 年的对比研究里就指出，训练集污染对密度估计类方法的伤害远大于对基于重构的方法^[6]。

第三条是工程便利性诉求，可以用"分层仅用于测试集内部划分"来满足——即在已经切出的测试集内部做分层，保证测试集异常比例可控，而不影响训练集纯净性。

3.2 纯净训练集模拟的代价与误区

另一条路线是严格模拟部署条件：训练集只放正常样本，测试集按真实异常率混入异常。这条路线的理论依据很硬——它直接对应"模型上线时只能看到正常数据"的现实。但它也有代价：

• 正常样本量要求高。剥离异常后训练集变小，对深度模型不友好。实践中常用"正常样本内部再划分"（如 80% 拟合、20% 做内部验证）来缓解。
• 无法直接做监督式超参搜索。没有异常标签参与训练，超参只能靠内部验证集上的无监督指标（如重构误差稳定性）或少量带标签的验证集来选。
• 测试集异常率的人为设定会扭曲指标。若测试集异常率远高于真实部署，Precision 会被系统性低估。这一点在 Kim 等人 2022 年的评估方法论文里有专门讨论^[7]。

常见误区是把"纯净训练集"理解成"把异常全删了就行"。实际上还要处理：正常样本内部的时间/设备/批次分布是否与测试一致（否则是另一种泄漏）、特征工程是否用了全量数据统计量（标准化参数、编码器都应在训练集上 fit）。这些细节在第六、七节展开。

四、部署条件对齐：本文的分析主线与决策框架

4.1 主线：先问"上线时能看到什么"

本文提出的贯穿主线是"部署条件对齐"（Deployment-Condition Alignment）：划分策略的唯一合法性来源，是它能否忠实复现模型上线时所面对的数据条件。这条主线可以拆成三个必答问题：

1. 上线时训练数据里有没有异常？如果训练阶段确实只能拿到正常数据（冷启动、新设备、新业务线），那训练集必须纯净，任何含异常的划分都是自欺。
2. 上线后模型是否持续更新？如果是在线学习/持续训练，训练集会逐渐混入被判定为正常的样本，此时要模拟的是"渐进污染"而非一次性纯净。
3. 评估的目标是"能力上限"还是"部署预期"？前者可以用含异常训练集做上限探测，后者必须用纯净训练集。两者不能混在一张表里报告。

这三个问题回答完，划分方案基本就定了。笔者把它整理成一个决策框架，见下表。

部署场景	训练集是否含异常	推荐划分	评估重点
冷启动/新设备	否（纯净）	按时间/实体切分，训练集仅正常	部署预期指标
有少量历史异常标签	否（异常留作验证/测试）	纯净训练 + 带标签验证集	阈值选择 + 预期指标
持续学习/在线更新	渐进混入	时间序切分 + 污染比例扫描	鲁棒性衰减曲线
研究/上限探测	可含异常	分层划分（明确标注为上限实验）	能力上限，不与部署指标混报

4.2 为什么"按标签分层"在多数异常检测场景是错的

把上表读一遍就能看出，分层划分只在最后一行"研究/上限探测"里有位置，而且必须显式标注。原因在于分层划分的数学假设是"训练集与测试集同分布"，而异常检测的部署假设是"训练集是测试分布的一个子集（仅正常部分）"。这两个假设互斥。

更细一点说，分层划分优化的是"训练集类别比例的代表性"，而异常检测关心的是"正常性基线的纯度"。前者是分类任务的评估需求，后者是异常检测的建模需求。把前者套到后者身上，等于用评估需求污染建模需求。这不是参数选择问题，是目标函数错位。

本文评述：有一种折中说法是"分层划分但训练时丢掉异常样本"，即先分层切、再把训练集里的异常删掉。这看似两全，实则浪费——被删掉的异常本可以放进测试集增强评估。正确做法是"先按部署条件切出纯净训练集，剩余数据（含异常）再按需分层进测试/验证"。顺序反了，信息就浪费了。

五、可落地的划分流程与代码骨架

5.1 五步划分流程

下面这套流程适用于绝大多数"训练集应纯净"的异常检测项目，按顺序执行即可。

第一步：确定切分维度。优先按时间切（避免未来信息泄漏），其次按实体切（设备、用户、门店），最后才考虑随机切。时间切分是工业与金融场景的默认选项，因为部署时模型只能看到过去。

第二步：先切出测试集，且测试集保留异常。测试集应覆盖部署时可能遇到的异常类型与比例。若异常类型多样，测试集内部可按异常子类分层，保证每类都有样本。

第三步：从剩余数据中剥离异常，得到纯净训练池。这一步是"模拟部署条件"的核心。剥离出的异常不要丢，转入验证集或测试集。

第四步：在纯净训练池内部再切"拟合集/内部验证集"。内部验证集用于无监督超参选择（如重构误差的稳定性、阈值分位数），不参与最终评估。

第五步：锁定协议，做污染压力测试。主协议固定后，另起一组实验，向训练集注入 0.5%、1%、2%、5% 的异常，观察指标衰减。这组实验单独报告，不混入主表。

5.2 代码骨架（Python / scikit-learn 风格）

import numpy as np
from sklearn.model_selection import train_test_split

def deployment_aligned_split(X, y, time_idx=None,
                             test_size=0.3, val_size=0.15,
                             random_state=42):
    """
    部署条件对齐的划分：
    1) 先切测试集（保留异常）
    2) 剩余数据剥离异常 -> 纯净训练池
    3) 纯净池内再切拟合/内部验证
    返回: X_fit, X_val, X_test, y_test
    """
    n = len(X)
    if time_idx is not None:
        # 按时间切：前 70% 训练池，后 30% 测试
        order = np.argsort(time_idx)
        cut = int(n * (1 - test_size))
        pool_idx, test_idx = order[:cut], order[cut:]
    else:
        pool_idx, test_idx = train_test_split(
            np.arange(n), test_size=test_size,
            random_state=random_state, stratify=y)

    X_pool, y_pool = X[pool_idx], y[pool_idx]
    X_test, y_test = X[test_idx], y[test_idx]

    # 关键：训练池只保留正常样本
    normal_mask = (y_pool == 0)
    X_normal = X_pool[normal_mask]

    # 纯净池内部再切拟合/验证
    X_fit, X_val = train_test_split(
        X_normal, test_size=val_size,
        random_state=random_state)

    return X_fit, X_val, X_test, y_test

# 污染压力测试（单独实验，不混入主协议）
def inject_contamination(X_fit, X_anom, ratio):
    k = int(len(X_fit) * ratio / (1 - ratio))
    idx = np.random.RandomState(0).choice(
        len(X_anom), size=k, replace=False)
    return np.vstack([X_fit, X_anom[idx]])

这段骨架的关键不在代码本身，而在两个设计决定：测试集先切、训练池后净化。先切测试集保证评估数据不被训练过程"看见"；后净化保证训练池纯度。顺序反了（先净化再切）会导致测试集异常比例不可控。

5.3 特征工程也要"只 fit 训练集"

划分干净了，特征工程仍可能泄漏。标准化用的均值方差、类别编码的目标统计量、PCA 的主成分、甚至缺失值填充的中位数，都必须在纯净训练集上 fit，再 transform 到验证/测试集。这一点在 scikit-learn 的 Pipeline 文档里有标准做法^[8]，但异常检测项目常因"图省事"在全量数据上 fit，造成二次泄漏。

推荐阅读与拓展：scikit-learn 官方 Common pitfalls 文档 对数据泄漏有系统说明；YouTube 上 StatQuest 的 "Machine Learning Fundamentals: Cross Validation" 视频对划分逻辑讲得很直观，适合团队内训。

六、评估协议设计：指标、阈值与置信区间

6.1 指标选择：别只看 AUC

AUC-ROC 在异常检测里被滥用。它对类别不平衡不敏感，且不反映阈值选择。部署时真正关心的是"在可接受的误报率下能抓多少异常"，所以 PR-AUC、Recall@FPR、以及固定误报预算下的 Precision 更贴近工程。Saito 与 Rehmsmeier 2015 年的论文系统论证了不平衡场景下 PR 曲线优于 ROC 曲线^[9]，这一结论在近年的异常检测评估研究里被反复引用^[10][11]。

指标	适用场景	局限
AUC-ROC	快速对比、类别较均衡	不平衡时偏乐观
PR-AUC	异常率低（<5%）	对异常率设定敏感
Recall@FPR=1%/5%	有明确误报预算的部署	需足够测试样本估计
平均精度 AP	多异常类型综合评估	类型极不均衡时失真

6.2 阈值必须在"纯净 + 带标签"的验证集上定

阈值选择是泄漏高发区。正确做法是：用纯净训练集拟合模型，用一份独立的、带标签的验证集选阈值，最后在测试集上一次性评估。验证集可以含异常（因为定阈值本来就需要知道异常长什么样），但它不能参与模型拟合，也不能被反复用到过拟合。

如果项目早期完全没有异常标签，只能用训练集分数分位数定阈值（如 99%），此时必须承认"阈值未经验证"，并在报告中标注。等积累到第一批真实异常后，再回补验证。

6.3 置信区间与重复评估

异常样本少，指标方差大。建议用 bootstrap 重采样测试集，报告指标的 95% 置信区间；若做了多次随机划分，报告均值±标准差。近年的评估方法学研究强调，异常检测论文应报告不确定性，否则不同方法间的微小差异可能只是噪声^[12][13]。

七、数据集与预处理细节：以真实公开数据集为例

7.1 三个常用公开数据集及其划分注意点

ODDS（Outlier Detection DataSets）。由 Stony Brook 团队维护的异常检测基准集合，含多个子集（如 cardio、thyroid、satellite 等）。使用时注意：部分子集本身是"正常类 vs 其他类"的二分类改造，异常比例差异极大（从 1% 到 30% 不等）。预处理建议：按原始标签剥离异常得到纯净训练池；对高维子集先做方差过滤再标准化（标准化参数仅在训练池 fit）。官方地址：http://odds.cs.stonybrook.edu/。

ADBench。2022 年 NeurIPS 数据集与基准 track 的工作，整合了 57 个数据集、30 余种算法，统一了评估协议^[14]。它的价值在于提供了"训练集纯净、测试集含异常"的标准切分，可直接复用其划分脚本，避免自己踩坑。预处理细节在其 GitHub 仓库有说明：缺失值用中位数填充、类别特征做 one-hot、数值特征做标准化，均在训练集上 fit。

MVTec AD。工业视觉异常检测的经典基准，15 个类别、共 5354 张图像，训练集仅正常样本、测试集含各类缺陷^[15]。它的划分天然符合部署条件，是"纯净训练集"理念的教科书式体现。预处理：统一 resize 到 256×256 后中心裁剪 224×224，ImageNet 均值方差标准化（注意：严格来说应在本数据集训练集上重算均值方差，但工业界普遍沿用 ImageNet 统计量，需在报告中注明）。

7.2 预处理清单（可直接抄）

• 缺失值：训练池中位数/众数填充，transform 到验证/测试。
• 标准化：StandardScaler 仅在训练池 fit；若特征长尾，先 log1p 再标准化。
• 类别编码：One-Hot 或目标编码（目标编码的统计量必须用训练池计算，且做平滑）。
• 时间特征：避免用"未来窗口"的聚合统计；滑窗特征要保证窗口右端点不超过当前时刻。
• 异常剥离：按标签剥离后，检查剥离前后正常样本的特征分布是否漂移（KS 检验或 PSI），漂移过大说明标签质量有问题。

本文评述：预处理里最容易被忽略的是"剥离异常后分布漂移"。如果异常集中在某些设备/时段，剥离后正常样本的分布会与总体正常分布不同，模型学到的"正常"就有偏。建议剥离后做一次分布对比，必要时按设备/时段做分层抽样，保证训练池覆盖部署时的正常工况。

八、工程实践中的常见坑与规避清单

8.1 八个高频坑

坑一：先划分后清洗。先去重、先异常剔除、先做全量统计，再划分——清洗阶段已经用了测试集信息。正确顺序是"先划分，再在训练池内清洗"。

坑二：用全量数据做特征选择。方差过滤、互信息、PCA 都算特征选择，必须在训练池上做。

坑三：时间序列随机切。随机切会让"未来"进入训练集，是比标签泄漏更严重的时序泄漏。

坑四：同一实体跨集。同一台设备的数据同时出现在训练和测试，模型可能记住设备指纹而非异常模式。按实体切分可解。

坑五：测试集异常率失真。测试集异常率远高于部署真实率，Precision 被低估、Recall 被高估。报告时注明测试集异常率，并给出按真实率重加权后的指标。

坑六：阈值在测试集上调。这是最赤裸的泄漏，但仍有团队为了"指标好看"反复调阈值。测试集只能用一次。

坑七：忽略标签噪声。所谓"异常"标签可能本身有错。建议对异常样本做置信度复核，低置信度的移出测试集或单列。

坑八：只报一个随机种子。异常样本少，单次划分的指标波动可能达 ±0.05。至少跑 5 个种子，报均值±标准差。

8.2 团队协作层面的建议

划分协议应写进项目的"评估契约"文档，明确：切分维度、训练池纯度要求、测试集异常率、阈值选择数据源、指标与置信区间。新成员接手时先读契约再动代码。这件事听起来官僚，但笔者见过太多"换个人重跑一遍指标就变了"的案例，根因都是协议没固化。

拓展资源：PyOD 官方文档的 Evaluation 章节 给出了异常检测评估的推荐做法；ADBench 的 GitHub 仓库 有完整的数据划分与预处理脚本，可直接对照。

九、前沿学术预判：从"划分"到"协议即产品"

9.1 三条值得关注的研究线索

线索一：评估协议标准化。ADBench 之后，社区对"统一划分、统一指标"的呼声越来越高。2023—2024 年出现了一批聚焦评估方法的工作，讨论如何在不平衡、少异常、多模态条件下给出可信指标^[16][17]。笔者判断，未来两年"评估协议"会像当年的"可复现性 checklist"一样，成为论文与工业方案的标准附件。

线索二：污染鲁棒性作为一等公民。既然真实数据难纯净，与其假装纯净，不如显式建模污染。近三年有多篇工作研究"训练集含未知比例异常"时的鲁棒检测^[18][19]，思路包括鲁棒损失、异常加权、以及基于分布偏移的样本重加权。笔者认为，这类方法的价值不在替代纯净训练，而在提供"污染下的退化曲线"，帮助团队做数据治理的投入产出判断。

线索三：自监督与基础模型的评估挑战。以重构、对比、掩码预测为代表的自监督方法，其"训练时是否见过异常"的边界更模糊——因为预训练数据往往海量且不可控。2024 年前后，关于"基础模型在异常检测上的零样本/少样本能力"的讨论增多^[20][21]，核心争议正是"预训练数据里是否已含下游异常"。这本质上是划分泄漏在更大尺度上的重演。

9.2 笔者的预判

未来异常检测的竞争，会从"模型结构"转向"评估协议 + 数据治理"。理由很简单：模型层面的边际收益在收窄，而协议层面的错误会系统性放大所有模型的指标。谁能把"部署条件对齐"做成可审计的流水线，谁就能在真实场景里少踩坑。对工程团队而言，这意味着划分脚本、预处理 Pipeline、评估报告模板应当作为基础设施来建设，而不是每个项目重写一遍。

本文评述：需要警惕另一种极端——为了"绝对纯净"而把大量可用数据弃之不用。纯净训练集是建模假设，不是数据越多越好或越少越好。合理做法是在纯净假设下建模，同时用污染压力测试量化"不纯净的代价"，再决定是否值得投入标注资源去净化。这是一个成本—收益问题，不是纯粹的学术洁癖。

十、结语与行动清单

回到最初的问题："划分到底该按标签分层，还是必须模拟训练时完全没有异常的部署条件？"本文的答案是：以部署条件对齐为准绳，主协议用纯净训练集模拟，分层划分仅用于测试集内部或明确标注的上限实验。分层划分不是错，错在把它当成异常检测的默认选项。

给读者的行动清单：

1. 检查现有项目的划分代码，确认训练集是否混入异常；
2. 把"先切测试集、再净化训练池"写进划分脚本；
3. 把标准化、编码、特征选择的 fit 范围限定在训练池；
4. 用 PR-AUC + Recall@FPR 替代单一 AUC；
5. 阈值在独立带标签验证集上定，测试集只用一次；
6. 补一组污染压力测试，报告指标衰减曲线；
7. 把以上写成"评估契约"，纳入代码评审。

数据划分看起来是项目里最不起眼的一步，却决定了后面所有指标的可信度。把它当协议来对待，而不是当一行 train_test_split 来对待，是异常检测工程走向成熟的第一步。

主要参考文献