準確率會騙人：混淆矩陣、Precision、Recall、AUC 與閾值

一個延遲預警系統，整體準確率89%；另一個什麼都不做，永遠預測「準時」，準確率卻有90%。應該直接把第一個系統丟掉嗎？

還需要知道它們各自錯在哪裡。如果真正延遲只占一成，永遠預測準時自然能猜對九成，卻一張延遲都抓不到。你在意的是整體猜對幾張、不要漏掉延遲，還是不要讓客服收到太多誤報？不同問題需要不同分母。

這篇沿用系列的配送預警教學數表，再用既有教材圖拆開混淆矩陣、分類閾值與排名指標。所有配送數字都是假想設定；原圖另有Iris花卉與互動玩具資料，不代表本站訓練成果。

先定義正類，再把四種結果排清楚

先把「真的延遲」定為正類，把「發出預警」定為預測正類。正類只是一個明確選定的事件，不代表好事或壞事。

假設10,000張訂單中有1,000張延遲；預警抓到其中800張，另外把900張準時訂單也標成延遲：

真實結果＼預測結果	發出預警	不發預警	合計
真的延遲	800，TP	200，FN	1,000
實際準時	900，FP	8,100，TN	9,000
合計	1,700	8,300	10,000

TP是真正例：該抓的抓到了；FN是偽負例：漏掉真正延遲；FP是偽正例：把準時誤報成延遲；TN是真負例：準時且沒有發警報。

這就是二元混淆矩陣。它把錯誤種類分開，才有辦法談哪種錯誤較昂貴。

scikit-learn三類Iris混淆矩陣，真實類別在縱軸、預測類別在橫軸 — 圖1｜原圖是三類花卉，縱軸True label、橫軸Predicted label；中間那列16筆真實versicolor中，3筆猜對、13筆猜成virginica。先看軸，再讀格子。來源：scikit-learn developers，Confusion matrix，BSD 3-Clause，完整聲明見文末；原圖未改，本文未重跑來源實驗。

不同工具可能把真實與預測放在相反方向，正類也可能排在不同位置。不要只記「左上角叫什麼」；先看標籤，必要時自己寫回四種情境。

Accuracy、Recall、Precision：分母各自是誰？

Accuracy問全部訂單中猜對多少；Recall問真正延遲中抓到多少；Precision問發出去的預警中有多少真的延遲。

指標	算式	本文配送例子	回答的問題
Accuracy，準確率	(TP＋TN)／全部	8,900／10,000＝89%	整體有幾成猜對？
Recall，召回率／TPR	TP／(TP＋FN)	800／1,000＝80%	真正延遲抓到幾成？
Precision，精確率	TP／(TP＋FP)	800／1,700≈47.1%	收到預警有幾成真的延遲？
FPR，偽正率	FP／(FP＋TN)	900／9,000＝10%	準時訂單中有幾成被誤報？

Recall高，不代表Precision高。這個系統抓到八成延遲，同時產生900個誤報，因此收到預警後真正延遲的比例不到一半。

FPR與「預警裡有幾成誤報」也不同。 FPR的分母是所有實際負類；後者的分母則是所有預測正類。本例預警中誤報的比例是900／1,700≈52.9%，不是10%。

若準時訂單遠多於延遲，即使FPR看起來不大，誤報絕對數仍可能很多。這也是基率改變時，Precision會跟著改變的原因；不能只帶著Recall與FPR就假定新城市的預警一樣可信。

百分比矩陣，先確認它除的是列、欄還是全體

scikit-learn按真實類別逐列正規化的Iris混淆矩陣 — 圖2｜來源以每列真實類別筆數作分母，因此versicolor列的3／16顯示0.19、13／16顯示0.81。這不是用預測類別作分母的Precision。來源同圖1，原圖未改。

按真實類別逐列歸一化，方便看每一類有多少被辨認、多少混到別類；按預測類別逐欄歸一化，則方便看各預測類別的組成；按總筆數歸一化，又是在看另一種比例。軸若交換，列欄名稱也會跟著改，應以語意確認分母。

多類別評估還要知道最後怎麼彙總。各類別等權平均與按樣本數加權，可能給少數類別完全不同的份量。報一個平均分數時，最好也留下逐類筆數與結果。

