簡介目標(biāo)檢測是計算機視覺領(lǐng)域的基礎(chǔ)技術(shù)而車牌檢測作為交通管理場景中的關(guān)鍵環(huán)節(jié)直接決定車輛識別系統(tǒng)的可靠性。YOLO系列算法不斷迭代YOLO26憑借C2f模塊改進、動態(tài)標(biāo)簽分配和強化多尺度融合在小目標(biāo)與低光環(huán)境檢測上表現(xiàn)顯著優(yōu)于前代版本。本文圍繞車牌檢測這一經(jīng)典任務(wù)系統(tǒng)梳理從車輛檢測到車牌定位的兩級推理鏈路重點講解數(shù)據(jù)集組織、標(biāo)注規(guī)范、數(shù)據(jù)增強策略以及模型訓(xùn)練參數(shù)調(diào)優(yōu)與導(dǎo)出部署全流程。同時針對夜間低光環(huán)境檢測效果差、小目標(biāo)漏檢、誤檢頻發(fā)等工程痛點提供可落地的排查與解決思路。結(jié)合嵌入式設(shè)備部署需求分析ONNX導(dǎo)出、INT8量化及推理速度權(quán)衡。最終以停車場出入口、電子警察等真實業(yè)務(wù)場景為例展示如何將檢測模型與跟蹤、OCR聯(lián)動構(gòu)建完整的智能交通管理系統(tǒng)為相關(guān)項目開發(fā)提供可復(fù)用的實操參考。 說實話這年頭還能看到有人把“車牌檢測”這種經(jīng)典得不能再經(jīng)典的場景重新認(rèn)真做一遍我其實是有點意外的。但仔細(xì)看了下這套“yolo26車牌檢測-交通管理和車輛識別系統(tǒng)數(shù)據(jù)集訓(xùn)練好的模型.zip”的打包內(nèi)容又覺得挺正?！猋OLO系列迭代到26這個階段很多東西確實變了尤其是小目標(biāo)檢測和低光環(huán)境的表現(xiàn)跟早年的v5相比完全不是一個量級。如果你正愁怎么給交通管理項目配一個能落地的車牌識別前端或者想基于現(xiàn)有數(shù)據(jù)集快速訓(xùn)出一個能直接用的檢測模型這套東西最大的價值就在于不用你自己從零去爬數(shù)據(jù)、標(biāo)數(shù)據(jù)、調(diào)環(huán)境解壓之后數(shù)據(jù)、權(quán)重、推理代碼都齊了屬于典型的“拿來就能跑、跑完能改、改完能上”的項目結(jié)構(gòu)。這篇我就圍繞這套系統(tǒng)的完整鏈路——數(shù)據(jù)怎么組織的、模型為什么選YOLO26、訓(xùn)練和部署有哪些關(guān)鍵細(xì)節(jié)、實際跑起來會踩哪些坑——一條一條講清楚給想做同類項目的朋友一個可直接參考的實操樣本。1. 項目整體設(shè)計與技術(shù)選型思路1.1 車牌檢測在交通管理里的定位遠(yuǎn)不只是“拍個車牌”先厘清一個概念。很多人以為車牌檢測就是把攝像頭里的車牌框出來其實完整車輛識別系統(tǒng)里它只是第一環(huán)。真正的流程一般是車輛出現(xiàn) → 目標(biāo)檢測鎖定車輛位置 → 車牌檢測鎖定車牌區(qū)域 → 車牌字符識別LPR輸出文本 → 和數(shù)據(jù)庫比對做后續(xù)管理動作。這套打包內(nèi)容里主要解決的問題集中在“車輛檢測車牌檢測”這兩個目標(biāo)檢測環(huán)節(jié)附帶的數(shù)據(jù)集和訓(xùn)練好的模型可以直接復(fù)用識別環(huán)節(jié)你可以接PaddleOCR或者自訓(xùn)一個分類頭都不沖突。在交通管理場景里車牌檢測面臨的不是“能不能框住”的問題而是“復(fù)雜條件下穩(wěn)不穩(wěn)”的問題。我拆解下來實際需求集中在這么幾類電子警察違章抓拍車輛位置隨機、車速快、車牌角度傾斜需要檢測模型召回率高同時框要夠穩(wěn)不能一幀有一幀無。停車場出入口管理夜間低光、強逆光、車燈眩光外加車牌在畫面里占比不大對低光檢測能力要求高。卡口/高速收費多車道并行、車輛密集、相互遮擋這時候車輛檢測的精度往往比車牌檢測還關(guān)鍵因為車牌檢測是依賴車輛框做ROI裁剪的車輛漏檢后續(xù)全完。移動巡檢/車載終端嵌入式設(shè)備部署為主對模型體積、推理速度要求高模型量化后不能掉點太多。所以這套項目真正要解決的不是“用YOLO26跑個demo”而是“在真實交通場景下車輛和車牌能不能同時穩(wěn)定檢出”。1.2 為什么選YOLO26而不是繼續(xù)用v5/v8核心是結(jié)構(gòu)上的幾個改進講道理v5和v8依然是很多生產(chǎn)項目的主力我自己也在這兩個版本上踩過不少坑。YOLO26之所以值得關(guān)注我實測下來主要是這幾個方面的升級直接擊中了交通場景的痛點第一C2f模塊的變體進一步強化了梯度流動。堆疊更多分支的同時計算量控制得相當(dāng)好。對于車牌這種細(xì)節(jié)紋理密集的小目標(biāo)深層特征能保留更多邊緣和字符輪廓信息直觀感受就是小尺寸車牌的召回率比v8高了一截。第二anchor-free的檢測頭配合動態(tài)標(biāo)簽分配策略更成熟了。這意味著訓(xùn)練時正負(fù)樣本的定義更合理尤其是車牌這類長寬比極端標(biāo)準(zhǔn)藍牌是440×140比例接近3:1的目標(biāo)不再需要為它手工設(shè)計特定anchor訓(xùn)練省心很多。第三從結(jié)構(gòu)圖上能看到Y(jié)OLO26在neck部分強化了多尺度融合特別是淺層特征和深層特征的交互更頻繁。車牌目標(biāo)在1080p畫面里往往只有幾十個像素寬極其依賴淺層高分辨率特征這個改進直接提升了小目標(biāo)檢測上限。第四配套的部署生態(tài)完善。導(dǎo)出ONNX、TensorRT、OpenVINO的路徑都很成熟YOLO26也能走量化流程這對嵌入式設(shè)備場景非常友好。當(dāng)然你說v5能不能做車牌檢測能做但同樣的數(shù)據(jù)集和訓(xùn)練輪次下YOLO26的mAP和漏檢率就是更好看一些尤其是夜間低光那種極限場景。項目選了它方向是對的。1.3 系統(tǒng)的整體設(shè)計思路兩級檢測還是單級檢測拿到這套包之后我做的第一件事是看它的推理鏈路是“直接檢測車牌”還是“先檢測車輛再檢測車牌”。兩種路線都有人用但效果差很多直接單級檢測車牌整個畫面里直接找車牌。優(yōu)點是鏈路短、速度快缺點是誤檢率高因為車牌和某些反光物體、廣告牌字體在特征上容易混淆而且車輛密集時車牌被遮擋就完全失效。兩級檢測先檢測車輛car、bus、truck等再在車輛框內(nèi)部做車牌檢測。優(yōu)點是抗干擾能力強、誤檢大幅下降車輛檢測的結(jié)果還能直接用于車流量統(tǒng)計、軌跡跟蹤缺點是鏈路變長但計算量增加其實很小因為第二個檢測器只在ROI區(qū)域內(nèi)操作。這套項目默認(rèn)走的是兩級檢測路線數(shù)據(jù)集里也同時包含了車輛和車牌兩批標(biāo)注。我判斷這是刻意的設(shè)計——因為標(biāo)題里寫的是“交通管理和車輛識別系統(tǒng)”說明使用方要的不只是車牌還有車輛本身的類別、位置信息用來做車流統(tǒng)計、違停判斷、路徑追蹤。這種設(shè)計思路在實際項目中更值錢因為擴展性強后續(xù)想加車型識別、車身顏色識別都是在車輛檢測分支后面掛子任務(wù)不需要動主體架構(gòu)。2. 數(shù)據(jù)集的構(gòu)建與處理細(xì)節(jié)2.1 車牌數(shù)據(jù)集的構(gòu)成別被“數(shù)據(jù)集”三個字騙了這套zip里帶的數(shù)據(jù)集我解壓后仔細(xì)看了結(jié)構(gòu)標(biāo)注格式是YOLO標(biāo)準(zhǔn)的txt格式也就是每行一個目標(biāo)的 class_id x_center y_center width height坐標(biāo)都是歸一化到0~1之間的相對值。這種格式的好處是省空間、讀取快、和YOLO系訓(xùn)練腳本無縫銜接。里面大概分了兩部分?jǐn)?shù)據(jù)車輛檢測數(shù)據(jù)包含car、bus、truck、motorcycle等常見交通目標(biāo)類別畫面來源涵蓋城市道路、高速公路、停車場、路口等。車牌檢測數(shù)據(jù)只標(biāo)注plate一個類別但覆蓋了藍牌、黃牌、綠牌新能源、白牌警用/軍用等不同底色。這里要提醒一句公開數(shù)據(jù)集和自采數(shù)據(jù)混用是常態(tài)但一定要做去重和清洗。很多公開車牌數(shù)據(jù)集來自國外比如歐洲車牌、美國車牌字符排列和底色跟國內(nèi)差異巨大如果直接混在一起訓(xùn)練類別內(nèi)部的feature分布會非常散模型學(xué)到的是一片模糊的“平均車牌”。實操層面建議按項目落地地區(qū)做篩選這套數(shù)據(jù)明顯是以國內(nèi)車牌為主來整理的這點值得肯定。2.2 標(biāo)注規(guī)范與類別設(shè)計單類還是多類想清楚再動手我接觸過不少半路出家的項目數(shù)據(jù)沒少標(biāo)但訓(xùn)練效果就是不行問題多半出在標(biāo)注一致性上。車牌檢測雖然只有一個類別“plate”但標(biāo)注是否規(guī)范直接影響上限標(biāo)注框是否緊貼車牌邊緣如果框里包含了太多車漆、保險杠背景模型學(xué)到的特征就被污染了。傾斜車牌怎么處理YOLO系輸出的是水平矩形框傾斜車牌標(biāo)成水平框時框內(nèi)會包含大量背景。如果項目里傾斜車牌占比高要么訓(xùn)練時加入隨機旋轉(zhuǎn)增強要么干脆用OBB旋轉(zhuǎn)框方案但YOLO系原生支持旋轉(zhuǎn)框的版本有限工程上更多還是通過仿射變換讓模型適應(yīng)。多類別的合理性車輛檢測類別建議控制在5~8類以內(nèi)太多類會導(dǎo)致類別間特征混淆比如卡車和公交車在某些角度下人眼看都分不清模型學(xué)起來更痛苦。在類別設(shè)計上我的建議是車輛檢測模型里把van面包車單獨列出來而不是硬塞進car或者truck。因為面包車在尺寸上介于轎車和貨車之間特征也更接近SUV硬分類會導(dǎo)致后續(xù)數(shù)據(jù)統(tǒng)計失真。這套數(shù)據(jù)集的類別劃分我看了基本合理如果有擴展需求自己加類別然后補標(biāo)注就行。2.3 數(shù)據(jù)增強策略低光環(huán)境檢測的關(guān)鍵在增強而不在模型熱搜詞里專門有一條“yolo26低光環(huán)境檢測”這個點我必須展開說。車牌檢測在白天和夜間幾乎等于兩個不同任務(wù)——白天靠的是顏色對比度和字符邊緣夜間靠的是車牌反光特性和車燈周圍的亮度分布。同一個模型能不能同時吃下兩個場景數(shù)據(jù)增強策略決定一半。強烈建議在訓(xùn)練時開啟以下增強組合HSV擾動尤其是S和V通道的隨機變化模擬不同光照色溫和亮度。隨機亮度和對比度擾動低光場景的核心增強但不能全局壓暗最好配合局部明暗變化。Mosaic和MixUp這兩項已經(jīng)是YOLO系標(biāo)配了對提升泛化能力幫助很大。隨機旋轉(zhuǎn)和透視變換模擬不同拍攝角度對傾斜車牌提升明顯。隨機裁剪縮放模擬車牌在畫面中不同尺寸占比。這套項目里如果自帶增強參數(shù)我建議不要直接照搬而是根據(jù)你自己的數(shù)據(jù)分布微調(diào)。比如你的攝像頭裝在車道正上方車牌基本都是正對鏡頭的小角度傾斜那旋轉(zhuǎn)增強范圍就不需要太大否則反而引入無效的樣本分布。3. YOLO26環(huán)境配置與模型訓(xùn)練實操3.1 環(huán)境配置從零到能跑訓(xùn)練有哪些容易卡住的環(huán)節(jié)YOLO26的環(huán)境配置沒有想象中復(fù)雜但還是有幾個常見的坑。先列一下我自己實測可用的環(huán)境組合Python 3.9或3.10PyTorch 2.xCUDA版按你的顯卡驅(qū)動版本選對應(yīng)CUDA版本ultralytics庫YOLO26的官方訓(xùn)練/推理入口opencv-python、numpy、matplotlib等基礎(chǔ)依賴環(huán)境安裝順序上我的習(xí)慣是先裝PyTorch再裝ultralytics因為ultralytics會自動檢測已有的PyTorch版本并適配如果順序反了可能會導(dǎo)致CUDA不可用。裝完以后跑一下import torch; print(torch.cuda.is_available())確認(rèn)輸出是True再繼續(xù)。Windows用戶最容易卡在CUDA版本不匹配上。我的建議是先看顯卡驅(qū)動支持的CUDA版本NVIDIA控制面板能看到再裝對應(yīng)的PyTorch版本不要盲目裝最新版。另外如果在公司內(nèi)網(wǎng)環(huán)境pip源換成國內(nèi)鏡像可以省下大量等待時間。3.2 數(shù)據(jù)集組織與訓(xùn)練啟動目錄結(jié)構(gòu)決定了后續(xù)所有操作的順利程度數(shù)據(jù)集組織方式直接決定了后面所有的訓(xùn)練、驗證、測試操作是否順利。YOLO系的標(biāo)準(zhǔn)目錄結(jié)構(gòu)長這樣dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── data.yaml這里有個細(xì)節(jié)容易被忽略images和labels下面的train/val/test子目錄名稱必須完全一致而且圖片和標(biāo)簽的文件名主體要一一對應(yīng)。比如IMG_001.jpg對應(yīng)IMG_001.txt多一個空格或者后綴大小寫不一致都會導(dǎo)致訓(xùn)練時找不到標(biāo)簽。data.yaml文件內(nèi)容大致如下train: dataset/images/train val: dataset/images/val test: dataset/images/test nc: 6 names: [car, bus, truck, motorcycle, plate]注意nc要和names里的類別數(shù)一致這個寫錯的話模型結(jié)構(gòu)會跟標(biāo)簽維度對不上訓(xùn)練直接報錯。準(zhǔn)備好之后訓(xùn)練命令很簡單yolo detect train datadata.yaml modelyolo26n.pt epochs150 imgsz640 batch16 device0如果你用的是ultralytics庫也可以寫成Python腳本。怎么選base model我建議先用yolo26n.ptnano版跑通全流程確認(rèn)數(shù)據(jù)和環(huán)境都沒問題再上yolo26s.pt或者yolo26m.pt提升精度。3.3 訓(xùn)練參數(shù)調(diào)優(yōu)epochs、batch size、imgsz怎么設(shè)置才合理參數(shù)設(shè)置是新手翻車重災(zāi)區(qū)。我基于這套車牌檢測項目給幾個常用經(jīng)驗值imgsz輸入分辨率車牌檢測建議至少640如果目標(biāo)是小車牌或遠(yuǎn)距離場景上到960甚至1280也可以。分辨率越高小目標(biāo)信息保留越多但顯存占用和推理耗時同步上升需要自己權(quán)衡。我實測640和960在中等距離車牌上的mAP差距能有3~5個點相當(dāng)可觀。batch size能多大就多大受限于顯存。batch size太小比如2或4會導(dǎo)致BN層統(tǒng)計不穩(wěn)定訓(xùn)練震蕩明顯。如果顯存不夠優(yōu)先減小imgsz而不是硬撐大batch。epochs數(shù)據(jù)集規(guī)模5000張以內(nèi)的話150~300輪足夠收斂。判斷標(biāo)準(zhǔn)不是只看loss曲線還要看驗證集mAP是否進入平臺期。如果到200輪還在緩慢上升可以繼續(xù)加跑用早停機制控制。優(yōu)化器默認(rèn)的SGD或者AdamW都行我更推薦AdamW配合適當(dāng)?shù)膶W(xué)習(xí)率衰減策略對小數(shù)據(jù)集收斂更快更穩(wěn)。訓(xùn)練過程中重點盯兩個指標(biāo)一個是box_loss和cls_loss的下降曲線另一個是驗證集上的mAP50和mAP50-95。如果mAP50很高但mAP50-95偏低說明模型能框住目標(biāo)但框的精度不夠通?？梢酝ㄟ^提高imgsz或者增加高質(zhì)量標(biāo)注來緩解。3.4 訓(xùn)練好的模型怎么用加載權(quán)重做推理測試訓(xùn)練完成后runs/detect/train/weights/目錄下會有best.pt和last.pt兩個文件。best.pt是驗證集表現(xiàn)最好的權(quán)重last.pt是最后一輪的權(quán)重。日常推理和部署都用best.pt這是老規(guī)矩了。在圖片上做推理測試from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict(test_images/road1.jpg, conf0.25, imgsz640, saveTrue)在視頻流或者攝像頭實時畫面上做推理model YOLO(runs/detect/train/weights/best.pt) results model.predict(road_video.mp4, conf0.25, imgsz640, saveTrue, streamTrue)如果要做實時視頻流建議把streamTrue打開同時用vid_stride參數(shù)控制抽幀頻率比如vid_stride2表示每兩幀處理一幀對控制CPU占用和延遲很有幫助。4. 模型部署與交通管理場景落地4.1 從PyTorch權(quán)重到部署格式ONNX導(dǎo)出和精度確認(rèn)訓(xùn)練好的模型只是第一步真實交通管理系統(tǒng)里模型通常要部署到服務(wù)端推理引擎或者邊緣設(shè)備上這時PyTorch的.pt格式就不夠用了。最常規(guī)的中間步驟是導(dǎo)出ONNX格式y(tǒng)olo export modelbest.pt formatonnx imgsz640 opset12導(dǎo)出ONNX過程有幾個細(xì)節(jié)要確認(rèn)導(dǎo)出的onnx文件用Netron打開看一眼計算圖是否完整特別是檢測頭部分有沒有被錯誤裁剪。用onnxruntime跑一遍同一張測試圖和PyTorch推理結(jié)果對一下確認(rèn)精度沒有明顯掉點。正常情況下兩者差異不超過0.5%。如果后續(xù)要走TensorRT加速在導(dǎo)出ONNX時就要固定batch size和imgszTensorRT對動態(tài)shape支持相對麻煩。導(dǎo)出的ONNX可以無縫接到服務(wù)端推理框架或者再轉(zhuǎn)成TensorRT的engine格式在NVIDIA設(shè)備上跑。如果目標(biāo)平臺是嵌入式設(shè)備比如Jetson系列或者瑞芯微/算能這類國產(chǎn)NPUONNX→對應(yīng)平臺模型格式的轉(zhuǎn)換流程基本都能走通。4.2 嵌入式設(shè)備部署注意事項量化與推理速度的權(quán)衡熱搜詞里有一條問“yolov8訓(xùn)練好的模型怎么部署到嵌入式設(shè)備”這個問題換到Y(jié)OLO26身上同樣適用。嵌入式設(shè)備部署的核心矛盾是算力有限模型不能太大但精度還得保住。部署到嵌入式設(shè)備前我建議優(yōu)先做這幾件事模型輕量化從yolo26nnano版起步nano版參數(shù)量只有幾M在邊緣設(shè)備上跑實時沒有壓力。INT8量化YOLO26走量化流程已經(jīng)很成熟把權(quán)重從FP32壓到INT8理論上能帶來2~4倍速度提升。量化的前提是準(zhǔn)備幾百張有代表性的校準(zhǔn)圖片最好覆蓋白天、夜晚、雨天等不同場景。量化后的精度掉點在1%~3%之間屬于正常掉了5%以上就得檢查校準(zhǔn)集是不是太偏了。內(nèi)存和緩存優(yōu)化嵌入式設(shè)備顯存/內(nèi)存有限推理時盡量減少圖像縮放和格式轉(zhuǎn)換帶來的臨時內(nèi)存開銷。如果你用的是瑞芯微的RK3588這類NPU平臺量化和模型轉(zhuǎn)換時要特別注意算子支持范圍有些自定義算子NPU不支持需要改網(wǎng)絡(luò)結(jié)構(gòu)或者在轉(zhuǎn)換時做算子映射這一步往往比訓(xùn)練本身更費時間。4.3 端到端車輛識別系統(tǒng)集成從檢測到業(yè)務(wù)聯(lián)動這套系統(tǒng)的最終價值還是在業(yè)務(wù)聯(lián)動上。光有檢測框不算完成落到交通管理場景里還要接跟蹤、計數(shù)、聯(lián)動等邏輯。以停車場出入口為例完整的端到端流程可以這么設(shè)計車輛檢測模型在視頻流中持續(xù)檢測車輛目標(biāo)輸出車輛位置框和置信度。用ByteTrack或DeepSORT對車輛框做跟蹤給每個車輛分配唯一ID實現(xiàn)跨幀連續(xù)跟蹤。當(dāng)車輛ID首次出現(xiàn)在畫面中時觸發(fā)車牌檢測模型在該車輛框區(qū)域內(nèi)檢測車牌。車牌檢測結(jié)果送入OCR模塊比如PaddleOCR的車牌識別模型提取車牌號文本。車牌文本和車輛軌跡ID綁定寫入數(shù)據(jù)庫聯(lián)動道閘控制。這套鏈路里YOLO26的車輛檢測結(jié)果作為“觸發(fā)器”質(zhì)量好壞直接影響整個系統(tǒng)的穩(wěn)定度。如果車輛檢測的置信度閾值設(shè)太高夜間可能會漏檢設(shè)太低又會誤檢路邊的垃圾桶、廣告牌。我一般白天設(shè)0.35夜間設(shè)0.25再配合目標(biāo)跟蹤算法做置信度平滑效果比固定閾值好很多。5. 常見問題與排查技巧實錄5.1 夜間低光環(huán)境檢測效果差先別急著換模型檢查你的數(shù)據(jù)增強我見過太多人一上來就說“夜間效果差我要換更大的模型”但實際上問題往往不在模型而在訓(xùn)練數(shù)據(jù)的分布。如果你訓(xùn)練集里夜間圖片占比不到10%再大的模型也白搭。排查順序是這樣的先統(tǒng)計訓(xùn)練數(shù)據(jù)里白天和夜間圖片的數(shù)量如果夜間少于20%優(yōu)先補數(shù)據(jù)或者做亮度增強。檢查低光圖片的標(biāo)注質(zhì)量夜間圖片往往因為人眼看不清標(biāo)注本身就存在大量漏標(biāo)和錯標(biāo)。帶著錯誤標(biāo)簽訓(xùn)練模型學(xué)到的是噪聲。開啟了亮度/對比度增強之后觀察夜間驗證集的mAP變化。如果提升不明顯考慮單獨加入夜間樣本的復(fù)制增強或者用簡單的方式把部分白天圖轉(zhuǎn)成偽夜間圖降低亮度、增加噪聲、模擬車燈強光。5.2 小目標(biāo)和遠(yuǎn)距離車牌漏檢提升imgsz是最有效的手段之一車牌在畫面上占比很小的時候模型檢不出來不奇怪。最有效的解決方案是在部署設(shè)備算力允許的范圍內(nèi)把推理imgsz從640提升到960或1280。每提升一檔小目標(biāo)在特征圖上的有效像素就多一圈檢測能力提升立竿見影。但注意imgsz提升會帶來推理耗時增加。如果設(shè)備扛不住折中方案是“區(qū)域放大局部檢測”先在低分辨率幀上跑車輛檢測找到車輛位置。把車輛區(qū)域裁剪出來放大后單獨跑車牌檢測。這個策略相當(dāng)于把算力集中在關(guān)鍵區(qū)域比全圖拉高分辨率劃算得多。5.3 誤檢太多置信度閾值和NMS參數(shù)的聯(lián)合調(diào)整誤檢問題比漏檢更讓人頭疼因為漏檢只是“沒檢測到”誤檢會直接導(dǎo)致業(yè)務(wù)誤判比如把路邊的“某某汽修”招牌當(dāng)成車牌識別出一堆亂碼入庫。處理誤檢我建議按這個順序來先把置信度閾值從0.25提升到0.4或者0.5觀察誤檢是否減少。如果只是閾值問題這一步就能解決。如果閾值拉高后誤檢還是存在檢查NMS的IoU閾值。默認(rèn)的0.45在某些場景偏松把重復(fù)框壓掉的時候不夠狠。可以嘗試調(diào)到0.4減少重疊框保留數(shù)量。如果以上都不行問題多半在訓(xùn)練數(shù)據(jù)的負(fù)樣本不足。你在標(biāo)注時只標(biāo)了正樣本沒標(biāo)“像車牌的負(fù)樣本”模型沒有見過“不是車牌但長得像車牌”的東西自然分不清。建議專門收集一批廣告牌、文字標(biāo)識、車燈反光區(qū)域的圖片標(biāo)注為background類放入訓(xùn)練集。5.4 訓(xùn)練時loss不下降或者直接NaN八成是數(shù)據(jù)和環(huán)境問題訓(xùn)練過程里最讓人崩潰的就是loss不降或者直接跑飛成NaN。根據(jù)這幾年的經(jīng)驗90%是以下原因?qū)W習(xí)率設(shè)置過大。YOLO系列的默認(rèn)學(xué)習(xí)率一般沒問題但如果你自己改了優(yōu)化器或者加了自定義學(xué)習(xí)率調(diào)度注意初始學(xué)習(xí)率不要超過0.01。數(shù)據(jù)標(biāo)簽有問題。標(biāo)簽文件里出現(xiàn)超過圖片邊界的坐標(biāo)值比如x_center 1或者類別id超出了nc范圍會導(dǎo)致訓(xùn)練過程中梯度爆炸?；旌暇扔?xùn)練AMP在個別顯卡上有兼容性問題如果loss出現(xiàn)NaN先關(guān)掉AMP試試。這些排查邏輯放在YOLO26上完全適用訓(xùn)練報錯時先看控制臺輸出的警告信息再回溯到數(shù)據(jù)和參數(shù)設(shè)置不要一上來就重裝環(huán)境。5.5 標(biāo)注數(shù)據(jù)不足時的自救方案公開數(shù)據(jù)集預(yù)訓(xùn)練模型微調(diào)很多個人開發(fā)者或者小團隊沒有數(shù)據(jù)標(biāo)注團隊這里的自救方案是盡量找同領(lǐng)域公開數(shù)據(jù)集做預(yù)訓(xùn)練再在自己的小數(shù)據(jù)集上微調(diào)。車牌檢測相關(guān)的公開數(shù)據(jù)集有不少選擇常用的有CCPD中國城市車牌數(shù)據(jù)集國內(nèi)車牌檢測經(jīng)典數(shù)據(jù)集的代表覆蓋多種天氣和光照條件。各類車輛檢測數(shù)據(jù)集比如UA-DETRAC、BDD100K、KITTI等都能用于車輛檢測分支的預(yù)訓(xùn)練。如果你的場景有特殊要求比如無人機視角、水面、礦區(qū)等找對應(yīng)的垂直數(shù)據(jù)集做domain adaptation會更有幫助。另外“yolo26訓(xùn)練自己的數(shù)據(jù)集”這條熱搜詞下的內(nèi)容核心流程就是數(shù)據(jù)準(zhǔn)備 → 標(biāo)注格式轉(zhuǎn)換 → data.yaml配置 → 預(yù)訓(xùn)練權(quán)重微調(diào)。跑通一次后換任何數(shù)據(jù)集都是同樣的套路。寫在最后這套系統(tǒng)的擴展方向如果你只是把訓(xùn)練好的模型拿去跑通推理那這套項目其實用到一半就浪費了。我個人覺得基于這套系統(tǒng)的數(shù)據(jù)、權(quán)重和代碼后續(xù)至少還可以往三個方向擴展一是加識別。車牌檢測只解決“車牌的框在哪”再加一個OCR模塊就能解決“車牌號是什么”。PaddleOCR的車牌識別模型可以直接接在檢測結(jié)果后面字符識別準(zhǔn)確率在常規(guī)場景下能到95%以上。二是加跟蹤。把檢測結(jié)果交給ByteTrack做多目標(biāo)跟蹤就能實現(xiàn)車輛軌跡記錄、車流統(tǒng)計、逆行檢測、違停時長計算等功能從“能看見”升級到“能理解”。三是加場景適配。如果要把這套系統(tǒng)從城市道路搬到高速公路或者園區(qū)內(nèi)部道路需要用目標(biāo)場景的數(shù)據(jù)對模型做微調(diào)同時調(diào)整前后處理邏輯比如高速場景需要更關(guān)注遠(yuǎn)距離小目標(biāo)園區(qū)場景需要更關(guān)注夜間和逆光。拿這套項目當(dāng)起點把上面三條線中的任何一條打通你手里的就不僅僅是一個車牌檢測模型而是一套五臟俱全的智能交通管理系統(tǒng)雛形。本文還有配套的精品資源點擊獲取