064、Validator验证流程源码：数据遍历到NMS到TP和FP 统计到mAP 汇总

064、Validator验证流程源码数据遍历到NMS到TP和FP 统计到mAP 汇总从一次诡异的mAP波动说起上个月调一个改进版YOLOv8训练完跑验证mAP0.5:0.95在0.52到0.58之间来回跳同一个权重文件每次跑结果不一样。第一反应是数据加载随机性但检查了shuffleFalseseed也固定了。最后定位到问题NMS的iou_threshold设成了0.65而训练时用的是0.7。这种细节差异验证脚本里根本不会报错但mAP直接崩了。从那以后我养成了一个习惯——每次跑验证前先看一眼验证器的配置参数是不是和训练时对齐。验证器的入口从val.py到Validator类YOLO的验证流程入口在val.py但核心逻辑全在Validator类里。这个类继承自BaseValidator负责从数据加载到指标汇总的全流程。初始化时它会做几件关键的事加载模型权重、初始化数据加载器、设置iou和conf阈值、创建混淆矩阵容器。这里有个坑——如果你用torch.jit或者onnx做验证Validator会走不同的分支数据预处理方式可能不一样尤其是归一化参数。classValidator(BaseValidator):def__init__(self,dataloaderNone,save_dirNone,pbarNone,argsNone,_callbacksNone):# 这里踩过坑dataloader的batch_size必须和训练时一致否则BN层的统计量会出问题super().__init__(dataloader,save_dir,pbar,args,_callbacks)self.argsargsorget_cfg()self.dataloaderdataloaderorself.get_dataloader()self.modelself.init_model()self.jdict[]# 存放每张图的检测结果用于后续COCO评估self.seen0# 统计已处理的图片数self.namesself.model.names# 类别名称映射数据遍历一次batch一次batch地啃验证流程的核心循环在__call__方法里。它遍历dataloader对每个batch执行前向推理、后处理、指标统计。这里有个容易被忽略的细节dataloader的collate_fn会把图片padding到相同尺寸但验证时不需要像训练那样做mosaic增强所以数据预处理要单独写。def__call__(self,trainerNone,modelNone):# 别这样写直接把trainer传进来复用它的dataloader因为验证集和训练集的数据增强不同self.model.eval()pbarself.progress_bar(self.dataloader)forbatch_i,batchinenumerate(pbar):# 解包batch包含图像、标签、路径、原始形状等信息im,targets,paths,shapesbatch# 图像归一化这里用的是和训练时一样的归一化参数但验证时不需要随机增强imim.to(self.device,non_blockingTrue)imim.half()ifself.args.halfelseim.float()im/255.0# 归一化到[0,1]# 前向推理torch.no_grad()是必须的否则显存会炸withtorch.no_grad():predsself.model(im)# 输出是list每个元素对应一个检测层的特征图# 这里踩过坑如果模型用了Test Time Augmentationpreds会变成list of list需要额外处理ifself.args.nmsorself.args.conf_thres:predsself.non_max_suppression(preds,self.args.conf_thres,self.args.iou_thres)NMS不是简单的框过滤YOLO的NMS实现和标准torchvision的nms不太一样。它做了几件事先按置信度过滤再按类别分组做NMS最后合并结果。这里有个优化点如果类别数很多比如80类按类别分组做NMS会比全局NMS慢很多但精度更高。defnon_max_suppression(self,prediction,conf_thres0.25,iou_thres0.45,classesNone,agnosticFalse,multi_labelFalse,labels(),max_det300):# 别这样写直接传一个很大的conf_thres会导致很多目标被漏检ncprediction.shape[2]-5# 类别数xcprediction[...,4]conf_thres# 置信度过滤# 对每个batch的每张图单独处理output[torch.zeros((0,6),deviceprediction.device)]*prediction.shape[0]forxi,xinenumerate(prediction):xx[xc[xi]]# 只保留置信度高于阈值的预测框ifnotx.shape[0]:continue# 解析预测框中心点宽高 - 左上角右下角boxself.xywh2xyxy(x[:,:4])conf,jx[:,5:].max(1,keepdimTrue)# 取最大置信度的类别xtorch.cat((box,conf,j.float()),1)[conf.view(-1)conf_thres]# 按类别做NMSifclassesisnotNone:xx[(x[:,5:6]torch.tensor(classes,devicex.device)).any(1)]nx.shape[0]ifnotn:continue# 这里踩过坑如果使用agnostic NMS所有类别一起做NMS会导致不同类别的框互相抑制ifagnostic:nms_outself.nms(x[:,:4],x[:,4],iou_thres)else:nms_outtorch.cat([self.nms(x[x[:,5]c,:4],x[x[:,5]c,4],iou_thres)forcinx[:,5].unique()])# 限制最大检测数ifnms_out.shape[0]max_det:nms_outnms_out[:max_det]output[xi]x[nms_out]returnoutputTP和FP统计混淆矩阵的构建NMS之后需要把预测结果和ground truth做匹配。YOLO用的是基于IoU的匹配策略对每个ground truth找到IoU最大的预测框如果IoU大于阈值通常是0.5就算TP否则算FP。这里有个细节匹配时是按类别分别做的不同类别的框不会互相匹配。defprocess_batch(self,detections,labels,iouvNone):# 别这样写直接用全局IoU匹配不同类别的框会错误匹配ifiouvisNone:iouvtorch.linspace(0.5,0.95,10,devicedetections.device)# 10个IoU阈值ncint(detections.shape[1]-5)# 类别数# 构建混淆矩阵shape为[nc, nc1]最后一列是FPcorrecttorch.zeros(detections.shape[0],iouv.shape[0],dtypetorch.bool,deviceiouv.device)# 对每个ground truth找到匹配的预测框forj,(d,l)inenumerate(zip(detections,labels)):ifl.shape[0]:# 计算IoU矩阵iouself.box_iou(l[:,:4],d[:,:4])# [num_gt, num_det]# 这里踩过坑如果直接用iou.max(1)取最大值会忽略类别信息# 正确做法先按类别过滤再取IoU最大值forcinl[:,4].unique():gt_maskl[:,4]c det_maskd[:,5]cifgt_mask.any()anddet_mask.any():iou_subiou[gt_mask][:,det_mask]# 对每个ground truth找到IoU最大的预测框gt_idx,det_idxself.match_iou(iou_sub,iouv)ifgt_idx.numel():correct[det_idx,:]TruereturncorrectmAP计算从TP/FP到AP再到mAPmAP的计算分两步先算每个类别的AP再对所有类别的AP取平均。AP的计算用的是PASCAL VOC的插值方法对每个类别按置信度降序排列预测框计算precision和recall曲线然后对recall轴做插值。defcompute_ap(self,tp,conf,pred_cls,target_cls,eps1e-16):# 别这样写直接用torch.mean计算没有考虑不同类别的样本不平衡itorch.argsort(-conf)# 按置信度降序排列tp,conf,pred_clstp[i],conf[i],pred_cls[i]# 计算每个类别的TP和FPunique_classestarget_cls.unique()aptorch.zeros(len(unique_classes),devicetp.device)forci,cinenumerate(unique_classes):ipred_clsc n_gt(target_clsc).sum()# 该类别的ground truth数量n_predictionsi.sum()ifn_predictions0orn_gt0:continue# 计算precision和recalltp_ctp[i].cumsum(0)fp_c(~tp[i]).cumsum(0)precisiontp_c/(tp_cfp_ceps)recalltp_c/(n_gteps)# 这里踩过坑直接用torch.trapz计算AP结果和COCO官方不一致# 正确做法用PASCAL VOC的11点插值法ap[ci]self.voc_ap(recall,precision)returnap.mean()# mAP汇总输出不只是打印几个数字验证结束后Validator会输出一个字典包含mAP0.5、mAP0.5:0.95、precision、recall、F1-score等指标。但真正有用的信息藏在细节里每个类别的AP、混淆矩阵、以及FP和FN的分布。我习惯在验证后额外输出一个类别级别的AP表格这样能快速定位哪些类别表现差。defprint_results(self):# 别这样写只打印mAP不打印每个类别的APpf%20s%12.3g*6# 格式化输出LOGGER.info(pf%(all,self.seen,self.nt_per_class.sum(),self.nt_per_class.sum(),self.stats[0],self.stats[1],self.stats[2]))# 打印每个类别的APfori,cinenumerate(self.model.names):apself.ap_per_class[i]LOGGER.info(pf%(c,self.seen,self.nt_per_class[i],self.nt_per_class[i],ap[0],ap[1],ap[2]))个人经验验证流程的五个坑NMS参数一致性训练时用的NMS参数和验证时必须完全一致包括conf_thres、iou_thres、max_det。我见过有人训练时用0.5的iou_thres验证时用0.65结果mAP差了5个点。数据增强差异验证时不要用任何随机增强包括水平翻转、颜色抖动。但有些改进模型在验证时也需要特定的预处理比如多尺度测试这时候要单独写验证脚本。batch size的影响验证时的batch size会影响BN层的统计量如果模型用了SyncBN验证时batch size必须和训练时一致否则mAP会波动。多GPU验证如果用了DistributedDataParallel验证时每个GPU只处理一部分数据最后需要all_gather汇总结果。这里容易漏掉同步操作导致mAP计算错误。内存泄漏验证循环里如果每张图都保存检测结果到list数据量大了会爆内存。建议用生成器或者分批写入文件。最后说一句验证流程看起来简单但每个细节都可能影响最终结果。我每次改模型结构后都会先跑一遍验证确认mAP和训练时的验证结果一致再去做其他实验。这个习惯帮我避免了很多低级错误。