Scikit-learn模型评估实战：从数据划分到交叉验证与指标选择

1. 为什么模型评估是机器学习项目里最容易被低估的一环

我见过太多刚入门的同学，训练完一个模型，accuracy_score 打印出来 0.97，就兴高采烈地觉得任务完成了。直到把模型丢到真实数据上跑，效果稀烂，才回过头来质疑：我的模型到底行不行？其实是评估环节出了问题。

机器学习项目的本质，不是让模型在训练集上考满分，而是让它在没见过的数据上也能稳定发挥——这个能力叫泛化能力。而泛化能力的好坏，恰恰是模型评估要回答的问题。Scikit-learn 之所以在机器学习生态里地位这么稳，除了算法实现简洁之外，它提供了一整套完整的模型评估工具链，从数据划分、交叉验证，到几十种评估指标，再到学习曲线、验证曲线，基本覆盖了你评估一个模型所需的全部环节。

这篇博文我会按自己实际做项目的顺序，把这套评估体系讲透。内容包括：怎么合理划分数据、K 折交叉验证的细节和坑、分类任务和回归任务各自该盯哪些指标、怎么用学习曲线诊断过拟合和欠拟合，最后是我这些年踩过的高频坑。内容偏实战，代码可以直接抄，适合已经会用 Scikit-learn 跑通基础模型、但对评估环节还停留在“看一眼 accuracy”阶段的朋友。

先立一个总原则：评估不是模型训练完之后的一个收尾动作，而是贯穿整个建模流程的决策依据。 你在做特征选择、调参、选模型的时候，每一步都需要用评估结果来判断方向对不对。如果评估本身不科学，那后面所有决策都是在盲人摸象。

2. 数据划分不是随便 split 一下：分层抽样与常见误区

2.1 train_test_split 里的三个关键参数

绝大多数人的第一个评估动作是 train_test_split。这个方法本身很简单，但参数的取舍直接决定你评估结果的可信度。

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
)

三个参数值得你逐个理解：

• test_size：测试集比例。0.2 或者 0.25 是常见选择。但数据量很小（比如几千条）的时候，0.2 的测试集可能只有几百条样本，评估结果的方差会很大。我自己的经验是，数据量低于 1 万条时，用 K 折交叉验证比单次划分更可靠，这点后面细说。
• random_state：固定随机种子。设成任何整数都行，作用是完全复现相同的划分。这个参数必须设。 如果你不设，每次运行代码划分结果都不一样，今天跑出来的分数和明天跑出来的分数可能差好几个百分点。对于想专心调模型的你来说，这种不确定性纯粹是干扰项。
• stratify：按类别比例分层抽样。分类任务里，如果类别不平衡（比如正样本只占 5%），不设 stratify 的话，随机划分很容易让测试集里正样本的比例严重偏离整体分布，甚至出现测试集里一个正样本都没有的极端情况。设了 stratify，Scikit-learn 会保证训练集和测试集里每个类别的比例和原始数据大体一致。

2.2 单次划分的局限：为什么需要交叉验证

单次划分的随机性隐患并不止于类别比例。哪怕你做了分层抽样，这一次划分里测试集的构成也是千变万化的。

举个例子。你手里有 1 万条数据，划分出 2000 条当测试集。这 2000 条数据可能恰好包含一些比较容易预测的样本，也可能恰好很刁钻。模型在这批测试集上的得分，带着相当强的偶然性。这就好像你考了一次数模竞赛，题目出得对你胃口，你拿了高分，但这并不完全证明你的能力。

交叉验证的思路就是把这个偶然性摊平。它把数据切成 K 份，轮流拿其中一份当验证集，其余 K-1 份训练模型，最终得到 K 个分数，再取平均。这样每个样本都有机会被验证到，评估结果比单次划分稳定得多。

Scikit-learn 里最常用的接口是 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():.4f})')

注意这里传给 cross_val_score 的是完整的数据 X 和 y，而不是已经切好的 X_train。因为交叉验证会自己负责切分数据，你不需要手动先划分一次。

2.3 KFold 与 StratifiedKFold：随机切分和分层切分的适用场景

cross_val_score 默认的 cv=5 用的是 StratifiedKFold（分层 K 折），这对分类任务来说是安全的选择。但如果你有自定义的划分需求，或者想更细粒度地控制切分逻辑，就需要直接操作 KFold 和 StratifiedKFold 这两个对象。

