企业官网建设流程全解析

做电力巡检的朋友应该都有同感：绝缘子缺陷检测这事儿，看着是目标检测的常规课题，真扔到现场环境里就全是坑。无人机飞一趟拍回来的图，阳光直射、雾霾遮挡、抖动模糊、微小裂纹……哪一样都在挑战模型的底限。我这次把YOLO11和自研的LQEHead检测头结合起来，从头搭了一套绝缘子缺陷检测与分类系统，从网络结构改到数据标注，再到训练调参和边缘设备部署，踩了不少坑，也趟出了一条能复用的路子。这篇文章就是完整记录，不仅讲清楚LQEHead为什么这么设计，还会把训练参数、数据集处理、常见报错这些实操细节一并交代清楚。

这个项目适合谁参考？如果你正在做电力监测类的视觉项目，或者想在YOLO11基础上做检测头的轻量化改造，又或者只是被无人机巡检图里的小目标绝缘子折磨过，这篇内容应该能省下你几个通宵。

1. 项目背景与目标拆解

1.1 绝缘子缺陷检测为什么是刚需

输电线路上的绝缘子承担着电气绝缘和机械支撑双重作用，一旦出现自爆、破损、闪络痕迹，轻则线路跳闸，重则引发大面积停电事故。传统巡检全靠人工登塔或望远镜目测，效率低、危险性高，而且山区、跨江河的杆塔往往巡检周期长，缺陷发现滞后。这几年无人机巡检普及之后，单次飞行能拍回几千张高清图，但积压的海量图片靠人眼筛查，一个熟练工一天也看不了多少，漏检率还不低。所以用目标检测模型做自动缺陷识别，不是锦上添花，而是刚需。

但绝缘子检测又和通用目标检测不太一样。它有几个比较棘手的特性：

• 目标尺度差异大。无人机在杆塔附近拍摄时，绝缘子串可能占图片很大面积；但在航线更高时，一串绝缘子只有几十个像素，属于小目标甚至极小目标。

• 背景复杂度高。铁塔横担、电线、树木、地面、天空都会出现在图像里，绝缘子和背景纹理经常混淆。

• 缺陷样本稀缺且形态多样。正常绝缘子是绝大多数样本，而缺陷类别（自爆、破损、闪络）本身就少，加上每种缺陷的视觉表现差异大，很难靠大样本堆出高精度。

• 部署端算力受限。巡检图片通常在飞控终端或边缘盒子上处理，不可能挂着一块大功率显卡去推理。

这些特性决定了模型既要检测精度高、小目标能力强，又要参数量可控、推理速度快，正好对上了标题里“YOLO11 + LQEHead”这套组合的定位：用YOLO11做高效的骨干特征提取，用LQEHead解决绝缘子检测场景下的细粒度分类和轻量化部署问题。

1.2 项目最终要交付什么

项目目标很明确：输入无人机拍摄的绝缘子图片或视频帧，输出每个绝缘子的位置框和缺陷类别标签。这里我把类别定为四类：正常绝缘子（Normal）、自爆（Self-Explosion）、破损（Broken）、闪络痕迹（Flashover）。自爆和破损在图像上的特征差异其实不小——自爆往往表现为绝缘子伞裙大面积碎裂缺失，破损则是边缘或局部的机械损伤，闪络痕迹则带有明显的放电烧灼痕迹和颜色变化。分类做得越细，现场维护人员就能越快地决定是安排停电检修还是计划性更换，价值是直接体现在运维成本上的。

系统分成三个模块：数据端（采集与标注）、训练端（YOLO11-LQEHead训练与评估）、部署端（模型导出与推理）。我后续会按照这三个模块逐一展开，每个环节都会给出可以直接抄作业的配置和代码层面说明。

2. 整体方案选型与LQEHead设计思路

2.1 为什么选YOLO11做基座

选哪个检测框架做基座，是项目一开始就要拍板的事。我评估过YOLOv8、YOLOv9、YOLO11，以及几个专门做小目标检测的变体。最后选YOLO11的理由，可以分成三块。

第一是结构上的优势。YOLO11延续了CSPNet的思想，骨干网络用C3k2模块替换了YOLOv8的C2f模块，在保持特征融合能力的同时减少了冗余计算。颈部网络引入了C2PSA（基于注意力机制的跨阶段模块），能够更好地建模全局上下文信息。这对绝缘子检测很重要——输电线路图像往往背景笔画复杂，如果模型看不到更大范围的上下文关系，很容易把横担的边缘误判成绝缘子。

