Scikit-learn模型评估全攻略：从数据划分到交叉验证的防泄漏指南

1. 从一次“翻车”的调参经历说起：为什么模型评估才是基本功

先讲个我早年间踩过的坑。当时我接了一个二分类任务，数据集不大，几千条样本，特征工程折腾了挺久，模型从逻辑回归一路试到XGBoost，最后挑了一个在测试集上准确率高达96%的模型，兴冲冲地准备上线。结果模型一上线，线上表现直接崩到60%出头，业务方差点把我拉黑。后来定位问题才发现，我犯了一个非常经典的错误：训练集和测试集划分之前，我拿全部数据做了标准化，相当于测试集的信息通过scaler的均值和方差泄漏到了训练过程里。更讽刺的是，那个96%的准确率本身也虚高，因为正负样本本来就失衡，模型学会的只是“无脑预测多数类”。

这件事之后我养成了一个习惯：不管模型多花哨，先问自己三个问题——评估流程有没有漏洞？指标选得对不对？结果能不能复现？这三个问题，全部落在“模型评估”这个环节上。Scikit-learn（以下简称sklearn）之所以能成为Python机器学习生态里最常用的库之一，除了它把大量算法封装得足够好用之外，它那一整套评估工具链——数据集划分、交叉验证、指标计算、学习曲线、验证曲线——才是真正让模型从“能跑”变成“可靠”的关键。

这篇文章不打算讲太多算法原理，而是聚焦在sklearn里模型评估的完整实操链条。不管你是刚接触机器学习的大学生，还是在做期末项目、竞赛或者准备面试，这套评估方法论都能直接用。我尽量把每一步的原理、代码、注意事项和踩坑经验都讲透，让你看完就能在自己的项目里落地。

2. 模型评估的整体设计思路与核心原则

2.1 评估到底在解决什么问题

很多人以为模型评估就是跑一下 accuracy_score，得到一个数字，然后看它够不够高。但实际工程里，评估是在回答三个递进的问题：

第一，这个模型的泛化能力怎么样？也就是说，它面对没见过的数据时，还能不能保持训练时的水平。第二，这个模型在什么条件下会失效？比如正负样本极端不平衡时、特征分布漂移时，它还行不行。第三，如果我要调参或者换模型，我凭什么说A方案比B方案好？评估就是那把“同一把尺子”。

这三个问题对应了评估体系的三个组成部分：数据划分策略、指标体系、验证方法。单独拎哪一个出来，都撑不起完整的评估流程。

从sklearn的设计哲学来看，它把评估相关的功能分散在几个模块里：model_selection 负责数据划分、交叉验证、超参搜索；metrics 负责指标计算；learning_curve 和 validation_curve 负责可视化诊断。理解了这个模块划分，你在写代码的时候就不会满世界翻API了——需要划分数据去找 model_selection，需要算指标去找 metrics，需要画学习曲线还是去 model_selection。

2.2 “先划分、再训练”这条铁律

模型评估最大的隐性陷阱就是信息泄漏。数据泄漏的定义很宽泛，但最常犯的就是在划分数据集之前做预处理。标准化、PCA、特征选择这些步骤一旦用全量数据去fit，测试集的信息就已经“参与”了训练，这时候就算测试集准确率再高，也不能代表真实泛化表现。

举个最直观的例子。你有一份数据，里面有“年龄”这个特征。如果你在全量数据上算均值和方差，然后做标准化，再划分训练集和测试集，那么测试集每一行的“年龄”都是通过全量均值调整过的。模型见过这个均值的“影子”，测试集的独立性就打了折扣。虽然在实际操作中这个偏差可能不大，但在企业级项目里，一点点的泄漏都可能被放大成线上事故。

sklearn提供了非常干净的解决方案：用 Pipeline 把预处理和模型打包，再用 cross_validate 或 GridSearchCV 去跑。Pipeline保证每一次交叉验证的fold里，预处理只有训练部分被fit，测试部分只是被transform。这个习惯如果你能从一开始就建立起来，能避开绝大多数评估翻车现场。

2.3 sklearn评估工具链全景

我先给一张工具清单，让你有个整体印象，后面再逐一展开。

后面每一个模块我都会给出可直接运行的代码，并且解释每个参数背后的“为什么”。说实话，sklearn的官方文档写得很全，但对新手不友好，因为它默认你已经有足够的统计学习背景。这篇文章帮你把文档里“没说透”的部分补上。

