一文吃透Scikit-learn模型评估：数据划分、交叉验证与防泄漏

很多人把模型训练完了，跑个accuracy，觉得90%多挺高，就兴冲冲上线。然后过两天业务方找过来：你这模型怎么预测得这么离谱？一看，训练集上表现好得不行，一到真实数据就拉胯。这种场景太常见了，根子上就是评估环节偷了懒。

用Scikit-learn做模型评估，表面上看不过是train_test_split加accuracy_score两行代码的事，但实际操作里全是门道：数据怎么切、切完怎么验证、指标怎么挑、交叉验证怎么配、网格搜索怎么不踩信息泄露的坑……每步选错都可能在最后给你一个大“惊喜”。这篇我把我这些年用Scikit-learn做模型评估的完整思路和踩坑记录梳理一遍，从数据划分到指标选择，从交叉验证到学习曲线诊断，再到嵌套交叉验证和信息泄露的预防，尽量讲透。

1. 模型评估的第一道分水岭：数据划分做得对不对

数据划分是整个模型评估里最容易被低估的一步。很多人觉得不就是train_test_split切一下就行吗？实际上划分方式直接决定了你后面所有评估结果到底可不可信。

1.1 留出法的基础用法与隐藏细节

train_test_split是Scikit-learn里最常用的数据划分工具，但它远不只是“切一刀”那么简单。先看一个日常案例：

python复制from sklearn.model_selection import train_test_split
from sklearn.datasets import load_breast_cancer

data = load_breast_cancer()
X, y = data.data, data.target

# 按7:3划分训练集和测试集
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.3, random_state=42, stratify=y
)

这里面有几个参数值得展开说说。

test_size控制测试集比例，这个比例不是拍脑袋定的。数据量大的时候，比如几万条以上，test_size=0.2就够了，测试集几千条样本算出来的指标已经比较稳定；但数据量只有几百条的时候，你还按0.2切，测试集就几十条，任何在测试集上算出来的指标方差都大得吓人。我之前做过一个只有400条样本的二分类任务，同样的模型换个随机种子，测试集上的准确率能从86%跳到93%，这不是模型变好了，纯粹是测试集太小扛不住波动。小数据集上我更倾向于用交叉验证来替代简单的留出法，这个后面专门讲。

random_state是用来固定随机数的，这个“固定”的价值很多人低估了。不固定的话，每次运行划分结果都不同，模型评估结果也就跟着变，你根本分不清改参数带来的提升到底是真提升了，还是换了份数据碰运气碰出来的。固定了random_state，至少能保证每次实验的数据划分是一致的，模型之间的对比才有意义。

重点说下stratify这个参数，这是最容易忽略又最关键的设置。它的作用是分层抽样，让训练集和测试集里各个类别的比例和原始数据集保持一致。二分类还好，如果遇到极度不平衡的数据，比如正样本只占5%，你不分层直接切，很可能切出来的测试集里一个正样本都没有，那评估个啥？模型预测全返回负类，准确率照样95%，毫无意义。更隐蔽的情况是多分类任务，某个小类别样本数本来就少，随机切分可能训练集里有它，测试集里反而没了，或者反过来，这都会让评估结果失真。

1.2 划分数据前必须规避的泄漏场景

数据泄漏是模型评估里最坑的问题，没有之一。它的本质是：训练过程接触到了“本来不该接触到”的信息，导致评估结果虚高，上线后直接崩掉。

最常见的泄漏场景有三种。

第一种是在划分之前做了特征选择或者数据预处理，比如你先用全部数据做方差分析筛特征，筛完再划分训练集和测试集。问题在于，这个筛选过程利用了测试集的信息，测试集不再是未知数据了，评估结果天然偏高。正确做法是先划分再预处理，所有统计量（均值、方差、分位数这些）只从训练集计算，然后套用到测试集上。Scikit-learn里Pipeline可以帮你把预处理和建模串起来，很容易避免这类问题。

第二种是用了目标信息来构建特征。比如预测用户会不会流失，你把“用户是否发过投诉邮件”作为特征，但投诉邮件往往发生在流失前一周，这种特征在训练集和测试集里都有，模型学到的其实是“投诉过的人会流失”，而不是真正的深层规律。这种泄漏很难被代码层面的检查发现，需要业务上足够敏感。

