准确率98%却零召回：混淆矩阵与精确度召回率实战

评估报告上写着 accuracy = 0.983，评审会上没人提异议，模型顺利上线。三周之后业务方找过来，说这套风控规则"一个坏账都没拦住"。回头翻评估日志才发现，测试集里坏样本只占 1.7%，模型把所有样本都判成了"正常"，光靠这一招就拿到了 98.3% 的准确率。真正例、假正例、真负例、假负例这四个格子没数清楚，精确度和召回率一个都没看，准确率再漂亮也只是个自欺欺人的数字。这篇就把这四个概念从"背定义"拉到"能上手用"的层面，不管你是刚学机器学习的学生、要做模型验收的工程师，还是只想搞懂业务报表里那几个指标含义的产品，看完都能自己算、自己判断该盯哪个数。

1. 那份准确率 98% 的报告，问题出在哪

1.1 一个把所有样本都判成"正常"的分类器

先把场景摆出来。假设你在做交易异常检测，测试集一万笔交易，其中真正异常的只有 170 笔，剩下 9830 笔都正常。现在有一个"懒惰"的模型，它对任何输入都输出"正常"。算一下它的准确率：9830 / 10000 = 98.3%。这个数字放在任何一份汇报 PPT 里都不难看。

但它抓到了几个异常？零个。业务方要的是把那 170 笔捞出来，模型却一笔都没报。准确率这个指标在这里完全失效了，因为它把"预测对正常样本"和"预测对异常样本"当成了同等重要的事，而现实中这两件事的价值差着几个数量级。

这就是类别不平衡场景下最常见的评估陷阱：当某一类样本占绝对多数时，准确率会被多数类绑架。你优化准确率，模型最省力的做法就是永远预测多数类。想绕开这个坑，就必须把"预测对"这件事拆开看——拆成四种情况，也就是混淆矩阵的四个格子。

1.2 混淆矩阵：把"对"与"错"拆成四个格子

混淆矩阵（Confusion Matrix）这个名字起得挺形象，它就是把模型搞混的地方摊开给你看。二分类问题里，每个样本的最终结果只有四种可能，对应四个格子：

• 真正例（True Positive, TP）：事实是正类，模型也判成正类。判对了。
• 假正例（False Positive, FP）：事实是负类，模型却判成正类。误报。
• 真负例（True Negative, TN）：事实是负类，模型也判成负类。判对了。
• 假负例（False Negative, FN）：事实是正类，模型却判成负类。漏报。

四个格子加起来等于样本总数：TP + FP + TN + FN = N。这个恒等式看着简单，但它是后面所有指标的根基——精确度、召回率、F1、特异度、ROC 曲线，全都是从这四个数里做加减乘除变出来的。换句话说，只要你把这四个格子数对了，剩下的指标都是算术题。

注意：不同教材、不同工具里混淆矩阵的行列摆放顺序并不统一。有的把"预测值"放行、"真实值"放列，有的正好反过来。看别人的图表之前，先确认一下行列标签，否则 TP 和 TN 很容易看反。

2. 四个名字为什么这么起：拆词就拆明白了

2.1 第一个字说对错，第二个字说预测成了什么

这四个中文译名其实翻译得相当讲究，只要会拆词就不会记混。规则是：前一个字（真/假）描述"这次预测对不对"，后两个字（正例/负例）描述"模型预测成了什么"。

按这个规则套一遍：

• 真正例：预测成了正例，而且这个判断是真的（对的）→ 事实也是正例。
• 假正例：预测成了正例，但这个判断是假的（错的）→ 事实是负例。
• 真负例：预测成了负例，而且这个判断是真的（对的）→ 事实也是负例。
• 假负例：预测成了负例，但这个判断是假的（错的）→ 事实是正例。

关键在于，"真正例/假正例"里的正负，说的是预测结果的标签，不是事实的标签。很多人记混就是因为下意识把"假正例"理解成"假的正例"，以为事实是正例只是判错了——恰恰相反，假正例的事实是负例，是模型硬把一个负例抬成了正例。

2.2 拿垃圾邮件过滤器当例子过一遍

抽象定义记不住，就挂一个具体场景。假设你训练了一个垃圾邮件过滤器，"垃圾邮件"是正类，"正常邮件"是负类。

• 一封真垃圾邮件被拦进垃圾箱 →真正例。你想要的，拦截成功。
• 一封正常邮件被误判成垃圾、扔进垃圾箱 →假正例。误杀，用户会骂人。
• 一封正常邮件被正确放进收件箱 →真负例。风平浪静。
• 一封真垃圾邮件被放进了收件箱 →假负例。漏网之鱼，用户会烦。

