文章譯者：追風者

內容來源：Datawhale

如何在投入生產前評估機器學習模型性能？

想象一下，你訓練了一個機器學習模型。也許，可以從中選幾個候選方案。

你在測試集上運行它，得到了一些質量評估。模型沒有過度擬合，特徵也有意義。總的來說，在現有的有限數據下，它們的表現盡善盡美。

**現在，是時候來決定它們是否好到可以投入生產使用了。**如何在標準性的質量評估外，評估和比較你的模型呢？

在本教程中，我們將通過一個案例，詳細介紹如何評估你的模型。

案例：預測員工流失情況

我們將使用一個來自 Kaggle 競賽的虛構數據集，目標是識別哪些員工可能很快離開公司。

這個想法聽起來很簡單：有了預警，你可能會阻止這個人離開。一個有價值的專家會留在公司——無需尋找一個新的員工，再等他們學會工作技巧。

讓我們試着提前預測那些有風險的員工吧！

首先，檢查訓練數據集。它是爲方便我們使用而收集的。一個經驗豐富的數據科學家會產生懷疑！我們將其視爲理所當然，並跳過構建數據集的棘手部分。

我們有 1470 名員工的數據。

共 35 個特徵，描述的內容包括：

• 員工背景（教育、婚姻狀況等）。

• 工作細節（部門、工作級別、是否出差等）。

• 工作歷史（在公司工作年限、最後一次晉升日期等）。

• 薪酬（工資、股票意見等）。

以及其他一些特徵。

還有一個二元標籤，可以看到誰離開了公司。這正是我們所需要的！我們將問題定義爲概率分類任務。模型應該估計每個員工屬於目標 "流失" 類的可能性。

在研究模型時，我們通常會將數據集分成訓練和測試數據集。我們使用第一個數據集來訓練模型，用其餘的數據集來檢查它在未知數據上的表現。

我們不詳細介紹模型訓練過程。這就是數據科學的魔力，我們相信你是知道的！

假設我們進行了很多次實驗，嘗試了不同的模型，調整了相應的超數，在交叉驗證中進行了區間評估。

我們最終得到了兩個合理的模型，看起來同樣不錯。

接下來，檢查它們在測試集上的性能。這是我們得到的結果。

• 隨機森林模型的 ROC AUC 值爲 0. 795 分

• 梯度提升模型的 ROC AUC 評分爲 0.803 分。

ROC AUC 是在概率分類的情況下優化的標準指標。如果你尋找過 Kaggle 這個用例的衆多解決方案，這應該是大多數人的做法。

我們的兩個模型看起來都不錯。比隨機拆分好得多，所以我們肯定可以從數據中得到一些線索。

ROC AUC 分數很接近。鑑於這只是一個單點估計（single-point estimate），我們可以認爲性能相似。

那麼問題來了，兩者之間我們應該選哪個呢？

同樣的質量，不同的特點

讓我們更詳細地分析這些模型。

我們將使用 Evidently 開源庫來比較模型並生成性能報告。

如果你想一步一步地跟着做，可以在文末打開這個完整的 upyter Notebook。

首先，我們在同一個測試數據集上訓練兩個模型並評估性能。

