持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第19天，点击查看活动详情
想象一下，你训练了一个机器学习模型。 也许，有几个候选模型可供选择。
您在测试集上运行它们并获得了一些质量估计。 模型没有过拟合。 特征是有意义的。 总体而言，鉴于手头的数据有限，它们的表现尽他们所能。
现在，是时候决定它们中的任何一个是否足以用于生产用途。 除了标准性能检查之外，如何评估和比较您的模型？
在本教程中，我们将通过一个示例详细介绍如何评估您的模型。
示例：预测员工流失
我们将使用来自 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 预测的不同场景。
例如，我们只能对第二个模型的前 5% 预测采取行动。 在测试集上，它对应的概率阈值为 66%。 所有具有较高预测概率的员工都被认为有可能离开。
在这种情况下，只剩下 18 个预测。 但其中有 14 个是正确的！ 召回率下降到只有 23.7%，但准确率现在是 77.8%。 我们可能更喜欢它而不是原来的 69% 精确率，以最大限度地减少误报。
为了简化概念，我们可以在类分离图上想象一条线。
在实践中，我们可以通过以下两种方式之一进行限制：
- 通过仅对 top-X 预测采取行动
- 通过将概率大于 X 的所有预测分配给正类。
第一个选项可用于批处理模型。 如果我们一次为所有员工生成预测，我们可以对它们进行排序并选取前 5%。
如果我们根据要求进行个别预测，那么选择自定义概率阈值是有意义的。
这两种方法中的任何一种都可以根据用例起作用。
我们也可能决定以不同的方式可视化标签。 例如，将每位员工的流失风险标记为高、中或低。 它需要基于预测概率的多个阈值。
在这种情况下，我们将额外注意模型校准的质量，如类分离图所示。
总而言之，我们会考虑精确率召回率权衡来评估我们的模型并选择应用场景。 我们不是为每个人显示预测，而是选择一个阈值。 它帮助我们只关注流失风险最高的员工。
示例 3：有选择地应用模型
我们也可以采取第三种方法。
当查看两个模型的不同图表时，出现了一个明显的问题。 图表上的圆点背后的具体员工是谁？ 这两种模型在预测来自不同角色、部门、经验水平的离职人员方面有何不同？
这种分析可能会帮助我们决定何时应用模型，何时不应用。 如果有明显的模型失败的部分，我们可以排除它们。 或者，反过来，我们只能应用模型表现良好的地方。
在界面中，我们可以显示“信息不足”之类的内容。 这可能比一直犯错要好！
表现不佳的段
为了更深入地了解表现不佳的段，让我们分析分类质量表。 对于每个特征，它将预测概率与特征值一起映射。
通过这种方式，我们可以看到模型在哪里出错，以及它们是否依赖于单个特征的值。
让我们举个例子。
这是一个职位级别特征，它是角色资历的特定属性。
如果我们对 Level 1 的员工最感兴趣，第一个模型可能是一个不错的选择！ 它以高概率做出了一些自信的预测。 例如，在 0.6 阈值处，该组中只有一个误报。
如果我们想预测 Level 3 的辞职情况，第二个模型看起来要好得多。
如果我们希望我们的模型适用于所有 Level，我们可能会再次选择第二个模型。 平均而言，它在Level 1、2 和 3 中具有可接受的性能。
但同样有趣的是，这两个模型在Level 4 和 Level 5上的表现如何。对于这些组中的员工所做的所有预测，概率明显低于 0.5。 两种模型总是分配一个“negative”标签。
如果我们查看真实标签的分布，我们可以看到在这些工作级别中，辞职的绝对数量非常低。 很可能在训练中也是如此，并且该模型没有为该段（segment）选择任何有用的模式。
如果我们要在生产中部署模型，我们可以构建一个简单的业务规则并将这些segments从应用程序中排除。
我们还可以使用此分析的结果将我们的模型放在“绩效改进计划”中。 也许，我们可以添加更多数据来帮助模型？
例如，我们可能有最初从训练中排除的“旧”数据。 我们可以选择性地为表现不佳的部分增加我们的训练数据集。 在这种情况下，我们将添加更多关于Level 4 和 Level 5 员工辞职的旧数据。
总而言之，我们可以识别模型失败的特定部分（segments）。 我们仍然为尽可能多的员工展示预测。 但知道该模型远非完美，我们仅将其应用于全体员工中表现最佳的部分。
还能了解模型的什么行为？
同样的表还可以帮助我们更详细地了解模型的行为。 我们可以探索错误、异常值，并了解模型学到了什么。
例如，我们已经看到，第一个模型只能自信地预测少数辞职。 第二个模型从我们的数据中“捕捉”了更多有用的信号。 它从何而来？
如果我们查看我们的特征，我们可以得到一个提示。
例如，第一个模型成功地预测了那些对公司来说相对较新的人的辞职。 第二种模型可以检测到具有长达 10 年经验的潜在离职者。 我们可以从这个图表中看出：
我们可以在股票期权级别看到类似的情况。
第一个模型只能成功地预测那些 Level 0 的人。即使我们有相当多的辞职者，至少在 Level 1 也是如此！
第二个模型捕获了更多离职的更高级别（Level）的人。
但是，如果我们看一下加薪（即最近的加薪），我们会注意到没有明确的部分，其中任何一个模型的表现更好或更差。
除了第一个模型的一般特征之外，没有特定的“skew”可以做出更少的自信预测。
类似的分析可以帮助在模型之间进行选择或找到改进它们的方法。
就像上面的 JobLevel 示例一样，我们可能有办法扩充我们的数据集。 我们可能会添加其他时期的数据或包含更多特征。 在段（segments）不平衡的情况下，我们可以尝试给予特定示例更多的权重。 作为最后的手段，我们可以添加业务规则。
我们有赢家！
回到我们的例子：第二个模型是大多数场景的赢家。
但谁会只看 ROC AUC 就发誓呢？
我们必须超越单一指标来深入评估模型。
它适用于许多其他用例。性能比准确率更重要。 并且并不总是可以为每种错误类型分配直接的“成本”以对其进行优化。 将模型视为产品，分析必须更加细致入微。
不要忽视用例场景并将我们的标准与它联系起来，这一点至关重要。 可视化可能有助于与不以 ROC AUC 术语思考的业务利益相关者进行交流。
附属细则
本教程不是关于辞职预测，而是更多关于模型分析！
如果您希望解决类似的用例，让我们指出这个玩具数据集中至少有一些限制。
我们缺少一个关键数据点：辞职类型。人们可以自愿离开、被解雇、退休、搬到全国各地，等等。这些都是不同的事件，将它们组合在一起可能会产生模棱两可的标签。专注于“可预测”类型的辞职或解决多类问题是有意义的。
关于所执行的工作没有足够的上下文。其他一些数据可能更好地表明流失：绩效评估、特定项目、晋升计划等。这个用例需要与领域专家一起仔细构建训练数据集。
没有关于时间和辞职日期的数据。我们无法解释事件的顺序，也无法与公司历史上的特定时期相关联。
最后但并非最不重要的一点是，像这样的用例可能非常敏感。
您可以使用类似的模型来预测一线人员的流动情况。目标是预测招聘部门的工作量和相关的招聘需求。不正确的预测可能会导致一些财务风险，但这些风险很容易被考虑在内。
但如果该模型用于支持有关个别员工的决策，其影响可能会更加严重。例如，考虑分配培训机会时的偏见。我们应该评估用例的伦理并审核我们的数据和模型的偏见和公平性。
原文链接：What Is Your Model Hiding? A Tutorial on Evaluating ML Models