第二是Anchor-Free和动态标签分配。绝缘子的形状比较固定，但长宽比在不同拍摄角度下变化很大。Anchor-Free机制让模型不用预先设定锚框比例，训练起来少了很多调参的负担。动态标签分配则能根据预测质量动态地为每个目标匹配正样本，在小目标比较密集的场景下，这种机制会比固定分配更稳定。

第三是工程生态。YOLO11有官方的训练、验证、导出流程，方便做ONNX和TensorRT部署，并且对小模型的优化做得比较好，适合把模型塞进边缘设备。很多改检测头的方案别人看不懂，做成YOLO系列至少大家能快速复现。

2.2 LQEHead是什么：轻量化设计加质量增强机制

LQEHead这个命名，拆开来就是Lightweight Quality Enhancement Head，轻量化质量增强检测头。它解决的痛点直接来自绝缘子检测的两个核心矛盾：检测头既要足够轻，让整体模型跑得动边缘端；又要有足够强的判别能力，把正常绝缘子和各种缺陷区分开。

为什么改检测头而不是改骨干？这是选型阶段想得比较清楚的一件事。骨干网络主要负责任何目标共通的底层特征提取，通用性强，YOLO11自带的C3k2和C2PSA已经做得够好了。而检测头直接影响最终的分类置信度和回归定位精度，它是和任务场景关系最密切的部分。绝缘子缺陷分类面临的问题是“特征细粒度差异”——正常和自爆之间的差异可能集中在伞裙缺失的纹理边界上，默认的头部分辨这种差异的能力有限。如果改骨干，改动成本高、容易破坏预训练权重带来的收益；改检测头则灵活得多，而且设计得当的话，参数量增加非常有限。

LQEHead的设计目标是三个：分类分支能聚焦缺陷细粒度特征、回归分支能对长条状绝缘子目标更友好、整体参数和计算量不拖累推理速度。围绕这三个目标，我从下几个方面改动YOLO11原本的Detect头。

2.3 轻量化改造的具体做法

轻量化这块，我采取的策略是“能少用标准卷积就少用，能用深度可分离卷积就不用普通卷积”。

原版YOLO11检测头的分类分支和回归分支各自有几层3x3卷积堆叠，用于将骨干和颈部的多尺度特征映射到预测空间。这些卷积虽然不重，但叠加在一起仍然占据了模型不小的一部分参数。我在LQEHead里做了这样的替代：

• 将分类分支中第二个3x3标准卷积替换为深度可分离卷积（Depthwise Separable Convolution），分解成深度卷积加1x1点卷积。深度卷积负责空间特征的提取，点卷积负责跨通道特征融合，参数量大约是原来的1/9到1/8，计算量也明显下降。

• 回归分支因为对空间位置的敏感度更高，我在第一条卷积层保留标准3x3卷积，后续再引入深度可分离卷积做通道压缩，保证定位特征不被过度“压扁”。

• 引入共享卷积策略。在FPN/PAN输出的三个尺度（P3、P4、P5）之间，检测头不会每个尺度都放一套完全独立的卷积，而是在部分层共享卷积参数，再通过尺度感知的调制因子去区分不同尺度目标。这样三个尺度的head加在一起，参数量比原版Detect头更小。

这里有一个权衡值得说明：深度可分离卷积的问题在于显式建模通道间关联的能力弱，如果直接堆很多层，精度会掉得比较明显。所以我的策略是“前重后轻”，靠近预测输出端的层使用更轻的结构，靠近特征输入的层保留更强的特征变换能力。实测下来，参数量降了约22%，mAP只降了0.4个点左右，这个交换是非常划算的。

2.4 质量增强模块：分类与回归置信度对齐

绝缘子检测还有一个容易被忽略但影响很大的问题：分类置信度和定位准确度不对齐。什么意思？模型对某个目标分类非常自信，但预测框偏移得厉害；或者框回归得很准，分类却犹豫不决。这会给后端的阈值筛选带来很大困扰——现场调试的时候，你会发现无论怎么调置信度阈值，总有一些又准又稳的框被滤掉，或者一些飘忽不定的框漏出来。

针对这个问题，我在LQEHead里引入了一个轻量的质量增强模块，名字叫QEM（Quality Enhancement Module）。它的核心思路是在分类分支和回归分支之间建立一个互相调制的通路：

