簡介本資源是一套基于YOLO目標檢測算法的排水系統與廢棄物管理智能監控解決方案面向計算機視覺初學者、環境工程智能化方向開發者及智慧城市項目實踐者聚焦于管道異物識別、垃圾類型分類等真實工業場景的自動化圖像分析需求。壓縮包共240個文件含72張標注/測試用PNG圖像、27個DartFlutter移動端邏輯、15個JSXWeb前端界面、13個JSON配置與標注數據、9個XMLPascal VOC格式標簽、8個C/C源文件含Flutter插件底層實現及若干構建配置與平臺適配文件整體大小為54.64MB結構覆蓋端側部署、跨平臺集成與API服務接口設計。已有35人學習下載資源提供完整可運行的YOLO推理流程、多端移動端/Web/API集成示例、典型廢棄物與排水異常樣本圖像及配套工程目錄組織便于快速復現、二次開發與教學演示。 上個月拿到一個“基于YOLO的排水系統與廢棄物管理.zip”的工程包解壓完看完目錄說實話挺感慨的。這類項目壓縮包網上不少但大多數是把模型跑個demo就結束真正值得參考的是從數據組織、模型訓練到邊緣部署、再到業務閉環的完整鏈路。這個項目把排水管網巡檢和城市廢棄物管理兩條線塞進了同一個檢測引擎里解決的實際問題很樸素市政養護和環衛保潔靠人盯視頻太累了而且漏檢率不低。這篇就按我自己的理解和實測經驗把這個包里面應該有的東西、踩過的坑、以及這類項目落地時真正要注意的細節展開聊一聊。適合正在做智慧水務、智慧環衛算法或者想在邊緣設備上跑YOLO檢測的朋友參考。1. 解壓這個zip包它構建的是一套“排水環衛”雙場景檢測閉環1.1 排水系統巡檢的核心痛點與YOLO的切入點先聊需求背景。水務管網運維公司每天都會產生大量排水管道CCTV檢測錄像就是那個小機器人鉆進管道里拍的視頻。這些視頻靠人工逐幀去看什么樣的管道有破裂、變形、堵塞、樹根侵入全靠巡檢員的眼力。一個半小時的視頻盯下來漏檢是大概率事件。廢棄物管理那邊則是另外一撥人天天盯著河道監控、排水口監控、雨水箅子截圖數哪里有漂浮垃圾、哪里被傾倒渣土、哪里箅子堵了。這兩個場景看起來差很遠但落到算法層面本質是同一件事目標檢測——在圖像或視頻流里把特定的目標定位出來。管道里的破裂口是一個目標河道里的漂浮物也是一個目標雨水箅子上的樹葉堆積還是一個目標。所以這個zip包的核心思路就是用一套YOLO檢測引擎同時喂兩個場景的數據訓練多個檢測頭或者配置多套權重最后統一部署到邊緣盒子或服務器上。從項目解壓后的目錄結構來看組織得比較常規但很實用. ├── data/ │ ├── drainage/ # 排水管道場景數據集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ ├── waste/ # 廢棄物管理場景數據集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ └── fusion/ # 兩個場景混合訓練數據 ├── models/ │ ├── yolov8n_drainage.pt │ ├── yolov8s_waste.pt │ └── yolov11n_fusion.pt ├── scripts/ │ ├── train.py │ ├── export.py │ └── detect.py ├── configs/ │ ├── train_drainage.yaml │ ├── train_waste.yaml │ └── deploy.yaml ├── docs/ └── weights/data目錄把兩個場景分得很清楚models和weights區分了不同版本的權重文件scripts是訓練、導出、推理三個階段的入口configs放超參數和部署配置。這種目錄設計對后續維護很友好尤其是當你要給不同客戶交付不同場景的模型時數據、模型、配置分離能省很多事。1.2 檢測類別體系怎么定別按“物體”分按“動作”分設計類別是最容易被忽略、但影響最大的環節。很多人拿到排水圖就先標“管道”“垃圾”“樹葉”這種按物體分類的方式在真實業務里基本沒法用。運維人員關心的是“這個位置是否需要人工處理”所以類別應該是動作導向的我按項目里的做法整理了幾類場景建議類別說明管道內檢crack破裂、deformation變形、obstruction堵塞物、root_intrusion樹根侵入病害類直接對接養護工單排水口/箅子blocked_grating箅子堵塞、garbage_accumulation垃圾堆積、illegal_dumping違規傾倒城市面源污染治理河道/泵站前池floating_garbage漂浮物、oil_slick油污、algal_bloom藻類聚集水體巡查環衛設施bin_overflow垃圾滿溢、bagged_waste袋裝垃圾、bulky_waste大件廢棄物環衛清運調度這套類別體系的邏輯是檢測結果要能直接映射到處置動作。檢測出“破裂”就派管道修復工單檢測出“箅子堵塞”就派清撈任務檢測出“垃圾滿溢”就調整清運路線。如果只輸出“垃圾”這種泛化類別后續系統集成時還得再做一層語義判斷項目交付時很難讓客戶滿意。1.3 兩條業務線共用一套檢測引擎的技術選型邏輯為什么不用兩個獨立模型分別跑而非要共用一個引擎核心原因是部署和維護成本。排水和廢棄物檢測在邊緣盒子上跑的時候如果每個場景都拉一個獨立推理服務內存、顯存、進程管理復雜度都翻倍。共用引擎的做法是同一個推理程序讀不同權重文件或者干脆用多任務模型共享backbone只在head層分叉。這個項目屬于前者——同一套YOLO推理代碼通過configs里的部署配置文件切換權重。這樣邊緣盒子上只裝一個推理服務API接口統一現場更新模型權重時不用重新編譯程序。對于甲方來說他們最怕的就是每次改需求都要重新部署整套系統這種一個服務多套權重的模式明顯更好維護。2. 數據工程排水場景里數據集質量比模型版本更重要2.1 數據來源其實很雜CCTV取幀、監控截圖、無人機航拍做排水廢棄物檢測數據來源往往有三路。第一路是CCTV管道機器人視頻這是管道病害檢測的主力數據源特點是視野窄、光照不均勻、畫面里全是管道內壁目標集中在正前方。第二路是固定點位監控包括河道監控、排水口監控、垃圾投放點監控特點是視角固定、背景變化小、但要檢測的目標在畫面里往往很小。第三路是無人機航拍主要用于河道兩側、大型垃圾堆放點的巡查特點是俯瞰視角、目標尺度變化大。不同來源的數據要分開處理不能直接混在一起訓練。我的建議是先用腳本把視頻抽幀CCTV視頻一般每秒抽1幀就夠抽多了相鄰幀高度相似對訓練沒什么幫助。監控視頻也一樣做一下去重只保留畫面有變化的幀。無人機航拍因為視角和目標尺度太特殊如果樣本量不夠最好單獨做一個數據子集而不是硬塞進主訓練集。2.2 從xml/voc到yolo格式轉換與坐標歸一化踩坑很多公開數據集和甲方給的歷史標注數據都是Pascal VOC格式xml文件需要轉成YOLO的txt格式。轉換代碼很簡單核心是坐標歸一化import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_map): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: continue cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 轉成YOLO格式類id、中心點x、中心點y、寬、高全部歸一化 cx (xmin xmax) / 2 / img_w cy (ymin ymax) / 2 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防止越界 cx min(max(cx, 0.0), 1.0) cy min(max(cy, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines))這個代碼看起來很常規但有兩個坑我特別提一下。一是xml里有些框會超出圖像邊界比如xmax大于圖片寬度轉出來的w就大于1訓練時YOLO會收到不合法目標輕則訓練波動重則指標全亂。所以上面代碼里加了個clip操作把這部分異常值壓回0到1。二是class_map的順序一旦定了就別改訓練和推理要保證同一個映射表否則模型輸出的類別id對應不上部署時全亂套。2.3 小目標與切片策略遠處的漂浮物到底怎么檢排水和廢棄物場景里最典型的識別難點就是小目標。一個礦泉水瓶在1080p河道監控畫面里往往只有二三十個像素寬一個箅子堵塞點的裂縫細節在管道CCTV畫面里也只占很小一塊。直接用YOLO訓練這種小目標mAP會很難看。項目里比較有效的思路是切片。把大圖切成若干個重疊的patch每個patch單獨送進模型檢測然后把檢測框坐標映射回原圖。切片的窗口大小和重疊率要看目標尺寸來定我這邊常用的是960x960窗口、20%重疊率。超分辨率放大目標區域也是一個補救方案但推理耗時增加明顯邊緣設備上不太劃算。另一個更省事的辦法是調大訓練時的輸入分辨率把imgsz從默認的640調到960甚至1280。代價是顯存占用和訓練時間上升但對小目標的提升是實打實的。我建議先用imgsz1280跑一版對比一下mAP50-95如果提升明顯部署時也保持同樣的輸入尺寸不要訓練和部署不一致。2.4 類別不平衡和難例挖掘廢棄物樣本少怎么破廢棄物檢測有個天然問題很多類別的正樣本特別少。河道里偶爾才有油污違規傾倒更是幾個月才發生一次能拍到并標注的樣本鳳毛麟角。類別不平衡直接導致模型把少數類全部預測成背景損失函數被多數類主導。項目里的做法是針對少數類做在線硬例挖掘也就是把那些被錯誤預測為背景的樣本單獨挑出來反饋到訓練數據里。另外Ultralytics框架里也可以調loss權重在dataset.yaml的cls參數上做加權。數據增強方面Mosaic和MixUp對這些場景很有效尤其是Mosaic能把四張圖拼成一張增加小目標密度的同時讓模型看到更多上下文信息。這里還有一個工程技巧先用少數類的樣本單獨做一個預訓練模型再混合全量數據繼續訓練。這樣相當于先讓模型記住“油污長什么樣”再學“什么場景下會出現油污”實測對少數類的召回率提升很明顯。3. 模型選型與結構改進從YOLOv8到YOLO11哪些特性對排水場景真正有用3.1 anchor-free帶來的變化為什么對這類場景友好YOLOv8以后全面轉向anchor-free這個變化對排水廢棄物場景的意義很多人沒意識到。以前YOLOv5要預設一組anchor尺寸如果預設的框和你業務里目標的長寬比差太多訓練收斂就慢小目標更是吃大虧。排水管道里的裂縫細長條、河道里的漂浮物形狀各異anchor-free機制讓模型直接在特征圖上回歸中心點和寬高省掉了anchor匹配這層負擔模型自由度更大對不同形狀目標的適應能力更強。這個項目里面用的是帶anchor-free head的YOLO好處是推理代碼里少了一步anchor解碼在邊緣部署時省了一點點延遲。對工程團隊來說YOLOv8以后模型結構統一、導出ONNX更干凈也是選擇它的重要原因。3.2 YOLO11相比YOLOv8的變化哪些升級對業務有實際收益熱詞里很多人問YOLOv11和YOLOv8的區別我按這個項目的實驗結論說一下。結構上YOLOv11把C2f模塊換成了C3k2更輕量檢測頭那邊做了更細的解耦分類和回歸分支分離得更徹底。實際訓練下來在排水管道病害數據集上YOLO11的mAP50比YOLOv8s高大概1.2個百分點同時推理速度還快了約15%。這個提升幅度算不上質變但結合速度優勢已經足夠讓我把默認基線從v8換到v11。真正值得關注的是YOLO11對動態卷積和注意力機制的整合。像C3k2里融入的一些輕量注意力對河道場景里“從背景中區分漂浮物”這種任務有正向作用因為它能讓特征提取更關注紋理和顏色差異。但注意模型不是越新越好如果你部署的盒子算力有限YOLO11n可能是更穩的選擇吞吐量比s級高一截精度差距在可接受范圍內。3.3 更換主干網絡的經驗從默認backbone到更輕量的替代方案熱詞里有人提到vanillanet換主干這個思路在邊緣部署場景很值得做。YOLO默認的backbone在GPU上表現不錯但到了Jetson這類邊緣設備上算力立即變成瓶頸。換用vanillanet這類以深度卷積為主的主干可以有效減少FLOPs和參數規模。具體做法是改模型的yaml配置文件把backbone部分直接替換掉不動的部分繼續復用預訓練權重。這里有個細節替換backbone后很多層的shape會發生改變Ultralytics框架會重新初始化結構但如果你只改backbone而保留head可以在加載預訓練權重時用strictFalse參數讓能對齊的層權重保留徹底對齊不了的重新學。實測這樣比從頭訓練收斂快很多。不過主干替換有代價。換vanillanet之后同等輸入尺寸下精度大概下降0.5到1個百分點它的價值在于把推理延遲壓下來。具體怎么取舍取決于你部署設備的算力預算而不是模型本身的好壞。3.4 多任務與開放詞表檢測的擴展垃圾分類和“新垃圾種類”怎么應對廢棄物管理有一個很實際的需求——垃圾細分。同樣是垃圾可回收物、廚余垃圾、有害垃圾的處置路徑完全不同。單純的檢測框只能告訴你“這里有垃圾”不能告訴你是哪一類。方案是在檢測頭后面加一個分類分支或者用YOLO的多任務能力同時輸出檢測框和分類標簽。YOLOv8/v11本身支持多任務擴展你可以把分類任務作為一個輔助head并行訓練共享backbone特征。另外一個更新穎的方向是開放詞表目標檢測像YOLO-World這種。它能把文本編碼器和檢測器結合起來推理時輸入任意類別名稱就能檢測出對應目標不用重新訓練。這個特性在廢棄物場景里很實用——今天要查“白色泡沫箱”明天要查“廢舊輪胎”這些新類別如果走傳統重訓流程要一到兩周用開放詞表模型的話直接改prompt就行。當然它的精度比專用模型略低適合做初篩或者巡檢口徑很寬的場景。4. 訓練過程中的常見翻車點指標全0、loss異常與續訓恢復4.1 訓練指標全為0的排查鏈路從數據讀到學習率逐個排除如果你訓練時發現精確率、召回率、mAP全部是0大概率不是模型問題是訓練數據或超參配置出了問題。我遇到過太多次這種情況按下面的順序排查最有效率先看數據加載是否正常。打開訓練日志里顯示的樣本圖片確認不是全黑或全灰圖確認標注框真的畫在圖片內容上。可視化幾個標注看一下比看坐標數字可靠得多。檢查標簽文件。用腳本統計每個txt文件第一列類別id看最大值是否超出了dataset.yaml里nc-1。類別id越界是靜默錯誤訓練不報錯但模型根本學不會。檢查歸一化坐標。如果標簽里出現負數或者大于1的坐標就是轉換腳本沒做clip按我前面給的那個代碼補上就行。看學習率。如果你用了自定義的lr初始學習率設得過大比如0.1訓練第一個epoch loss就會爆炸指標當然全0。Ultralytics默認的lr00.01對大多數場景是安全的除非你換了特別小的batch size。最后做一個單圖overfit測試把訓練集縮減到一張圖跑20個epoch如果loss能降到接近0說明模型結構和數據管線是通的問題出在訓練集本身。如果單圖都學不進去那就是標簽或者預處理有硬傷。這個排查思路我建議貼在項目文檔里團隊里任何人訓練翻車都能按圖索驥。4.2 loss不收斂、mAP震蕩的常見調參手段排水廢棄物場景的樣本分布差異大訓練過程中mAP震蕩是常態。常見的手段包括增大batch size穩定梯度降低lr配合warmup讓訓練平穩啟動EMA指數滑動平均在多epoch訓練下能明顯平滑指標波動Ultralytics默認是開啟的沒必要關。還有一個容易被忽略的參數是weight_decay。在小型數據集上weight_decay設太大會讓模型欠擬合設太小又容易過擬合。我這邊在排水場景數據集上常用的配置是lr00.01、lrf0.01、weight_decay0.0005batch size根據顯存盡可能往上頂最好不低于16。如果你的顯卡只能跑到batch size4那條數據訓練會非常抖建議用accumulate參數做梯度累積等效放大batch size。數據增強也是影響收斂的重要因素。Ultralytics默認的增強策略在通用目標上表現不錯但排水管道CCTV畫面有很強的方向性比如畫面下方永遠是管道內壁底部。Mosaic增強會把四張圖旋轉拼貼可能讓模型學到錯誤的方向先驗。我在這個項目里的做法是量夠大之后關掉Mosaic只保留hsv、fliplr這類溫和增強讓模型專注于學習紋理特征。4.3 小樣本訓練的四個策略預訓練、凍結、增強、偽標簽排水和廢棄物場景經常只有幾百張標注圖這種體量直接從頭訓YOLO基本是浪費顯存。我常用的四個策略按優先級排序加載COCO預訓練權重即使你的類別跟COCO完全不重合backbone學到的低層特征邊緣、紋理、顏色塊依然有效。凍結backbone只訓練head。數據量少時凍結主干能防止低層特征被破壞。一般前10個epoch凍結之后解凍整個網絡用低學習率微調。數據增強拉滿。除了默認增強可以再加隨機旋轉、隨機透視、復制粘貼目標。復制粘貼這個技巧對廢棄物場景特別有用因為河道里的垃圾分布是稀疏的。偽標簽。用訓練好的模型在無標注監控視頻上做預測把高置信度的檢測結果當標注回填訓練集然后重新訓練。這是半監督里最簡單的一招但能顯著提升小樣本下的召回率。4.4 訓練中斷怎么暫停和續訓last.pt與best.pt的正確用法訓練過程中按CtrlC中斷或者服務器掉電這種情況在項目現場太常見了。Ultralytics框架里訓練到一定epoch會自動保存last.pt和best.pt兩個權重文件。last.pt是最近一個epoch的權重best.pt是驗證集上指標最好的那個epoch的權重。續訓的正確姿勢是from ultralytics import YOLO # resume訓練會自動從last.pt恢復 model YOLO(runs/detect/train/weights/last.pt) model.train(resumeTrue)注意resumeTrue時不用重新指定數據集和超參框架會讀取上次訓練保存的配置文件。工程上我建議定期手動把手頭的權重復制一份帶時間戳保存防止last.pt和best.pt被覆蓋后又后悔。“yolo怎么暫停”這個熱詞大家經常搜實際上就是上面這樣中斷后resume即可。但有一點如果你用LibTorch或OpenCV DNN做部署時的模型文件是onnx訓練中斷不影響已經導出的onnx不需要重新訓練。4.5 在vscode里本地調模型的工作流建議用VSCode在本地調試YOLO訓練我自己的慣例是先用小數據集、小模型yolov8n.pt跑通整個流程確認數據管線和訓練參數沒有硬傷再切換成正式數據集和大模型。這個習慣能幫你把“訓練環境配置錯誤”和“模型質量問題”這兩類問題分開。調試時建議用Ultralytics的GUI的weightbiases集成或comet或者干脆用tensorboard觀察train/loss和val/mAP的實時曲線。如果vscode的Python調試器直接掛著訓練進程調試性能會慢很多我一般只調試推理腳本和數據預處理腳本訓練腳本直接跑命令行。5. 部署與實測邊緣盒子、C推理和“用OpenCV量物體大小”5.1 從pt導出ONNX/TensorRT格式選擇和量化細節模型訓練完之后要部署第一步是把torch權重導出成推理引擎能跑的格式。Ultralytics框架一行命令就能導出yolo export modelweights/best.pt formatonnx imgsz640 halfTrueonnx是比較通用的中間格式CPU上可以用OpenCV DNN或者ONNX Runtime跑GPU上可以進一步用TensorRT構建engine。TensorRT的engine格式是NVIDIA平臺專屬的但推理速度最快。導出時要注意選擇halfTrue開啟FP16這能讓顯存占用減半、吞吐量接近翻倍。如果顯存更緊張還可以考慮INT8量化但INT8需要標定數據集而且這個項目里排水管道病害這類細節紋理在INT8下精度損失明顯實測不建議。導出之后一定在部署環境上用相同輸入尺寸實測一遍因為訓練時的數據增強和預處理letterbox要在推理側復現否則圖像被拉伸變形檢測框位置就全偏了。5.2 C環境部署要點OpenCV DNN和ONNX Runtime的實際取舍很多現場設備是Linux工控機沒法裝Python環境C部署就成了必須項。C側加載YOLO模型有兩個主流選擇OpenCV DNN模塊和ONNX Runtime C API。OpenCV DNN適合快速上線不用引入額外依賴但它的NMS實現和TRT比還是有點差距batch推理支持也弱一些。ONNX Runtime則是更正規的選擇支持CUDA EP能精確控制輸入輸出張量。我這邊更推薦ONNX Runtime代碼結構大概是這樣Ort::Env env(ORT_LOGGING_LEVEL_WARNING, yolo); Ort::SessionOptions opts; opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); Ort::Session session(env, model.onnx, opts); // 輸入預處理letterbox BGR2RGB normalize cv::Mat letterbox_img letterbox(frame, input_shape); cv::cvtColor(letterbox_img, blob, cv::COLOR_BGR2RGB); blob.convertTo(blob, CV_32F, 1.0 / 255.0); // 推理 std::vectorfloat input_tensor_values(blob.beginfloat(), blob.endfloat()); // 構造Ort::Value并Run // 后處理解碼bbox NMS 坐標映射回原圖推理出來的結果是歸一化的中心點、寬高要映射回原圖坐標時記得把letterbox的填充偏移減掉再除以縮放系數。這一步寫錯會導致檢測框整體偏移現場排查非常費勁。5.3 用OpenCV測量檢測物體的實際大小很多業務場景不只要知道“這里有垃圾”還想知道“這個垃圾有多大”。比如河道監管要求超過一定面積的漂浮物才算事件。我們可以用OpenCV結合相機標定來做測量。最簡單實用的方法是用已知尺寸的參考物做像素標定。比如一個標準雨水箅子直徑是800毫米在畫面里某個位置測出對應像素寬度是100像素那像素尺寸轉換系數就是8毫米/像素。檢測時把模型輸出的框寬高乘以這個系數就得到近似物理尺寸。注意這個系數只在該參考物所在平面附近有效離得太遠誤差會增大。更正規的做法是用相機標定calibrate camera獲取內外參然后通過地面平面的單應性矩陣把像素坐標轉換成世界坐標。但這個對現場實施的要求比較高需要知道相機的安裝高度和俯仰角。如果甲方對測量的準確性有硬性要求這個環節就得專門做而不是靠估計。論工程項目我個人的建議是先按參考物法快速上線等有投訴或者精度不達標時再上完整標定方案這樣能控制初期交付成本。5.4 邊緣設備選型與性能預算部署硬件選擇上這個項目典型是NVIDIA Jetson系列。Orin NX 16GB是比較舒服的選擇跑YOLOv8s在640x640輸入下能到30-40 FPSINT8下還能再高一些。如果是更低端的Jetson Nano就只能跑YOLOv8n或者YOLO11n而且最好限制輸入640分辨率。現場還有幾個容易被忽略的事。鏡頭臟污是監控場景的大敵一個泥點貼在鏡頭前模型可能把泥點識別成“廢棄物”。雨水天氣的誤檢率會飆升這個我在后文細說。夜間低照度下YOLO的檢測率掉得很厲害解決辦法是接紅外補光或者用支持低照度的攝像頭單純依賴算法去扛是沒有意義的。5.5 從檢測到業務閉環告警、工單、統計怎么接模型跑通了只是第一步真正的交付是跟業務系統打通。檢測結果要轉換成業務動作一般流程是算法服務輸出事件類別、置信度、位置、截圖事件網關做去重和閾值過濾然后推送告警到工單系統由處置人員接單處理最后形成月度統計報表。置信度閾值的設置需要按場景分開。排水管道病害寧可多報漏報一條管道破裂可能導致路面塌陷所以閾值可以放低到0.25并由人工復核。廢棄物告警則相反誤報太多會讓處置人員麻木閾值建議拉高到0.5以上并且加一個時序過濾連續N幀都檢測到同一個目標才觸發生成工單。這個過濾邏輯很關鍵它能消除單幀誤檢也能避免同一堆垃圾在視頻里反復告警的情況。6. 部署現場的一個真實踩坑雨天誤檢率翻倍的教訓最后分享一個我在類似項目里親歷過的現場問題。第一次在河道監控點跑廢棄物檢測模型晴天效果不錯河流和岸邊的靜態目標區分得很清楚。結果第一場雨下來誤檢率直接翻倍雨滴、水花、落葉、波紋全被模型當成漂浮垃圾。告警平臺一晚上彈了三百多條差點讓現場運維把算法直接停用。根因有兩層第一訓練數據里幾乎沒有雨天場景模型不知道“水面在雨里長這樣”第二單幀檢測天然缺少時間維度信息雨滴和水花都是短時出現又消失跟真正的漂浮物在時間維度有明顯區別。解決措施分兩步。第一步是數據層面補采雨天、逆光、夜間低照度下的河道監控樣本重新微調模型。第二步也是更有效的一步在業務側加一個時序判定邏輯同一個位置連續N幀比如10幀以上都檢測到目標才上報雨滴水花這種瞬間出現的檢測結果會被直接丟棄。加了這兩個措施之后雨天誤報率降到了晴天水平。這類項目做得越多越有體會真正考驗團隊的往往不是YOLO訓練的理論知識而是對場景數據的理解深度和工程化的耐心。模型結構可以幾個月換一版但數據清洗、時序過濾、業務聯動這些臟活累活才是決定一個算法項目能不能落地、能不能長久跑下去的關鍵。本文還有配套的精品資源點擊獲取 基于YOLO的排水與廢棄物檢測：從數據到部署的實戰解析
簡介本資源是一套基于YOLO目標檢測算法的排水系統與廢棄物管理智能監控解決方案面向計算機視覺初學者、環境工程智能化方向開發者及智慧城市項目實踐者聚焦于管道異物識別、垃圾類型分類等真實工業場景的自動化圖像分析需求。壓縮包共240個文件含72張標注/測試用PNG圖像、27個DartFlutter移動端邏輯、15個JSXWeb前端界面、13個JSON配置與標注數據、9個XMLPascal VOC格式標簽、8個C/C源文件含Flutter插件底層實現及若干構建配置與平臺適配文件整體大小為54.64MB結構覆蓋端側部署、跨平臺集成與API服務接口設計。已有35人學習下載資源提供完整可運行的YOLO推理流程、多端移動端/Web/API集成示例、典型廢棄物與排水異常樣本圖像及配套工程目錄組織便于快速復現、二次開發與教學演示。 上個月拿到一個“基于YOLO的排水系統與廢棄物管理.zip”的工程包解壓完看完目錄說實話挺感慨的。這類項目壓縮包網上不少但大多數是把模型跑個demo就結束真正值得參考的是從數據組織、模型訓練到邊緣部署、再到業務閉環的完整鏈路。這個項目把排水管網巡檢和城市廢棄物管理兩條線塞進了同一個檢測引擎里解決的實際問題很樸素市政養護和環衛保潔靠人盯視頻太累了而且漏檢率不低。這篇就按我自己的理解和實測經驗把這個包里面應該有的東西、踩過的坑、以及這類項目落地時真正要注意的細節展開聊一聊。適合正在做智慧水務、智慧環衛算法或者想在邊緣設備上跑YOLO檢測的朋友參考。1. 解壓這個zip包它構建的是一套“排水環衛”雙場景檢測閉環1.1 排水系統巡檢的核心痛點與YOLO的切入點先聊需求背景。水務管網運維公司每天都會產生大量排水管道CCTV檢測錄像就是那個小機器人鉆進管道里拍的視頻。這些視頻靠人工逐幀去看什么樣的管道有破裂、變形、堵塞、樹根侵入全靠巡檢員的眼力。一個半小時的視頻盯下來漏檢是大概率事件。廢棄物管理那邊則是另外一撥人天天盯著河道監控、排水口監控、雨水箅子截圖數哪里有漂浮垃圾、哪里被傾倒渣土、哪里箅子堵了。這兩個場景看起來差很遠但落到算法層面本質是同一件事目標檢測——在圖像或視頻流里把特定的目標定位出來。管道里的破裂口是一個目標河道里的漂浮物也是一個目標雨水箅子上的樹葉堆積還是一個目標。所以這個zip包的核心思路就是用一套YOLO檢測引擎同時喂兩個場景的數據訓練多個檢測頭或者配置多套權重最后統一部署到邊緣盒子或服務器上。從項目解壓后的目錄結構來看組織得比較常規但很實用. ├── data/ │ ├── drainage/ # 排水管道場景數據集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ ├── waste/ # 廢棄物管理場景數據集 │ │ ├── images/ │ │ ├── labels/ │ │ └── dataset.yaml │ └── fusion/ # 兩個場景混合訓練數據 ├── models/ │ ├── yolov8n_drainage.pt │ ├── yolov8s_waste.pt │ └── yolov11n_fusion.pt ├── scripts/ │ ├── train.py │ ├── export.py │ └── detect.py ├── configs/ │ ├── train_drainage.yaml │ ├── train_waste.yaml │ └── deploy.yaml ├── docs/ └── weights/data目錄把兩個場景分得很清楚models和weights區分了不同版本的權重文件scripts是訓練、導出、推理三個階段的入口configs放超參數和部署配置。這種目錄設計對后續維護很友好尤其是當你要給不同客戶交付不同場景的模型時數據、模型、配置分離能省很多事。1.2 檢測類別體系怎么定別按“物體”分按“動作”分設計類別是最容易被忽略、但影響最大的環節。很多人拿到排水圖就先標“管道”“垃圾”“樹葉”這種按物體分類的方式在真實業務里基本沒法用。運維人員關心的是“這個位置是否需要人工處理”所以類別應該是動作導向的我按項目里的做法整理了幾類場景建議類別說明管道內檢crack破裂、deformation變形、obstruction堵塞物、root_intrusion樹根侵入病害類直接對接養護工單排水口/箅子blocked_grating箅子堵塞、garbage_accumulation垃圾堆積、illegal_dumping違規傾倒城市面源污染治理河道/泵站前池floating_garbage漂浮物、oil_slick油污、algal_bloom藻類聚集水體巡查環衛設施bin_overflow垃圾滿溢、bagged_waste袋裝垃圾、bulky_waste大件廢棄物環衛清運調度這套類別體系的邏輯是檢測結果要能直接映射到處置動作。檢測出“破裂”就派管道修復工單檢測出“箅子堵塞”就派清撈任務檢測出“垃圾滿溢”就調整清運路線。如果只輸出“垃圾”這種泛化類別后續系統集成時還得再做一層語義判斷項目交付時很難讓客戶滿意。1.3 兩條業務線共用一套檢測引擎的技術選型邏輯為什么不用兩個獨立模型分別跑而非要共用一個引擎核心原因是部署和維護成本。排水和廢棄物檢測在邊緣盒子上跑的時候如果每個場景都拉一個獨立推理服務內存、顯存、進程管理復雜度都翻倍。共用引擎的做法是同一個推理程序讀不同權重文件或者干脆用多任務模型共享backbone只在head層分叉。這個項目屬于前者——同一套YOLO推理代碼通過configs里的部署配置文件切換權重。這樣邊緣盒子上只裝一個推理服務API接口統一現場更新模型權重時不用重新編譯程序。對于甲方來說他們最怕的就是每次改需求都要重新部署整套系統這種一個服務多套權重的模式明顯更好維護。2. 數據工程排水場景里數據集質量比模型版本更重要2.1 數據來源其實很雜CCTV取幀、監控截圖、無人機航拍做排水廢棄物檢測數據來源往往有三路。第一路是CCTV管道機器人視頻這是管道病害檢測的主力數據源特點是視野窄、光照不均勻、畫面里全是管道內壁目標集中在正前方。第二路是固定點位監控包括河道監控、排水口監控、垃圾投放點監控特點是視角固定、背景變化小、但要檢測的目標在畫面里往往很小。第三路是無人機航拍主要用于河道兩側、大型垃圾堆放點的巡查特點是俯瞰視角、目標尺度變化大。不同來源的數據要分開處理不能直接混在一起訓練。我的建議是先用腳本把視頻抽幀CCTV視頻一般每秒抽1幀就夠抽多了相鄰幀高度相似對訓練沒什么幫助。監控視頻也一樣做一下去重只保留畫面有變化的幀。無人機航拍因為視角和目標尺度太特殊如果樣本量不夠最好單獨做一個數據子集而不是硬塞進主訓練集。2.2 從xml/voc到yolo格式轉換與坐標歸一化踩坑很多公開數據集和甲方給的歷史標注數據都是Pascal VOC格式xml文件需要轉成YOLO的txt格式。轉換代碼很簡單核心是坐標歸一化import xml.etree.ElementTree as ET def voc_to_yolo(xml_path, out_path, class_map): tree ET.parse(xml_path) root tree.getroot() img_w int(root.find(size/width).text) img_h int(root.find(size/height).text) lines [] for obj in root.iter(object): name obj.find(name).text if name not in class_map: continue cls_id class_map[name] box obj.find(bndbox) xmin float(box.find(xmin).text) ymin float(box.find(ymin).text) xmax float(box.find(xmax).text) ymax float(box.find(ymax).text) # 轉成YOLO格式類id、中心點x、中心點y、寬、高全部歸一化 cx (xmin xmax) / 2 / img_w cy (ymin ymax) / 2 / img_h w (xmax - xmin) / img_w h (ymax - ymin) / img_h # 防止越界 cx min(max(cx, 0.0), 1.0) cy min(max(cy, 0.0), 1.0) w min(max(w, 0.0), 1.0) h min(max(h, 0.0), 1.0) lines.append(f{cls_id} {cx:.6f} {cy:.6f} {w:.6f} {h:.6f}) with open(out_path, w) as f: f.write(\n.join(lines))這個代碼看起來很常規但有兩個坑我特別提一下。一是xml里有些框會超出圖像邊界比如xmax大于圖片寬度轉出來的w就大于1訓練時YOLO會收到不合法目標輕則訓練波動重則指標全亂。所以上面代碼里加了個clip操作把這部分異常值壓回0到1。二是class_map的順序一旦定了就別改訓練和推理要保證同一個映射表否則模型輸出的類別id對應不上部署時全亂套。2.3 小目標與切片策略遠處的漂浮物到底怎么檢排水和廢棄物場景里最典型的識別難點就是小目標。一個礦泉水瓶在1080p河道監控畫面里往往只有二三十個像素寬一個箅子堵塞點的裂縫細節在管道CCTV畫面里也只占很小一塊。直接用YOLO訓練這種小目標mAP會很難看。項目里比較有效的思路是切片。把大圖切成若干個重疊的patch每個patch單獨送進模型檢測然后把檢測框坐標映射回原圖。切片的窗口大小和重疊率要看目標尺寸來定我這邊常用的是960x960窗口、20%重疊率。超分辨率放大目標區域也是一個補救方案但推理耗時增加明顯邊緣設備上不太劃算。另一個更省事的辦法是調大訓練時的輸入分辨率把imgsz從默認的640調到960甚至1280。代價是顯存占用和訓練時間上升但對小目標的提升是實打實的。我建議先用imgsz1280跑一版對比一下mAP50-95如果提升明顯部署時也保持同樣的輸入尺寸不要訓練和部署不一致。2.4 類別不平衡和難例挖掘廢棄物樣本少怎么破廢棄物檢測有個天然問題很多類別的正樣本特別少。河道里偶爾才有油污違規傾倒更是幾個月才發生一次能拍到并標注的樣本鳳毛麟角。類別不平衡直接導致模型把少數類全部預測成背景損失函數被多數類主導。項目里的做法是針對少數類做在線硬例挖掘也就是把那些被錯誤預測為背景的樣本單獨挑出來反饋到訓練數據里。另外Ultralytics框架里也可以調loss權重在dataset.yaml的cls參數上做加權。數據增強方面Mosaic和MixUp對這些場景很有效尤其是Mosaic能把四張圖拼成一張增加小目標密度的同時讓模型看到更多上下文信息。這里還有一個工程技巧先用少數類的樣本單獨做一個預訓練模型再混合全量數據繼續訓練。這樣相當于先讓模型記住“油污長什么樣”再學“什么場景下會出現油污”實測對少數類的召回率提升很明顯。3. 模型選型與結構改進從YOLOv8到YOLO11哪些特性對排水場景真正有用3.1 anchor-free帶來的變化為什么對這類場景友好YOLOv8以后全面轉向anchor-free這個變化對排水廢棄物場景的意義很多人沒意識到。以前YOLOv5要預設一組anchor尺寸如果預設的框和你業務里目標的長寬比差太多訓練收斂就慢小目標更是吃大虧。排水管道里的裂縫細長條、河道里的漂浮物形狀各異anchor-free機制讓模型直接在特征圖上回歸中心點和寬高省掉了anchor匹配這層負擔模型自由度更大對不同形狀目標的適應能力更強。這個項目里面用的是帶anchor-free head的YOLO好處是推理代碼里少了一步anchor解碼在邊緣部署時省了一點點延遲。對工程團隊來說YOLOv8以后模型結構統一、導出ONNX更干凈也是選擇它的重要原因。3.2 YOLO11相比YOLOv8的變化哪些升級對業務有實際收益熱詞里很多人問YOLOv11和YOLOv8的區別我按這個項目的實驗結論說一下。結構上YOLOv11把C2f模塊換成了C3k2更輕量檢測頭那邊做了更細的解耦分類和回歸分支分離得更徹底。實際訓練下來在排水管道病害數據集上YOLO11的mAP50比YOLOv8s高大概1.2個百分點同時推理速度還快了約15%。這個提升幅度算不上質變但結合速度優勢已經足夠讓我把默認基線從v8換到v11。真正值得關注的是YOLO11對動態卷積和注意力機制的整合。像C3k2里融入的一些輕量注意力對河道場景里“從背景中區分漂浮物”這種任務有正向作用因為它能讓特征提取更關注紋理和顏色差異。但注意模型不是越新越好如果你部署的盒子算力有限YOLO11n可能是更穩的選擇吞吐量比s級高一截精度差距在可接受范圍內。3.3 更換主干網絡的經驗從默認backbone到更輕量的替代方案熱詞里有人提到vanillanet換主干這個思路在邊緣部署場景很值得做。YOLO默認的backbone在GPU上表現不錯但到了Jetson這類邊緣設備上算力立即變成瓶頸。換用vanillanet這類以深度卷積為主的主干可以有效減少FLOPs和參數規模。具體做法是改模型的yaml配置文件把backbone部分直接替換掉不動的部分繼續復用預訓練權重。這里有個細節替換backbone后很多層的shape會發生改變Ultralytics框架會重新初始化結構但如果你只改backbone而保留head可以在加載預訓練權重時用strictFalse參數讓能對齊的層權重保留徹底對齊不了的重新學。實測這樣比從頭訓練收斂快很多。不過主干替換有代價。換vanillanet之后同等輸入尺寸下精度大概下降0.5到1個百分點它的價值在于把推理延遲壓下來。具體怎么取舍取決于你部署設備的算力預算而不是模型本身的好壞。3.4 多任務與開放詞表檢測的擴展垃圾分類和“新垃圾種類”怎么應對廢棄物管理有一個很實際的需求——垃圾細分。同樣是垃圾可回收物、廚余垃圾、有害垃圾的處置路徑完全不同。單純的檢測框只能告訴你“這里有垃圾”不能告訴你是哪一類。方案是在檢測頭后面加一個分類分支或者用YOLO的多任務能力同時輸出檢測框和分類標簽。YOLOv8/v11本身支持多任務擴展你可以把分類任務作為一個輔助head并行訓練共享backbone特征。另外一個更新穎的方向是開放詞表目標檢測像YOLO-World這種。它能把文本編碼器和檢測器結合起來推理時輸入任意類別名稱就能檢測出對應目標不用重新訓練。這個特性在廢棄物場景里很實用——今天要查“白色泡沫箱”明天要查“廢舊輪胎”這些新類別如果走傳統重訓流程要一到兩周用開放詞表模型的話直接改prompt就行。當然它的精度比專用模型略低適合做初篩或者巡檢口徑很寬的場景。4. 訓練過程中的常見翻車點指標全0、loss異常與續訓恢復4.1 訓練指標全為0的排查鏈路從數據讀到學習率逐個排除如果你訓練時發現精確率、召回率、mAP全部是0大概率不是模型問題是訓練數據或超參配置出了問題。我遇到過太多次這種情況按下面的順序排查最有效率先看數據加載是否正常。打開訓練日志里顯示的樣本圖片確認不是全黑或全灰圖確認標注框真的畫在圖片內容上。可視化幾個標注看一下比看坐標數字可靠得多。檢查標簽文件。用腳本統計每個txt文件第一列類別id看最大值是否超出了dataset.yaml里nc-1。類別id越界是靜默錯誤訓練不報錯但模型根本學不會。檢查歸一化坐標。如果標簽里出現負數或者大于1的坐標就是轉換腳本沒做clip按我前面給的那個代碼補上就行。看學習率。如果你用了自定義的lr初始學習率設得過大比如0.1訓練第一個epoch loss就會爆炸指標當然全0。Ultralytics默認的lr00.01對大多數場景是安全的除非你換了特別小的batch size。最后做一個單圖overfit測試把訓練集縮減到一張圖跑20個epoch如果loss能降到接近0說明模型結構和數據管線是通的問題出在訓練集本身。如果單圖都學不進去那就是標簽或者預處理有硬傷。這個排查思路我建議貼在項目文檔里團隊里任何人訓練翻車都能按圖索驥。4.2 loss不收斂、mAP震蕩的常見調參手段排水廢棄物場景的樣本分布差異大訓練過程中mAP震蕩是常態。常見的手段包括增大batch size穩定梯度降低lr配合warmup讓訓練平穩啟動EMA指數滑動平均在多epoch訓練下能明顯平滑指標波動Ultralytics默認是開啟的沒必要關。還有一個容易被忽略的參數是weight_decay。在小型數據集上weight_decay設太大會讓模型欠擬合設太小又容易過擬合。我這邊在排水場景數據集上常用的配置是lr00.01、lrf0.01、weight_decay0.0005batch size根據顯存盡可能往上頂最好不低于16。如果你的顯卡只能跑到batch size4那條數據訓練會非常抖建議用accumulate參數做梯度累積等效放大batch size。數據增強也是影響收斂的重要因素。Ultralytics默認的增強策略在通用目標上表現不錯但排水管道CCTV畫面有很強的方向性比如畫面下方永遠是管道內壁底部。Mosaic增強會把四張圖旋轉拼貼可能讓模型學到錯誤的方向先驗。我在這個項目里的做法是量夠大之后關掉Mosaic只保留hsv、fliplr這類溫和增強讓模型專注于學習紋理特征。4.3 小樣本訓練的四個策略預訓練、凍結、增強、偽標簽排水和廢棄物場景經常只有幾百張標注圖這種體量直接從頭訓YOLO基本是浪費顯存。我常用的四個策略按優先級排序加載COCO預訓練權重即使你的類別跟COCO完全不重合backbone學到的低層特征邊緣、紋理、顏色塊依然有效。凍結backbone只訓練head。數據量少時凍結主干能防止低層特征被破壞。一般前10個epoch凍結之后解凍整個網絡用低學習率微調。數據增強拉滿。除了默認增強可以再加隨機旋轉、隨機透視、復制粘貼目標。復制粘貼這個技巧對廢棄物場景特別有用因為河道里的垃圾分布是稀疏的。偽標簽。用訓練好的模型在無標注監控視頻上做預測把高置信度的檢測結果當標注回填訓練集然后重新訓練。這是半監督里最簡單的一招但能顯著提升小樣本下的召回率。4.4 訓練中斷怎么暫停和續訓last.pt與best.pt的正確用法訓練過程中按CtrlC中斷或者服務器掉電這種情況在項目現場太常見了。Ultralytics框架里訓練到一定epoch會自動保存last.pt和best.pt兩個權重文件。last.pt是最近一個epoch的權重best.pt是驗證集上指標最好的那個epoch的權重。續訓的正確姿勢是from ultralytics import YOLO # resume訓練會自動從last.pt恢復 model YOLO(runs/detect/train/weights/last.pt) model.train(resumeTrue)注意resumeTrue時不用重新指定數據集和超參框架會讀取上次訓練保存的配置文件。工程上我建議定期手動把手頭的權重復制一份帶時間戳保存防止last.pt和best.pt被覆蓋后又后悔。“yolo怎么暫停”這個熱詞大家經常搜實際上就是上面這樣中斷后resume即可。但有一點如果你用LibTorch或OpenCV DNN做部署時的模型文件是onnx訓練中斷不影響已經導出的onnx不需要重新訓練。4.5 在vscode里本地調模型的工作流建議用VSCode在本地調試YOLO訓練我自己的慣例是先用小數據集、小模型yolov8n.pt跑通整個流程確認數據管線和訓練參數沒有硬傷再切換成正式數據集和大模型。這個習慣能幫你把“訓練環境配置錯誤”和“模型質量問題”這兩類問題分開。調試時建議用Ultralytics的GUI的weightbiases集成或comet或者干脆用tensorboard觀察train/loss和val/mAP的實時曲線。如果vscode的Python調試器直接掛著訓練進程調試性能會慢很多我一般只調試推理腳本和數據預處理腳本訓練腳本直接跑命令行。5. 部署與實測邊緣盒子、C推理和“用OpenCV量物體大小”5.1 從pt導出ONNX/TensorRT格式選擇和量化細節模型訓練完之后要部署第一步是把torch權重導出成推理引擎能跑的格式。Ultralytics框架一行命令就能導出yolo export modelweights/best.pt formatonnx imgsz640 halfTrueonnx是比較通用的中間格式CPU上可以用OpenCV DNN或者ONNX Runtime跑GPU上可以進一步用TensorRT構建engine。TensorRT的engine格式是NVIDIA平臺專屬的但推理速度最快。導出時要注意選擇halfTrue開啟FP16這能讓顯存占用減半、吞吐量接近翻倍。如果顯存更緊張還可以考慮INT8量化但INT8需要標定數據集而且這個項目里排水管道病害這類細節紋理在INT8下精度損失明顯實測不建議。導出之后一定在部署環境上用相同輸入尺寸實測一遍因為訓練時的數據增強和預處理letterbox要在推理側復現否則圖像被拉伸變形檢測框位置就全偏了。5.2 C環境部署要點OpenCV DNN和ONNX Runtime的實際取舍很多現場設備是Linux工控機沒法裝Python環境C部署就成了必須項。C側加載YOLO模型有兩個主流選擇OpenCV DNN模塊和ONNX Runtime C API。OpenCV DNN適合快速上線不用引入額外依賴但它的NMS實現和TRT比還是有點差距batch推理支持也弱一些。ONNX Runtime則是更正規的選擇支持CUDA EP能精確控制輸入輸出張量。我這邊更推薦ONNX Runtime代碼結構大概是這樣Ort::Env env(ORT_LOGGING_LEVEL_WARNING, yolo); Ort::SessionOptions opts; opts.SetGraphOptimizationLevel(GraphOptimizationLevel::ORT_ENABLE_ALL); Ort::Session session(env, model.onnx, opts); // 輸入預處理letterbox BGR2RGB normalize cv::Mat letterbox_img letterbox(frame, input_shape); cv::cvtColor(letterbox_img, blob, cv::COLOR_BGR2RGB); blob.convertTo(blob, CV_32F, 1.0 / 255.0); // 推理 std::vectorfloat input_tensor_values(blob.beginfloat(), blob.endfloat()); // 構造Ort::Value并Run // 后處理解碼bbox NMS 坐標映射回原圖推理出來的結果是歸一化的中心點、寬高要映射回原圖坐標時記得把letterbox的填充偏移減掉再除以縮放系數。這一步寫錯會導致檢測框整體偏移現場排查非常費勁。5.3 用OpenCV測量檢測物體的實際大小很多業務場景不只要知道“這里有垃圾”還想知道“這個垃圾有多大”。比如河道監管要求超過一定面積的漂浮物才算事件。我們可以用OpenCV結合相機標定來做測量。最簡單實用的方法是用已知尺寸的參考物做像素標定。比如一個標準雨水箅子直徑是800毫米在畫面里某個位置測出對應像素寬度是100像素那像素尺寸轉換系數就是8毫米/像素。檢測時把模型輸出的框寬高乘以這個系數就得到近似物理尺寸。注意這個系數只在該參考物所在平面附近有效離得太遠誤差會增大。更正規的做法是用相機標定calibrate camera獲取內外參然后通過地面平面的單應性矩陣把像素坐標轉換成世界坐標。但這個對現場實施的要求比較高需要知道相機的安裝高度和俯仰角。如果甲方對測量的準確性有硬性要求這個環節就得專門做而不是靠估計。論工程項目我個人的建議是先按參考物法快速上線等有投訴或者精度不達標時再上完整標定方案這樣能控制初期交付成本。5.4 邊緣設備選型與性能預算部署硬件選擇上這個項目典型是NVIDIA Jetson系列。Orin NX 16GB是比較舒服的選擇跑YOLOv8s在640x640輸入下能到30-40 FPSINT8下還能再高一些。如果是更低端的Jetson Nano就只能跑YOLOv8n或者YOLO11n而且最好限制輸入640分辨率。現場還有幾個容易被忽略的事。鏡頭臟污是監控場景的大敵一個泥點貼在鏡頭前模型可能把泥點識別成“廢棄物”。雨水天氣的誤檢率會飆升這個我在后文細說。夜間低照度下YOLO的檢測率掉得很厲害解決辦法是接紅外補光或者用支持低照度的攝像頭單純依賴算法去扛是沒有意義的。5.5 從檢測到業務閉環告警、工單、統計怎么接模型跑通了只是第一步真正的交付是跟業務系統打通。檢測結果要轉換成業務動作一般流程是算法服務輸出事件類別、置信度、位置、截圖事件網關做去重和閾值過濾然后推送告警到工單系統由處置人員接單處理最后形成月度統計報表。置信度閾值的設置需要按場景分開。排水管道病害寧可多報漏報一條管道破裂可能導致路面塌陷所以閾值可以放低到0.25并由人工復核。廢棄物告警則相反誤報太多會讓處置人員麻木閾值建議拉高到0.5以上并且加一個時序過濾連續N幀都檢測到同一個目標才觸發生成工單。這個過濾邏輯很關鍵它能消除單幀誤檢也能避免同一堆垃圾在視頻里反復告警的情況。6. 部署現場的一個真實踩坑雨天誤檢率翻倍的教訓最后分享一個我在類似項目里親歷過的現場問題。第一次在河道監控點跑廢棄物檢測模型晴天效果不錯河流和岸邊的靜態目標區分得很清楚。結果第一場雨下來誤檢率直接翻倍雨滴、水花、落葉、波紋全被模型當成漂浮垃圾。告警平臺一晚上彈了三百多條差點讓現場運維把算法直接停用。根因有兩層第一訓練數據里幾乎沒有雨天場景模型不知道“水面在雨里長這樣”第二單幀檢測天然缺少時間維度信息雨滴和水花都是短時出現又消失跟真正的漂浮物在時間維度有明顯區別。解決措施分兩步。第一步是數據層面補采雨天、逆光、夜間低照度下的河道監控樣本重新微調模型。第二步也是更有效的一步在業務側加一個時序判定邏輯同一個位置連續N幀比如10幀以上都檢測到目標才上報雨滴水花這種瞬間出現的檢測結果會被直接丟棄。加了這兩個措施之后雨天誤報率降到了晴天水平。這類項目做得越多越有體會真正考驗團隊的往往不是YOLO訓練的理論知識而是對場景數據的理解深度和工程化的耐心。模型結構可以幾個月換一版但數據清洗、時序過濾、業務聯動這些臟活累活才是決定一個算法項目能不能落地、能不能長久跑下去的關鍵。本文還有配套的精品資源點擊獲取