产线质检这个事，在制造业待久了的人都清楚，它从来不只是技术问题，更是成本问题。我们车间原来靠人工目检，两个人盯一台设备，一天下来眼睛酸得不行，漏检率还压不下去。后来评估过商用质检软件，报价一出来，直接把人劝退了。最后决定自己搭一套开源私有化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 硬件配置与预算估算
硬件是私有化方案里最大的一笔硬支出，但相比商用方案，仍然便宜很多。我们按两个检测工位加一套训练环境来估算：
| 硬件项 | 配置参考 | 单价（约） |
|---|---|---|
| 训练服务器GPU | 24GB显存级显卡，搭配64GB内存、2TB NVMe | 3-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质检系统这个方向，真正难的不是训练模型，而是把数据、部署、产线、人这四个环节拧在一起。数据采集要蹭产线停机的窗口，部署调试要蹲在车间里有故障就现场解决，产线工人对系统的接受度要靠"减少误报"一点一点换回来。建议想上这套方案的同行，不要一上来就铺开，选一条最痛、样本最好收集的产线做试点，跑通全流程、把账算清楚，再横向复制。模型和数据资产的积累会随着时间滚雪球，越到后面，这套系统的价值越难被任何外购方案替代。
