训练集、验证集、测试集：AI 数据泄漏为什么让分数虚高

一个售后工单模型，在测试中总能准确找出最终会退款的订单，上线后却突然失灵。检查发现，训练表格里有一列“结案原因”。对历史记录来说，这列普通得不能再普通；对刚收到新工单的模型来说，它却相当于提前看到了答案。

这就是数据泄漏容易迷惑人的地方：代码可以正常运行，指标可以计算得非常规范，但评估使用的信息边界已经错了。测试分数测到的，可能是系统在偷看线索后的表现，而不是它在真实工作时的能力。

判断一条信息能不能使用，不能只问“数据库里有没有”，还要问“做出这次预测的那一刻，实际能不能得到”。

一、三类数据分别承担什么任务

训练集用于学习规律，验证集用于选择方案，测试集用于在方案基本确定后进行相对独立的检验。把它们理解成练习题、调试题和最终检验题，比背诵一个固定划分比例更重要。

“训练八成、测试两成”不是放之四海而皆准的答案。数据量、类别稀缺程度、任务的时间属性和实体关系，都会影响划分方式。一个比例看上去很标准的拆分，也可能把同一张工单的不同记录放到了两边。

验证集也不是永久中立的裁判。团队比较了几十种方案，最后选中的版本往往已经适应了这批验证题。因此，报告成绩时要说明是开发过程中的验证结果，还是方案确定后的独立测试结果。

二、最直观的泄漏：输入里藏着未来

设想我们要在“工单刚进入系统时”，预测它之后是否需要升级到人工专员。下面仍是教学案例，不涉及真实客户数据，也不报告虚构的实验成绩。

这里最隐蔽的是统计字段。团队可能删掉了明显的“最终状态”，却保留了根据完整历史计算的用户画像、累计次数或风险分。字段名称不一定带有答案，但计算它的数据可能来自预测之后。

检查时应追到每个特征的来源：原始记录何时发生、何时写入系统、聚合窗口怎样定义、回填是否覆盖了旧值。仅仅把数据按创建日期排序，并不能自动阻止后来补写的信息进入早期样本。

scikit-learn 的常见陷阱文档把这类边界问题归入数据泄漏，并提醒它会导致过于乐观的评估。实践中，最有效的检查往往是一句具体追问：“当时的系统真的能拿到这一列吗？”

三、随机拆行之前，先确定独立单位

假设一位用户提交了一次问题，客服补充两次，系统又导出了一个总结。表格里出现四行，不意味着出现了四个独立案例。随机拆行可能让训练集拿到原文，测试集拿到同一事件的总结。

文本去重也不能只比较字符串是否完全相同。改写、翻译、截短和格式调整都可能留下几乎同一份信息。为了扩大数据而生成的多个版本，应当保留源样本标识，再按源样本整体分配。

该按用户、工单、设备还是公司分组，取决于你究竟想回答什么问题。如果上线需要处理“从未见过的新客户”，评估中就应避免同一客户同时进入训练与测试；如果上线主要处理已有客户的新事件，设计又会不同，但仍要阻断事件本身的重复。

不存在脱离业务目标的最佳拆分。真正需要对齐的是：测试样本与训练样本之间允许存在怎样的关系，是否与未来使用场景一致。把同一用户隔离出去可以检验跨用户泛化，却不能自动证明模型适应了未来的产品政策变化。

scikit-learn 的交叉验证文档提供了分组划分与时间序列划分等工具。工具负责执行约束，团队仍需先确定哪些记录必须同组，以及测试应代表哪一种未知情况。

四、面向未来预测时，时间顺序是关键

如果任务是预测下个月的工单，随机把全年数据混在一起再划分，可能让训练过程接触到后期才出现的产品名称、政策和用户行为。这样的测试更像“补全同一时期的缺失记录”，未必代表真正的向前预测。

一种合理的起点是：较早时间段用于训练，之后一段用于验证，再后面一段用于测试。团队还可以设置多个滚动窗口，观察方案在不同时间阶段是否稳定，而不是只挑一个最顺利的月份。

