做了快六年工业AI落地,经手的项目从汽车零部件、3C电子到重型装备都有,一个感受越来越强烈:国内制造企业踩过的AI坑,大多不是技术不行,而是从一开始就瞄错了方向。上整套大模型平台、搭大数据中台、买一堆GPU服务器,最后做成一个大屏看板,产线上该靠老师傅靠老师傅,该靠眼睛靠眼睛——这就是典型的花了智能化的钱,做了自动化的活。
我写这篇东西的初衷很简单:把工业AI落地从那种“汇报级、演示级”的怪圈里拽出来,回到它本来该有的样子——轻、快、准、便宜。所谓“工业AI 3.0”,不是什么新概念新平台,而是企业终于开始务实,不再追求大而全,转而追求每一分钱投入都能在产线上看到回报。这篇文章里我会把轻量化落地的完整思路、技术选型、实操步骤和踩坑记录都摊开讲,适合正在做智能制造转型评估的工厂技术负责人、做工业视觉和设备预测维护的工程师,以及在这个领域找切入点的创业者参考。
1. 先聊清楚:为什么大多数工业AI项目都在“表演智能化”
1.1 无效智能化的三个典型面孔
我在不少工厂看到过这样的“智能化成果”:会议室大屏上跳动着实时产量、设备OEE、质量SPC图表,数据确实在流动,但你只要在产线上待半天就会发现,老师傅依然靠肉眼判断工件表面瑕疵,维修班组依然凭经验判断哪台设备该保养,计划员依然用Excel排产。大屏上那些漂亮的曲线,没有一条真正干预过生产决策。这就是典型的演示级智能化。
第二种叫报表级智能化。工厂上了AI质检设备,检测精度确实到99.5%了,但缺陷图片没有回流到工艺部门做根因分析,检测结果没有联动到前面的加工参数,老师傅只需要在触摸屏上点“OK”“NG”就行。AI在这里扮演的不是智能体,而是一个高级传感器加一个确认按钮。
第三种是专家依赖型智能化。这种项目更隐蔽,算法模型是外部公司“黑盒交付”的,调试的时候外部工程师驻场一切正常,人一走模型准确率就跌;更麻烦的是,模型为什么误判、怎么调阈值、怎么增量学习,工厂内部没人懂。结果就是每年花一笔不低的维护费,请人回来“看看”。这三种面孔背后的共同点,是用AI的噱头替代了管理的改进,用项目的交付替代了能力的沉淀。
我判断一个智能化项目是不是“无效”,有个很土的标准:投产后三个月,产线工人有没有因为这套系统改变哪怕一个操作习惯。如果没有,那这项目在技术再漂亮,在经营层面也是失败的。
1.2 制造业的真实家底:三座绕不开的山
要说轻量化之前,我们得先看清制造业的真实家底。很多AI公司方案卖不动,根子就在于用互联网的逻辑做工业生意。制造业普遍存在三座山。
第一座是算力山。汽车工厂单条焊装线每天产生的过程数据几十个GB,但车间机房的算力可能就几台工作站,专用GPU服务器更是奢侈品。指望每个工厂都建一个上千卡集群的智算中心,这不现实也没必要。第二座是数据山。设备通讯协议五花八门,老旧机床连网口都没有,数据采全本身都是巨大工程,更不要说数据质量——工业数据脏、乱、缺是常态,你跑出来的模型自然不可靠。第三座是人才山,工厂里最懂工艺的老师傅不懂AI,AI工程师又不懂工艺,两者之间隔着一条巨大的鸿沟。
所以你会发现,凡是能在中小企业真正落地跑起来的AI项目,几乎都有一个共同特征:克制的数据需求、便宜的计算资源、闭环的小场景。这不是妥协,这是工业现场的客观规律决定的。
1.3 判断该不该上AI的三道关卡
并不是所有产线问题都值得上AI,有时候换个传感器、调一下工艺参数,效果比AI好十倍。我给自己定了一套判断关卡:
第一关:这个问题是不是高频且重复的?老师傅一天要看5000个零件、巡检工人要在嘈杂环境里听设备异响、质检员要数一箱里有没有漏装——这种高频重复、靠人眼和人耳经验判断的活,就是AI的天然场景。反过来,一个月才发生一次的设备故障,就别费劲训练模型了。
第二关:有没有稳定、可获取的数据信号?AI本质上是从历史数据里找规律,数据都不全,再牛的算法也白搭。先盘一下:这个场景有没有数据?数据能不能自动采集?采集上来的数据能不能对应到结果标签?三连问下来,能筛掉一半的伪需求。
第三关:判断结果能不能闭环产生动作?这里要特别强调闭环。所谓闭环,就是AI输出一个结果之后,系统能自动触发一个动作,而不是让人再去操作一遍。检测到缺陷能自动剔除并报警、预测到设备异常能自动生成维修工单、识别到违规操作能自动锁定设备——这些是闭环。如果AI判断完结果只是存数据库里供人查看,那这个项目大概率走不远。
2. 工业AI3.0的本质:轻量化不是阉割,是回归工具属性
2.1 轻量化到底轻在哪三层
很多人一提轻量化,第一反应是模型轻量化,把70B的大模型蒸馏成7B、把YOLO从v8换到v5,这是最表层的理解。真正的轻量化其实是三层叠加:
第一层是模型轻。模型的参数量、计算量要适配工业现场的算力条件。能用CPU跑的不用GPU,能边缘跑的坚决不上云。一个风机动平衡预测模型,在普通工控机上推理只要20毫秒,就没必要去租云端GPU。这一层的技术核心是量化、剪枝和知识蒸馏。
第二层是系统轻。这个很多团队容易忽略。工业AI的系统架构应该像瑞士军刀,而不是瑞士手表。别一上来就设计十几个微服务、搞数据中台、搞消息队列,一个单机服务加一个数据库能解决的问题,就不要引入K8s和Kafka。系统轻的本质是降低运维成本和故障恢复时间。工厂IT就两三个人,你给他搞一堆容器编排,出了问题没人会弄,最终还是被抛弃。
第三层是流程轻。AI落地要嵌入现有业务流程的最小闭环,而不是再造一套流程。我见过一个工厂上智能排产系统,结果要求计划员每天先把系统里跑出来的计划手工录入ERP——这种就是流程没打通,额外增加了两倍工作量。轻量化的落地流程应该是:识别一个具体的工艺痛点,找到某个环节可以自动决策,让AI替人做这个决策,然后慢慢扩展边界。
2.2 选开源协议还是商业闭源:一个被忽视的关键决策
做工业AI落地选型的时候,开源和闭源之争往往是最后一个被想起来的问题,但这个决策一旦做错,后期非常被动。选开源模型和框架,比如PyTorch、ONNX Runtime、OpenVINO、YOLO系列,最大的好处不只是省license费用,而是可控性——工厂的工程师可以打开源码定位问题,可以拿着模型文件到任何一台机器上部署,数据完全留在本地,不依赖供应商。对制造业这种普遍追求长周期稳定运行的环境来说,这种“可掌控感”非常关键。
商业闭源方案则强在开箱即用和技术支持。如果你的场景特别冷门、算法能力又弱的小团队,买商业软件的省心程度确实高。但一定要在合同里盯死几个条款:模型是否本地化部署?数据是否仅存本地?如果供应商倒闭了,模型还能不能继续运行?我见过不止一个工厂被SaaS模式绑死,网络一断检测系统直接瘫痪。
我的建议很简单:能用开源解决的就尽量用开源,商业闭源只买“开源做不了”的部分。在工业AI这种强定制、强私有化的场景里,掌握代码和模型的所有权,等于掌握了后续迭代的主动权。
2.3 和传统MES、ERP的关系:AI是插件不是平台
制造企业最不缺的就是系统:ERP、MES、APS、WMS、SCADA,五花八门。很多AI厂商上来就提“打通ERP和MES数据,构建企业级AI中台”,一听这个我基本就知道这项目要黄。为什么?因为传统软件是流程固化的工具,AI是预测和感知的工具,两者定位完全不同。
轻量化的做法是把AI当作一个服务插件,挂在现有系统的边缘。比如一个设备预测维护模块,它只需要从SCADA或者PLC读到振动和温度数据,跑完模型之后把结果以标准接口推给MES生成工单就行。你们之前用什么系统根本不需要动,只需要加一个小服务、开一个接口。这种“寄生式”的落地方式最大的好处是风险低——AI项目失败了对原有系统零影响,工厂决策层的心理负担小,反而更容易推进。
具体到技术架构上,我不建议一开始就引入ESB企业服务总线或者API网关这类重量级中间件。一个WebSocket接口或者MQTT消息,基本就能覆盖80%的对接场景。等以后场景多了、接口多了,再逐步引入更规范的接口管理体系,才是顺其自然的演进路径。
3. 落地实操:从一条产线开始的轻量化AI改造
3.1 第一步:选场景、定边界
我反复跟企业强调一句话:AI落地最忌一口吃成胖子。选择第一个场景,要同时满足三个条件:一是痛点足够痛,老板和车间主任一提起来就头疼;二是数据相对容易获取,不需要大动干戈改造设备;三是价值可以量化,比如良率提升一个点、停机时间减少百分之十、人工成本省两个人,这样项目做完可以算账。
从我的经验来看,最适合做“第一个轻量AI项目”的三大场景是:视觉外观缺陷检测、设备预测性维护、操作行为合规识别。这三个场景都有共同特点:感知对象明确(图像、振动、视频)、判断逻辑相对固定、决策动作简单(剔废、报修、报警),非常适合用轻量化模型快速跑通。
边界划定同样重要。缺陷检测就聚焦某一种缺陷类型,哪怕这种缺陷只占全部缺陷的60%,也先做起来;预测维护就先看某一个工位的一台关键设备,用最低成本验证技术可行性。范围缩得越小,项目阻力越小,反而越容易出成果。
3.2 数据收集与标注:0到1的最小数据集
轻量化项目在数据上最大的误区是“等数据攒够了再动手”。工业现场的数据永远攒不够,正确的做法是边跑边攒。以缺陷检测为例,第一条规则是优先收集缺陷样本,而不是追求总量。正常品图片几百张就够训练,难的是那几百张缺陷图。我见过一个团队花了三个月想收集一万张完整数据集,最后连500张缺陷样本都凑不齐。正确做法是先有500张着手训练,部署到产线试运行,靠系统自动筛选异常样本再补标注,两周就能超越手工收集半年的效果。
关于标注,轻量化项目我自己摸索出来的经验是要建立“像素级细化+整图级分类”两层标注体系。第一层用多边形或者掩膜把缺陷区域画出来,供检测模型学习位置和边界信息;第二层给整张图打标签,供分类模型判断哪个区域的缺陷属于什么类型。两层都做的好处是模型换型的时候你不用重新标注全部数据。
另外要专门提醒标注的一致性问题。同一类缺陷,不同标注员画出来的框可能差很多,甚至同一标注员前后标准都可能漂移。我的建议是最开始由项目负责人和最有经验的工艺工程师一起标注前50张图,定下标准后其他人照着执行,并且每周抽检标注质量。数据质量直接决定模型上限,这个功夫省不得。
3.3 模型选型:从YOLO到轻量级大模型,别被参数带偏
模型选型是很多工程师最容易纠结的环节,其实你只需把握一条原则:模型大小和效果之间永远在tradeoff,工业场景优先选经过大规模验证的成熟模型。视觉任务,目标检测从经典YOLO系列到最新的YOLO26系列,每一代都在精度和速度之间做平衡,部署生态非常成熟,网上案例多、问题容易被搜索到,这是工业落地最在意的因素。
值得注意的是,近两年轻量化的一个明显趋势是Transformer架构开始和卷积神经网络融合。一些轻量级检测算法在保持CNN的高效推理特性的同时,引入了Transformer的自注意力机制,能更好地捕捉全局特征,应对复杂背景下的目标检测明显更从容。比如在铸造件表面缺陷检测里,有的缺陷区域小且对比度低,纯CNN容易漏检,混合架构的效果会更好。但如果你的场景是相对简单和稳定的(例如传送带上的零件有无判断),那老牌的YOLO照样够用,没必要追新。
至于现在火热的工业大模型,我的建议是把它当“大脑”而不是“眼睛”。具体说:用轻量级视觉模型做高速感知判断,用大模型做异常样本的事后理解和报告生成。比如一个装配检测场景,视觉模型0.1秒内判断错装漏装,大模型则根据视觉模型输出的结构化信息,生成一份中文描述的问题报告发到班组群。这样既控制了计算成本,又享受了大模型的理解与生成能力,这才是现阶段工业AI实际可用的组合方式。
3.4 部署方式:边缘盒子、工控机还是云边协同
模型训练好之后,放在哪里跑,这是个必须认真对待的现实问题。我在项目里会按计算量和实时性要求做决策:
单路或者双路视频流且要求毫秒级响应,直接上边缘计算盒子。市面上成熟的边缘盒子有几十上百种,算力在几TOPS到几十TOPS之间,功耗控制在10W以内,可以直接挂在工业相机旁边取电运行。这类设备胜在便宜、零维护、现场部署灵活,是缺陷检测场景的默认选择。
如果场景需要3路以上视频流处理,或者除了AI推理还有设备数据采集、历史存储等任务,边缘盒子就会吃力,建议用高性能工控机。工控机的好处是扩展性强,可以插多张加速卡、加内存和硬盘,能同时跑多个模型,还能兼任边缘服务器。部署的时候把推理、存储、通信模块做成Docker容器,方便以后按需迁移。
云边协同则是那种既有实时判断又有趋势分析的场景:边缘负责实时推理,云端负责模型迭代和样本汇总。但这套架构对企业的IT基础要求较高,轻量化项目初期不建议上。先跑单机边缘版本,等积累足够多的数据样本和真实运行经验之后,再逐步引入云端,是更稳妥的路径。
3.5 实操案例:机械装备行业的AI+数字孪生+机器人协同
机械装备制造是工业AI落地很有代表性的领域,受限于离散制造工件种类多、批量小、自动化程度参差不齐的特点,传统方案很难标准化。这几年我们看到的一条可行路径,是“AI+数字孪生+机器人”的结合。具体逻辑是这样:用机器视觉识别工件的类型和位置,通过数字孪生模型实时计算抓取路径和干涉检测再驱动机械臂执行上下料或分拣动作,整个流程里AI负责“看”,数字孪生负责“算”,机器人负责“做”。
在轻量化框架下,这个组合不需要一上来就搭建完整的三维产线数字孪生车间。一个实用的轻量方案是:只对机器人工作单元(一个工位)构建数字孪生模型,用于路径规划和碰撞检测;视觉模型只识别工件的关键特征点和抓取中心,不追求完整的六自由度位姿估计。这样一个典型的上料工位改造,硬件成本可以控制在几万元以内,视觉识别算力靠一个边缘盒子就能带起来,模型也能在两周之内训练迭代到可用的状态。
我曾经跟进的一个机械加工车间做的小型柔性上下料单元,就是这么落地的。原来的机器人只会执行固定轨迹,工件稍有偏移就会抓空或碰撞,后来加了轻量视觉定位和孪生模型进行轨迹复核,抓取成功率从90.5%提到99.2%,整个改造周期不到一个月。这个案例经常被我拿来说明一个观点:轻量化的核心不是技术新颖,而是把合适的技术组合用到刀刃上。
4. 关键环节实现:一个缺陷检测项目的完整技术拆解
4.1 从零搭建轻量缺陷检测系统
这一章我拿一个真实的冲压件外观缺陷检测项目来拆解,把从数据到上线的每个环节都摆出来,方便你对照落地。
首先是相机和光照选型。工业视觉圈有句话叫“打光打得好,算法省一半”,非常真实。冲压件表面缺陷分为三大类:划痕、凹坑、毛刺。划痕方向不定,凹坑反光特性独特,毛刺则是边缘突起。针对不同缺陷要设计不同的打光角度:低角度环形光能突出划痕和凹坑的轮廓,同轴光适合检测镜面区域的细微变化。我的习惯是先在实验室用几组不同光源反复对比,选定最合适的打光方案再固定相机机位,而不是直接拿一个普通摄像头去现场硬拍。
相机分辨率需要根据检测精度反推。假设工件大小是100mm×100mm,要检测的最小缺陷是0.2mm,那么一个像素要覆盖0.1mm才能可靠检出,算下来至少需要1000×1000=100万像素。再加上边缘计算量、帧率要求和成本因素,我常用的是200万~500万像素的工业相机。这里要注意,并不是分辨率越高越好,分辨率越高数据量越大,推理速度会受影响,系统成本也跟着上涨。
4.2 模型结构:从数据集到第一版可用模型
数据集准备好以后,模型训练的第一步是先分数据集。我的实践做法是按缺陷类型而不是按图片数量来划分训练集、验证集和测试集,保证每种缺陷在测试集都有样本,避免出现“模型对某种缺陷泛化很好,对另一种几乎全瞎”的假阳性。按8:1:1的比例划分,但缺陷样本少的类型要重点保证能被分到训练集和验证集。
模型结构选择上,我最常用的是YOLO系列加一个分类头的变体。检测头负责输出缺陷的位置和类别,分类头负责对检测结果做二次确认,降低误检率。前面提到的CNN+Transformer混合架构在这里有独特优势:冲压件表面的划痕常常呈现细长条状且分布随机,自注意力机制可以捕捉划痕的全局上下文,避免由于划痕不连续特征而造成的漏检。模型输入分辨率我一般都设置在640×640,这分辨率在检测小目标和推理速度之间比较均衡。
第一个版本训练完,不要急着改网络结构,先看错误案例。把所有误判和漏判图片打印出来贴上墙,拉着质检老师傅一个个看,让老师傅告诉你错在哪里。很多时候你会发现,问题不在模型精度,而在数据标注本身有歧义,或者某个背景区域长得就像缺陷。把这些错误案例补进训练集重训一版,效果往往比调任何参数都明显。
4.3 训练与部署优化:蒸馏、量化、加速一整套
模型在GPU上训练好之后,离产线部署还差关键一步:推理优化。工业现场没有A100,常见的计算设备是Jetson盒子或普通工控机CPU,所以必须做模型压缩。
第一步是知识蒸馏。如果你手上有一个大模型(比如YOLO系列里的大尺寸版本)在同样数据上精度不错,可以用它作为教师模型,把小模型作为学生模型去模仿大模型的输出。论文实验里轻量级检测算法融合CNN和Transformer的训练,往往都借鉴蒸馏技巧,能让学生在保持少参数量的同时学到教师的泛化能力。我用YOLOv8m蒸馏YOLOv8n的实践表明,学生模型的mAP能提升2到5个百分点,这已经是很可观的了。
第二步是量化。把模型权重从FP32降到INT8,模型体积和推理延迟都能大幅下降,缺点是精度有轻微损失。我的建议是做量化感知训练,在训练时就模拟量化误差,这样测试时精度损失通常能控制在1%以内。主流推理引擎TensorRT和OpenVINO都提供成熟的量化工具,照文档做即可。
第三步是推理引擎优化。我常用的组合是:英伟达GPU平台用TensorRT,Intel CPU平台用OpenVINO,ARM平台用ONNX Runtime加RKNN。同一模型在这几个框架下的推理速度差距可以达到数倍,选对了引擎等于免费获得一次性能升级。
我拿一个具体的参数表来说明优化后的收益:
| 阶段 | 模型体积 | 推理延迟(单张640图) | 精度(mAP) |
|---|---|---|---|
| 原始FP32 | 45MB | 42ms | 0.912 |
| 知识蒸馏后 | 42MB(结构不变) | 41ms | 0.934 |
| INT8量化后 | 11MB | 18ms | 0.925 |
| TensorRT优化 | 11MB | 9ms | 0.925 |
可以看到,通过蒸馏、量化、加速三步组合,推理速度提升了4倍以上,模型体积压缩到原来的四分之一,精度反而还有微小提升。这也是我为什么一直坚持:轻量化不是牺牲效果,而是把冗余算力挤干净。
4.4 上线后的持续迭代与告警闭环
模型部署上线只是起点,真正的工业AI项目是持续运营的过程。上线后要注意的几件事:
数据回流机制不能少。所有模型判断“不确定”的样本,都要自动存下来供后续标注和再训练。我做的系统里设了一个“人工复核队列”,如果模型输出的置信度在0.5到0.8之间,就把图片推送到检测工位的触摸屏上让人工确认。这个机制既保证了产线的误判率可控,又为模型迭代积累了最难能可贵的边界样本。
告警闭环要连到具体的责任人。模型检测到连续三个缺陷,不仅要在屏幕上报警,还要通过企业微信或者短信通知到当班的质量工程师,并自动触发停线或者批次隔离动作。这里有一个小心得:告警信息里要附上缺陷图片和位置坐标,让工程师不用跑到产线就能初步判断问题源头,这种效率提升在多层级的工厂里尤其明显。
关于模型更新频率,我的建议是:轻量模型不是“训练一次用一年”,而是“每周用上周的积累数据做增量微调”。你可以把训练脚本和自动标注流程做成流水线,每周五晚上自动跑一轮,周一现场就有新模型可用。这样模型会随着产线工艺变化始终保持新鲜度,而不是半年之后变成一块废铁。
5. 工具选型、团队配置与投入产出测算
5.1 工具链清单:开源为主,按需组合
结合这些年上手过的项目,我整理了一份轻量化工业AI落地常用工具链,可直接作为选型参考:
| 类别 | 推荐工具 | 选择理由 |
|---|---|---|
| 模型训练框架 | PyTorch | 生态最成熟,算法更新最快,社区案例多 |
| 检测算法 | YOLO系列(v8/v11/最新版) | 部署生态完善,预训练模型丰富 |
| 模型转换 | ONNX | 打通训练框架和推理引擎的通用中间格式 |
| 推理加速 | TensorRT / OpenVINO / RKNN | 分别覆盖NVIDIA GPU、Intel CPU/核显、RK芯片 |
| 边缘计算设备 | Jetson Orin Nano / 工业边缘盒子 | 性能与功耗平衡,配套软件完善 |
| 数据标注 | LabelImg / X-AnyLabeling | 免费开源,支持多种标注格式 |
| 部署方式 | Docker + docker-compose | 环境隔离,工厂运维友好,升级回滚简单 |
| 温湿度/振动采集 | Modbus / OPC UA | 工业设备数据接入的标准协议 |
这套工具链有几个共同特点:全部免费或低成本、生态活跃、中文社区资料丰富。对于绝大多数制造业场景,这套组合已经能覆盖从训练到部署的全流程,不需要再购买任何昂贵授权。
5.2 人才配置:不一定要养一支AI算法团队
中小企业最头疼的是人才。我的建议是:第一阶段的轻量化项目,不需要成立AI算法团队。你只需要两类人:一个懂工艺的工程师,负责提需求、标数据、验收效果;一个会Python和基础的PyTorch/Docker操作的软件工程师,负责训练脚本和部署运维。这两个人可以是兼职,项目跑起来之后再逐步培养。
整个训练和调优环节,可以依托已经成熟的预训练模型做微调,不需要从零设计网络结构。而数据、现场协调、效果分析这些真正决定项目成败的工作,工厂自己的人参与得越深越好——尤其工艺工程师对缺陷的理解、对误判容忍度的把握,是外部算法工程师短期内无法替代的。
如果实在没有适合的内部人选,也可以找外部团队做技术交付,但要把“知识转移”作为硬性交付物写进合同。具体来说要有:模型源码、训练数据、训练脚本、部署手册、二次开发文档,并且在项目结束前安排一轮内部工程师的培训,确保你离开外部团队也能独立完成微调、更新和问题排查。否则,项目交付那天就是你失去控制权的开始。
5.3 ROI怎么算:把账算到车间主任心坎里
一个AI项目能不能推进,很大程度取决于你算不算得清账。我计算ROI的公式很简单:年收益 = 节省人工成本 + 良率提升带来的收益 + 停机损失减少 + 能耗节约,项目总投入 = 一次性硬件和开发费用 + 每年运维费用。然后算出回收期。
拿一个五台CNC设备的预测维护项目举例。假设没有上系统之前,平均每年每台设备发生两次非计划停机,每次停机4小时,停机损失每小时1200元,每年损失就是5×2×4×1200=48000元。加上紧急维修比计划维修多花的费用,每年多支出约3万元。也就是说这个项目每年可避免损失约七八万元。项目投入如果是一套传感器加边缘计算加开发费用合计10万元,回收周期大约一年半。
这个账算给车间主任和财务看,既有数字又有逻辑,比讲一百遍“智能制造趋势”有效得多。这也是我强调“轻量化”的原因:不是大而全的智能化没有价值,而是对绝大多数制造企业来说,先算清这笔账、用最小成本跑通一个闭环,比愿景宏大但落地遥遥无期的方案重要得多。
6. 常见问题与避坑指南(现场踩坑实录)
6.1 数据标注翻车:一次“提纯”带来的教训
有次一个项目甲方满怀信心地给了我们两万张标注好的图片,说“数据量够大了”。结果训练出来的模型在产线上一测,准确率比预想低了将近10个点。排查后发现,这两万张图里有近三成是重复的(同一工件不同角度拍了多次),还有一成是把“疑似缺陷”全部标成了真实缺陷,标注框更是五花八门:有人把整个划痕区域打了个大框,有人只框了划痕最严重的一段。
这次之后我定了条铁律:训练数据必须经过“去重+标准复核”两道工序才能进模型。去重不是简单删除文件名重复的图片,而是对图片做感知哈希或者特征向量的相似度计算,把内容重复率超过九成的归一组。标准复核则是拉上标注意见最不一致的几百条数据,请工艺工程师做最终判定并统一标注口径。数据集的“纯度”永远比“体量”重要,这个观念一定要刻在脑子里。
6.2 模型在实验室跑得好,产线上一团糟
这是所有工业AI项目里最常见的翻车现场。原因无非四条:现场光照变了、相机角度歪了、来料批次变了、环境背景不一样了。实验室里用恒定光源拍的图,跟产线上日光灯频闪加自然光干扰的实拍图,分布差异能大到模型崩溃。
我的经验是做两件事:第一,数据收集的第一步就直接在产线上装相机,用真实环境的光照和角度去拍,宁可实验室阶段脏一点糙一点,也不要“太干净”的数据。第二,部署前做一个简单的“数据分布体检”——把现场实时采集的图片和训练集图片做一个特征分布的可视化对比,如果两者重叠度低,就说明环境变量跑偏了,需要先调整数据而不是硬上线。这两个动作能避开大概七成“实验到现场失效”的问题。
6.3 产线网络抖动,整套系统跟着瘫痪
有个做质检的项目,因为工厂车间网络质量差,设备端把图像传到云端推理,来回延迟达到几秒,产线节拍根本等不起。更致命的是断网之后整个检测环节直接卡死,质检员只能靠人工肉眼顶班。这个问题暴露出一个架构性缺陷——过度依赖中心化推理。
解决思路很简单:把推理搬到边缘,网络只用于结果上报和模型更新。我在之前的项目里推广过一个“边缘优先”原则:所有实时推理均需在边缘设备完成,网络断了系统照常运行,只是暂时无法上报数据;云端断线重连后自动补传。这套架构让系统的弱网韧性大幅提升,至今仍是交付标准之一。
6.4 老板就想看大屏Dashboard,怎么办
老板看大屏、看驾驶舱这事本身没有错,管理层需要直观了解产线状态。但问题是很多项目把大屏当成了最终交付物,AI的结果只是为了喂给好看的图表,这就本末倒置了。
我的处理模式是:第一步,先把AI系统的闭环动作做扎实——检测、报警、联动停线、自动生成工单,这些实际控制功能是里子;第二步,在此基础上做一个精简的管理驾驶舱,显示核心KPI(检测量、缺陷率、误报率、模型迭代次数),用于给管理层汇报;第三步,驾驶舱里的每个数字,都要支持一键下钻到具体的缺陷图片和处理记录。有里子才有面子,次序千万不能反。大屏做得再炫,下钻后颗粒无收,管理者看两周就会失去兴趣。
6.5 常见问题速查表
| 现场表现 | 可能原因 | 快速排查与对策 |
|---|---|---|
| 模型漏检多 | 缺陷样本太少或标注不一致 | 收集真实缺陷样本,统一标注标准,补充困难样本 |
| 误报率高 | 背景复杂、光照变化大 | 增加负样本,调整置信度阈值,优化打光方案 |
| 推理速度比预期慢 | 未做量化或推理引擎选型不对 | INT8量化,按硬件平台换TensorRT/OpenVINO |
| 断网后系统不可用 | 推理放在云端 | 推理切到边缘设备,网络只负责上报 |
| 现场识别准确率持续下降 | 环境漂移或来料批次变化 | 用增量微调,每周自动更新模型 |
| 项目验收后没人维护 | 内部团队没有接手能力 | 交付时必须含源码、文档和培训,签知识转移协议 |
写在最后
我个人在实际操作中最深的一点体会是:工业AI轻量化落地,技术的门槛从来不是最高的门槛,最难的是克制。克制住什么都想用大模型解决的冲动,克制住一张大屏展示宏大叙事的冲动,克制住一上来就搞中台、搞平台的冲动。把AI当成一个拿着一把称手小刀的老师傅,哪里痛就切哪里,切完让人看见切实的好处,再往下一个痛点推进,这种节奏才是制造业真正能消化的节奏。
最后再分享一个小技巧:开始任何轻量化AI项目之前,先问自己一句话——“如果明天这个AI模块被撤掉,产线会不会有人觉得不方便?”如果答案是不会,那说明它还没有真正长在流程里,项目还需要继续打磨嵌入的深度。等哪天老师傅主动跟你说“这个东西现在离不开”,恭喜你,这才是真正的落地。