第三种是重复样本跨集合。比如数据里有重复用户，同一个人既出现在训练集又出现在测试集，模型在训练时“见过”这个人，测试时就相当于开卷考试。处理时可以先按用户ID去重，再做划分。

我自己有个习惯：每次划分完数据，会主动打印训练集和测试集的类别分布做个对比。

python复制print("训练集类别比例:", y_train.mean())
print("测试集类别比例:", y_test.mean())

如果两者差距明显，就说明划分可能有问题，需要回头检查。这个习惯帮我挡住过好几次数据泄漏引发的虚假评估。

2. 分类任务评估指标：准确率的局限与怎么选真正有用的指标

分类模型是Scikit-learn里最主流的场景，但大部分教程讲指标就是准确率、精确率、召回率、F1各来一遍就完了。实际项目里选哪个指标，背后是业务逻辑在决定，而不是数学公式。

2.1 混淆矩阵是所有分类指标的源头

python复制from sklearn.metrics import confusion_matrix, classification_report

y_pred = model.predict(X_test)
cm = confusion_matrix(y_test, y_pred)
print(cm)

混淆矩阵输出的四格（二分类下）分别代表：真正例（TP）、假正例（FP）、假负例（FN）、真负例（TN）。准确率这个指标看起来很直观，但它有个致命弱点——在类别不平衡时毫无区分度。假设10000个样本里只有100个正类，模型全预测成负类，准确率也是99%，看起来模型完美无比，实际上一点用没有。

所以我看任何分类评估结果，第一件事永远是看混淆矩阵的四格分布，而不是先看准确率。这四格才能真正告诉你：模型把哪些东西搞错了，错的方向是往哪偏。

2.2 精确率、召回率与F1的选择逻辑

精确率（Precision）回答的问题是“模型预测为正类的样本里，有多少真的为正类”。召回率（Recall）回答的是“真正的正类里，有多少被模型成功抓住了”。这两个指标天然此消彼长，你不可能同时无限拉高两个。

具体选哪个，完全看业务对错误的容忍程度。举两个对比强烈的例子：

例一：垃圾邮件过滤。 一封正常邮件被误判为垃圾邮件，用户可能从此错过一封重要合作函件，代价很高；而一封垃圾邮件漏网混进收件箱，用户顶多点个“举报”按钮。这个场景下精确率优先级更高，宁可不抓，也别误杀。

例二：癌症筛查。 漏掉一个真正的阳性病人，后面要付出的代价可能是生命。而把健康人误判为疑似阳性，最多是再做一轮检查确认。这个场景下召回率优先级更高，宁可错杀一千，不能放过一个。

实际项目里经常需要在这两者之间做平衡，F1就是调和平均数，把两者综合成一个数字方便对比模型。但F1也有个问题：它对精确率和召回率一视同仁，业务上如果有明显偏向，直接拿F1当唯一标准可能会选错模型。

这时候可以看classification_report的输出，一次把所有关键指标都列出来：

python复制print(classification_report(y_test, y_pred, target_names=['负类', '正类']))

输出里每个类别都有对应的精确率、召回率、F1，还有一个支持度（该类别真实样本数）。多分类场景下尤其方便，一眼就能看出哪个类别被模型“欺负”了——通常是样本少或者特征区分度低的那个类别。

2.3 ROC曲线与AUC：排序能力的度量

准确率、精确率、召回率这些指标都要求模型先给出一个确定的类别预测，然后才能统计。但很多分类模型（尤其是逻辑回归、SVM这些）实际输出的是概率分数，最后一步才根据阈值（默认0.5）判定正负类。

问题来了：阈值为什么必须用0.5？如果你的正类样本本来就很少，0.5的阈值可能太苛刻了；反过来如果误判的成本极低，0.3的阈值可能更合理。ROC曲线和AUC就是用来评估“不依赖具体阈值”的模型排序能力的指标。

python复制from sklearn.metrics import roc_curve, roc_auc_score

y_proba = model.predict_proba(X_test)[:, 1]
fpr, tpr, thresholds = roc_curve(y_test, y_proba)
auc_score = roc_auc_score(y_test, y_proba)
print("AUC:", auc_score)

AUC的含义是：随机抽一个正样本和一个负样本，模型给正样本打分高于负样本的概率。这个解释非常直觉化——它衡量的是模型把真正例排在假正例前面的能力。AUC=0.5代表模型完全是随机猜，AUC=1表示完美排序。

