試與可視化全流程解析:從配置到調(diào)參實(shí)踐)
1. 測(cè)試與可視化的整體思路MMDetection這個(gè)開(kāi)源目標(biāo)檢測(cè)工具箱大家在訓(xùn)練上投入的精力往往最多但真正到了模型測(cè)試和結(jié)果可視化這一步反倒容易草草了事。其實(shí)測(cè)試和可視化是閉環(huán)里最關(guān)鍵的一環(huán)模型在驗(yàn)證集上跑出什么指標(biāo)、在真實(shí)場(chǎng)景里到底長(zhǎng)什么樣全靠這一步來(lái)回答。如果只盯著訓(xùn)練損失下降卻不知道預(yù)測(cè)框畫(huà)出來(lái)是什么效果那前面的調(diào)參工作基本屬于盲人摸象。很多同學(xué)第一次接觸MMDetection的test流程時(shí)第一反應(yīng)是直接跑tools/test.py看到打印出一串mAP數(shù)值就覺(jué)得完事了。這里我想先強(qiáng)調(diào)一個(gè)容易被忽略的前提測(cè)試階段和訓(xùn)練階段的數(shù)據(jù)處理方式是有差異的。MMDetection在訓(xùn)練時(shí)為了增強(qiáng)魯棒性會(huì)做隨機(jī)翻轉(zhuǎn)、隨機(jī)尺度變化、馬賽克之類(lèi)的操作而測(cè)試時(shí)這些都應(yīng)該關(guān)掉保留原始分辨率或者只做固定尺度的縮放這樣才能真實(shí)反映模型在干凈數(shù)據(jù)上的表現(xiàn)。好在MMDetection的設(shè)計(jì)已經(jīng)內(nèi)置了pipeline的區(qū)分train_pipeline和test_pipeline各自獨(dú)立配置但從思路上理解這個(gè)差異能幫你在自定義數(shù)據(jù)時(shí)少踩坑。另外一個(gè)核心思路是可視化要放在指標(biāo)之前做。我第一次跑一個(gè)新數(shù)據(jù)集時(shí)習(xí)慣先輸出幾張可視化結(jié)果圖粗略檢查預(yù)測(cè)框的坐標(biāo)是否貼合目標(biāo)、類(lèi)別標(biāo)簽是否正確然后再去看mAP、AR這些數(shù)字。因?yàn)橹笜?biāo)是聚合的損失它可以告訴你整體好還是壞但不會(huì)告訴你具體錯(cuò)在哪。比如mAP偏低可能是定位偏差、分類(lèi)混淆、重復(fù)檢測(cè)、小目標(biāo)漏檢四種完全不同的病根治療方案完全不同??梢暬苤苯佣ㄎ徊≡钸@是任何指標(biāo)都替代不了的。測(cè)試和可視化適合誰(shuí)來(lái)做不光是做算法研究的同學(xué)做工程落地的朋友更需要。經(jīng)常有做巡檢、安防、工業(yè)質(zhì)檢的工程師朋友跟我聊說(shuō)離線指標(biāo)挺好但部署到現(xiàn)場(chǎng)效果不穩(wěn)定。這種問(wèn)題十有八九能從測(cè)試可視化里看出端倪——場(chǎng)景光照變化、遮擋、目標(biāo)尺度分布和訓(xùn)練集不一致這些在畫(huà)框圖上一目了然。所以這篇文章我會(huì)從配置、命令行、原理解析、常見(jiàn)坑這幾個(gè)角度把這套流程完整拆開(kāi)給你一份可以直接參考的實(shí)操方案。2. 測(cè)試階段的核心配置解析2.1 test_pipeline的數(shù)據(jù)處理鏈路MMDetection的測(cè)試流程本質(zhì)上也是通過(guò)DataLoader驅(qū)動(dòng)把測(cè)試數(shù)據(jù)從硬盤(pán)上的圖片變成可以直接喂進(jìn)模型的張量。這條鏈路里的test_pipeline決定了模型推理時(shí)看到的數(shù)據(jù)長(zhǎng)什么樣直接關(guān)系到預(yù)測(cè)結(jié)果的可靠性。先看一個(gè)常見(jiàn)的test_pipeline長(zhǎng)什么樣。以RetinaNet或Faster R-CNN這類(lèi)檢測(cè)模型為例配置文件里的測(cè)試數(shù)據(jù)處理單元通常由LoadImageFromFile、Resize、LoadAnnotations、PackDetInputs這幾個(gè)組件組成。LoadImageFromFile負(fù)責(zé)把圖片讀到內(nèi)存并解碼成數(shù)組Resize負(fù)責(zé)把圖片縮放到模型輸入尺寸LoadAnnotations負(fù)責(zé)把標(biāo)注文件通常是COCO格式的JSON解析成模型需要的格式PackDetInputs負(fù)責(zé)把圖像數(shù)據(jù)和標(biāo)注信息打包成一個(gè)統(tǒng)一的數(shù)據(jù)結(jié)構(gòu)DetDataSample供模型推理時(shí)消費(fèi)。這里最需要關(guān)注的是Resize的策略。MMDetection在測(cè)試推理時(shí)為了保證不同尺寸圖片能組成一個(gè)batch會(huì)先把所有圖片縮放到同一個(gè)尺度。常見(jiàn)的做法是保持長(zhǎng)寬比縮放讓短邊固定為一個(gè)值比如img_scale(1333, 800)表示長(zhǎng)邊不超過(guò)1333、短邊固定為800。如果測(cè)試時(shí)你想保持原始分辨率可以把img_scale設(shè)得足夠大也可以直接讓Resize不做縮放但那樣做batch內(nèi)圖片尺寸不一致MMDetection的collate函數(shù)需要額外處理實(shí)際中不推薦。我的經(jīng)驗(yàn)是按訓(xùn)練時(shí)用的img_scale來(lái)設(shè)定測(cè)試尺度這樣數(shù)據(jù)分布最接近訓(xùn)練狀態(tài)指標(biāo)參考價(jià)值最高。2.2 test_dataloader與test_evaluator的配置邏輯在MMDetection 3.x版本中測(cè)試配置被拆分成test_dataloader、test_evaluator、test_cfg三塊。test_dataloader里有batch_size、num_workers、dataset和sampler四個(gè)關(guān)鍵子配置。batch_size要結(jié)合顯存來(lái)定測(cè)試階段不需要做反向傳播梯度計(jì)算關(guān)閉顯存占用比訓(xùn)練小很多通??梢栽O(shè)成訓(xùn)練時(shí)的一倍或兩倍。num_workers決定數(shù)據(jù)加載線程數(shù)建議在Linux下用nproc命令看看物理核數(shù)一般設(shè)為8到12比較穩(wěn)妥設(shè)太高反而可能引起進(jìn)程切換開(kāi)銷(xiāo)過(guò)大。test_evaluator指定用哪種指標(biāo)評(píng)測(cè)方式最常用的是CocoMetric。這個(gè)配置里核心參數(shù)是ann_file標(biāo)注文件路徑、metric比如bbox或segm、classwise是否輸出每個(gè)類(lèi)別獨(dú)立的AP值。我習(xí)慣把classwiseTrue打開(kāi)因?yàn)橹豢凑wmAP會(huì)掩蓋類(lèi)別不均衡的問(wèn)題。比如一個(gè)數(shù)據(jù)集里貓和狗的數(shù)量比例是10比1整體mAP可能還湊合但狗的AP往往慘不忍睹通過(guò)classwise能快速定位到哪個(gè)類(lèi)別拖了后腿。test_cfg里還有一個(gè)容易被忽略的參數(shù)就是推理時(shí)的det_threshold之類(lèi)的后處理配置。測(cè)試階段模型會(huì)輸出大量候選框一般通過(guò)NMS非極大值抑制篩選之后再用score_thr比如0.05或0.01過(guò)濾掉置信度過(guò)低的框。這里要說(shuō)明一個(gè)細(xì)節(jié)評(píng)測(cè)指標(biāo)計(jì)算時(shí)mAP本身就兼顧了不同置信度閾值下的精度和召回率所以score_thr設(shè)低一點(diǎn)如0.01不會(huì)漏報(bào)評(píng)測(cè)結(jié)果更接近模型的真實(shí)能力。如果你設(shè)成0.5mAP會(huì)有虛高的傾向因?yàn)橄喈?dāng)于人為砍掉了大量低置信度檢測(cè)讓precision看起來(lái)很漂亮。做可視化時(shí)卻恰恰相反建議把score_thr調(diào)高到0.3或0.5只看高置信度的預(yù)測(cè)圖面更干凈、說(shuō)服力更強(qiáng)。下面給一份精簡(jiǎn)的測(cè)試配置片段方便你對(duì)照檢查自己的配置文件# configs/_base_/datasets/coco_detection.py test_dataloader dict( batch_size2, num_workers4, persistent_workersTrue, samplerdict(typeDefaultSampler, shuffleFalse), datasetdict( typeCocoDataset, data_rootdata/coco/, ann_fileannotations/instances_val2017.json, data_prefixdict(imgval2017/), pipeline[ dict(typeLoadImageFromFile), dict(typeResize, scale(1333, 800), keep_ratioTrue), dict(typeLoadAnnotations, with_bboxTrue), dict(typePackDetInputs, meta_keys(img_id, img_path, ori_shape, img_shape, scale_factor)) ])) test_evaluator dict( typeCocoMetric, ann_filedata/coco/annotations/instances_val2017.json, metricbbox, classwiseTrue, format_onlyFalse) test_cfg dict(typeTestLoop, det_threshold0.01)注意PackDetInputs里meta_keys這個(gè)參數(shù)它決定了哪些原始信息會(huì)被保留在數(shù)據(jù)樣本中img_shape、scale_factor是可視化時(shí)反向映射坐標(biāo)必須的信息千萬(wàn)別省。如果你自定義了可視化腳本需要用到原始圖像路徑或尺寸記得在這里補(bǔ)充對(duì)應(yīng)的meta_key。3. 測(cè)試命令的完整實(shí)操流程3.1 基于訓(xùn)練好的權(quán)重跑測(cè)試訓(xùn)練完模型或者拿到一個(gè)預(yù)訓(xùn)練權(quán)重測(cè)試是第一步。MMDetection標(biāo)準(zhǔn)的測(cè)試命令長(zhǎng)這樣python tools/test.py \ configs/faster_rcnn/faster-rcnn_r50_fpn_1x_coco.py \ work_dirs/faster-rcnn_r50_fpn_1x_coco/epoch_12.pth \ --work-dir work_dirs/faster-rcnn_r50_fpn_1x_coco/test_epoch12 \ --cfg-options test_evaluator.classwiseTrue \ --show-dir work_dirs/faster-rcnn_r50_fpn_1x_coco/vis_results三個(gè)位置參數(shù)要記牢第一個(gè)是配置文件路徑第二個(gè)是權(quán)重文件路徑第三個(gè)可選是日志和評(píng)測(cè)結(jié)果的輸出目錄。--work-dir用來(lái)指定測(cè)試日志、評(píng)測(cè)pkl文件的落盤(pán)位置建議每次測(cè)試都單獨(dú)設(shè)置一個(gè)子目錄避免和訓(xùn)練日志混在一起。--show-dir就是輸出可視化圖片的目錄只要指定了這個(gè)參數(shù)工具腳本會(huì)在跑完指標(biāo)評(píng)測(cè)后自動(dòng)把所有測(cè)試圖片都畫(huà)上預(yù)測(cè)框保存下來(lái)。--cfg-options可以臨時(shí)覆蓋配置里任何參數(shù)不需要改配置文件本身適合快速驗(yàn)證某個(gè)參數(shù)的影響比如把classwise打開(kāi)。在跑測(cè)試之前打開(kāi)配置文件確認(rèn)一下model.test_cfg的配置。以Faster R-CNN為例test_cfg里通常會(huì)有nms的iou_threshold默認(rèn)0.5和max_per_img默認(rèn)100。max_per_img決定了每張圖最終保留的檢測(cè)框上限設(shè)太小會(huì)丟失部分目標(biāo)設(shè)太大會(huì)讓結(jié)果包含大量低質(zhì)量框可視化時(shí)畫(huà)面也亂100是精度和可讀性的平衡點(diǎn)。測(cè)試過(guò)程跑完后終端會(huì)打印類(lèi)似這樣的內(nèi)容coco/bbox_mAP: 0.376 coco/bbox_mAP_50: 0.584 coco/bbox_mAP_75: 0.405 coco/bbox_mAP_s: 0.209 coco/bbox_mAP_m: 0.417 coco/bbox_mAP_l: 0.493這些指標(biāo)含義得先說(shuō)透因?yàn)楹芏嗳酥豢匆粋€(gè)mAP就下結(jié)論。mAP_50表示IoU閾值0.5下的平均精度mAP_75是IoU閾值0.75下的平均精度后者更嚴(yán)格對(duì)定位精度要求更高。mAP_s/m/l分別是小、中、大目標(biāo)的平均精度COCO數(shù)據(jù)集的定義是小目標(biāo)面積小于32x32大目標(biāo)面積大于96x96。如果你的項(xiàng)目場(chǎng)景里小目標(biāo)居多就得重點(diǎn)盯mAP_s這個(gè)指標(biāo)比整體mAP更能反映實(shí)際效果。3.2 用測(cè)試結(jié)果pkl做更靈活的分析如果不指定--show-dir工具腳本默認(rèn)會(huì)生成一個(gè)results開(kāi)頭的.pkl文件里面保存了模型在測(cè)試集上每張圖的全部預(yù)測(cè)信息包括框坐標(biāo)、置信度分?jǐn)?shù)、類(lèi)別ID。這個(gè)文件是后續(xù)做各種自定義分析的“原材料”我強(qiáng)烈建議每次測(cè)試都保留它。比如你在測(cè)試腳本里加上--out work_dirs/test_result.pkl參數(shù)就能把預(yù)測(cè)結(jié)果整個(gè)dump出來(lái)。拿到pkl文件后有幾個(gè)很實(shí)用的分析方向。第一個(gè)是看置信度分布把每張圖的預(yù)測(cè)框按置信度從高到低排列統(tǒng)計(jì)不同置信度區(qū)間里正確檢測(cè)和誤檢的數(shù)量可以幫你判斷模型是“猶豫型”還是“自信型”。第二個(gè)是做PR曲線分析雖然mAP已經(jīng)聚合了PR曲線的面積但PR曲線的形狀能告訴你模型更擅長(zhǎng)保精度還是保召回對(duì)業(yè)務(wù)上線時(shí)設(shè)置置信度閾值的參考價(jià)值很大。第三個(gè)是分析錯(cuò)誤類(lèi)型比如用TIDE之類(lèi)的工具庫(kù)把檢測(cè)錯(cuò)誤分類(lèi)成定位誤差、分類(lèi)混淆、重復(fù)檢測(cè)、背景誤檢等幾類(lèi)有針對(duì)性地調(diào)優(yōu)。寫(xiě)一段簡(jiǎn)單代碼看看怎么讀取和分析pkl文件import pickle with open(work_dirs/test_result.pkl, rb) as f: results pickle.load(f) # MMDetection 3.x中results是DetDataSample列表 for sample in results[:5]: # 從gt_instances取真實(shí)框從pred_instances取預(yù)測(cè)框 gt_bboxes sample.gt_instances.bboxes.tolist() pred_bboxes sample.pred_instances.bboxes.tolist() pred_scores sample.pred_instances.scores.tolist() print(gt num:, len(gt_bboxes), pred num:, len(pred_bboxes)) print(max score:, max(pred_scores) if pred_scores else 0)這種腳本寫(xiě)得越早越好因?yàn)楹罄m(xù)換backbone、調(diào)anchor、調(diào)loss都需要用同一套分析腳本對(duì)比前后差異有了腳本就可以做到量化對(duì)比而不是誰(shuí)訓(xùn)完誰(shuí)說(shuō)了算。我曾經(jīng)把五六個(gè)版本的pkl合并在一起做可視化對(duì)比一眼就看出來(lái)某個(gè)版本在特定類(lèi)別上召回率提升很多但在遮擋場(chǎng)景下誤檢也增多這種Trade-off只靠看單獨(dú)一個(gè)mAP根本發(fā)現(xiàn)不了。3.3 帶上可視化一起跑--show-dir的細(xì)節(jié)--show-dir參數(shù)是MMDetection 3.x內(nèi)置的可視化入口。指定它之后你不需要額外寫(xiě)繪圖代碼測(cè)試腳本會(huì)在每個(gè)epoch的評(píng)估階段結(jié)束后遍歷測(cè)試集圖片把預(yù)測(cè)框和真實(shí)框畫(huà)到原圖上保存到指定目錄。對(duì)著一張圖你能直觀看到兩個(gè)方面預(yù)測(cè)框通常用藍(lán)色或綠色和真實(shí)框通常用紅色存在的錯(cuò)檢、漏檢都能看出來(lái)。默認(rèn)只畫(huà)預(yù)測(cè)框如果你想把真實(shí)框一起畫(huà)出來(lái)做對(duì)比需要確保test_pipeline里包含LoadAnnotations并且在配置文件的visualizer里設(shè)置draw_gtTrue。可視化結(jié)果的文件名默認(rèn)是原圖文件名.jpg。如果你的測(cè)試圖片很多建議按類(lèi)別或場(chǎng)景建子目錄否則幾百上千張圖堆在一起想找某一特定場(chǎng)景非常麻煩。另外建議在--cfg-options里加上visualizer.save_dirwork_dirs/vis_xxx把可視化目錄獨(dú)立出來(lái)不要和pkl文件混在一起。有一點(diǎn)值得單獨(dú)提醒test.py的可視化是邊推理邊畫(huà)圖全程不中斷但這種方式在高分辨率圖片上會(huì)明顯拖慢測(cè)試速度因?yàn)楫?huà)圖本身也是IO操作。如果你只是需要跑指標(biāo)不一定要可視化就別開(kāi)--show-dir如果必須要可視化建議用小一點(diǎn)的測(cè)試集子集做展示比如隨機(jī)抽200張效果一樣的卻能省不少時(shí)間。后續(xù)我會(huì)講怎么優(yōu)雅地做這種抽樣可視化。4. 靈活的可視化方案與手工可視化實(shí)踐4.1 使用內(nèi)置工具腳本快速出圖除了用--show-dirMMDetection還提供了一個(gè)專(zhuān)門(mén)的可視化腳本tools/analysis_tools/browse_dataset.py雖然它最初設(shè)計(jì)是給訓(xùn)練前檢查數(shù)據(jù)標(biāo)注用的但也能用來(lái)查看帶預(yù)測(cè)框的結(jié)果——如果你把模型權(quán)重掛載上去的話。大部分情況下--show-dir已經(jīng)夠用了。內(nèi)置可視化的最大好處是零代碼缺點(diǎn)是定制能力弱。比如你想把置信度分?jǐn)?shù)直接顯示在框邊上默認(rèn)畫(huà)布不展示想按類(lèi)別用不同顏色區(qū)分默認(rèn)是隨機(jī)顏色想只顯示置信度大于0.5的框默認(rèn)是全部顯示。遇到這些需求就得自己寫(xiě)腳本了。4.2 手工可視化腳本的完整實(shí)現(xiàn)我平時(shí)用得最多的可視化方案還是基于DetDataSample結(jié)構(gòu)自己寫(xiě)繪圖腳本。這樣可控性最強(qiáng)想調(diào)什么調(diào)什么。下面給出一份可以直接借鑒的腳本結(jié)合了pkl結(jié)果和原圖路徑進(jìn)行可視化import os import pickle import cv2 import numpy as np from mmdet.visualization import DetLocalVisualizer with open(work_dirs/test_result.pkl, rb) as f: results pickle.load(f) # 假設(shè)測(cè)試圖片在test_imgs目錄 image_root data/coco/val2017 save_root work_dirs/vis_custom os.makedirs(save_root, exist_okTrue) for sample in results: img_path sample.metainfo[img_path] image cv2.imread(img_path) pred_instances sample.pred_instances # 過(guò)濾低置信度框可視化時(shí)只留下0.3以上的 keep pred_instances.scores 0.3 pred_instances pred_instances[keep] # 調(diào)用mmdet內(nèi)置可視化器的draw方法這里傳入樣本會(huì)繪制gt和pred visualizer DetLocalVisualizer() visualizer.dataset_meta {classes: (cat, dog)} visualizer.add_datasample( result, image, sample, draw_gtTrue, draw_predTrue, showFalse, wait_time0, out_fileos.path.join(save_root, os.path.basename(img_path)))這個(gè)腳本里有兩個(gè)關(guān)鍵地方。第一個(gè)sample.pred_instances是一個(gè)InstanceData對(duì)象支持布爾索引scores 0.3直接返回InstanceData的切片非常方便想過(guò)濾哪個(gè)字段都行。第二個(gè)visualizer.add_datasample接口負(fù)責(zé)真正畫(huà)圖draw_gtTrue時(shí)會(huì)把標(biāo)注框也畫(huà)出來(lái)out_file指定輸出路徑不指定就會(huì)直接彈窗顯示在服務(wù)器上運(yùn)行沒(méi)有GUI的話就等著報(bào)錯(cuò)吧所以記得一定要設(shè)out_file。你可能會(huì)問(wèn)手動(dòng)畫(huà)圖為什么不用OpenCV畫(huà)框因?yàn)镸MDetection的DetLocalVisualizer已經(jīng)實(shí)現(xiàn)了類(lèi)別顏色管理、置信度文本、圖例等復(fù)雜功能自己用OpenCV從零畫(huà)代碼量至少翻三倍而且邊界框粗細(xì)、字體大小這些細(xì)節(jié)調(diào)試起來(lái)也費(fèi)勁。除非你要做極度定制化的效果比如視頻流實(shí)時(shí)預(yù)覽、在非標(biāo)準(zhǔn)圖像格式上繪制否則不建議重復(fù)造輪子。4.3 視頻與多圖對(duì)比的可視化思路如果你測(cè)試的對(duì)象是視頻逐幀保存成圖片再合成視頻是最蠢但最穩(wěn)定的做法。效率高一點(diǎn)的方法是直接改造測(cè)試腳本的推理循環(huán)把每一幀的預(yù)測(cè)結(jié)果傳給視頻寫(xiě)入器。MMDetection提供了inference_detector接口可以逐幀推理配合OpenCV的VideoWriter就能把預(yù)測(cè)框?qū)崟r(shí)畫(huà)到視頻幀上并輸出成MP4。下面是用inference_detector做單張圖片推理的極簡(jiǎn)示例from mmdet.apis import init_detector, inference_detector import mmcv config_file configs/faster_rcnn/faster-rcnn_r50_fpn_1x_coco.py checkpoint_file work_dirs/epoch_12.pth model init_detector(config_file, checkpoint_file, devicecuda:0) img test.jpg result inference_detector(model, img) # result是DetDataSample可以直接可視化或檢查框這個(gè)接口對(duì)工程集成特別有用比如接到攝像頭實(shí)時(shí)流、嵌入到Flask服務(wù)里做API推理都可以基于它來(lái)擴(kuò)展。多圖對(duì)比分析時(shí)把同一張圖在不同模型配置下的預(yù)測(cè)結(jié)果拼成一張畫(huà)布左半部分是模型A的框右半部分是模型B的框能直觀看出哪個(gè)模型定位更準(zhǔn)。我常用np.concatenate把多張可視化圖橫向拼接然后用一個(gè)標(biāo)題欄標(biāo)注每個(gè)子圖對(duì)應(yīng)的配置名這樣對(duì)比效率極高。4.4 可視化結(jié)果如何指導(dǎo)調(diào)參講了這么多操作層面的東西落到最終用途上可視化結(jié)果到底怎么指導(dǎo)調(diào)參。這里我總結(jié)幾個(gè)高頻場(chǎng)景。第一如果預(yù)測(cè)框普遍偏大或偏小說(shuō)明anchor size設(shè)置和數(shù)據(jù)集目標(biāo)尺度不匹配。訓(xùn)練前先用可視化腳本檢查數(shù)據(jù)集的標(biāo)注框尺寸分布如果目標(biāo)普遍較小而模型默認(rèn)anchor是適合COCO的尺度就要在小尺度anchor上增密。第二如果同類(lèi)目標(biāo)距離極近導(dǎo)致漏檢或誤檢NMS的iou_threshold需要調(diào)低讓重復(fù)框更容易被抑制。第三如果預(yù)測(cè)框整體偏移比如所有框都往下偏大概率是訓(xùn)練時(shí)數(shù)據(jù)標(biāo)注有系統(tǒng)性誤差可視化能幫你一眼看出這種偏差。第四如果高置信度預(yù)測(cè)框經(jīng)常落在背景區(qū)域說(shuō)明模型學(xué)到了紋理特征而非語(yǔ)義特征可能需要換更強(qiáng)的backbone或者增加上下文信息。這些調(diào)參結(jié)論如果不做可視化根本得不出來(lái)。所以我要強(qiáng)調(diào)這一條理念每跑一次測(cè)試至少抽看50張可視化結(jié)果圖然后再看指標(biāo)。別看40張就說(shuō)夠了因?yàn)殄e(cuò)檢和漏檢往往集中在長(zhǎng)尾分布的那部分目標(biāo)上看得越多樣品越容易碰到。5. 測(cè)試階段常用參數(shù)速查表與效率提示把測(cè)試環(huán)節(jié)涉及的常用參數(shù)和對(duì)應(yīng)建議整理一張表方便你直接對(duì)照使用。其中有一些參數(shù)是從工程效率角度給出的經(jīng)驗(yàn)值請(qǐng)結(jié)合自己的硬件條件合理調(diào)整。參數(shù)項(xiàng)常見(jiàn)取值建議與說(shuō)明test_dataloader.batch_size1 ~ 8顯存不夠時(shí)優(yōu)先調(diào)小因?yàn)闇y(cè)試不走反向傳播Faster R-CNN系列2~4是穩(wěn)妥起點(diǎn)test_dataloader.num_workers4 ~ 12建議按CPU物理核數(shù)的一半設(shè)置設(shè)太高反而增加調(diào)度開(kāi)銷(xiāo)test_evaluator.metricbbox / segm檢測(cè)任務(wù)用bbox實(shí)例分割任務(wù)用segmtest_cfg.det_threshold0.01 ~ 0.05評(píng)測(cè)時(shí)用低閾值保證召回率統(tǒng)計(jì)完整score_thr可視化0.3 ~ 0.5只在可視化或部署時(shí)使用評(píng)測(cè)時(shí)不用高閾值--show-dir自定義目錄只跑指標(biāo)時(shí)不要設(shè)置避免無(wú)謂IO--out自定義.pkl路徑建議每次測(cè)試都保存方便后續(xù)自定義分析接著說(shuō)說(shuō)測(cè)試效率的問(wèn)題。測(cè)試階段最耗時(shí)的點(diǎn)其實(shí)是數(shù)據(jù)加載和預(yù)處理GPU本身閑置率往往很高。有人覺(jué)得GPU顯存大干脆batch_size設(shè)成16猛干結(jié)果發(fā)現(xiàn)速度提升不是線性的瓶頸在CPU端數(shù)據(jù)預(yù)處理和IO。想提升測(cè)試吞吐優(yōu)先加num_workers再考慮批量大小。如果圖片分辨率很大預(yù)處理里的Resize會(huì)成為一個(gè)計(jì)算熱點(diǎn)測(cè)試時(shí)可以考慮用一個(gè)更小的img_scale比如(1000, 600)前提是你得明白這會(huì)降低小目標(biāo)檢測(cè)精度必須做對(duì)比驗(yàn)證后再確定。如果你的測(cè)試集是那種大而全的原始數(shù)據(jù)集幾萬(wàn)張圖全跑一遍太耗時(shí)可以用--cfg-options臨時(shí)構(gòu)造一個(gè)抽樣子集比如用tools/analysis_tools/analyze_logs.py的腳本或mmcv的抽樣工具隨機(jī)取500張做快速驗(yàn)證。我在實(shí)際項(xiàng)目中經(jīng)常先跑500張驗(yàn)證流程沒(méi)問(wèn)題再全量跑能省下不少來(lái)回調(diào)試的時(shí)間。6. 測(cè)試可視化常見(jiàn)問(wèn)題與排查技巧實(shí)錄6.1 預(yù)測(cè)框置信度全是0或者沒(méi)有預(yù)測(cè)輸出這個(gè)現(xiàn)象通常和test_cfg里的score_thr設(shè)置無(wú)關(guān)更可能是數(shù)據(jù)預(yù)處理出了問(wèn)題。排查步驟從下往上走先看看測(cè)試圖片能否正常加載再檢查test_pipeline里的Resize是否把大圖縮得太狠導(dǎo)致目標(biāo)在縮放后小于2像素最后檢查模型輸入的batch_inputs形狀是不是正常。我在自定義數(shù)據(jù)集上踩過(guò)這個(gè)坑原因是LoadAnnotations里的with_bbox在測(cè)試時(shí)依然為T(mén)rue而測(cè)試標(biāo)注文件路徑不存在導(dǎo)致數(shù)據(jù)加載靜默失敗預(yù)測(cè)結(jié)果自然為空。解決方法是確保測(cè)試集標(biāo)注文件始終可用即使零標(biāo)注也要提供一個(gè)空的JSON別讓數(shù)據(jù)加載報(bào)錯(cuò)吞掉。6.2 可視化結(jié)果里框和原圖對(duì)不上位置這是最常見(jiàn)也最容易讓人抓狂的坑??虍?huà)出來(lái)和物體位置錯(cuò)位幾像素或幾十像素通常不是模型問(wèn)題而是繪制時(shí)沒(méi)有用原圖坐標(biāo)。MMDetection在推理時(shí)會(huì)把圖片縮放或加padding預(yù)測(cè)框坐標(biāo)是基于縮放后的圖算的。如果你直接從pred_instances.bboxes里取值然后畫(huà)到原圖上框就會(huì)偏移。正確做法是乘回scale_factor或者用DetLocalVisualizer的add_datasample接口它會(huì)自動(dòng)處理坐標(biāo)還原。我建議在配置PackDetInputs時(shí)保留ori_shape和scale_factor元信息這樣任何時(shí)候想手動(dòng)繪圖都有足夠信息做反變換。如果你在用inference_detector接口result里自帶這些元信息直接用visualizer渲染就行不需要手動(dòng)換算。6.3 尺寸不匹配單張測(cè)試沒(méi)問(wèn)題但batch測(cè)試崩潰這個(gè)問(wèn)題大多是test_pipeline沒(méi)有設(shè)置統(tǒng)一的Resize尺度或者keep_ratioTrue導(dǎo)致batch內(nèi)圖片尺寸不一致觸碰了batch維度校驗(yàn)的限制。MMDetection 3.x對(duì)batch內(nèi)張量尺寸一致性要求很?chē)?yán)格如果尺寸不一致會(huì)報(bào)invalid argument或size mismatch錯(cuò)誤。解決方法是確保所有測(cè)試圖片最終縮放到完全相同的尺寸比如固定(1333, 800)并且設(shè)置keep_ratioTrue這樣batch內(nèi)尺寸仍然可能不一致所以更好的做法是用統(tǒng)一的scale但這樣會(huì)犧牲原始比例信息。實(shí)際中一般不會(huì)對(duì)測(cè)試集做嚴(yán)格統(tǒng)一因?yàn)镸MDetection的分組采樣器會(huì)盡量把尺寸接近的圖片分到同一個(gè)batch但如果你自己改了數(shù)據(jù)加載方式就要特別小心這個(gè)問(wèn)題。6.4 顯存不足OOM怎么辦測(cè)試階段OOM可能出現(xiàn)在兩個(gè)地方。第一個(gè)是test_dataloader的batch_size設(shè)置太大FP16加速也沒(méi)開(kāi)很容易爆顯存。第二個(gè)是高分辨率圖片做全圖推理時(shí)特征圖占用過(guò)大。常見(jiàn)解決辦法有四種把batch_size調(diào)成1使用--cfg-options model.data_preprocessor.batch_augmentsNone關(guān)閉一些數(shù)據(jù)增強(qiáng)相關(guān)操作如果配置里有嘗試開(kāi)啟--amp混合精度推理或者給大的測(cè)試圖做TTATest-Time Augmention之前先切圖避免一次性把整張大圖塞進(jìn)GPU。顯存優(yōu)化是一個(gè)越早做收益越大的事。建議測(cè)試之前先用nvidia-smi看看GPU顯存剩余量粗略估算一下當(dāng)前模型大小x batch_size的顯存需求。如果還不夠用torch.cuda.max_memory_allocated()峰值統(tǒng)計(jì)接口判斷瓶頸是在backbone還是在檢測(cè)頭后處理上。6.5 可視化結(jié)果過(guò)多或過(guò)少可視化圖太多時(shí)篩選的策略很關(guān)鍵。只保存置信度最高的前K個(gè)檢測(cè)這是一個(gè)辦法按類(lèi)別過(guò)濾只看你關(guān)心的類(lèi)別這樣更精準(zhǔn)。漏檢占比高的圖是最有價(jià)值的單獨(dú)抽出來(lái)分析誤檢多的圖也有參考意義。我的建議是把可視化結(jié)果按預(yù)測(cè)框數(shù)量排序多框的、零框的、高置信度錯(cuò)檢的分別歸類(lèi)存放這樣分析效率會(huì)高很多。如果你介意人工一個(gè)個(gè)翻圖還可以寫(xiě)腳本統(tǒng)計(jì)每張圖的錯(cuò)檢率只把錯(cuò)檢率高于某個(gè)閾值的圖保存下來(lái)減少人工工作量。6.6 測(cè)試結(jié)果與訓(xùn)練時(shí)的驗(yàn)證集結(jié)果不一致有朋友遇到過(guò)這樣的怪事訓(xùn)練日志里每個(gè)epoch的驗(yàn)證mAP有0.5但單獨(dú)用tools/test.py跑出來(lái)的結(jié)果只有0.4。這個(gè)問(wèn)題的根源通常是兩個(gè)評(píng)估流程的數(shù)據(jù)處理不完全一致。一種可能是訓(xùn)練過(guò)程里的驗(yàn)證階段用了val_pipeline而tools/test.py用的是test_pipeline兩者如果配置不同比如Resize尺度、是否帶TTA指標(biāo)自然會(huì)不一樣。另一種可能是測(cè)試時(shí)使用了不同的權(quán)重文件最常見(jiàn)的是best_coco_bbox_mAP_epoch和latest的混淆——前者保存的是驗(yàn)證集上指標(biāo)最好的權(quán)重后者是隨機(jī)初始化的權(quán)重如果你用的是--auto-resume之類(lèi)還有可能加載到不完整權(quán)重。解決的關(guān)鍵是每次測(cè)試都把配置和權(quán)重路徑記錄下來(lái)尤其是用bash腳本批量跑測(cè)試時(shí)別搞混。7. 將測(cè)試與可視化嵌入日常開(kāi)發(fā)流的建議很多同學(xué)把測(cè)試和可視化當(dāng)作一個(gè)階段性的動(dòng)作訓(xùn)完了跑一次就完事。但我更建議把它做成一個(gè)可重復(fù)的日常流程。每次調(diào)整數(shù)據(jù)增強(qiáng)、修改模型結(jié)構(gòu)、更換訓(xùn)練策略之后都跑一次小規(guī)模測(cè)試和可視化與前一個(gè)版本對(duì)比。這個(gè)迭代回路看起來(lái)增加了工作量實(shí)際能幫你盡早發(fā)現(xiàn)問(wèn)題。具體怎么嵌進(jìn)日常工作我的習(xí)慣是寫(xiě)一個(gè)驗(yàn)證腳本輸入是配置文件路徑和權(quán)重路徑輸出是一份自動(dòng)生成的對(duì)比報(bào)告包含mAP、各類(lèi)別AP、PR曲線以及抽樣可視化圖。這樣只要跑一條命令就能拿到全部信息不需要每次手動(dòng)進(jìn)終端敲一串工具命令再打開(kāi)目錄找圖。sh scripts/validate_and_vis.sh \ configs/my_faster_rcnn.py \ work_dirs/best.pth \ work_dirs/exp_compare腳本內(nèi)部邏輯不算復(fù)雜調(diào)用tools/test.py跑指標(biāo)和結(jié)果pkl再用一段Python腳本讀取pkl抽50張圖做可視化最后用pandas匯總指標(biāo)并畫(huà)柱狀圖。整個(gè)過(guò)程跑完大概需要幾分鐘取決于測(cè)試集大小但省下來(lái)的“改配置-重新訓(xùn)練-手工比較”時(shí)間往往是以天來(lái)計(jì)的。最后提醒一個(gè)容易被忽視的點(diǎn)可視化保存的圖片是給人類(lèi)看的不是給模型看的。你在調(diào)參時(shí)看可視化結(jié)果也要帶上業(yè)務(wù)視角。比如做工業(yè)質(zhì)檢漏檢比誤檢嚴(yán)重得多那看到低置信度漏檢的圖應(yīng)該優(yōu)先考慮降低置信度閾值而不是調(diào)整NMS做安防巡檢誤檢率太高會(huì)煩死值班人員那就要想辦法提高正樣本質(zhì)量、增加難負(fù)樣本挖掘。同一張可視化圖在不同業(yè)務(wù)目標(biāo)下得出的調(diào)參方向可能是相反的。8. 結(jié)尾再聊兩句個(gè)人心得做檢測(cè)項(xiàng)目幾年下來(lái)我最大的感受是模型訓(xùn)練只是“煉丹”測(cè)試和可視化才是“驗(yàn)丹”。很多人煉丹煉得很投入驗(yàn)丹卻馬虎得很只看一個(gè)mAP就交差。但真正把系統(tǒng)推到實(shí)際場(chǎng)景里最容易暴露問(wèn)題的恰恰是那些可視化里看起來(lái)“不夠自然”的預(yù)測(cè)結(jié)果——一個(gè)高置信度的錯(cuò)誤框、一個(gè)被漏檢的小目標(biāo)、一條偏離的邊界這些才是模型能力邊界的真實(shí)投影。講到底測(cè)試可視化和指標(biāo)評(píng)測(cè)是互補(bǔ)的指標(biāo)告訴你“做到什么程度”可視化告訴你“為什么是這個(gè)程度”。兩者一起用模型在什么場(chǎng)景下能打、在什么場(chǎng)景下會(huì)翻車(chē)基本就心里有數(shù)了。最后分享一個(gè)小建議跑測(cè)試時(shí)與其等到訓(xùn)完再看不如訓(xùn)練到中途就經(jīng)常拿最新權(quán)重做小規(guī)模可視化抽查。批量訓(xùn)練動(dòng)輒幾十個(gè)小時(shí)中途發(fā)現(xiàn)模型存在系統(tǒng)性誤差比如類(lèi)別混淆嚴(yán)重、或者目標(biāo)邊界定位整體偏移早發(fā)現(xiàn)就能早停掉重訓(xùn)或者調(diào)整方案比熬到最后一秒鐘看到結(jié)果失望要省錢(qián)省心得多。反正可視化的成本很低就是幾張圖的事但信息量往往比一個(gè)先進(jìn)指標(biāo)更大。這套“半路驗(yàn)丹”的習(xí)慣我一直用到現(xiàn)在實(shí)戰(zhàn)里幫我在好幾次實(shí)驗(yàn)中提前發(fā)現(xiàn)了一開(kāi)始沒(méi)注意到的問(wèn)題推薦你也試試。