企业官网建设流程全解析

1. 先把问题定义清楚：这个项目到底在识别什么

1.1 人工登塔看片的老路，卡在哪儿了

做电网绝缘子缺陷识别的第一课，不是搭模型，而是搞清楚这件事原来是怎么干的。我接触过的巡检流程大致是这样：无人机沿着航线飞一基杆塔，拍下上百张照片，回来之后由班组里的老师傅一张张翻，看到伞裙缺了一块、玻璃件爆了、表面有放电烧蚀痕迹，就截图归档、开缺陷单。一个架次动辄三五百张图，一个班组一天要看几千张，眼睛花、效率低，更麻烦的是漏看——绝缘子自爆这种缺陷，在整张四千像素的大图上可能只占几十个像素，翻快了就过去了。

这套流程的瓶颈特别明显：一是人力线性增长，杆塔数量涨了，看片的人也得涨；二是判断标准依赖个人经验，同一张图两个人可能给出不同结论；三是缺陷从发生到被发现的时间窗口太长，等季度巡检发现时，可能已经发展成掉串隐患。深度学习在这个场景里真正有价值的地方，不是"炫技"，而是把"从海量图里挑出可疑的那几十张"这件事变成秒级的事，人只需要复核少量候选，工作量和漏检率都能压下来。

所以项目一开始我就把定位说死了：这是一套辅助筛查系统，不是全自动判决系统。它负责从几千张图里把疑似的挑出来并排好优先级，最终定性还是人说了算。这个边界定清楚了，后面很多技术选型的纠结就迎刃而解——比如要不要为了 0.5 个点的 mAP 上一个超大模型，答案是不值得，因为召回率和推理速度才是这个场景的硬约束。

1.2 检测、分类、分割，别一上来就选最贵的

新手最常见的误区是：什么任务都往分割上靠。我见过不少方案，一上来就要做像素级分割，理由是"缺陷边界要精确"。听起来合理，实际落地时几乎都会被标注成本和推理开销拖死。我一般按缺陷类型分层处理，不同任务用不同形式：

我的实际选择是"分类粗筛 + 检测精定位"的两级结构。第一级用轻量分类网络把明显正常的图扔掉，第二级用检测器在剩下的图上找缺陷。这个结构的收益很直接：原本一千张图全要跑检测器，现在可能只有两百张进第二级，整体吞吐直接提升三到四倍，而正常图本来就不需要精细定位。代价是分类器本身要足够保守，宁可多放一些正常图进第二级，也不能把带缺陷的图误判成正常扔掉——这是一个单向的错误代价问题，阈值必须往召回那边偏。

1.3 把缺陷清单翻译成算法能听懂的语言

拿到业务方给的缺陷描述，第一件事是翻译。业务上说"绝缘子破损"，算法上要拆成：玻璃件的自爆（伞盘缺失一整块）、瓷件的伞裙崩边（边缘小缺口）、串体整体倾斜（可能是掉串前兆）。这三类在图像上的表现完全不同，标注规则、样本量、识别难度也完全不同，混成一个"破损"类别是自找麻烦。

同样，"异物"这个词也很笼统。鸟巢、塑料薄膜、风筝线、气球残片在图上形态差异巨大，颜色、尺寸、纹理都不同，硬塞进一个类别，模型会学出一个"什么都有可能"的模糊边界，置信度分布会非常难看。我一般是先拆细，样本量实在撑不起来的再合并，并且合并时优先合并视觉特征相近的，比如把几种挂线状异物归为一类，而不是把鸟巢和塑料布放一起。

这一步做完，你会得到一张带优先级的缺陷清单：哪些必须查出来（自爆、掉串），哪些可以容忍漏检（轻微污秽），哪些先不做（需要专用传感器才能判定的内部缺陷）。这份清单直接决定了后面损失函数的权重设计和评估指标的计算方式，是整条链路上最不能偷懒的一步。

2. 数据这一关，直接决定项目天花板

2.1 三条采集渠道，各有各的坑

数据来源我试过三条路，实际项目里基本都是混着用。

