一场现场检完直接跑路的实战复盘AI工业检测真正的拦路虎其实是工具链我最早接触AI工业检测是从一条漏检投诉开始的。产线上某款金属件表面有一类极隐蔽的压伤传统机器视觉一直用阈值分割方式处理客户换了一批毛坯料后同样的参数突然压不住漏检率直接冲到百分之五。那段时间我几乎把图像处理算法书翻烂最后接入了几个深度学习分类模型问题才算兜住。那次经历让我意识到在工业场景里AI检测不是“有没有好模型”的问题而是“能不能在产线节奏下稳定跑起来、快速迭代、可控排障”的问题。换句话说光有算法远远不够真正决定项目成败的往往是围绕AI检测搭建的整套工具链。这篇文章不聊学术前沿也不堆概念就按我在实际产线落地AI工业检测项目的经验拆解这个领域里的算法选型、数据工程、模型部署、工具链集成以及我在现场踩过的那些坑。1. 内容整体设计与思路拆解1.1 先搞清楚工业检测到底难在哪工业视觉检测表面上是个“看图说话”的任务但其实和普通的计算机视觉项目差别很大。比如最常见的缺陷检测场景需求方提的是“把不良品挑出来”这背后至少有三个隐含指标漏检率、过检率误杀率和检测节拍。漏检率关乎质量事故过检率关乎生产成本节拍关乎产线效率。这三者经常互相牵制一个模型如果为了把漏检率压到极低就会不停误报导致现场堆了一堆待复检品生产节奏全乱。另一个和学术任务差异很大的点是工业现场的缺陷形态高度多样普通算法工程师常接触的ImageNet、COCO这类公开数据集在这里完全不适用。现场缺陷可能是几毫米的划痕可能是密集的点蚀可能是和纹理极其相似的色差甚至同一种缺陷在光照变化下看起来完全两样。正因如此工业检测项目永远是“数据工程”大于“模型工程”。业内有个共识AI工业检测项目的成败七成在数据两成在工程化部署剩下一成才轮到模型结构创新。我自己的体会也差不多很多项目最初模型精度看起来不错一到产线就被光照、震动、来料批次差异打得体无完肤根本原因就是前期没把数据、评估口径和部署链路当回事。1.2 从端到端视角规划整套工具链所谓工具链不是单个软件或者单个模型而是从数据采集到最终产线稳定运行的一整套流水线。我一般习惯分成五个环节数据获取与管理、标注与清洗、模型训练与评估、部署与推理优化、监控与迭代。数据获取环节解决“拍什么、怎么拍、存哪里”的问题需要考虑相机、镜头、光源、触发方式以及图库管理方式。标注与清洗环节决定“模型学习什么”标注规范不统一后面所有环节都会跟着遭殃。模型训练与评估环节负责“选哪个网络、定什么指标”关键是要建立一套贴近产线真实损失的评估方法。部署与推理优化解决“跑多快、怎么跑”的问题涉及推理引擎选择、模型量化、边缘设备适配。监控与迭代则是持续跟进产线数据分布变化定期做模型更新。这五个环节在很多时候不是串行的而是环状的。产线发现漏检数据回流到训练集重新标注、迭代、验证再发布。如果没有一套顺手的工具链支撑整个闭环会非常痛苦到处都是手工导图、手工切训练集、手工改参数。1.3 为什么我坚持走开源工具链路线市面上有成熟的商业工业视觉软件比如Halcon、VisionPro它们功能完善、文档齐全在固定场景下非常可靠。但AI检测项目有个特性模型迭代频繁、网络结构多样、部署目标碎片化。如果你选了闭源商业方案一旦算法层面需要深度定制或者要部署到非主流的边缘设备就会非常被动。我目前的偏好是走开源路线核心组件包括Python生态里的图像处理库OpenCV、Pillow、深度学习框架PyTorch为主、推理优化套件OpenVINO、ONNX Runtime、TensorRT以及数据标注工具LabelStudio、CVAT。这套组合的好处是可控性强每个环节都知道内部原理出了问题能直接定位修复不会遇到黑盒卡死的困境。当然开源路线对团队能力要求更高需要有人能hold住从模型训练到C部署的全过程。如果团队全是纯算法背景没有工程化积累我还是建议先拿商业软件做原型验证后续再逐步替换。2. 核心算法模型选型与细节解析2.1 工业异常检测一类被低估的算法方向工业界有个和学术界不太一样的点真正的“正常样本”很容易获取而“缺陷样本”往往少得可怜。因为产线绝大多数情况下都在生产合格品只有偶发异常才会产生不良。如果一味依赖有监督缺陷分类就会遇到严重的样本不平衡问题负样本可能只有几十张根本喂不饱深度学习模型。于是这几年工业异常检测算法逐渐火起来。这类算法的核心思想是只用正常样本训练学习“正常长什么样”推理时凡是偏离正常分布的都视为异常。比较有代表性的工作是PatchCore、PaDiM、SPADE这类基于预训练特征的方法它们不需要大量缺陷样本就能对多种异常形态给出不错的检出效果。以PatchCore为例它的思路可以这样理解用一个在大规模自然图像上预训练好的卷积网络比如ResNet或Wide ResNet把训练集里所有正常图像切块后提取特征存到内存中形成一个特征库。推理时待测图像同样提取局部特征然后在特征库里寻找到最近邻计算与最近邻的距离如果距离超过阈值就判定为异常。整个过程没有梯度更新属于“用特征记忆匹配”的思路训练极快通常几分钟到十几分钟就能搞定。我实测下来PatchCore在纹理类表面的异常检测上效果相当稳比如布匹、木材、金属拉丝面。但对于结构复杂的装配体比如电路板上有各种元器件PatchCore容易把“正常但不常见”的布局误判为异常这时就需要配合检测网络做两层判断。2.2 有监督任务分类、目标检测与分割怎么选如果缺陷样本足够多通常每个类别有几百张以上我们还是倾向于用有监督模型因为控制精度和可解释性更强。按任务形式区分缺陷检测主要有三条路线图像级分类、目标检测框、像素级分割。图像级分类最简单输入一张图输出“OK/NG”或者具体缺陷类别适用于只需要筛掉不良品、不需要定位的场景。目标检测则要在图上框出缺陷位置用YOLO系列或Faster R-CNN便于后续机器人抓取或人工复检定位。像素级分割最精细输出每个像素的类别能精确计算缺陷面积适合对缺陷尺寸有量化要求的场景比如要求划痕长度小于多少毫米。我自己的选型逻辑是能分级解决就不用分割。因为分割模型标注成本极高同一张图上逐像素勾轮廓一个熟练标注员一天也标不了几十张。很多场景其实用检测框就够甚至分类也够。做项目要控制成本模型层面能简单就尽量简单。2.3 模型效果对比与硬件约束下的取舍工业部署端常常不是GPU服务器而是工控机甚至ARM盒子算力有限。因此模型选型必须提前考虑部署端的推理速度而不是只盯着训练时的mAP。这里有一张我在项目里常用的选型对照表录在这里供参考模型类型端侧GPU/CPU速度精度特点适用场景MobileNetV3 / EfficientNet-Lite分类极快适合CPU跑精度一般但对简单缺陷够用单一产品、缺陷形态简单的OK/NG判断ResNet50 / EfficientNet-B4分类中等精度高特征提取能力较强多类别缺陷分类样本较充足YOLOv5s / YOLOv8s检测快GPU实时小目标能力一般需调anchor缺陷定位、多目标筛选YOLOv8n检测版检测最快精度略降但体积小适合边缘嵌入式端实时检测Faster R-CNN检测慢精度高小目标表现好对精度要求极高、速度不敏感的场景U-Net / DeepLabV3分割慢像素级输出标注成本高缺陷面积量化、复杂形状缺陷PatchCore / PaDiM异常检测推理由特征距离决定可接受零缺陷训练适合少样本无缺陷样本或缺陷样本极少的场景在这张表的基础上我还习惯再加一个底线要求如果部署设备是CPU工控机推理时间必须控制在300ms以内如果是GPU边缘卡推理时间控制在50ms以内。达不到就换更轻量的模型或者考虑量化。2.4 别忽略输入分辨率与打光这两个“隐藏参数”算法工程师很容易陷入网络结构调优但在工业检测项目里输入分辨率往往比模型参数量更影响最终效果。同一套YOLO模型输入分辨率从320提到640小缺陷的检出率可能直接翻倍但推理耗时也会成倍增加。这里没有银弹需要针对实际缺陷大小和节拍要求找一个平衡点。我常用的经验法则是把缺陷的最小尺寸换算到输入图像中的像素宽度一般目标物体在缺陷方向至少要占20个像素以上模型才有能力稳定学到。如果实际缺陷在原始图里只有几个像素宽先做图像裁块或者用更高分辨率相机而不是盲目上大模型。打光同样关键。很多AI检测项目在现场翻车不是模型不行而是打光变了。产线换了一批发黄的灯管或者光源控制器被人调了亮度测试集指标立刻崩。所以我每次项目交付都会叮嘱现场工程师光源参数要锁定相机曝光时间做成配置文件任何人不得随意改动。3. 数据标注、训练调参与模型评估实操3.1 实操第一步从产线拿到可用的数据很多团队接到项目后第一件事是上网找公开数据集这实际上是个误区。工业检测场景和公开数据集差异太大哪怕同类产品、不同厂家的表面处理工艺不同缺陷形态也完全不同。正确做法是去现场搭一套和产线一致或接近的图像采集装置把真实样品拍一遍。数据采集中有几个容易踩的坑一是样本分布偏斜有些缺陷类型拍了几百张有些只有个位数二是背景单一化所有图都在同一角度、同一亮度下拍摄模型泛化能力差三是标注和采集脱节拍回来的图没有同步记录对应的工艺参数后续想分析缺陷根因就少了很多线索。建议做好采集记录每张图像至少附带产品批次、工艺参数、光源状态、相机位置等信息。这些元数据在后续做数据筛选时非常有用比如发现某一批次的产品误检率偏高可以直接按批次号回查图像特征。3.2 标注规范定不好规则模型就学偏标注是工业检测项目里最容易被低估的环节。我见过太多项目标注员和算法工程师各干各的标出来的框一会儿紧一会儿松类别定义前后矛盾最后模型训练出来精度不差但一到线上就各种漏。原因很简单模型学到的是标注员“标注习惯”里的噪声而不是缺陷的本质。所以我建议在项目一开始就写好标注规范文档内容至少包括类别定义与边界情况说明、目标框紧贴程度要求、遮挡目标处理规则、模糊目标处理规则、争议样本的仲裁机制。其中最常见的坑是“同一目标允许同时标两类”的问题比如一个区域既像划伤又像压伤规范里必须明确优先级别。此外标注质量检查不能省。我通常会让算法工程师在训练前随机抽查5%~10%的标注结果如果错误率超过2%就退回给标注团队重新修正。这个成本看起来不高却能在训练阶段省下大量来回试错的时间。3.3 训练超参不是玄学一份可复现的基础配方模型训练本身并不难难的是让每次训练可复现、可对比。工业项目里最怕的是“上次跑出来90%准确率这次同样代码跑出来85%但谁也不知道哪里变了”所以我养成了一个习惯所有训练实验都固定随机种子并记录详细的超参组合包括优化器、学习率、批大小、数据增强策略、图像分辨率、训练轮数。在数据量不大的工业场景里我推荐直接用预训练权重做迁移学习不要从零训练。比如PyTorch里加载torchvision提供的ResNet预训练模型替换最后一层全连接再冻结前几层训练收敛速度会快很多。import torch import torchvision.models as models from torch import nn # 以ResNet18为例替换分类头 model models.resnet18(weightsmodels.ResNet18_Weights.IMAGENET1K_V1) num_features model.fc.in_features model.fc nn.Linear(num_features, num_classes) # 冻结前3层只微调后续层 for name, param in model.named_parameters(): if layer3 in name or layer4 in name or fc in name: param.requires_grad True else: param.requires_grad False optimizer torch.optim.Adam(filter(lambda p: p.requires_grad, model.parameters()), lr1e-3) criterion nn.CrossEntropyLoss()关于学习率我推荐先用一个较小的热身轮数再切换到Cosine退火避免开局震荡。批大小在显存允许范围内尽量取大一点工业数据集类别不平衡明显时建议在损失函数里加上类别权重或者用Focal Loss别硬啃普通交叉熵。3.4 用混淆矩阵和“产线口径”来评估而不是只看准确率分类任务光看准确率是非常危险的。假如合格品占99%一个全预测为“合格”的模型准确率就是99%看似完美但实际一个不良都没拦住。工业项目里真正要盯的是两类指标不良品召回率漏检率1-召回率和合格品精确率过检率1-精确率。漏检率和过检率要分开统计并且要结合产线节拍来权衡。我通常在训练完模型后不光看测试集整体指标还会按缺陷类别分别看混淆矩阵找出哪些类别最容易互相混淆。比如压伤和划痕经常分不清那就考虑是否合并类别或者增加相应训练样本。一个更有价值的做法是用模型对一段真实产线录像做离线推演模拟线上运行统计“每1000个合格品会被误杀几个”“每1000个不良品能拦住几个”。这种离线推演结果比随机划分的测试集更能说明问题也能提前暴露出数据分布偏移的隐患。4. 模型部署推理优化与边缘端适配4.1 推理引擎选型OpenVINO、TensorRT和ONNX Runtime怎么挑训练完的PyTorch模型不能直接扔到产线跑必须经过推理优化和格式转换。目前主流的方案有OpenVINO、TensorRT和ONNX Runtime三套选择依据主要是部署端的硬件平台。OpenVINO是Intel家的工具套件对Intel CPU、集成显卡和Movidius加速卡优化得很到位尤其适合工控机只有CPU的场景。TensorRT是NVIDIA的GPU加速套件能显著降低GPU推理延迟适合对算力要求高、使用NVIDIA显卡的边缘设备。ONNX Runtime则更像一个“通用转换层”从PyTorch导出ONNX后可以直接在多种硬件上跑也可以结合各家的Execution Provider调用OpenVINO或TensorRT的底层加速。我现在的默认流程是先把PyTorch模型导出为ONNX再做简单的静态输入分辨率固定然后按部署端硬件选择Execution Provider。如果目标是Intel CPU就接OpenVINO如果是NVIDIA GPU就接TensorRT。这样代码层面的迁移成本最低后面换硬件也不会伤筋动骨。4.2 模型量化从FP32到INT8要做的准备与权衡模型量化是把32位浮点权重压缩到16位或8位整数从而减少模型体积、加快推理速度。在工业端侧设备上量化几乎必做因为很多设备的内存和算力非常有限原版FP32模型加载都费劲。但量化不是简单地torch.onnx.export之后自动完成的需要准备校准数据集。校准集要尽量涵盖产线真实图像分布通常选几百张正常图和缺陷图就够了。量化后要做的是对比检测精度如果掉点明显那就需要回到训练阶段加入量化感知训练或者放宽到FP16精度。我踩过的一个坑是在量化时选了训练集里最“干净”的图像做校准结果模型上线后遇到光照变化大的图像输出概率变得很奇怪。后来改成从产线录像里随机抽帧做校准精度才稳定下来。校准集的选择直接影响量化模型面对真实环境的鲁棒性这点一定要重视。4.3 边缘端部署ARM架构与交叉编译工具链工业现场很多设备是ARM架构的边缘计算盒子比如RK3588、Jetson系列这类设备上部署模型时“交叉编译”这个词就会频繁出现。简单解释一下我们日常开发用的电脑通常是x86架构比如Intel或AMD的CPU而边缘盒子是ARM架构两者指令集不同。你不能把在x86上编译出的可执行文件直接复制到ARM盒子上运行必须在开发机上用“交叉编译工具链”生成目标平台能运行的程序。比如我们在一块ARM工控板上做推理程序常见做法是在x86开发机上用aarch64-linux-gnu-gcc这套工具链编译C代码再把编译产物拷贝到ARM板上运行。为什么不在ARM板上直接编译因为开发机性能更强、库更全而且可以并行处理多个目标平台。项目交付时一份代码用不同交叉编译工具链就能同时产出x86版和ARM版效率高很多。我自己的开发环境是VMware里装一台Ubuntu虚拟机作为x86开发机再在虚拟机上安装对应的交叉编译工具链比如gcc-arm-10.3-aarch64。然后编写CMakeLists.txt时指定工具链文件编译出的可执行文件拷贝到ARM板子运行。关键点在于依赖库也需要匹配目标架构比如OpenCV要交叉编译成ARM版本不能直接拿x86的库去链接。# 在Ubuntu开发机安装AArch64交叉编译工具链 sudo apt install gcc-aarch64-linux-gnu g-aarch64-linux-gnu # 交叉编译一个简单测试程序 aarch64-linux-gnu-g -o hello_arm hello.cpp file hello_arm # 输出里看到 ARM aarch64 字样就说明编译目标正确很多人第一次接触交叉编译会觉得麻烦但如果你的目标设备是ARM盒、要用OpenVINO或ONNX Runtime做推理这件事绕不开。我建议项目初期就把部署链路确定好不要等模型训练完了才去想怎么部署到那时候再踩交叉编译的坑时间成本太高。4.4 现场部署时相机通信与触发架构的处理模型推理只是检测系统的一部分完整的工业检测还包含相机采集和PLC触发联动。现场常用的方案是传感器触发工业相机拍照图像传输到上位机或边缘盒子AI模型跑推理结果通过IO或协议通知PLCPLC再控制分料机构把不良品剔除。这里面有一个特别容易被算法团队忽略的点图像采集与推理线程的耦合。如果采集线程和推理线程串行执行相机每拍一张图就要等模型跑完才能拍下一张产线速度一旦加快就会丢帧漏检。正确的做法是设计成多线程或双缓冲架构采集线程不停拍照入库推理线程持续从队列取图并输出结果这样才能匹配产线节拍。另一个细节是通信超时处理。PLC发来触发信号后如果AI推理耗时超过产线节拍PLC会怎样是继续等待还是直接判NG这个联动逻辑必须在项目验收前明确并在程序里做超时保护否则产线上一旦出现偶发卡顿就会批量误判。4.5 本地部署大模型辅助工业检测脚本开发最近这一年大语言模型辅助编程已经成了我工具链里的常规部分。写图像处理脚本、调OpenCV接口、写部署配置文件这些重复劳动让AI先搭个框架我再做修正效率提升非常明显。我常用的方式是在本地部署一个中规模的代码模型通过API接入自己的开发环境。这样做的好处是数据不出内网工业图像和产线参数不会外泄。项目里很多涉及保密协议的检测项目对数据安全要求极高用本地部署的模型写代码、生成脚本既合规又省心。使用时注意控制提示词的粒度不要给一个太模糊的任务比如“帮我写一个缺陷检测程序”这得到的东西基本没法用。我会把任务拆细比如“用Python和OpenCV读取目录下的所有图像统一缩放到640x640然后保存为二进制数组”这样模型给出的代码更精准我再针对业务逻辑微调。5. 工具链集成、AI辅助与自动化进度5.1 MLOps让数据版本、模型版本和实验记录都可追溯当项目进入持续迭代阶段没有版本管理的工具链会变成一场灾难。训练数据换了一版模型参数更新了一轮评价指标也变了如果没有记录三个月后想找回“那个效果最好的模型”根本无从下手。现在我的标准配置是数据层面用DVC做数据版本管理模型文件统一存到模型注册表实验记录写进WandB或者MLflow。每次训练跑完除了保存权重文件还要记录对应的训练代码版本、数据版本、超参配置以及验证集指标。这样即使换人接手也能快速恢复训练环境和复现结果。在自动化层面我习惯用Shell脚本或者Python脚本把“数据更新→预处理→训练→评估→导出ONNX→量化→打包部署”串成一条流水线。每次更新都能一键跑完生成新的部署包。这项工作初看耗时但一旦跑通后期迭代效率是手工作业的十倍以上。5.2 AI Agent在工业检测项目管理中的应用尝试AI Agent这个概念最近很火我在工业检测项目里也做了一些落地尝试。比较实用的方向是自动生成检测报告和异常分析摘要比如每天产线的检测日志喂给本地Agent让它自动汇总当天的缺陷趋势、异常类别分布和可能的原因推测。这样质量工程师不用每天手动打开Excel做透视表直接看摘要即可。另一个探索方向是用Agent自动处理简单的图像排查请求。比如现场反馈某批次误检率偏高Agent可以自动抓取该批次图像并进行初步特征统计把可疑样本聚类出来再转给算法工程师深入分析。这类自动化虽然还达不到完全无人值守但能省掉大量重复劳动。我也尝试过用大模型生成PLC侧的联动代码比如根据逻辑时序描述自动生成梯形图或结构化文本但目前看实用性还一般。原因在于PLC编程和现场硬件绑定太强手写更稳妥等模型在特定品牌PLC上的知识积累更充分后再考虑也不迟。5.3 用“提示词模板”沉淀项目经验项目做多了以后我发现很多重复性工作其实可以通过提示词模板来加速。比如每周复盘时我会把训练日志、混淆矩阵、产线反馈三项数据整理成固定格式丢给AI让它生成问题列表和假设然后我再逐条验证。这里分享一个我常用的模板思路不一定适合所有团队但可以参考先描述背景指定角色是“资深工业视觉算法工程师”再给出数据文件路径和关键指标最后要求输出“问题假设、验证方法、优先级排序”。模型的输出往往比较泛但能帮你快速打开思路离真正问题的原因又近一步。真正核心的判断还是要靠人来下。AI能给的是效率不是结论。我见过有些团队把AI生成的报告直接发给客户结果里面有一本正经的胡说八道反而损害了专业信任度。我的原则是AI辅助生成的内容人必须复核特别是涉及产线数据、质量结论的部分绝不能直接外发。6. 常见问题与排查技巧实录6.1 打光变化导致误检率飙升有一次交付现场设备上午正常下午误检率突然翻倍。排查发现是窗外太阳角度变化环境光通过地面反射到了被测工件表面相当于给所有图像叠加了一个渐变背景。解决办法是加遮光罩、固定光源亮度并在代码里加入图像亮度均一化预处理把光照影响降到最低。这里提醒一句AI模型对光照变化的鲁棒性并没有想象中那么强尤其是训练数据如果只在一种光照条件下采集模型很容易过拟合到“光源影子”上。最好在数据采集阶段就故意变化光源位置和强度让模型学到更多不变特征。6.2 测试集指标高、现场表现差是哪里出了问题“测试集mAP 99%产线一试漏检一堆”这是工业检测项目最常见的一个困惑。原因基本可以归为三类一是训练测试集和现场图像的分布不一致比如分辨率不同、光照不同、产品批次不同二是测试集划分方式用了纯随机划分导致同一产品批次的图像同时出现在训练和测试集里产生了“数据泄漏”式虚高三是缺陷类型冷启动现场出现了一种训练时没见过的缺陷形态模型必然漏。排查思路是先对比现场图像和训练集图像的数据分布可以简单用图像均值、方差或者用PCA特征做可视化比对。如果分布明显偏移优先补充现场数据做增量训练如果分布接近但依然误检就要检查测试集划分和标注质量。6.3 推理延迟不稳定时快时慢边缘设备上的推理延迟在实验室里测得很稳定到了产线却时快时慢这多半不是模型的问题而是系统资源竞争导致的。比如现场工控机同时跑着HMI人机界面、上位机通信、日志写入这些任务会抢占CPU和内存推理线程拿不到稳定资源延迟自然飘。解决方案有三个方向一是把推理线程绑核到特定CPU核心优先级调高二是关掉或精简同一设备上的其他高负载程序三是适当增大推理队列缓冲用批处理方式降低平均延迟。实测下来绑核和优先级调整的效果最明显代码改动也不大。6.4 缺陷样本不足时怎么把模型撑起来工业项目经常遇到“一种缺陷只见过几例”的情况。这时候硬着头皮训练有监督模型结果往往过拟合。我通常采取的策略是多管齐下用异常检测算法做第一层粗筛用极少量的正负样本微调一个简单的分类器做第二层确认同时在现场部署阶段开启“样本回收”机制每发现新的缺陷样本立刻回流到训练集。数据增强也能在一定程度上弥补样本不足但对工业缺陷要谨慎使用过于夸张的增强策略比如随机裁剪、大角度旋转可能会破坏缺陷本身的形态关系。我更推荐使用轻度几何变换加颜色扰动以及基于CutMix的混合增强后者在我的实验里效果比较稳定。6.5 常见问题速查表现象可能原因排查步骤紧急缓解手段误检率突然升高光源亮度变化、产品批次变更检查光源电流、对比新旧批次图像均值回退上一版模型同步现场图像做增量训练推理延迟不稳定CPU资源竞争、内存不足用top命令查CPU占用检查推理线程优先级绑核、关掉无关进程、提高进程优先级小缺陷漏检严重输入分辨率不足、缺陷像素太小测量缺陷在输入图中的像素尺寸提高输入分辨率或做图像裁块新增缺陷类型漏报缺陷样本未覆盖人工查看新图像打标后增量训练先用异常检测粗筛再人工复检量化后精度下降太多校准集分布不合理更换校准集为产线真实图像做FP16对比暂时保留FP32模型确认稳定后重做量化写在最后回到开头说的那次漏检投诉后来我复盘了整个项目发现模型本身改进的空间只占一小部分真正让问题变得可控的是把数据采集、标注流程、模型训练评估、量化部署和现场监控这一整条工具链搭建起来了。我现在做项目的习惯也变成了这样拿到需求先不急着试模型而是问清楚产线节拍、部署设备、数据来源、缺陷种类分布、可接受误检率。这些信息到位后再按工具链的思路一步一步推进每一步都有记录、有评估、有可回退的版本项目才不会越做越玄。最后分享一个挑边缘设备的小经验决定用哪块板子之前先拿典型的ONNX模型到板子上跑一遍基准测试测一下真实推理时间不要只看官方标称的TOPS算力很多板子的算力在工业场景里根本发挥不出来。把这一步放在项目早期能省掉后期大量换硬件的痛苦。