1. 飞机表面缺陷检测为什么这项质检非做不可1.1 缺陷类型与失效风险飞机表面的缺陷和普通制造业的划痕、脏污完全不是一个量级的问题。机身蒙皮直接承受客舱压力、气动载荷和环境腐蚀任何一条细微裂纹都可能发展成灾难性的结构失效。典型的飞机表面缺陷大致有这几类缺陷类型典型表现主要风险疲劳裂纹蒙皮表面细长线状多发生在铆钉孔、应力集中区结构强度下降可能快速扩展腐蚀蒙皮氧化、点蚀、层状剥蚀常见于尾部、舱门周边蒙皮变薄隐蔽性强漆面鼓包/剥落涂层起泡、脱落往往伴随底层腐蚀暴露金属基体加速腐蚀凹坑变形冰雹、地勤碰撞等造成的局部凹陷影响气动外形产生应力集中铆钉缺陷铆钉松动、裂纹、脱出连接强度丧失裂纹源烧蚀/雷击点雷击后的熔融坑、烧蚀痕迹表面防护层破坏这里尤其要注意腐蚀的隐蔽性——很多时候漆面看起来只是微微鼓包撬开以后底下已经大片剥蚀了。这类缺陷靠传统图像处理很难识别因为它的边缘模糊、形状不规则、对比度低。1.2 人工目视质检的三大硬伤我近距离跟过机务维修的定检流程一架窄体机绕机目视检查下来少说要一两个小时。人工目视检测的问题集中在三点。第一是疲劳。机库光线复杂、蒙皮反光强检查员连续工作四十分钟以后注意力明显下降细长裂纹在银色蒙皮上本来就不显眼眼睛一花就过去了。第二是主观性。同一个缺陷老师傅和新手判断的标准完全不同有人觉得要报有人觉得还能飞。这种标准不统一在质量体系里非常致命。第三是效率整机表面几百平方米人眼逐寸扫过去成本太高定检周期被迫拉长。也因此“先用视觉算法做一遍全表面预筛再让检测人员聚焦预警区域复核”成了很自然的解决思路。这也是飞机表面缺陷识别这类工业零部件自动化质检项目存在的根本原因。1.3 为什么选目标检测而不是传统图像处理可能有人会问缺陷不就是边缘、纹理异常吗用OpenCV阈值分割或者边缘检测不行吗我一开始也这么想过直到拿真实蒙皮照片跑了一遍才发现完全行不通。飞机蒙皮上本身就有铆钉排、蒙皮接缝、打磨痕迹、舷窗轮廓甚至反光都会形成边缘传统的边缘检测和阈值分割会把大量正常结构误判成缺陷你得为每种机型、每种光照条件手工调一堆参数换一个拍摄角度又废了。而目标检测模型尤其是YOLO这类端到端方案直接把“框出缺陷”“判断缺陷类型”两步合在一起模型的感受野能自动学习“铆钉孔周围的细线是裂纹”“蒙皮接缝是正常结构”这样的上下文。训练数据够的情况下泛化能力远好于手工特征。再加上YOLO在工业部署上的生态成熟训练、导出、推理都有标准链路正适合机务和产线场景。2. 数据集底子决定模型上限类别设计、标注标准与清洗2.1 缺陷类别设计粒度太粗犯迷糊太细没法标很多做数据集的朋友第一个坑就是类别设计。飞机表面缺陷识别数据集最忌讳两种做法一种是把所有不正常的东西都标成defect模型倒是能框出来但完全没法指导后续处置另一种是把裂纹按形态分成直裂纹、分叉裂纹、网状裂纹、微裂纹……标着标着就发现过渡形态太多连标注员自己都拿不准该归哪一类标签噪声爆炸。我自己的实践是控制在6类左右crack所有裂纹形态、corrosion腐蚀、paint_peeling漆面鼓包剥落、dent凹坑、rivet_defect铆钉缺陷、burn烧蚀点。这样分类的好处在于每个类别的视觉特征相对稳定标注一致性高下游处置逻辑清晰——看到腐蚀和铆钉缺陷优先级最高漆面剥落可以暂缓处理类别之间不易混淆模型收敛快。如果你的实际场景中发现“裂纹”和“划痕”在视觉上确实高度重叠宁可单独加一个scratch类给模型一个学习区分的机会也不要硬把两者合并成一类。合并只会让模型无所适从精确率崩掉。2.2 边界框标注红线紧致框、极小目标与遮挡标注质量对YOLO系模型的影响往往比模型结构本身还大。我踩过的坑集中在这几条红线。第一是紧致框。很多人习惯给缺陷留一圈“安全边距”框得松一点觉得这样好标、不容易漏。但在计算IoU的时候松框和紧框的差距会被平方放大一条裂纹本来占框面积的5%你外扩一倍正样本质量大幅下降mAP直接被稀释。裂纹这种细长目标标注时要尽量贴合外接矩形宁可框得窄也别为了省事框一个大方块。第二是极小目标。对于在输入分辨率下小于10×10像素的目标我建议直接过滤掉。你强行标进去模型在640分辨率下根本学不到足够特征反而会给训练带来噪声。真想覆盖这类缺陷应该靠提高输入分辨率或切块推理而不是硬标。第三是模糊样本。凡是人眼需要纠结3秒以上才能确定类别的样本建议直接删掉。工业质检的标注原则是“宁缺毋滥”模糊标签比缺失标签危害更大。一个标错的样本和一百个正确样本对梯度的破坏力相当。2.3 数据清洗与YOLO格式转换数据来源通常很杂真实维修场景拍摄的、实验室样板拍的、合成渲染的混合在一起。我习惯在标注前先跑一遍清洗脚本用感知哈希去掉近似重复图片检查图片能否正常解码、分辨率是否达标检查标注框是否越界、宽度高度是否为0或负数检查类别ID是否超出nc范围。YOLO格式要求每张图片一个同名txt文件每行是class_id x_center y_center width height坐标全部归一化。数据划分建议按场景而不是按文件名随机打散——同一个机身、同一个机位拍的图片容易高度相似如果训练集和验证集都包含同一场景验证指标会虚高。按拍摄批次或机型划分才能测出真实泛化能力。3. YOLO训练实战模型选型、参数配置与增强策略3.1 模型选型不是越新越好要看算力和产线节拍这几年轻松点的局面是YOLO系列版本迭代特别快从v5到v8、v9、v10还有RT-DETR选择很多。但要记住一个原则算法选型不只看精度榜单还要看团队熟不熟、部署链条顺不顺、产线节拍能不能跟上。我的建议是默认从YOLOv8s或YOLOv8m开始。理由很实际ultralytics训练、导出生态成熟踩坑资料多v8s在640分辨率下推理延迟低边缘设备也能跑v8m在小目标和细长形态上比v8s有明显提升适合裂纹这类小目标较多的场景。如果算力非常紧张甚至可以退回YOLOv5s配ONNX Runtime精度差一些但胜在CPU上跑得动。没必要一上来就追YOLOv10或者RT-DETR——新模型结构不代表在你的缺陷数据集上必然更好很多情况下v8已经够用把精力留给数据和部署更划算。3.2 训练参数怎么设从YAML到命令行数据集准备好之后第一步是写YAMLpath: /data/aircraft_defect/ train: images/train val: images/val test: images/test nc: 6 names: [crack, corrosion, paint_peeling, dent, rivet_defect, burn]训练命令我习惯写成这样yolo train \ dataaircraft_defect.yaml \ modelyolov8m.pt \ epochs300 \ imgsz960 \ lr00.01 \ batch16 \ mosaic1.0 \ close_mosaic10 \ --patience 50几个参数的取舍值得单独说。输入分辨率是飞机表面缺陷识别里最影响结果的一个旋钮。640分辨率下细裂纹只有几个像素效果会很差960或1024能明显提升小目标召回率。代价是显存和推理时长翻倍除非有10GB以上显存否则配合m模型容易爆显存。close_mosaic10是很多新手忽略的参数。YOLO默认持续开Mosaic增强但训练后期Mosaic生成的伪目标会让模型对真实目标尺度产生错误认知。我习惯在最后10-20个epoch关掉Mosaic让模型在接近真实分布的数据上微调。学习率方面在默认SGD下lr00.01是比较稳的起点。如果batch size压到8以下lr同步调到0.005左右。训练过程中盯住loss曲线和验证集mAP到平台期就可以early stop不用傻跑满300轮。3.3 针对金属反光与光照不均的数据增强飞机蒙皮表面最大的视觉干扰是反光和光照不均。同样是裂纹直射光下可能亮得刺眼阴天散射光下可能几乎看不见。数据增强如果不做针对性处理模型在机库里稍微变个角度就失灵。我会在ultralytics的增强参数上做这些调整hsv_h: 0.02 hsv_s: 0.7 hsv_v: 0.6 degrees: 30 translate: 0.1 scale: 0.2 fliplr: 0.0 flipud: 0.0 mosaic: 1.0 mixup: 0.1这里重点说一下hsv_v和翻转。hsv_v调到0.6是为了模拟不同光照强度下蒙皮明暗变化让模型学会“只看缺陷的形态而非整体亮度”。fliplr和flipud我建议关掉——机身蒙皮上的铆钉排布、蒙皮接缝方向是有物理规律的水平翻转会让模型学到错误的几何先验。很多默认训练模板开着水平翻转在缺陷检测里反而帮倒忙。如果小目标漏检严重可以试试“缺陷复制粘贴”增强从标注样本中裁出缺陷小图经过随机缩放、旋转、亮度扰动后粘贴到无缺陷的背景蒙皮图上。这个操作能将正常背景中的“负样本”转化为优质“正样本”对小目标缺陷的提升非常明显前提是做好边缘融合别留下明显矩形接缝。4. 三个反直觉的坑小目标裂纹、易混类别与漏检权衡4.1 裂纹是细长小目标为什么AP一直上不去我在复盘实验结果时最常碰到的现象是整体mAP还行VAE特别高但crack类的AP总是拖后腿。原因很直白——裂纹天生就是细长小目标极端情况下一条裂纹宽2像素、长80像素边界框的长宽比达到40:1。YOLO的下采样结构对这类极端宽高比目标天然不友好特征图从浅到深逐级下采样细线的特征在深层特征图上几乎消失。解决办法我验证过几条提高输入分辨率960起步条件允许上1280使用带P2输出层的模型结构YOLOv8-P2能保留浅层高分辨率特征对小目标更友好大图推理用切块策略把相机拍的6K高清图切成带重叠的768小块分别推理再按坐标拼回全景训练时对小目标做过采样或复制粘贴增强。几条组合下来crack类的召回率能从65%左右拉到85%以上。单靠某一条提升有限。4.2 裂纹与划痕傻傻分不清误报怎么压这类缺陷检测项目做到中期最大的敌人不是“没检出”而是“误报太多”。最常见的误报来自裂纹和划痕、打磨痕迹的视觉相似性。在二维图像里裂纹是材料分离划痕是表面磨损但照片看起来都是细长暗线神经网络很难靠单帧RGB区分。我有几个实战有效的思路第一在类别表里加上scratch类让模型显式学习“这玩意儿是划伤不是裂纹”的分类边界这个类未必是业务要报的缺陷但能显著降低crack的误报。第二利用上下文信息做二次判定。裂纹出现在铆钉孔、铆钉连线附近有明确的工程意义而划痕往往随机分布。可以在检测后处理里增加一个规则检测框落在已知应力集中区域铆钉排、舱门角隅才保留为裂纹否则降级为提示信息。第三如果算力允许换成分割模型。YOLO-seg输出的轮廓信息比边界框丰富得多对细长形态的判别比纯框检测更细腻。缺点是标注成本翻倍——分割标注一张裂纹图比框标注慢三到五倍。4.3 漏检与误报的工业级权衡调阈值不是拍脑袋工业质检和学术竞赛最大的区别在于代价不对称。漏掉一条正在扩展的疲劳裂纹可能危及飞行安全误报一次顶多多花两分钟人工复核。所以生产环境里的风险偏好一定是“宁可多报不可漏检”。具体到工程实现我一般会把推理的conf阈值从默认的0.25降到0.15甚至0.10。别看只是阈值微调召回率能涨好几个点。代价是误报数量可能翻倍但反正下一步有人工复核兜底这个代价是可以接受的。更稳妥的做法是同时计算NMS IoU阈值对多目标重叠的影响。裂纹这种细长目标挨得很近比如一条主裂纹派生出几条分叉默认NMS 0.7会把相邻检测框合并或抑制掉一部分我习惯调到0.5左右保留更多候选框把筛选的判断交给人工或后处理规则。评估指标上与其死盯mAP0.5:0.95不如单独看每个缺陷类别的召回率。生产报告里我会列出conf在0.1、0.15、0.2三档下的Recall和F1供团队一起决定最终阈值而不是我一个人拍脑袋。5. 从模型到产线成像方案、推理优化与复核流程5.1 成像端偏振光源和相机选型模型再好拍出来的照片不行也是白搭。飞机蒙皮是高反光曲面普通室内照明下一条裂纹可能正好落在高光区完全看不出来。成像方案上我有几个明确结论。光源优先用低角度光配合偏振片。低角度光让裂纹、凹坑产生阴影增强缺陷和正常表面的对比度偏振片能滤掉金属表面的镜面反射眩光只保留漫反射信息。光线方向很讲究条形光沿铆钉排方向打纵向裂纹会格外清晰环形光则更适合检查凹坑和漆面鼓包这类圆形缺陷。相机方面静态定检场景用500万到1200万像素的全局快门工业相机就够了镜头根据检测距离选焦距景深要覆盖住机身弧面的起伏。如果将来要做地面巡检小车或机械臂自动扫查帧率至少要15fps以上否则运动模糊会毁掉图像。还有一个很容易忽略的问题是曝光和自动增益。机库环境光不断变化相机的自动曝光会让同一块蒙皮在上午和下午拍出的亮度差异巨大模型在训练数据里见得少的光照情况下会劣化。建议固定曝光参数配合遮光罩稳定环境光。5.2 推理加速ONNX/TensorRT落地实战训练阶段用PyTorch没毛病但到了产线我强烈建议导出成ONNX再转TensorRT。实测下来一张640×640的YOLOv8m在桌面级GPU上FP16推理只需3-5msCPU上的ONNX Runtime则要60-100ms。TensorRT构建的简化流程是先把ultralytics模型导出为ONNXyolo export modelyolov8m.pt formatonnx opset12然后用TensorRT重新构建engine开启FP16import tensorrt as trt logger trt.Logger(trt.Logger.WARNING) builder trt.Builder(logger) network builder.create_network(1 int(trt.NetworkDefinitionCreationFlag.EXPLICIT_BATCH)) parser trt.OnnxParser(network, logger) with open(yolov8m.onnx, rb) as f: parser.parse(f.read()) config builder.create_builder_config() config.set_flag(trt.BuilderFlag.FP16) engine builder.build_engine(network, config) with open(yolov8m_fp16.engine, wb) as f: f.write(engine.serialize())这里有个坑我要提醒一下如果模型训练时用了960分辨率导出和构建engine时的输入尺寸要固定为960×960推理时也保持同样尺寸否则精度会有明显回退。边缘侧部署如果没有GPU可以考虑自带NPU的嵌入式板卡或者退而求其次用CPU方案。CPU上要重点优化预处理和后处理图片缩放到模型输入尺寸的resize操作用OpenCV的INTER_LINEAR就够避免多余的色彩空间转换。5.3 人机协同AI预警人工复核把AI当成“自动判罚系统”是很多工业项目的认知误区。飞机表面缺陷识别的正确落地形态是“机器筛、人复核”。具体流程是相机采集图像后模型以较低的置信度阈值输出所有候选缺陷系统把这些候选框按类别和置信度分级红色预警直接推到复核工位黄色提示进入一般队列检测人员只对预警框区域做二次目视确认确认结果实时录入系统。这套流程跑起来以后我的体感是单个机位的目检工作量降低了六成以上人的精力可以集中在有限数量的预警框上漏检率反而比纯人工更低。更重要的是复核人员每一次确认结果都在为数据集贡献新标签——误报的图像被标记为负样本漏检的图像被补上标注框再回流到训练集。6. 数据闭环新缺陷回流与主动学习实战6.1 产线新缺陷回流机制模型上线不是终点而是数据收集的起点。真实产线上遇到的缺陷形态一定会比训练集里见过的更杂。比如南方沿海地区的腐蚀形态和北方干燥地区的很不一样不同批次的蒙皮材料漆面剥落的表现也不一样。所以我坚持在部署系统里加一个“自动导出”功能凡是模型预测置信度在0.2到0.5之间的样本以及人工复核时判定为误报/漏检的样本全部自动存进待标注池。每周固定一个迭代批次把池子里的样本拿给人补标追加进训练集做增量训练。这个闭环看起来简单但很多团队做到这一步就停了。原因通常是增量训练流程太粗糙——新数据直接混进原训练集重训没有版本管理结果指标忽高忽低。我的做法是给数据集和模型都打上版本号每次迭代固定数据快照训练前先验证新模型在旧测试集上的指标没有倒退再部署。6.2 主动学习让模型自己挑难例数据回流如果全量让人工标注成本依然很高。更聪明的做法是让模型自己挑“有价值的样本”。我的标准做法是用当前模型对产线新增图片做批量推理把置信度记录排序。置信度极高比如0.9以上和极低0.05以下的样本价值最低——前者模型已经很确定了直接采纳为伪标签或负样本后者要么是背景要么是太难标注员效率也低。最有价值的是置信度在0.3到0.6之间的“犹豫区”样本这些就是模型没学明白的难例。实际落地时我还会加一个“类别不确定度排序”同一张图模型在crack和scratch之间反复横跳、两个类别置信度接近的样本优先级最高。这类易混样本对模型的帮助远超随机抽取的新图。6.3 迭代节奏与团队协作数据闭环这件事最怕“三天打鱼两天晒网”。我自己的节奏是首个版本从标注到训练压到三周以内跑通先让模型处理80%的简单场景上线后每月做两轮增量训练每轮追加500到1000张高质量标注图每季度做一次全量重训覆盖所有历史数据刷新基线模型。团队协作上我强烈建议标注、算法、现场三方每周对一次“bad case”。标注员不理解缺陷工程背景很容易把腐蚀标成漆面剥落算法工程师不现场看也不知道铆钉阴影才是误报主力。这个沟通成本省不得。另外一个小提醒数据集版本管理做扎实。我见过不止一次同事在旧分支上改了标注新分支又训练了新模型最后对不上账白白浪费两周时间。Git LFS管理图片和标注文件训练前锁定commit简单有效。最后再说一个我自己很受益的小技巧每次增量训练之后不急着替换线上模型。先在产线上并线跑三天对比新旧模型的误报率和漏检率确认没有回归后再切换。AI质检这种场景稳定性永远比峰值精度更重要。