AUC有个好处是它对类别不平衡不那么敏感，而且不依赖阈值选择，所以在很多业务里喜欢用AUC来衡量排序类模型的效果（比如推荐系统、风控里的评分卡）。但注意AUC高不代表模型在业务上可用，两个模型AUC一样，一个在顶部分数段表现更准，另一个在中间分数段更准，对实际业务影响完全不同。所以AUC适合做模型选择的参考，做最终上线决策时还是得回到业务指标上。

3. 回归任务的评估指标：别只盯着R平方

回归模型的评估经常被人敷衍对待，很多人直接跑个r2_score就结束了。R平方虽然直观，但它有很多局限性，如果数据形态不合适，它会给你一个相当误导性的数字。

3.1 常用回归指标与使用边界

Scikit-learn回归评估核心有四个指标：均方误差（MSE）、均方根误差（RMSE）、平均绝对误差（MAE）和R平方（R²）。

python复制from sklearn.metrics import mean_squared_error, mean_absolute_error, r2_score

mse = mean_squared_error(y_test, y_pred)
rmse = mean_squared_error(y_test, y_pred, squared=False)  # Scikit-learn 1.4+ 推荐写法
mae = mean_absolute_error(y_test, y_pred)
r2 = r2_score(y_test, y_pred)

这几个指标的区别我举个例子来说明。假设你预测三个样本，真实值分别是[100, 200, 300]，预测值是[110, 190, 310]。

• MAE = (|100-110| + |200-190| + |300-310|) / 3 = 6.67，平均每个样本差了6.67个单位。
• MSE = (100 + 100 + 100) / 3 = 100，因为误差平方后是100。
• RMSE = sqrt(100) = 10。

注意MSE因为把误差平方了，所以大误差的影响力被放大了，RMSE是对MSE开根号，量纲回到原始单位。MAE则是把误差的权重一视同仁。选择哪个更合适，取决于你对“大的预测偏差”有多敏感。

举个例子：如果模型偶尔几个样本预测得离谱（比如真实值200被预测成了500），MSE会被这几个离谱样本拉高得非常明显，因为300的误差平方是90000；而MAE只算平均数，300的误差只贡献了300，影响相对小。所以如果你希望模型“尽量别犯大错”，就关注RMSE；如果你能接受偶尔的大偏差但希望整体误差稳定，就关注MAE。

R²更特殊一点，它表示模型解释了多少比例的方差，最大为1，越小代表效果越差。但R²有个陷阱：当数据有明显趋势（比如时间序列）或者测试集的方差本身非常大的时候，R²可能低得吓人，但模型实际没那么差。R²也不太适合对比不同业务场景下的两个模型，因为它跟数据本身的方差有关。我做项目时一般回归任务至少同时看R²和RMSE，一个看相对解释力，一个看绝对误差水平，两个结合起来才不会误判。

3.2 回归残差分析：被多数人跳过的关键检查

很多人算完回归指标就觉得大功告成，其实回归评估里最能发现问题的环节被漏掉了——残差分析。模型预测值和真实值的差就是残差，把残差画出来，能看出很多指标数字告诉不了你的问题。

最理想的残差图：残差随机地散布在0附近，没有明显的规律或趋势。如果你的残差呈现出喇叭口形状（预测值变大，残差也变大），说明数据存在异方差性，模型可能漏掉了一些非线性关系或者权重分布有问题；如果残差随某个特征的值出现有规律的波动，说明该特征与目标可能存在非线性关系，你当前的模型没有捕捉到。

python复制import matplotlib.pyplot as plt

residuals = y_test - y_pred
plt.scatter(y_pred, residuals, alpha=0.6)
plt.axhline(y=0, color='red', linestyle='--')
plt.xlabel("预测值")
plt.ylabel("残差")
plt.show()

有一次我做房价预测，模型R²到了0.85，看起来相当不错。但残差图一画出来，明显看到预测值在500万以上的区间残差全是正的，而且是越贵越离谱。也就是说模型对高价房普遍低估。检查后发现是训练数据里高价房样本太少，模型根本没学到高价区的规律。后来单独对高价区间做了加权采样和特征工程，才把这个系统性偏差修正过来。这种问题只看R²是永远看不出来的。

4. 交叉验证：比单次留出法稳健得多的评估方案

4.1 K折交叉验证的核心机制与配置选择