3. 数据集划分：评估的第一道关口

3.1 train_test_split：别只填一个test_size

train_test_split 是入门最常用的函数，但很多人对它参数的理解停留在“按比例分一下”。实际上它有四个值得关注的细节。

第一个是 stratify 参数。做分类任务时，如果数据本身类别不平衡，比如正样本只占5%，单纯随机划分很容易导致某一折里正样本为0。stratify=y 可以保证训练集和测试集中的类别比例与原数据一致。这行代码我写过的次数可能比任何其他API都多。

python复制from sklearn.model_selection import train_test_split

X_train, X_test, y_train, y_test = train_test_split(
    X, y,
    test_size=0.2,
    random_state=42,
    stratify=y  # 分类任务强烈建议加这个
)

第二个是 random_state。这个参数固定了随机数种子，让划分结果可复现。很多新手抱怨“为什么我每次跑结果都不一样”，90%是因为没设 random_state。虽然不是每个场景都必须固定，但在你做模型对比的时候，如果每次划分都不一样，你没法判断性能差异是模型带来的还是数据划分运气带来的。

第三个是划分比例。test_size=0.2 和 0.3 哪个好？没有标准答案，取决于数据量。数据量大（十万级以上），0.2甚至0.1都够用；数据量小（几千条），0.3或者0.4可能更合适，因为测试集太小会让评估结果方差很大。我个人的经验是，万级以下数据，测试集样本量最好不低于500条，否则置信区间宽到等于没测。

第四个是 shuffle 参数，默认是True。如果你的数据是按时间排序的，比如每天的日志数据，shuffle=True会打乱时间顺序，制造出“未来数据预测过去”的假象，导致评估结果虚高。时序场景建议设置 shuffle=False，或者用 TimeSeriesSplit。这一条很多人忽略，但做风控、销量预测的人早晚会碰到。

3.2 K折交叉验证：用“多轮考试”替代“一次考试”

单次划分训练集和测试集的问题在于：结果依赖于这一次特定的划分，运气成分太大。你可能分的这一份测试集恰好比较容易，也可能恰好很难。为了降低这种随机性，交叉验证的思路是：把数据分成K份，轮流拿其中一份做验证，其余K-1份做训练，最后把K次结果平均。

sklearn里最常用的是 cross_val_score：

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

model = RandomForestClassifier(n_estimators=100, random_state=42)
scores = cross_val_score(model, X, y, cv=5, scoring='accuracy')
print(f"每折得分: {scores}")
print(f"平均得分: {scores.mean():.4f} (+/- {scores.std() * 2:.4f})")

cv=5 是默认值，代表5折。为什么常见5折或10折？这其实是偏差和方差的权衡：折数越多，训练数据越多，模型偏差越小，但计算成本越高，而且折与折之间重叠越多，评估结果的方差也可能增大。5折是工程上比较折中的选择。

scoring 参数指定使用什么指标。这里有个小坑：sklearn的指标参数有的是“越大越好”（如accuracy、f1、roc_auc），有的是“越小越好”（如neg_mean_squared_error）。交叉验证里为了统一返回“得分”概念，回归的MSE会被取负号，所以是 neg_mean_squared_error，用的时候自己取个负号就是真正的MSE。这个细节坑了我不止一次。

3.3 StratifiedKFold：分类任务的默认选项

cross_val_score 的 cv=5 在底层用的是 KFold，它对回归任务没问题，但对分类任务有隐患——如果类别分布不均衡，某个fold里可能完全没有少数类样本，导致这一折的模型根本没学过怎么识别少数类，得分自然奇低。

解决办法是 StratifiedKFold，它在划分时对每一折都做分层抽样，保证每一折里面的各类别比例和全量数据基本一致。如果你直接传 cv=StratifiedKFold(n_splits=5) 给 cross_val_score，就能覆盖这个场景。

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')

我个人建议，凡是分类任务，无脑用 StratifiedKFold 或者 cross_val_score 里传入带有 stratify 逻辑的cv对象就行。你可能会觉得多写两行代码麻烦，但它在类别不平衡时能省下你排查诡异结果的半天时间。

3.4 其他划分策略：什么时候用GroupKFold和TimeSeriesSplit

