在 2020 年那个 YOLOv5 仓库刚放出来的夏天我把一个工业质检项目从 Faster R-CNN 整条链路搬到了 YOLO 上训练时间从两天缩到六小时那是我第一次真切感到版本选对了等于省掉一个算法工程师。四年多过去我手上跑过 v5、v7、v8、v9、v10、v11也帮人擦过 v6 和 YOLOX 的屁股前阵子又有朋友拿着 v11 的分割头来问要不要升 v12。这篇东西就是把这几年攒下来的版本演进脉络和选型逻辑摊开讲一遍重点不是背诵每个版本改了哪几个模块而是讲清楚什么时候该用哪个、为什么这么选、选完之后哪里最容易翻车。如果你正准备起一个检测项目、要给团队定技术栈、或者单纯被YOLO 目前到几了这个问题绕晕了这篇应该能给你一个能直接落地的答案。1. 版本谱系从 v5 到 v11 到底各改了什么1.1 一条时间线先把家谱理清楚YOLO 这个系列的版本号是行业里最乱的东西没有之一。原因很简单真正定义第几代的不是论文而是谁在维护那个仓库。Joseph Redmon 时代的 v1/v2/v3 是学术脉络到了 v4 之后主干就分叉了Ultralytics 接手做了 v5美团做了 v6WongKinYiu 做了 v7然后 Ultralytics 又用 v8 把生态重心拉了回来。所以你在网上看到的v9 比 v8 强多少的对比很多时候比的根本不是一个团队的产物。我把主线版本按时间顺序捋一遍顺便给每个版本一句人话定位版本发布方时间一句话定位YOLOv5Ultralytics2020.06工程化最强的一代PyTorch 原生、代码干净、教程铺天盖地YOLOv6美团2022.06工业部署导向重参数化骨干在部分硬件上推理很香YOLOv7WongKinYiu2022.07ELAN 结构 辅助训练头当年 COCO 上性价比很高YOLOv8Ultralytics2023.01Anchor-free 全面转向一套代码吃下检测/分割/姿态/OBBYOLOv9WongKinYiu2024.02可编程梯度信息 PGI GELAN主打信息保留YOLOv10清华团队2024.05无 NMS 端到端双标签分配延迟压得很低YOLO11Ultralytics2024.09C3k2 与 C2PSA精度/速度曲线整体上移工具链最完整需要说明的是v12 在 2025 年也已经放出主要思路是往注意力机制更重的方向走骨干里塞进了 A2C2f 这类结构。但从工程角度看v8 和 v11 这两个 Ultralytics 自家的版本仍然是绝大多数项目的实际落点因为它们的训练/导出/部署链路是打通的API 也基本一致迁移成本几乎为零。这也是我后面选型建议里反复强调 v8/v11 的原因不是其他版本不行是配套成本太贵。还有一个坑要提前说市面上流传的v5 有 6.0、6.1、6.2、7.0 好几个分支是真的。Ultralytics 在 v5 的 7.0 版本里把代码结构和 v8 对齐了一次所以同样是git clone下来的 v57.0 和 6.2 的目录结构完全不一样README 和教程也对不上。你要用 v5一定要先看清 taggit checkout v6.2和git checkout v7.0踩出来的坑是两套。1.2 为什么 v5 到现在还有大量存量项目如果你只在国内做落地会有一个错觉v5 才是主流。原因主要有三个都很现实。第一是教程存量。从 2020 到 2023 三年时间里几乎所有中文技术博客、B站课程、毕设模板、大作业范例都建立在 v5 之上。你搜YOLO 环境配置YOLO 训练自己的数据集排在前面的八成还是 v5 的内容。对刚入门的人来说遇到报错能搜到答案这个价值比模型 AP 高两个点重要得多。第二是显存和算力门槛。v5s、v5n 这类轻量模型在 6 GB 显存的老笔记本上还能凑合跑起来配上一套--img 416 --batch 8的参数组合勉强能训。而 v8 之后的默认配置更吃显存很多老设备直接劝退。第三是 anchor-based 路线带来的可解释性。v5 依赖 anchor 框先验虽然需要跑kmeans聚类生成适配自己数据集的 anchor但很多老工程师习惯了这套逻辑觉得锚框看得见摸得着改起来心里有底。anchor-free 的动态标签分配在直觉上反而更难理解。但代价也很明确v5 的源码里那套build_targets逻辑复杂且和后续版本不通用你的自定义模块写进去之后换到 v8 基本要重写一遍另外 v5 对新型算子和导出格式的支持是滞后的ONNX opset 更新、TensorRT 新版本的适配社区基本不会再管了。所以我的建议是新项目不要从 v5 起步存量项目如果跑得稳就不要动。这话说得很废话但确实是实情我见过太多人因为想升级把一个稳定的产线模型改崩了。1.3 v6、v7 这两个中间代值不值得看v6 和 v7 经常被忽略但它们的代码里有几处设计思路值得借鉴。v7 的 ELAN 结构核心思想是控制最短和最长梯度路径。它通过堆叠不同深度的分支让浅层特征和深层特征都能有相对短的梯度传播路径训练时更容易收敛。这个思路后来被 v9 的 GELAN 进一步发扬光大。v7 还有一处很实用的是它的辅助训练头训练时多加几个 head 帮助中间层学习推理时全部剪掉不增加任何延迟。这种训练时加料、推理时减负的套路在后来的 v10、v11 里都能看到影子。v6 的重参数化则更适合部署侧的人关注。它在训练时用多分支结构提升表达能力推理前把分支融合成单个 3x3 卷积这样模型在 GPU 上的实际延迟会明显低于同等 FLOPs 的普通结构。我当时在一个边缘盒子上测过v6s 的实测帧率比同期的 v5s 高了大约两成虽然 AP 只高出零点几个点。如果你的场景是AP 够用就行、吞吐必须上去v6 值得花半天时间跑个基准。2. 决定效果的三件事损失函数、标签分配、网络结构2.1 损失函数三块拼图搞懂一块就能调参网上搜yolo 损失函数的人特别多因为这是训练不收敛时第一个被怀疑的对象。从 v5 到 v11损失函数其实可以拆成三块独立的拼图。第一块是分类损失。从 v5 开始就一直用 BCE二元交叉熵因为一个网格可以同时预测多个类别多标签场景用 BCE 比 softmax 更灵活。v8/v11 沿用这一套。所以如果你遇到类别不平衡标准做法是给 BCE 加pos_weight或者改用 Focal Loss而不是去动整个损失框架。第二块是框回归损失。v5 用的是 CIoU也就是在 IoU 基础上加上中心点距离和长宽比一致性两个惩罚项。CIoU 的收敛速度比原始 IoU 和 GIoU 都稳但长宽比那一项在训练早期容易引入噪声尤其在标签框本身画得不准的时候。v8 和 v11 仍然以 CIoU 为基础但对小目标的处理更细。第三块是 v8 引入的DFLDistribution Focal Loss这是 v5 到 v8 之间最本质的变化之一。传统做法是直接回归一个确定的坐标值DFL 则是把坐标离散成若干个 bin默认 16 个让网络预测一个分布再取期望得到最终坐标。好处是回归目标不再是单点网络能表达这个边界大概在 15 到 17 像素之间这种模糊性对标注噪声更宽容。代价是输出通道数变成原来的 16 倍reg_max16推理时的解码头要多做一次 softmax 加期望计算。实测中DFL 对小目标的定位精度提升比较明显但对大目标影响不大。调参上有一条经验如果训练 loss 一开始就剧烈震荡先检查标注框有没有越界或者宽高为 0 的脏数据而不是去调损失权重。我遇到过的八成loss 爆炸都是数据集问题不是损失函数问题。2.2 标签分配从静态匹配到动态对齐标签分配是很多人忽略但影响巨大的一环。简单说就是哪几个预测框该为哪个真实框负责。v5 的做法是静态的每个真实框根据宽高比匹配到最合适的 anchor再把中心点所在的网格以及左右上下几个邻居网格也算作正样本。这套逻辑的好处是规则明确坏处是对不同尺度的目标不够自适应需要针对数据集重新聚类 anchor。v8 开始用TaskAlignedAssignerTAL思路是完全动态的对每个真实框计算所有预测框的分类得分和 IoU 的加权组合通常用s^α * IoU^β挑出得分最高的一批作为正样本剩下的算负样本。这个机制让分类准和框得准两个目标互相促进避免了静态匹配里框对上了但类别学不会的尴尬。v11 沿用 TAL 的框架主要改动在结构侧而不是分配侧。所以从训练行为上看v8 和 v11 的表现非常接近你在 v8 上调好的超参搬到 v11 基本不用大改。这是我把它们并列为2026 年主力选择的另一个理由。这里有个实操细节值得记下来TAL 的topk默认是 13alpha1.0beta6.0。beta 越大越侧重 IoU如果发现模型框定位不准但分类很准可以适当调大 beta反过来类别混淆严重、框位置还行就往小了调。这个参数在 v5 里是不存在的很多人第一次调 v8 时会找不到北。2.3 主干与 Neck 的结构演进结构层面的变化是版本之间最看得见的差异。v5 是 CSPDarknet53 骨干加 PANet 特征融合C3 模块是基本单元整个结构偏重但对多尺度目标的适应力不错。v8 把 C3 换成了C2f核心改动是在残差分支上做了更细的 split-concat 操作梯度流动更充分同等参数量下效果更好。这个改动当时争议挺大很多人觉得只是换汤不换药但实际跑下来的收敛曲线确实更平滑。v11 把 C2f 升级为C3k2思路是让模块可以根据配置灵活切换两种不同的瓶颈结构小模型用轻的、大模型用重的一套代码覆盖 n/s/m/l/x 五个尺寸。同时 v11 在 Neck 之后加了一个C2PSA模块里面是注意力机制主要作用是在不显著增加参数量的前提下提升全局感受野。我实测过 v11n 对中等尺寸目标的召回率比 v8n 高了大约一到两个点代价是推理延迟增加了不到一成。需要提醒的是这些结构改进的收益是平均意义上的。在特定数据集上v8 反超 v11 完全有可能尤其是你的数据分布比较特殊比如全是极小目标或者全是超大目标时。所以在选型阶段跑一次真实数据的对比实验比看任何基准表格都靠谱。3. 2026 年选型指南先定场景再定版本3.1 按任务类型选不是所有任务都叫目标检测很多人问该用哪个版本其实第一个该问的是你要做什么任务。Ultralytics 从 v8 开始把检测、分割、姿态、OBB旋转框和分类统一到一套 API 里这是它最大的价值点。如果你只做普通矩形框检测v8 和 v11 都能胜任模型文件名分别是yolov8n.pt和yolo11n.pt。如果你要做实例分割v8-seg 和 v11-seg 都开箱即用输出的是掩码加框。分割任务里有个常见需求是求圆度这个不需要改模型拿掩码算就行用cv2.findContours提取轮廓cv2.contourArea取面积cv2.arcLength取周长圆度公式是4πA/P²。需要留意的是YOLO 输出的掩码是 160×160 的低分辨率再上采样回原图的边界会比较毛糙如果圆度计算精度要求高要么把retina_masksTrue打开输出原图分辨率掩码要么对掩码做一次形态学闭运算再算。如果你要做旋转框检测比如遥感影像里的船只、飞机、以及泥石流滑坡这类地物用 OBB 模型比水平框准得多因为水平框会把相邻目标框到一起NMS 阶段互相抑制。姿态估计用-pose模型关键点数量由数据集决定。多目标跟踪是个例外YOLO 本身只提供检测跟踪要靠外挂算法。Ultralytics 内置了 ByteTrack 和 BoT-SORT 两个跟踪器直接model.track()就能用。跟踪指标MOTA、IDF1、HOTA要单独用 TrackEval 这类工具算不能拿检测的 mAP 代替。3.2 按硬件选显卡不是只有一种硬件这一环最容易出事。NVIDIA 显卡是最省心的路径CUDA cuDNN PyTorch 官方轮子装完就能训。新卡比如 40 系、50 系要注意 CUDA 版本和 PyTorch 版本的匹配PyTorch 2.x 对 50 系的支持需要较新的 CUDA 12.x 版本装老版本会出现能识别到卡但一跑就报错的情况。AMD 显卡跑 YOLO是这几年问得特别多的。可行路径有三条一是 PyTorch 的 ROCm 版本在 Linux 下体验接近 CUDAWindows 支持有限二是 ONNX Runtime 的 DirectML 执行提供器Windows 下能直接调用 AMD 显卡做推理训练不行三是把模型转成 OpenVINO 格式在带核显的 AMD 平台上推理核显路径的吞吐在轻量模型上其实很不错。我的经验是训练环节尽量用 N 卡或者云上租卡推理环节可以充分压榨 AMD 的性价比很多边缘盒子和小主机用集显跑 v11n 能到实时。FPGA 部署是更小众但确实存在的需求。走这条路一般要做三件事训练后把模型量化到 INT8把 DFL 解码头和 NMS 后处理从网络里剥出来放到 CPU 或者软核上做用厂商的量化编译工具链比如 Vitis AI 这类把主干和 Neck 编译成硬件加速器。这里最大的坑是 YOLO 的动态算子很多量化后的精度掉点可能比预期大建议量化后一定要用一整批真实图片跑精度对比别只看编译是否通过。3.3 按交付形态选脚本、服务还是桌面软件交付形态决定了你在版本选择上要额外考虑什么。服务器 API 形态最自由v8/v11 都可以配合 FastAPI 或者 Triton Inference Server 都行。这种场景我一般推荐直接上 TensorRT 引擎吞吐能比原生 PyTorch 推理高两到三倍。桌面 GUI 工具形态要特别注意打包体积。v8/v11 的 PyTorch 依赖加上 torch 本身就有小两个 G打包成 exe 会非常臃肿。这种场景建议用 ONNX Runtime 推理只需要几十兆的运行时配合 PyQt 或者 Tkinter 做界面最终包体控制在两百兆以内是可行的。一键部署脚本形态是很多人偷懒的重灾区。我见过太多install.sh里写死pip install torch而不指定版本的换台机器就崩。正确做法是把 CUDA 版本、torch 版本、ultralytics 版本三者锁死写在一个requirements.txt里并且加上--extra-index-url指定 PyTorch 官方源避免被镜像源里的旧版本覆盖。3.4 一张对照表直接抄你的情况推荐版本理由新项目通用检测有 N 卡YOLO11s/m精度速度曲线最好工具链完整存量 v5 项目跑得稳维持 v5迁移收益小于风险老设备6GB 显存以下YOLOv8n / v11n轻量模型 小分辨率训练需要分割/姿态/OBBYOLOv8 或 v11 对应后缀一套 API 全覆盖延迟极度敏感端到端YOLOv10NMS-free后处理开销为零Windows AMD 显卡推理ONNX DirectML免 CUDA部署简单FPGA 硬件加速YOLOv5n / v8n 量化结构简单量化友好毕设 / 学习 / 教学演示YOLOv8教程多出问题好搜4. 一条可复现的训练链路4.1 环境配置把版本锁死比什么都重要环境这一步我建议用 conda 单独开一个环境别和系统 Python 混。核心命令大概是这样conda create -n yolo python3.10 -y conda activate yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu121 pip install ultralytics装完之后必须验证三件事torch.cuda.is_available()返回 True、torch.cuda.get_device_name(0)能看到你的卡、ultralytics.__version__是你预期的版本。这三条里任何一条不对后面训练一定出问题。有个细节很多人踩过装了ultralytics之后它会自动拉一个 torch 版本如果之前手动装过不同版本的 torch可能出现两个版本共存、实际加载的是旧版的情况。解决办法是先装 torch 再装 ultralytics或者在pip install ultralytics后面加--no-deps手动管理依赖。VS Code 里做这件事的话记得把解释器切到 conda 环境对应的那个python.exe路径一般在anaconda3/envs/yolo/python.exe。切错了会出现终端里能跑、编辑器里 import 报错的诡异现象。4.2 数据标注与格式转换脏数据是万恶之源标注工具的选项很多labelImg 是上手最快的画完框直接导出 YOLO 格式的 txt。YOLO 格式每行是类别id 中心x 中心y 宽 高全部归一化到 0 到 1 之间。labelImg 会在导出目录生成一个classes.txt这个文件的类别顺序必须和你的data.yaml里names的顺序完全一致错一位整个数据集就废了。CVAT 适合团队协作支持自动标注和多人复核导出时同样可以选 YOLO 格式。VS Code 里也有一些社区插件可以在编辑器内画框预览适合边写代码边看数据但正式标注还是用专门工具效率高。几个高频转换场景值得单独说MOT16 转 YOLOMOT 的gt.txt格式是帧号,目标id,x,y,w,h,置信度,类别,可见度。转换时要按帧号分组过滤掉类别不对的行多数跟踪任务只关心行人然后把x,y,w,h从左上角坐标转成中心点归一化坐标。注意 MOT 的可见度字段一般只保留visibility 0.3的目标否则会引入大量几乎被完全遮挡的样本。YOLO 转 COCO如果要用 pycocotools 算指标或者用别的框架训需要把归一化中心点还原成绝对左上角坐标再拼成 COCO 的bbox[x,y,w,h]格式。Ultralytics 里有现成的convert_coco工具做反向转换正向的自己写二十行代码就够了。转换之后一定要抽三张图可视化核对框位置错位是最常见的 bug。分割数据集YOLO-seg 的标签是多边形点序列每行是类别id x1 y1 x2 y2 ...也是归一化的。点数必须是偶数且至少三个点。用 labelme 标多边形再转过来是常见做法。数据集组织上标准结构是images/train、images/val、labels/train、labels/val四个目录加一个data.yaml。我强烈建议在开始训练前写个校验脚本检查每个 label 文件有没有越界坐标、有没有宽高为 0、有没有类别 id 超范围。这个脚本我每换一个数据集都会重写一遍能省下大把调试时间。4.3 训练参数哪些必须调哪些别碰以 v11 为例一条典型的训练命令yolo detect train modelyolo11s.pt datadata.yaml epochs200 imgsz640 batch16 \ lr00.01 lrf0.01 warmup_epochs3 close_mosaic10 patience50 device0几个参数的重点说明imgsz是最重要也最容易调错的一个。默认 640如果你的目标都是小目标比如遥感图像里的车辆、工业图像里的缺陷点直接拉到 1280 甚至更高通常比换模型更有效。但显存占用是平方级增长的1280 相比 640 大概要多吃四倍显存。batch在显存允许的前提下尽量大因为 BN 层的统计量在小 batch 下不稳定。显存不够就调小 batch 同时按比例调小学习率或者开启 AMP默认就是开的。lr0和优化器是绑定的。SGD 用 0.01 起步是安全的AdamW 要用 0.001 这个量级否则很容易发散。小数据集几千张以内我更倾向 AdamW收敛快且对学习率不那么敏感大数据集还是 SGD 更稳。close_mosaic这个参数很关键含义是最后 N 个 epoch 关闭 Mosaic 数据增强。Mosaic 把四张图拼成一张能显著提升小目标效果但它制造出来的图像分布和真实分布差异很大如果全程开着训练后期 loss 下不去验证指标也会飘。默认 10 是比较合理的数据量特别小的时候可以适当加大。patience是早停轮数默认 50。数据量小的时候建议调到 20 到 30避免过拟合后还在白跑。配合save_period定时存 checkpoint避免训练中断前功尽弃。4.4 导出与推理不同硬件的落地姿势训练完导出是最后一步也是最容易在客户现场翻车的一步。yolo export modelbest.pt formatonnx opset12 simplifyTrue imgsz640 yolo export modelbest.pt formatengine halfTrue device0 imgsz640 yolo export modelbest.pt formatopenvino halfTrue imgsz640ONNX 是最通用的中间格式注意opset版本。opset 11 是很多老推理框架最后一个完整支持的版本如果你要部署到比较老的硬件或者国产推理框架上用 11 比 12 稳妥。simplifyTrue会调用 onnxsim 做图优化能去掉一些冗余算子但如果导出后推理结果和 PyTorch 对不上第一个要排查的就是它先关掉试试。TensorRT 引擎和硬件强绑定在 A 卡上导出的引擎拿到 B 卡上可能加载失败甚至同型号不同驱动版本都可能有问题。所以引擎一定要在目标机器上现场导出或者记录好显卡型号加驱动版本加 TensorRT 版本这一整套指纹。OpenVINO 是 Intel 平台的最优解CPU 和核显都能加速。有个细节是halfTrue在 CPU 上不一定生效实际用 INT8 量化收益更大可以用 NNCF 做训练后量化。推理侧还有一个经常被忽视的性能点预处理。很多人只盯着模型推理时间结果发现端到端延迟还是很低。其实图像从 BGR 转 RGB、resize、归一化、HWC 转 CHW 这一套操作如果全用 Python 循环做可能比模型推理还慢。用cv2.dnn.blobFromImage或者直接写 numpy 向量化操作能省掉一大半。5. 踩坑速查表5.1 训练侧这些报错我见过太多次现象大概率原因处理办法loss 一开始就 nan学习率过大或标签越界降 lr0跑数据校验脚本loss 正常但 mAP 一直是 0data.yaml 里 names 顺序和标签不对应抽图可视化核对训练爆显存imgsz 或 batch 太大降 imgsz 优先降 batch 次之显存够但速度极慢数据加载成瓶颈提高 workers检查磁盘 IO验证集指标剧烈波动batch 太小或验证集太小增大 batch扩大验证集训到一半 loss 突然上升Mosaic 未关闭或学习率调度问题检查 close_mosaic 和 lrf类别极度不均衡少数类学不会正样本太少过采样、加 Copy-Paste 增强、调 loss 权重关于少数类学不会我想多说一句。我做过一个烟火识别的项目烟和火在整幅图里占的面积不到千分之三用常规训练怎么调都上不去。最后有效的做法是改采样策略把包含目标的图在数据集里复制若干份让正样本占比从千分之一提到百分之五左右同时把 Mosaic 关闭改用更大范围的随机缩放和裁剪。这样下来召回率从 0.6 提到了 0.89。这个案例告诉我数据侧的调整收益往往远超结构侧的改动。5.2 部署侧精度对不上怎么查部署阶段最典型的症状是PyTorch 里结果好好的换成 ONNX 或者引擎之后就错乱。排查顺序我总结成一个固定流程照着走基本都能定位。第一步确认输入预处理完全一致。PyTorch 推理时用的是 letterbox 填充保持长宽比多余部分填灰如果你的部署代码直接 resize 成正方形坐标就会整体偏移。这个问题占了部署精度问题的六成以上。第二步确认输出张量的解析逻辑。v8 之后的输出是[batch, 4nc, num_anchors]注意通道在前还是在后很多老代码是按 v5 的[batch, num_anchors, 5nc]写的直接套用会全乱。第三步确认量化带来的精度损失。FP16 一般掉点在一两个千分点以内可以接受INT8 掉点可能到两三个点需要用真实数据做校准集并且优先保证检测头的输出层不被过度量化。第四步确认 NMS 参数一致。PyTorch 默认conf0.25, iou0.45部署侧如果用了不同阈值框的数量和位置都会明显不同看起来就像模型坏了。5.3 指标好看但落地不行这是最让人难受的一类问题验证集 mAP 0.9上线之后一堆误检漏检。根据我的经验八成是下面几个原因。训练集和实际场景的分布不一致。比如训练数据全是晴天白天的图实际部署有夜间和雨天那模型必然崩。这种问题的唯一解法是补数据没有捷径。验证集划分方式有泄漏。如果是视频抽帧的数据集随机划分会让同一段视频的相邻帧同时出现在训练集和验证集里指标虚高。正确做法是按视频或者按时间段划分。评价指标和业务指标不对齐。mAP 是 IoU 阈值下的平均精度但你的业务可能只关心有没有漏检那应该重点看召回率而不是 mAP。我做生产日期识别的时候业务方只在乎日期字符一个都不能错那就得把置信度阈值往下压宁可多检几个再后处理过滤。标注本身就不一致。多个人标的数据边界框松紧标准不一样模型学到的就是一个模糊的目标。这种问题在小团队里特别常见建议标注规范写清楚框要贴紧目标边缘还是留两像素余量并且定期做交叉复核。6. 模型改进与二次开发的实操心得6.1 模块缝合先问清楚要解决什么问题yolo 模块缝合yolo 改进是搜索量很大的一组词说明很多人需要发论文或者做创新点。我在这里给几条很实在的建议。第一改结构之前先把 baseline 跑满。很多人的改进实验之所以看着有效是因为 baseline 本身没调好。你把 baseline 的学习率、增强策略、训练轮数都调到最优再去加模块收益可能就没那么明显了。第二改一个变量。我见过太多论文在一个模型里同时加注意力、换损失、改标签分配、上新的 Neck最后涨了两个点根本说不清是哪一部分起的作用。做对比实验一次只动一处。第三模块不是越复杂越好。SE、CBAM、ECA 这些注意力模块加在骨干末端效果通常最明显加在每个 bottleneck 里反而可能因为参数量膨胀导致在小数据集上过拟合。我做过一个对比在三千张图的数据集上加了三处 CBAM 的版本比只加一处的版本验证集 mAP 低了 0.8。数据集越小越要克制。第四注意推理延迟。加了注意力之后 FLOPs 可能只涨了 5%但实际 GPU 延迟可能涨 30%因为注意力里的 reshape 和矩阵乘对硬件不友好。一定要在目标硬件上实测延迟不能只看论文里的 FLOPs 对比。6.2 数据侧的手段清单如果你问我这几年做下来最值钱的经验是什么我会说把精力放在数据上比放在模型上回报率高得多。常用的数据手段我列一下按性价比排序标注质量复核。找两个人交叉检查 10% 的样本把不一致的挑出来统一标准这一步的收益通常超过换模型。困难样本挖掘。拿训练好的模型在实际场景里跑把误检和漏检的图挑出来补标注迭代两三轮效果提升非常明显。有针对性的增强。小目标就多加随机缩放和 Mosaic遮挡严重就加 Cutout 或者 Copy-Paste光照变化大就调 HSV 增强的色调和饱和度范围。不要无脑全开有些增强是互相冲突的比如同时开 Mosaic 和 MixUp图像会糊成一团。合成数据。工业场景里缺陷样本很难采集可以用渲染或者图像合成的方式造一批但要注意域差距合成数据通常需要配合风格迁移或者大量真实数据混合训练。负样本。这一点被严重低估。模型在产线上误检很多时候是因为训练集里从来没有出现过那些看起来像目标但实际不是的物体。补几百张纯负样本误检率能降一大截。最后分享一个我在实际项目里反复验证过的小技巧训练完成后别急着交付拿验证集里指标最差的那 20 张图一张一张看模型的输出。你会发现在这些图上问题往往高度一致——要么是某个特定角度要么是某种特定光照要么是某个被反复误检的背景物体。找到这个共性之后针对性地补个一两百张这样的数据重新微调比盲目加几万张数据有效得多。这个习惯我保持了四年几乎每次都能从最后一公里里再抠出一两个点的提升。