自有巡检图是主力。它的优点是视角、设备、光照和上线时完全一致，分布贴得最紧；缺点是缺陷样本天然稀疏，可能几万张里只有几百个真缺陷，而且这些图是给人工看片用的，构图未必适合算法。我踩过的一个坑是：早期直接用原图缩放训练，结果模型学到的是"绝缘子在画面中央"这种伪相关，因为巡检航线是居中对准杆塔的，模型很快就学会偷懒不看细节。

公开数据集能快速把流程跑通，适合做骨架验证和预训练，但和实际场景的差异往往大到不能用。我在验证阶段用公开数据训出来的模型，换到自有数据上 mAP 直接腰斩，原因就是背景、拍摄高度、器件型号全变了。

仿真合成是我认为被低估的一条路。用三维重建的杆塔模型，在虚拟场景里换光照、换天气、换拍摄角度渲染，专门生成缺陷样本。它解决的是长尾问题，不是替代真实数据。合成数据的价值在于把"缺样本"的类别补到能训起来，但绝对不能只用合成数据训练，否则模型会学到渲染器的伪影——我曾经遇到过模型对某个特定阴影极度敏感，查了半天发现是渲染引擎的出图特征。

注意：任何合成数据进入训练集之前，必须做一次"真伪可分性"检验——用一个小分类器试着区分真实图和合成图，如果轻松分开，说明渲染特征太明显，这批数据要么加更强的域随机化，要么降低采样权重。

2.2 标注规范不写死，后期返工能返到你怀疑人生

标注这件事，最贵的不是人力，是返工。我现在的做法是先写一页纸的标注细则，逐条给正例和反例截图，标完一百张先做一致性验收，通过率不到 90% 就停下来改细则，绝不批量铺开。

细则里必须写死的东西包括：框的边界怎么贴（贴外轮廓还是贴可见区域，被遮挡一半怎么处理）、最小可标尺寸（我一般定在原图短边千分之四，低于这个像素数不标，因为模型也学不会）、相邻同类目标粘连时是分开标还是合并标、以及最容易扯皮的"疑似"怎么处理。疑似缺陷我单独设一个suspicious类，不混进正类，训练时权重降一半，这样既保留了信息，又不会污染主类别的分布。

另一个容易被忽略的点是标注一致率的量化。我的做法是从标注集里随机抽 200 张，让两个人独立标，算 IoU 大于 0.5 的匹配率和类别一致率。这两个数如果低于 0.85，说明细则本身有歧义，不是标注员的问题。很多人一上来就怀疑模型不行，其实模型只是忠实反映了标注里的噪声——你给它一堆自相矛盾的标签，它学出来的决策边界必然是糊的。

2.3 长尾分布怎么补，别只盯着过采样

绝缘子缺陷数据的长尾程度，用数字说比较直观：我手上的一批数据里，正常串体样本六万多，自爆样本不到四百，比例接近 150:1。这种分布下，你直接训练，模型会倾向于把所有东西都判成正常，因为这样 loss 最小。

我试过的组合拳，按性价比排序：

• 复制粘贴增强：把已标注的缺陷区域抠出来，贴到正常图的合理位置上（绝缘子串区域），配合色彩、亮度、缩放扰动。这个手段对小目标缺陷特别有效，我靠它把自爆样本从四百扩到了四千多，召回涨了将近二十个点。关键细节是粘贴位置要限制在串体掩膜内，否则模型会学到"缺陷出现在奇怪位置"的错误先验。
• 损失函数重加权：分类分支用 focal loss 压低易分样本的贡献，回归分支对稀有类别的样本加权。权重别拍脑袋设，我一般按类别频次的平方根倒数来定，再手动微调。
• 切片采样：把大图切小之后，含缺陷的切片在采样时重复更多次。这个办法的副作用是训练集分布变了，验证集和测试集一定要用原始未采样分布，否则指标虚高。
• 难例挖掘：每轮训练后把假阴性样本捞出来，人工确认后加进训练集。这条最慢但最有效，我的经验是三轮迭代能解决大部分"模型死活学不会"的个案。

3. 模型选型：为什么最后落在单阶段检测器上