除了常规的K折，有两个场景需要特殊的划分策略。

第一个是“同一组的数据不能同时出现在训练集和测试集”。比如你的数据里有多个用户的多次操作记录，如果同一用户的一部分记录在训练集、另一部分在测试集，模型相当于已经“见过”这个人了，评估会虚高。这时要用 GroupKFold，指定 groups 参数为用户ID。

python复制from sklearn.model_selection import GroupKFold, cross_val_score

groups = df['user_id'].values
gkf = GroupKFold(n_splits=5)
scores = cross_val_score(model, X, y, cv=gkf, scoring='accuracy')

第二个是时间序列的 “不允许使用未来数据” 约束。TimeSeriesSplit 的划分方式是：第一次用第1~k折训练、k+1测试；第二次用第1~k+1折训练、k+2测试。这样训练集永远是测试集的过去。

python复制from sklearn.model_selection import TimeSeriesSplit

tscv = TimeSeriesSplit(n_splits=5)
scores = cross_val_score(model, X, y, cv=tscv, scoring='neg_mean_squared_error')

这两个场景在面试里也经常被问到，理解了它们的存在意义，你对“评估”这件事的理解就已经超过很多人了。

4. 核心评估指标：选对尺子比跑对模型更难

4.1 分类任务：accuracy、precision、recall、F1与AUC怎么选

分类指标是最容易被滥用的。accuracy_score 看起来最直观，但它有一个致命弱点：类别不平衡时，它完全失效。举个例子，99%的样本是负类，1%是正类，你只要无脑把全部样本预测成负类，accuracy就是99%。这个模型有价值吗？没有。

所以二分类场景下，我更建议至少同时看这几个指标：precision（精确率）、recall（召回率）、F1-score、AUC。它们对应的业务含义是：

• precision：预测为正类的样本里，有多少是真的正类。它告诉你“模型说的好消息有多少可信”。
• recall：真实正类样本里，模型找回了多少。它告诉你“模型漏掉了多少真正的好消息”。
• F1：precision和recall的调和平均，两者出现极端偏差时F1会很低，适合想要平衡的场景。

sklearn里计算这些指标非常方便：

python复制from sklearn.metrics import classification_report, confusion_matrix

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

classification_report 会一次性输出precision、recall、F1和support（每个类别的样本数），适合快速体检。而混淆矩阵能让你直观看到模型在哪些类别上容易混淆。

AUC是另一个常用指标，它的好处是与分类阈值无关，衡量的是模型把正样本排在负样本前面的能力。roc_auc_score 在sklearn里一行就能算：

python复制from sklearn.metrics import roc_auc_score

y_proba = model.predict_proba(X_test)[:, 1]
auc = roc_auc_score(y_test, y_proba)
print(f"AUC: {auc:.4f}")

注意这里用的是 predict_proba，而不是 predict。因为AUC依赖的是概率排名，不是最终分类结果。如果你把 predict 的结果传进去，AUC就退化成accuracy了，这个细节很多人搞错。

4.2 回归任务：MSE、RMSE、MAE、R2与业务风险绑定

回归任务的指标选型，核心是理解“你更在乎哪种错误”。mean_squared_error（MSE）对大的误差极其敏感，因为误差被平方了。如果你的业务里，犯大错误的代价远大于犯小错误，MSE就很合适。但MSE的数值单位是平方后的，不好解释，所以常用 mean_squared_error取平方根后得到RMSE，回到原始单位。

mean_absolute_error（MAE）则对所有误差一视同仁，更稳健，对异常值不敏感。如果数据里有很多离群点，而你不想让它们过度影响评估，MAE更合适。

r2_score 的官方名称是“决定系数”，更通俗的理解是“模型比用均值当预测好了多少”。R2等于1表示完美拟合；等于0表示和直接预测均值差不多；小于0说明连均值都不如。这是回归任务里最“通用”的指标，因为它是相对值，能在不同量纲的任务间做比较。

实际项目里，我一般会同时打印RMSE、MAE和R2：

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

y_pred = model.predict(X_test)
mse = mean_squared_error(y_test, y_pred)
rmse = mse ** 0.5
mae = mean_absolute_error(y_test, y_pred)
r2 = r2_score(y_test, y_pred)
print(f"RMSE: {rmse:.4f}, MAE: {mae:.4f}, R2: {r2:.4f}")