再换一个医疗筛查的场景，"患病"是正类：

• 病人被正确诊断为患病 → 真正例。
• 健康人被误诊为患病 → 假正例（虚惊一场，要复查）。
• 健康人被正确判为健康 → 真负例。
• 病人被漏诊为健康 → 假负例（这个最要命）。

同一个模型结构，换一个业务场景，FP 和 FN 的严重程度完全不同。垃圾邮件场景里 FP 更讨厌，疾病筛查场景里 FN 更致命。这也是后面选择指标时要看业务的原因。

2.3 一张表把四个格子钉在脑子里

把上面的内容压成一张表，行是模型预测，列是客观事实：

对角线上的 TP 和 TN 是判对的，反对角线上的 FP 和 FN 是判错的。这份表建议在草稿纸上画三遍，比看十遍文字描述都管用。我自己的习惯是在代码注释里直接写死这个布局，免得过两个月回头改动时行列搞混。

还有一个容易忽略的点："正例"到底是哪一类，是你自己定义的，不是数据自带的。sklearn 默认认为标签值大的那一类或者标签为 1 的那一类是正例。如果你想评估的是"少数类"而不是"标签为 1 的类"，就得手动指定pos_label，否则算出来的精确度和召回率可能刚好是反的，这种错误非常隐蔽，报表看起来一切正常，结论却完全颠倒。

3. 精确度与召回率：两个问题，两种问法

3.1 精确度问的是"你报出来的有多少靠谱"

精确度（Precision），有些地方也叫查准率，公式是：

Precision = TP / (TP + FP)

看分母：所有被模型判为正例的样本。也就是说，精确度评价的是"模型报出来的这批正例，有多少是真的"。

拿医院打比方。医生给一批病人做了手术，精确度问的就是：这刀开下去的人里，有多少是真的需要开刀的。分母是"被开了刀的人"，分子是"开对了的人"。如果精确度低，说明医生乱开刀的多，把很多不需要手术的人也推上了手术台。

精确度关心的是误报（FP）。FP 越多，分母越大而分子不变，精确度就往下跌。所以精确度这个指标，天生对"狼来了"很敏感。

3.2 召回率问的是"该找出来的你找到了多少"

召回率（Recall），也叫查全率，公式是：

Recall = TP / (TP + FN)

看分母：所有事实上为正例的样本。召回率评价的是"这批真正该被找出来的样本，模型找出来了多少"。

还用医院的例子。召回率问的是：所有真正患病的病人里，有多少被诊断出来了。分母是"所有真病人"，分子是"被揪出来的病人"。召回率低，说明漏诊多，有病的人没查出来，混在健康人群里走了。

召回率关心的是漏报（FN）。FN 越多，分母不变而分子越小，召回率就往下跌。所以召回率这个指标，天生对"漏网之鱼"很敏感。

3.3 分母的差别就是全部的差别

很多人搞不清这两个指标，问题都出在没盯住分母。把公式并排写出来看：

• Precision = TP / (TP + FP)，分母是预测为正例的总数，也就是混淆矩阵里"预测正例"那一行的和。
• Recall = TP / (TP + FN)，分母是事实为正例的总数，也就是混淆矩阵里"事实正例"那一列的和。

一个看行，一个看列，这是它们最本质的区别。所以有个很好用的记忆法：精确度沿着"预测"方向横着看，召回率沿着"事实"方向竖着看。你只要在草稿纸上画好矩阵，用尺子横着划一下算精确度，竖着划一下算召回率，基本不会错。

顺便提两个常跟它俩一起出现的量。一个是特异度（Specificity）= TN / (TN + FP)，衡量"负例里有多少被判对"，可以理解成"负类视角的召回率"。另一个是真正例率 TPR = TP / (TP + FN)，你会发现它和召回率的公式一模一样——是的，召回率就是 TPR，只是换了个名字、换了个使用场合（画 ROC 曲线的时候一般叫 TPR）。而假正例率FPR = FP / (FP + TN)，分母是全部真实的负例。这几个量互相之间的换算关系很紧密，记住一个通常就能推出其余几个。

4. 为什么这两个数总在互相拆台

4.1 阈值：决定模型"多大胆"的那根滑杆

绝大多数分类模型输出的不是一个硬邦邦的类别，而是一个概率或者分数。比如逻辑回归给你 0.73，梯度提升树给你 -1.2 的 logit。真正把它变成"正例/负例"的，是你设的那条阈值线。

