场景一句话：一家覆盖 6 个制造基地、200+ 条产线的电子代工企业，怎么把视觉质检 AI 从”一台相机 + 一台工控机”的小试点，做到云边端一体、模型持续迭代的全量部署。

一、场景设定

1.1 行业与客户画像

• • 行业：电子组装 / 精密零部件代工
• • 客户类型：国内某 EMS（Electronic Manufacturing Services）企业，6 大制造基地、200+ 条产线、员工 4 万+，年产能涉及手机主板、汽车电子、PCB 模组等多品类
• • 业务版图：覆盖华东、华南、西南三大集群，单条产线节拍 3-12 秒/件，质检环节过去依赖大量 AOI 设备 + 人工复检
• • 技术基础：已建成 MES、ERP、QMS（质量管理系统）、WMS 等核心系统，单基地机房已有私有化算力池，IT/OT 团队合计 300+ 人

1.2 AI 项目要解决的业务问题

• • 核心痛点：
  • • 传统 AOI 误判率 8-15%，人工复检工时占整线 18%
  • • 新品导入周期 6-8 周，缺陷类型定义每变一次，AOI 规则就要重新写
  • • 多基地之间质检标准不一致，跨基地良率比对失真
• • 传统方案为什么解决不了：
  • • 规则式 AOI 依赖人工调阈值，对纹理类、装配类缺陷几乎无能为力
  • • 不同供应商的 AOI 设备数据协议封闭，无法汇聚训练
  • • 产线每天产生数百万张图，人工只能抽样复检 1-3%
• • AI 切入的角度：用深度学习模型替代规则引擎，同时构建云端集中训练 + 边缘实时推理 + 端侧相机即采即传的视觉质检体系，把”调阈值”变成”迭代模型”。

二、AI 系统的整体架构

2.1 云边端分工

• • 云端（中心数据中心 + 行业公有云）
  • • 职责：模型训练、跨基地数据汇聚、长周期良率分析、缺陷类型聚类、模型仓库管理
  • • 部署方式：自建私有云 + 公有云混合，训练集群 32 卡 H100 / A100，推理服务集群独立部署
  • • 数据流：边缘端上传”脱敏后的缺陷样本 + 难例 + 标注数据”，云端做合并、清洗、再训练
• • 边缘（产线工控机 / 边缘盒子）
  • • 职责：实时推理（每张图 200ms 内返回结果）、本地缓存、与产线 PLC / MES 联动
  • • 部署方式：每条产线 1-2 台工业 PC（CPU + 独立 GPU，如 RTX 4090 / L4），部分新建产线用边缘盒子（Jetson Orin 替代工控机）
  • • 关键约束：推理必须在产线本地完成，不能上公有云——节拍不允许网络抖动
• • 端（工业相机 + 光源 + 触发器）
  • • 职责：图像采集、触发抓拍、初步 ROI（感兴趣区域）裁剪
  • • 部署方式：GigE / CoaXPress 工业相机，单产线 4-8 个工位，每工位 1-3 个相机 + 配套光源

2.2 模型部署方式

• • 训练：云端集中训练，缺陷样本先做半自动标注（人工标注 + 模型预标注 + 一致性校验）；新品上线时启动”小样本冷启动”流程，先用 200-500 张样本做微调
• • 推理：边缘本地推理，模型格式 ONNX + TensorRT 加速；不同产线部署不同版本（按基地、按产品族、按缺陷类型分组）
• • 更新机制：
  • • 模型仓库统一在云端管理，边缘通过 OTA 拉取
  • • 小版本（修复 / 调参）：每周一次，灰度发布
  • • 大版本（新增缺陷类型 / 换骨干网络）：每月一次，全量升级
  • • 回滚：每条产线保留最近 3 个版本，支持一键回滚
• • 模型蒸馏：为边缘推理做模型蒸馏，云端保留大模型做”教师”，边缘只跑”学生”模型

2.3 与现有系统的集成

• • 数据输入：
  • • MES：工单信息、产品型号、工艺参数（用于切换模型版本）
  • • QMS：历史缺陷定义、判定规则（用于知识对齐）
  • • AOI 设备：触发信号、原始图像（取代或绕过原 AOI 软件）