3.1 两阶段和单阶段的取舍，本质是速度换精度的账

两阶段检测器在精度上确实有优势，尤其是小目标和密集目标。但这个项目里我没有选它，理由很实在：部署端是边缘盒子，算力有限，巡检队希望的是"落地就能出结果"，而不是"传回机房慢慢算"。

我做过对比测试，同一批数据、同样的输入分辨率，两阶段方案的 mAP50 比单阶段高大概 1.5 到 2 个点，但单帧推理时间差了三倍以上。放到实际业务里，这三个点换不来任何决策变化——因为最终还有人工复核这一层，模型多找一个少找一个，复核员的工作量差别不大，但推理慢三倍意味着一个架次的图要跑几个小时，这个体验是灾难性的。

所以我的结论是：在保证召回的前提下，速度优先。单阶段检测器的精度损失可以用输入分辨率、数据增强和切片推理补回来，但速度损失补不回来。

3.2 输入分辨率这笔账，得算清楚再定

输入分辨率是这个项目里最需要精打细算的参数。原图一般是 4000×3000 这个量级，直接缩到 640 输入，绝缘子自爆的缺口在特征图上可能只剩两三个像素，等于直接抹掉了。

我算过一笔账：一架次典型拍摄高度下，绝缘子串在图中长度约 1200 像素，自爆缺口宽度约 60 像素。如果输入缩到 640，缩放系数是 0.16，缺口只剩不到 10 像素，勉强能学但极不稳定；输入 1280 时缺口有 19 像素，召回明显稳。但 1280 输入的计算量是 640 的四倍，边缘盒子扛不住。

最终的解法是切片推理：训练和推理都按 1280 的窗口在原图上滑动切块，相邻块重叠 20%，保证跨界的缺陷至少完整出现在一个块里。重叠率的算法很简单，要求重叠长度大于目标最大尺寸即可——我按最大目标 300 像素算，1280 窗口下重叠 256 像素（20%）已经够用，再高只是浪费算力。

这条路的代价是后处理复杂了：同一个缺陷可能被两个块同时检出，需要做跨块的框合并。我用的是按类别分组做 NMS，重叠阈值 0.5，配合位置还原（把块内坐标加上块的偏移量，映射回原图坐标）。这块逻辑写起来不难，但坐标换算一定要反复验，我第一版就是因为没处理图像 padding 导致的偏移，结果所有框整体偏了一百多像素，排查了大半天。

3.3 水平框还是旋转框，看你的绝缘子串歪不歪

航拍视角下，绝缘子串在画面里经常是斜的，长宽比能到 4:1 甚至 6:1。用水平框标它，框里会塞进大量背景，模型学到的特征里掺了一半是干扰。

如果只做缺陷检测、不做串体定位，水平框其实够用——因为缺陷本身（自爆缺口、破损）形状不规则，水平框的包围误差不影响判断。但如果你的流程里需要先定位整串绝缘子、再在串内找缺陷，那旋转框值得上，它能把背景压到最小，串体的定位精度提升很明显。

我的折中方案是：串体定位用旋转框，缺陷检测用水平框。两套头分开训，共享骨干网络。这样既拿到了串体定位的精度，又不用为小缺陷承担旋转框的标注和回归复杂度。训练时注意两套任务的损失权重要平衡，我的经验是串体定位损失权重给 1.0，缺陷检测给 2.0，因为后者是主任务。

3.4 骨干网络选型的三个硬指标

选骨干网络我一般看三个指标，不看论文里的 FLOPs 排名：

一是小目标特征保真度，具体看网络最深层的下采样倍数。总下采样 32 倍的网络，1280 输入下特征图只有 40×40，小缺陷根本留不下；我倾向于用下采样 16 倍的输出层做检测头，必要时再加一个下采样 8 倍的高分辨率分支，代价是显存涨得厉害。

二是边缘设备的实测帧率，不是 GPU 上的理论值。同一个网络在桌面卡和边缘盒子上差距能有五倍，必须以目标硬件实测为准。

