這兩年我跑了不少制造工廠的數(shù)字化項目最大的感受是很多工廠不是不想上AI質(zhì)檢而是壓根不知道怎么把AI從demo變成產(chǎn)線上天天能跑的工藝。視覺質(zhì)檢其實不是新概念CCD光學(xué)檢測在產(chǎn)線用了很多年但真正讓檢測能力產(chǎn)生質(zhì)變的是后面那套數(shù)據(jù)閉環(huán)的支撐。AWS在這個環(huán)節(jié)里恰恰扮演了骨架的角色——從圖像存儲、模型訓(xùn)練到邊緣推理它把視覺質(zhì)檢從“實驗室演示”拉到了“車間常態(tài)化運行”的位置。這篇文章我就圍繞“AI賦能視覺質(zhì)檢、AWS推動工業(yè)智能化”這個主題把整套系統(tǒng)的設(shè)計思路、核心環(huán)節(jié)、實操過程以及我在現(xiàn)場踩過的坑一次性講清楚。適合制造業(yè)的數(shù)字化負責人、視覺工程師以及正在琢磨怎么把AI落到車間里的開發(fā)者。1. 這個項目到底在解決什么問題1.1 傳統(tǒng)質(zhì)檢的三大瓶頸先聊聊我見過最多的產(chǎn)線質(zhì)檢場景。無論是金屬件表面缺陷、紡織布面疵點還是電子元器件的焊點檢測傳統(tǒng)做法基本靠人工目檢加少量光電傳感器。人工目檢的問題很現(xiàn)實一條產(chǎn)線一分鐘過幾十個工件質(zhì)檢員盯著屏幕看三個小時后注意力必然下降漏檢率會肉眼可見地往上走。我曾經(jīng)在一家汽車零部件工廠統(tǒng)計過白班和夜班的漏檢率能差出兩倍這不是人的態(tài)度問題是人眼的生理規(guī)律。第二個瓶頸是節(jié)拍壓力。產(chǎn)線提速之后人工質(zhì)檢往往成了瓶頸工序。我在現(xiàn)場經(jīng)常聽到一種做法把產(chǎn)線速度降下來讓質(zhì)檢員能看清。這本質(zhì)上是在用產(chǎn)能換質(zhì)量代價很大?？吭黾尤耸忠膊滑F(xiàn)實質(zhì)檢崗位流動性高、培訓(xùn)周期長熟練工的判斷標準還帶很強的個人色彩同一塊缺陷甲說NG乙說OK標準根本落不了地。第三個瓶頸是數(shù)據(jù)黑洞。人工檢完之后最多在紙質(zhì)單上打個勾或者錄一條OK/NG記錄。至于缺陷長什么樣、位置在哪、尺寸多大、趨勢如何統(tǒng)統(tǒng)沒有量化。這就導(dǎo)致工藝改善沒有依據(jù)供應(yīng)商來料的質(zhì)量波動也發(fā)現(xiàn)不了。我們后來做AI視覺質(zhì)檢本質(zhì)上不是用一套算法去替代人眼而是在補上“數(shù)據(jù)記錄和量化分析”這一塊短板。1.2 AI視覺質(zhì)檢的技術(shù)閉環(huán)是什么AI視覺質(zhì)檢的技術(shù)閉環(huán)說穿了就是四步圖像采集、缺陷識別、結(jié)果輸出、數(shù)據(jù)回流。圖像采集解決“能不能看清”的問題光源、相機、觸發(fā)方式都在這一步缺陷識別是AI模型的核心能力它要回答“這是什么缺陷”結(jié)果輸出是把模型的判斷變成產(chǎn)線能用的信號比如OK/NG指示燈、報警、機械臂剔除數(shù)據(jù)回流則是把每一次檢測的圖片和結(jié)論保存下來定期分析趨勢反哺到前端的工藝參數(shù)調(diào)整。這四步看著簡單但真正落地的難點在最后一步。很多項目做到第三步就停了模型能識別缺陷、能輸出NG結(jié)果然后就沒了。沒有數(shù)據(jù)回流系統(tǒng)就是一個高級報警器改不了工藝、降不了漏檢老板自然覺得投入產(chǎn)出比低。而AWS這套體系的價值恰恰是把第四步的數(shù)據(jù)存儲、分析和可視化做得很順手。訓(xùn)練出的模型是一個判斷引擎而S3加QuickSight這套組合讓圖片、缺陷標簽、產(chǎn)線節(jié)拍數(shù)據(jù)能沉淀成可查詢的資產(chǎn)后面排產(chǎn)、工藝優(yōu)化、供應(yīng)商考核就都有了依據(jù)。1.3 為什么選擇AWS來承載這套體系我選AWS做這套體系的底座主要出于幾個現(xiàn)實考慮。第一個是存儲和計算資源的彈性。訓(xùn)練缺陷識別模型是個計算密集的活但沒有哪條產(chǎn)線需要24小時不間斷地訓(xùn)練模型更多時候是每周或者每月重訓(xùn)一次。AWS按需開訓(xùn)練實例、用完釋放的計費方式比在本地機房常駐一批GPU服務(wù)器務(wù)實得多尤其適合中小規(guī)模的工廠項目。第二個是服務(wù)鏈路的完整性。從S3對象存儲收圖到SageMaker做訓(xùn)練和推理再到Lambda做事件觸發(fā)和無狀態(tài)業(yè)務(wù)邏輯最后用QuickSight做可視化這條鏈路基本不用拼第三方組件減少了系統(tǒng)集成的工作量。第三個是邊緣側(cè)的能力。車間現(xiàn)場往往網(wǎng)絡(luò)條件差不可能每臺相機都把圖片傳到云端再回傳結(jié)果。AWS Panorama這類邊緣設(shè)備支持在本地直接跑模型推理模型在云端訓(xùn)練好、推到邊緣節(jié)點運行兼顧了集中管理和現(xiàn)場低延遲這兩個需求。2. 核心環(huán)節(jié)拆解視覺質(zhì)檢系統(tǒng)的四塊基石2.1 圖像采集光源與相機的工程細節(jié)先說結(jié)論圖像質(zhì)量決定了AI模型的天花板而圖像質(zhì)量里光源的影響往往比相機還大。我在不少項目里看到團隊一上來就選幾十萬像素的高端相機結(jié)果光源沒做好拍出來的圖對比度低模型再怎么調(diào)也救不回來。視覺質(zhì)檢的光源一般分幾種環(huán)形光適合突出邊緣和輪廓同軸光適合高反光表面條形光適合大平面均勻照明。金屬件表面缺陷通常會用到低角度光讓劃痕和凹凸在灰度圖像上產(chǎn)生明顯的亮度差。相機選型上面陣相機適合形態(tài)穩(wěn)定的工件線陣相機適合連續(xù)運動的卷材比如紡織布和鋼材。分辨率不是越高越好而是取決于你要檢測的最小缺陷尺寸。舉例說如果視場是200mm寬要識別0.3mm的針孔缺陷每個缺陷至少要覆蓋3個像素那么需要的分辨率大約是200mm除以0.1mm每像素0.1mm也就是至少2000像素。這個計算在方案階段就要做不要等系統(tǒng)跑起來才發(fā)現(xiàn)缺陷像素太小模型根本學(xué)不到特征。觸發(fā)方式同樣影響成像穩(wěn)定性。產(chǎn)線速度快的時候用光電傳感器配合延時觸發(fā)確保工件運動到相機視野正中間才曝光。我遇到過項目拍出來的工件位置每次都偏一點模型訓(xùn)練時老是不收斂后來查清楚是觸發(fā)延時沒調(diào)好圖像上工件位置偏移好幾個像素。這一類工程細節(jié)不會在論文里寫但恰恰是現(xiàn)場落地成敗的分水嶺。2.2 數(shù)據(jù)標注與預(yù)處理決定模型上限的功課數(shù)據(jù)標注是視覺質(zhì)檢項目里最枯燥但最決定上限的環(huán)節(jié)。我常跟團隊說模型不會比你給它的標注更聰明。標注質(zhì)量不行后面所有調(diào)參都是在垃圾上蓋樓。標注工作要認真規(guī)劃缺陷類別太粗了模型分不清細節(jié)太細了標注成本翻倍還容易標錯。比如金屬表面缺陷可以先分成劃傷、凹坑、銹斑、異色四類每個類別定義清楚邊界標注人員在動手前先做一輪培訓(xùn)和一致性測試。樣本均衡是另一個繞不開的問題。產(chǎn)線上正常品永遠占絕大多數(shù)缺陷樣本可能只有千分之幾。直接拿原始數(shù)據(jù)訓(xùn)練模型很容易學(xué)成“永遠輸出OK”也能把準確率刷到99%。這不是模型聰明是它偷懶了。實際做法一般有兩種一是欠采樣正常品控制正負樣本比例在1:1到1:3之間二是對缺陷樣本做數(shù)據(jù)增強比如旋轉(zhuǎn)、平移、亮度變換、加噪聲把有限的缺陷樣本“擴”出更多變體。這里要特別說一下增強操作要遵循物理規(guī)律。做表面檢測的時候缺陷的形態(tài)受光照角度影響很大所以亮度變化是合理的但上下翻轉(zhuǎn)要慎重——如果工件工藝決定劃痕方向是固定的翻轉(zhuǎn)后樣本含義就變了。我見過團隊盲目套用ImageNet的增強策略把缺陷項目搞崩的。標注完成后數(shù)據(jù)版本管理也要做不能今天標一批、明天改一批最后訓(xùn)練用的數(shù)據(jù)和評估用的數(shù)據(jù)對不上。2.3 模型訓(xùn)練算法選型與效果調(diào)優(yōu)圖像分類、目標檢測、語義分割這三類任務(wù)在視覺質(zhì)檢里都能找到對應(yīng)場景。表面缺陷是否存在的粗篩通常用分類就能解決需要定位缺陷位置和數(shù)量的用目標檢測需要對缺陷輪廓做精細分析、評估面積和形狀的用語義分割。從我個人的經(jīng)驗看大部分項目不會一上來就分得這么細建議先用一個檢測模型跑通全流程再根據(jù)業(yè)務(wù)需求逐步增加分類或分割能力。模型選型上我不建議在產(chǎn)線應(yīng)用里追新。YOLO系列和Faster R-CNN這類檢測模型在工業(yè)界驗證充分社區(qū)資料多出問題好排查。ResNet作為分類骨干網(wǎng)絡(luò)穩(wěn)定性也經(jīng)過了大量項目檢驗。訓(xùn)練時強烈建議用預(yù)訓(xùn)練權(quán)重做遷移學(xué)習(xí)而不是從零隨機初始化訓(xùn)練。工業(yè)缺陷數(shù)據(jù)量通常只有幾千張遠不足以讓模型從零學(xué)會基本視覺特征但在預(yù)訓(xùn)練模型基礎(chǔ)上微調(diào)哪怕只有兩千張缺陷圖也能訓(xùn)練出可用的檢測器。調(diào)優(yōu)環(huán)節(jié)要盯住一組核心指標精確率、召回率、F1分數(shù)和平均精度。質(zhì)檢場景里召回率通常比精確率更金貴——漏掉一個缺陷流到客戶手里比多報警幾次讓工人復(fù)檢的代價大得多。所以模型訓(xùn)練完不要只看準確率要看在可接受的誤報率下召回率能不能達到99%以上。這個閾值設(shè)定是個動態(tài)博弈我在后面會展開講。2.4 推理部署云端與邊緣的執(zhí)行路徑模型訓(xùn)練完之后部署路徑有兩條云端推理和邊緣推理。云端推理適合對實時性要求不極端、網(wǎng)絡(luò)穩(wěn)定的場景模型托管在SageMaker Endpoint上相機把圖像上傳到云端推理結(jié)果返回耗時通常在幾百毫秒到一兩秒。邊緣推理則適合產(chǎn)線節(jié)拍快、網(wǎng)絡(luò)受限的情況模型部署到AWS Panorama設(shè)備或工控機里本地完成推理延遲能壓到幾十毫秒。邊緣部署相對復(fù)雜需要考慮模型壓縮和硬件適配。同一套模型在GPU云端能跑到毫秒級在邊緣設(shè)備的推理芯片上可能是另一回事。實際操作上常做兩步優(yōu)化一是模型量化把浮點權(quán)重壓縮到INT8精度推理速度能提升一到三倍代價是精度可能有小幅下降需要拿測試集重新驗證二是用推理加速框架做層融合和算子優(yōu)化具體能優(yōu)化多少取決于模型結(jié)構(gòu)和硬件平臺。我個人的經(jīng)驗云端和邊緣不是二選一的關(guān)系更常見的是混合路徑邊緣設(shè)備做實時判斷把NG置信度高的圖片異步傳到云端云端用完整模型做二次復(fù)核同時把數(shù)據(jù)沉淀下來做后續(xù)訓(xùn)練迭代。兩條鏈路各司其職既保證了產(chǎn)線節(jié)拍又讓數(shù)據(jù)閉環(huán)完整運轉(zhuǎn)。3. 實操過程在AWS上跑通一個金屬表面缺陷檢測項目3.1 數(shù)據(jù)管道搭建S3與Lambda的流水線拿一個我做過的最典型的金屬表面缺陷項目舉例。現(xiàn)場是一條金屬沖壓件產(chǎn)線產(chǎn)線上部署了兩臺工業(yè)相機每秒鐘產(chǎn)出大概5張1280x720的灰度圖。第一步我把相機端采集軟件與AWS S3打通圖片按“日期/班次/產(chǎn)線編號”的目錄結(jié)構(gòu)落盤。S3這個選擇很自然它不限制存儲容量檢索也方便加個生命周期規(guī)則就可以自動歸檔過期數(shù)據(jù)控制存儲成本。圖片進了S3之后下一步要做的是觸發(fā)下游任務(wù)。這里用Lambda來做事件驅(qū)動是最順的做法。在S3桶上配置ObjectCreated事件新圖片上傳后自動觸發(fā)一個Lambda函數(shù)。這個函數(shù)做兩件事一是讀取圖片的元數(shù)據(jù)把產(chǎn)線、班次、時間戳統(tǒng)一記錄到DynamoDB二是調(diào)用一個邏輯判斷——如果圖片是產(chǎn)線上隨機抽檢的樣本就進入訓(xùn)練數(shù)據(jù)集如果是全天候全量圖片就進入推理流水線。這一步看起來簡單但把數(shù)據(jù)分類邏輯在源頭做清楚后面訓(xùn)練和推理兩條線就不會互相污染。數(shù)據(jù)樣本攢到一定規(guī)模后訓(xùn)練流程也要自動化。我習(xí)慣用Lambda定期檢查S3桶里的有效樣本數(shù)量達到設(shè)定閾值就自動提交SageMaker訓(xùn)練任務(wù)。整個數(shù)據(jù)管道跑起來之后人的角色基本只剩兩個查看訓(xùn)練報告和確認是否發(fā)布新模型。這比傳統(tǒng)人工拷貝數(shù)據(jù)、手動啟動訓(xùn)練的方式省了大量時間。3.2 SageMaker訓(xùn)練從內(nèi)置算法到自定義模型的路徑SageMaker訓(xùn)練任務(wù)啟動時需要把訓(xùn)練腳本和參數(shù)配置清楚。我用的路徑是這樣的訓(xùn)練數(shù)據(jù)以Manifest文件格式指向S3里的圖片路徑和標注信息SageMaker會從S3拉取數(shù)據(jù)做數(shù)據(jù)增強和批量讀取。訓(xùn)練腳本里定義好網(wǎng)絡(luò)結(jié)構(gòu)和損失函數(shù)記錄訓(xùn)練過程的損失值和驗證集指標到CloudWatch日志方便隨時查看。訓(xùn)練參數(shù)的選擇上我踩過幾次坑之后有了一套相對穩(wěn)妥的默認值。批量大小取決于顯存一般取16到32之間初始學(xué)習(xí)率用0.001配合學(xué)習(xí)率衰減策略在總訓(xùn)練輪次的1/3和2/3處各衰減一次衰減系數(shù)0.1優(yōu)化器選Adam它對超參不那么敏感適合工業(yè)場景里快速跑通。訓(xùn)練輪次我通常控制在50到80配合早停策略驗證集指標連續(xù)10輪不提升就提前結(jié)束節(jié)省算力支出。這里我要重點建議訓(xùn)練過程中務(wù)必記錄每一項超參數(shù)和評估指標形成一份實驗追蹤表。SageMaker的Experiment功能可以做這件事但很多人沒用好。工業(yè)項目有個實際痛點——過幾個月要復(fù)現(xiàn)當初一個不錯的結(jié)果如果沒有實驗記錄光憑記憶根本找不到當時用的參數(shù)組合。每跑完一次訓(xùn)練我把數(shù)據(jù)集版本、模型結(jié)構(gòu)、超參數(shù)、評估指標整理成一個JSON存到S3后續(xù)回顧時直接查詢。訓(xùn)練完成后SageMaker會自動把模型產(chǎn)物傳到指定的S3路徑然后創(chuàng)建一個模型注冊條目。我通常會在驗證集上算好F1分數(shù)并設(shè)定一個“是否達到發(fā)布線”的閾值。只有指標達標的模型才允許后續(xù)創(chuàng)建推理Endpoint。這個門檻非常關(guān)鍵不然線上跑的模型可能越換越差。3.3 云端推理接口封裝模型發(fā)布之后我通過SageMaker Endpoint創(chuàng)建一個實時推理接口。Endpoint本質(zhì)上是把模型部署到一個持續(xù)運行的實例上等待請求進來。圖像傳來時先由Lambda對圖像做預(yù)處理——統(tǒng)一縮放到模型輸入尺寸、歸一化像素值然后封裝成JSON格式的請求發(fā)送到Endpoint。推理響應(yīng)里包含缺陷類別、置信度和檢測框坐標。接口這一環(huán)容易被客戶問到“如果我現(xiàn)有MES系統(tǒng)想接這個檢測結(jié)果怎么辦”我的做法通常是再包一層API Gateway把Lambda推理入口暴露成一個REST接口MES系統(tǒng)通過HTTP調(diào)用即可。返回結(jié)果結(jié)構(gòu)要事先約定好我用一個標準JSON結(jié)構(gòu)image_id、defect_type、confidence、bbox、timestamp五個字段。這樣MES拿到的是一份結(jié)構(gòu)化數(shù)據(jù)可以直接落庫也可以在后續(xù)做不良品的批次追溯。云端的完整模型跑實時推理雖然延遲高一點但好處是精度高、可以處理復(fù)雜缺陷。實際操作中云端推理更像是邊緣節(jié)點的一個“復(fù)核員”。邊緣設(shè)備發(fā)現(xiàn)可疑缺陷后把原始圖片轉(zhuǎn)發(fā)給云端接口再做一次精細判斷雙方結(jié)果一致才放行不一致則優(yōu)先判NG并通知人工介入。這層雙保險對于客戶要求極低漏檢率的情況很管用。3.4 邊緣部署與產(chǎn)線聯(lián)動把模型放到邊緣設(shè)備進行實時檢測是整個項目里最有工業(yè)現(xiàn)場感的一環(huán)。AWS Panorama設(shè)備可以直接接入網(wǎng)絡(luò)攝像頭或者RTSP視頻流在設(shè)備本地完成推理。模型在云端訓(xùn)練好、轉(zhuǎn)換成邊緣設(shè)備支持的格式后通過Panorama管理控制臺下發(fā)到設(shè)備。這套流程比傳統(tǒng)人工到現(xiàn)場去拷貝模型、重啟服務(wù)的方式規(guī)范很多也支持批量下發(fā)到多條產(chǎn)線。邊緣模型部署完第一件事不是直接跑而是先做新舊結(jié)果一致性比對。我要求在設(shè)備頂部部署運行兩周觀察期邊緣模型和云端模型同時對同一批圖片推理比較兩者的偏差率。如果偏差超過0.5%說明邊緣量化的精度損失不可接受需要回爐調(diào)優(yōu)。觀察期通過后再正式切換產(chǎn)線聯(lián)動信號線接到PLCNG結(jié)果直接觸發(fā)報警或機械臂剔除。這里有一個容易忽略的點邊緣設(shè)備的模型版本要和云端保持同步管理。我遇到過現(xiàn)場設(shè)備跑了舊模型幾個月沒人發(fā)現(xiàn)后來因為月度對比數(shù)據(jù)對不上才排查出來。后來我定了一個規(guī)則——模型發(fā)布時自動創(chuàng)建一個版本號標簽邊緣設(shè)備上報當前版本號運維巡檢只要比對版本號就能發(fā)現(xiàn)問題。產(chǎn)線聯(lián)調(diào)的細節(jié)很多這個版本管理算是最容易被忽視但又最影響全局的環(huán)節(jié)。4. 常見問題與排查技巧實錄4.1 誤檢率降不下來怎么辦誤檢率是視覺質(zhì)檢項目里被問得最多的問題。產(chǎn)線一天跑下來幾千個工件誤報個幾十次工人就要反復(fù)跑去看時間久了會不信任系統(tǒng)。誤檢高的原因我排查的順序一般是這樣先看訓(xùn)練數(shù)據(jù)是否有標簽噪聲有些標注本身就標錯了模型學(xué)到的邊界自然就會偏再看出圖環(huán)境是否發(fā)生了變化比如光源衰減、相機位移導(dǎo)致現(xiàn)場圖片和訓(xùn)練圖片分布不一致這個在工業(yè)現(xiàn)場非常常見。解決誤檢最直接的手段是調(diào)置信度閾值。模型輸出一個0到1的置信度默認區(qū)分正負樣本的閾值是0.5。誤報多的時候把閾值往上提比如提到0.85讓模型只有非常確信時才判NG。這一招簡單有效但副作用是可能漏掉真正的低置信度缺陷所以調(diào)閾值前必須先算清楚業(yè)務(wù)更在意漏檢還是誤檢。我做過一個客戶因為后端有大量的人工復(fù)檢所以接受較高的誤檢率來換取極低的漏檢率閾值反而下調(diào)了。閾值不是一個死值它應(yīng)該由業(yè)務(wù)止損邏輯來決定。4.2 推理延遲不達標推理延遲不達標在邊緣場景里經(jīng)常表現(xiàn)為產(chǎn)線節(jié)拍跟不上——檢測結(jié)果還沒出來工件已經(jīng)流到下一道工序了。排查時先測量延遲構(gòu)成圖像采集花多少毫秒、預(yù)處理花多少毫秒、模型推理花多少毫秒、結(jié)果輸出花多少毫秒。很多時候模型推理不是最大瓶頸圖像預(yù)處理和格式轉(zhuǎn)換反而占了大頭。釋數(shù)壓縮圖像、改傳JPEG而不是BMP預(yù)處理時間能降下一大截。模型側(cè)的優(yōu)化主要是量化和剪枝。INT8量化是我最常用的手段能把推理速度提升2倍左右具體收益因模型結(jié)構(gòu)而異。另外輸入尺寸也值得審視——如果模型輸入是640x640而原始圖像是1280x720可以先在邊緣設(shè)備上對目標區(qū)域做裁剪再縮放而不是把整張圖直接resize這樣既減小了輸入數(shù)據(jù)量也避免細小缺陷被整體縮小后丟失特征。如果延遲還是超標就要考慮換推理加速框架或者換更輕量的模型結(jié)構(gòu)了。4.3 小樣本場景下的過擬合小樣本過擬合在工業(yè)缺陷檢測里太常見了?？蛻裟芴峁┑娜毕輼泳鸵粌砂購埬Ｐ陀?xùn)練在訓(xùn)練集上表現(xiàn)很好一到新數(shù)據(jù)就抓瞎。遷移學(xué)習(xí)是最有效的應(yīng)對手段用ImageNet預(yù)訓(xùn)練權(quán)重做初始化缺陷數(shù)據(jù)只用來微調(diào)最后一層和部分中間層。這么做的好處是模型前幾層的底層視覺特征不用重新學(xué)只需要把高層語義特征適配到缺陷檢測任務(wù)上。第二個手段是采用更強的正則化。Dropout系數(shù)從默認的0.5調(diào)到0.7權(quán)重衰減系數(shù)適當增大數(shù)據(jù)增強里把旋轉(zhuǎn)角度、亮度擾動范圍放寬一些。這些操作的目標都一致把模型對訓(xùn)練樣本“死記硬背”的傾向壓下去逼它學(xué)更泛化的特征。我還在項目里用過一種補充樣本的思路——找公用的表面缺陷數(shù)據(jù)集做預(yù)訓(xùn)練再用自己的小樣本微調(diào)效果常常出人意料地好行業(yè)公開數(shù)據(jù)集雖然場景不完全一致但紋理類特征是可遷移的。4.4 成本控制與長期運營云端算力成本是客戶常常關(guān)心的隱性問題。訓(xùn)練階段按需開實例我記得一個中型項目每輪訓(xùn)練大概幾美元到幾十美元但如果不注意釋放實例放著不用的Endpoint每個月也能吃掉上百美元。我的習(xí)慣是給非核心環(huán)境的Endpoint設(shè)置自動休眠在CloudWatch上配定時關(guān)閉和啟動的規(guī)則工作日產(chǎn)線生產(chǎn)時開機夜間和休息日自動停掉。存儲側(cè)也要有生命周期策略。S3桶里原始圖片如果全量永久保存存儲費用會隨產(chǎn)線運行時間線性增長。我一般按“三個月內(nèi)熱存儲、一年內(nèi)冷存儲、超過一年匹配規(guī)則刪除”來做分層規(guī)劃。另外數(shù)據(jù)最終要流回工藝改善QuickSight這類BI服務(wù)連接S3或Athena查詢結(jié)果管理層能看到的是缺陷趨勢圖和不良率曲線而不僅僅是技術(shù)系統(tǒng)的運行指標。這部分投入雖然不直接產(chǎn)出檢測能力但它是整個項目后續(xù)擴大影響的通道值得在前面就規(guī)劃好。5. 關(guān)于這套體系我最后想說的做工業(yè)AI項目實施到后面我越來越形成一種體會技術(shù)模型只是整個系統(tǒng)里很小的一部分產(chǎn)線上的數(shù)據(jù)有多少、干凈程度如何、缺陷定義是否清晰、業(yè)務(wù)目標到底是降低漏檢還是減少誤報往往比模型本身更能決定項目成敗。AWS的優(yōu)勢不在某個單點能力而在于提供了一套能把數(shù)據(jù)采集、訓(xùn)練、部署、反饋串起來的完整閉環(huán)讓整個體系的每一環(huán)都有跡可循。如果你正在規(guī)劃工廠里的視覺質(zhì)檢項目我的建議是別一上來就追求最新最強的大模型先把一條產(chǎn)線跑通用已有的成熟檢測模型搭好S3到SageMaker再到邊緣設(shè)備的鏈路采集一批真實數(shù)據(jù)把模型訓(xùn)練和部署的流程走順再逐步迭代檢測能力和業(yè)務(wù)場景。工業(yè)現(xiàn)場不比算法榜單穩(wěn)定、可追溯、能跟上產(chǎn)線節(jié)拍比什么都重要。系統(tǒng)跑上半年以上沉淀下來的數(shù)據(jù)和運營流程才真正是這套智能化改造的核心資產(chǎn)。這套邏輯在很多行業(yè)通用也希望這篇文章能讓正在做類似探索的朋友少走一點彎路。