python复制from sklearn.model_selection import KFold, StratifiedKFold

# KFold：纯粹按顺序切分，不做类别比例控制
kf = KFold(n_splits=5, shuffle=True, random_state=42)

# StratifiedKFold：每折里各类别比例与整体一致
skf = StratifiedKFold(n_splits=5, shuffle=True, random_state=42)

KFold 适用于回归任务。回归任务的 y 是连续值，不存在类别比例一说，所以用普通的 KFold 就够了。StratifiedKFold 适用于分类任务，尤其是类别不平衡的场景，它能保证每一折里正负样本的比例都和全量数据接近。

还有个容易被忽略的参数是 shuffle。如果不设 shuffle=True，KFold 会按数据原始顺序依次切分。如果数据本身有顺序性（比如按时间排序的日志数据），不 shuffle 的切分方式会导致训练集和验证集的时间分布不一致，评估结果会失真。处理带时间特性的数据时，甚至应该用 TimeSeriesSplit，普通 shuffle 也不够安全，因为它会打乱时间顺序，造成用未来数据预测过去数据的数据泄漏。

2.4 时序数据的交叉验证：TimeSeriesSplit

如果数据是按时间排序的，而且特征里包含时间相关的信息（比如销量预测、股价预测、日志异常检测），常规的 K 折交叉验证就不适用了。原因很简单：你训练集里如果混入了未来时刻的数据，模型会“偷看”到未来信息，验证分数虚高，但真实线上推理时你不可能拿到未来数据。

Scikit-learn 提供了 TimeSeriesSplit，它的切分方式保证训练集永远是验证集之前的时间段：

python复制from sklearn.model_selection import TimeSeriesSplit

tscv = TimeSeriesSplit(n_splits=5)
for train_index, val_index in tscv.split(X):
    X_train, X_val = X[train_index], X[val_index]
    # 训练和验证

第一折用前 20% 的数据训练，验证后 20%；第二折用前 40% 训练，验证接下来的 20%，以此类推。这种做法模拟了“用历史预测未来”的真实场景。

3. 分类模型评估指标深挖：准确率失效后我们该看什么

3.1 混淆矩阵：一切分类指标的源头

很多人用 accuracy_score 用习惯了，遇到不平衡数据（比如欺诈检测里正样本只有 1%）就直接翻车。一个把所有样本都预测为负类的“傻瓜模型”，准确率也能到 99%。这时候 accuracy 完全失去了参考价值。

真正有用的第一步永远是看混淆矩阵（Confusion Matrix）：

python复制from sklearn.metrics import confusion_matrix, ConfusionMatrixDisplay

y_pred = model.predict(X_test)
cm = confusion_matrix(y_test, y_pred)
disp = ConfusionMatrixDisplay(confusion_matrix=cm)
disp.plot()

混淆矩阵的四个格子对应四种情况：

绝大多数分类指标都是从这四个数推导出来的。准确率 = (TP + TN) / 总数，但它在类别不平衡时毫无区分度。于是我们引入精确率和召回率。

3.2 精确率、召回率与 F1：一对永远在博弈的指标

• 精确率（Precision） = TP / (TP + FP)。它回答的问题是：模型预测为正类的样本里，有多少真的为正？精确率高，意味着模型宁可漏掉一些正样本，也不愿意把负样本误报为正。适合“误报代价高”的场景，比如垃圾邮件过滤——把一封正常邮件扔进垃圾箱比放过一封垃圾邮件更让人恼火。
• 召回率（Recall） = TP / (TP + FN)。它回答的问题是：所有真实的正样本里，模型找到了多少？召回率高，意味着模型偏向于把所有可疑的都标记出来，哪怕误报多一点也无所谓。适合“漏报代价高”的场景，比如癌症筛查——宁可让健康的人多做几次复查，也不能漏掉一个真正的病人。

这两个指标天然矛盾：提高召回率通常意味着降低精确率，反之亦然。为了在两者之间找一个平衡点，就有了 F1 分数——精确率和召回率的调和平均数：

python复制from sklearn.metrics import precision_score, recall_score, f1_score

print(f'精确率: {precision_score(y_test, y_pred):.4f}')
print(f'召回率: {recall_score(y_test, y_pred):.4f}')
print(f'F1 分数: {f1_score(y_test, y_pred):.4f}')