阈值就是模型胆子大小的旋钮：

• 阈值调低 → 判为正例的门槛变松 → 更多样本被报出来 → 抓到的真阳性变多，召回率上升，但顺手带进来的假阳性也变多，精确度下降。
• 阈值调高 → 只有非常有把握的样本才敢报正 → 报出来的几乎都是真的，精确度上升，但很多真阳性因为分数不够被压下去了，召回率下降。

这就解释了为什么这两个指标总在打架：它们共享同一个分子 TP，但分母一个盯着你报了多少（FP 惩罚），一个盯着你漏了多少（FN 惩罚）。你想扩大战果，就必然引入噪声；你想保证质量，就必然放过一些目标。不存在一个阈值能同时让两者都最优，除非模型本身足够强。

4.2 手算一遍，把阈值滑动看明白

光讲道理不够直观，拿一组具体的分数算一遍。假设有 10 个样本，真实标签和模型打分如下（1 为正类，0 为负类）：

真实的状况是：正例 5 个（A、B、D、F、I），负例 5 个（C、E、G、H、J）。

取阈值 0.7（严格，大于 0.7 才判正）：只有 A（0.90）和 B（0.80）被报出来。

• TP = 2（A、B 果然是正例）
• FP = 0（没有误报）
• FN = 5 - 2 = 3（D、F、I 被漏掉）
• Precision = 2 / (2 + 0) = 1.00
• Recall = 2 / 5 = 0.40

阈值卡得严，报出来的全对，但十成里只抓到了四成。

取阈值 0.3（宽松，大于等于 0.3 才判正）：A、B、C、D、E、F、G、H 都被报出来。

• TP = 4（A、B、D、F）
• FP = 4（C、E、G、H 都是假的）
• FN = 1（只剩 I 被漏掉）
• Precision = 4 / 8 = 0.50
• Recall = 4 / 5 = 0.80

阈值一放松，召回率从 0.40 涨到 0.80，精确度从 1.00 掉到 0.50。这组数字把 P-R 权衡演示得清清楚楚：没有一个阈值是"对"的，只有"更适合当前业务"的。

手动算这一遍的价值在于，你会真正理解为什么模型评估报告里要给出 PR 曲线（每个阈值算一组 P、R，连成一条线），而不是只报一个数。PR 曲线就是把上面这个实验从两个阈值扩展到全部可能的阈值，画出来的一条轨迹。

4.3 F1 是妥协，不是解药

P 和 R 打架，想用一个数把它俩捏起来，最常见的做法是F1 分数（F1-Score）：

F1 = 2 × Precision × Recall / (Precision + Recall)

这是精确度和召回率的调和平均。为什么用调和平均而不是普通的算术平均？因为算术平均对极端值太宽容。假设 Precision = 1.0、Recall = 0.1，算术平均是 0.55，看着还不错，但实际上这个模型基本没检出任何东西。换成调和平均算一下：2 × 1.0 × 0.1 / (1.0 + 0.1) = 0.18，一下子把短板暴露出来了。调和平均的特点是"被小的那个数拖后腿"，正好符合"两个指标都要过得去才算好模型"的诉求。

如果业务上对某一侧更敏感，还有带权版本Fβ：β 大于 1（常见取 2）时更看重召回率，β 小于 1（常见取 0.5）时更看重精确度。F2 常用于安全检测、疾病筛查这类"漏一个代价很大"的场景。

不过要提醒一句：F1 是个妥协产物，它把两个有明确业务含义的数字压成了一个没有明确业务含义的数字。汇报给业务方的时候，我不建议只丢一个 F1 过去，还是要把 P 和 R 分开报，再说清楚当前阈值是怎么选的。F1 适合在你需要横向对比多个模型、快速排序的时候用。

5. 该盯精确度还是召回率：算一下错一次的代价

5.1 两种错法的代价从来不对称

选指标的本质，是比较FP 的代价和FN 的代价。这两个代价在几乎所有真实业务里都不相等，有时甚至差好几个数量级。

一个朴素的判断方法：问业务方一句话——"报错了和被漏掉，你更怕哪个？"

• 更怕"报错"（FP 代价高）→ 优先保精确度。
• 更怕"漏掉"（FN 代价高）→ 优先保召回率。

5.2 宁可错杀和宁可放过的典型场景

优先保召回率的场景（宁可错杀，不可放过）：

