“InspekTron”這個名字一聽就有點味道Inspect 加 Tron既有“檢測”的本意又帶著點“硬核工具”的氣質。我當時拿到這個項目需求時第一反應是這不是又一個換皮的 OCR 識別工具就是那種套著殼子做圖像分類的玩具。但真正把需求捋清楚之后發(fā)現它是要把工業(yè)場景里“人眼盯著屏幕看缺陷”這件事用一套完整的視覺方案替代掉。這篇博文就當是一個項目復盤從最初的技術選型到數據標注的坑再到模型訓練和灰度上線的完整過程。如果你也正在做類似的質檢項目或者打算用視覺方案解決生產線上的檢測問題這篇文章應該能給你不少參考。1. 項目整體設計與技術選型1.1 這個項目到底要解決什么問題InspekTron 核心解決的是工業(yè)產線上的外觀缺陷檢測問題。之前客戶的產線上每一件產品經過特定工位時都需要一位質檢員盯著看判斷表面有沒有劃痕、臟污、凹陷、毛刺。這種崗位的問題很明顯人眼會疲勞標準不統一而且培養(yǎng)一個合格的質檢員周期不短人員流動還特別大。InspekTron 的定位就是把這個環(huán)節(jié)自動化。通過固定相機拍照、算法識別、結果輸出三個步驟替代人工目檢。而且它不是簡單地做“好”和“壞”的二分類而是要能做到缺陷分類告訴產線這個產品是劃傷、臟污還是其他問題方便后續(xù)追溯是哪一道工序出了問題。這個定位本身就決定了技術路線。它不是通用目標檢測項目不能用網上隨便下的模型就往上套。產線上的缺陷種類、形態(tài)、大小、出現位置都有極強的行業(yè)屬性必須從數據采集開始就圍繞具體產品來設計。1.2 硬件方案與軟件架構的取舍硬件上我們最終選定了工業(yè)面陣相機 同軸光源的組合。這個選擇不是拍腦袋是踩過坑之后定下來的。最開始用的環(huán)形光源裝上去一拍發(fā)現反光嚴重特別是金屬表面的輕微劃痕在環(huán)形光下完全沒有對比度。后來換了同軸光源光線垂直照射再垂直反射表面缺陷才會因為散射和反射差異形成明顯的灰度差。如果你做的產品是玻璃、金屬、拋光塑料這類高反光材質光源選型這一步一定要重視光源不對后面算法再強也白搭。相機分辨率的計算也提一下經驗公式。假設我們要檢測的最小缺陷是 0.1 mm希望在圖像上至少占 3 個像素那么視野寬度如果是 50 mm需要的橫向分辨率就是 50 / 0.1 * 3 1500 像素?？紤]到邊緣畸變和冗余實際選型至少要有 200 萬像素。如果視野更大或者要檢測更小的缺陷分辨率要求還會更高。軟件架構上我堅持把程序拆成三個獨立模塊。采集模塊負責相機觸發(fā)和圖像獲取推理模塊負責加載模型并執(zhí)行預測結果模塊負責把預測結果寫入數據庫并觸發(fā)產線動作。模塊之間用消息隊列通信這樣任何一個模塊升級替換都不影響另外兩個。這種解耦思路在工業(yè)現場特別重要因為產線停機成本很高誰也不想因為改一個檢測邏輯就要整條線停下來重新部署。1.3 為什么選擇 YOLOv8 作為基礎模型模型選型這部分我們對比過幾種方案。傳統圖像處理OpenCV 閾值分割、邊緣檢測跑了幾個典型缺陷樣本直接被 pass 了。原因是缺陷形態(tài)多變光照稍有波動傳統算法的參數就得重調現場根本維護不過來。后來綜合考慮訓練成本、推理速度和部署便利性我選了 YOLOv8。理由有三點。第一它本身是 one-stage 檢測器推理速度快在工業(yè)場景里如果一秒鐘要檢測幾十件產品速度就是硬指標。第二Ultralytics 這個開源項目維護得非?；钴S文檔完善遇到問題能搜到的資料也多項目交付之后人家自己也好維護。第三YOLOv8 在小目標檢測上的表現比之前的版本改進不少而劃痕、臟污這類缺陷往往就是小目標。也考慮過 YOLOv8 的實例分割版本能精確到像素級別。但后來評估下來產線上只要知道缺陷的位置和類別不需要精確的輪廓檢測框就夠用了。實例分割訓練成本更高推理時間也不占優(yōu)勢投入產出比不高。技術選型關鍵是夠用就好過度設計只會給自己挖坑。2. 數據采集與標注的實戰(zhàn)經驗2.1 數據集不用“多多益善”而要“壞得均勻”這個項目里數據環(huán)節(jié)踩的坑最多也最值得拿出來說。很多初學者上來就堆圖片集覺得樣本越多越好。但實際上對工業(yè)質檢來說壞樣本的質量和覆蓋度遠重要于數量。一個常見的問題是缺陷樣本極度不平衡。產線上良品率可能高達 95% 以上按正常生產節(jié)奏采集數據十有八九都是好樣本壞樣本零零散散。如果直接拿來訓練模型會瘋狂偏向“無缺陷”這一類哪怕真的出現缺陷它也會大概率漏檢。解決辦法是主動制造“壞樣本多樣性”。我們那時候和產線老師傅聊了很久把過去一年里出現過的缺陷種類整理成清單然后改進了一批相同缺陷類型的壞品專門用來拍照。如果現場湊不齊某個罕見缺陷的樣本還會手工模擬比如用砂紙打磨表面模擬劃傷用油污涂抹模擬臟污。這種做法在行業(yè)里比較常見但要注意手工模擬出來的缺陷和自然形成的缺陷之間紋理和形態(tài)上還是有差異所以模擬樣本只能做補充主力還是得靠真實不良品。還有一點是關于背景干擾的。工業(yè)現場不會像實驗室那么干凈產品表面可能有水漬、指紋、灰塵這些不是缺陷但會干擾模型判斷。訓練數據里要專門放入一定比例的“干擾背景”圖片告訴模型這些不算缺陷。不然模型很容易把即將出廠的良品誤判成不良品產線上的復判工作量會大得驚人。2.2 標注格式、小目標問題和數據增強策略標注格式上因為我們選的是 YOLOv8數據格式自然就是 txt 格式的歸一化坐標每個缺陷框一行包含類別序號、中心點 x、中心點 y、框寬 w、框高 h。需要注意的是標注工作一定要用專業(yè)的標注工具比如 LabelImg 或 X-AnyLabeling不要自己寫個腳本在圖片上畫框效率太低而且容易出錯。小目標缺陷的標注要格外小心。劃痕通常有長寬比極大的形態(tài)特征可能整張圖中只占幾十個像素這時候標注框要盡可能貼合缺陷的邊界不要為了省事畫一個很大的框把周圍正常區(qū)域也圈進去這樣會把大量背景信息混進正樣本里嚴重影響模型的定位精度。數據增強這塊我用了 Mosaic、隨機旋轉、亮度擾動、噪聲擾動這幾種組合。亮度擾動對這個項目特別關鍵因為現場光照雖然有遮光罩但還是會有緩慢漂移訓練時把亮度變化范圍加大模型對光照波動的魯棒性會好很多。另外我還加了 Cutout 增強隨機遮擋一部分圖像區(qū)域強迫模型學會用局部特征判斷缺陷。剛開始可能會覺得遮擋會讓模型變笨實際測試效果反而讓泛化能力更好了有點意外但也算正常這本質上是正則化的一種手段。3. 模型訓練與推理部署的關鍵環(huán)節(jié)3.1 訓練超參數配置與 Loss 變化曲線解讀訓練部分我直接基于 Ultralytics 的官方接口來做。數據集結構按它的標準放好images/train、images/val、labels/train、labels/val四個目錄對應放好就行。數據集材料準備好之后寫一個 YAML 配置文件指定類別數和路徑然后開始訓練。這里說一下我在超參數上做的調整。YOLOv8 的默認輸入尺寸是 640x640但我們的產品缺陷較小我嘗試過 800x800 和 960x960。實測發(fā)現分辨率提升對檢測效果有顯著幫助因為小目標在更高分辨率下保留的像素信息更多mAP 從 0.85 左右提升到 0.91 以上。但代價是訓練時間幾乎翻倍推理時間也變長。最終我取了一個折中值img_size 設為 800在精度和速度之間找到了平衡點。學習率方面默認的 0.01 跑起來發(fā)現收斂速度偏慢后來改成余弦退火調度初始學習率 0.005最終降到 0.0001。訓練到第 50 輪左右Loss 曲線就開始平緩。這里想特別提醒一下不要只盯著總 Loss 看最好把 box_loss 和 cls_loss 分開觀察。如果 box_loss 降不下來通常說明定位分支有問題要回去檢查標注框質量如果 cls_loss 降不下來說明類別特征區(qū)分度不夠可能需要增加樣本或者調整網絡結構。3.2 推理服務架構單機 GPU 還是多機分布式工業(yè)現場部署我強烈不建議一上來就搭一套微服務集群。項目周期短、現場環(huán)境復雜越簡單越可靠。我們的方案是單臺推理服務器 本地 GPU。服務器上跑一個常駐 Python 進程監(jiān)聽消息隊列收到圖像就調用模型推理再把結果寫入數據庫并觸發(fā) PLC 信號。整個鏈路簡單可靠沒有額外的網絡開銷。如果你要同時檢測多個工位也不需要把模型拆分只要開多個進程每個進程加載同一個模型文件分別監(jiān)聽不同的隊列就行。GPU 顯存足夠的情況下這種多進程方案能夠把顯存利用率拉滿。我這里用的是 Docker 容器來封裝推理服務好處是部署環(huán)境一致性有保證換機器的時候直接 docker pull 鏡像就能跑省去很多依賴安裝的麻煩。3.3 推理耗時、并發(fā)策略與硬件資源評估推理耗時這個指標產線上的要求通常很苛刻。我們的產線節(jié)拍是 3 秒一件也就是說單件產品檢測必須在 3 秒內完成否則就會導致產線堵塞。在實際測試中YOLOv8 在 NVIDIA T4 上推理一張 800x800 圖像大約耗時 35~45 毫秒加上圖像預處理縮放、歸一化和后處理NMS、坐標轉換單張圖總耗時約 60 毫秒。這個速度對于 3 秒節(jié)拍的產線來說綽綽有余。如果你的節(jié)拍更快比如 1 秒多件可以考慮用 TensorRT 對模型進行加速。YOLOv8 導出 ONNX 再轉 TensorRT推理速度一般能提升 2 倍左右。TensorRT 的 int8 量化會掉一點精度建議優(yōu)先用 fp16。另外GPU 卡的選型不用盲目上高配T4 或者 RTX 4000 級別的卡就足夠應付大多數產線場景了省錢還能干活甲方也高興。4. 六大高頻故障排查與實操避坑指南4.1 漏檢、誤檢與光照波動問題現場實際跑起來之后遇到最多的問題就是漏檢和誤檢。漏檢意味著不良品流出誤檢意味著良品被攔下兩個都會造成損失。漏檢的原因排查思路我建議按這個順序來先確認新樣本有沒有參與訓練再看當前的光照和訓練時差多少最后檢查模型輸入分辨率是否被壓縮得太狠。如果這三步都沒問題那就回到缺陷樣本本身看是不是出現了訓練集中從未見過的缺陷形態(tài)。我遇到過一種情況產品表面的輕微劃痕在特定光照角度下才可見正常直射光下根本拍不出來。這種屬于成像層面的問題不是算法能解決的調整打光角度和光源波長才是關鍵。誤檢則往往跟背景雜訊有關。比如產線上偶爾會有操作員的影子掠過視野邊緣或者傳送帶上殘留的異物被當成缺陷。這種問題可以加一個 ROI 檢測區(qū)域只對設定的畫面區(qū)域進行判定其余區(qū)域直接忽略。YOLOv8 本身沒有掩膜功能但可以在推理前裁剪圖像也可以在后處理時過濾掉超出 ROI 的檢測框。4.2 模型推理速度慢或內存暴漲的應對模型推理速度變慢常見原因是顯存碎片化。長時間運行的過程中多個進程的顯存分配和釋放會產生碎片導致部分顯存無法利用進而觸發(fā)顯存溢出或換頁。我當時的處理辦法是定時重啟推理進程每天凌晨產線停線檢修的時候自動重啟一次。簡單粗暴但非常有效。如果你想更優(yōu)雅一點可以定期用torch.cuda.empty_cache()清理緩存但實測下來效果不如重啟進程明顯。還有一個容易忽略的坑是 CPU 預處理瓶頸。如果你在 NVIDIA 上做推理但圖像預處理讀取、縮放、歸一化全部在主線程串行完成那 GPU 會頻繁空閑等待。正確的做法是把預處理和推理放到兩個線程里用隊列銜接讓 GPU 始終有活干。這一條對吞吐量影響巨大我們優(yōu)化完之后整體吞吐提升了大概 25%。4.3 模型在不同批次產品間漂移的應對工業(yè)產線還有一個讓人頭疼的問題是產品切換。今天生產 A 型號明天生產 B 型號雖然都是同類產品但尺寸、顏色、材質不一樣缺陷特征也會跟著變。應對方案有兩種思路。第一種為每個型號單獨訓練一個檢測頭推理時根據型號自動選擇模型。缺點是模型文件會越來越多維護成本高。第二種訓練一個多型號通用的模型把所有型號的數據混合起來訓練。缺點是當型號差異過大時模型容量可能不夠。我最后采用的是主模型 增量微調的策略。先盡可能收集所有型號的數據訓練一個基礎模型然后在某個具體型號上線前用這個型號的少量新數據對模型做短時間的增量訓練生成一個輕量的專用版本。這樣既保證了新型號的檢測精度又不需要為每個型號從零訓練一個模型成本可控維護也方便。5. 從演示到落地部署形態(tài)與生態(tài)擴展5.1 單機演示版與產線正式版的區(qū)別很多人會忽略“演示”和“生產”在部署上的巨大差異。演示版只需要在筆記本上跑通模型截幾張圖給老板看效果。但正式版必須考慮可靠性、可維護性和可觀測性。正式版的架構我建議按下面這個清單來搭推理服務必須以守護進程方式運行掉線要能自動拉起。必須記錄每一次檢測的完整日志包括圖像路徑、模型版本、推理結果、耗時方便后期追溯。必須支持遠程更新模型不需要每次更新模型都跑到工控機面前手動操作。必須具備看板界面讓產線管理人員實時看到當前的合格率和缺陷分布。這些點每一條都來自交付現場的直接教訓。項目剛開始跑的時候系統突然靜默崩潰產線沒人知道直到過了一小時才發(fā)現積壓了一堆未檢產品。后來我們加了看門狗服務和微信告警通知這類問題就再也沒發(fā)生過。你在產線上做系統可靠性和可觀測性永遠是第一優(yōu)先級。5.2 告警聯動、數據看板與質量追溯閉環(huán)InspekTron 的價值不只是在檢測那一瞬間。檢測結果如果只是孤零零地存進數據庫那它的價值就打了一半折扣。真正好用的系統會把檢測數據變成產線管理的決策依據。我們的實現方式是檢測結果實時寫入 MySQL同時推送到前端看板?？窗蹇梢园葱r、按班次、按產品型號展示缺陷分布和直通率趨勢。一旦缺陷率超過閾值系統會自動給產線負責人發(fā)送告警消息。再往深做一層就是把檢測圖像和缺陷坐標關聯到產品的條碼上。當客戶投訴某一批次產品質量問題時我們可以快速調出當時這個批次的檢測記錄和圖像定位問題源頭是原料批次問題、設備磨損問題還是工藝參數漂移。這個“質量追溯閉環(huán)”能力往往是客戶決定最終是否驗收的關鍵。6. 一些額外想說的經驗心得項目做完之后回看最想分享的一個經驗是算法工程師在工業(yè)項目里一定不能只會調模型。你得坐得住產線聽得懂現場操作工和工藝工程師的話。很多關鍵技術指標比如“缺陷最小多少毫米需要檢出”“漏一個會給后續(xù)工序帶來多少損失”最開始都是老師傅口頭告訴你的你做成需求文檔再跟對方確認才能避免做出一個技術上完美但現場完全不適用的方案。另外不要迷信“AI 萬能論”。如果傳統視覺方案能用 50 行代碼穩(wěn)定解決就別為了炫技硬上深度學習。工業(yè)現場維護成本才是真正的成本模型的版本管理、數據標注的持續(xù)迭代、現場環(huán)境變化帶來的重新訓練都是隱藏的開發(fā)量。InspekTron 到現在已經穩(wěn)定跑了大半年檢測準確率比人工目檢高不少漏檢率也控制在很低的水平。但我很清楚這只是一個階段性成果。產線的產品會變工藝會變缺陷也會變模型需要跟著迭代系統需要跟著成長。做工業(yè)視覺項目心態(tài)上要有打持久戰(zhàn)的準備這些問題不是一次上線就能徹底終結的。如果你正準備做類似的檢測項目歡迎拿去參考這些經驗。就算硬件和場景完全不同數據標注的策略、模塊解耦的思路、現場部署的避坑點這些東西應該多少有點共通的地方。后面有機會我還可以聊聊模型進一步輕量化的事或者把檢測類項目里標注數據的那些細節(jié)單開一篇。