单次留出法评估结果受数据划分方式影响太大，换一次random_state结果就变，这个问题在小数据集上尤其致命。K折交叉验证就是为了解决这个不稳定性。

它的流程是：把数据集平均分成K份，每轮取其中1份做验证，剩下K-1份做训练，跑K轮，最后把K轮的指标取平均。这样每条数据都做过验证集，评估结果比单次划分稳定得多。

python复制from sklearn.model_selection import cross_val_score

scores = cross_val_score(model, X, y, cv=5, scoring='accuracy')
print("各折分数:", scores)
print("平均准确率: {:.4f} +/- {:.4f}".format(scores.mean(), scores.std()))

cv=5是常用选择，5折交叉验证意味着每轮80%数据训练、20%验证。K值的选取逻辑是：K越大，训练数据越多，评估偏差越小，但计算量越大，而且折之间结果的方差会变大（因为每轮的训练集高度重叠导致折间结果相关性增加）。实际项目里5折或10折用得最多，数据量几万以下用10折，几十万以上用5折，因为10折意味着多一倍的训练时间，收益却不大。

交叉验证输出里的标准差值得专门说一说。这个标准差反映的是“不同折之间模型表现的稳定性”，如果标准差太大（比如0.9 ± 0.15），说明模型对训练数据的分布变化非常敏感，泛化能力堪忧。这种情况优先考虑的不是调参，而是检查数据质量、特征是否存在异常、样本量是否不足。

4.2 分层K折和不平衡数据的处理方案

普通的K折在类别不平衡时会出问题：随机切分可能导致某一折里几乎没有少数类样本。这时候应该用StratifiedKFold，它保证每一折里各类别的比例和原始数据一致。

python复制from sklearn.model_selection import StratifiedKFold, cross_val_score

skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)
scores = cross_val_score(model, X, y, cv=skf, scoring='f1')

shuffle=True也很重要，它先把数据打乱再分层划分，避免原始数据里正样本排在一起导致分层失效。注意配合random_state来让结果可复现。

对于极度不平衡的数据集，比如正样本只有1%，分层K折可能还不够，因为某些折里正样本只有几个，模型根本学不到东西。这时候有两条路线：一是使用重复分层K折（RepeatedStratifiedKFold），把整个K折过程重复多次，每次用不同的随机种子，最后取平均，能有效降低极端划分带来的方差；二是换成专门为不平衡设计的评估策略，比如在训练时用class_weight='balanced'或者在评分时用scoring='roc_auc'，让模型的比较基准对不平衡更宽容。

4.3 交叉验证应用范围的一个提醒

交叉验证是评估模型泛化能力的好工具，但它并不是万能的。

第一个限制是时间序列数据不适用普通K折。时间序列有先后依赖关系，未来数据不能用来训练过去的模型，否则就是泄漏。时间序列应该用TimeSeriesSplit，它保证训练集始终在验证集之前。

第二个限制是交叉验证结果只对“同一分布”的数据有参考价值。如果模型上线后真实数据的分布发生漂移（比如用户行为习惯变了、市场环境变了），交叉验证的结果就会虚高。部署时要持续监控线上数据分布和模型指标衰减，交叉验证只是快速迭代期的参考工具。

5. 学习曲线与验证曲线：用图形判断模型是欠拟合还是过拟合

模型训练完，你经常面临一个灵魂拷问：效果不够好，到底是模型太简单了没学到东西，还是模型太复杂把噪声也记住了？调参方向错了，后面所有努力都白费。学习曲线和验证曲线就是用来回答这个问题的。

5.1 学习曲线的解读方法

学习曲线画的是：训练集样本量从少到多变化时，模型在训练集和验证集上的表现分别怎么变。

python复制from sklearn.model_selection import learning_curve
import numpy as np

train_sizes, train_scores, val_scores = learning_curve(
    model, X, y, cv=5, scoring='neg_mean_squared_error',
    train_sizes=np.linspace(0.1, 1.0, 5)
)

把训练曲线和验证曲线的均值和标准差画在图上（横轴是样本量，纵轴是分数），核心看两种典型形态：

欠拟合的典型形态：训练曲线和验证曲线都停在较低水平，且随着样本量增加，两条曲线趋于接近但都上不去。这说明模型容量不够，学不动数据的规律。解决方向是增强模型复杂度（换更强的算法）、增加特征、减少正则化强度。

