“The reported AUC may be overly optimistic.” 收到这条意见，先别把随机森林换成 XGBoost。算法未必是问题所在。如果测试集早就参与了选基因，换多少模型，也还是在同一条有泄漏的流程上挑冠军。
最常见的一种情况：先用全部样本做差异分析，选出一批基因，再把样本分为训练集和测试集，最后说测试结果是独立验证。虽然模型拟合时没有直接输入测试标签，但特征名单已经吸收了测试数据的信息。
拿出脚本，从第一行数据处理开始查
| 检查位置 | 危险信号 | 修订方向 |
|---|---|---|
| 患者划分 | 同一患者的多份组织分别进入训练与测试 | 按患者或更合适的独立单位划分 |
| 数据预处理 | 用全部数据学习填补值、缩放参数或降维 | 只在训练部分学习，再应用到留出部分 |
| 特征选择 | 全数据筛基因后再做交叉验证 | 把筛选步骤放进训练折内部 |
| 模型挑选 | 反复查看测试 AUC 来选算法或参数 | 在训练数据内调参，保留未参与选择的评估 |
scikit-learn 官方文档把数据泄漏列为常见陷阱，并建议用 Pipeline 管理需要学习参数的处理步骤。Pipeline 能减少实现错误，但不会替你判断供体划分是否独立，也不会修复在进入 Pipeline 前已经完成的全数据筛选。
重新评估时，先锁定“要评估的流程”
把候选特征、预处理、选择规则、模型和调参范围写清楚。内部交叉验证评估的是整套流程，不只是最后那个分类器。若需要同时调参和估计泛化性能，应评估嵌套交叉验证等与任务相符的设计；分组、时间先后和数据量也会影响划分方式，不能只随手填一个折数。
注意另一种隐藏泄漏：你已经用测试集试了十几套流程，最后决定“从现在开始不再看它”。这个测试集已经参与过选择，不能靠改个名字恢复独立性。应如实交代选择过程，并寻找新的留出数据，或把现有结果重新定位为内部探索。
重算后的 AUC 下降，要不要放进去
要。返修的目的不是守住原来的漂亮数字，而是让指标对应真实评估条件。可以做一张流程差异表，列出旧流程的问题、新流程的修订和新结果的位置。不要继续在摘要里保留旧的最高 AUC，却在方法中描述改过的验证流程。
同时检查类别比例、结局定义和指标用途。高 AUC 不自动意味着某个临床阈值下可用；对风险预测还需要关注校准，对类别不平衡的任务要解释指标选择。仅凭一个数值也不能确认发生了过拟合，流程和数据结构才是核查入口。
We audited the full modeling pipeline and identified [actual issue, or describe the checks if none was found]. We repeated the evaluation with [all learned preprocessing/feature selection] confined to the training partitions and used [independent-unit split]. The updated performance is [actual estimates and uncertainty], reported in [location]. We have replaced the previous figures and revised the interpretation accordingly.
这是可修改的写作框架，不是对你的研究结果的陈述；未完成的工作不得写成已完成。
先做一个不用算力的动作：画出“谁在什么时候看到了测试数据”。这张图若画不清楚，先不要继续生成下一张 ROC。
参考与更新
本文的处理步骤为编辑整理的实践建议，需结合研究设计判断；示例不是客户案例，表格不包含虚构实测数据。
云生信 · 审稿与返修系列 · 内容核对日期 2026-10-06。我们会根据方法文档和使用反馈持续修订；欢迎通过官网反馈不准确或不清楚的地方。