1. 对分类特征图分别做全局平均池化和全局最大池化，得到两个通道描述向量，再接一个共享的全连接层，生成通道层面的注意力权重。这一步本质上是在做通道维度的特征重新校准，让分类分支更关注缺陷相关的关键通道。

2. 把这一步得到的通道注意力动态地注入到回归分支的定位响应上，让回归分支在解码时越“看重”某个通道，定位输出的置信度调节就越明显。

3. 最终在训练阶段，我用分类分数乘以预测框与真实框的IoU作为联合质量分数，参与正负样本的分配和损失函数的加权计算。

这个设计为什么有效？因为绝缘子缺陷的判别往往依赖颜色纹理的局部差异（比如闪络痕迹的颜色发黑、自爆的空洞纹理），这些信息分布在特定的通道上。QEM让分类分支自动学习去加权这些通道，同时把这个加权信号同步到回归分支，使得某个目标分类置信度高的时候，回归框的质量也确实配得上这个置信度。训练完对比了一下，加了QEM之后，相同置信度阈值下，正确检测的召回率高了大约6到8个百分点，这正是“质量增强”四个字的意义。

3. 数据集构建与标注规范

3.1 数据来源与构成

讲到绝缘子检测，数据永远是最头疼的一环。不是不想用大模型，而是缺陷样本真的太少了。我这个项目的数据大概来自三块：无人机在数条110kV和220kV线路上拍摄的巡检影像、部分变电站人工巡检拍摄的杆塔照片、以及网上能找到的公开绝缘子数据集中和场景比较接近的部分。三块合在一起，经过清洗后共13200张图片。

清洗这一步，很多人不重视，但直接影响模型上限。我做了两个重要处理：一是把所有重复或高度相似的帧去掉，防止模型在重复帧上过拟合；二是将图像质量差到连人都无法正确判别的删除。模糊、过曝、严重雾霾的图，除非有特殊考虑，否则不进入训练集。因为绝缘子缺陷的标注本来就是人工经验判断，如果原图质量不行，标注噪声就会非常大，模型学到的就是噪声。

最终数据集按8:1:1划分，训练集10560张，验证集1320张，测试集1320张。测试集和训练集在图片来源上做了严格隔离，也就是同一段航线拍回来的图不会既出现在训练集又出现在测试集，这样评估指标才有意义。

3.2 标注类别与边界约定

标注是另一个决定成败的环节。四类目标的标注边界，我在项目启动前就和参与标注的同事对齐过，定了几条硬规矩：

• 正常绝缘子：只标注视觉清晰、结构完整的绝缘子串。模糊不清或遮挡严重的宁可不标，也不标成正常，避免给模型引入噪声。

• 自爆绝缘子：定义为伞裙大面积碎裂或缺失超过三分之一。如果整串绝缘子有多片伞裙自爆，每一片区域都单独标注，不能只标一个框完事。

• 破损绝缘子：定义为机械损伤导致的边缘崩坏或裂纹，但缺失面积不到三分之一。破损和自爆的区别在于损伤程度和形态，标注时严格按面积和形态约定来。

• 闪络痕迹：定义为表面有明显的放电烧灼痕迹，颜色发黑或碳化，即使绝缘子本身结构完好也算闪络。因为闪络痕迹虽然不影响结构，但对运维决策很重要。

标注格式直接用YOLO格式的txt，每行一个目标：类别id加中心点x、y坐标和宽高，全部归一化到0到1区间。我用半自动的工具做辅助预标注：先拿一个初步训练的模型跑一遍，把预测框导出，人工再对这些框做修正和补标。这个小流程至少节省了三分之二的标注时间，而且预标注框的存在也降低了标注人员找目标的疲劳度，误标漏标的情况少了。

3.3 数据增强策略与样本平衡

缺陷样本稀缺是绕不过去的坎。我数了一下，13200张图里，自爆缺陷目标约1800个，破损目标约1400个，闪络目标约1100个，而正常绝缘子目标超过3万个。如果不做处理，模型会倾向于把所有目标都预测为正常绝缘子，因为这样训练损失已经足够小了。