F1 用调和平均而不是算术平均，是因为它对较小值更敏感。如果精确率 0.9、召回率 0.1，算术平均是 0.5，看起来还凑合；但调和平均只有 0.18，如实反映了这个模型“偏向输出正类但抓不住真目标”的失败本质。

3.3 多分类场景下的宏平均与加权平均

上面说的都是二分类。多分类时，指标的计算有两种常见策略：

• 宏平均（macro）：每个类别各自算一次指标再取平均。它把每个类别同等看待，即使某个类别的样本很少，也不会因为是少数类而在计算时被稀释。类别不平衡时，宏平均能暴露模型在小类上的糟糕表现。
• 加权平均（weighted）：每个类别的指标按样本量加权取平均。Scikit-learn 的 classification_report 默认同时输出这两者。

python复制from sklearn.metrics import classification_report

print(classification_report(y_test, y_pred, target_names=['类0', '类1', '类2']))

实际项目里，我一般先看加权平均，了解整体水平；再逐个看每个类别的精确率和召回率，特别关注样本量最小的那个类别。很多线上事故，都是模型在多数类上表现很好，在少数类上全军覆没，加权平均分数被“漂亮”的多数类掩盖住了。

3.4 ROC 曲线与 AUC：看阈值之外的真正实力

精确率、召回率、F1 都有一个共同前提：它们是在某个固定判别阈值下计算出来的。分类器输出的通常是概率值，默认用 0.5 作为阈值来划分正负类。但换个阈值，精确率和召回率就变了。

ROC 曲线的核心思想，是不固定在某个阈值，而是把从 0 到 1 的所有阈值都试一遍，画出一条描述模型分类能力的曲线。横轴是假正率（FPR），纵轴是真正率（TPR，也就是召回率）。

python复制from sklearn.metrics import roc_curve, auc
from sklearn.metrics import roc_auc_score

y_proba = model.predict_proba(X_test)[:, 1]
fpr, tpr, thresholds = roc_curve(y_test, y_proba)
roc_auc = auc(fpr, tpr)
print(f'AUC: {roc_auc:.4f}')

AUC 是 ROC 曲线下方的面积。它的含义可以理解成：随机抽一个正样本和一个负样本，模型给正样本打高分（比负样本高）的概率。 AUC = 0.5 相当于瞎猜，AUC = 1 是完美分类。

AUC 对类别不平衡不那么敏感，也不依赖具体的阈值选择。我个人的习惯是：给老板汇报模型效果时，用 F1 搭配实际业务场景说明；给算法方案做对比选型时，主要看 AUC，因为它更能反映模型真正的排序能力。

4. 回归模型评估指标解读：MSE、MAE 和 R2 到底怎么选

4.1 核心指标对照

回归任务的目标是预测连续值，评估思路和分类完全不同。Scikit-learn 的 metrics 模块里最常用的几个回归指标如下：

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

y_pred = model.predict(X_test)

mae = mean_absolute_error(y_test, y_pred)
mse = mean_squared_error(y_test, y_pred)
rmse = mean_squared_error(y_test, y_pred, squared=False)
r2 = r2_score(y_test, y_pred)

4.2 什么时候用哪个

MAE 是最符合直觉的：预测值和真实值平均偏离多少。但它把所有误差一视同仁，两个 100 的误差和四个 50 的误差，MAE 算出来一样。如果你的业务场景里，大误差和小误差的代价没有本质区别，MAE 就够了。

MSE/RMSE 对大的误差施加了平方惩罚，一个 100 的误差的惩罚是 50 的误差的 4 倍。这使得它在训练时能迫使模型更努力地去修正那些偏离大的点。但这也意味着如果数据里有几个离群点，RMSE 会被拉得很高，显得模型“很差”，哪怕大部分预测都还不错。

R2 的思路是拿模型和“平均值模型”比：如果我只预测所有样本的目标均值，误差是多少？R2 衡量的是，我们的模型比“均值党”好多少。R2 = 0.85 意味着模型解释了 85% 的目标值方差。R2 为负数时也别慌，这说明模型预测比直接猜均值还差，多见于小样本+强非线性+模型不合适的组合。

我自己的选择逻辑是：调超参时用 RMSE 作为主指标，因为它的梯度更陡，能清晰区分不同参数组合的差异；最终评估模型时，MAE 和 R2 一起报告，MAE 给业务方一个直观的“平均偏多少”的认知，R2 给技术团队一个“解释力”的判断。