三个指标一起看的原因很简单：RMSE和MAE的差距能反映误差的分布形态，如果RMSE明显大于MAE，说明误差中有少数极端大值在拖后腿；R2则给出一个全局视角，看模型相比“均值预测”提升了多少。

4.3 多分类场景：微平均与宏平均的差别

多分类任务的评估会比二分类复杂一点。classification_report 在二分类里会给每个类别输出precision和recall，多分类也一样，只不过多了一个“微平均（micro）”和“宏平均（macro）”的概念。

微平均是把所有类别的TP、FP、FN汇总后统一算指标，等价于“全局来看的准确率”，适合类别不平衡时评估整体表现。宏平均是每个类别单独算指标再取平均，对少数类更敏感。如果少数类表现极差，宏平均会拉低整体得分，而微平均可能被多数类掩盖。

python复制from sklearn.metrics import f1_score

macro_f1 = f1_score(y_test, y_pred, average='macro')
micro_f1 = f1_score(y_test, y_pred, average='micro')
print(f"Macro F1: {macro_f1:.4f}, Micro F1: {micro_f1:.4f}")

选哪种取决于业务诉求。如果你在乎每个类别的平均表现，选macro；如果你只在乎总体正确率，选micro。竞赛里常看到的weighted平均则是按样本量加权的宏平均，适合数据不平衡时综合评估。

4.4 评估指标与业务场景的映射：用生活案例理解

指标选型的核心逻辑是：把评估指标对应到业务代价。

拿电商风控举例。假设你在建一个“识别恶意下单”的模型。恶意订单占比可能只有2%。这时候你如果用accuracy评估，模型只需要把所有订单都判为“正常”，准确率就能到98%，这个模型毫无用处。正确做法是用recall：把“恶意订单有多少被抓出来”作为核心指标。因为漏掉一个恶意订单，平台就要承受一笔退款或营销损失。

反过来，如果在做“垃圾邮件过滤”，误报的代价是用户正常邮件被扔进垃圾箱，这比漏掉几封垃圾邮件更糟糕。所以precision是第一优先级，至少要保证“模型说是垃圾邮件的，是真的垃圾邮件”。

AUC则适合“先排序、后处置”的场景。比如你有100万个用户，只能给其中1万人发优惠券，那你关注的是模型能否把“高响应概率用户”排在前面，AUC天然适合这类排序问题。

你可以在自己的项目里做这样一个练习：写一段文字描述业务场景，然后明确标注“如果模型犯错误，哪种错误代价更高”，再据此选择指标。这个习惯一旦建立，后面的建模工作会有明确方向。

5. 实操过程：用sklearn完整跑通一个模型评估流程

5.1 数据准备与预处理流程

这一节我用一个可以完整复现的示例，把前面讲的内容串起来。这里用sklearn自带的糖尿病数据集（diabetes）来演示回归任务，顺便模拟完整的评估流程。

python复制import numpy as np
import pandas as pd
from sklearn.datasets import load_diabetes
from sklearn.model_selection import train_test_split
from sklearn.preprocessing import StandardScaler
from sklearn.pipeline import Pipeline
from sklearn.linear_model import Ridge
from sklearn.ensemble import RandomForestRegressor
from sklearn.model_selection import cross_val_score
from sklearn.metrics import mean_squared_error, mean_absolute_error, r2_score

# 加载数据
diabetes = load_diabetes()
X, y = diabetes.data, diabetes.target

# 划分数据集
X_train, X_test, y_train, y_test = train_test_split(
    X, y,
    test_size=0.2,
    random_state=42
)

print(f"训练集样本量: {X_train.shape[0]}, 测试集样本量: {X_test.shape[0]}")

这里有个关键点：标准化要在划分之后做。我在代码里用Pipeline把标准化和模型绑定起来，就是为了防止数据泄漏。

python复制# 构建带预处理的回归Pipeline
pipeline = Pipeline([
    ('scaler', StandardScaler()),
    ('model', Ridge(alpha=1.0))
])

# 交叉验证评估
cv_scores = cross_val_score(
    pipeline, X_train, y_train,
    cv=5,
    scoring='neg_root_mean_squared_error'
)
print(f"交叉验证RMSE: {-cv_scores.mean():.4f} (+/- {cv_scores.std() * 2:.4f})")