三是量化的友好度，有没有大量对量化敏感的结构（比如某些归一化层、特殊的激活函数）。我吃过亏，选了个结构花哨的骨干，INT8 量化之后精度掉了六个点，只能退回 FP16，速度优势全没了。

4. 训练实操：从配置到收敛的完整记录

4.1 环境与目录组织

环境这块我不迷信最新版本，能用稳定版就用稳定版，因为训练脚本跑通之后没人愿意再动它。我用的组合是 Python 3.10 + PyTorch 2.x + CUDA 11.8，显卡单卡 24G 显存，1280 输入、批大小 8 能跑满。

目录结构我固定成这套，多人协作时能少吵很多架：

insulator_defect/ ├── data/ │ ├── images/{train,val,test} │ ├── labels/{train,val,test} │ └── dataset.yaml ├── configs/ │ ├── train_1280.yaml │ └── infer_slice.yaml ├── weights/ │ └── pretrain_backbone.pth ├── scripts/ │ ├── train.py │ ├── slice_infer.py │ └── eval.py └── runs/

dataset.yaml里最容易被写错的是类别顺序。类别 id 和名字必须和标注文件里的 id 严格对齐，我见过一次因为顺序错位，模型把"自爆"学成了"异物"，训了两天才发现，白烧了几十块电费。

path: ./data train: images/train val: images/val test: images/test nc: 6 names: 0: insulator_string 1: self_explosion 2: broken_shed 3: flashover_trace 4: foreign_object 5: missing_pin

4.2 训练启动与关键超参的设定逻辑

启动命令本身很简单，难的是超参怎么定。我一般分两段训：先冻结骨干、只训检测头，学习率给 1e-3，跑 20 轮，让头部快速收敛；再解冻全部、学习率降到 1e-4，配合余弦退火跑 150 轮。这个两段式的好处是避免一开始就用大学习率把预训练权重冲坏。

python scripts/train.py \ --cfg configs/train_1280.yaml \ --weights weights/pretrain_backbone.pth \ --img-size 1280 \ --batch 8 \ --epochs 170 \ --lr0 0.001 \ --lrf 0.01 \ --freeze 10 \ --mosaic 0.8 \ --mixup 0.1

几个参数值得单独说：

mosaic 增强给 0.8，不给 1.0。四图拼接对小目标友好，但拼得太狠会让缺陷出现在不符合物理规律的位置（比如绝缘子悬在半空），模型会学到错误的空间上下文。我留 20% 的样本用原图训，当作"纠偏"。

mixup 只给 0.1。这个增强对分类任务友好，对检测任务其实有副作用，因为两张图叠加后框的归属会变模糊。给小值主要是为了平滑决策边界，不能给大。

学习率不设 warmup 太长。我一般 warmup 3 轮就够，设长了在冻结阶段会浪费大量轮次。

训练日志我主要盯三个数：分类损失、回归损失、以及验证集的召回率。分类损失和回归损失如果长期不同步（一个降一个不降），基本可以判定是标注质量或者类别不平衡的问题，而不是模型结构问题。召回率我按类别分开看，因为平均值会掩盖稀有类的糟糕表现——总召回 0.9 但自爆类召回只有 0.5，这模型是没法上线的。

4.3 评估指标怎么看才不骗自己

评估这件事，我最反对的是只看 mAP50 一个数。这个指标在类别不平衡的数据上特别容易好看，因为优势类别会把平均值拉上去。

我实际用来做决策的指标是这几个：

每张图平均误报数这个指标，很多方案里不写，但它才是决定系统能不能被一线接受的关键。你想想，如果一个架次五百张图，每张蹦出三个误报，复核员要处理一千五百个框，他第二天就会把这系统关掉。宁可少报，不可乱报，这个原则贯穿了我的阈值选取。

阈值怎么定，我的做法是在验证集上画 PR 曲线，找到满足"关键类召回 ≥ 0.92"的最低置信度点，然后把这个阈值再往下压 0.05 作为上线值，留一点余量应对真实场景的分布漂移。这不是最优的 F1 点，但在业务上是合理的——漏检的代价远大于多报几个让人看一眼。