我在这里做了三层处理。第一层是离线增强，专门针对缺陷类别做目标级别的裁剪和粘贴增强，做法是把缺陷绝缘子从原图中裁剪出来，通过随机缩放、旋转、亮度变化后，粘贴到不含该类缺陷的巡检图上。这里的注意点是粘贴位置要符合物理直觉，不能把绝缘子贴到天空中或者树丛里，否则模型学到的会是“贴图感”而不是真实的缺陷特征。第二层是训练时的在线增强：Mosaic、MixUp、HSV扰动、随机仿射变换等，YOLO11自带的增强策略本来就不错，我在默认基础上适当加大了Mosaic的概率，因为电力场景下目标分布稀疏，Mosaic能把不同图的目标拼到一起，让模型在一个batch里看到更多样的目标形态。第三层是损失函数层面的辅助——在分类损失中对正常绝缘子的损失权重做了轻微下调，让训练重心自然偏向缺陷类，幅度不能太大，否则模型会过度激进地把正常目标判成缺陷，这个我调试了几轮才找到一个合适的平衡点。

4. 环境搭建与训练配置

4.1 开发环境与硬件配置

训练环境算是一套比较常规的配置。操作系统是Ubuntu 20.04，Python 3.10，PyTorch 2.1.0，CUDA 11.8，显卡是单张24GB显存的GPU。YOLO11的官方仓库是基于ultralytics框架的，我直接在它的基础上改造了检测头模块，这样做的好处是可以继续复用它的数据加载、训练循环、评估和导出接口。

关于依赖版本的坑，有必要提一下。ultralytics框架对PyTorch和CUDA的版本比较敏感，尤其是torch 2.1和CUDA 11.8的组合，实测比较稳。如果Python版本太高（比如3.12），一些依赖的编译可能会有问题。建议严格按照官方文档的版本组合来装，省得浪费时间在环境排错上。

4.2 关键训练参数设置

训练参数的设置直接决定了模型能不能收敛到好的解。这里我给出实际用的配置，并解释每个参数背后的理由。

• 输入尺寸imgsz设成640。绝缘子在无人机图里很多是小目标，理论上输入尺寸越大对小目标越友好，但1280的输入会让训练和推理时间翻几倍。我先用640跑通流程，后续再根据需要微调。

• batch size设成16。在24GB显存下，这个数值比较舒适，训练不会因为显存不足中断，梯度统计也足够稳定。

• epochs设成200，训练后期使用余弦退火学习率调度。绝缘子数据集中缺陷样本少，需要较多的迭代轮次让模型充分学习到缺陷特征。如果只想快速验证流程，把epochs降到80到100就行。

• 优化器选用SGD，momentum 0.937，weight_decay 0.0005。虽然AdamW在很多人手里精度更好，但对检测头这种结构，SGD配合适当的warmup在YOLO系列里一直表现稳定，而且泛化性通常更好一些。

• 初始学习率0.01，warmup 3个epoch。这几项是YOLO系列官方训练的常规配置，我沿用下来。

• 类别损失权重：NC（正常绝缘子）为0.8，三种缺陷类别为1.0。这个系数是我试出来的。如果正常类权重过高，模型把所有目标都判成正常就能获得很低损失；如果过低，又容易把背景里的纹理误判为缺陷。0.8算是一个实践上比较有效的折中。

训练中我记录了关键节点的指标变化，可以给到一组参考数据：

4.3 训练过程中的调参记录

第一个epoch的loss曲线很能说明问题。如果前五个epoch里分类损失没有明显下降，排除数据加载问题之后，第一嫌疑就是学习率太大或warmup设置不当。我在第一次训练时就遇到失败：前四个epoch损失一直在波动，第五个epoch开始直接梯度爆炸到NaN。排查下来的原因是warmup轮次太少（只设了1个epoch），加上初始学习率0.01对改过的检测头来说稍微偏大。后来把warmup提高到3个epoch，损失曲线就稳定了。

另一个重点是验证集上的表现要分类别看，不能只看整体mAP。YOLO11默认的训练日志只输出总体mAP，但我用官方的验证脚本按类别统计了指标，发现前100轮里破损类别的mAP一直停留在0.6左右，明显低于其他类别。回归到数据上看，破损样本在三种缺陷里最少，且部分破损在视觉上和正常绝缘子的阴影非常相似。我针对这个类别专门增加了离线增强样本量，同时把破损目标在Mosaic增强中的混入概率调高，训练到150轮时破损类mAP提升到了0.78，虽然还是略低于其他类别，但至少是可用的水平了。

训练完成之后，我保存了最后一轮的权重，同时也保留了验证集mAP最高的那轮权重。YOLO系列的惯例是最后一轮往往接近最优，但出现过拟合风险的时候，中间那轮的权重反而更稳定。最后部署用的是验证集最优权重。