注意我用的是 neg_root_mean_squared_error，这是sklearn新版提供的直接算RMSE的scoring方式，不用自己开根号。如果你用的版本比较老没有这个参数，就退回 neg_mean_squared_error 再手动开根号。

5.2 交叉验证评估：一次跑出多个指标

cross_val_score 一次只能算一个指标，如果我想同时看RMSE、MAE、R2，就得用 cross_validate：

python复制from sklearn.model_selection import cross_validate

scoring = {
    'rmse': 'neg_root_mean_squared_error',
    'mae': 'neg_mean_absolute_error',
    'r2': 'r2'
}

cv_results = cross_validate(
    pipeline, X_train, y_train,
    cv=5,
    scoring=scoring,
    return_train_score=True
)

print("训练集R2: {:.4f}".format(cv_results['train_r2'].mean()))
print("测试集R2: {:.4f}".format(cv_results['test_r2'].mean()))
print("测试集RMSE: {:.4f}".format(-cv_results['test_rmse'].mean()))
print("测试集MAE: {:.4f}".format(-cv_results['test_mae'].mean()))

return_train_score=True 会同时返回训练集得分，这让你能快速观察过拟合：如果训练集R2远高于测试集R2，说明模型过拟合了。这是一个成本极低的排查手段，建议日常评估时都打开。

5.3 在测试集上的最终验证：评估流程的“期末考试”

交叉验证的结果可以用来说服自己“模型大概能到什么水平”，但最终的对外汇报还是需要一次“干净”的测试集评估。注意，这里说的“最终验证”和前面的交叉验证不完全是一回事：交叉验证是在训练集内部循环评估，而最终的测试集验证是模型所有开发完成之后，再在从未参与过任何训练或验证步骤的数据上做一次最终确认。

python复制# 用全量训练集拟合Pipeline
pipeline.fit(X_train, y_train)

# 在测试集上做最终预测
y_pred = pipeline.predict(X_test)

rmse = mean_squared_error(y_test, y_pred) ** 0.5
mae = mean_absolute_error(y_test, y_pred)
r2 = r2_score(y_test, y_pred)

print(f"测试集最终表现 -> RMSE: {rmse:.4f}, MAE: {mae:.4f}, R2: {r2:.4f}")

如果你在完整评估流程中反复使用测试集做决策，比如“这个指标不好，我调一下参数再测一次”，那测试集实际上已经变成了训练集的一部分，最终结果依然会虚高。所以成熟的流程是：交叉验证期间反复调整，最后只在测试集上做一次验证，拿到的分数才是可以对外承诺的“真实水平”。

5.4 用分类任务再走一遍评估流程

为了照顾做分类任务的同学，我再补一段分类评估的完整示例。这里用make_classification生成一个不平衡的二分类数据来演示：

python复制from sklearn.datasets import make_classification
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import classification_report, roc_auc_score, confusion_matrix

# 生成不平衡数据
X, y = make_classification(
    n_samples=2000, n_features=20,
    n_informative=15, n_redundant=5,
    weights=[0.9, 0.1],  # 90%负类，10%正类
    random_state=42
)

X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.3, random_state=42, stratify=y
)

model = LogisticRegression(max_iter=1000)
model.fit(X_train, y_train)

y_pred = model.predict(X_test)
y_proba = model.predict_proba(X_test)[:, 1]

print(classification_report(y_test, y_pred))
print(f"AUC: {roc_auc_score(y_test, y_proba):.4f}")
print("混淆矩阵:")
print(confusion_matrix(y_test, y_pred))

这段代码你拿去跑一遍，就会直观看到为什么accuracy在这种场景下会“骗人”。如果你不看 classification_report，只看accuracy，会觉得模型不错；看了precision和recall，才发现少数类的召回率可能很低。

6. 学习曲线与验证曲线：用图形诊断模型的“病”

6.1 学习曲线：判断过拟合还是欠拟合

交叉验证告诉你“模型表现如何”，但没有告诉你“模型为什么表现不好”。学习曲线是这里最好的诊断工具之一。它的思路是：逐步增加训练样本量，记录模型在训练集和验证集上的表现，然后把两条曲线画出来看趋势。

python复制import matplotlib.pyplot as plt
from sklearn.model_selection import learning_curve