过拟合的典型形态：训练曲线远远高于验证曲线，中间隔着一大段“鸿沟”，而且随着样本量增加这个鸿沟收窄得很慢。这说明模型把训练数据的细节和噪声背了下来，缺乏泛化能力。解决方向是增加训练数据、降低模型复杂度、加强正则化、早停法等。

实际操作里，曲线形态比绝对分数更重要。有一次我在做用户流失预测时看到训练分数极高、验证分数极低，第一反应是加正则化，但曲线图显示随着样本量增大，验证分数在下行趋势的减缓点之前还有明显上升势头，说明主要矛盾其实是数据太少而不是模型太复杂。后来补充了一批采样数据，同样参数下验证分数提高了近8个百分点。没有学习曲线，很容易病急乱投医。

5.2 验证曲线：找到一个超参的合适区间

验证曲线针对的是“单个超参”的敏感性分析。它以横轴为某个超参的取值（比如max_depth、C、n_estimators），纵轴为训练分数和验证分数，观察随着参数变化两条曲线的走势。

python复制from sklearn.model_selection import validation_curve

param_range = [1, 3, 5, 7, 9, 11]
train_scores, val_scores = validation_curve(
    RandomForestClassifier(random_state=42), X, y,
    param_name="max_depth", param_range=param_range,
    cv=5, scoring='accuracy'
)

画出来后通常会看到：训练分数随参数增大一直上升，验证分数先升后降。验证分数最高点对应的参数值，就是当前数据下的“甜蜜点”。注意验证曲线分析的是单个参数效果，多个参数交互作用它看不出来，需要结合网格搜索来做全局寻优。

6. 网格搜索与信息泄露：最容易被坑的评估环节

6.1 GridSearchCV的正确打开方式

超参数调优是模型评估的延伸，它的本质还是“评估不同参数配置下的模型泛化能力”。Scikit-learn的GridSearchCV把交叉验证和超参搜索捆绑在一起：对每一组参数组合，它跑一遍交叉验证，选平均分数最高的那组参数。

python复制from sklearn.model_selection import GridSearchCV
from sklearn.ensemble import RandomForestClassifier

param_grid = {
    'n_estimators': [50, 100, 200],
    'max_depth': [None, 5, 10],
    'min_samples_split': [2, 5, 10]
}

grid_search = GridSearchCV(
    RandomForestClassifier(random_state=42),
    param_grid=param_grid,
    cv=5,
    scoring='accuracy',
    n_jobs=-1
)
grid_search.fit(X_train, y_train)

print("最佳参数:", grid_search.best_params_)
print("最佳交叉验证分数:", grid_search.best_score_)

这里必须强调一个很多人栽过跟头的点：GridSearchCV内部用的是全量训练数据的K折交叉验证，网格搜索结束后的best_score_是交叉验证的平均分数，它不能直接当作模型在未知数据上的最终评估结果。搜索本身是在“挑最优参数”，这个挑选过程已经“看过”训练数据内部的划分结果，所以best_score_会有一点虚高。

正确的流程是用独立的测试集做最终评估：

python复制final_score = grid_search.score(X_test, y_test)

也就是网格搜索只用训练集（内部再切出小验证集做参数选择），测试集全程不参与调参，最后用来给出模型真实泛化能力的估计。这就是经典的“三集分立”原则：训练集用来拟合，验证集（由交叉验证充当）用来选参数，测试集用来终审。

6.2 嵌套交叉验证解决“选出来的模型也虚高”问题

如果你不仅想调出一个好模型，还想客观评估“这个调参流程整体上的泛化能力有多好”，那要用到嵌套交叉验证。

嵌套交叉验证的结构是：外层循环把数据切成多个折，每轮留一折做最终评估，其余数据进入内层循环；内层循环用交叉验证做参数搜索；选好参数后，在外层这个留出的折上评估。整个过程把“模型选择”也当作评估流程的一部分，得到的分数是对整个建模管线（包括调参决策）泛化能力的无偏估计。

python复制from sklearn.model_selection import cross_val_score, KFold
from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler

pipeline = Pipeline([
    ('scaler', StandardScaler()),
    ('svc', SVC())
])

param_grid = {'svc__C': [0.1, 1, 10], 'svc__kernel': ['linear', 'rbf']}

# 简化实现：内外两层都用5折
outer_cv = KFold(n_splits=5, shuffle=True, random_state=42)
inner_cv = KFold(n_splits=5, shuffle=True, random_state=42)

