你的模型隐藏了什么？ 一个评估 ML 模型的教程（Evidently）（上）

示例：预测员工流失

我们将使用来自 Kaggle 比赛的虚构数据集。 目标是确定哪些员工可能很快从公司离职。

这个想法听起来很简单：通过早期警告，您可能会阻止此人离开。 有价值的专家会留在公司——无需寻找新员工并等到他们学会了这些概念。

让我们尝试提前预测那些处于风险中的人！

首先，我们检查训练数据。 它是为我们方便地收集的。 经验丰富的数据科学家会产生怀疑！

让我们认为这是理所当然的，跳过构建数据集的困难部分。

我们拥有 1,470 名员工的数据。

‍共有 35 个特征描述了如下内容：‍

• 员工背景（学历、婚姻状况等）
• 工作详情（部门、工作级别、出差需要等）
• 工作经历（在公司工作的年限、上次晋升日期等）
• 报酬（薪水、股票期权等）
• 和其他一些特征。

还有一个二分类标签可以查看谁离开了公司。 这正是我们需要的！

‍我们将问题定义为概率分类任务。 该模型应估计每个员工属于目标“attrition”类别的可能性。

在处理模型时，我们通常将其拆分为训练和测试数据集。 我们使用第一个来训练模型。 我们保留其余部分以检查它在看不见的数据上的表现。

我们不会详细介绍模型训练过程。 我们相信这就是您知道的数据科学魔法！

假设我们进行了相当多的实验。 我们尝试了不同的模型，调整了超参数，在交叉验证中进行了区间评估。

我们最终得到了两个看起来同样出色的技术上合理的模型。

接下来，我们检查了它们在测试集上的表现。 这是我们得到的模型：

• ROC AUC 得分为 0.795 的随机森林模型
• ROC AUC 得分为 0.803 的 Gradient Boosting 模型

ROC AUC 是在概率分类的情况下优化的标准指标。 如果你为这个 Kaggle 用例寻找众多解决方案，大多数人都会这样做。

我们的两个模型看起来都很好。 比随机切分要好得多。ROC AUC 分数接近。 鉴于这只是一个单点估计，我们可以假设性能大致相同。

我们应该选择两者中的哪一个？

同样的质量，不同的质量

让我们更详细地看一下模型。

我们将使用 Evidently 开源库来比较模型并生成性能报告。

如果你想一步一步来，这里有一个完整的 Jupyter notebook 示例。

首先，我们训练了这两个模型并在相同的测试数据集上评估了它们的性能。

接下来，我们将两个模型的性能日志准备为两个 pandas DataFrame。每个都包括输入特征、预测类别和真实标签。

我们指定列映射来定义target位置、predicted类别以及分类（categorical）和数字（numerical）特征。

然后，我们调用evidently选项卡来生成分类性能报告。它在单个仪表板中显示两个模型的性能，以便我们进行比较。

dashboard = Dashboard(tabs=[ProbClassificationPerformanceTab]) 
dashboard.calculate(rf_merged_test, 
    cat_merged_test, 
    column_mapping = column_mapping
    ) 
dashboard.show()
复制代码

我们将我们更简单的随机森林模型作为基线。对于这个工具，它成为“Reference”。第二个梯度提升（Gradient Boosting ）被表示为正在评估的“Current”模型。

我们可以快速查看测试集上两个模型的性能指标概要。

现实生活不是 Kaggle，所以我们并不总是关注某个指标。 如果我们只看准确率和 ROC AUC，这两个模型的性能看起来非常接近。

我们甚至可能有理由喜欢更简单的随机森林模型。 例如，因为它更具可解释性或具有更好的计算性能。

但 F1 分数的差异暗示故事可能还有更多内容。 模型的内部工作方式各不相同。

关于不平衡类问题的复习

精明的机器学习者知道诀窍。 我们两个类别的人数远不相等。 在这种情况下，准确度指标几乎没有用处。 即使这些数字“on paper”看起来不错。

target类别通常有一个较小的类别。 我们想预测一些罕见但重要的事件：欺诈、流失、辞职。 在我们的数据集中，只有 16% 的员工离开了公司。

如果我们建立一个简单的模型，将所有员工归类为“可能留下”，我们的准确率是 84%！

ROC AUC 并没有给我们一个完整的画面。 相反，我们必须找到更适合预期模型用途的指标。

拥有“好”模型意味着什么？

如果一个模型能简单地指出那些即将辞职的人并且总是正确的，那就太好了。 那么我们可以做任何事情！ 理想模型适用于任何用例，但不会在现实中出现。

