1. 产线质检的困局：为什么AI视觉质检成了刚需
我在产线现场待过很长一段时间，深知人工质检的苦。光源稍微调整一下，底板换一批，同一个缺陷在甲眼里是明显瑕疵，在乙眼里就含糊带过了。这种“一致性”问题，不是靠管理手段能彻底解决的，因为人本身就会有疲劳、情绪和注意力波动。这也是为什么AI视觉质检能在工业圈子里快速落地，它本质上解决的不是“看得见”的问题，而是“看得准、看得稳、看得久”的问题。
很多人以为质检只是产线里一个环节，实际上它是工厂交付体系里最敏感的一道关卡。漏检一次，客户退货是一回事，更麻烦的是品牌信誉受损。我见过有工厂因为一批外观缺陷的产品流出，被下游客户直接暂停供货资格，损失远远超过那批货本身的货值。所以产线管理者对质检方案的要求从来非常朴素：不要漏，不要误，不要成为瓶颈。而传统的机器视觉方案，在应对复杂表面缺陷时，正变得越来越吃力。
1.1 传统机器视觉的边界：规则写得再好，也追不上缺陷的千变万化
传统机器视觉的逻辑是“用规则去描述缺陷”。工程师把所有已知缺陷形态抽象成特征，比如灰度的阈值、边缘的梯度、纹理的方差，再通过像素级别的算法去判断“这块区域是否异常”。这种思路对标准化程度极高的场景是有效的，比如贴片电阻的引脚有无、药瓶封口是否压紧、瓶盖有无缺失。因为这些目标的特征足够刚性，规则可以稳定命中。
但到了材料表面缺陷这类场景，问题就来了。金属拉丝表面的细微划伤，纹理方向是变化的，灰度接近背景，阈值分割根本分不干净。还有高光反射区域，同一套光源下不同表面角度拍出来的灰度差异，比缺陷和正常区域的差异还要大。规则算法在这种场景下会出现两个极端：阈值调严了，误杀率暴涨，把正常产品当废品；阈值调松了，漏检率失控，该抓的缺陷全放过去了。
另外一个更现实的痛点，是规则的维护成本。每来一种新产品、换一次材料批次、调整一次工艺参数，原先调好的规则可能全部失效。工厂的工艺工程师不得不在产线旁拿着电脑反复调参数，这本身就违背了“减少人工介入”的初衷。我见过最夸张的项目，一套规则写了两年多，积累了几千个参数分支，最后还是因为产品改版而推倒重来。
1.2 AI视觉质检真正解决的三类问题
AI视觉质检用机器学习模型替代了“人工规则定义”的核心部分，让模型从样本中自己学习“什么是正常”“什么是缺陷”。在实际落地中，它主要解决了三类问题。
第一类是复杂表面缺陷检测。深度学习模型能从图像中提取层次化的特征，不再依赖单一的灰度和边缘信息。细微划伤、压痕、脏污、气泡这类原本难以用阈值描述的缺陷，可以通过大量样本训练被模型有效识别。
第二类是相似缺陷的精细分类。很多工厂不仅需要知道“有没有缺陷”，还要知道“是哪一类缺陷”，因为不同缺陷对应的工艺责任方不同。比如注塑件的料花和烧焦，外表相似，但一个需要调模温、一个需要调注射压力。人工分检容易混淆，AI模型在数据充足的情况下，可以稳定区分这些高度相似的类别。
第三类是动态变化场景下的自适应。产品换型时，AI模型只需要补充少量新样本做迁移学习，通常几天内就能适应新产线，而不是像规则方案一样重新写逻辑。这一点对多品种、小批量的柔性产线尤其重要。
一句话总结：AI视觉质检不是把“看得见”的门槛提高到多高的程度，而是把质检从依赖人的经验判断，变成依赖数据驱动的稳定决策。这也是工业智能化绕不开的一个基础模块。
2. AWS在AI视觉质检里的具体位置：不是花瓶，是链条的底盘
刚开始做工业视觉项目时，我常被问到：模型可以用开源的，训练可以用本地的，为什么非要引入AWS？这个问题如果放在三年前，我会说“看预算”。但现在我的答案变了：要看你想把这件事做成一个单点方案，还是一个可持续迭代的系统。如果只是给一台设备装个检测镜头，那确实一台工控机加一个训练好的模型文件就够了。但要真正融入生产管理体系，把检测数据变成改善工艺的依据，云底座的价值就显现出来了。
以AWS为例，它在视觉质检链路里不是某一个环节，而是贯穿数据回流、模型训练、版本管理、边缘推理、结果反馈的整条链路底座。我甚至觉得，AWS在这个场景下最值钱的不是某个算法能力，而是它把“数据从哪里来、模型往哪里去、结果怎么反馈”的闭环路径给铺好了。
2.1 我为什么把底座放在AWS上
选择AWS有几个非常现实的理由。
第一，它和现场工业设备之间的链路成熟。AWS IoT Core、Greengrass、Kinesis Video Streams这些服务都是为海量设备接入场景设计的，工业相机拍到的图像数据可以直接通过边缘网关上传，也可以预处理后在边缘端完成推理，只把结果和异常样本回传。这比自建一套MQTT加对象存储的方案省事得多。
第二，训练侧的生态完整。从数据标注（SageMaker Ground Truth）、训练环境（SageMaker Training）、模型优化（SageMaker Neo）、到部署（SageMaker Endpoint或IoT Greengrass），AWS把整个MLOps链路封装得比较顺手。对于工厂里的IT团队或算法工程师来说，不需要自己折腾Kubernetes集群就能完成模型上线。
第三，工业数据的合规和权限管理需求。质检图像本质上属于生产数据，很多工厂对它的存储位置、访问权限有严格规定。AWS在身份认证（IAM）、数据加密（KMS）、审计日志（CloudTrail）上的能力，能直接满足工厂和审计方的大部分要求。这一点在集团型客户那里往往是硬门槛，没有合规能力，方案再好也进不去。
2.2 一套质检链路用到哪些AWS服务，各自干什么
我整理一下实际项目中常用的服务组合，每个服务在链路里的定位如下：
| AWS服务 | 在视觉质检链路中的角色 |
|---|---|
| Amazon Kinesis Video Streams | 采集产线相机视频流，实时上传或边缘侧预筛选后上传 |
| AWS IoT Greengrass | 在边缘设备上运行推理模型，支持本地推理和云端同步 |
| Amazon S3 | 存储原始图像、标注数据、训练数据集和模型版本 |
| Amazon SageMaker | 数据标注、模型训练、调优、部署、监控全流程 |
| AWS Lambda | 处理图像上传事件、触发训练任务、实现结果分发等轻逻辑 |
| Amazon DynamoDB | 存储检测结果记录、生成批次统计报表 |
| Amazon QuickSight | 把检测数据变成管理看板，供产线经理查看趋势 |
这些服务单独看都不稀奇，但组合起来就能形成一条自动化的数据链路。比如边缘设备拍到的NG图像传到S3，Lambda检测到上传事件后自动更新数据集统计，当样本数量达到阈值就触发一次增量训练，训练完成后灰度部署到边缘端，整个流程人只需要在评审节点做确认。
2.3 一条最小可用架构长这样
一个刚起步的视觉质检项目不需要一上来就铺满各种服务，最小可用架构其实可以很简洁：
产线上的工业相机通过GigE或USB接到边缘计算设备（比如带GPU的工业电脑或AWS Panorama设备），边缘设备上运行着训练好的缺陷检测模型。模型推理结果有两个去处：正常的OK结果直接记录；NG结果连同图像一起上传到AWS，存入S3。DynamoDB里记录检测信息，包括产品批次、工位、检测时间、缺陷类型。当异常趋势上升到一定阈值，系统通过Lambda触发告警，通知质量工程师去确认。
云端训练这边，S3里积累的图像数据定期导出，经过标注后投入SageMaker训练新版本模型。模型验证通过后，再通过Greengrass部署回边缘设备。整个闭环不需要专门开发一套复杂的后端平台，用好AWS现有组件的编排就能跑起来。
这套架构的好处是，每一个组件都可以独立替换或扩展。比如边缘设备性能不够了，可以把推理参数调低继续用，也可以换更强算力的设备；云端训练数据量大了，可以加数据版本管理工具，或者接入SageMaker的管线自动化。
3. 从相机到云端再到产线：搭建视觉质检链路的实操过程
理论架构清楚了，真正落地还是有一段路要走。这一节我把实操过程中的关键环节拆开讲，包含数据、训练、部署三块。每一点都是我实际踩过的经验，照着做能少走不少弯路。
3.1 数据是质检的地基：采集与标注的经验
AI视觉质检项目里流传一句话：模型决定上限，数据决定下限。但工业场景的数据采集和互联网场景完全不同，它有几个特殊性。
首先是数据不均衡问题。正常品永远比缺陷品多得多，甚至一天产出几十万个正常品，只有几十个缺陷样本。这种情况直接把原始数据扔给模型，模型很快就会学成“永远输出OK”，因为准确率也能到99%以上。我常用的做法是：先收集一段时间的历史缺陷样本，做初步聚类，保证每个缺陷类别至少有200到500张图像，再结合正常样本做数据增强。
其次是标注一致性。曾经有项目里，两个标注员对同一张图的判定结论不一致，差出了20%的样本量。后来我们在标注规范里加入了“缺陷类型定义卡”，每个类别配上三张典型图像和两张边界图像，并要求标注员先做一套20张图的测试，准确率达到95%以上才允许正式标注。另外，SageMaker Ground Truth里可以用“标注质检”功能，让经验更丰富的人抽检，把标注质量这个变量控住。
第三是光源和采集的一致性。很多算法团队在实验室训练的时候效果很好，上了产线就崩，原因之一就是实验室拍图和现场拍图的光照条件不一致。我建议在项目初期就固定产线拍摄环境，包括光源类型、角度、曝光参数，后续所有采集图像都保持相同的拍摄条件。这样采集到的数据才是有效的训练素材，而不是给模型增加干扰噪声。
3.2 模型训练：选择什么架构、怎么调优
视觉质检的模型选择没有银弹，一般视具体任务而定。我按照实际接触过的项目经验做个分类：
缺陷定位与分类需求明确的场景，最常用的是YOLO系列目标检测模型。它可以同时给出“这个缺陷在图像的哪个位置”和“它属于哪一类”两个信息，非常适合产线上需要在图像中标记缺陷位置的需求。如果只需要整体判断OK/NG，不考虑缺陷位置，轻量分类网络比如ResNet、MobileNet就够用。
对于比较细微的表面缺陷，比如布匹的纹理异常、金属表面的细微刮伤，单纯的目标检测有时会把微小目标漏掉。这时候可以考虑用图像分割模型（如U-Net）或者异常检测模型（如PatchCore），这类模型通过重构误差或特征距离来判断某块区域是否偏离正常形态，对微小异常更敏感。
训练过程中有几个经验值得分享。第一，图像尺寸不要一上来就resize到过小，很多细微缺陷在缩小后特征就消失了。可以先在256×256或512×512的尺度上训练，跑通后再根据边缘设备的算力做适配。第二，数据增强要结合工业场景，不要盲目用颜色抖动，因为产线对颜色的稳定性要求很高，反倒是随机旋转、平移、亮度对比度微调比较实用。第三，不要只看准确率或mAP指标，要同时看缺陷类别的召回率。在质检场景里，漏检的代价远高于误检，所以我的习惯是在验证集上重点观察每个缺陷类别的召回率是否都达标。
用SageMaker做训练也比较顺滑。把数据放在S3里，写一个训练脚本，指定实例类型（通常用ml.g4dn或ml.p3系列做GPU训练），SageMaker会自动拉起训练环境、完成训练、把模型输出到指定路径。数据量不大（几千张图）时，甚至用ml.g4dn.xlarge单机训练就够了，没必要一上来就搞分布式。
3.3 部署到产线：边缘推理、结果上云与数据回流
训练出的模型如何部署到产线，这个环节的坑比训练还多，因为现场环境远比云端复杂。
首先是推理框架的选择。PyTorch模型不能直接部署到边缘设备上，一般需要导出成ONNX格式，再用TensorRT或OpenVINO做转换和优化。以NVIDIA Jetson设备为例，我的习惯是：PyTorch训练好模型后，先导出ONNX，再转成TensorRT的engine文件，用FP16精度跑推理。这样能把推理速度提升一倍到三倍，而且精度损失通常可以控制在可接受范围内。
其次是边缘设备的选择。很多人以为边缘端必须要很强的GPU，其实不完全是。检测节拍、图像分辨率、缺陷大小这些参数共同决定了算力需求。比如节拍是每秒检测一个工件，图像分辨率是500万像素，目标是最小的划伤长度为10个像素，那推理时间就要控制在几百毫秒内。这时候一块Jetson Orin Nano或者Jetson Xavier NX级别的小卡就能胜任。如果节拍到每秒5个以上，就需要更强算力，或者考虑用多块卡并行推理。
推理结果的回传也要设计好。OK结果的记录可以非常精简，只记ID和时间。NG结果必须关联图像，方便后续分析和复盘。我通常会在边缘端先把NG图像做JPEG压缩再上传，以降低带宽压力。同时，不要把每张正常图像都传到云端，成本上完全划不来。
数据回流是很多项目容易忽略的一环。边缘端积累的推理结果和异常图像，要定期回流到云端，变成下一轮模型训练的素材。曾经有个项目，边缘端已经跑了两周，一直没有新的缺陷样本回流，因为新品没上市。后来新品一代出来，缺陷类型和原来的训练集差异很大，模型表现立刻下降。这时候才知道，持续的数据回流不是可选项，是必选项。
4. 最容易翻车的几个地方：我的排错记录
前面讲的都是正向流程，但实际项目一定会在某个环节突然给你一个大嘴巴。我把几个让我印象深刻的翻车点记录下来，给各位参考。
4.1 类别不平衡导致“假收敛”问题
最开始我训练一个注塑件表面缺陷检测模型，训练曲线非常漂亮，loss一路下降，验证集准确率到99%，当时还挺得意。结果到了产线上，连续一周都只报出极少数的NG样本，而且报出来的还都是同一类严重缺陷。仔细分析才发现，训练集中严重缺陷类别的样本占比太高，而轻微缺陷和正常品的特征区分度不够，模型实际上走了一条“偷懒”路径——把所有不确定的都判成OK。准确率高是因为OK样本本身就占绝大多数，模型只需要“一直输出OK”就能拿到高分。
后来的解决办法是重新设计训练集：把交替类别的数量平衡了一下，又引入了Focal Loss来惩罚“简单样本”的过大权重。效果立刻改善，轻微缺陷的召回率从不到50%提升到了90%以上。这件事让我得出的结论是：在质检项目里，不要只看整体准确率，要按类别单独看混淆矩阵。
4.2 边缘设备推理性能不够？先别急着换硬件
有一个项目，客户用的工控机是好几年前的产品，模型部署上去之后单张图像推理耗时超过3秒，根本无法满足产线节拍。当时客户的第一反应是换一台更贵的GPU工控机，一台要好几万元。我没有急着让他们花钱，而是先做了一轮排查。
先看模型本身。模型输入尺寸是1024×1024，对于这个场景的缺陷粒度来说，其实用736×736就完全够用了。改成736后，推理耗时从3秒直接降到1.8秒。然后做TensorRT优化，从FP32改到FP16，耗时降到0.9秒。再检查推理代码，发现图像预处理和归一化全是在CPU上串行跑的，这部分占了0.3秒。把预处理改成批处理并放到GPU上之后，耗时降到0.6秒。最后再用多线程做流水线，实际每张图的耗时压缩到0.4秒以内。
所以我的经验是：推理速度不达标时，先查模型输入尺寸、推理精度、预处理放的位置，这三项优化完还不够，再考虑换硬件。这样既能帮客户省钱，也是工程师真正有价值的体现。
4.3 误判闭环：AI模型输出之后还缺一环
模型部署之后，客户提出一个要求：“你们AI说NG，我不可能直接就信，能不能让NG结果先走一遍人工复判？”这个要求很合理。因为AI视觉质检的定位是“筛出可疑品”，而不是完全替代人的终判。最终措施是：AI判定NG的工件不直接淘汰，而是按批次进入一个固定的人工复判工位，复判结果再录入系统，作为反馈数据。
这个“人机协同”的闭环比纯自动化更难，但价值非常大。因为人工复判的结果不断回流到训练数据集，模型的误检率会逐步下降。经过三个月的积累，AI判断NG的工件里，人工复判后确认真正有缺陷的比例从最开始不到60%，提升到了90%以上。这也说明，在质检场景里，模型不是在真空中工作，它需要和人的反馈形成持续学习的回路。
4.4 毫米级到底怎么来的：标定和光源才是隐形杀手
有次项目验收时，客户说检测精度要求0.5毫米，我们实验室测试时也确实是能达到的。但上了产线，同样的模型，同样的相机，精度却掉到了1毫米甚至更差。排查了很久才找到原因：产线安装相机时，没有严格按照标定流程做镜头和工件的垂直度校正，导致图像边缘存在透视变形。另外，现场的日光灯导致部分区域光线变化，模型在训练时从未见过这种光照条件。
这件事之后，我们在所有项目里都把“现场环境标定”作为一个正式环节来管理，包括相机的内外参标定、光源亮度验证、环境光遮蔽。并且，每次采集新数据时都要在系统里记录当天的光照参数，保证训练数据和现场运行数据的环境条件可追溯。
5. 持续迭代与成本控制：从一次质检到工厂级智能化
视觉质检项目如果只是部署上线就结束了，那它只是一个“算法加上摄像头”的单点工具。真正能产生持续价值的，是它作为工业智能化数据入口的那部分潜力。
5.1 模型上线不是终点：Shadow部署与灰度更新
模型版本更新是最容易被轻视的环节。很多时候，算法工程师训练出一个新模型，直接覆盖部署到产线上。如果新模型的误检率比旧版本高，现场立刻就会出现批量的误报警，产线直接停掉，损失会非常大。
正确的做法是Shadow部署，也就是影子模式。新模型部署上去，但并不参与实际判定，而是把它的推理结果实时记录下来，和旧模型的结果做对比。只有当新模型的指标全面超过旧模型，再把它切换为正式判定模型。整个过程可以由SageMaker的模型监控和版本管理功能协助完成。
我在一个项目里就是用了一套脚本，自动把新模型的推理结果同步到DynamoDB，每天生成一份对比报告，连续跑了一周确认无误后才切换。这样能避免大多数因模型更新引起的产线异常。
5.2 训练/推理成本怎么压下来
云服务的成本是需要认真算的，视觉质检在这方面尤其明显，因为图像数据占用空间很大。训练侧的成本比较直观：GPU实例按小时计费，一次完整的训练在ml.g4dn.xlarge上通常几小时就够，成本几十美元，完全可控。推理侧的成本会因为在线推理和边缘推理的路径不同而有很大差异。
如果推理全部放在云端，每个工件都要传图、推理、返回结果，首先带宽压力大，其次按API调用次数算的钱也不便宜。所以我一般建议：正常品的判断尽量在边缘端完成，只有两种情况才上云——一是边缘端判定NG需要做二次确认，二是需要云端做统计分析。这样云端整体负载很小，成本就会控制在很低的水平。
存储侧的成本则是通过数据生命周期管理来优化。S3里可以设置规则，把超过一定时间且没有被标记为缺陷样本的原始图像，自动转移到Glacier归档存储。这个操作可以把存储成本降低80%以上。
5.3 从质检单点扩展到多工序协同
质检项目做顺手之后，很容易往“工厂级智能化”这个方向延展。这里最有价值的不是多加几个检测工位，而是把不同工位的检测数据串联起来，形成各工序的质量关联分析。
举一个实际例子：某产品在组装工位发现了划伤缺陷，传统思路是只拦截这个工位的不合格品。但如果把前道工序的质检数据也拉进来，可能就会发现，划伤缺陷高发的批次，恰好对应着注塑工位某台机器某个时段的数据。这个关联一旦建立，就可以追溯到源头去改善工艺，而不是靠末端拦截。AWS这边可以用DynamoDB存储检测记录，用Athena做SQL分析，再用QuickSight做可视化。整个过程不需要预置复杂的数据仓库，按量加载数据就能做分析。
我对“工业智能化”的理解是：它不是让AI替代每一道工序上的人，而是通过AI把原本散落在各处的信息连成一张网。视觉质检这个点，天然离产品最近，离质量数据最近，最适合作为这张网的起点。
最后再分享一个体会：项目做到最后，成功的关键往往不是模型精度有多高，而是流程、数据和人的配合度。模型精度这种东西，大家都能调到接近的水平，真正拉开差距的是数据管道是否顺畅、更新机制是否稳定、现场和算法团队之间能否高效沟通。所以如果你准备启动这类项目，别把精力全部花在模型调参上，花在流程设计和数据治理上的时间，回报率更高。