4.3 回归评估里容易犯的错

回归任务里，r2_score 单独使用并不全面。一个典型的场景：你的预测值和真实值呈完全线性关系，但整体系统性偏移（比如预测值总是高 10%）。这时候 R2 依然可能很高，但 MAE 也很大。所以务必画一张残差图：横轴是预测值，纵轴是真实值减预测值（残差）。如果残差出现明显的趋势性结构，说明模型还有可挖掘的模式没有利用到，或者评估本身有偏差。

python复制import matplotlib.pyplot as plt

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

残差均匀分布在零线附近、没有明显形状的模型，才算是真正拟合好了。

5. 诊断欠拟合与过拟合：验证曲线和学习曲线的实战用法

5.1 验证曲线：找到超参数的最佳区间

交叉验证不只用来评估最终模型，它还能帮你诊断模型的偏差-方差状况。validation_curve 就是拿来干这件事的：固定一个超参数的取值范围，在不同取值上分别做交叉验证，观察训练集分数和验证集分数的变化趋势。

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

param_range = np.logspace(-3, 3, 7)
train_scores, val_scores = validation_curve(
    SVC(), X, y,
    param_name='gamma',
    param_range=param_range,
    cv=5,
    scoring='accuracy'
)

train_mean = train_scores.mean(axis=1)
val_mean = val_scores.mean(axis=1)

判断逻辑很经典：

• 训练集分数高，验证集分数低，差距拉大 —— 过拟合。模型把训练集背下来了，但没有学到可泛化的规律。
• 训练集分数和验证集分数都低，且接近 —— 欠拟合。模型容量不够，或者特征信息不足以支撑预测。
• 训练集分数和验证集分数都高，且接近 —— 理想状态。

用验证曲线的实际意义，是提前终止无谓的调参。比如你调 gamma 的时候发现，随着 gamma 增大，训练集分数一路飙升到接近 1，验证集分数先升后降，那你就不需要再往更大的 gamma 方向试了，最佳区间已经浮出水面。

5.2 学习曲线：判断数据量是否足够

另一个常用工具是 learning_curve。它的横轴是训练样本数量，纵轴是分数。通过观察随着训练数据增多，训练集分数和验证集分数如何收敛，来判断当前瓶颈是数据量不足还是模型容量不够。

python复制from sklearn.model_selection import learning_curve

train_sizes, train_scores, val_scores = learning_curve(
    RandomForestClassifier(n_estimators=100),
    X, y,
    train_sizes=np.linspace(0.1, 1.0, 10),
    cv=5,
    scoring='accuracy'
)

典型场景有两种：

• 训练集分数始终很高，验证集分数随数据量增多缓慢上升，两者差距在缩小但没闭合。这说明增加数据能继续提升模型效果，因为模型容量还有余量。
• 训练集分数和验证集分数很早就在一个较低水平汇合。这说明模型容量是瓶颈，加数据也没用，得换更强的模型或者加特征。

这个工具在项目初期特别有用。我经常被问到“数据量够不够”，与其凭感觉，不如跑一次学习曲线，看趋势说话。

5.3 用交叉验证的结果分布来辅助判断

还有一种更轻量的诊断方式：直接看交叉验证每一折的分数分布。

python复制scores = cross_val_score(model, X, y, cv=10, scoring='accuracy')
print(f'均值: {scores.mean():.4f}, 标准差: {scores.std():.4f}')

如果标准差偏大（比如准确率均值 0.85，标准差 0.08），说明模型在不同数据子集上表现非常不稳定。可能的原因包括：数据量太小、存在离群子集、模型方差太大。这时候优先考虑的不是继续调参，而是检查数据质量，或者换一个方差更小的模型（比如正则化更强、树深度更浅的模型）。

6. 评估流程里的五个高频坑，以及我的处理方案

6.1 数据泄漏：交叉验证里的隐形杀手

这是模型评估里最严重、也最难察觉的问题。最常见的形态是：在交叉验证之前就做了特征选择或数据标准化。

python复制# 错误示范
from sklearn.preprocessing import StandardScaler
from sklearn.feature_selection import SelectKBest

scaler = StandardScaler()
X_scaled = scaler.fit_transform(X)  # 用全量数据拟合 scaler

scores = cross_val_score(model, X_scaled, y, cv=5)  # 泄漏！