F1可以濃縮兩個指標，不能代替成本與容量

F1是Precision與Recall的調和平均，二元形式也可以寫成：

F1 = 2×TP / (2×TP + FP + FN)
本文例子 = 1,600 / (1,600 + 900 + 200) ≈ 59.3%

當你希望兩者都顧到，F1提供一個比較方式；但它不包含TN，也沒有自動反映客服每次誤報要花幾分鐘、漏掉延遲會造成多大損失，或每天最多能處理幾張預警。

如果從不發出預警，Precision的分母會是0，不能把它描述為「沒有誤報，所以Precision100%」。工具可能依設定回傳0、NaN或警告；必須交代零分母的處理，而不是只取一個好看的數字。

前面的永遠準時基準Accuracy90%、Recall0%，不會因此滿足延遲預警的任務。反過來，也不能只因新系統有Recall，就略過它帶來的誤報成本。兩者要放回同一份保留資料與同一個業務問題比較。

分數變成分類，中間還有一個閾值

分類模型常先給一個分數，再依閾值決定要不要發預警。0.5只是可能的設定，不是所有應用必須使用的標準。模型輸出落在0到1，也不表示已經驗證為可靠的機率。

以下兩張是Google互動教材的同一個Separated玩具資料集，總共99筆。方框與圓點代表真實類別，分界位置決定預測類別；它與本文10,000張訂單無關。

Google互動教材閾值0.10，矩陣為TP48、FP43、FN0、TN8 — 圖3｜閾值0.10時有91筆被判為正類：抓到48筆真正例，也帶入43筆誤報，Recall100%、Precision約52.7%。注意這張矩陣的真實類別在欄、預測類別在列，和上面的scikit-learn原圖方向不同。來源：Google，Thresholds and the confusion matrix，CC BY 4.0，擷取原互動頁，未改樣本數值。

同一Google教材將閾值提高到0.90，矩陣為TP7、FP0、FN41、TN51 — 圖4｜閾值0.90時只判7筆為正類，這7筆都正確，但漏掉另外41筆真正例；Precision100%、Recall約14.6%。來源同圖3，擷取同一玩具資料集的另一閾值，未改樣本數值。

提高閾值時，預測正類的集合縮小，TP與FP都不會增加，FN與TN則不會減少。因此Recall會不增、FPR也會不增；但Precision是兩個變動數量的比值，不能保證每次提高閾值都嚴格增加Precision。

分數恰好等於閾值時，判正還是判負，也要看實作的 > 或 >= 規則。離散分數或大量同分的資料，這個差別可能影響不少樣本。

ROC：把每一個閾值變成一個座標點

ROC橫軸是FPR，縱軸是TPR，也就是Recall。每選一個閾值，都能從四格計數算出一個點；掃過閾值就得到曲線。

Google ROC原圖以A、B、C標出同一模型的不同閾值位置 — 圖5｜越往右上走，通常抓到更多正例，也接受更多負例誤報。A、B、C是操作點，不是三次重訓。來源：Google，ROC and AUC，CC BY 4.0，原圖未改。

從左上角附近選操作點，有助看抓取與誤報的取捨；但幾何上最近的點，不會自動等於業務成本最低的點。預警處理容量、基率、誤報與漏報代價，都需要另外帶進決策。

Google理想分類器的ROC與面積1.0 — 圖6｜理想排序可在某個閾值同時達到TPR1、FPR0；圖內面積為1。這是理想示意，不是實際模型成效。來源同圖5，原圖未改。

Google以對角線表示隨機排名基準，ROC-AUC為0.5 — 圖7｜對角線代表隨機排名的理論基準。有限樣本的隨機分數曲線會有波動，不必剛好貼住對角線。來源同圖5，原圖未改。

ROC-AUC可以理解為：隨機選一個正例與一個負例，正例排得較前面的機率；同分時依慣例計半分。它評估排名，不是「有幾成樣本分類正確」，也不是分數已校準的保證。

AUC高，仍要看你實際使用哪一段曲線

Google示例模型的ROC-AUC0.65 — 圖8｜原教材用這張曲線示意一個整體排名面積較小的模型。來源同圖5，原圖未改。