train_sizes, train_scores, test_scores = learning_curve(
    pipeline, X_train, y_train,
    cv=5,
    train_sizes=np.linspace(0.1, 1.0, 10),
    scoring='neg_root_mean_squared_error',
    random_state=42
)

train_means = -train_scores.mean(axis=1)
test_means = -test_scores.mean(axis=1)

plt.figure(figsize=(8, 5))
plt.plot(train_sizes, train_means, marker='o', label='训练集RMSE')
plt.plot(train_sizes, test_means, marker='s', label='验证集RMSE')
plt.xlabel('训练样本量')
plt.ylabel('RMSE')
plt.title('学习曲线')
plt.legend()
plt.grid(True)
plt.show()

怎么读这张图？

• 如果训练集RMSE很低、验证集RMSE很高，而且随着样本量增加两者在缓慢靠近，说明模型过拟合，需要增加数据量、降低模型复杂度或者加强正则化。
• 如果两条曲线都高，且基本平行、不怎么下降，说明模型欠拟合，需要增加特征、提高模型复杂度。
• 如果两条曲线在尾部趋于收敛，说明当前样本量已经接近“够用”，再加数据收益不大。

学习曲线的价值在于它把“模型为什么差”这个抽象问题变成了可视化的趋势判断。我在实际项目中，几乎每个模型上线前都会画一张，成本极低，收获却很大。

6.2 验证曲线：观察单个超参数的影响

验证曲线解决的是另一个问题：某个超参数怎么取值最合适。它固定其他参数，只变化目标参数，画出训练集和验证集得分随参数变化的情况。

拿Ridge回归的alpha举例：

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

param_range = np.logspace(-3, 3, 20)

train_scores, test_scores = validation_curve(
    pipeline, X_train, y_train,
    param_name='model__alpha',
    param_range=param_range,
    cv=5,
    scoring='neg_root_mean_squared_error'
)

train_means = -train_scores.mean(axis=1)
test_means = -test_scores.mean(axis=1)

plt.figure(figsize=(8, 5))
plt.semilogx(param_range, train_means, marker='o', label='训练集RMSE')
plt.semilogx(param_range, test_means, marker='s', label='验证集RMSE')
plt.xlabel('alpha')
plt.ylabel('RMSE')
plt.title('验证曲线')
plt.legend()
plt.grid(True)
plt.show()

注意 param_name 里我写的是 model__alpha。这个双下划线语法是Pipeline里的参数寻址方式：model 是Pipeline里步骤的名字，alpha 是Ridge模型里的参数名。Pipeline的步骤名在Pipeline构造时定义，写成 ('model', Ridge(...)) 后，访问该步骤的参数就得用 model__alpha 这种格式。很多新手在这里卡住，报KeyError，实际上就是步骤名写错了。

验证曲线的用法简单说就是：如果增大参数导致训练集和验证集得分一起变差，说明参数过大了；如果训练集得分很好但验证集很差，说明过拟合区，需要朝反方向调参。

6.3 GridSearchCV：让超参搜索自动带上交叉验证

当你从验证曲线里确认了几个值得尝试的参数区间后，就可以用网格搜索把这些区间里的组合全部试一遍。GridSearchCV 会在每个候选参数组合上都做交叉验证，并选出得分最高的组合。

python复制from sklearn.model_selection import GridSearchCV

param_grid = {
    'model__alpha': [0.01, 0.1, 0.5, 1.0, 5.0, 10.0, 50.0]
}

grid_search = GridSearchCV(
    pipeline,
    param_grid=param_grid,
    cv=5,
    scoring='neg_root_mean_squared_error',
    n_jobs=-1
)

grid_search.fit(X_train, y_train)

print(f"最佳参数: {grid_search.best_params_}")
print(f"最佳交叉验证RMSE: {-grid_search.best_score_:.4f}")

GridSearchCV 内部的逻辑其实就是把交叉验证套在候选参数上。它fit完之后，best_estimator_ 就是最优模型，可以直接用来预测。

这里有几个值得注意的细节：

第一，n_jobs=-1 代表使用所有CPU核心并行计算。网格搜索本质上是把多个模型的训练任务并行跑，这个参数能大幅缩短等待时间。