scores = cross_val_score(
    GridSearchCV(pipeline, param_grid, cv=inner_cv),
    X, y, cv=outer_cv, scoring='accuracy'
)
print("嵌套交叉验证分数:", scores.mean())

这种做法的优势是评估结果更诚实，缺点是计算量成倍上升。数据量大、模型复杂的时候非常吃算力。我的建议是：如果只是日常模型选型和调参，用普通的GridSearchCV加独立测试集就足够了；如果模型要用于重要决策，并且你特别关心“整个建模流程”的真实泛化误差，嵌套交叉验证值得跑。

6.3 预处理与网格搜索的Pipeline化

在网格搜索里，有一种信息泄露隐患极其隐蔽：如果不把标准化、PCA、特征选择这些预处理步骤放进Pipeline，而是一开始基于全部数据算好再喂给GridSearchCV，交叉验证就废了。

假设你有一列特征取值在0到100000，另一列在0到1，不标准化SVM直接跑效果很差。于是你把全部X（包括训练和测试）拿去StandardScaler，然后用GridSearchCV在X_train_scaled上搜索。这个流程看起来没什么问题，实际上标准化这一步在计算均值和方差时用到了训练集和测试集的全部信息，每个折里模型都间接接触到了验证折的数据分布信息，相当于开卷考。评估结果会系统性偏高。

正确做法是把标准化放进Pipeline，让它在每折的训练集上单独fit，再transform验证折。

python复制from sklearn.pipeline import Pipeline
from sklearn.preprocessing import StandardScaler
from sklearn.svm import SVC

pipeline = Pipeline([
    ('scaler', StandardScaler()),
    ('svc', SVC())
])

param_grid = {'svc__C': [0.1, 1, 10], 'svc__kernel': ['linear', 'rbf']}
grid_search = GridSearchCV(pipeline, param_grid, cv=5, scoring='accuracy')
grid_search.fit(X_train, y_train)

同理，PCA、基于统计的特征选择器、缺失值填充器等所有涉及数据统计信息的步骤，都应该放进Pipeline里。这个习惯能帮你避免绝大多数由预处理引发的信息泄露。我见过不止一个项目，把预处理放在Pipeline外，线上效果比离线评估低了十多个点，最后排查才发现是这一步惹的祸。

7. 一个完整评估套路的梳理与经验建议

写到这里，把整个模型评估的脉络做个串联。

按我实际操作的习惯，一个标准评估流程大致分这几步：

1. 拿到数据后先别急着建模，检查数据基本情况、缺失值、类别分布，确定业务指标。
2. 用train_test_split划分出独立的测试集，类别不平衡时务必打开stratify。
3. 所有预处理、特征工程全部放进Pipeline，只在训练集上fit，再transform测试集。
4. 先用交叉验证快速评估基础模型的水平，用分类报告或回归指标看初步表现。
5. 画学习曲线，判断偏差方差状态，确定调整方向。
6. 用GridSearchCV配合Pipeline做参数搜索，选最优参数。
7. 最优参数模型在独立测试集上做最终评估，看是否和交叉验证分数一致（差距过大说明有泄漏或过拟合）。
8. 残差分析（回归）或错误样本分析（分类），从定性层面确认模型的错误模式。

这套流程每一步之间有明确的依赖关系，跳过任何一步后面都可能返工。我自己吃过好几次亏，印象最深的一次就是前期没做学习曲线，直接上网格搜索调参数，调了半天验证分数就是不涨，后来画了学习曲线才发现是特征本身区分度不够，模型容量调到再大也没用。

另一条经验与数据划分相关。数据集采集的时候，时间跨度内的样本往往不是独立同分布的——不同时间段收集的数据可能有轻微分布差异。如果业务上预测的都是未来数据，交叉验证时最好用TimeSeriesSplit而不是随机划分，否则评估结果会过于乐观。

最后想说一点关于评估工具之外的事：Scikit-learn的评估体系设计得已经很完善，模型评估的难点从来不是API不会用，而是是否知道每个指标、每个方法背后回答的是什么业务问题。准确率回答不了“误杀重不重要”的问题，AUC也回答不了“阈值该定多少”的问题。指标是来服务业务决策的，不是反过来用模型去凑指标的。模型评估做得好不好，判断标准永远是：这个数字能不能真实反映模型在目标场景里的表现，并帮你做出正确的下一步决策。