Google另一示例模型的ROC-AUC0.93 — 圖9｜較大的整體面積是另一項比較資訊，但不能單靠面積決定最終閾值。兩圖均為來源示意，非本站模型比較。來源同圖5，原圖未改。

不同模型的ROC可能交叉：整體AUC較高，不保證在極低誤報率區間也比較好。如果一天只能處理少量預警，應直接檢查這個容量下抓到多少，而不是只挑整條曲線面積最大者。

AUC也不會替你處理資料洩漏、時間分布改變或重要子群表現。它只描述當前評估資料與分數之間的排序關係。

PR曲線：直接看預警名單的品質與涵蓋率

PR曲線以Recall為橫軸、Precision為縱軸。對少數正類問題，它讓「抓到多少」與「抓到的有多少是真的」直接放在同一張圖。

Google PR示意圖橫軸Recall、縱軸Precision，標示PR AUC0.623 — 圖10｜這張面積是PR座標下的面積，不能拿0.623與前面ROC-AUC的數字直接比較。來源同圖5，原圖未改。

ROC的FPR分母是所有負類；當負類非常多，FPR很小仍可能有大量誤報。PR直接把誤報放進預警名單的分母，常能揭露這個問題。但PR也受正類比例影響，不同基率資料上的Precision不能直接橫比。

scikit-learn二元Precision-Recall曲線與正類比例基準，圖例標示AP0.91 — 圖11｜原圖標記LinearSVC的AP約0.91，水平基準約0.52對應此資料的正類比例。PR基準不固定是0.5；這張圖也不是前面的配送資料。來源：scikit-learn developers，Precision-Recall，BSD 3-Clause，完整聲明見文末；原圖未改，本文未重跑來源實驗。

AP，average precision，常用每次Recall增加量乘上對應Precision再加總。它與對PR點做梯形插值後的面積，計算方式不同，數值可能不同。報告中的「PR-AUC」要註明算法，不要把不同套件的AP與梯形面積都當成完全相同的指標。

最後選的是一個使用方案，不只是一個數字

先在開發資料上選模型與閾值，再用未參與選擇的保留資料評估。把測試集上的最佳閾值當成上線方案，再報同一份測試分數，會讓最後評估受到選擇影響。

交付時至少留下正類定義、四格筆數、資料範圍與切分方式、閾值及同分規則。再依問題補Recall、Precision、FPR、預警數量與成本／容量；需要比較排序時才加ROC或PR與其計算法。

一個分數讓你快速比較，一組清楚的分母與假設，才讓別人知道這個比較能支持什麼。

來源與圖像授權

scikit-learn developers，Confusion matrix：Iris原始筆數與逐真實類別正規化圖。
Google，Accuracy, recall, precision, and related metrics：各指標分母與使用取捨。
Google，Thresholds and the confusion matrix：原互動玩具資料的0.10／0.90兩個狀態。
Google，ROC and AUC：ROC、PR與AUC示意。Google原圖／互動頁擷取依CC BY 4.0使用，見網站政策，未改來源數值。
scikit-learn developers，Precision-Recall：PR原圖與AP；依BSD 3-Clause使用，完整聲明附於下方。

本文10,000張訂單是系列另設教學例子，沒有使用真實企業資料，也沒有宣稱重現來源的模型結果。

圖像授權聲明

以下保留scikit-learn原圖的完整BSD聲明；原作者沒有為本站背書。

BSD 3-Clause License

Copyright (c) 2007-2026 The scikit-learn developers.
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:

* Redistributions of source code must retain the above copyright notice, this
  list of conditions and the following disclaimer.

* Redistributions in binary form must reproduce the above copyright notice,
  this list of conditions and the following disclaimer in the documentation
  and/or other materials provided with the distribution.

* Neither the name of the copyright holder nor the names of its
  contributors may be used to endorse or promote products derived from
  this software without specific prior written permission.

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

封面取自本文Google ROC操作點原圖，等比縮放加白邊；手機閾值圖將原畫面的分數圖與混淆矩陣上下編排，保留原樣本與數值。這些版本同樣依CC BY 4.0使用，來源與署名見上述正文。