第二，GridSearchCV 如果用了整个训练集去fit，那它内部的交叉验证结果只是一张“参考成绩单”，不能作为最终对外宣称的分数。因为网格搜索本身也是“看了验证集结果才选出来的参数”，带了调参痕迹，最终分数要在独立的测试集上重新算一遍。

第三，如果你搜索的参数范围过大，网格搜索的计算量呈指数级增长，这时候优先用 RandomizedSearchCV，它在参数空间中随机采样，计算量大减，效果通常也不错。

6.4 嵌套交叉验证：评估调参后的模型真实水平

如果你严谨到连“调参过程带来的信息泄漏”都要规避，那就得上嵌套交叉验证（Nested CV）。它的思路是：外层循环划分训练集和测试集，内层循环做网格搜索调参。最终通过外层测试集的平均得分来评估“调参+训练”整套流程的泛化能力。

sklearn里嵌套交叉验证的做法其实是复用 cross_val_score，只不过把内层的 GridSearchCV 当成一个“模型”传进去：

python复制from sklearn.model_selection import cross_val_score

# 内层网格搜索
inner_cv = GridSearchCV(
    pipeline,
    param_grid=param_grid,
    cv=5,
    scoring='neg_root_mean_squared_error'
)

# 外层交叉验证
outer_scores = cross_val_score(
    inner_cv, X_train, y_train,
    cv=5,
    scoring='neg_root_mean_squared_error'
)

print(f"嵌套交叉验证RMSE: {-outer_scores.mean():.4f} (+/- {outer_scores.std() * 2:.4f})")

嵌套交叉验证的计算成本很高，但它是学术界公认最严谨的评估方式之一。如果你在发论文、跑竞赛或者做模型选型对比，建议使用这种方式，省得审稿人或面试官追着问“你的评估流程有泄漏吗”。

7. 评估全流程中那些防不胜防的坑：问题排查与避坑实录

7.1 数据泄漏：最容易犯、最难发现的错误

数据泄漏的隐蔽之处在于，有时候你代码逻辑看着没问题，但实际上已经泄漏了。除了前面说的先标准化后划分，还有几个场景非常高频：

• 特征选择时在全量数据上fit。比如你用 SelectKBest 选择特征，如果先fit全量数据再划分，特征选择的“倾向性”已经包含了测试集信息。
• 填充缺失值时用全量均值。比如 SimpleImputer(strategy='mean') 在全量上fit，训练集填充的均值实际上是含测试集数据的均值。
• 类别编码时在全量上fit。比如 OrdinalEncoder、OneHotEncoder，必须在训练集上fit，再transform验证集和测试集。

避免这些问题的通用解法，就是把所有预处理步骤都塞进Pipeline。Pipeline里每个步骤都遵循“fit只在训练集上、transform在所有集合上”的原则。养成这个习惯，数据泄漏基本能从源头上杜绝。

7.2 随机种子：不做实验对比的时候，也要固定

随机种子对评估的影响比很多人想象中大。你用不同的 random_state 划分数据，可能得到完全不同（甚至相反）的模型排序。尤其是数据量小的时候，这个波动会被无限放大。

我建议的做法是：每个项目固定一个 random_state，比如42，作为默认种子。开会对比模型时，大家看到的结果是可复现的；线上复现问题时，定位也快。不要一个脚本里用了七八个不同的 random_state，出了问题自己都查不清。

交叉验证里 KFold(shuffle=True, random_state=42) 和 ShuffleSplit 等划分器也要记得设种子。cross_val_score 这种高层API如果不传入cv对象，只传cv=5，那么它底层用的是不带shuffle的KFold，结果倒是确定的，但如果你改成 cv=StratifiedKFold(n_splits=5, shuffle=True) 而忘了设 random_state，又会变成不可复现。这些细节虽然不起眼，但排查起来非常难受。

7.3 类别不平衡：accuracy之外的生存指南

前面讲过accuracy在类别不平衡时的“欺骗性”，这里再补充两个实践中常用的处理方向。

第一个方向是换个评估指标：用precision、recall、F1、AUC这些对类别不平衡更敏感的指标。如果业务场景要求最高recall，那就锁定recall；如果要求precision和recall的平衡，就锁定F1。

第二个方向是采样策略：用 imbalanced-learn 库里的 RandomUnderSampler（欠采样）或 SMOTE（过采样）处理训练集，让模型看到更均衡的类别分布。注意：采样只能对训练集做，不能对测试集做。测试集必须保持真实分布，否则评估结果无法反映线上情况。

