建AI視覺質(zhì)檢流水線:從模型訓(xùn)練到邊緣部署的實戰(zhàn)指南)
工廠車間的燈光總是帶著點昏黃檢測工位的老師傅用肉眼盯著一件件沖壓件一天下來眼睛酸得快睜不開。我跑了幾年視覺項目最深的一個體會是真正能讓工廠愿意掏錢的AI視覺質(zhì)檢不是實驗室里刷個99.8%的準(zhǔn)確率就完事而是能從產(chǎn)線穩(wěn)定跑起來、誤報少得讓工人不煩躁、壞了能有人快速排查的系統(tǒng)。這兩年AWS把訓(xùn)練、部署、邊緣推理的工具鏈幾乎都補齊了正好讓這件事從“做個Demo”變成了“搭一條流水線”。這篇文章我就把自己在AWS上落地AI視覺質(zhì)檢項目時踩過的坑、總結(jié)出的套路、反復(fù)驗證過的參數(shù)選擇一次說清楚。無論你是在工廠做設(shè)備管理還是剛準(zhǔn)備上AI視覺希望能少走幾周彎路。1. 為什么視覺質(zhì)檢在工業(yè)里突然“非它不可”1.1 傳統(tǒng)質(zhì)檢的三種切膚之痛傳統(tǒng)質(zhì)檢大概分兩種人眼盯或者用老式機器視覺做規(guī)則判斷。人眼盯的問題不用多講疲勞、漏檢、人員流動、標(biāo)準(zhǔn)不統(tǒng)一同一個缺陷在不同班次可能得出完全不同的結(jié)論。而老式機器視覺就是那些用固定閾值、邊緣檢測、模板匹配的算法在背景干凈、光源穩(wěn)定、缺陷類型固定的場景里確實能用可一旦產(chǎn)品表面有紋理、反光、油污、涂層漸變規(guī)則寫起來就非常痛苦。你花兩星期調(diào)一組參數(shù)換一個料號又全廢了。另一個被忽視的痛點是數(shù)據(jù)。很多工廠不是沒有質(zhì)量數(shù)據(jù)而是質(zhì)檢數(shù)據(jù)散落在Excel、紙質(zhì)單、ERP里和產(chǎn)線上的設(shè)備參數(shù)、工藝參數(shù)完全是割裂的。出了問題只能靠“感覺哪個環(huán)節(jié)不對”很難量化。這種狀況下做質(zhì)量追溯基本是事后諸葛亮。1.2 AI視覺質(zhì)檢和傳統(tǒng)算法的本質(zhì)區(qū)別AI視覺質(zhì)檢尤其是基于深度學(xué)習(xí)的缺陷檢測核心能力是“從樣本里自動學(xué)習(xí)缺陷的特征”而不需要人把“劃痕長什么樣、凹坑灰度范圍是多少”一條條寫出來。你給它幾百張標(biāo)注好的缺陷圖它自己就能總結(jié)出規(guī)律。哪怕是以前規(guī)則算法根本處理不了的復(fù)雜紋理或者缺陷和背景灰度幾乎一致的場景深度學(xué)習(xí)都能找到可用的特征。但別把AI想得太神。它能替代的是“在穩(wěn)定成像條件下進行可重復(fù)判斷”這一環(huán)節(jié)。它不會替你解決光源設(shè)計、產(chǎn)線節(jié)拍、數(shù)據(jù)標(biāo)注準(zhǔn)確度、設(shè)備兼容性這些工程問題。很多項目翻車不是模型不行而是前面這些工業(yè)工程基礎(chǔ)沒打牢。AWS在整個鏈條里提供的價值是把數(shù)據(jù)存儲、模型訓(xùn)練、邊緣推理、云端運維串成了一套可以復(fù)用的基礎(chǔ)設(shè)施讓算法工程師能把大部分精力放在數(shù)據(jù)和模型本身而不是折騰服務(wù)器和部署腳本。2. 一條AWS上完整的AI視覺質(zhì)檢流水線是怎么搭起來的這一章是整個方案的骨架。你可以把它理解成一條從相機到云端再到產(chǎn)線的數(shù)字動脈。我們按數(shù)據(jù)流向一步步拆。2.1 產(chǎn)線采集與邊緣預(yù)處理視覺質(zhì)檢第一步是把產(chǎn)品的圖像穩(wěn)定拍下來。這里有個很常見的誤區(qū)以為買個好相機就行了。實際工程里相機、鏡頭、光源、觸發(fā)方式是一個整體缺一個都跑不穩(wěn)。物理鏈路上通常這樣搭工業(yè)相機通過GigE Vision或USB3 Vision接口連接工控機或者直接接到支持PoE的工業(yè)交換機。光電傳感器或PLC給出“產(chǎn)品到位”信號觸發(fā)相機拍照避免拍空或者拍到運動模糊。工控機上安裝相機廠商SDK拉取圖像后先做必要的預(yù)處理ROI裁剪、圖像校正、亮度歸一化、去噪。預(yù)處理后的圖像通過AWS IoT Greengrass部署的邊緣組件以MQTT或HTTP方式上傳到S3對象存儲同時保留一份在邊緣緩存。為什么推薦AWS IoT Greengrass因為它可以在邊緣節(jié)點上運行Lambda函數(shù)和容器還能做斷網(wǎng)續(xù)傳。工廠網(wǎng)絡(luò)經(jīng)常不穩(wěn)定如果每次斷網(wǎng)都丟圖數(shù)據(jù)就殘缺了。你用Greengrass在本地把圖片先落盤備份網(wǎng)絡(luò)恢復(fù)后再按序同步這樣訓(xùn)練數(shù)據(jù)和實時日志都不會丟。另外一個實用功能是它可以管理邊緣端模型版本當(dāng)你更新模型時不需要人工跑到每臺工控機去拷文件一次下發(fā)所有節(jié)點自動更新。注意工業(yè)相機拍出來的原始圖通常是幾百KB到幾MB級別的BMP或未壓縮RAW直接全量上云很浪費帶寬也不安全。建議在邊緣先做JPEG壓縮或無損壓縮保留關(guān)鍵的ROI區(qū)域即可。缺陷檢測需要全幅圖時再考慮使用有損更低的格式。2.2 訓(xùn)練、調(diào)優(yōu)與模型轉(zhuǎn)換數(shù)據(jù)上了S3之后就到了模型訓(xùn)練環(huán)節(jié)。我在AWS上最常用的路線是Amazon SageMaker。它不只是個訓(xùn)練Notebook而是把數(shù)據(jù)處理、訓(xùn)練任務(wù)、自動調(diào)參、模型注冊全部管理起來。整個流程大致是將標(biāo)注數(shù)據(jù)按COCO或VOC等格式整理成Manifest文件或者直接掛在S3的標(biāo)注輸出里。在SageMaker里啟動一個訓(xùn)練任務(wù)選擇預(yù)置的深度學(xué)習(xí)容器PyTorch或TensorFlow指定GPU實例類型。小規(guī)模數(shù)據(jù)用ml.g4dn.xlarge足夠幾萬張圖訓(xùn)練可以上ml.p3.16xlarge或ml.g5.48xlarge。通過SageMaker Experiments記錄每次訓(xùn)練的指標(biāo)和超參數(shù)防止“看著差不多的實驗”最后都對不上號。訓(xùn)練完成后把模型注冊到SageMaker Model Registry自動做版本管理和灰度評估。模型轉(zhuǎn)換如果是跑在邊緣的Jetson或x86工控機一般把PyTorch模型導(dǎo)出為ONNX再轉(zhuǎn)成TensorRT或者OpenVINO格式。這一步相當(dāng)關(guān)鍵直接決定邊緣推理的延遲。在云上訓(xùn)練用FP32精度轉(zhuǎn)成INT8量化后實測推理速度能提升兩到三倍而準(zhǔn)確率幾乎不掉前提是做校準(zhǔn)數(shù)據(jù)集。SageMaker本身沒有直接轉(zhuǎn)TensorRT的托管能力你可以用一個Pipeline步驟調(diào)用EC2實例上的轉(zhuǎn)換腳本或者直接在邊緣端部署前完成轉(zhuǎn)換。之所以用SageMaker而不是自己在EC2上開個Jupyter敲命令是因為SageMaker的任務(wù)和實驗歷史能保留下來。工廠里做質(zhì)量改善審計要求很高——你這批模型是用哪些數(shù)據(jù)、哪些參數(shù)訓(xùn)出來的哪天客戶審廠要問你得說得清楚。SageMaker的Lineage Tracking就是干這個的多點幾次界面比翻代碼倉庫找commit香得多。2.3 邊緣推理與云端回流的架構(gòu)模型訓(xùn)練好最終要跑在產(chǎn)線旁邊。這里有不同的部署策略離線檢測每張圖在邊緣端直接推理做出OK/NG判斷控制信號傳給PLC。這是最常見的方式實時性最好也最穩(wěn)定。在線抽檢或復(fù)判邊緣端判斷為NG的圖連同局部裁剪圖傳回云端由更高精度的云端大模型或人工復(fù)核。這種方式能顯著降低誤殺率。我推薦的生產(chǎn)架構(gòu)是邊緣推理優(yōu)先云端復(fù)核兜底。具體來說邊緣端用SageMaker Edge Manager來管理模型適配、量化、運行時依賴。Edge Manager支持將模型編譯成針對具體芯片優(yōu)化的二進制并提供了推理時采集指標(biāo)和做模型更新的能力。如果邊緣算力很弱比如只有一塊樹莓派那也可以考慮把圖像通過AWS IoT Analytics或Kinesis Video Streams傳到云端做異步檢測。但異步檢測只適合節(jié)拍比較慢的工序?qū)τ?.5秒一個件的快速產(chǎn)線還是必須邊緣算。數(shù)據(jù)流向圖不必畫得花哨核心就三件事圖像從相機到邊緣推理模塊結(jié)果回PLC同時圖像和結(jié)果同步到S3云端的SageMaker模型更新后再推送到邊緣節(jié)點。這套閉環(huán)下來模型就不是一次性的而是越用越準(zhǔn)。3. 核心算法選型與參數(shù)設(shè)置的經(jīng)驗細(xì)節(jié)3.1 缺陷檢測/分類/分割模型選型視覺質(zhì)檢任務(wù)可以分成幾類缺陷有沒有分類、缺陷在哪檢測、缺陷輪廓什么樣分割。選模型時別一上來就挑大的先看任務(wù)和算力預(yù)算。二分類OK/NG如果缺陷形態(tài)差異大用ResNet-50或EfficientNet-B3就夠了。重點不是網(wǎng)絡(luò)多深而是最后的決策閾值怎么劃。多分類區(qū)分劃痕、污漬、毛刺等建議加上向量的輸出做Embedding方便出現(xiàn)未知缺陷時判定為“其他”。目標(biāo)檢測定位缺陷位置YOLOv8或Faster R-CNN都成熟。YOLO系列在邊緣部署友好FP16推理輕松跑滿線程Faster R-CNN精度高但速度慢。實例分割精確到像素用Mask R-CNN但訓(xùn)練成本高。實際產(chǎn)線很少需要像素級輪廓除非要做缺陷面積測量。這里我自己的經(jīng)驗是超過一半的場景用“分類熱力圖”就能解決優(yōu)先嘗試簡單方案。缺陷尺寸小、對比度低用小錨框的檢測模型效果更好但標(biāo)注成本高解決不了再上實例分割。3.2 圖像增強與數(shù)據(jù)標(biāo)注要點數(shù)據(jù)標(biāo)注是視覺質(zhì)檢項目里耗時最大、最容易出問題的環(huán)節(jié)。我見過太多項目因為標(biāo)注不專業(yè)導(dǎo)致模型訓(xùn)練出來完全沒法看。幾點實操建議標(biāo)注一致性定一個《標(biāo)注規(guī)范》把“輕微劃痕算不算缺陷”“遮擋邊緣算不算”寫清楚至少兩個人同時標(biāo)注后再交給專家復(fù)核。任天堂紅白機時代“兩個程序員對著同一段代碼各有理解”的教訓(xùn)在標(biāo)注團隊里一樣會發(fā)生。不要只標(biāo)正樣本很多團隊喜歡標(biāo)缺陷圖忽略正常品的“正?!睒?biāo)注。模型需要大量負(fù)樣本來抑制誤檢。建議正常圖和缺陷圖的比例控制在51到101之間。用增強模擬缺陷如果某種缺陷類型樣本太少可以用圖像合成的方式把缺陷疊加到正常樣本上。比如劃痕可以用隨機曲線加高斯噪聲模擬但要注意不能太假否則模型學(xué)到了錯誤的模式。光照增強車間不同時段光線會有變化建議在訓(xùn)練時加亮度擾動、隨機對比度、輕度模糊。這個操作簡單但能顯著提升現(xiàn)場魯棒性。3.3 關(guān)鍵指標(biāo)怎么定工業(yè)上不能只看準(zhǔn)確率。漏檢率和誤檢率是更關(guān)鍵的兩個指標(biāo)而且往往是矛盾的。漏檢率False Negative Rate真正有缺陷但被判為OK的比例。這個直接關(guān)系到客戶投訴和質(zhì)量事故必須盡量壓低。誤檢率False Positive RateOK件被判為NG的比例。誤檢高會導(dǎo)致產(chǎn)線頻繁停機復(fù)判工人耐心會被磨光甚至偷偷把AI檢測繞過。綜合指標(biāo)可以用F1分?jǐn)?shù)或者“在漏檢率低于X%的前提下最小化誤檢率”。實際項目里我會先定一個漏檢率的紅線比如0.1%然后通過調(diào)低置信度閾值或修改損失函數(shù)權(quán)重來滿足這個硬指標(biāo)再去盡量壓低誤檢率。還有一類指標(biāo)是讓人變得懶惰的比如mAP。要知道m(xù)AP在工業(yè)場景里和最終體驗不完全等價因為mAP是對不同置信度的平均而你實際只用一個工作點。給自己的提示上線前一定要把PR曲線打出來畫出模型在“漏檢率-誤檢率”之間的權(quán)衡曲線然后和產(chǎn)線人員一起談判確定工作點。千萬不要只在測試集上刷個99%就當(dāng)交差了到現(xiàn)場一條曲線高低立判。4. 實操環(huán)節(jié)部署案例一個小型沖壓件外觀檢測項目為了讓上面的內(nèi)容更落地我拿一個真實做過的項目來走一遍全流程。場景是某五金廠的不銹鋼沖壓件外觀檢測產(chǎn)品大概指甲蓋大小檢測目標(biāo)是劃痕、凹坑、生銹和毛刺。節(jié)拍要求單件處理時間小于0.5秒。產(chǎn)線有兩臺工業(yè)相機一臺拍正面一臺拍側(cè)面。4.1 需求定義和硬件清單這個項目我們接觸得比較早一開始客戶只提了一個很模糊的需求“能不能用AI幫我們檢外觀”后來我們倒推出三個關(guān)鍵約束節(jié)拍每分鐘120件單件圖像處理含運動、通信不能超過0.5秒。最小缺陷劃痕寬度大于0.05毫米且長度大于1毫米必須被檢出。環(huán)境車間溫度約35°C粉塵較多偶爾有油霧光照有波動。根據(jù)這些約束硬件選型如下相機500萬像素CMOS工業(yè)相機全局快門感光度好配合環(huán)形無影光源。鏡頭35mm定焦工業(yè)鏡頭。光源白色LED環(huán)形光源配漫射板減少沖壓件表面反光影響。工控機GPU為NVIDIA Jetson AGX Orin或工控機配一塊RTX 4000 Ada32GB內(nèi)存512GB NVMe SSD。網(wǎng)絡(luò)通過工業(yè)交換機接入工廠局域網(wǎng)AWS側(cè)用IoT Greengrass。這里我特意強調(diào)光源。很多AI項目直接把別人設(shè)備拍好的圖拉來訓(xùn)練結(jié)果現(xiàn)場光線一換模型性能直接跳水。所以我在這個項目里堅持在現(xiàn)場搭建一套模擬光源拍到的圖盡量接近真實產(chǎn)線而且整個偵察階段就把相機的曝光、增益、白平衡全部固定下來。甚至要求工廠這種會變動的環(huán)境光源對我們沒有影響燈管老化、早晚自然光變化都要通過遮光罩排除掉。4.2 數(shù)據(jù)采集與標(biāo)注流程數(shù)據(jù)采集我們花了兩個星期。因為沖壓件有幾十個料號不同料號尺寸差異大但表面材質(zhì)相同。我們決定按料號分批采集每個料號先拍300個正常件和50個缺陷件這是最初的數(shù)據(jù)池。素材主要來自生產(chǎn)線上自然產(chǎn)生的缺陷少部分從歷史不良品倉庫里挖出來單獨擺拍。標(biāo)注上做了幾件事先用SageMaker Ground Truth的自動標(biāo)注功能把明顯的大塊凹坑用檢測框粗標(biāo)出來然后人工微調(diào)。劃痕這種細(xì)長目標(biāo)用多邊形標(biāo)注更準(zhǔn)。我們推薦旋轉(zhuǎn)框比正矩形框更能貼合斜向劃痕減少背景干擾。對于毛刺只標(biāo)注接近邊緣的小區(qū)域生銹則標(biāo)為區(qū)域分割。最終數(shù)據(jù)集共1.2萬張正常圖、3200張缺陷圖按照811劃分訓(xùn)練、驗證和測試集。這里要給個忠告不要直接用拍照原圖先做ROI裁剪。沖壓件通常只占畫面中心區(qū)域周圍很大一塊是背景。背景多變?nèi)菀鬃屇P蛯W(xué)到錯誤特征而且更浪費算力。我們預(yù)先標(biāo)了工件外輪廓訓(xùn)練時統(tǒng)一裁剪到固定尺寸512×512這樣速度更快模型也更容易收斂。4.3 模型訓(xùn)練、邊緣部署、在云端進行異?;厮萦?xùn)練環(huán)節(jié)我們選擇了YOLOv8的小模型。先直接默認(rèn)超參跑一輪把baseline拿到然后用SageMaker的自動調(diào)參Automatic Model Tuning去搜學(xué)習(xí)率、權(quán)重衰減和圖像增強概率。大概并行跑了十幾輪找到一組明顯更優(yōu)的參數(shù)。注意自動調(diào)參不是萬能的搜索空間設(shè)得太大反而浪費時間最好只調(diào)三個最關(guān)鍵的超參。之后把模型轉(zhuǎn)成ONNX再在Jetson上用TensorRT做INT8量化。量化校準(zhǔn)圖片數(shù)量300張足夠但如果缺陷很細(xì)量化后可能丟失。遇到這種情況我會把檢測頭保留為FP16其他部分INT8算是個折中。部署時用SageMaker Edge Manager把編譯好的模型和推理配置打包成一個組件通過Greengrass下發(fā)到工控機。邊緣推理模塊對外提供Socket接口PLC通過TCP讀取結(jié)果信號輸出給分揀機構(gòu)。云端回溯方面我們設(shè)置了一個采樣策略所有判定為NG的圖和5%判定為OK的圖都會上傳到S3。每天跑一個Batch任務(wù)統(tǒng)計當(dāng)天誤檢、漏檢率并把誤檢原因自動歸類光照變化、油污干擾、工件翹起等。這個數(shù)據(jù)很重要因為現(xiàn)場缺陷分布每天都在變化模型需要持續(xù)迭代。沒有這套閉環(huán)AI質(zhì)檢上線三個月后性能就會悄悄劣化。5. 常見問題與排錯錦囊5.1 現(xiàn)場光線與圖像一致性最大的坑就是“同一臺相機、同一天早上和下午出的圖不一樣”。有的工廠屋頂有透明瓦下午太陽直射光線變化極大有的日光燈老化后頻閃嚴(yán)重。解決方案物理層面加遮光罩、用DC恒流驅(qū)動光源、選用低紋波電源。圖像層面訓(xùn)練前做歸一化推理時也做同樣歸一化保證訓(xùn)練和推理的圖像分布一致。代碼層面連拍多張求平均去噪但產(chǎn)線節(jié)拍太快時不現(xiàn)實。如果現(xiàn)場判定邊緣端應(yīng)該增加一個亮度異常檢測模塊如果當(dāng)張圖的平均亮度偏離參考值超過閾值則不給PLC輸出OK/NG而是判定為“檢測無效”同時報警。這樣可以避免因為環(huán)境光變化導(dǎo)致誤檢保證系統(tǒng)的可信度。5.2 推理延遲不穩(wěn)定、并發(fā)問題很多工控機看起來配置不錯但推理延遲就是忽高忽低。排查步驟我曾經(jīng)記錄過先確認(rèn)有沒有其他進程搶占CPU/GPU特別是殺毒軟件和Windows更新。用TensorRT或OpenVINO的profile工具看具體是哪一層耗時抖動。有些動態(tài)shape的模型在推理時反復(fù)分配內(nèi)存延遲就會忽高。解決辦法是固定輸入尺寸或使用內(nèi)存池。多線程推理時GPU推理可以用CUDA Stream管理并發(fā)CPU推理則要控制線程數(shù)和批處理大小。圖像解碼往往被忽略。JPEG解壓在CPU上耗時不少建議使用libjpeg-turbo或GPU硬解碼異步流水線設(shè)計采集線程、推理線程、通信線程分離不要串行等。5.3 模型漂移和誤報率隨時間升高這是最隱蔽的問題。模型沒變產(chǎn)線也沒變但三個月后誤報率從0.5%升到3%。原因大概率是產(chǎn)線磨損、耗材更換、環(huán)境微變。比如沖壓模具磨損會導(dǎo)致毛刺變大表面噴油量變化會導(dǎo)致圖像明暗不同。解決辦法只能靠持續(xù)監(jiān)控和快速迭代。用SageMaker Pipeline做定時重訓(xùn)練把最新一周的數(shù)據(jù)混合進訓(xùn)練集。重訓(xùn)練的周期不用太短每周一次足夠。每次重新訓(xùn)練前需要對新的NG圖做人工復(fù)核確認(rèn)到底是真缺陷還是新干擾。把這些反饋數(shù)據(jù)作為增量樣本。5.4 數(shù)據(jù)安全與權(quán)限管理產(chǎn)線上的圖片通常包含工件設(shè)計特征屬于公司機密。上云傳輸必須走TLS加密S3桶默認(rèn)私有并通過IAM Role授予最小權(quán)限。邊緣端不要存明文Access Key用IoT Greengrass的證書認(rèn)證和臨時憑證。這里有個常見錯誤很多工程師為了方便把AWS密鑰配在工控機的環(huán)境變量里一旦設(shè)備丟失整個云資源就暴露了。正確做法是使用AWS IoT的憑證提供程序讓Greengrass自動輪換臨時憑證。6. 從單點項目到規(guī)?;瘡?fù)制的一些思考6.1 標(biāo)準(zhǔn)化工作流和項目復(fù)制單條產(chǎn)線跑通之后一定會快速復(fù)制到其他產(chǎn)線。復(fù)制的瓶頸往往不在算法而在“如何把一次性的成功變成可重復(fù)的工程流程”。AWS在這里的價值是提供了大量托管服務(wù)和現(xiàn)成模板。我建議把項目沉淀成一套“視覺檢測模板”數(shù)據(jù)采集規(guī)范相機安裝要求、光照要求、文件命名規(guī)范、目錄結(jié)構(gòu)。標(biāo)注規(guī)范和工具SageMaker Ground Truth的標(biāo)注模板內(nèi)置質(zhì)檢標(biāo)注FAQ。訓(xùn)練Pipeline用Amazon SageMaker Pipelines把數(shù)據(jù)準(zhǔn)備、訓(xùn)練、驗證、模型注冊串聯(lián)起來形成可重復(fù)執(zhí)行的工作流。部署Pipeline用AWS IoT Greengrass組件版本管理、Artifact傳到S3新產(chǎn)線直接拉取基本不需要現(xiàn)場“陪跑”。模板化之后一套新產(chǎn)線從進場到上線可以壓縮到兩周內(nèi)。6.2 成本規(guī)劃和TCO考量很多老板一聽上云就擔(dān)心成本失控。其實視覺質(zhì)檢上云的成本大頭是“數(shù)據(jù)處理和訓(xùn)練”真正跑產(chǎn)線的邊緣推理不會因為云端推理次數(shù)多而飆升。因為推理在邊緣云上主要是S3存儲偶爾的SageMaker訓(xùn)練。這里要特別提醒S3存儲圖片長期積累會非常貴。建議設(shè)置存儲生命周期策略原始圖默認(rèn)保存30天不合格品圖保存1年方便回溯合格圖抽樣的則7天后轉(zhuǎn)成低頻訪問存儲甚至刪除。訓(xùn)練時用Spot實例可以省70%的GPU費用但需要訓(xùn)練任務(wù)支持?jǐn)帱c續(xù)訓(xùn)。6.3 團隊怎么搭配才能不踩坑最后聊人。一個AI視覺質(zhì)檢項目需要三類角色產(chǎn)線自動化工程師懂PLC、相機、光源、機械結(jié)構(gòu)負(fù)責(zé)硬件和通信。算法工程師負(fù)責(zé)標(biāo)注管理、訓(xùn)練、模型轉(zhuǎn)換、調(diào)參。云架構(gòu)工程師負(fù)責(zé)賬號權(quán)限、數(shù)據(jù)管道、網(wǎng)絡(luò)、運維。很多項目是算法工程師一把抓結(jié)果現(xiàn)場接線搞得一塌糊涂也有工廠讓電氣工程師去調(diào)模型玩不轉(zhuǎn)。最佳做法是組建一個矩陣小組云架構(gòu)師統(tǒng)一設(shè)計底座算法和自動化并行推進。最重要的是讓老師傅參與驗收他提出的意見往往比算法工程師卡閾值更接近真實生產(chǎn)需求。視覺質(zhì)檢說到底不是一個算法項目而是一個系統(tǒng)工程。AWS能幫你把工程化的部分變得模塊化但產(chǎn)線上的那些“脾氣”還是得靠人一顆顆螺絲擰出來。踩過這么多坑我現(xiàn)在的體會是先讓產(chǎn)線穩(wěn)定讓AI在穩(wěn)定中學(xué)習(xí)再讓AI反過來提升產(chǎn)線的穩(wěn)定性這才是工業(yè)智能化的正循環(huán)。