5. 模型评估与推理部署

5.1 和基线模型的对比评估

模型改得好不好，不能自说自话，要有和基线的对比。我在完全相同的训练集和超参数下，训练了原版YOLO11n、原版YOLO11s和带LQEHead的YOLO11n。评估结果放在一张表里看：

这套数据说明三件事。第一，LQEHead在参数量和计算量比原版更少的情况下，mAP反而明显更高，说明改进方向是对的，不是靠叠加参数量堆精度。第二，YOLO11n加LQEHead的精度已经超过了更大的YOLO11s基线，这意味着在相同精度目标下，我们完全可以选择更小的模型部署到边缘设备上。第三，推理耗时从2.1毫秒降到1.8毫秒，虽然看起来只是零点几毫秒的差距，但对于视频流的实时处理场景，这个优势在高帧率下会放大。

5.2 ONNX导出与边缘设备部署

部署这一步，我用的是ONNX导出加TensorRT加速的路径。YOLO11官方仓库支持一键导出ONNX，但如果直接在代码里加了自定义检测头，容易遇到两个问题：一是自定义模块里的某些算子（比如一些特殊注意力实现）ONNX不支持，二是输出层的形状拼接需要显式处理。

LQEHead的QEM部分大量使用PyTorch的注意力操作，导出ONNX时我踩过具体的坑——全局最大池化加全连接层的组合在ONNX转换时会多出几个额外节点，导致推理框架的算子兼容性报错。解决办法是用torch.nn.functional.adaptive_avg_pool2d和adaptive_max_pool2d时，配合torch.onnx.export的opset_version设为12及以上，同时对QEM中自定义的权重调整逻辑做简化，确保整个过程只使用ONNX标准算子集。改完之后，导出一路顺利。

TensorRT的加速效果很直观。在Jetson Orin NX设备上，原版PyTorch模型推理一张640x640图片大约是22毫秒，转成TensorRT FP16之后降到约9毫秒，已经能满足接近实时处理的需求。这个速度对应到无人机巡检场景，意味着单张巡检图不需要排队等着出结果，飞完一块区域基本就能同步完成缺陷预筛。

5.3 实际场景推理效果评估

我把模型部署后跑到几段真实的无人机巡检视频上，有一个现象值得所有做类似项目的人注意：离线测试集上mAP很高，但现场视频上的表现会有明显的下降，主要体现在漏检上。原因不复杂，现场视频里有大量连续帧高度相似，模型在一帧上漏检之后，下一帧大概率也漏检，除非目标运动产生了新的角度。所以评估一个巡检模型不能只看测试集mAP，还应该放到连续帧序列上看“单目标连续多少帧被稳定跟踪检测到”。

我这个项目里做了一个额外的评估：在视频序列上统计成功检测的连续性，发现大多数漏检发生在目标尺寸小于15x15像素的情况下。这进一步印证了小目标能力是电力巡检场景的核心瓶颈。针对这个发现，我后续做了两件事：一是把输入尺寸提升到960，专门作为高精度模式的选项；二是对ONNX模型尝试加入TTA（测试时增强），但实测下来，TTA虽然能提升一点召回率，推理耗时增加的代价在实时场景下不可接受，所以最终没有采用。

6. 常见问题与排错实录

做这种偏工程的项目，真正耗时间的往往不是设计模型，而是排错。我把实际遇到的问题整理成一张速查表，后续做类似项目的朋友可以直接对照排查。

6.1 训练阶段常见问题速查

这里针对第一个问题多说一句。NaN出现在训练早期通常是因为学习率太大，导致梯度值过大，权重更新直接冲出了正常数值范围。但还有一种隐蔽的可能，是数据标签里出现了Inf或超大的坐标值，反向传播时损失值异常放大。我排查到后面才发现，问题根源不是学习率，而是有几张标注图的txt文件里有一个目标宽度写成了0，导致计算IoU时除以了零。所以训练前对标注文件做一次性清洗是值得的，我写了一个五十行的Python脚本，检查每个txt文件的坐标是否在0到1之间、宽高是否大于0、类别id是否在合法范围，全部通过才允许进入训练。

6.2 部署推理阶段的三种典型问题

部署阶段遇到最典型的问题有三个。