python复制from imblearn.over_sampling import SMOTE
from imblearn.pipeline import Pipeline as ImbPipeline

smote_pipeline = ImbPipeline([
    ('smote', SMOTE(random_state=42)),
    ('scaler', StandardScaler()),
    ('model', LogisticRegression(max_iter=1000))
])

imblearn.pipeline.Pipeline 和sklearn的 Pipeline 用法基本一致，区别在于它能让SMOTE在交叉验证中正确作用于每折的训练部分，而不会提前在测试部分生成合成样本。注意：SMOTE只对训练数据过采样，验证集和测试集一律不动。 这个细节如果你直接手动SMOTE再交叉验证，很容易踩雷。

7.4 概率校准：predict_proba的质量也值得评估

很多场景下，你不仅需要一个二分类结果，还需要模型输出的概率本身是可靠的。比如在风控里，你把用户违约概率p=0.6的样本和p=0.9的样本视为同一风险等级，就会出问题。

sklearn里评估概率质量的方法叫 Brier score，数值越低代表概率预测越准：

python复制from sklearn.metrics import brier_score_loss

brier = brier_score_loss(y_test, y_proba)
print(f"Brier Score: {brier:.4f}")

如果发现概率校准不好，可以用 CalibratedClassifierCV 做一个后处理校准：

python复制from sklearn.calibration import CalibratedClassifierCV

calibrated = CalibratedClassifierCV(model, cv=5, method='isotonic')
calibrated.fit(X_train, y_train)
y_proba_calibrated = calibrated.predict_proba(X_test)[:, 1]

校准这个动作常被忽略，但在工业界其实很重要。你拿排序结果做决策时，概率绝对值有没有意义，会直接影响后续的阈值设定和ROI测算。

7.5 模型对比时的显著性：别被“高一点点”骗了

最后一个坑是个统计层面的问题：A模型的交叉验证平均分比B模型高了0.01，你能说A比B好吗？

不一定。交叉验证多次得分的标准差可能高达0.05，0.01的差距完全可能在噪声范围内。严格的做法是跑多次交叉验证，然后用统计检验来比较。sklearn里提供了 scipy.stats 的配对检验方式，其中一个近似做法是用不同种子的K折重复跑，记录每折得分，然后做配对t检验。

python复制from scipy import stats

scores_a = cross_val_score(model_a, X_train, y_train, cv=10, scoring='accuracy')
scores_b = cross_val_score(model_b, X_train, y_train, cv=10, scoring='accuracy')

t_stat, p_value = stats.ttest_rel(scores_a, scores_b)
print(f"p值: {p_value:.4f}")

如果p值大于0.05，说明两者的差异在统计上不显著，选择模型时应该考虑其他因素，比如训练速度、可解释性、推理延迟。

这个思想在工作里非常实用。你向业务方解释“为什么选这个模型”时，如果只说“准确率高0.5%”，对方不一定信服；如果你补一句“做了10折配对t检验，p值小于0.05，差异显著”，这就完全是专业人士的表达方式了。

8. 写在最后：评估是你和模型之间的“信任契约”

做机器学习这几年，我越来越觉得，模型评估不是一个“最后做一下”的收尾动作，而是一条贯穿模型开发全过程的“信任契约”。你每一次告诉自己“模型比上次好了”，都需要靠它来证明；你每一次向别人承诺“模型上线不会崩”，也需要靠它来支撑。没有评估的模型，和没有方向盘的车一样，你可能开得很快，但不知道什么时候会出事。

sklearn把评估工具做得足够完善，但工具是死的，使用者对“为什么这么评估”的理解才是核心。如果你能把这篇文章里涉及的方法沉淀成自己的标准流程，并且理解每个参数、每个指标背后的含义，那么恭喜你，你已经在机器学习这条路上跨过了一个很重要的门槛。后面再碰到新模型、新算法，无非是换一个模型对象，评估的框架几乎可以原样复用。

以后写代码之前，不妨先问自己一遍：我要用什么指标衡量好坏？这个指标和我的业务目标对不对得上？我的评估流程有没有泄漏？如果你能每次都对答如流，说明你真的把评估这件事想明白了。