不过，按时间分开只是起点。工单是否升级，可能需要等到提交后一段时间才能确认。如果训练数据截止日已经确定，但某些训练标签还借用了截止日之后的处理结果，就要重新检查标签成熟时间以及评估时的可用信息。

必要时，在相邻时间窗口之间留出间隔，让同一事件的延续记录和尚未成熟的标签不至于跨界。间隔多长应依据业务处理周期来定，不是随意填写一个天数就完成防护。

也不要反过来认为随机划分永远错误。若目标是对同一稳定总体中的独立样本做预测，随机划分可能完全合理。需要避免的是：使用一种方便的拆分方式，却声称自己验证了另一种更困难的现实任务。

五、预处理也会学习，必须放进正确边界

很多泄漏不发生在模型本身，而发生在模型之前。例如先用全部数据计算缺失值的填充值，再拆训练和测试；或者先根据全部标签挑出最有区分度的特征，再报告测试成绩。测试信息已经参与了方案构建。

凡是需要从数据中估计的步骤，都要检查它在哪一部分数据上拟合。常见例子包括均值填充、标准化、特征选择，以及依赖样本分布的转换。正确边界通常是：在训练部分学习规则，再把已经确定的规则应用到验证与测试部分。

如果进行了交叉验证，这个过程还要在每一折内部重做。不能先对全部开发数据做一次带学习的预处理，再以为后面的交叉验证已经完全独立。流水线工具的价值，就在于把这些拟合步骤与训练范围一起管理。

与此同时，不必把所有清洗都视为泄漏。事先确定、无需观察样本分布或标签的格式转换，与利用全量数据挑特征不是同一回事。关键不是函数名字里有没有“清洗”，而是它是否从本应独立的数据中学到了东西。

少数类过采样、样本增强也应在划分之后谨慎安排。由同一个源样本复制或生成的内容，不能一份用于训练、一份用于检验，再被当成从未见过的新例子。

六、大模型项目也会遇到同一种问题

即使你没有训练模型，只是在调整提示词，也需要考虑评测独立性。把测试题逐个拿出来改提示，直到它们全部答对，再把同一批题的成绩当作最终能力，实际上已经把测试集当成了开发材料。

少样本示例中不小心放入测试问答，或者知识库里混入了一份带标准答案的评测文件，也会改变评估含义。尤其是答案措辞与目标输出高度一致时，应检查系统是在完成任务，还是在复述评测材料。

但也要区分正常检索和泄漏。如果任务本来就是根据一份允许访问的产品手册回答问题，检索到手册中的事实属于预期流程；若任务要求在新案例上推理，却偷偷提供了该案例的标准答案，才越过了原定边界。判断必须回到评测协议。

这里的“数据泄漏”指评估边界被打破，不等同于隐私信息外泄。两者都重要，却需要不同的检查方法：前者关注成绩是否可信，后者关注数据是否被不当访问、传播或使用。

最后：用一份可复查清单守住分数的含义

• 写清预测发生的时刻，以及那一刻系统能获得哪些字段。
• 定义独立样本单位，记录用户、事件与增强样本之间的来源关系。
• 让随机、分组或时间划分与真实使用场景一致，而不是只追求固定比例。
• 检查所有统计特征、预处理和特征选择的拟合范围。
• 记录测试集被查看和使用的次数，避免把反复调试后的成绩包装成独立检验。
• 保留数据快照、划分规则与评测版本，让另一位同事能复现检查过程。

划分正确之后，指标本身也要选择得当。可以继续阅读准确率、精确率、召回率与 F1，理解漏判与误判的不同代价。一个不那么漂亮但边界清楚的成绩，通常比一张无法说明信息来源的高分表更有决策价值。

本文为「读懂 AI」原创科普，售后工单与字段示例为教学构造，不包含真实客户数据。具体拆分方案需根据任务目标、数据依赖关系和可用信息确定。

配图来自 Unsplash：Campaign Creators、Eric Rothermel、Shekinah Togonon；照片用于辅助阅读。