★ FEATURED ARTICLE 做机器学习项目时我最常被问的一个问题不是“模型怎么训练”而是“模型到底行不行”。很多人训练完模型看一眼训练集准确率95%就觉得自己大功告成了结果模型一到真实数据上立刻露馅准确率掉到70%还多。问题出在哪出在你根本没搞懂模型评估这件事到底在干什么。“使用Scikit-learn进行机器学习模型评估”这个主题听起来像一个不过脑子的教材章节但真正把它搞明白之后你会发现它其实是整个机器学习流程里最值得花时间打磨的一环。模型评估不是简单算几个指标它是你在给模型做“体检”判断它有没有病、病在哪、该吃什么药。这篇文章我就从实操角度把Scikit-learn做模型评估的完整思路、常用工具、核心指标和踩坑经验一次说清楚。无论你是刚入门的新手还是已经写过一阵子模型的进阶玩家这篇文章都能帮你把评估这步做得更扎实。1. 模型评估的本质你不是在建模型而是在做决策1.1 训练集上效果好不是真本事先说一个很多初学者容易走进去的怪圈在训练集上把准确率刷到接近满分就觉得自己模型天下无敌。这里面最大的误区在于——你把模型在训练集上的表现当成了模型在真实世界中的表现。打个比方你把一份数学卷子的标准答案背得滚瓜烂熟考试时原题重现你能拿满分但只要题目换个表述方式你就不会做了。机器学习模型也是这样。决策树模型深度设得足够大它可以把训练集的每一个样本都“记住”但这不是学习规律这叫死记硬背。一个只会背答案的模型你还能指望它在考试测试集里有多好的发挥吗所以模型评估首先要解决的核心问题就是我们需要一个能够公平反映模型泛化能力的方式。这里的“泛化能力”指的就是模型面对从未见过的数据时做出正确预测的能力。训练集表现好只代表模型记住了训练数据测试集表现好才代表模型真的学会了规律。我们做评估就是要系统地去测量这种“学会规律”的能力。1.2 评估方案先于建模落地我在实际项目中养成了一个习惯动手写模型之前先把评估方案定下来。先想清楚这个模型做好做坏用什么标准来衡量数据怎么切分怎么防止评估结果失真然后再去谈用什么算法、怎么调参。这听起来像多此一举但真正做起来能帮你少走无数弯路。Scikit-learn把评估这件事变得特别方便但正因为太方便了很多人只是机械地调用accuracy_score或者r2_score根本不思考背后的逻辑。举个例子用同一个评估函数处理不同场景的数据结果可能是完全错误的决策依据。比如一个二分类问题里面99%的样本是A类那么一个永远预测A类的“傻子模型”准确率都能到99%这时候你用准确率来评估模型就会得到一个自欺欺人的结论。所以在Scikit-learn进行模型评估之前先建立一套完整的评估框架。这套框架至少包含三个层面数据集怎么切分、用什么指标来衡量、怎么判断模型有没有过拟合或欠拟合。这三个层面互相配合才能把评估结果转化为有效的行动方案。2. 数据集切分评估的第一道关口2.1 三层划分法与常见比例很多项目一开始只有一份数据集那这份数据怎么用答案就是切分。我之前做过一个图像识别项目数据量不大就几千张图片刚开始我图省事直接把数据分成训练集和测试集两部分用训练集训练用测试集评估简单粗暴。但后来发现这种二分法有个隐患——你要是用同一个测试集反复调模型超参数时间一长测试集的信息会悄悄“泄漏”到模型调参过程里评估结果会越来越乐观但模型真正面对未知数据时的表现并没有那么好。更稳妥的做法是三层划分训练集、验证集、测试集。训练集用来拟合模型验证集用来调超参数、做模型选择测试集只用来做最终评估。打个比方验证集像是平时小测验帮你调整学习方法测试集像是期末大考考完才知道你真正学得怎么样。你要是平时小测验和期末大考用同一张卷子那次次都“考得好”但真实水平很可能被严重高估。切分比例上Scikit-learn的train_test_split默认是75%训练、25%测试这个比例在数据量充分时没问题。但如果是中小型数据集我建议训练集占70%到80%剩下的留给测试集如果数据量特别大比如几百万条可以把测试集比例调小到10%到20%因为这时候数据足够支撑训练集和测试集之间的信息覆盖度。2.2 交叉验证把数据用到极致三层划分有一个天然的痛点数据不够用。尤其在一些竞赛项目或者小样本场景里分完训练集和测试集之后训练集本身可能就不够模型学习了。这时候交叉验证就是一个非常优雅的解法。Scikit-learn里的cross_val_score是我用得最多的函数之一。它的核心思路是把训练数据分成K份每次拿其中K-1份训练、剩下的1份验证轮流做K次最后取K次验证结果的平均值。这样做的好处很明显每一份数据都被用作过训练和验证你对待评估模型的性能估计会比单次切分更稳定、更可靠。K值一般取5或10。5折交叉验证计算开销小一些在大数据集上跑得快10折交叉验证的估计偏差更小但计算量也更大。我自己的习惯是数据量小就上10折数据量大又赶时间就5折折中的做法是取10次随机切分然后取平均Scikit-learn里可以通过设置shuffleTrue来实现随机化交叉验证。2.3 分层抽样与随机种子切分数据还有一个极其容易忽视的点类别分布。假设你手头有个二分类任务正样本只占10%负样本占90%切分时如果不做处理很可能训练集里正样本只占5%测试集里正样本却占15%两边分布完全不对齐评估出来的指标也就失去了参考价值。Scikit-learn的train_test_split里有一个参数stratify专门解决这个问题。设置stratifyy之后切分出来的训练集和测试集里各类别样本的比例会和原始数据集保持一致。这个参数我第一次用的时候觉得“不就用一下而已”但后来做时间序列分类项目时发现如果忽略分层极容易出现测试集里某些类别样本过少导致个别类别的评估指标波动巨大。随机种子random_state也必须提一下。切分数据本身带有随机性种子不同切分结果就会不一样。我见过不少项目两个人用同一套数据复现同一套代码结果指标对不上最后发现就是random_state一个设了42一个没设。做正式实验时统一固定种子保证实验可复现这是数据侧最基本的一个好习惯。3. 分类任务的度量标准准确率之外的世界3.1 混淆矩阵一张表说清所有问题分类任务的评估指标多得让人眼花缭乱但最底层的逻辑都源自一个东西——混淆矩阵。Scikit-learn里的confusion_matrix函数可以输出一个2×2矩阵二分类情况下四个格子分别代表真正例TP、假正例FP、真负例TN、假负例FN。你光看准确率的时候只能知道模型预测对了多少但你不知道它是把正样本认错了还是把负样本认错了。我之前做一个借贷风控模型的时候项目一开始只关注准确率模型准确率刷到了90%多感觉相当不错。后来把混淆矩阵打出来一看发现坏账用户被预测成好用户的比率特别高这才是业务上真正致命的错误。准确率再高拦不住该拦的人模型对业务就没有价值。所以我强烈建议做分类模型评估的时候第一个动作永远是输出混淆矩阵别急着看那堆衍生指标。理解了混淆矩阵后面的精确率、召回率、F1等你都能很自然地串起来。3.2 精确率、召回率与F1的取舍逻辑精确率和召回率是怎么从混淆矩阵里来的精确率Precision是“预测为正类的样本里有多少是真的正类”召回率Recall是“真实为正类的样本里有多少被模型成功找出来了”。这两个指标往往此消彼长——你追求精确率高就会保守一点只把把握大的样本预测为正类结果就是漏掉不少真正的正类你追求召回率高就会激进一点把很多疑似正类的都抓出来结果就是误伤一堆负样本。到底优先哪个要看业务场景。垃圾邮件过滤任务里精确率更重要因为把正常邮件误判成垃圾邮件的代价很高癌症早期筛查任务里召回率更重要因为漏掉一个真病号可能比多让几个健康的人做复查严重得多。Scikit-learn里的classification_report函数会一次性输出精确率、召回率、F1值特别方便省得你手动算。F1值是精确率和召回率的调和平均数适合你不想纠结二选一、想综合衡量时的场景。F1越高说明模型在精确率和召回率之间平衡得越好。但有一点要记牢F1高不代表业务好只是说两个指标的几何意义上都还行具体决策还得回到业务场景来看。3.3 AUC-ROC衡量排序能力AUC-ROC是另一个高频使用的评估方式尤其适合二分类问题。它的逻辑是从排序角度衡量模型能力——对一堆样本做预测时模型给出的概率值能不能把正样本排在负样本前面。AUC值等于随机抽取一个正样本和一个负样本正样本的预测概率比负样本高的概率。AUC为0.5就相当于瞎猜1.0就是完美排序。我为什么强调AUC因为它对类别不平衡没有准确率那么敏感。一个99%负样本的数据集你预测全负样本准确率是99%但AUC会非常诚实——因为模型根本没有排序能力。在用户流失预测、信用评分这类场景里AUC是评判模型排序能力的黄金标准。Scikit-learn里可以用roc_auc_score直接计算AUC用roc_curve获取曲线数据后自己画图。画ROC曲线我一直觉得比单看一个AUC数值信息量大得多——曲线底下的面积是AUC但曲线的形状能看出模型在不同阈值下的表现那种靠近左上角的曲线才是真的好模型。另外要注意一点AUC评估的是排序能力而不是校准能力。如果业务上需要精确的概率数值比如某产品要求给出一个漂移率直接用这个概率做决策那AUC就不够看了得用对数损失或者看概率校准图。3.4 类别不平衡时怎么选指标类别不平衡是工业界最常见的坑之一。有个我做过的案例某个监控预警系统正样本真正需要预警的事件发生率大概只有0.5%模型如果全部预测负类准确率能到99.5%但预警系统完全没起作用。这种情况下准确率就是垃圾指标。应该看哪些呢首选是召回率因为预警场景漏报才是最大的风险其次是精确率看你预警了100次里有多少次是真的避免预警疲劳另外F1、AUC也可作参考。当业务要求必须同时兼顾精确率和召回率时可以设定一个行业经验里的最低阈值然后用F2指标召回率权重更大来衡量。处理类别不平衡还应从数据侧入手比如用重采样、SMOTE生成少数类样本、改变类别权重等。但有一点我想特别提醒评估指标和数据预处理必须一体设计。你用了SMOTE之后如果还是用原本的准确率做评估很可能得到一个漂亮的假结果因为合成样本的特性和真实样本未必一致。我在实际项目里一直坚持“用混淆矩阵和召回率/精确率这些更细粒度的指标来监控不平衡场景下的模型效果”这个习惯帮我在很多项目里发现了潜在风险。4. 回归任务的度量标准误差到底怎么算合理4.1 MAE与MSE两种性格的误差分类讲完了回归任务同样有一堆评估指标。最基础的两个是MAE平均绝对误差和MSE均方误差。MAE就是预测值与真实值差值的绝对值加起来取平均MSE是差值的平方加起来取平均。前者直观误差单位跟原始数据一致后者因为平方的存在会把那些“大误差”放大很多倍。我在做房价预测项目时体会特别深。用MAE做指标时模型预测平均偏了3万元听上去还行但用MSE会发现少数几套房子预测偏了20万元以上它们的平方贡献已经把整个误差拉爆了。MSE对异常值极度敏感这是它的特征不一定是坏事——如果你的业务场景非常讨厌大的预测偏差MSE就能放大这个风险帮你发现模型的极端失误。MAE则偏向“常态表现”。它不会因为个别极端偏差而剧烈波动更适合你想了解“整体上平均差多少”的场景。两者选哪个没有标准答案回到业务需求就清楚了。但我自己的习惯是建模初期同时打印MAE和MSE一边看平均偏差一边看是否存在极端偏差。二者联合起来看比只看任何一个都能暴露更多信息。4.2 RMSE与R2谁更能反映模型质量MSE开个根号就是RMSE均方根误差它把单位恢复成了原始数据的单位解释性比MSE好不少。R²决定系数则是“模型解释了多少数据方差”的比例取值一般接近1是好接近0或者为负说明模型基本没用。R²为0.9时给人的直观感觉是“模型解释了90%的方差”这个概念看似清晰实际很容易误读。实际项目中不同数据集的R²不可直接横向比较。同样是0.8的R²在一个规律很强、噪声很低的数据集上可能还不够好但在另一个噪声很大的现实数据集上可能已经相当出色。所以R²别拿去做跨数据集的绝对比较它更多是反映“当前数据上模型比均值强多少”。还有一个常用指标是MAPE平均绝对百分比误差在销售预测、备货预测里很好用。它回答的是“平均误差占比多少”的问题。但它有一个致命缺陷当真实值特别小甚至接近0时百分比会被极端放大。销售额预测还好真实值一般不会趋近0但某些点击率、故障率之类的数据有些时段真实值就是0MAPE会直接爆表。这时候可以选择SMAPE这类改进的百分比误差指标。4.3 指标选择与业务场景绑定回归指标的选择本质是业务价值的投射。我做过一个供应链需求预测的项目仓库里囤货过多会积压资金囤货不足又会缺货影响销售所以“预测值比真实值高一点”和“预测值比真实值低一点”的代价并不一样。这种情况下单纯看MSE或MAE都不够需要把误差按方向拆开看“预测偏高”造成的平均成本和“预测偏低”造成的平均成本明显偏高和偏低的业务损失不同。Scikit-learn里回归指标也都现成mean_absolute_error、mean_squared_error、r2_score等函数一行调用。但工具是死的业务是活的。我的建议是每次做回归评估时先想清楚这样一个核心问题误差在业务上一定会产生代价吗代价是对称的吗如果不对称就把指标拆开来看不要用一个综合指标把所有信息盖住。5. Scikit-learn评估全家桶从指标到工具5.1 内置指标函数速查Scikit-learn的metrics模块几乎覆盖了所有主流评估指标这一点做得确实很贴心。用习惯了之后你会发现不用自己手工实现各种评估逻辑。下面列一下最常用的几个分类指标函数from sklearn.metrics import ( accuracy_score, precision_score, recall_score, f1_score, confusion_matrix, classification_report, roc_auc_score, roc_curve, precision_recall_curve ) y_true [0, 1, 1, 0, 1, 0] y_pred [0, 1, 0, 0, 1, 0] print(confusion_matrix(y_true, y_pred)) print(classification_report(y_true, y_pred, digits4))classification_report是我日常使用频率最高的一个因为它输出整齐精确率、召回率、F1、支持度一目了然。用的时候注意digits参数默认是小数点后两位追求精细对比时可以改成4位。注意微平均和宏平均的区别averagemicro是把所有类别的预测结果汇总后再计算指标averagemacro是先分别算每个类别的指标再取平均。多分类场景下如果你的类别极其不平衡宏平均更能反映每个类别的个体表现。回归指标也顺手列一下from sklearn.metrics import mean_absolute_error, mean_squared_error, r2_score y_true [3.0, -0.5, 2.0, 7.0] y_pred [2.5, 0.0, 2.0, 8.0] print(MAE:, mean_absolute_error(y_true, y_pred)) print(MSE:, mean_squared_error(y_true, y_pred)) print(R2:, r2_score(y_true, y_pred))这些函数本身没什么学习成本真正的成本在于知道什么场景该用哪个。像上面介绍的分类我会优先看混淆矩阵和classification_report回归则根据业务输入常结合MAE、MSE和R²来看。5.2 交叉验证评估实操cross_val_score是最主要的交叉验证评估入口。看一个实际例子from sklearn.datasets import load_breast_cancer from sklearn.tree import DecisionTreeClassifier from sklearn.model_selection import cross_val_score data load_breast_cancer() X, y data.data, data.target clf DecisionTreeClassifier(max_depth3, random_state42) scores cross_val_score(clf, X, y, cv5, scoringroc_auc) print(每次交叉验证的AUC:, scores) print(平均AUC:, scores.mean()) print(标准差:, scores.std())cv5表示5折交叉验证scoringroc_auc指定评估指标为AUC。这里有一个细节值得注意如果scoring不传默认会用模型自带的score方法。对分类器通常是准确率但这不代表对每个场景都合适。不平衡分类任务里一定要自己显式指定评分方式。cross_val_score还支持scoring参数传一个负的MSE回归里常见的neg_mean_squared_error因为sklearn的设计原则是“得分越大越好”。它会返回一列负的MSE值负值越大说明误差越小。第一次看的时候容易一头雾水但理解了它的设计逻辑就豁然开朗了。交叉验证的结果还有一个用途评估稳定性。如果五次得分是0.89、0.91、0.88、0.90、0.92说明模型表现稳定如果五次是0.95、0.70、0.59、0.96、0.82那问题就大了——模型很可能对某些特定数据分布非常敏感或者数据本身有问题。我通常用标准差来辅助判断标准差太大说明模型不稳定需要去查数据和特征。5.3 模型调参中的评估GridSearchCV模型评估的另一个重要场景是网格搜索调参。GridSearchCV把参数搜索和交叉验证绑定在一起每次用一组参数做交叉验证最后选平均分最高的那组参数。这是我在项目里用到最频繁的自动化调参方式。看一个简单的例子调整逻辑回归的正则化强度from sklearn.model_selection import GridSearchCV from sklearn.linear_model import LogisticRegression from sklearn.pipeline import Pipeline from sklearn.preprocessing import StandardScaler pipe Pipeline([ (scaler, StandardScaler()), (clf, LogisticRegression(max_iter1000, random_state42)) ]) param_grid { clf__C: [0.01, 0.1, 1, 10, 100] } grid GridSearchCV( pipe, param_grid, cv5, scoringroc_auc, n_jobs-1, return_train_scoreTrue ) grid.fit(X, y) print(最优参数:, grid.best_params_) print(最优得分:, grid.best_score_)这里有三个值得关注的点。第一return_train_scoreTrue可以同时拿到训练得分和验证得分用来对比是否过拟合。如果训练得分一路飙升、验证得分上不去那说明模型开始过拟合了。第二n_jobs-1表示用所有CPU核心并行计算能节省大量时间。第三GridSearchCV内部已经做了交叉验证这里面的训练集和测试集划分尤其是最终评估不要用同一个数据集去调参再评估不然会有信息泄漏。当数据量很大、计算资源吃紧时RandomizedSearchCV是更好的选择。它从参数分布中随机采样比穷举网格的GridSearchCV高效得多。我一般会优先用RandomizedSearchCV做粗搜再用GridSearchCV在最优值附近做细搜这样兼顾搜索效率和精度。但有一点始终要记牢调参是对超参数空间进行搜索搜索本身也是在利用验证集信息你调得越频繁验证集上得出来的分就越乐观最终结果必须放到一个从未参与过调参的测试集上去检验才算数。5.4 学习曲线一眼看出过拟合还是欠拟合有经验的从业者做模型评估时不光看最终指标还会看模型“成长过程”这就是学习曲线。Scikit-learn的learning_curve函数可以画出训练样本数量从少到多时训练得分和交叉验证得分的变化趋势。学习曲线教你快速区分三种状态欠拟合训练得分和验证得分都很低两条曲线接近说明模型太简单连训练数据都学不好。对策是增加模型复杂度、增加特征。过拟合训练得分非常高验证得分明显偏低两条线之间有一道很大的“鸿沟”。对策是增加训练数据、降低模型复杂度、正则化。正常两条线都收敛到一个合理的水平差距不大。以逻辑回归为例这里画一下学习曲线import numpy as np import matplotlib.pyplot as plt from sklearn.model_selection import learning_curve train_sizes, train_scores, val_scores learning_curve( LogisticRegression(max_iter1000, random_state42), X, y, cv5, scoringneg_log_loss, train_sizesnp.linspace(0.1, 1.0, 10) ) train_mean np.mean(train_scores, axis1) val_mean np.mean(val_scores, axis1) plt.figure(figsize(8, 5)) plt.plot(train_sizes, train_mean, labelTraining Score, markero) plt.plot(train_sizes, val_mean, labelValidation Score, markero) plt.xlabel(Training Examples) plt.ylabel(Score) plt.legend() plt.show()当然在实际项目中我也会借助验证曲线validation_curve来观察某个超参数在不同取值下的表现。比如固定其他参数调整决策树深度观察训练得分和验证得分的变化找到那个“验证得分开始下降”的临界点——这就是最优深度所在之处。曲线的趋势往往比单个数值更能说明问题。6. 实际项目中的评估陷阱与避坑指南6.1 数据泄露比你想的更容易发生做评估时最隐蔽、后果最严重的坑就是数据泄露——训练过程中用到了未来本不该看到的数据信息导致评估指标看起来完美实际上线后完全拉胯。我见过一个真实例子某项目做时序预测切分数据时用的是普通的train_test_split没有按时间顺序切结果未来数据混进训练集验证指标漂亮得不像话一到线上预测立刻崩盘。数据泄露的主要来源有几类预处理时把整个数据集拿来计算均值、方差然后切分这部分信息已经泄漏到了训练集中。正确的做法是先切分再用训练集的统计量去标准化测试集。特征选择、降维等操作在训练集和测试集合并的数据上做的直接用了测试集的信息。时序数据没有按时间分割而是在全部时间内随机切分。数据处理泄漏的经典做法是把预处理放进Pipeline里让Scaler只拟合训练集避免任何测试集信息提前参与。在时间序列场景中用TimeSeriesSplit代替KFold也是保证评估可信的必需操作。我可以负责任地告诉你数据泄露在真实项目里出现的频率远比你想象中高。也正是因为这个原因我在项目里养成了一个习惯任何评估结果都要问一句“这个结果是在完全干净的训练/测试分离下跑出来的吗”如果没有把握就把清洗流程重新捋一遍。6.2 评估指标要和业务损失对齐很多刚入行的人会犯一个典型错误拿准确率当万能指标不管什么场景都先“accuracy_score一顿输出。但业务方真正关心的并不是准确率这个抽象数字他们关心的是这个模型能不能降低坏账率、能不能节省多少人力成本、能不能把漏掉的高价值客户捞回来。要让模型评估产生实际业务价值就得把评估指标翻译成业务语言。还是拿风控来说一次信用误判把好用户拒了损失的是获客机会一次逾期漏判把坏用户放了进来损失的是资金风险。你要做的就是把两类风险的代价量化然后去看模型的阈值怎么定、模型的表现是否在可接受区间内。Scikit-learn本身不管你的业务代价计算但你可以通过混淆矩阵或者precision_recall_curve来调整决策阈值。默认是0.5但是你可以根据业务需求把它调到0.3或者0.7找到最佳平衡点。不要默认0.5就是最优——它只是数学上不偏不倚的一个默认值离业务最优很远。6.3 随机种子的影响随机种子这件事看似琐碎实际上对评估结果影响大得惊人。同样的模型、同样的数据、同样的参数random_state0和random_state42跑出来的评估指标可能相差好几个百分点。在模型复杂度本来就高、数据量又小的情况下这个差异会更明显。我给你一个务实的建议正式做评估时至少用3到5个不同的随机种子跑一遍看评估指标的范围。如果范围跨度很大说明模型的方差也大这时候表面上的最优结果很可能是随机性带来的运气而不是模型本身真的厉害。与此同时在对外汇报或者做方案对比时必须明确标注你用的种子值否则别人复现不出来就是一场灾难。我自己的标配是每次都固定random_state42关键实验再另外补两个种子做敏感性分析。6.4 常见问题速查表问题现象可能原因解决思路训练集得分极高测试集得分低过拟合降低模型复杂度、增加正则化、扩大训练数据训练集和测试集得分都很低欠拟合增加模型复杂度、增加有效特征交叉验证各折得分波动极大数据分布不均匀或模型方差大使用分层采样、增加交叉验证折数、检查异常数据测试集得分比训练集高数据切分不当或数据量太小重新检查数据切分逻辑、排除数据泄漏类别不平衡场景准确率很高但业务不买账模型偏向多数类改用精确率、召回率、AUC等指标结合重采样或者调整决策阈值加了特征之后交叉验证得分下降新特征噪声太大做特征选择、检查特征工程逻辑调完参测试集分数比验证集低很多调参过程泄漏了验证集信息或者测试集太小重新切分、保留一个真正的独立测试集这张速查表我是从大量实际项目中总结出来的。先对照症状再决定排查方向比闷头调模型高效得多。很多问题看着像模型不对实际是数据切分或者评估策略出了问题先改那边模型性能立刻就有变化。在实际项目里的一次亲身体会最后再分享一个小细节。前阵子帮朋友排查一个风控模型的评估问题他死活想不明白为什么自己加了那么多好特征交叉验证得分反而越来越低。我上去看了一眼代码发现他每次做特征筛选之前都把整个数据集拿来算了缺失值比例和相关性然后筛完特征再切分数据做交叉验证。问题就出在这——特征筛选的环节已经看完了全量数据的分布再去做交叉验证数据早就“不干净”了。后来我把特征筛选挪到Pipeline里让每一次交叉验证的每一折都在训练集上独立做特征筛选验证得分马上恢复理性。这个案例让我更加笃定一个观点模型评估的结果其实反映了你的整个数据处理流程是否严谨而不只是模型这一个环节的参数好坏。用Scikit-learn评估模型本质上是在用一套客观方法给自己整个建模流程打分。把评估这步做好、做扎实你得到的不只是几个漂亮的数字而是一个经得起推敲、上得了线、扛得住真实数据考验的模型。
阅读完成 · 觉得有帮助？