问题在于，scaler.fit 使用了全量数据的统计信息（均值和方差），包括验证集里的样本。模型训练时，验证集的信息已经通过 scaler 的参数间接混进了训练过程，评估结果会偏乐观。

正确的做法是让数据转换过程纳入每一折的训练流程中。Scikit-learn 提供的 Pipeline 就是为了解决这个问题：

python复制from sklearn.pipeline import make_pipeline

pipeline = make_pipeline(StandardScaler(), RandomForestClassifier(n_estimators=100))
scores = cross_val_score(pipeline, X, y, cv=5)

Pipeline 会在每一折的训练过程中独立地 fit 和 transform 数据：先用训练折的数据拟合 scaler，再用这个 scaler 转换训练折和验证折。验证折的信息永远不会泄漏到训练过程中。

凡是涉及特征缩放、缺失值填补、降维、特征选择这些“需要从数据中学习参数”的操作，都应该放进 Pipeline，而不是在 Pipeline 外面先做好。

6.2 不平衡数据下只看 accuracy

前面提到过，正样本只有 1% 的分类任务里，全预测为负类的模型 accuracy 也有 99%。这是评估指标选择上的经典错误。

处理策略：

• 分类报告必须看，精确率、召回率、F1 各来一份。
• 用 StratifiedKFold 做交叉验证，保证每折类别比例一致。
• 必要时考虑采用 class_weight='balanced' 调整模型对少数类的重视程度，或者在评估时使用平衡准确率（balanced accuracy），即每个类别的召回率的平均值。

python复制from sklearn.metrics import balanced_accuracy_score

balanced_acc = balanced_accuracy_score(y_test, y_pred)
print(f'平衡准确率: {balanced_acc:.4f}')

平衡准确率能比较公平地反映模型在多数类和少数类上的综合表现，比单纯 accuracy 可靠得多。

6.3 随机性不可复现：random_state 设置不统一

模型本身的随机性（树模型的随机分裂、初始化等）和交叉验证划分的随机性，都会导致评估结果波动。如果不设置 random_state，同一份数据跑两次代码，分数可能差不少，这让你根本没法判断算法的修改到底是有效还是无效。

我的习惯是在三处地方统一设置随机种子：

• 模型内部的 random_state
• 交叉验证的 shuffle 和 random_state
• train_test_split 的 random_state

更彻底的做法是像 Kaggle 比赛那样，在代码开头统一设置全局随机种子：

python复制import random
import numpy as np

random.seed(42)
np.random.seed(42)

6.4 回归只看 R2，不看残差分布

R2 高不代表模型没问题。前面已经说过，系统性的偏移不会显著拉低 R2。更隐蔽的情况是：预测值在目标值较大区间内偏差大，而在小区间内偏差小，数据整体 R2 看起来不错，但业务恰恰最关心大值区的预测准确性。

所以但凡做回归，我都建议把残差分布图和 prediction_error 画出来，直观地看误差随预测值的变化。

6.5 忽略交叉验证之间的数据依赖

最后这个坑比较进阶。某些数据里样本之间并不独立，比如同一用户的多条行为记录。如果这些记录同时出现在训练集和验证集里，模型相当于“见过这个人”的数据，评估结果自然偏高。

解决思路是按更高层级的实体（用户、店铺等）做分组划分。Scikit-learn 提供了 GroupKFold：

python复制from sklearn.model_selection import GroupKFold

# groups 是一个和样本一一对应的数组，标记每个样本属于哪一组
group_kfold = GroupKFold(n_splits=5)
scores = cross_val_score(model, X, y, cv=group_kfold, groups=groups)

这样划分后，同一个用户的所有样本只会出现在同一折里，不会跨折泄漏。

这五个坑，我基本都在真实项目里踩过一遍。数据泄漏的后果最严重，因为它给你的评估分数是虚高的，会让你对模型上线后的表现产生不切实际的预期；不平衡数据选错指标次之，它会让你在错误的模型上越走越远。建议你接手一个新任务时，先对照这五条排查一遍自己的评估流程，再开始调模型。

7. 按需求自定义评估函数：当内置指标不够用的时候

7.1 用 make_scorer 包裹自定义指标

实际业务中，标准的准确率、F1、MAE 往往不能完全契合业务诉求。举个例子：在电商的点击率预测里，把高价值用户的点击预测错了，和把普通用户的点击预测错了，代价完全不同。这时候需要自定义指标，把“代价权重”放进去。