5. 部署落地：把模型塞进边缘设备

5.1 导出链路和踩过的坑

训练完的模型不能直接扔到边缘设备上跑，中间要走一遍导出。我的链路是 PyTorch → ONNX → TensorRT，每一步都有坑。

导出 ONNX 时最常见的问题是动态维度。切片推理的输入尺寸是固定的（1280×1280），所以我直接固定 shape 导出，避免动态轴带来的优化损失。另外一个坑是后处理里的 NMS，如果写进模型图里，某些算子在不同版本的推理引擎上行为不一致，我现在的做法是把 NMS 挪到 CPU 侧用自己写的代码做，模型只输出原始预测，这样跨平台一致性最好。

import torch model.eval() dummy = torch.randn(1, 3, 1280, 1280) torch.onnx.export( model, dummy, "insulator_1280.onnx", input_names=["images"], output_names=["preds"], opset_version=12, do_constant_folding=True, )

TensorRT 转换时，工作空间给足，FP16 是默认选项。我在边缘盒子上实测，FP16 相比 FP32 大概快 2.2 倍，精度损失在 0.3 个点以内，完全可以接受。INT8 更快，但要准备校准集，而且小目标检测对量化误差特别敏感，我试过一次，自爆类召回掉了四个点，最后放弃了。

5.2 切片推理的工程实现细节

切片推理的代码不长，但每一行都有讲究。核心逻辑是：按窗口滑动切图，每块单独推理，把结果映射回原图坐标，最后跨块合并。

def slice_infer(img, model, win=1280, stride=1024, conf=0.25): H, W = img.shape[:2] all_boxes = [] for y in range(0, max(H - win, 0) + 1, stride): for x in range(0, max(W - win, 0) + 1, stride): patch = img[y:y+win, x:x+win] ph, pw = patch.shape[:2] if ph < win or pw < win: patch = cv2.copyMakeBorder( patch, 0, win-ph, 0, win-pw, cv2.BORDER_CONSTANT, value=(114,114,114)) preds = model(patch) for b in preds: if b.score < conf: continue all_boxes.append([ b.x1 + x, b.y1 + y, b.x2 + x, b.y2 + y, b.score, b.cls ]) return nms_per_class(all_boxes, iou_thr=0.5)

两个细节必须注意。一是边缘补边，图的最右侧和最下侧往往不足一个窗口，直接切会导致尺寸不对。补边用的填充值要和训练时的 letterbox 填充值一致（我用 114），否则边缘区域的特征分布会突变，容易产生虚假检测。二是坐标裁剪，映射回原图后要把超出图像边界的框裁掉，我第一版忘了这步，结果出现了大量负坐标的框，下游系统直接报错。

滑动步长我设成 1024，也就是 1280 窗口的 80%，重叠 256 像素。这个值是按最大目标尺寸倒推的：目标最大长度约 240 像素，只要重叠大于它，任何目标至少完整落在一个窗口里。

5.3 吞吐量估算，别等上线才发现跑不完

部署前一定要做一次端到端的吞吐估算，我见过太多项目在这个环节翻车。

假设一张原图 4000×3000，1280 窗口、步长 1024，横向需要ceil((4000-1280)/1024)+1 = 4个窗口，纵向ceil((3000-1280)/1024)+1 = 3个窗口，总共 12 个切片。单切片在边缘设备上推理耗时 60 毫秒，12 个就是 720 毫秒，加上前后处理大概 900 毫秒一张图。一个架次 500 张，串行处理约 7.5 分钟。

这个数字是可以接受的，因为巡检回来本来就要等，七分钟出结果比人工看两小时强太多。但如果你的设备单切片要 200 毫秒，那 500 张就是 20 分钟，体验就会开始变差。这时候的优化方向不是换模型，而是先用分类器粗筛，把明显正常的图直接跳过，通常能砍掉 70% 的图，整体时间降到 6 分钟左右。

提示：估算的时候一定要留 30% 的余量，因为真实场景的图片尺寸不统一、磁盘 IO 和内存拷贝都会拖慢整体速度，纸面算出来的数字在实际部署时普遍要打个七折。

