做火災檢測系統(tǒng)之前我習慣先問自己一個問題這個場景里傳統(tǒng)傳感器到底哪里不夠用只有把這個問題想明白了后面方案選型和架構設計才不會跑偏?；趫D像識別的火災檢測本質上就是用攝像頭當眼睛、用算法當大腦從視頻幀里實時發(fā)現(xiàn)早期火焰和煙霧再觸發(fā)報警聯(lián)動。它解決的核心痛點很直接傳統(tǒng)點式傳感器只能感知探頭附近的變化而圖像方案能覆蓋整個可視區(qū)域還能在報警的同時留下可回看的現(xiàn)場證據(jù)誤報也可以通過算法做嚴格校驗。適合看這篇文章的朋友是正準備動手做此類系統(tǒng)設計的人不管是學校里的課題還是廠區(qū)監(jiān)控升級都可以參考這套完整思路。1. 需求拆解與整體架構設計1.1 圖像識別方案對比傳統(tǒng)傳感器強在哪先說一個真實對比。傳統(tǒng)感煙探測器在很多場景里表現(xiàn)并不差但它本質上是“點感知”只有煙霧擴散到探頭附近才會觸發(fā)。在大空間倉庫、開闊廣場、隧道、戶外停車場這些場景里煙霧到達探頭需要很長時間等觸發(fā)報警時火可能已經(jīng)燒大了。而攝像頭是面感知只要火焰或煙霧進入畫面算法就能在幾百毫秒內發(fā)現(xiàn)目標在時間上快得多。除了響應速度圖像方案還有一個隱藏優(yōu)勢證據(jù)鏈完整。傳統(tǒng)傳感器報警只給出一個開關量信號現(xiàn)場燒成什么樣完全不知道。圖像方案在報警同時會把現(xiàn)場截圖和前后時段的視頻自動保存下來事后調出來看起火點在哪、蔓延過程如何一目了然。成本上圖像方案也不是劣勢。一個高清攝像頭可以監(jiān)控數(shù)百平方米范圍對比為了覆蓋同樣面積需要布設大量點式傳感器硬件數(shù)量和維護成本反而更低。當然這不意味著圖像方案要完全替代傳統(tǒng)傳感器兩種手段互補才是合理的比如廚房這類油煙大的封閉空間感溫探頭仍然很可靠。1.2 四層架構是怎么搭起來的整個系統(tǒng)我在設計時拆成了四層視頻采集層、算法分析層、告警聯(lián)動層、存儲展示層。每層職責單一后續(xù)維護和迭代會輕松很多。視頻采集層負責把攝像頭畫面拉進來這里要考慮的不只是分辨率還有接入?yún)f(xié)議。市面上主流攝像頭基本都支持RTSP或者GB28181直接取流解碼就行。幀率一般設置在10到15FPS就夠用了火災檢測不需要高幀率太高反而浪費算力。算法分析層是整個系統(tǒng)的心臟。視頻幀進來之后先做預處理再送入火焰和煙霧檢測模型模型輸出的是目標框和置信度。這里有個非常關鍵的設計思路不能因為某一幀檢出了火焰就直接報警。我后來踩過這個坑單幀誤檢率高得嚇人日光反射、紅色燈光、汽車尾燈都可能騙過模型。正確做法是加一個時序確認模塊連續(xù)N幀都檢出目標才進入下一步確認一般N取3到5按10FPS計算確認延遲也就0.3到0.5秒幾乎感覺不到。告警聯(lián)動層負責把確認后的結果轉成具體動作。聲光報警器要響監(jiān)控平臺要彈窗短信或者電話要推送給值班人員同時把告警前30秒到后30秒的視頻片段截取保存。存儲展示層則負責歷史錄像、告警記錄和現(xiàn)場截圖的統(tǒng)一管理方便事后檢索回看。1.3 算法放邊緣還是放云端部署位置權衡算法模型的運行位置直接影響整個系統(tǒng)的實時性和成本。我當時評估了三種方案各有適用場景。純服務器集中推理適合路數(shù)少、機房條件好的場景算法迭代方便模型更新直接換文件就行但視頻都要回傳對網(wǎng)絡帶寬要求高。邊緣算力盒子則把模型跑在攝像頭旁邊的專用處理器上只把告警信息和截圖回傳到平臺帶寬占用小斷網(wǎng)也能獨立工作缺點是硬件算力有限模型必須做輕量化。第三種是端邊云協(xié)同攝像頭端做初步過濾邊緣盒子做精細檢測云端負責匯總和迭代彈性最大但工程量也最大。我自己的建議是如果項目階段是驗證算法效果先用服務器集中推理省事如果準備實際落地直接上邊緣盒子越早接觸真實部署環(huán)境后面少踩坑。實際項目里我見過不少因為一開始只顧算法精度、不考慮部署形態(tài)結果現(xiàn)場帶寬拉不動、延遲又高整個系統(tǒng)白做的案例。2. 核心檢測算法原理與選型分析2.1 傳統(tǒng)視覺方案怎么建立火焰模型很多老系統(tǒng)到現(xiàn)在還在用傳統(tǒng)圖像處理方案做火焰檢測因為它對算力幾乎沒要求一個低端嵌入式芯片就能跑。它的核心思路是抓火焰的三個維度特征。顏色特征是最直觀的?；鹧嬖贖SV顏色空間里有相對集中的分布我之前常用的初篩范圍是色相H在0到60度之間飽和度S大于50亮度V大于120。選HSV而不是RGB是因為HSV把亮度和顏色分開能扛住一定程度的曝光變化。但這個閾值只能做粗篩純粹靠它判斷畫面上所有紅色東西都會變成候選目標。運動特征針對的是火焰“閃爍”這個獨一無二的現(xiàn)象。真實火焰的亮度在相鄰幀之間會明顯波動波動主頻集中在1到3赫茲。用幀間差分或者背景建模把前景目標提取出來再統(tǒng)計候選區(qū)域亮度變化的頻率如果這個頻率落在特征范圍內就認為它具備火焰的動態(tài)屬性。這個特征非常有用能過濾掉絕大多數(shù)靜態(tài)紅色物體。形態(tài)特征用來輔助判斷。真實火焰的邊緣是不規(guī)則、不穩(wěn)定的如果用圓形度去度量火焰的圓形度偏低而燈泡、車燈這類光源圓形度很高一算就分開了。組合這三個維度做加權投票就能搭起一個能用的火焰判斷器。順便說一句傳統(tǒng)方案在煙霧檢測上更吃力因為煙霧邊緣模糊、顏色又不穩(wěn)定單純靠規(guī)則很難把飄動的白煙和霧氣區(qū)分開。2.2 深度學習方案選擇目標檢測還是圖像分割傳統(tǒng)視覺方案的最大瓶頸是泛化能力弱換個場景就要重新調閾值。后來做這個項目我果斷切換到深度學習路線。但到底用目標檢測還是圖像分割需要根據(jù)檢測對象來定?；鹧婺繕诉吔缦鄬η逦蟛糠謭鼍跋掠脝坞A段目標檢測模型就夠了。我實際測試下來單階段模型在速度和精度之間最平衡輸入分辨率640乘以640時單幀推理的延遲可以控制在百毫秒級別完全滿足實時監(jiān)控要求。煙霧和火焰不一樣它是半透明的邊界彌散用目標框描述會框進大量背景區(qū)域導致大量誤判和漏判。這種情況下用語義分割效果更好直接逐像素判斷哪些區(qū)域屬于煙霧再按面積比例評分。那模型選多大的合適我的經(jīng)驗是不要一上來就用最大的模型先跑通再優(yōu)化。骨架版本適中即可在公開火焰檢測場景里精度已經(jīng)接近滿配水平但參數(shù)數(shù)量只有三分之一不到。后續(xù)如果想要更小的部署體積可以做通道剪枝和量化INT8量化之后模型體積能壓縮到原來的四分之一推理速度也能再翻一倍精度損失在可以接受的范圍內。下面把傳統(tǒng)方案和深度學習方案的取舍放在一起對比對比維度傳統(tǒng)視覺方案深度學習方案混合方案檢測準確性場景固定時可用復雜環(huán)境誤報多高泛化能力強以深度學習為主傳統(tǒng)規(guī)則作兜底算力需求極低嵌入式芯片即可需要GPU或NPU可量化壓縮中等開發(fā)工作量調參周期長場景遷移需重調需要標注數(shù)據(jù)集訓練迭代開發(fā)量大但系統(tǒng)最健壯真實火情識別率漏報偏高召回率高漏報最低誤報控制能力依賴規(guī)則設計依賴數(shù)據(jù)質量兩者結合最優(yōu)2.3 抑制誤報與保住漏報率的博弈策略做檢測系統(tǒng)的朋友都知道誤報和漏報是一對難兄難弟閾值調低了誤報多調高了漏報多。我在這套系統(tǒng)里的處理原則是置信度閾值寧可定得低一些把單幀誤檢放進來但靠時序確認機制和規(guī)則引擎去過濾絕不能為了保證低誤報而把閾值拉得很高導致真火漏掉。為什么敢這么做因為誤報可以通過連續(xù)幀確認來消除誤檢通常是偶發(fā)的不可能連續(xù)三五幀都在同一個位置穩(wěn)定出現(xiàn)。但真實火焰一旦出現(xiàn)就會持續(xù)存在并且形態(tài)和位置都有連貫性。時序確認機制天然不會放過它。我做過一次對比實驗只看單幀時誤報率有百分之幾體驗非常差加上連續(xù)5幀確認之后誤報率能下降一個數(shù)量級而真實火情的檢測延遲只增加了0.4秒。這套策略的代價是系統(tǒng)確認告警的實時性會稍微下降。但火災檢測本來就不要求毫秒級響應0.5秒內的確認延遲完全在可接受范圍內。在規(guī)則引擎里還可以再加上最小面積限制和最大面積限制。比如目標框占畫面總像素比例低于萬分之五時直接忽略這能過濾掉遠距離的微小反光點。目標框面積在一兩秒內不增大的也直接忽略因為真實火焰蔓延時面積一定會增長。3. 數(shù)據(jù)集構建與模型訓練全流程3.1 數(shù)據(jù)采集、負樣本策略與標注規(guī)范深度學習檢測模型的性能很大程度取決于數(shù)據(jù)集質量。目前公開的火焰檢測數(shù)據(jù)集規(guī)模都不大并且場景單一絕大多數(shù)是室內火盆或者戶外的篝火直接拿去訓練在真實監(jiān)控場景下泛化會出問題。我自己做數(shù)據(jù)時走的是“公開數(shù)據(jù)加自采數(shù)據(jù)”結合的路子。自采數(shù)據(jù)要覆蓋常見起火場景紙張燃燒、布料引燃、油鍋起火、木柴燃燒、垃圾桶起火這些都可以在可控環(huán)境下拍攝。每段視頻建議錄夠兩三分鐘并且要有從點燃到蔓延再到穩(wěn)定的完整過程這樣模型才能學到火焰早期和穩(wěn)定期的不同形態(tài)。負樣本同樣重要甚至可以說更重要。所謂負樣本就是完全沒有火焰的正常監(jiān)控畫面但里面包含了大量顏色容易混淆的目標早晚時段的陽光、紅色車身、工地焊光、紅色警示燈、晚霞映照的玻璃幕墻這些都得多拍。很多模型誤報率高根本原因就是負樣本太少。標注規(guī)范要提前定清楚?；鹧孢吘壞：煌瑯俗T給出的框差距會很大。我定下的規(guī)則是火焰矩形框要完整包含火苗核心區(qū)域亮度過曝的最亮中心如果是火焰的一部分也應包含在框內但外圍透明蔓延的余暉不算。煙霧如果做分割標注時只標密度較高、輪廓可見的核心煙團淡薄邊界不標盡量保證標注一致性能提升最終模型的mAP。3.2 訓練參數(shù)配置與模型評估指標訓練配置我直接用一個完整的YOLO訓練命令來解釋思路是數(shù)據(jù)即代碼訓練入口干凈利落。python train.py --data fire.yaml --weights yolov8s.pt --img 640 --batch 16 --epochs 100 --hyp hyp.scratch-low.yaml參數(shù)里最需要花心思的是輸入分辨率和批量大小。640乘以640是一個很甜點的尺寸再往上提精度提升有限但推理耗時明顯增加往下降小火焰目標容易丟失。批量大小主要看顯卡顯存16對中等顯存很友好。訓練輪數(shù)不需要盲目堆100輪左右加早停機制足夠收斂再多就會過擬合把訓練數(shù)據(jù)里的背景紋理背下來了。評估指標不能只看mAP。mAP0.5在模型調參時很有用一般我的驗收線是0.9以上但業(yè)務上更要看三個指標召回率、誤報率、告警延遲。召回率決定了真實火災有多少能被發(fā)現(xiàn)這個是系統(tǒng)存在的意義必須放在第一位。誤報率決定系統(tǒng)能不能長期穩(wěn)定運行可以用每天每路視頻的誤報次數(shù)來衡量我實測做到零到一次就不錯。告警延遲則包含了模型推理時間、時序確認時間和消息推送時間端到端控制在3秒以內完全可以接受。訓練時我還用了一組固定的數(shù)據(jù)增強策略隨機翻轉、隨機旋轉、色彩擾動、以及模擬運動模糊。其中色彩擾動很重要因為不同攝像頭白平衡和曝光差異很大增強色彩魯棒性可以在換攝像頭時少踩坑。3.3 跨場景泛化與模型迭代節(jié)奏一個模型在一個場景效果好不代表換個地方也能用。我訓練好的模型在廠區(qū)室內場景表現(xiàn)很好拿到戶外廣場測試時第一周就出現(xiàn)了好幾次誤報后來一查全是傍晚低角度陽光造成的暖色反光。這是我的切身體會。模型迭代節(jié)奏不能亂。我的做法是系統(tǒng)上線后持續(xù)收集實際場景中產(chǎn)生的誤報警情截圖和間隔抽幀保存的疑似目標視頻每周導出一次篩選出值得練的新樣本清洗后增量訓練一輪。增量訓練時要注意防止災難性遺忘我會在訓練集里保留過去已有的主體數(shù)據(jù)再按比例加入新樣本而不是只訓新樣本。每次更新模型之前還要先跑一遍回歸測試?；貧w測試集是整理好的一批歷史視頻片段里面既包含確認過的真火案例也包含過去最容易被誤報的干擾案例模型如果在新版本里反而把老樣本判錯了說明訓練出問題要重新評估。這套流程看著繁瑣但恰恰是它能保證系統(tǒng)在真實環(huán)境里越用越穩(wěn)。4. 攝像頭部署、硬件選型與告警聯(lián)動4.1 攝像頭部署位置和硬件選型經(jīng)驗攝像頭裝在哪其實比算法還重要。位置選不好算法再強也白搭。我總結出幾條實戰(zhàn)經(jīng)驗。第一攝像頭盡量高位俯視這樣可以減少人和貨物對火焰區(qū)域的遮擋。第二絕對避免強光源直射鏡頭逆光畫面里火焰特征會被嚴重壓縮模型很難檢出目標。第三大空間場景下畫面中的火焰可能只有幾個像素大小這時候可以考慮在重點區(qū)域加裝近景機位作為輔助兩個視角互相印證還能降低漏報。夜間場景要單獨考慮。普通紅外補光攝像頭在暗光下輸出的是灰度圖像火焰亮度雖然高但顏色信息丟失了這時如果模型只見過彩色火焰效果會明顯下降。兩種辦法一是單獨訓練灰度圖像版本的檢測模型二是在攝像頭旁加可見光補光保持彩色成像。此外有條件的場景可以增配一個低分辨率熱成像攝像頭用溫度閾值先做一次預篩再把候選區(qū)域轉到可見光模型二次確認這套雙光方案是我自己覺得可靠性最高的組合。硬件選型的量級可以參考下面這張表具體型號可以按項目預算和路數(shù)來定部署方案適合場景算力參考可支撐路數(shù)普通CPU服務器算法開發(fā)調試、少量路數(shù)純CPU處理推理慢2到4路GPU服務器集中推理、算法迭代頻繁中高端顯卡即可8到16路邊緣算力盒子現(xiàn)場部署、斷網(wǎng)工作NPU或輕量級GPU4到8路端邊云協(xié)同大型園區(qū)、多級管理邊緣端加云端算力池幾十路以上4.2 告警規(guī)則引擎設計與聯(lián)動實現(xiàn)告警不能直接拿模型輸出裸奔中間要有一個規(guī)則引擎。我設計規(guī)則時用了三個條件疊加置信度大于閾值連續(xù)幀數(shù)達到閾值關鍵區(qū)域持續(xù)存在時間超過閾值。只有三者都滿足才判定為一次有效告警。規(guī)則引擎還有一個好處可以按區(qū)域配置不同的觸發(fā)靈敏度。比如在加油站這種高風險場所閾值可以調低一些在工廠車間因為常有焊接火光為了讓正常作業(yè)不被頻繁打斷閾值就要適當調高避免正常生產(chǎn)流程被誤報干擾。確認告警之后聯(lián)動動作按優(yōu)先級執(zhí)行本地聲光報警器是最快的響應在毫秒級然后是監(jiān)控平臺彈窗并播放提示音方便值班人員第一時間看到第三步是推送短信或者電話通知這一步通常走第三方接口要把告警的截圖地址、攝像頭位置、時間都放在消息內容里。錄像保存安排在最后但必須在告警確認的瞬間就觸發(fā)把告警前30秒到后30秒的畫面都截取下來。告警記錄結構上我會把關鍵信息都存成結構化數(shù)據(jù)供后續(xù)查詢和統(tǒng)計。大致字段如下{ alarm_id: 20250607153012_001, channel_id: CAM-01, timestamp: 2025-06-07 15:30:12, confidence: 0.87, bbox: [120, 80, 360, 300], image_url: /alarm/20250607/001.jpg, video_url: /alarm/20250607/001.mp4, rule_level: 1 }字段含義很直觀告警ID保證冪等不重復推送置信度和目標框可以讓值班人員快速判斷是否誤報截圖和視頻留底規(guī)則等級用于決定是否走最高優(yōu)先級推送。這套結構在后續(xù)對接客戶平臺時也很省事直接給JSON文檔對方就能對接。5. 典型故障與性能優(yōu)化實戰(zhàn)5.1 誤報漏報問題速查表做系統(tǒng)最費時間的就是現(xiàn)場調試階段。我把項目里遇到最多的問題整理成一張速查表基本覆蓋了大部分同類項目會碰到的坑?，F(xiàn)象常見原因解決辦法日光反射到玻璃幕墻或水面被識別為火暖色高光的顏色特征與火焰接近疊加閃爍特征要求亮度在連續(xù)幀間有波動限制最大目標面積紅色車燈、紅色工裝、紅色燈光誤報顏色空間與火焰交叉大量補充負樣本訓練規(guī)則中增加形態(tài)特征校驗夜間紅外畫面下火焰漏報灰度圖丟失顏色信息單獨訓練灰度版本模型增加可見光補光遠距離小目標火焰漏報目標像素太少特征不明顯提高輸入分辨率增加小目標檢測頭或注意力機制畫面抖動導致候選中不斷變化誤報幀差和背景模型被抖動干擾開啟電子防抖降低背景建模更新率煙霧報警延遲高煙霧擴散初期很淡目標得分低針對早期煙霧單獨訓練分割模型降低濃度閾值這些問題的共性在于不要期望一個模型解決所有問題規(guī)則引擎、數(shù)據(jù)增強、硬件選型配合起來才能把現(xiàn)場表現(xiàn)拉到可用水平。5.2 推理性能與系統(tǒng)穩(wěn)定性優(yōu)化模型推理速度是優(yōu)化重點。我在實際優(yōu)化中使用了幾種有效手段。一個是跳幀策略火焰和煙霧變化頻率并不高沒有必要每一幀都跑模型我實際測試里每三幀抽一幀推理CPU負載下降了接近一半告警延遲增加不到一百毫秒這個投入產(chǎn)出比很劃算。另一個手段是批量推理如果有多路視頻同時接入可以把多路的畫面拼成一批數(shù)據(jù)送進模型整體吞吐量會明顯提升這比單獨逐路推理要高效得多。模型本身也可以繼續(xù)瘦身。我用大模型當老師訓練小模型充當學生通過蒸餾的方式把精度盡量帶過去。配合INT8量化小模型在邊緣盒子上的性能從約每秒七八幀提升到每秒十幾幀效果很可觀。這里有個提醒量化后必須在真實視頻上復測召回率有些模型的權重分布對INT8敏感火苗這種小目標精度會明顯掉點如果發(fā)現(xiàn)掉點超過百分之二就要考慮局部層保持浮點精度。穩(wěn)定性方面算法進程一定要有守護機制。我碰到過一次邊緣盒子上的推理進程因為視頻流斷流導致內存吃滿最后整個系統(tǒng)卡死值班室大屏上畫面全黑。后來加了看門狗進程異常退出會自動拉起同時增加視頻流斷線重連和內存告警的監(jiān)控。模型文件加載失敗時還要有降級預案我默認回退到傳統(tǒng)視覺規(guī)則方案雖然效果差一些但至少保證系統(tǒng)不中斷。穩(wěn)定性和算法精度有時候同等重要一個經(jīng)常掉線的系統(tǒng)即使模型再準也沒有實際價值。最后再分享一個感觸比較深的經(jīng)驗。我最初也迷信大模型和高精度后來項目落地多了才發(fā)現(xiàn)系統(tǒng)的可靠性來自整個鏈路而不只是模型本身。數(shù)據(jù)質量、規(guī)則設計、部署形態(tài)、運維預案每一環(huán)都不能掉鏈子。如果你打算把這個項目從實驗推向真實環(huán)境我強烈建議先跑通一個最小閉環(huán)一路攝像頭、一臺推理設備、一個告警通知連續(xù)觀察一周的現(xiàn)場日志把誤報和漏報的樣本收集起來迭代一輪再決定要不要擴展多路和復雜聯(lián)動。這個過程雖然不性感但項目能不能真正交付就看這一步做得到不到位。