Scikit-learn 允许你用 make_scorer 把任意函数包装成评估器，供 cross_val_score 和网格搜索使用：

python复制import numpy as np
from sklearn.metrics import make_scorer

def cost_sensitive_recall(y_true, y_pred):
    # 假设样本权重向量：每个样本的“价值”
    # 这里简单地认为正样本被正确预测的收益是 2，负样本被误报的损失是 1
    tp = np.sum((y_true == 1) & (y_pred == 1))
    fp = np.sum((y_true == 0) & (y_pred == 1))
    return (2 * tp - fp) / (tp + fp + 1e-9)

cost_scorer = make_scorer(cost_sensitive_recall, greater_is_better=True)

scores = cross_val_score(model, X, y, cv=5, scoring=cost_scorer)

greater_is_better=True 告诉 Scikit-learn 这个指标越高模型越好。如果你的指标是损失（越小越好），就设成 False。这一步做完，后续的网格搜索和交叉验证就都能用上符合业务语义的评估口径了。

7.2 多指标同时评估：cross_validate 的用处

很多情况下，你不想只看一个指标。比如分类任务里，既想关注 AUC，也想知道 F1，还想顺带看一眼准确率。cross_val_score 只支持一个指标，cross_validate 可以一次性返回多个：

python复制from sklearn.model_selection import cross_validate

cv_results = cross_validate(
    model, X, y,
    cv=5,
    scoring={
        'accuracy': 'accuracy',
        'f1': 'f1_macro',
        'roc_auc': 'roc_auc'
    },
    return_train_score=True
)

for metric_name, values in cv_results.items():
    print(f'{metric_name}: {values.mean():.4f} (±{values.std():.4f})')

return_train_score=True 会额外返回训练集上的分数，方便我快速判断模型是过拟合还是欠拟合——训练集分数远高于测试集分数，就是过拟合的明确信号。

7.3 评估指标选择要与业务方对齐

技术层面的指标选择相对容易，难的是让业务方理解你的评估逻辑。我的经验是：给业务方汇报时，永远先讲他们能直接感知的指标（比如误报率、漏报率、平均误差），再讲技术指标（F1、AUC）。毕竟 AUC 提高了 0.02，业务方很难直接感受到价值；但漏报率从 15% 降到 8%，这个价值是清晰的。

所以在项目启动时，我就会和业务方确认清楚：“这个模型上线后，最不能接受哪种错误？”如果是“绝对不能把坏人放过去”，那评估指标就以召回率为主；如果是“不能把好人拦下来”，那重点看精确率。评估指标从来不是纯技术问题，它背后是整个业务的价值取向。

8. 最终建议：适合你的工作流

讲了这么多，最后给出我日常做模型评估的标准流程，你可以直接照搬或按需修剪。

• 接到任务后，先花 10 分钟检查数据形态。分类任务确认类别分布，回归任务确认目标值分布，检查是否有明显的离群点和缺失值。
• 搭一个最简单的模型作为基线（比如逻辑回归或线性回归），用 cross_validate 同时输出几个核心指标，记下来。
• 画学习曲线判断当前瓶颈：是数据量不够，还是模型太弱。如果训练集和验证集分数很早汇合在低水平，优先上更复杂的模型或者做特征工程；如果两者差距大，说明过拟合，优先考虑简化模型、加正则化或收集更多数据。
• 用验证曲线对关键超参数（树的深度、正则化强度等）做范围搜索，缩小最佳参数区间后再用网格搜索精调。
• 最终评估阶段，固定随机种子，用 cross_validate 跑一次完整的多指标评估，记录平均分和标准差，同时画出残差图（回归）或混淆矩阵（分类）。
• 上线的最后一道检查：确认所有数据预处理步骤都放进了 Pipeline，没有在全量数据上提前拟合过任何东西。

这套流程完成下来，你对模型的判断会比较扎实。我个人从“跑完模型看一眼准确率”到“系统地做完这一整套评估”，大概用了两个项目的时间，中间踩了不少坑。现在回头看，那些坑踩得值，因为只有亲眼见过一个虚高 0.05 的评估结果被水落石出地纠正，才会真正理解评估科学的重要性。

模型评估这件事，某种程度上比模型本身更考验基本功。祝你的模型评估之路少踩几个我踩过的坑。