第一个是ONNX导出自定义检测头时报算子不支持。前面说过一个解决方案是规范算子集，另一个经验是对注意力模块这种结构，尽量用标准卷积、池化、全连接组合来实现，避免用过于花哨的自定义函数。即使能导出成功，也尽量以ONNX Runtime的推理结果和PyTorch的结果做逐像素对比，一般允许有很小的数值误差，但如果输出结果的类别分布都变了，那一定是哪里改错了。

第二个是模型在桌面GPU上跑得好，换到边缘设备上帧率骤降。这通常不是模型的锅，而是边缘设备没有针对ONNX模型做推理优化。我建议直接用TensorRT的engine文件而不是ONNX Runtime直接跑，并且把精度模式改为FP16。如果边缘设备是老一点的芯片，INT8量化可以进一步提速，但要先做量化校准，否则精度会掉得很厉害，绝缘子这种小目标尤其容易掉点。

第三个是现场图背景复杂，模型误把铁塔横担上的锈迹当作破损绝缘子。这种误检往往是训练数据不充分导致的——训练集里缺少了带锈迹横担的负样本。解决方式是收集一批现场真实背景图，只标注其中真正的绝缘子目标，其他区域自然作为背景，加入训练集。增加500到1000张带背景的图，误检率能明显下降。

6.3 避坑技巧：来自实操的几条心得

第一，标注质量比标注数量更重要。三个不靠谱的标注不如一个准确的标注。缺陷类样本少，每一个标注都影响极大，最好由有电力行业经验的人审核关键类别，不能指望外包标注完全不出错。

第二，不要一上来就追求复杂模型。先用小模型跑通整个流程，从数据到训练到部署，全链路通了再逐步加模块优化。这样出了问题定位范围小，调试效率高。

第三，模型训练的日志、权重、配置参数，每个版本都要归档好。在改检测头代码之后如果是训练效果突然变差，能快速回滚到之前的版本做对比。我用一个简单的记录脚本自动保存每次训练的配置文件和关键指标，回头查问题快很多。

第四，对于绝缘子这类缺陷样本少的长尾场景，冻结骨干权重先训练检测头，等检测头收敛后再解冻骨干整体微调，是一种很有效的策略。我对比过全量从头训练和这个两阶段策略，后者的最终mAP高出约两个点。这是因为检测头可以从随机初始化快速适应任务，而骨干保留的预训练特征不会在训练初期被破坏。

7. 项目总结与可扩展方向

系统跑通之后，我在验证集和现场数据上都做了评估。mAP@0.5到0.9以上，参数量只有2.0M，单张图在边缘设备上推理不到十毫秒，这套YOLO11-LQEHead方案，在当前的项目约束下已经达到了一个比较理想的平衡点。但作为实践者，我更看重的是这套方案有没有可扩展的余地，因为电力场景的需求不会停在一个模型上。

一个明确的扩展方向是缺陷类型的继续细分。目前四分类对于运维决策已经提供了基础信息，但现场还经常需要判断缺陷的严重等级，比如破损的面积区间、闪络痕迹的扩展范围等。这些本质上可以转化为更细粒度的分类任务，已有的标注体系稍做扩展就能支持。

另一个方向是多模态数据融合。输电线路巡检不只是可见光图像，红外热像仪对发热缺陷的识别更敏感。如果把可见光检测和红外温度异常检测结合起来，对于发热型缺陷（比如接触不良导致的局部过热）会有更好的提前预警能力。这个方向的模型改造空间不小，但值得做。

还有一点是关于小目标检测的持续优化。绝缘子在远距离拍摄下只有十几个像素，目前模型对这种极小目标的召回率还不够理想。后续可以考虑引入专门的小目标增强策略，或者在YOLO11的基础上增加一个更高分辨率的特征层。我们在试验中发现，在640输入下，用P2层（更高分辨率特征图）做辅助检测确实能提升小目标召回，但推理速度会牺牲一些，要在实际部署约束下权衡。

最后分享一个小技巧，也是做了很多次项目总结出来的经验：训练模型时一定要保存每次实验的训练参数、数据版本、代码commit号和评估结果，最好形成一个简单的表格记录。别人复现你的项目时需要的是完整的实验上下文，而不是只有一组最佳权重。这个习惯不仅让你的工作更可靠，也让后续优化迭代有据可查。

YOLO11结合LQEHead这套方案，目前已经在我处理的几批真实巡检数据上稳定运行。如果后续有新的检测头改进思路，或者在实际部署中遇到新的问题，我会再更新这个系列。