工厂车间的灯光总是带着点昏黄检测工位的老师傅用肉眼盯着一件件冲压件一天下来眼睛酸得快睁不开。我跑了几年视觉项目最深的一个体会是真正能让工厂愿意掏钱的AI视觉质检不是实验室里刷个99.8%的准确率就完事而是能从产线稳定跑起来、误报少得让工人不烦躁、坏了能有人快速排查的系统。这两年AWS把训练、部署、边缘推理的工具链几乎都补齐了正好让这件事从“做个Demo”变成了“搭一条流水线”。这篇文章我就把自己在AWS上落地AI视觉质检项目时踩过的坑、总结出的套路、反复验证过的参数选择一次说清楚。无论你是在工厂做设备管理还是刚准备上AI视觉希望能少走几周弯路。1. 为什么视觉质检在工业里突然“非它不可”1.1 传统质检的三种切肤之痛传统质检大概分两种人眼盯或者用老式机器视觉做规则判断。人眼盯的问题不用多讲疲劳、漏检、人员流动、标准不统一同一个缺陷在不同班次可能得出完全不同的结论。而老式机器视觉就是那些用固定阈值、边缘检测、模板匹配的算法在背景干净、光源稳定、缺陷类型固定的场景里确实能用可一旦产品表面有纹理、反光、油污、涂层渐变规则写起来就非常痛苦。你花两星期调一组参数换一个料号又全废了。另一个被忽视的痛点是数据。很多工厂不是没有质量数据而是质检数据散落在Excel、纸质单、ERP里和产线上的设备参数、工艺参数完全是割裂的。出了问题只能靠“感觉哪个环节不对”很难量化。这种状况下做质量追溯基本是事后诸葛亮。1.2 AI视觉质检和传统算法的本质区别AI视觉质检尤其是基于深度学习的缺陷检测核心能力是“从样本里自动学习缺陷的特征”而不需要人把“划痕长什么样、凹坑灰度范围是多少”一条条写出来。你给它几百张标注好的缺陷图它自己就能总结出规律。哪怕是以前规则算法根本处理不了的复杂纹理或者缺陷和背景灰度几乎一致的场景深度学习都能找到可用的特征。但别把AI想得太神。它能替代的是“在稳定成像条件下进行可重复判断”这一环节。它不会替你解决光源设计、产线节拍、数据标注准确度、设备兼容性这些工程问题。很多项目翻车不是模型不行而是前面这些工业工程基础没打牢。AWS在整个链条里提供的价值是把数据存储、模型训练、边缘推理、云端运维串成了一套可以复用的基础设施让算法工程师能把大部分精力放在数据和模型本身而不是折腾服务器和部署脚本。2. 一条AWS上完整的AI视觉质检流水线是怎么搭起来的这一章是整个方案的骨架。你可以把它理解成一条从相机到云端再到产线的数字动脉。我们按数据流向一步步拆。2.1 产线采集与边缘预处理视觉质检第一步是把产品的图像稳定拍下来。这里有个很常见的误区以为买个好相机就行了。实际工程里相机、镜头、光源、触发方式是一个整体缺一个都跑不稳。物理链路上通常这样搭工业相机通过GigE Vision或USB3 Vision接口连接工控机或者直接接到支持PoE的工业交换机。光电传感器或PLC给出“产品到位”信号触发相机拍照避免拍空或者拍到运动模糊。工控机上安装相机厂商SDK拉取图像后先做必要的预处理ROI裁剪、图像校正、亮度归一化、去噪。预处理后的图像通过AWS IoT Greengrass部署的边缘组件以MQTT或HTTP方式上传到S3对象存储同时保留一份在边缘缓存。为什么推荐AWS IoT Greengrass因为它可以在边缘节点上运行Lambda函数和容器还能做断网续传。工厂网络经常不稳定如果每次断网都丢图数据就残缺了。你用Greengrass在本地把图片先落盘备份网络恢复后再按序同步这样训练数据和实时日志都不会丢。另外一个实用功能是它可以管理边缘端模型版本当你更新模型时不需要人工跑到每台工控机去拷文件一次下发所有节点自动更新。注意工业相机拍出来的原始图通常是几百KB到几MB级别的BMP或未压缩RAW直接全量上云很浪费带宽也不安全。建议在边缘先做JPEG压缩或无损压缩保留关键的ROI区域即可。缺陷检测需要全幅图时再考虑使用有损更低的格式。2.2 训练、调优与模型转换数据上了S3之后就到了模型训练环节。我在AWS上最常用的路线是Amazon SageMaker。它不只是个训练Notebook而是把数据处理、训练任务、自动调参、模型注册全部管理起来。整个流程大致是将标注数据按COCO或VOC等格式整理成Manifest文件或者直接挂在S3的标注输出里。在SageMaker里启动一个训练任务选择预置的深度学习容器PyTorch或TensorFlow指定GPU实例类型。小规模数据用ml.g4dn.xlarge足够几万张图训练可以上ml.p3.16xlarge或ml.g5.48xlarge。通过SageMaker Experiments记录每次训练的指标和超参数防止“看着差不多的实验”最后都对不上号。训练完成后把模型注册到SageMaker Model Registry自动做版本管理和灰度评估。模型转换如果是跑在边缘的Jetson或x86工控机一般把PyTorch模型导出为ONNX再转成TensorRT或者OpenVINO格式。这一步相当关键直接决定边缘推理的延迟。在云上训练用FP32精度转成INT8量化后实测推理速度能提升两到三倍而准确率几乎不掉前提是做校准数据集。SageMaker本身没有直接转TensorRT的托管能力你可以用一个Pipeline步骤调用EC2实例上的转换脚本或者直接在边缘端部署前完成转换。之所以用SageMaker而不是自己在EC2上开个Jupyter敲命令是因为SageMaker的任务和实验历史能保留下来。工厂里做质量改善审计要求很高——你这批模型是用哪些数据、哪些参数训出来的哪天客户审厂要问你得说得清楚。SageMaker的Lineage Tracking就是干这个的多点几次界面比翻代码仓库找commit香得多。2.3 边缘推理与云端回流的架构模型训练好最终要跑在产线旁边。这里有不同的部署策略离线检测每张图在边缘端直接推理做出OK/NG判断控制信号传给PLC。这是最常见的方式实时性最好也最稳定。在线抽检或复判边缘端判断为NG的图连同局部裁剪图传回云端由更高精度的云端大模型或人工复核。这种方式能显著降低误杀率。我推荐的生产架构是边缘推理优先云端复核兜底。具体来说边缘端用SageMaker Edge Manager来管理模型适配、量化、运行时依赖。Edge Manager支持将模型编译成针对具体芯片优化的二进制并提供了推理时采集指标和做模型更新的能力。如果边缘算力很弱比如只有一块树莓派那也可以考虑把图像通过AWS IoT Analytics或Kinesis Video Streams传到云端做异步检测。但异步检测只适合节拍比较慢的工序对于0.5秒一个件的快速产线还是必须边缘算。数据流向图不必画得花哨核心就三件事图像从相机到边缘推理模块结果回PLC同时图像和结果同步到S3云端的SageMaker模型更新后再推送到边缘节点。这套闭环下来模型就不是一次性的而是越用越准。3. 核心算法选型与参数设置的经验细节3.1 缺陷检测/分类/分割模型选型视觉质检任务可以分成几类缺陷有没有分类、缺陷在哪检测、缺陷轮廓什么样分割。选模型时别一上来就挑大的先看任务和算力预算。二分类OK/NG如果缺陷形态差异大用ResNet-50或EfficientNet-B3就够了。重点不是网络多深而是最后的决策阈值怎么划。多分类区分划痕、污渍、毛刺等建议加上向量的输出做Embedding方便出现未知缺陷时判定为“其他”。目标检测定位缺陷位置YOLOv8或Faster R-CNN都成熟。YOLO系列在边缘部署友好FP16推理轻松跑满线程Faster R-CNN精度高但速度慢。实例分割精确到像素用Mask R-CNN但训练成本高。实际产线很少需要像素级轮廓除非要做缺陷面积测量。这里我自己的经验是超过一半的场景用“分类热力图”就能解决优先尝试简单方案。缺陷尺寸小、对比度低用小锚框的检测模型效果更好但标注成本高解决不了再上实例分割。3.2 图像增强与数据标注要点数据标注是视觉质检项目里耗时最大、最容易出问题的环节。我见过太多项目因为标注不专业导致模型训练出来完全没法看。几点实操建议标注一致性定一个《标注规范》把“轻微划痕算不算缺陷”“遮挡边缘算不算”写清楚至少两个人同时标注后再交给专家复核。任天堂红白机时代“两个程序员对着同一段代码各有理解”的教训在标注团队里一样会发生。不要只标正样本很多团队喜欢标缺陷图忽略正常品的“正常”标注。模型需要大量负样本来抑制误检。建议正常图和缺陷图的比例控制在51到101之间。用增强模拟缺陷如果某种缺陷类型样本太少可以用图像合成的方式把缺陷叠加到正常样本上。比如划痕可以用随机曲线加高斯噪声模拟但要注意不能太假否则模型学到了错误的模式。光照增强车间不同时段光线会有变化建议在训练时加亮度扰动、随机对比度、轻度模糊。这个操作简单但能显著提升现场鲁棒性。3.3 关键指标怎么定工业上不能只看准确率。漏检率和误检率是更关键的两个指标而且往往是矛盾的。漏检率False Negative Rate真正有缺陷但被判为OK的比例。这个直接关系到客户投诉和质量事故必须尽量压低。误检率False Positive RateOK件被判为NG的比例。误检高会导致产线频繁停机复判工人耐心会被磨光甚至偷偷把AI检测绕过。综合指标可以用F1分数或者“在漏检率低于X%的前提下最小化误检率”。实际项目里我会先定一个漏检率的红线比如0.1%然后通过调低置信度阈值或修改损失函数权重来满足这个硬指标再去尽量压低误检率。还有一类指标是让人变得懒惰的比如mAP。要知道mAP在工业场景里和最终体验不完全等价因为mAP是对不同置信度的平均而你实际只用一个工作点。给自己的提示上线前一定要把PR曲线打出来画出模型在“漏检率-误检率”之间的权衡曲线然后和产线人员一起谈判确定工作点。千万不要只在测试集上刷个99%就当交差了到现场一条曲线高低立判。4. 实操环节部署案例一个小型冲压件外观检测项目为了让上面的内容更落地我拿一个真实做过的项目来走一遍全流程。场景是某五金厂的不锈钢冲压件外观检测产品大概指甲盖大小检测目标是划痕、凹坑、生锈和毛刺。节拍要求单件处理时间小于0.5秒。产线有两台工业相机一台拍正面一台拍侧面。4.1 需求定义和硬件清单这个项目我们接触得比较早一开始客户只提了一个很模糊的需求“能不能用AI帮我们检外观”后来我们倒推出三个关键约束节拍每分钟120件单件图像处理含运动、通信不能超过0.5秒。最小缺陷划痕宽度大于0.05毫米且长度大于1毫米必须被检出。环境车间温度约35°C粉尘较多偶尔有油雾光照有波动。根据这些约束硬件选型如下相机500万像素CMOS工业相机全局快门感光度好配合环形无影光源。镜头35mm定焦工业镜头。光源白色LED环形光源配漫射板减少冲压件表面反光影响。工控机GPU为NVIDIA Jetson AGX Orin或工控机配一块RTX 4000 Ada32GB内存512GB NVMe SSD。网络通过工业交换机接入工厂局域网AWS侧用IoT Greengrass。这里我特意强调光源。很多AI项目直接把别人设备拍好的图拉来训练结果现场光线一换模型性能直接跳水。所以我在这个项目里坚持在现场搭建一套模拟光源拍到的图尽量接近真实产线而且整个侦察阶段就把相机的曝光、增益、白平衡全部固定下来。甚至要求工厂这种会变动的环境光源对我们没有影响灯管老化、早晚自然光变化都要通过遮光罩排除掉。4.2 数据采集与标注流程数据采集我们花了两个星期。因为冲压件有几十个料号不同料号尺寸差异大但表面材质相同。我们决定按料号分批采集每个料号先拍300个正常件和50个缺陷件这是最初的数据池。素材主要来自生产线上自然产生的缺陷少部分从历史不良品仓库里挖出来单独摆拍。标注上做了几件事先用SageMaker Ground Truth的自动标注功能把明显的大块凹坑用检测框粗标出来然后人工微调。划痕这种细长目标用多边形标注更准。我们推荐旋转框比正矩形框更能贴合斜向划痕减少背景干扰。对于毛刺只标注接近边缘的小区域生锈则标为区域分割。最终数据集共1.2万张正常图、3200张缺陷图按照811划分训练、验证和测试集。这里要给个忠告不要直接用拍照原图先做ROI裁剪。冲压件通常只占画面中心区域周围很大一块是背景。背景多变容易让模型学到错误特征而且更浪费算力。我们预先标了工件外轮廓训练时统一裁剪到固定尺寸512×512这样速度更快模型也更容易收敛。4.3 模型训练、边缘部署、在云端进行异常回溯训练环节我们选择了YOLOv8的小模型。先直接默认超参跑一轮把baseline拿到然后用SageMaker的自动调参Automatic Model Tuning去搜学习率、权重衰减和图像增强概率。大概并行跑了十几轮找到一组明显更优的参数。注意自动调参不是万能的搜索空间设得太大反而浪费时间最好只调三个最关键的超参。之后把模型转成ONNX再在Jetson上用TensorRT做INT8量化。量化校准图片数量300张足够但如果缺陷很细量化后可能丢失。遇到这种情况我会把检测头保留为FP16其他部分INT8算是个折中。部署时用SageMaker Edge Manager把编译好的模型和推理配置打包成一个组件通过Greengrass下发到工控机。边缘推理模块对外提供Socket接口PLC通过TCP读取结果信号输出给分拣机构。云端回溯方面我们设置了一个采样策略所有判定为NG的图和5%判定为OK的图都会上传到S3。每天跑一个Batch任务统计当天误检、漏检率并把误检原因自动归类光照变化、油污干扰、工件翘起等。这个数据很重要因为现场缺陷分布每天都在变化模型需要持续迭代。没有这套闭环AI质检上线三个月后性能就会悄悄劣化。5. 常见问题与排错锦囊5.1 现场光线与图像一致性最大的坑就是“同一台相机、同一天早上和下午出的图不一样”。有的工厂屋顶有透明瓦下午太阳直射光线变化极大有的日光灯老化后频闪严重。解决方案物理层面加遮光罩、用DC恒流驱动光源、选用低纹波电源。图像层面训练前做归一化推理时也做同样归一化保证训练和推理的图像分布一致。代码层面连拍多张求平均去噪但产线节拍太快时不现实。如果现场判定边缘端应该增加一个亮度异常检测模块如果当张图的平均亮度偏离参考值超过阈值则不给PLC输出OK/NG而是判定为“检测无效”同时报警。这样可以避免因为环境光变化导致误检保证系统的可信度。5.2 推理延迟不稳定、并发问题很多工控机看起来配置不错但推理延迟就是忽高忽低。排查步骤我曾经记录过先确认有没有其他进程抢占CPU/GPU特别是杀毒软件和Windows更新。用TensorRT或OpenVINO的profile工具看具体是哪一层耗时抖动。有些动态shape的模型在推理时反复分配内存延迟就会忽高。解决办法是固定输入尺寸或使用内存池。多线程推理时GPU推理可以用CUDA Stream管理并发CPU推理则要控制线程数和批处理大小。图像解码往往被忽略。JPEG解压在CPU上耗时不少建议使用libjpeg-turbo或GPU硬解码异步流水线设计采集线程、推理线程、通信线程分离不要串行等。5.3 模型漂移和误报率随时间升高这是最隐蔽的问题。模型没变产线也没变但三个月后误报率从0.5%升到3%。原因大概率是产线磨损、耗材更换、环境微变。比如冲压模具磨损会导致毛刺变大表面喷油量变化会导致图像明暗不同。解决办法只能靠持续监控和快速迭代。用SageMaker Pipeline做定时重训练把最新一周的数据混合进训练集。重训练的周期不用太短每周一次足够。每次重新训练前需要对新的NG图做人工复核确认到底是真缺陷还是新干扰。把这些反馈数据作为增量样本。5.4 数据安全与权限管理产线上的图片通常包含工件设计特征属于公司机密。上云传输必须走TLS加密S3桶默认私有并通过IAM Role授予最小权限。边缘端不要存明文Access Key用IoT Greengrass的证书认证和临时凭证。这里有个常见错误很多工程师为了方便把AWS密钥配在工控机的环境变量里一旦设备丢失整个云资源就暴露了。正确做法是使用AWS IoT的凭证提供程序让Greengrass自动轮换临时凭证。6. 从单点项目到规模化复制的一些思考6.1 标准化工作流和项目复制单条产线跑通之后一定会快速复制到其他产线。复制的瓶颈往往不在算法而在“如何把一次性的成功变成可重复的工程流程”。AWS在这里的价值是提供了大量托管服务和现成模板。我建议把项目沉淀成一套“视觉检测模板”数据采集规范相机安装要求、光照要求、文件命名规范、目录结构。标注规范和工具SageMaker Ground Truth的标注模板内置质检标注FAQ。训练Pipeline用Amazon SageMaker Pipelines把数据准备、训练、验证、模型注册串联起来形成可重复执行的工作流。部署Pipeline用AWS IoT Greengrass组件版本管理、Artifact传到S3新产线直接拉取基本不需要现场“陪跑”。模板化之后一套新产线从进场到上线可以压缩到两周内。6.2 成本规划和TCO考量很多老板一听上云就担心成本失控。其实视觉质检上云的成本大头是“数据处理和训练”真正跑产线的边缘推理不会因为云端推理次数多而飙升。因为推理在边缘云上主要是S3存储偶尔的SageMaker训练。这里要特别提醒S3存储图片长期积累会非常贵。建议设置存储生命周期策略原始图默认保存30天不合格品图保存1年方便回溯合格图抽样的则7天后转成低频访问存储甚至删除。训练时用Spot实例可以省70%的GPU费用但需要训练任务支持断点续训。6.3 团队怎么搭配才能不踩坑最后聊人。一个AI视觉质检项目需要三类角色产线自动化工程师懂PLC、相机、光源、机械结构负责硬件和通信。算法工程师负责标注管理、训练、模型转换、调参。云架构工程师负责账号权限、数据管道、网络、运维。很多项目是算法工程师一把抓结果现场接线搞得一塌糊涂也有工厂让电气工程师去调模型玩不转。最佳做法是组建一个矩阵小组云架构师统一设计底座算法和自动化并行推进。最重要的是让老师傅参与验收他提出的意见往往比算法工程师卡阈值更接近真实生产需求。视觉质检说到底不是一个算法项目而是一个系统工程。AWS能帮你把工程化的部分变得模块化但产线上的那些“脾气”还是得靠人一颗颗螺丝拧出来。踩过这么多坑我现在的体会是先让产线稳定让AI在稳定中学习再让AI反过来提升产线的稳定性这才是工业智能化的正循环。