• 疾病初筛：漏诊一个病人，可能延误治疗甚至危及生命；误诊一个健康人，只是多做几项复查，代价可控。
• 反欺诈预警：漏掉一笔欺诈交易，是真金白银的损失；误报一笔正常交易，顶多让人工审核一下。
• 召回阶段的信息检索：搜索引擎的第一轮抽取宁可多召回一些候选，精确排序交给后面几轮做。
• 工业设备异常预警：漏掉一次设备异常，可能导致整条产线停机；误报一次，只是多一次巡检。

优先保精确度的场景（宁可放过，不可错杀）：

• 垃圾邮件拦截：把所有正常邮件误判成垃圾，用户直接不用了；漏掉几封垃圾邮件，用户手动删一下就行。
• 自动化决策/自动执行类系统：比如自动扣款、自动封号，误触发一次就是事故，宁可先不动，交给人工兜底。
• 司法或信用类辅助判断：把无辜的人卷进来，代价远大于放过个别案例。
• 推荐系统的强干预：推送一条明显不相关或者冒犯性的内容，用户对产品的信任会直接打折。

5.3 一张对照表帮你快速定位

表格只能给个起点，真实项目里我还是建议用钱算一遍。假设每笔误报的人工审核成本是 5 元，每笔漏报的平均损失是 500 元，那么 FN 的代价是 FP 的 100 倍，模型阈值就该往低了压，让召回率优先。把代价量化成货币单位，比空泛地争论"该不该提高召回"有效得多，这也是我在实际项目里最常用的说服业务方的手段。

5.4 PR 曲线和 ROC 曲线，什么时候看哪个

评估报告里常见的另外两个图是 PR 曲线和 ROC 曲线。

• ROC 曲线：横轴是 FPR，纵轴是 TPR（也就是召回率）。它的好处是对类别不平衡相对不敏感，因为 FPR 的分母是全部真实负例，样本里负例再多也不会让 FPR 数值结构崩掉。
• PR 曲线：横轴是召回率，纵轴是精确度。它直接暴露了精确度在不平衡数据上的表现。

经验上的取舍是：当正例非常稀少（比如低于 5%）的时候，优先看 PR 曲线和 PR-AUC。因为此时 ROC 曲线会被大量的真负例"撑得很漂亮"，AUC 看着 0.95，实际精确度可能只有 0.2。ROC-AUC 高不代表模型在少数类上有用，这在异常检测类项目里是高频踩坑点。

6. 从二分类走到多分类：宏平均和微平均在平均什么

6.1 一对多拆解：每个类别轮流当正例

现实中大部分问题是多分类，比如新闻分类有 10 个类别。多分类的 P/R 是通过**一对多（One-vs-Rest）**的方式算出来的：把第 1 类当正例、其余 9 类当负例，算一组 P 和 R；再把第 2 类当正例，算一组；如此循环 10 次，得到 10 组指标。

关键问题是：这 10 组数字怎么合成一个能写进报告的结论？这就是宏平均和微平均的分歧所在。

6.2 宏平均与微平均：一个"按类投票"，一个"按样本说话"

宏平均（Macro Average）：把每个类别的 P、R 分别算出来，然后直接求算术平均。每个类别无论样本多少，权重都一样。

微平均（Micro Average）：先不分类别，把所有类别的 TP 加在一起、FP 加在一起、FN 加在一起，得到全局的 TP、FP、FN，再套公式算一次。效果上等价于"把每个样本平等看待"。

这两者在样本分布均衡时差别不大，一旦不均衡就会严重打架。举个例子：3 个类别，A 类 1000 个样本，B 类 10 个，C 类 10 个。模型在 A 类上表现很好（P=0.95, R=0.95），在 B、C 两个小类上表现很差（P=0.3, R=0.2）：

• 宏平均：三个类别等权，每个占 1/3，小类的糟糕表现被放大了，结果会被拉低到 0.4 左右。
• 微平均：A 类样本占绝对多数，全局指标基本被 A 类主导，结果接近 0.94。

同一份预测结果，宏平均 0.4、微平均 0.94，差了两倍还多。如果你关心的是小类的识别效果（比如罕见病、长尾商品），就该看宏平均；如果关心的是整体吞吐的准确程度，看微平均更合适。

还有第三种叫加权平均（Weighted Average），按每个类别的样本数加权，是宏平均和微平均之间的折中。sklearn 的classification_report三种都会给你，但很多人只看最后一行微平均，把真正暴露问题的小类数字忽略了。

6.3 多分类下真正例假正例怎么数

从"每个类别轮流当正例"这个角度看，多分类的混淆矩阵其实就是把二分类的四个格子扩展成了 K×K 的矩阵。第 i 行第 j 列的元素，表示"事实是第 i 类、被预测成第 j 类"的样本数。