6. 上线之后的坑：问题排查实录

6.1 漏检和误检，要分开归因

模型上线后出的问题，八成可以归到两类：漏检和误检。这两类的排查路径完全不同，混在一起查会浪费大量时间。

漏检我先看三件事：一是看这个缺陷在原图里到底有多大，如果小于训练时设定的最小尺寸，那不是模型的问题，是任务定义的问题；二是看这个样本的形态是否在训练集里出现过，比如侧视角的自爆，如果训练集全是正视角，模型不认识很正常；三是看置信度分布，如果大量真缺陷的置信度卡在 0.1 到 0.2 之间，说明模型"看到了一点但不确定"，这通常是类别不平衡或者标注噪声导致的，不是能力问题。

误检的排查更依赖可视化。我一般会把误检框抠出来做成一张拼图，一眼就能看出规律。最常见的三种：一是把正常的伞裙边缘阴影当成裂纹，这类在强光斜射时特别多；二是把杆塔上的螺栓、金具当成绝缘子缺陷，本质是上下文特征不够；三是把远处的植被纹理当成异物，这是切片边缘的填充区域带来的伪影。

针对第一种，我加了一组针对性的负样本——专门挑强光斜射的正常图，标成背景，然后重新训。这个手段效果非常直接，一轮就能把这类误检压下去大半。针对第三种，把填充值改成镜像填充，伪影基本消失。

6.2 常见问题速查表

这张表是我踩坑攒下来的，基本覆盖了这个项目百分之八十的线上问题：

6.3 告警分级和人工复核闭环，才是系统的终点

模型输出一堆框，直接丢给业务系统是没有意义的。我做的分级是这样：

置信度高于 0.7 的，直接生成待复核工单，标记为高优先级；置信度在 0.35 到 0.7 之间的，进低优先级队列，复核员有空再看；低于 0.35 的直接丢弃，不展示。这个分级让复核员的工作量从"每张图都要看"变成"每天看几十个高优工单"，接受度完全不同。

闭环的另一半是误报回流。复核员标记为误报的图，我要求必须回传，并且记录误报类型。这些样本每周汇总一次，人工确认后加进训练集，做一轮增量训练。这个机制建立起来之后，模型的误报率在三个月里从每图 0.8 个降到了 0.2 个，效果比任何一次架构调整都明显。

这套闭环里最容易断的一环是"人懒得标"。我的解决办法是把回传做成复核流程的必填项，不填就不能关闭工单，同时每个月给复核员看一次"因为你标的这些样本，模型进步了多少"的对比图。人看到自己的标注真的有用，配合度会高很多，这比发文件强调重要性管用。

7. 最后分享几条实打实的心得

做这类项目，我最深的体会是：算法只占三成，数据工程和流程设计占七成。我见过太多团队把精力全砸在调模型上，换了五六个骨干网络，mAP 涨了一个点，结果上线之后因为误报太多被一线弃用。反过来，数据清洗干净、标注规范统一、阈值定得合理，用一个结构很普通的检测器也能跑出让人满意的效果。

第二条心得是别追求一次性做全。缺陷类型有十几种，一上来全做，每类样本都不够，模型哪类都学不好。我的做法是先做两三类高频、高危害的，把整条链路跑通、跑稳，让业务方看到价值，然后再一类一类往上加。每加一类，只针对这一类补数据、调阈值、做验证，风险可控，进度也好汇报。

第三条是测试集一定要独立，而且要按场景分桶。我现在的测试集按拍摄高度、光照条件、器件型号分了几个桶，每次评估都出分桶报告。这样模型在哪个场景弱，一眼就能看出来，不用等线上出问题才知道。这个习惯帮我省了无数次返工。

如果这个项目还要往下走，我下一步想试的是把检测和缺陷程度分级结合起来——不只是判断"有没有缺陷"，还要判断"缺陷发展到什么程度"，比如自爆的伞盘缺了几片。这就从检测问题变成了细粒度分类问题，标注要求更高，但对运维决策的价值也更大。这条路不好走，但值得试。