验证集和测试集为何要分开?

训练集、验证集和测试集的区别不在文件名，而在它们是否参与决策。训练集用于拟合参数；验证集用于选择模型、超参数、提示、阈值和停止点；测试集在这些选择冻结后，用来估计最终方案在目标分布上的泛化表现。只要某个集合的结果被用来改方案，它就已经承担了验证集角色。

把验证与测试合并后，团队会在同一批样本上比较许多候选方案并挑最高分者。即使每个指标都有噪声，反复选择也更容易选中偶然偏高的结果，形成乐观的选择偏差。这不是训练loss与验证loss必然同步，也不能用一个固定百分比描述，偏差大小取决于候选数量、数据规模、指标方差和调参方式。

测试集也不是物理意义上只能执行一次。可以为了复现、审计或不同版本报告而重复运行，问题在于不能观察结果后继续改模型、阈值或样本处理，再把同一集合当作无偏测试。如果已经根据测试反馈做了决策，就应明确降级为验证用途，并准备新的独立holdout。

数据划分还要防止实体和时间泄漏。同一用户、患者、文档近重复或未来信息跨集合，会让结果虚高；标准化、特征选择和重采样也只能在训练折拟合。时间场景应按过去训练、较新窗口验证、更晚窗口测试，组相关数据则按实体切分，而不是只做随机抽样。

工程上我会预先写明主要指标、切分键、允许的调参范围和最终报告规则。日常迭代使用验证集；测试结果只在候选冻结后查看；若团队长期迭代，再设置隐藏holdout或滚动新时间窗。指标还要给置信区间，并按关键人群分桶，避免平均分掩盖风险。

这样分开的价值，是让模型选择和泛化声明对应两份不同证据。验证集可以频繁支持决策，测试集保留对决策过程之外数据的估计能力。若业务分布发生变化，则应重新定义评测窗口，而不是继续依赖一个早已被团队反复消费的旧测试集。

当数据很少时，可以使用嵌套交叉验证：内层负责调参，外层估计选择后的性能；但外层结果仍不能反复驱动方案修改。若产品需要持续上线，按时间滚动保留新holdout通常更贴近真实分布。无论采用哪种形式，都要把数据职责和决策日志写清，避免同一集合在流程中悄悄换角色。