产线质检这个事在制造业待久了的人都清楚它从来不只是技术问题更是成本问题。我们车间原来靠人工目检两个人盯一台设备一天下来眼睛酸得不行漏检率还压不下去。后来评估过商用质检软件报价一出来直接把人劝退了。最后决定自己搭一套开源私有化AI质检系统数据不出厂模型自己训成本大约是商用方案的一个零头。这套系统现在已经稳定跑了八个多月今天把从选型到上线的全过程复盘一遍给正在评估自建质检系统的同行做个参考。1. 为什么一定要走私有化这条路1.1 传统质检方式到底卡在哪先说人工目检。产线上最常见的场景是产品从流水线流过来工人盯着屏幕或者用放大镜看外观判断有没有划伤、脏污、缺件。人眼的问题不是看不准而是不稳定。一个工人在上午十点和下午三点状态完全不一样连续盯两小时后漏检率会明显上升。工厂为了控漏检只能堆人一条线放两个人还要定时轮换人力成本就这么上去了。再说传统机器视觉。用规则去判断缺陷比如设定灰度阈值检测划痕、用边缘检测查轮廓。这类方案在单一场景、光照稳定的前提下表现还行但一旦产品换型、光照变化、缺陷形态复杂规则就崩了。我们之前上一套国产视觉检测设备调试工程师驻场一个月调了一百多个参数换型号就要重新调运维成本极高。核心问题是传统视觉只能回答和模板差多少回答不了这个差算是哪种缺陷、严不严重。1.2 云服务方案为什么落不了地很多AI质检厂商主推云服务模式摄像头采集图片上传到云端云端模型推理返回结果。听起来很美好但在工厂实际环境里这条路普遍走不通。原因很简单。第一产品图片是制造工艺的直接体现属于核心生产数据。很多产品的外观、结构、瑕疵特征外人是能反推出工艺参数的。你把图片传到外部服务器数据安全关首先就过不了。我们当初对接某云厂商的方案时对方把数据流向画了个示意图老板看了一眼就否了。第二工厂网络环境普遍不稳定车间里金属结构多、干扰大实时检测对网络延迟极其敏感一旦断网整个工位就停摆。第三合规层面不少行业对生产数据存储有明确要求数据本地化是硬约束。1.3 开源私有化方案的优势在哪自己搭一套私有化AI质检系统核心价值是三件事数据不出厂、成本可控、能力可沉淀。数据不出厂是底线。图片在本地采集、本地存储、本地推理外网断开都不影响运行。模型在本地训练训练用到的数据也全部留在厂内。成本可控体现在两个层面。一是软件许可商用AI质检系统通常按工位收费单工位报价动辄几十万还要收年度维护费开源方案只花硬件和人力成本没有License费用。二是定制开发开源方案所有代码可控想加功能自己改不用等厂商排期。还有一个容易被忽视的点能力沉淀。商用方案是个黑盒子你永远不知道模型为什么误判。自建方案从数据处理到模型训练全部自己掌握时间越长积累的样本和调参经验越值钱这是任何外购方案都给不了的。2. 系统整体架构与选型决策2.1 一套完整系统包含哪些部分先明确一个概念AI质检不只是训练一个模型它是从图像采集到结果反馈的完整链路。我们最终落地的架构分五层图像采集层工业相机、镜头、光源、光电传感器。负责在产线上稳定拍到清晰、标准化的图片。边缘计算层一台工控机或小型GPU设备部署推理服务实时接收图片并输出检测结果。模型训练层一台带GPU的训练服务器负责数据标注、模型训练、版本管理。业务集成层检测结果回传产线控制系统PLC执行剔除动作同时上报MES记录质量数据。监控管理层Web看板展示实时检测状态、缺陷统计、模型运行日志。这套架构最关键在于采集和推理解耦。相机拍到图后先写入本地队列推理服务从队列取图处理而不是让相机直接阻塞等待模型返回。这样相机帧率再高也不会把推理服务拖死。2.2 检测模型的选型逻辑模型选型看的是任务类型。质检场景无非三类缺陷检测、分类、字符识别。缺陷检测划伤、脏污、缺料用目标检测模型能同时定位缺陷位置和类别。我们的场景用的是YOLO系列单阶段检测算法速度和精度平衡比较好。单阶段检测模型不像两阶段模型那样分两步走而是直接回归出目标框和类别推理速度快适合产线实时场景。分类任务比如按外观等级分A/B/C类用轻量级分类网络。如果只是按整张图判定合格/不合格MobileNet这类轻量结构就够了几百兆的模型跟几十兆的模型在单张图上差距不大但部署和更新轻便得多。字符识别用来读产品表面的批次号、日期码。这部分可以用OCR开源方案但在我们的实际需求里产品型号是固定的只需要读位置固定的几个字符数据量不大训练成本也低。选型时容易犯的错是盲目追求大模型。工业质检场景往往缺陷类别只有五六种样本量就几千张超大模型的收益微乎其微反而推理慢、显存占用高。我们的经验是模型参数量能解决任务的80%就好剩下的靠数据和调试补。2.3 硬件配置与预算估算硬件是私有化方案里最大的一笔硬支出但相比商用方案仍然便宜很多。我们按两个检测工位加一套训练环境来估算硬件项配置参考单价约训练服务器GPU24GB显存级显卡搭配64GB内存、2TB NVMe3-4万推理设备工业级小型GPU工控机单卡1.5-2万/台工业相机500万像素全局快门千兆网口0.3-0.6万/支镜头定焦工业镜头按工作距离选型0.2-0.5万/支光源LED环形光/条形光加控制器0.2-0.4万/套配套工控机无GPU版本负责采集和IO控制0.5-1万/台光源看着不起眼实际是最值得花钱的地方。同样的相机和模型打光方案对不对准确率能差好几个点。我们后来总结的经验是表面划伤用低角度条形光让划痕产生明暗对比检测脏污和异色用环形光均匀照亮整个表面镜面材质得加偏振片消除反光。这个钱不能省。3. 数据采集、标注与模型训练实战3.1 数据采集决定成败的第一步模型效果的上限在数据不在算法。这句做AI的人常说的话在工厂里特别真实。数据采集踩过的坑能写满一页纸。第一样本量。每个缺陷类别最好累计到2000张以上越常见的缺陷类别越要堆样本。太少的话模型容易把缺陷特征和背景特征学混。我们第一批数据里划伤只有300多张训练出来的模型把正常的料纹也判定成划伤误报率直接爆表后来补到2500张才稳定。第二采集环境要和产线一致。很多团队图省事把产品搬到实验室拍照结果实验室光线均匀、背景干净产线上光照杂散、背景复杂部署后模型完全不认。正确的做法是在产线现场离线采集用实际的工作距离、光源条件和背景按产线节拍拍图。第三缺陷样本不能只从废品堆里找。废品堆里的样本往往缺陷严重、形态典型但产线上真正要抓的是那些刚好要判废的边缘缺陷。只拿重缺陷训练出来的模型对轻微缺陷不敏感这正是漏检的主要来源。我们后来在产线上特意蹲了三天专门收集外观可疑但还没被判废的样本。3.2 标注规范与质量控制标注这件事做得快的团队三天干完做对的团队要做三周甚至更久。规范比速度更重要。缺陷框的标注要定义到像素级的共识。比如划伤的长度到什么程度算缺陷是任意长度都算还是超过几毫米才算如果不提前定清楚两个人标注同一个图边界画得都不一样模型学到的就是矛盾的标注。我们的做法是写一页《标注规范SOP》配典型样例图标注前先让所有人做一致性测试偏差超过5%的重新培训。标注质量还要有抽查机制。每批次标注完成后抽取10%由质检工程师复核。我们遇到过标注员把胶水残留标成脏污的情况几十张图标错模型训练出来就多了一个错误类别认知。这类问题如果不复核后边排查起来极其痛苦。格式上标注工具导出为通用检测格式即可。YOLO格式的好处是每个目标一行类别ID加归一化坐标后面转训练集时处理方便。数据的目录组织也要提前规划按缺陷类别分目录每个目录下原始图和标注文件一一对应训练脚本只需要读一遍目录就知道数据集全貌。3.3 训练配置与调参经验训练环节最核心的工作是在正确的数据上做正确的实验而不是盲目堆算力。我们的训练配置供参考输入尺寸640×640兼顾小目标缺陷的检测能力与推理速度预训练权重用公开数据集预训练的权重做迁移学习初始化训练轮数150轮配合早停机制验证集指标连续20轮不涨就停批大小16显存不够时降到8优先保证模型能正常收敛优化器与学习率常用优化器配余弦退火调度初始学习率大约在0.01量级具体看框架默认值再微调数据增强要克制。像随机翻转这类增强对很多工业场景是毒药——产品的缺陷方向是固定的纹理方向也有规律你水平翻转一下把原本不存在的缺陷形态硬造出来模型反而被误导。我们最后只保留了亮度扰动、轻微缩放和局部遮挡模拟效果明显提升。调参最大的经验是先解决欠拟合再谈过拟合。如果训练集loss都降不下去先检查数据本身——标注有没有错、类别是不是不均衡、图片有没有花屏。我们有一次模型训练loss居高不下查到最后是某批图片在传输过程中损坏文件打开正常但内容偏色模型被这批脏数据干扰了。4. 推理服务部署与产线集成4.1 模型导出与推理优化模型训练完成的产物要经过导出、转换、优化三个步骤才能进入推理环境。这一步很多团队忽略导致训练好好的模型部署后速度掉一半。先把训练权重导出成跨框架通用模型格式再做推理优化。我们的做法是导出后开启FP16半精度推理单张图推理时间从25毫秒降到15毫秒左右。显存占用也下降明显。如果追求更极致可以尝试进一步的编译优化但要注意和生产环境兼容性我们在某个版本的驱动上踩过坑编译优化后的引擎检测结果异常折腾两天排查最后回退到半精度方案才稳定。模型的量化要谨慎。INT8量化能把模型再压缩一半推理更快但对小目标缺陷和低对比度划伤这类场景量化后的精度损失往往不可接受。我们的经验是先跑FP16如果延迟满足产线节拍就不要碰量化。4.2 推理服务架构设计推理服务是整条链路的承压点设计原则是异步、队列、监控。我们最终用的是HTTP服务加消息队列的架构。相机触发拍照后图像写入本地临时目录同时往队列里推送一条任务消息推理服务从队列取任务加载图片预处理推理返回结果。这样做的原因是相机触发的频率可能短时间突发而GPU推理是串行的直接同步调用必然导致图像堆积和服务崩溃。加一个削峰填谷的队列后哪怕一秒来30张图处理不过来也只是排队不会丢图。批处理是提升GPU利用率的关键手段。GPU擅长并行计算单张推理时大部分计算单元在空转。我们实现了一个简单的批收集器攒够8张图或者等待20毫秒就把这一批一起送进模型推理。实测吞吐量提升了接近三倍。代价是单张图延迟增加几十毫秒但对于节拍在1秒以上的产线来说完全没影响。服务侧还要做超时保护。我们遇到过GPU偶发复位的情况推理请求卡住不返回导致队列越堆越长。后来给推理加了超时机制超过2秒直接标记失败并重试必要时丢弃该帧并记录告警保证产线不因为单帧异常而停线。4.3 与产线控制系统对接检测结果最终要落到执行端要么触发剔除机构要么在MES里标记该产品为异常。这一层对接往往比训练模型更花时间。对接方式上最常见的组合是推理服务通过HTTP或MQTT把结果上报给中间层应用再由中间层通过Modbus TCP或以太网IP协议与PLC通讯执行剔除动作。跨两个网段时要注意网络隔离车间控制网和生产管理网分开中间用接口服务器做转发同时满足数据不出厂的要求。两个容易被忽略的细节。一是结果覆盖问题同一产品如果拍了多个视角每个视角都返回一个结果PLC侧要定义清楚任何视角判异常即剔除还是所有视角正常才放行。二是缓存和确认机制剔除动作执行后PLC要回传一个已执行信号接口层把这个状态和检测结果绑定存档。没有这层确认后续追溯时无法区分检出了但没剔除和漏检。看板层简单做就够实时显示每分钟检测量、缺陷率、当班缺陷分类统计以及模型服务的健康状态。我们用在制品系统上顺手加了一个页面效果却意外地好——班组长每天盯看板盯得比盯电脑都勤。5. 上线后的踩坑记录与排错速查5.1 高频问题速查表系统上线不是终点真正的考验是跑得住和稳得住。下面是这八个多月里遇到的典型问题按频率排序整理成表问题现象根因解决思路换班后漏检率突然升高车间照明受自然光影响光照漂移加遮光罩模型训练时增加亮度扰动增强固定摄像头增益参数GPU显存持续增长直至OOM推理框架的显存缓存未释放排查框架显存池配置加定时任务监控显存并设置告警图片偶发模糊导致漏检产线震动或产品运动速度变化缩短曝光时间启用全局快门调整光电传感器触发位置某一缺陷类别误报暴增新产品切换表面纹理与旧产品差异大按产品型号分模型版本切换型号时自动加载对应模型推理服务偶发无响应排队任务积压导致线程池耗尽限流超过队列上限直接丢弃低优先级帧重启策略改为自动拉起标注错误在训练后暴露复检不充分个别类别标注张冠李戴建立线上误报反馈通道把产线争议图定期回流到标注集有一个印象很深的排查案例系统上线第二周某天白班突然疯狂误报脏污类别几乎把良品全标成了次品。我们第一反应是模型坏了反复测试模型文件都正常。后来无意中看了一眼车间监控发现那天保洁刚做完地面打蜡车间反光变强光源打在反光面上的效果全变了。这件事之后我们在产线额外加了一圈遮光围挡再也没有出现过类似问题。5.2 性能优化的几个有效手段上线稳定后我们做过一轮系统性的性能优化三个手段收获最大。第一ROI区域裁剪。相机视野里产品只占中间一部分边缘区域全是背景。模型推理前先把图像裁剪到产品区域减少送入模型的冗余像素。这个改动让推理时间又减少了30%左右。第二动态帧率策略。产线节拍慢的时候检测频率确实用不了那么高。我们把相机的触发方式从固定频闪改成光电传感器触发有产品经过才拍照既减少无效计算也让每张图的位置一致性更好。第三模型预热和连接复用。推理服务启动时先用几张图做一次推理把GPU显存中的运行时缓存激活避免第一个真实推理请求被初始化拖慢。同时所有下游接口的连接池复用避免每次请求都重新建连的握手开销。还有一条管理侧的经验模型版本要留回滚能力。算法优化后觉得新模型更好更新上线结果跑了半天发现误报率高了。如果模型文件名直接覆盖回滚就要找历史文件。我们后来改成版本号命名的模型目录配一个加载配置指到具体版本切换和回滚都是改一行配置的事。6. 成本省百万是真的吗投入产出核算6.1 自建方案到底花多少钱还是用我们自己的账来算。初期投入包括一套训练环境、两套检测工位硬件、开发调试人工总共花了约12万元硬件加两个人约三个月的开发时间。按工厂内部人力折算开发人工成本大约8万元左右整体初期投入约20万元。商用方案对照前文提到的那家云服务厂商单工位报价38万元一年两工位就是76万元还不含硬件订货周期和每年的维护费10%。即使只算第一年自建方案只有商用方案的四分之一上下。后期运维成本也不高。日常成本集中在样本补充标注、模型定期重训和硬件保养。标注和重训基本由厂内工程师兼职完成每月投入几天时间。对比商用方案的年度维护费这部分成本可以忽略。6.2 收益端怎么量化省百万不是一句空话靠的是三块收益叠加。第一块是人力节省。原来两个工位需要六名质检员三班倒系统稳定后减到两名主要负责复核机器判定的异常品。按当地质检员工资加社保每年约8万元算四个人年成本32万元扣除系统运维分摊每年净节省接近28万元。第二块是质量损失下降。系统投用前下游客户反馈的外观不良PPM百万分之不良率在800左右。投用半年后降到200以下。按每月出货量10万件、单件返工成本5元计算每月少损失3000元全年约3.6万元——这块对体量更大的工厂来说数字会更可观。第三块是管理效率和数据价值。MES里有了确切的缺陷分类统计工艺部门终于能说清楚这批不良到底是划伤还是脏污调整工艺参数有了依据。这块很难精确折算成钱但产线工程师都认同价值不比前两块小。三块加起来两工位一年创造的综合价值超过35万元。如果扩展到十条线体规模效应会进一步摊薄软硬件开发成本年度综合收益到百万量级是完全可预期的。6.3 效果评估指标怎么定系统上线时我们定义了三层指标建议新上项目的团队直接照抄模型层按缺陷类别分别统计精确率、召回率、F1值。重点关注召回率质检漏掉缺陷的成本远高于多拦几个良品。系统层单图推理延迟、每分钟检测吞吐、服务可用率目标99.5%以上。业务层漏检率、误杀率误判导致的良品报废、客户投诉率。阈值设定上有个经验初始阈值不要追求零漏检。你把阈值调得极严漏检率确实降了但误报率会快速上升。产线上剔除机构动作太多工人对系统信任度会下降甚至出现工人直接放行被剔除产品的对抗操作。我们的做法是先定一个可接受的误报基线再把召回率往上拉稳定运行两周后再逐步收紧阈值。上线一个月后我们把所有误报图片拉出来做了分类分析发现两大类问题一是模型对轻微形变的产品纹理判断不稳二是光源遮挡导致的暗角被识别成缺陷。这两类问题通过补充数据和调整ROI基本解决精确率从上线初的92%拉到了97%以上。这个复盘的过程就是自建方案相比外购方案最值钱的部分。我个人在实际操作中的体会是开源私有化AI质检系统这个方向真正难的不是训练模型而是把数据、部署、产线、人这四个环节拧在一起。数据采集要蹭产线停机的窗口部署调试要蹲在车间里有故障就现场解决产线工人对系统的接受度要靠减少误报一点一点换回来。建议想上这套方案的同行不要一上来就铺开选一条最痛、样本最好收集的产线做试点跑通全流程、把账算清楚再横向复制。模型和数据资产的积累会随着时间滚雪球越到后面这套系统的价值越难被任何外购方案替代。