临床预测模型里的数据集划分：诚实模拟未来使用场景

在机器学习文章里，我们经常看到三个词：训练集（training set）、验证集（validation set）和测试集（test set）。

很多临床医生第一次接触机器学习时，会自然地以为：
一个模型研究是不是都应该把数据分成三份？
是不是只要有 training、validation、test，就说明研究很规范？

其实不一定。

临床预测模型研究里，真正重要的不是机械地切出几个数据集，而是：

模型开发过程和模型评价过程是否被清楚分开；验证方式是否能诚实估计模型在目标临床场景中的表现。

这句话听起来有点抽象，下面慢慢解读。

1. 训练集、验证集、测试集分别做什么？

这三个词在机器学习里经常混用，但严谨地说，它们的角色不同。

1.1 Training set：模型真正学习的地方

训练集是模型用来学习规律的数据。

比如用训练集训练：

logistic regression
random forest
XGBoost
neural network
Cox model

模型的参数主要是在训练集里学出来的。

1.2 Validation set：模型开发过程中的“选择题”

验证集不是最终考试，而是模型开发过程中的“模拟考”。

它常用于：

选择模型类型
调整 hyperparameters
选择 predictors
选择 probability threshold
early stopping
feature selection
feature engineering
calibration 方法选择

所以 validation set 虽然没有直接参与训练模型参数，但它参与了模型决策。

1.3 Test set：最终报告模型表现的地方

测试集应该在模型完全确定之后才使用。

最终模型确定后，才在 test set 上报告：

AUC / C-statistic
calibration plot
calibration slope
Brier score
decision curve analysis
sensitivity / specificity
PPV / NPV
net benefit

test set 不应该用来：

选模型
调参
选变量
改 outcome 定义
改 cohort 定义
改 threshold
改 preprocessing
改 imputation 方法

如果看了 test set 表现后觉得“不够好”，然后回头修改模型，再重新在 test set 上评价，那么这个 test set 也被“用脏”了。

这时它已经不再是独立测试集，而变成了另一个 validation set。

2. 为什么 validation set 会被“用脏”？

所谓“用脏”，不是说数据本身坏了，而是说：

这个 validation set 已经被反复用来做模型决策，因此它不再像一个完全独立的新数据集。

举个简单例子。

有三个模型：

Model A: logistic regression
Model B: random forest
Model C: XGBoost

在 validation set 上测试：

于是选择 Model C。

然后又觉得 XGBoost 还能继续调参，于是反复尝试：

max_depth = 3, 4, 5, 6
learning_rate = 0.01, 0.05, 0.1
n_estimators = 100, 300, 500

每次都看 validation set 表现，最后选了 validation AUC 最高的组合。

这时问题就出现了：
选出来的模型不仅学到了 training set 的规律，也间接迎合了 validation set 的偶然特点。

所以 validation performance 会偏乐观。

可以用一个考试比喻理解：

validation set 像反复使用的模拟题。
题做得越来越好，不一定代表真的掌握了知识，也可能只是越来越熟悉这套题的“脾气”。
test set 才应该像最后一次从未见过的正式考试。

3. 每个研究都必须有 training、validation、test 三个集吗？

不一定。

不是每个临床预测模型研究都必须机械分成三份。

这取决于：

样本量
outcome events 数量
模型类型
研究目标
是否需要调参
是否有外部数据
模型未来使用场景

临床预测模型研究的重点不是“有没有三个集”，而是：

有没有清楚地区分模型开发和模型评价。

4. 常见的数据划分与验证方式

4.1 Training + Test 两个集

这是比较简单的做法。

Training set: develop model
Test set: evaluate final model

但如果在 training set 里还要大量调参、选变量、比较模型，最好在 training set 内部使用 cross-validation 或 bootstrap 完成这些步骤。

否则 test set 容易被不小心用于模型开发。

4.2 Training + Validation + Test 三个集

这是机器学习文章里很常见的结构。

Training: fit model
Validation: tune/select model
Test: final performance

优点是逻辑清楚。

缺点是：样本会被切成三份。对于临床研究，尤其 outcome events 较少时，test set 的性能估计会很不稳定。

比如只有 300 个 outcome events：

training 70% = 210 events
validation 15% = 45 events
test 15% = 45 events

test set 只有 45 个事件时，AUC、calibration、subgroup performance 都可能非常不稳定。

这时候，强行三分未必是最好的选择。

4.3 Training 内部 cross-validation + independent test set

这是更常见也更稳妥的一种方式。

Development data:
  cross-validation / bootstrap for tuning and internal validation

Independent test data:
  final evaluation

这样既能在 development data 内部完成模型选择，又保留一个相对独立的数据集做最终评价。

4.4 Bootstrap internal validation

传统临床预测模型中很常见，尤其适合样本量不大时。

All data used for model development
Bootstrap used to estimate optimism-corrected performance

这种情况下，研究里可能没有单独的 validation set 或 test set，但并不等于“没有验证”。

它做的是 internal validation。

对于回归模型、Cox 模型、小中等样本量预测模型，bootstrap 有时比随便切一个 70/30 更合理。