• • 决策输出：
  • • OK / NG 判定 → 推送给 PLC，触发分拣机构
  • • 缺陷分类结果 → 写入 QMS，生成 SPC（统计过程控制）数据
  • • 复检请求 → 推送到复检工位看板 / 平板
• • 集成方式：
  • • MES / QMS 用 RESTful API + Kafka 消息队列
  • • PLC 用 OPC UA / Modbus TCP，工业协议直接联动
  • • 边缘到云端用 MQTT（轻量、断线续传）

2.4 硬件配置

• • 云端：私有云 GPU 集群（训练）+ 推理服务集群（按产品族分组）；对象存储用于图像样本库，冷热分层（30 天内热存，之后归档）
• • 边缘：每条产线 1-2 台工业 PC，CPU 8-16 核 + GPU（推理用 24GB 显存），512GB NVMe（用于本地缓存当班图像）；新建产线试点 Jetson Orin 64GB 替代工控机
• • 端侧：每工位 1-3 个 GigE 相机（500 万 – 2000 万像素）+ LED 条形 / 环形光源 + 光电触发器

三、部署过程

阶段一：需求诊断与方案设计（3-4 周）

业务方与 AI 团队做了什么：

• • 业务调研：驻线 2 周，跟班质检员记录典型缺陷类型、误判场景、节拍要求
• • 数据可行性评估：调取 6 个月 QMS 缺陷记录 + 抽样 AOI 原始图，评估样本量与缺陷分布
• • 方案比选：自研 vs 采购成熟视觉平台 → 最终选”自研模型 + 第三方推理框架 + 自建 MLOps”

AI 系统的设计输出：

• • 缺陷类型树（按产品族拆分，约 30+ 类细粒度缺陷）
• • 云边端架构设计稿（详细到每个组件的网络协议、部署形态）
• • 选型报告：模型骨干（最终选 EfficientNet + 自研检测头）、推理框架（TensorRT）、部署平台（自研 + Argo CD 灰度）
• • ROI 测算：按”节省人工复检工时 + 良率提升 0.5-1%”估算回收周期

踩过的坑：

• • KPI 共识拉锯：业务方想要”良率绝对值提升”，但 AI 团队认为模型上线后短期内良率波动是正常的，最终改用”误判率下降幅度”作为第一阶段目标
• • 需求蔓延：第一周业务方连续加了 4 个需求（追溯、报表、跨基地对比），被项目负责人砍到只剩 1 个

阶段二：数据准备与模型开发（6-10 周）

数据准备：

• • 数据治理范围：6 个月 QMS 缺陷图 + 抽样 AOI 图，总计约 280 万张，缺陷样本 22 万张
• • 数据治理工作量：原计划 4 周，实际用了 9 周（主要卡在跨基地标注标准对齐）
• • 数据集构建：训练 / 验证 / 测试按 7:1.5:1.5 划分，按产品族 + 缺陷类型分层抽样

模型开发：

• • 模型选型：先试通用检测模型（Cascade R-CNN / YOLO 系列），在纹理类缺陷上效果不佳；后改用”分类 + 检测”两阶段 + 自研小骨干
• • 训练策略：云端离线训练 → 蒸馏到边缘小模型 → INT8 量化 → TensorRT 优化
• • 评估指标：召回率、误判率、单图推理延迟、GPU 显存占用

踩过的坑：

• • 数据治理延期：6 个基地的”OK”定义不统一，30% 的样本需要重新标注
• • 模型选型反复：通用大模型召回率 79% → 自研小模型召回率 91%，但代价是每个产品族都要单独训练
• • 合规流程：员工误检图像涉及摄像头拍摄工人手部画面，被工会与法务同时质疑，最终通过”只在工位上拍摄工件、不拍摄操作员”的产品形态规避

阶段三：试点部署与迭代（8-12 周）

试点部署：

• • 试点产线选择：选 5 条产线（覆盖 3 个产品族、3 个基地），避开节拍最快和最慢的产线
• • 部署方式：边缘工控机本地推理，云端只做模型下发与样本回收
• • 双轨运行：AI 判定结果与原 AOI 并行 4 周，差异样本全部人工复检，确认后再切换主路

模型迭代：

• • 反馈收集：复检员每日标记”AI 漏检 / AI 误检”样本，自动回流到云端训练库
• • 快速迭代：关键 bug 48 小时内修复，普通调优 2 周一次小版本
• • A/B 测试：A 组用 AI 判定，B 组继续用原 AOI，4 周后对比误判率与漏检率

