017、mAP 评价指标手动计算：Precision-Recall 曲线积分与 mAP 0.5:0.95 的实现
从一次模型评估翻车说起
去年有个项目，我训练了一个YOLOv5s检测行人，验证集mAP 0.5显示0.89，心里美滋滋。结果部署到实际场景，漏检率高达30%。排查了半天，发现是mAP计算时，我直接调用了torchmetrics的接口，但那个版本默认的IoU阈值是0.5，而我的目标是小行人，IoU 0.5太宽松了，很多半身遮挡的框都被算成正样本。后来我手动实现了mAP 0.5:0.95的计算，才发现0.5和0.95的mAP差距能到0.3以上。从那以后，我再也不敢把mAP当黑盒用了。
Precision-Recall曲线：别被平滑的曲线骗了
很多人以为PR曲线是连续的、光滑的，像教科书画的那样。实际计算时，PR曲线是阶梯状的，因为预测框的置信度是离散的。我们按置信度降序排列所有预测框，然后逐个判断是否匹配到GT。
假设一张图里有3个GT框，模型输出了5个预测框，置信度分别是0.95、0.85、0.75、0.65、0.55。我们设定IoU阈值0.5，逐个判断：
- 置信度0.95的框：和GT1的IoU=0.6，匹配成功，TP=1，FP=0，此时Precision=1/1=1.0，Recall=1/3≈0.333
- 置信度0.85的框：和GT2的IoU=0.55，匹配成功，TP=2，FP=0，Precision=1.0，Recall=2/3≈0.667
- 置信度0.75的框：和GT3的IoU=0.3，匹配失败，TP=2，FP=1，Precision=2/3≈0.667，Recall=0.667
- 置信度0.65的框：和GT1的IoU=0.7，但GT1已经被匹配过了，这个框算重复检测，FP=2，Precision=2/4=0.5，Recall=0.667
- 置信度0.55的框：和GT2的IoU=0.4，匹配失败，FP=3，Precision=2/5=0.4，Recall=0.667
这里有个坑：重复检测的处理。YOLO的NMS已经去重了，但如果你自己写评估代码，一定要记得每个GT只能匹配一次。我见过有人把重复检测也算TP，结果mAP虚高。
积分计算AP：11点插值 vs 全点插值
得到PR曲线后，AP就是曲线下的面积。但PR曲线是阶梯的，积分就是求和。有两种主流方法：
11点插值法（VOC 2007标准）：在Recall 0.0到1.0之间均匀取11个点（0.0, 0.1, …, 1.0），每个点取该Recall右侧的最大Precision。比如Recall=0.667时，右侧最大Precision是0.667（因为后面Precision更低），所以Recall=0.7对应的Precision也是0.667。然后对这11个点求平均。
全点插值法（VOC 2010后标准，也是COCO标准）：直接对PR曲线所有转折点积分。每个Recall区间取该区间内最大的Precision。比如上面例子，Recall从0.333到0.667，Precision保持1.0，这段面积是(0.667-0.333)*1.0=0.334。Recall从0.667到1.0，Precision是0.667，面积是(1.0-0.667)*0.667≈0.222。总AP=0.334+0.222=0.556。
实际代码里，我习惯用全点插值，因为更精确。但要注意，计算前要把Precision序列做“右侧最大”处理，也就是从右向左遍历，把每个点的Precision更新为它右侧所有点中最大的Precision。这一步很多人漏掉，导致AP偏低。
mAP 0.5:0.95：10个IoU阈值的平均
COCO的mAP 0.5:0.95，就是在IoU阈值从0.5到0.95，步长0.05，共10个阈值下分别计算AP，然后取平均。每个IoU阈值下，匹配规则不同：IoU越高，匹配越严格。
比如IoU=0.5时，预测框和GT的IoU大于0.5就算匹配；IoU=0.95时，必须大于0.95才算匹配。所以高IoU下，很多框会被判为FP，AP会显著下降。
实现时，我通常先对所有预测框按置信度排序，然后对每个IoU阈值，遍历一遍预测框，计算TP/FP。但这样10个阈值就要遍历10次，效率低。优化方法是：对每个预测框，预先计算它和所有GT的IoU矩阵，然后对每个IoU阈值，直接查表判断是否匹配。这样只需要一次IoU计算。
代码实现：逐行解析
defcompute_mAP(pred_boxes,gt_boxes,iou_thresholds=[0.5:0.05:0.95]):# pred_boxes: list of dict, 每个dict包含'boxes', 'scores', 'labels'# gt_boxes: list of dict, 每个dict包含'boxes', 'labels'# 1. 按置信度排序所有预测框all_preds=[]forimg_id,predinenumerate(pred_boxes):forbox,score,labelinzip(pred['boxes'],pred['scores'],pred['labels']):all_preds.append({'img_id':img_id,'box':box,'score':score,'label':label})# 按置信度降序排序，这里踩过坑：一定要降序，升序会导致PR曲线反着走all_preds.sort(key=lambdax:x['score'],reverse=True)# 2. 对每个类别分别计算APclass_aps=[]forclsinunique_labels:# 筛选当前类别的预测框和GTcls_preds=[pforpinall_predsifp['label']==cls]cls_gts=[gforgingt_boxesifg['label']==cls]# 统计每个图片的GT数量gt_counts={}forgincls_gts:gt_counts[g['img_id']]=gt_counts.get(g['img_id'],0)+1total_gts=sum(gt_counts.values())# 对每个IoU阈值计算APaps_per_iou=[]foriou_thriniou_thresholds:# 初始化TP/FP数组，长度等于预测框数量tp=[0]*len(cls_preds)fp=[0]*len(cls_preds)# 记录每个GT是否已被匹配gt_matched={g['img_id']:[False]*len(g['boxes'])forgincls_gts}# 别这样写：gt_matched = {} 然后动态添加，容易漏掉空GT的图片fori,predinenumerate(cls_preds):img_id=pred['img_id']# 找到当前图片的GTimg_gts=[gforgincls_gtsifg['img_id']==img_id]ifnotimg_gts:fp[i]=1continue# 计算IoUbest_iou=0best_gt_idx=-1forj,gtinenumerate(img_gts):iou=compute_iou(pred['box'],gt['box'])ifiou>best_iou:best_iou=iou best_gt_idx=j# 判断是否匹配ifbest_iou>=iou_thrandnotgt_matched[img_id][best_gt_idx]:tp[i]=1gt_matched[img_id][best_gt_idx]=Trueelse:fp[i]=1# 计算Precision和Recalltp_cumsum=np.cumsum(tp)fp_cumsum=np.cumsum(fp)precisions=tp_cumsum/(tp_cumsum+fp_cumsum+1e-6)# 加小常数防止除零recalls=tp_cumsum/total_gts# 计算AP：全点插值# 先做右侧最大处理foriinrange(len(precisions)-2,-1,-1):precisions[i]=max(precisions[i],precisions[i+1])# 积分ap=0foriinrange(len(recalls)-1):ap+=(recalls[i+1]-recalls[i])*precisions[i+1]aps_per_iou.append(ap)# 当前类别的mAP是10个IoU阈值的平均class_aps.append(np.mean(aps_per_iou))# 最终mAP是所有类别的平均returnnp.mean(class_aps)这段代码有几个关键点：
- 排序降序：必须按置信度从高到低，否则PR曲线会乱。
- GT匹配记录：每个GT只能匹配一次，用布尔数组记录。
- 右侧最大处理：从右向左遍历，把Precision更新为右侧最大值。这一步很多人用循环实现，但numpy有更高效的方法：
np.maximum.accumulate(precisions[::-1])[::-1]。 - 积分：用相邻Recall的差值乘以右侧的Precision。注意是乘
precisions[i+1]，因为右侧最大处理后，每个点的Precision代表该Recall右侧的最大值。
个人经验：别踩这些坑
IoU计算精度：用float32就够了，但如果你用float16，累积误差会导致mAP波动0.01左右。我吃过这个亏，后来统一用float64计算IoU。
空类别处理：如果某个类别在验证集中没有GT，但模型输出了预测框，这个类别的AP怎么算？COCO官方是忽略这个类别，不参与平均。但有些实现会算成0，导致mAP偏低。建议统一：如果GT数量为0，跳过该类别。
多尺度预测：YOLO输出多个尺度的特征图，每个尺度有不同大小的锚框。计算mAP时，所有尺度的预测框要合并后统一排序，不能分开算。
置信度阈值：mAP计算时，通常不设置信度阈值，所有预测框都参与。但实际部署时，你会设一个阈值（比如0.5）来过滤低置信度框。所以mAP反映的是模型在所有置信度下的综合性能，而实际部署性能取决于你选的阈值。
mAP 0.5:0.95的物理意义：它衡量的是模型在不同定位精度要求下的平均表现。如果你的应用对定位精度要求不高（比如检测车辆，框稍微偏一点没关系），mAP 0.5更有参考价值。如果要求高精度定位（比如医学图像中的病灶检测），mAP 0.95才是关键。
调试技巧：当mAP异常低时，先检查IoU计算是否正确。我写过一个小脚本，随机生成几个预测框和GT，手动计算mAP，然后和代码输出对比。这样能快速定位问题。
最后说一句：mAP只是一个指标，别迷信它。我见过mAP 0.8的模型在实际场景中不如mAP 0.7的模型，因为mAP没有考虑推理速度、内存占用、小目标检测能力等。评估模型时，一定要结合你的业务场景，多看几个指标，比如F1-score、推理时间、模型大小。