4.5 Temporal validation

按时间切分数据。

例如：

2018–2022: development
2023–2024: evaluation

这种方式在真实世界数据研究中很有价值，因为它更接近模型未来使用时的场景：

模型是在过去数据中开发出来的，然后用于未来来的患者。

它可以检验：

疾病谱有没有变化
治疗流程有没有变化
编码习惯有没有变化
检查习惯有没有变化
模型是否受到 temporal drift 影响

4.6 Geographic / site external validation

按医院、地区或数据源切分。

例如：

Hospital A/B/C: development
Hospital D: external validation

这种验证方式能回答一个更实际的问题：

这个模型换一家医院还能不能用？

它可以检验：

医院等级差异
患者构成差异
检验设备差异
编码习惯差异
医疗路径差异
数据质量差异

如果模型未来要推广到其他医院，site external validation 比单纯随机切分更有说服力。

5. 不同临床场景，应选择不同验证方式

验证方式不是技术装饰，而是要对应模型的目标使用场景。

应该先问：

这个模型未来要在哪些患者、哪个时间、哪个医院、哪个流程里使用？

然后再选择最能模拟这个未来场景的验证方式。

6. 影像 AI 和 longitudinal EHR 特别要小心 data leakage

临床机器学习研究最容易被忽视的问题之一是 data leakage。

6.1 影像 AI：不要按图片随机切

如果一个患者有多张图片，不能让同一个患者的不同图片同时出现在 training set 和 test set。

错误做法：

按 image 随机切分

正确做法：

按 patient 切分
同一个患者的所有图片只能进入同一个数据集

否则模型可能学到的是某个患者的特征，而不是疾病规律。

6.2 Longitudinal EHR：不要让同一个患者泄漏到多个集合

如果一个患者有多次就诊或多次住院，也要小心。

比如一个患者有 5 次住院记录。
如果前 3 次住院进入 training set，后 2 次住院进入 test set，模型可能会通过患者的稳定特征“认出”这个人。

除非研究设计明确允许这种结构，并且在分析中处理了患者内相关性，否则更稳妥的做法是：

patient-level split
cluster-aware split

7. PROBAST+AI 关心的不是“三个集”，而是偏倚有没有被避免

在临床预测模型研究中，PROBAST+AI 并不是要求每篇文章都必须切成 training、validation、test 三个集。

它更关心的是：

是否避免只看 apparent performance
样本量是否合理
missing / censored data 是否处理合理
如果使用 class imbalance 方法，评价是否在未校正的数据集中完成
如果做了 data splitting，是否避免 data leakage
如果用 resampling，是否重复所有 model development steps
是否适当评价 calibration、discrimination、net benefit

也就是说，重点不是形式上有没有三个数据集，而是：

评价方式是否会让模型性能虚高？
这个验证方式是否
适合研究目的和未来使用场景？

8. 如何理解“诚实估计模型在目标场景中的表现”？

模型不是为了在论文数据里拿高分，而是为了未来在某个真实临床环境中使用。

所以验证方式要尽量回答：

如果这个模型明天在目标场景中使用，它大概会表现如何？

如果未来想在外院使用，却只做了本院随机 split，验证就不够诚实。

如果未来想预测未来患者，却只做了同一时期随机 split，可能低估 temporal drift。

如果未来做影像模型，却按图片而不是按患者 split，性能可能虚高。

如果未来用于长期、多次就诊的 EHR 场景，却没有处理同一患者多条记录之间的相关性，模型表现也可能被高估。

9. 对临床研究者的实用建议

做临床预测模型时，可以按下面几个问题检查自己的数据划分是否合理：

1. 我的模型未来打算用于什么人群？
2. 是同一家医院使用，还是要推广到其他医院？
3. 是用于未来患者，还是只做当前数据中的探索？
4. 是否有足够 outcome events 支持切分数据？
5. validation set 是否参与了模型选择？
6. test set 是否真的没有参与任何模型决策？
7. 是否存在同一患者、同一图片、同一次住院泄漏到不同集合？
8. 是否报告了每个 development/evaluation dataset 的人数和 outcome events？
9. 是否评价了 calibration，而不仅仅是 AUC？
10. 如果只是 internal validation，是否避免夸大临床可用性？

如果研究只是早期探索，可以坦诚地说：

The model showed promising internally validated performance and requires external validation.

不要过度宣称：

This model is ready for clinical deployment.

10. 写在最后

Validation set 会被“用脏”，是因为它参与了模型选择；test set 的价值在于它没有参与模型选择。

而验证方式的选择，本质上是在问：

我现在做的这个验证，能不能模拟模型未来真正会遇到的临床世界？

所以，临床预测模型不能只追求“随机切分后 AUC 很高”。

真正重要的是：

时间是否匹配
医院是否匹配
人群是否匹配
数据源是否匹配
工作流是否匹配
outcome ascertainment 是否可靠
data leakage 是否被避免
calibration 和 clinical utility 是否被评价

机器学习模型不是在表格里得高分就结束了。
它最终要面对的是未来真实世界里的患者、医生、医院和数据系统。