• 对角线上的数字（i = j）就是每一类的真正例数 TP。
• 第 i 行的非对角元素之和，是"事实第 i 类但被预测成别的类"总数，也就是第 i 类的假负例 FN。
• 第 j 列的非对角元素之和，是"事实不是第 j 类却被预测成第 j 类"总数，也就是第 j 类的假正例 FP。

所以看多分类报告时，最该盯的不是那些对角线上的大数字，而是非对角线上的异常值——哪两类之间频繁混淆，往往暗示这两类的特征空间有重叠，或者标注标准本身就不清晰。这个信息比一个总体的 F1 有用得多，也是我在模型调优阶段最先看的地方。

7. 代码实操：手算和库函数对不上时怎么查

7.1 用 sklearn 跑一遍，和手算结果对齐

理论过完，落到代码上验证一遍。下面这段就是用刚才那 10 个样本的数据，验证第 4 节手算的结果：

import numpy as np from sklearn.metrics import confusion_matrix, precision_score, recall_score, f1_score y_true = np.array([1, 1, 0, 1, 0, 1, 0, 0, 1, 0]) scores = np.array([0.90, 0.80, 0.70, 0.60, 0.55, 0.45, 0.40, 0.30, 0.20, 0.10]) for thr in (0.7, 0.3): y_pred = (scores > thr).astype(int) cm = confusion_matrix(y_true, y_pred) print(f"阈值 {thr} 混淆矩阵:\n{cm}") # 注意 pos_label 和 zero_division 要显式指定，否则警告一堆 print("Precision:", precision_score(y_true, y_pred, pos_label=1, zero_division=0)) print("Recall: ", recall_score(y_true, y_pred, pos_label=1, zero_division=0)) print("F1: ", f1_score(y_true, y_pred, pos_label=1, zero_division=0)) print("-" * 30)

跑出来阈值 0.7 时 Precision = 1.0、Recall = 0.4；阈值 0.3 时 Precision = 0.5、Recall = 0.8，和第 4 节手算的完全一致。这种"先手算再跑库"的对照习惯非常值得养成，尤其在你第一次接触新指标的时候，它可以帮你确认自己对公式的理解和库实现的定义是一致的。

confusion_matrix返回的矩阵布局是[[TN, FP], [FN, TP]]，跟第 2 节那张表（行是预测、列是事实）的摆放不一样。第一次看很容易看反，建议打印之后立刻用纸笔对照确认一遍。

7.2 几个把我坑得比较惨的地方

说几个实际排查过的坑，都是文档里写得不显眼、但踩上去很疼的：

第一，正例标签的定义。precision_score默认把 1 当正例，如果标签是字符串或别的数字，要么报错，要么悄悄按错误的类别算。我遇到过一次标签是"yes"/"no"的项目，同事直接跑precision_score，代码没报错但自动把"no"当正例（因为字母序），算出来的精确度和预期完全反了，白排查了两小时。解决办法是永远显式传pos_label。

第二，average参数的默认行为。二分类时average='binary'是对的，多分类如果不显式传average='macro'或'weighted'，会直接报错或者给出一个你并不想要的结果。这个参数在多分类项目里必须写死。

第三，predict出来的结果本身就是某个阈值下的硬分类。很多人以为model.predict()是一个"客观结果"，其实对二分类模型来说，它就是概率大于 0.5 之后做的截断。你想调整 P/R 平衡，改阈值就行，不需要重新训练模型。但要注意，如果阈值不是 0.5，那就不能用predict了，得自己拿predict_proba算。

第四，zero_division参数。当某个类别一个样本都没被预测出来时，精确度会出现 0/0，sklearn 会给你个警告并默认填 0。这在长尾数据里非常常见，看起来是 0 分，但其实是"没预测"，两者的业务含义完全不同。

7.3 一张自查清单，验收前过一遍

模型交付前我一般会按这个清单过一遍，也能省掉不少返工：

模型评估这件事，说到底就是把"预测对了"这四个字拆开算清楚。真正例、假正例、真负例、假负例这四个格子是所有指标的根，精确度和召回率分别从"预测行"和"事实列"两个方向盯住它们。我自己的习惯是，拿到任何一个分类问题，先在纸上画一遍矩阵，标出 FP 和 FN 分别对应业务里的什么损失，再去决定优化哪个方向。这么做之后，和业务方的沟通顺畅多了，因为你谈的不再是"精确度 0.85"，而是"误报成本和漏报成本哪个更高"。指标是给人做决策用的，脱离了业务语境，再精确的数字也说明不了什么。