上周调一个YOLOv5的产线缺陷检测模型测试集准确率看着挺高上线后误报却把生产线搞停了。现场工程师抱怨“你们这模型怎么乱报警” 打开日志一看模型把几个正常工件上的划痕阴影也框出来了——典型的精度不足问题。这时候只盯着“准确率”已经没用了得搬出那套老伙计Precision、Recall、F1还有mAP。一、从混淆矩阵说起模型预测结果可以塞进一个2x2的表格里这就是混淆矩阵。别被名字吓到其实就是四个数TPTrue Positive模型说“是缺陷”实际也是缺陷。这是我们想要的。FPFalse Positive模型说“是缺陷”实际是正常。这就是误报产线停摆的元凶。FNFalse Negative模型说“正常”实际是缺陷。漏检可能放次品流入下道工序。TNTrue Negative模型说“正常”实际也正常。这个在目标检测里通常不单独算因为背景区域太大了。很多新手拿到模型就只看整体准确率但在类别不平衡的场景下比如缺陷样本只占1%模型全预测正常也能拿到99%的准确率——完全没意义。二、Precision宁可放过不可错杀Precision TP / (TP FP)翻译成人话所有模型报警的框里有多少是真的缺陷。这个指标对应的是“误报率”。在产线场景里误报会导致停机检查成本很高。所以有时候我们宁可调高阈值让模型只报把握大的缺陷哪怕漏掉一些不明显的。计算的时候注意TP和FP是按框算的不是按图片。一张图里模型可能预测10个框其中3个是TP7个是FP那这张图的Precision就是3/100.3。三、Recall宁可错杀不可放过Recall TP / (TP FN)翻译成人话所有真实缺陷里模型抓住了多少。这个指标对应的是“漏检率”。在安防、医疗场景下漏掉一个目标后果可能很严重这时候Recall就比Precision重要。但Recall高了往往Precision会降——模型为了不漏检会倾向于多报误报就上去了。这两个指标通常互相打架。四、F1 Score既要又要的权衡F1 2 * (Precision * Recall) / (Precision Recall)F1是Precision和Recall的调和平均数。它强迫两个指标都不能太低。如果Precision0.9Recall0.1算下来F1只有0.18很能说明问题。但F1也有坑它假设Precision和Recall同等重要。实际业务里往往需要根据成本调整权重。比如产线场景我可能更看重Precision那就用Fβ给Precision更高权重。五、AP和mAP目标检测的硬通货单张图片的Precision和Recall还好算整个数据集怎么办这时候就要看PR曲线——把置信度阈值从高到低滑动每个阈值对应一组(P,R)连起来就是曲线。APAverage PrecisionPR曲线下的面积。理想情况是曲线贴近右上角P1,R1面积接近1。实际计算时常用插值法VOC用的是11点插值COCO用的是101点插值后者更平滑。mAPmean Average Precision所有类别的AP平均值。多类别检测里这是核心指标。但要注意不同数据集的mAP计算细节可能不同比如COCO的mAP0.5:0.95是多个IoU阈值下的平均值比VOC的mAP0.5严格得多。六、代码里的坑# 计算单类AP的简化示例VOC风格defcompute_ap(tp,conf,n_gt):# tp: list of bool, 每个预测框是否是TP# conf: list of float, 每个预测框的置信度# n_gt: int, 该类别的真实框总数# 按置信度降序排序indicesnp.argsort(-conf)tptp[indices]# 计算累积的TP和FPtp_cumsumnp.cumsum(tp)fp_cumsumnp.cumsum([notxforxintp])# 这里踩过坑别用1-tpbool转int小心# 计算各点的Precision和Recallprecisiontp_cumsum/(tp_cumsumfp_cumsum1e-16)# 加epsilon防除零recalltp_cumsum/n_gt# VOC 11点插值ap0.0fortinnp.arange(0,1.1,0.1):maskrecalltifmask.any():apnp.max(precision[mask])/11# 注意这里是取最大值不是平均值returnap常见坑点IoU阈值没对齐训练时用0.5评估时用0.6结果对不上。务必确认评估代码的IoU阈值。重复预测框处理同一个真实框被多个预测框匹配时通常只留一个TP其他算FP。NMS参数会影响这个。置信度阈值影响mAP计算时通常用所有预测框阈值0但实际部署时会设阈值这时候的指标才是真实的。七、调试经验谈Precision低模型乱报框。先看FP里是不是有固定pattern——比如某种背景纹理总被误报。可能是训练数据缺少负样本或者数据增强太激进。试试加大分类损失权重或者加一些困难负样本挖掘。Recall低模型漏检。小目标漏检常见试试减小anchor尺寸或者用FPN结构。大目标漏检可能是感受野不够或者训练数据里同类目标太少。mAP卡在某个值上不去别光调模型回头看看标注质量。我遇到过标注框偏了几个像素导致IoU永远过不了0.9mAP0.9死活上不去。清洗一遍标注数据指标直接涨3个点。部署指标和测试指标对不上除了阈值差异还要看输入数据分布。测试集可能是精心挑选的真实数据可能有亮度、角度变化。做个简单的域适应比如加个灰度直方图匹配。最后说个反直觉的指标不是越高越好。产线场景下mAP从0.95提到0.96可能需要一个月但产线误报率从5%降到1%带来的收益更大。有时候在0.9的mAP基础上针对高频误报类别做数据增强比盲目追求全局指标更有效。模型评估不是跑完脚本看个数字就完事了。那些数字背后是真实的业务代价——误报的成本、漏检的风险。好的工程师应该能把这些数字翻译成业务语言告诉产品经理“把阈值调到0.7误报率会降一半但每100个缺陷会漏掉3个你们能接受吗”这才是指标存在的意义。