相反，我们处理不完善的模型以使它们对我们的业务流程有用。 根据应用程序，我们可能会选择不同的模型评估标准。

没有单一的指标是理想的。 但是模型不是凭空存在的，我们希望你从为什么开始！

让我们考虑不同的应用场景并在此背景下评估模型。

示例 1：给每个员工贴标签

在实践中，我们可能会将模型集成到一些现有的业务流程中。

假设我们的模型用于在内部 HR 系统的界面中显示标签。 我们希望突出显示高风险流失率的每位员工。当经理登录系统时，他们会看到部门中每个人的“高风险”或“低风险”标签。

我们希望为所有员工显示标签。 我们需要我们的模型尽可能“正确”。 但我们已经知道，准确度指标隐藏了所有重要的细节。 我们将如何评估我们的模型？

除了准确率之外

让我们回到evidently报表，更深入地分析这两种模型的性能。

我们可以很快注意到两个模型的混淆矩阵看起来不同。

我们的第一个模型只有 2 个误报。 听起来不错？ 事实上，它并没有给我们太多关于潜在辞职的错误警报。

但是，另一方面，它正确地确定了只有 6 人辞职。 其他 53 人错过了。

第二个模型错误地将 12 名员工标记为高风险。 但是，它正确预测了 27 人的辞职。 它只错过了32。

具有按类别划分的质量指标的图总结了这一点。 让我们看一下“yes”类别。

精确率大致相同：当模型预测辞职时，在 69-75% 的情况下它是正确的。

但是第二个模型在召回率中获胜！ 它发现 45% 的人离开了公司，而第一个模型只有 10%。

你会选择哪个模型？

最有可能的是，在目标“resignation”类中召回率较高的模型会获胜。 它可以帮助我们发现更多可能离开的人。

我们可以容忍一些误报，因为解释预测的是经理。 已经存在于 HR 系统中的数据也提供了额外的上下文。

更有可能的是，必须添加可解释性。 它可以帮助用户解释模型预测并决定何时以及如何做出反应。

总而言之，我们将根据召回指标评估我们的模型。 作为非 ML 标准，我们将添加经理对该特征的可用性测试。 具体来说，将可解释性视为界面的一部分。

示例 2：发送主动警报

假设我们期望在模型之上执行特定操作。

它可能仍与相同的人力资源系统集成。 但现在，我们将根据预测发送主动通知。

也许是一封给经理的电子邮件，提示安排与有风险的员工会面？ 或者可能的保留措施的具体建议，例如额外的培训？

在这种情况下，我们可能会对这些误报有额外的考虑。

如果我们过于频繁地向经理发送电子邮件，它们很可能会被忽略。不必要的干预也可能被视为负面结果。

我们应该做什么？

如果我们没有任何新的有价值的特征要添加，我们就剩下我们拥有的模型。我们不能挤压更多的准确率。但是，我们可以限制我们采取行动的预测数量。

目标是只关注那些预测风险很高的员工。

精确率召回率权衡

概率模型的输出是 0 到 1 之间的数字。要使用预测，我们需要在这些预测概率之上分配标签。二分类的“默认”方法是在 0.5 处截断。如果概率较高，则标签为“yes”。

相反，我们可以选择不同的阈值。也许，0.6 甚至 0.8？通过将其设置得更高，我们将限制误报的数量。

但这是以召回率为代价的：我们犯的错误越少，正确预测的数量也就越少。

evidently报表中的这个类分离图使这个想法非常直观。它在实际（actual）标签旁边显示了单独的预测概率。

我们可以看到第一个模型做出了一些非常自信的预测。 稍微“向上”或“向下”调整阈值不会对绝对数字产生很大影响。

‍然而，我们可能会意识到模型能够挑选一些具有高确信的事例。 例如，如果我们认为误报的成本非常高。 在 0.8 处进行截止将提供 100% 的精确率。 我们只会做两个预测，但两个都是正确的。

‍如果这是我们喜欢的行为，我们可以从一开始就设计出这样一个“果断”的模型。 它将强烈惩罚误报并在概率范围的中间做出更少的预测。（老实说，这正是我们为这个演示所做的！）。

第二个模型的预测概率更加分散。 更改阈值会产生不同的情况。 我们可以通过查看图像来做出大致的估计。 例如，如果我们将阈值设置为 0.8，它只会给我们留下几个误报。

‍更具体地说，让我们看一下precision-recall表。 它旨在帮助在类似情况下选择阈值。 它显示了 top-X 预测的不同场景。