踩过的坑：

• • 试点第三周翻车：新品切换时模型没及时换版本，召回率从 91% 跌到 68%，紧急加了”工艺参数变更触发模型自动切换”的机制
• • 误报告警风暴：边缘缓存写满后推理卡顿，触发 PLC 误动作，紧急加了磁盘监控 + 自动清理
• • 复检员不信任：AI 第一周采纳率只有 40%，靠”差异样本可追溯 + 错误可申诉”的机制建立信任，第四周升到 75%

阶段四：规模化部署（4-6 个月）

规模化策略：

• • 分批上线：5 条 → 30 条 → 80 条 → 200+ 条，每批间隔 4 周，每批覆盖不同产品族
• • 部署流水线：自动化脚本 + Argo CD 灰度发布 + 一键回滚
• • 基地差异化：每个基地单独维护一份”产品族 × 模型版本”映射表，工艺变更自动触发

运维监控：

• • 监控指标：模型召回率漂移、单图推理延迟、误判率、GPU 显存、PLC 通信成功率
• • 告警机制：误判率超阈值 → 自动降级（原 AOI 接管）；推理延迟 > 300ms → 告警
• • 模型更新：每周一次小版本，每月一次大版本，每季度一次大复盘

踩过的坑：

• • 全量效果反而下降：模型在中等节拍产线训练，推广到高速产线水土不服，紧急做了”按节拍分档训练”
• • 基地间数据孤岛：某基地拒绝把样本上传到云端，临时方案是”云端下发模型、边缘本地训练”（联邦学习雏形）
• • 产线停产风险：模型升级时不能中断产线，最终引入”双模型并行 + 热切换”机制

四、AI 系统的最终效果

4.1 业务指标

4.2 AI 模型指标

4.3 AI 系统的关键作用

• • AI 接管了缺陷判定工作：以前是 AOI 规则 + 人工复检”两层兜底”，现在 AI 直接做主判定，复检员只处理 AI 标记的难例
• • AI 提供了缺陷分类决策：以前缺陷分类靠人工看图 + 经验，现在 AI 把缺陷自动归到 30+ 细分类别，直接驱动 QMS 的 SPC 分析
• • AI 解决了新品冷启动瓶颈：以前每款新品要 6-8 周调 AOI 规则，现在 AI 用 200-500 张样本微调 2-3 周即可上线
• • AI 改变了跨基地协作方式：以前各基地质检标准各自为政，现在 AI 模型统一版本，跨基地良率比对第一次具备可信度

五、可复用的部署模式

5.1 适合这套架构的场景

• • 多基地 / 多产线、节拍快、对漏检零容忍、缺陷类型多变的离散制造场景
• • 已经上了 MES / QMS、但传统 AOI 误判高的工厂

5.2 不适合的场景

• • 单条产线、数据量小、缺陷类型极少的场景——直接买现成视觉平台即可
• • 工艺频繁变更、连样本都难以稳定的产线——AI 还没建立稳定就先上反而是负担
• • 对实时性极敏感（< 50ms）、但硬件预算有限的场景——边缘推理成本不划算

5.3 同行业复用的关键改造点

• • 按产品族拆模型：不要追求一个大模型覆盖所有产品，每个产品族单独训练
• • 按节拍分档：高速产线和低速产线用不同量化策略和模型规格
• • 按基地建样本库：每个基地的缺陷分布不一样，样本库要本地留副本

5.4 给同行业读者的具体建议

第一期要避免的 3 个动作：

1. 1. 不要第一期就铺 50+ 条产线，先做 3-5 条试点覆盖核心产品族
2. 2. 不要同时启动”质检 AI + 追溯 + 报表”等多个需求，第一期只做主判定
3. 3. 不要用通用大模型硬扛所有缺陷类型，先把每类缺陷的样本量盘清楚

第一期必须坚持的 3 个动作：

1. 1. 数据治理预算预留 40%（比模型开发更费时）
2. 2. 设立”双轨运行期”（至少 4 周），不要让 AI 一上来就接管主路
3. 3. 把”AI 漏检可追溯、误检可申诉”作为复检员的硬性权利写进流程