接下來，我們將兩個模型的性能日誌準備成兩個 pandas 數據框 (DataFrames）。每個包括輸入特徵、預測類和真實標籤。

我們指定了列映射來來定義目標的位置，預測的類別，以及分類和數字特徵。

然後，我們調用 evidently tabs 來生成分類性能報告。在單個的 dashboard 中顯示兩個模型的性能，以便我們可以比較它們。

comparison_report = Dashboard(rf_merged_test, cat_merged_test, column_mapping = column_mapping, tabs=[ProbClassificationPerformanceTab]) 
comparison_report.show()

我們將較簡單的隨機森林模型作爲基準，對於這個工具來說，它成爲 "參考（Reference）"。第二個梯度提升被表示爲 "當前（Current）" 的評估模型。

我們可以快速看到兩個模型在測試集上的性能指標彙總。

現實情況不是 Kaggle，所以我們並不總是關注第二位數。如果我們只看準確率和 ROC AUC，這兩個模型的性能看起來非常接近。

我們甚至可能有理由去偏愛更簡單的隨機森林模型，源於它更強的可解釋性，或者更好的計算性能。

但 F1-score 的差異暗示可能還有更多故事。模型的內部運作方式各不相同。

重溫類別不平衡問題

精明的機器學習者知道其中的竅門。兩個類別的規模遠不相等。在這種情況下，準確度的衡量標準是沒有太大意義的。即使這些數字可能在 "論文" 上看起來很好。

目標類通常是一個次要的類。我們希望預測一些罕見但重要的事件，比如：欺詐、流失、辭職。在我們的數據集中，只有 16% 的員工離開了公司。

如果我們做一個樸素的模型，只是把所有員工都歸類爲 "可能留下"，我們的準確率是 84%！

ROC AUC 並不能給我們一個完整的答案。相反，我們必須找到更適合預期模型性能的指標。

何謂 "好的" 模型？

你知道其中的答案：這要視情況而定。

如果一個模型能簡單地指出那些即將辭職的人，並且永遠是對的，那就太好了。那麼我們就可以做任何事情了！一個理想的模型適合任何用例——但這往往不會在現實中出現。

相反，我們處理不完美的模型，使它們對我們的業務流程有用。根據應用，我們可能會選擇不同的標準來評估模型。

沒有一個單一的衡量標準是理想的。但模型並不是存在於真空中——希望你可以從提出問題開始！

讓我們考慮不同的應用場景，並在此背景下評估模型。

示例 1：給每個員工貼標籤

在實踐中，我們可能會將該模型集成到一些現有的業務流程中。

假設我們的模型用於在內部人力資源系統的界面上顯示一個標籤，我們希望突出顯示每個具有高損耗風險的員工。當經理登錄系統時，他們將會看到部門中每個人的 "高風險" 或 "低風險" 標籤。

我們希望爲所有員工顯示標籤。我們需要的模型儘可能的 "正確"。但我們知道，準確度指標隱藏了所有重要的細節。我們將如何評估我們的模型呢？

超越準確度

讓我們回到 evidently 的報告中，更深入地分析兩種模型的性能。

我們能夠很快注意到，兩個模型的混淆矩陣看起來是不同的。

我們的第一個模型只有兩個假陽性（false positives）。聽起來很不錯？的確，它沒有給我們太多關於潛在辭職的錯誤提醒。

但是，另一方面，它只正確識別了 6 次辭職。其他的 53 個都被漏掉了。

第二個模型錯誤地將 12 名員工標記爲高風險。但是，它正確預測了 27 個辭職。它只漏掉了 32 人。

按類別劃分的質量指標圖總結了這一點。讓我們看看 "yes" 類別。

但第二個模型在召回率中勝出！它發現 45% 的人離開了公司，而第一個模型只有 10%。

你會選擇哪個模型呢？

最有可能的是，在目標 "辭職" 類別中，召回率較高的那一個會贏。它可以幫助我們發現更多可能離職的人。

我們可以容忍一些假陽性，因爲解釋預測的是經理。人力資源系統中已有的數據也提供了額外的背景。

更有可能的是，在其中增加可解釋性是必不可少的。它可以幫助用戶解釋模型預測，並決定何時以及如何做出反應。

總而言之，我們將基於召回率指標來評估我們的模型。作爲一個非 ML 標準，我們將添加經理對該功能的可用性測試。具體來說，要把可解釋性作爲界面的一部分來考慮。

示例 2：發送主動警報

讓我們想象一下，我們期望在模型上有一個特定的行動。

它可能會與同一個人力資源系統進行整合。但現在，我們將根據預測發送主動通知。

也許，給經理發送一封電子郵件，提示安排與有風險的員工會面？或者是對可能的留用環節提出具體建議，比如額外的培訓等等。

在這種情況下，我們可能對這些假陽性有額外的考慮。

如果我們過於頻繁地給經理們發送郵件，他們很可能會被忽略。不必要的干預也可能被視爲一種負面結果。

我們該怎麼辦？

如果沒有任何新的有價值的功能可以添加，我們就只能使用現有的模型。我們無法榨取更多的精度。但是，可以限制採取行動的預測數量，目標是隻關注那些預測風險較高的員工。

精度 - 召回率權衡

概率模型的輸出是一個介於 0 和 1 之間的數字，爲了使用預測，我們需要在這些預測的概率上分配標籤。二元分類的 "默" 方法是以 0.5 爲切入點。如果概率較高，標籤就是 "yes"。

我們可以選擇一個不同的閾值，也許，0.6 甚至 0.8？通過設置更高的閾值，我們將限制假陽性的數量。

但這是以召回率爲代價的：我們犯的錯誤越少，正確預測的數量也越少。

這個來自 evidently 報告的類別分離圖（Class Separation）讓這個想法非常直觀。它在實際標籤旁邊顯示了各個預測概率。

我們可以看到，第一個模型做出了幾個非常自信的預測。稍微 "上調" 或 "下調" 閾值，在絕對數字上不會有太大的差別。

然而，我們可能會欣賞一個模型，並挑選出幾個具有高置信度的案例的能力。例如，如果我們認爲假陽性的成本非常高。在 0.8 處做一個分界點，就能得到 100% 的精度。我們只做兩個預測，但都是正確的。

如果這是我們喜歡的行爲，我們可以從開始就設計這樣一個 "決定性" 的模型，它將強烈地懲罰假陽性，並在概率範圍的中間做出較少的預測。(事實上，這正是我們在這個演示中所做的！）。

第二個模型的預測概率比較分散。改變閾值會產生不同的情況。我們只需看一下圖示，就能做出大致的估計。例如，如果我們將閾值設置爲 0.8，就會讓我們只剩下幾個假陽性。

更具體地說，讓我們看看精度 - 召回表。它旨在類似情況下選擇閾值。它顯示了 top-X 預測的不同情況。

例如，我們可以只對第二個模型的前 5% 的預測採取行動。在測試集上，它對應的概率閾值爲 66%。所有預測概率較高的員工都被認爲有可能離職。

在這種情況下，只剩下 18 個預測。但其中 14 個將是正確的！召回率下降到只有 23.7%，但現在的精度是 77.8%。我們可能更喜歡它，而不是原來的 69% 精度，以儘量減少誤報。

爲了簡化概念，我們可以想象一下類別分離圖上的一條線。

在實踐中，我們可以通過以下兩種方式之一進行限制：

• 只對 topX 預測採取行動

• 將所有概率大於 X 的預測分配給正類。

第一種方案可用於批量模型。如果我們一次生成所有員工的預測，我們可以對它們進行分類，比如說，前 5%。

如果我們根據要求進行個別預測，那麼選取一個自定義的概率閾值是有意義的。

這兩種方法中的任何一種都可以工作，這取決於具體用例。

我們也可以決定用不同的方式來可視化標籤。例如，將每個員工標記爲高、中、低流失風險。這將需要基於預測概率的多個閾值。

在這種情況下，我們會額外關注模型校準的質量，這一點從類別分離圖上可以看出。

綜上所述，我們會考慮精度 - 召回率的權衡來評估我們的模型，並選擇應用場景。

我們不顯示每個人的預測，而是選擇一個閾值。它幫助我們只關注流失風險最高的員工。

示例 3：有選擇地應用模型

我們還可以採取第三種方法。

當看到兩個模型的不同圖譜時，一個明顯的問題出現了。圖上的小點背後的具體員工是誰？兩種模型在預測來自不同角色、部門、經驗水平的辭職者時有什麼不同？

這種分析可能會幫助我們決定什麼時候應用模型，什麼時候不應用模型。如果有明顯的細分市場，模型失效，我們可以將其排除。或者反過來說，我們可以只在模型表現好的地方應用模型。

在界面中，我們可以顯示 "信息不足" 這樣的內容。這可能比一直錯誤要好！

低性能部分

爲了更深入地瞭解表現不佳的片段，我們來分析一下分類質量表（Classification Quality Table）。對於每個特徵，它將預測的概率與特徵值一起映射。

這樣，我們就可以看到模型在哪些方面犯了錯誤，以及它們是否依賴於單個特徵的值。

我們舉個例子。

這裏有一個工作等級（Job Level）特徵，它是角色資歷的特定屬性。

如果我們對 1 級的員工最感興趣，那麼第一個模型可能是一個不錯的選擇！它能以高概率做出一些有把握的預測。例如，在 0.6 的閾值下，它在這個羣體中只有一個假陽性。

如果我們想預測 3 級的辭職情況，第二個模型看起來要好得多。

如果我們希望我們的模型對所有級別都有效，我們可能會再次選擇第二個模型。平均而言，它在 1、2、3 級中的表現可以接受。

但同樣有趣的是，這兩個模型在第 4 級和第 5 級上的表現 。 對這些羣體中的員工做出的所有預測，概率都明顯低於 0.5。兩種模型總是分配一個 "負" 的標籤。

如果我們看一下真實標籤的分佈，我們可以看到，在這些工作級別中，辭職的絕對數量相當低。很有可能在訓練中也是如此，模型並沒有發現任何有用的模式。

由於我們比較的是同一測試數據集上的性能，所以分佈是相同的。

如果我們要在生產中部署一個模型，我們可以構建一個簡單的業務規則，將這些片段（segments）從應用中排除。

我們也可以利用這個分析的結果，把我們的模型放在一個 "性能改進計劃" 上。也許，我們可以添加更多的數據來幫助模型。

例如，我們可能有一些 "舊的" 數據，而這些數據是我們最初從訓練中排除的。我們可以有選擇地增強訓練數據集，用於表現不佳的部分。在這種情況下，我們會添加更多關於 4 級和 5 級員工辭職的舊數據。

綜上所述，我們可以識別出模型失敗的特定細分片段，我們仍然顯示出對儘可能多的員工的預測。但知道模型遠非完美，我們只對表現最好的那部分員工進行應用。

模型知道什麼？

這張表同樣可以幫助我們更詳細地瞭解模型的行爲。我們可以探索誤差、離羣值，並瞭解模型的學習情況。

例如，我們已經看到，第一個模型只預測了少數有把握的辭職。第二個模型從我們的數據中 "捕捉" 到了更多有用的信號。它是從哪裏來的呢？

如果通過我們的特徵，可以得到一個提示。

比如說，第一個模型只成功預測了那些相對新進公司的人的辭職，第二個模型可以檢測出有 10 年以下工作經驗的潛在離職者。我們可以從這個圖中看到。

我們可以從股票期權等級（stock options level）中看到類似的情況。

第一個模型只成功預測了 0 級的員工。即使我們有不少重新加入的員工，至少也是 1 級的！第二種模型捕獲到了更多等級較高的離職者。

但如果我們看加薪（即最近的加薪），我們會發現沒有明顯的細分，無論哪個模型的效果都更好或更差。

除了第一種模型的一般特徵外，並沒有具體的 "傾斜"，做出較少的置信預測。

類似的分析可以幫助在模型之間進行選擇，或者找到改進模型的方法。

就像上面工作級別的例子一樣，我們可能有辦法來增強我們的數據集。我們可能會添加其他時期的數據，或者包含更多的特徵。在類別不平衡的情況下，我們可以嘗試給特定例子更多的權重。作爲最後的手段，我們也可以添加業務規則。

我們找到了贏家！

回到我們的例子：第二種模式是大多數情況下的贏家。

但誰會只看 ROC AUC 就被信服了呢？我們必須超越單一的指標來深入評估模型。

它適用於許多其他用例。性能比準確度更重要。而且並非總是可以爲每種錯誤類型分配簡單的 "成本" 來對其進行優化。像對待產品一樣對待模型，分析必須更加細緻入微。

關鍵是不要忽視用例場景，並將我們的標準與之掛鉤。可視化可能有助於那些不以 ROC AUC 思考的業務相關者進行溝通。

提示：本教程不用於辭職預測，而是模型分析

如果你想解決類似的用例，我們至少要指出這個數據集的幾個限制。

• 我們缺乏一個關鍵的數據點：辭職的類型。人們可以自願離職、被解僱、退休、搬到全國各地等等。這些都是不同的事件，將它們歸爲一類可能會造成模糊的標籤。如果把重點放在 "可預測" 的辭職類型上，或者解決多類問題來代替，會比較合理。

• 關於所從事的工作，沒有足夠的上下文。一些其他數據可能會更好地表明流失情況：績效評估、特定項目、晉升規劃等。這種用例需要與領域專家一起精心構建訓練數據集。

• 沒有關於時間和辭職日期的數據。我們無法說明事件的順序，並與公司歷史上的特定時期有關。

最後提醒一點：像這樣的用例可能是高度敏感的。

你可能會使用類似的模型來預測一線人員的流動率。目標是預測招聘部門的工作量和相關的招聘需求。不正確的預測可能會導致一些財務風險，但這些很容易考慮進去。

但如果該模型用於支持對單個員工的決策，其影響可能會更加關鍵。例如，考慮分配培訓機會時的偏差。我們應該評估使用案例的道德規範（the ethics of the use case），並審覈我們的數據和模型是否存在偏見和公平（bias and fairness）。

參考鏈接：

• 本文所用數據集地址：https://www.kaggle.com/pavansubhasht/ibm-hr-analytics-attrition-dataset

• Evidently 開源庫：https://github.com/evidentlyai/evidently

• Jupyter notebook 地址：https://github.com/evidentlyai/evidently/blob/main/evidently/examples/ibm_hr_attrition_model_validation.ipynb

• 原文地址：https://evidentlyai.com/blog/tutorial-2-model-evaluation-hr-attrition

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/uTwfMqhHONs5pSHVf_AKDQ