企业官网建设流程全解析

前阵子一个做巡检项目的朋友跟我吐槽，模型在测试集上 mAP 看着还行，一上现场就漏检，最后排查到根因，不是网络结构的问题，而是训练数据里几百张小目标的标注框画偏了。这种事我见过太多次了。很多人把 YOLO 当成“pip install 一下、三行代码跑通”的黑盒，真到训练、部署、出问题排查的时候，根本不知道从哪里下手。这篇 YOLO 详解，就是想把这条从原理到落地的完整链路讲透，把那些热搜里大家最关心的问题——yolo 损失函数是什么、yolo 后处理流程怎么走、AMD 显卡怎么跑、yolo 训练数据怎么标、怎么部署到 RK3588——全部串起来讲一遍。不管你是刚入门的小白，还是已经在调模型但经常被各种怪问题卡住的开发者，这篇文章都值得你花点时间从头读到尾。

1. YOLO 为什么能成为目标检测的代名词：核心思想和版本演进

1.1 单阶段检测到底“单”在哪里

YOLO 的全称是 You Only Look Once，翻译过来就是“你只看一次”。这种设计思路在当年是颠覆性的。在它之前的检测主流是两阶段方法，代表就是 Faster R-CNN 那一套：第一阶段先用区域提议网络生成一堆可能包含目标的候选框，第二阶段再对每个候选框做分类和框回归。两阶段的好处是精度高，但坏处也很明显——速度慢，一张图要跑两遍网络。

YOLO 的做法是把检测当成一个端到端的回归问题，整张图只经过一次前向传播，就能同时输出所有目标的位置、大小和类别。它把输入图像划分成网格，每个网格负责预测中心点落在自己范围内的目标，直接回归出边界框坐标和类别概率。这种“一次前向搞定所有事”的设计，让检测速度提升了几个量级，也让 YOLO 在实时场景里几乎没有对手。

1.2 版本演进：从 Darknet 到 Ultralytics，主流线别搞混

YOLO 的版本迭代是目标检测领域最热闹、也最容易把人搞晕的一条线。我经常在网上看到“yolo v26”这种说法，这里得先泼盆冷水：官方主线根本没有 v26。版本号通货膨胀主要来自社区项目，看的时候一定要认清是哪条线。

现在实际开发中用得最多的，是两条主线。

一条是 Joseph Redmon 和 Alexey Bochkovskiy 维护的 Darknet 版 YOLO，经典的是 v1 到 v4，其中 v3 是里程碑，v4 在工程上做了大量优化。另一条是 Ultralytics 团队搞的 YOLOv5 之后的分支，还有 YOLOv6、v7、v8，以及后来的 YOLOv9、v10、v11。其中 YOLOv8 是当前生态最成熟的版本，文档全、社区活跃、支持的训练推理脚本最完善。YOLOv11 是 Ultralytics 在 2024 年下半年推出的新版本，主要在效率上做了提升，官方支持检测、分割、分类、姿态估计和跟踪。

我做项目选型时的经验是：不用盲目追新。如果你的场景是常规目标检测，YOLOv8 是最稳的；如果对延迟有极致要求，可以考虑 YOLOv11 的 nano 版；如果要做实例分割，YOLOv8-seg 或者 YOLO11-seg 都足够好。版本选择的核心指标是你的硬件平台和任务类型，而不是“数字越大越强”。

2. 前向推理全链路拆解：一张图从输入到检测框输出，中间经历了什么

2.1 预处理：letterbox 和归一化

很多人以为推理就是模型前向传播那一下，其实预处理和后处理占了整个链路里最容易出 bug 的一大半。

第一步是 letterbox。因为模型输入尺寸是固定的（比如 YOLOv8 默认 640x640），但原始图片长宽比千奇百怪，如果直接 resize 成正方形，物体会被拉伸变形，检测精度会明显下降。letterbox 的做法是保持长宽比缩放，短的边用灰色填充到目标尺寸。这个操作在训练和推理里都会用，关键是要记住：后处理还原坐标时，必须把 letterbox 的填充偏移和缩放比例考虑进去，否则框的位置会整体偏移。

第二步是归一化。把像素值从 0-255 缩放到 0-1，然后转成模型要求的 NCHW 格式，N 是 batch 大小，C 是通道数（RGB 就是 3），H 和 W 是空间尺寸。

2.2 骨干网络和颈部：多尺度特征图的诞生

预处理完的图像进入骨干网络。以 YOLOv8 为例，骨干用的是 CSPDarknet 的改进版本，它的作用是从图像里提取特征。网络越深，感受野越大，能看到的语义信息越丰富，但小目标的细节信息也会被逐渐“稀释”。所以现代 YOLO 不会只取最后一层特征图，而是提取三个尺度的特征图，分别是原图 stride 8、16、32 的降采样结果，通常记作 P3、P4、P5。三个尺度分别对应小目标、中目标、大目标，这样既保住了语义信息，又不丢细节。

骨干之后是颈部网络，YOLOv8 用的是 PAN-FPN 结构。它做的事情可以理解为“上下楼传递消息”：自顶向下把高层语义往低层传，帮助小目标特征增强；再自底向上把低层细节往高层传，帮助大目标分类更准。这种双向融合让每一层特征图都同时具备语义和细节信息，是 YOLO 系列处理多尺度目标的核心武器。

2.3 检测头与输出张量形状

拿到融合后的特征图，下一步就是检测头。YOLOv5 及之前的检测头是耦合的，也就是分类和回归共用一个分支；从 YOLOv8 开始改为解耦头，分类一个分支，框回归一个分支。解耦的好处是训练时梯度更干净，收敛速度更快，精度也有提升。

以 YOLOv8 检测模型为例，输入 640x640，三个尺度的特征图经过检测头后，每个特征图上的每个格子都会输出一批值。输出通道数是 4 + 1 + 类别数，其中 4 是边界框中心点偏移和宽高，1 是目标置信度，类别数按你的数据集来，COCO 就是 80。如果是分割模型，输出里还会多出一段 mask 系数，这个后面讲实例分割时再展开。

2.4 后处理：阈值过滤、NMS 和坐标还原

模型输出的原始张量不能直接用。特征图上每个格子都会预测出若干框，这些框数量巨大，而且同一个目标会被相邻格子的多个框重复命中。所以后处理是必经之路，流程可以概括为四步：

1. 置信度过滤：把所有低于置信度阈值（比如 0.25）的预测框丢弃。
2. 类别过滤：每个框取得分最高的类别作为最终类别，同时得到该类的分数。
3. NMS（非极大值抑制）：在同一类别内，按分数从高到低排序，保留分数最高的框，然后删除所有与它 IoU 大于阈值的框，再对下一个框重复这个过程。
4. 坐标还原：把 NMS 之后的框坐标按 letterbox 的比例和填充偏移还原到原始图像坐标系。

这一步在 YOLOv8 里由 ultralytics 框架在推理时自动完成，但到了部署环节，很多推理引擎只给你原始输出张量，NMS 得自己写，或者用第三方库实现。我踩过的坑是：后处理里的 IoU 阈值设太高，同一个目标会被输出好几个框；设太低，挨得近的两个物体会被当成一个。一般默认 0.45 左右比较稳，密集小目标场景可以适当降到 0.3。

3. 训练时它到底在学什么：损失函数与标签匹配机制的演进

3.1 三大损失分量：分类、回归和置信度

YOLO 训练的核心是让网络的输出尽可能接近真实标注，而“接近”的程度由损失函数来定义。这个方向几乎每个用 YOLO 的人都问过，也是理解训练日志中 loss 曲线的前提。

YOLOv5 时代的损失函数由三部分组成：类别损失、目标置信度损失和框回归损失。前两种用的是 BCE 交叉熵，回归损失用的是 CIoU。到了 YOLOv8，置信度损失被去掉了，因为新框架的标签分配策略已经隐含了“这个位置有没有目标”的判断，只保留分类损失和回归损失，其中回归损失变成了 CIoU 和 DFL 的组合。DFL（Distribution Focal Loss）做的事是把框坐标预测从“直接回归一个值”改成“预测一个离散分布”，然后加权求和得到最终坐标。这个设计的直观好处是：网络可以对边界位置的不确定性进行建模，框定位更稳。

3.2 正负样本匹配：网络怎么知道该学谁

损失函数只是“公式”，真正决定训练质量的是它作用在哪些样本上。也就是标签分配机制，业内叫 label assignment。早期 YOLO 的做法很朴素：看 GT 框中心落在哪个格子，就由哪个格子的 anchor 来负责预测它，并把 IoU 低于阈值的 anchor 当作负样本。

YOLOv8 之后改用 TaskAlignedAssigner，它的匹配逻辑更“聪明”：候选 anchor 同时考虑分类分数和框与 GT 的 IoU，两者对齐程度高的才被选为正样本。这样网络学到的特征对齐更好，分类和回归两个任务也能互相促进。

这里我想多说一句：很多人训练的时候只看总 loss 下没下降，其实更应该看各个分量的变化。如果分类 loss 降不下去，大概率是数据类别不均衡或者难例太多；如果回归 loss 一直抖，可能是标签框本身画得不准。把损失函数拆开看，是排查训练问题的第一步。

3.3 从损失函数理解训练日志

YOLOv8 训练时终端会打印 box_loss、cls_loss、dfl_loss 这三项，分别对应回归、分类和 DFL。正常情况下三者的曲线都是先快速下降然后逐渐趋于平稳。如果你的 box_loss 训了 50 个 epoch 还在高位震荡，先别急着调网络结构，检查一下训练集里有没有坐标明显越界的标注，这类脏数据对回归损失的影响非常大。

一个特别容易踩的坑是：mAP 已经开始收敛了，但 loss 还在缓慢下降，这一步不是模型有问题，而是数据增强带来的正常现象。YOLOv8 默认开启了 Mosaic 和多种增强策略，增强样本的分布和验证集的干净分布本来就不完全一致，loss 和指标之间没有必要强行对齐。

4. 数据准备是新手翻车重灾区：标注规范、格式转换与工具链选择

4.1 YOLO 标注格式到底长什么样

YOLO 的标注格式是每个训练自己数据集的人必须刻进 DNA 的东西。它用 txt 文本存放标注，文件名和图片名保持一致。每行一个目标，格式是：

class x_center y_center width height

注意一个关键细节：这四个数值全部是归一化后的值，也就是除以图片宽高之后的 0-1 小数。类别编号从 0 开始，比如 COCO 数据集里 0 是人，1 是自行车。标签文件放在 labels 目录下，按训练集和验证集分别组织，图片放在 images 目录下，目录结构一般是：

dataset/ ├── images/ │ ├── train/ │ └── val/ ├── labels/ │ ├── train/ │ └── val/ └── data.yaml

data.yaml 里写明 train 路径、val 路径和类别列表。很多新手第一次训练报 “no labels found”，基本都是目录结构没按这个约定来。

4.2 标注工具选型：CVAT、Label Studio 和 X-AnyLabeling

标注工具的选择取决于项目规模。如果你只是临时标几百张图验证想法，用 X-AnyLabeling 就够了，它支持加载 YOLO 模型做辅助预标注，人工只需要修正边缘，效率能提升好几倍。它的界面是纯桌面端的，免部署，开箱即用。

如果是团队协作或者数据量上万，强烈建议用 CVAT。CVAT 是开源 Web 端标注工具，支持多人同时标注、任务分配、自动标注插件，导出格式里直接就有 YOLO。部署 CVAT 需要 Docker，第一次配得折腾一会儿，但长远看值。还有一个选择是 Label Studio，它是通用数据标注平台，不只是标图，文本、音频、视频都能标，也支持 YOLO 导出。它的优势是可接入机器学习后端做预标注，劣势是配置复杂度和资源占用都偏高。

4.3 常见格式互转：KITTI、MOT16 转 YOLO 格式

真实的项目里，数据很少是现成的 YOLO 格式，网上开源数据集大多是 VOC 的 XML、COCO 的 JSON，或者自动驾驶领域常用的 KITTI、MOT 格式。格式转换是逃不掉的活。

以 KITTI 转 YOLO 为例。KITTI 的 2D 框标注是像素坐标的左上角 x1、y1 和右下角 x2、y2，转 YOLO 格式的核心公式是：

x_center = (x1 + x2) / 2 / image_width y_center = (y1 + y2) / 2 / image_height width = (x2 - x1) / image_width height = (y2 - y1) / image_height

需要注意 KITTI 的类别和 YOLO 想要的目标类别可能不一致，转换时要做映射，比如 Car、Van、Truck 都映射成 car。还有一点，KITTI 的 3D 标注里有截断和遮挡属性，如果不要这些信息，直接跳过就行。

MOT16 转 YOLO 格式也是常被问到的高频需求。MOT16 的标注在 gt.txt 里，每行是“帧号, 目标ID, 框左上x, 框左上y, 框宽, 框高, 是否进入画面, 类别, 可见性”。转 YOLO 格式时关键步骤是：按帧号分组，把同一帧的所有目标写进同一个 txt，文件名命名成帧号。还有一个容易踩的坑是 MOT 格式里第 7 列是 0/1，表示该目标是否在画面内，第 9 列是可见性比例，一般建议过滤掉不在画面内（第 7 列为 0）或者可见性低于 0.5 的框，否则你的训练集里会混入大量无效标注。

4.4 数据质量决定了模型的天花板

数据准备这件事我多说几句。检测模型的精度上限基本由数据质量决定，网络结构只是决定你离这个上限有多近。我排查过非常多训练问题，最后发现有相当比例是数据问题：类别编号从 1 开始写导致所有标注整体偏一位、归一化时忘了除以宽高、同一个数据集里图片尺寸不统一却没有统一处理、标注和图片文件没有一一对应。这些错误不会让你训练直接报错，而是会悄悄降低 mAP，肉眼很难发现。

推荐的做法是：训练前写一个脚本，逐张检查标注框是否越界、宽高是否为正、归一化值是否在 0-1 之间，再用可视化脚本把标注框画到图上抽查一遍。这一步花半小时，能省下后面调优的几天时间。

5. 从零训练一个自己的检测器：环境搭建、参数解读与 AMD 显卡实测

5.1 环境配置：NVIDIA、AMD 和 CPU 三种情况

训练 YOLO 的环境配置，按显卡分成三种情况。

如果你有 NVIDIA 显卡，环境配置最顺：装 CUDA、cuDNN，然后 pip 安装 ultralytics 即可，框架会自动调用 GPU 加速。训练前用 nvidia-smi 确认显存够用，一般 8G 显存跑 YOLOv8s 的 640 输入、batch size 16 问题不大。

如果是 AMD 显卡，情况就要多说几句了。网上搜“amd显卡跑yolo”能找到一堆帖子，核心痛点在于 PyTorch 官方对 AMD 的支持默认是通过 ROCm，但 ROCm 在 Windows 上的支持远不如 Linux。我的实测经验是这样的：

• Linux + ROCm：对部分 AMD 卡支持比较完整，可以正常跑训练，安装时注意 ROCm 版本和 PyTorch 版本的对应关系。
• Windows + AMD：这是最头疼的组合。ROCm 在 Windows 上可用性差，很多 AMD 卡根本没有官方支持。两条替代路线是：用 DirectML 版本的 PyTorch，走微软的 DirectML 后端，能跑推理和小规模训练，但速度和稳定性都不如原生 CUDA；或者干脆用 CPU 训练小模型。CPU 训练 YOLOv8n 这种 nano 模型，一张小数据集也能接受，但稍微大一点的模型就别指望 CPU 了，一个 epoch 能跑到天荒地老。

我的建议是：AMD 显卡用户如果只是推理和测试，DirectML 能应付；如果真的要长期训练模型，考虑云 GPU 是最省心的选择，不用折腾驱动和编译。

5.2 训练命令和参数全解读

环境配好之后，训练命令的核心是这一条：

yolo detect train data=dataset/yourdata.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 device=0 lr0=0.01

参数看着多，真正需要花心思调的就那几个。我整理了一个常用参数表，按优先级从高到低排列：

新手最容易犯的错误是把 epochs 拉到 300+ 不管了。实际上小数据集 60-100 轮就基本收敛了，后面的轮次如果没加数据增强，大概率是在过拟合。正确做法是：第一轮训练用默认参数跑通，观察 val 指标；第二轮再针对性地调学习率和数据增强。

5.3 训练日志和结果文件怎么读

训练完成后，结果都在 runs/detect/train 目录下，最重要的三个文件是 results.png、weights/best.pt 和 weights/last.pt。

results.png 里画了每一轮的 loss 曲线、precision、recall、mAP50、mAP50-95。这里最需要关注的是 mAP50-95，它比 mAP50 更严格，要求框的位置和高低分排序都够好。如果你的 mAP50 很高但 mAP50-95 很低，说明你的框定位不够精确，可以试试提高 imgsz 或者用更深的模型。

weights 目录下有两个权重：best.pt 是验证集上 mAP 最高的权重，last.pt 是最后一轮的权重。部署和继续训练都用 best.pt，这是原则。

5.4 那些年我踩过的训练坑

最后列几个高频训练问题。

loss 不降：先看学习率，再看数据。学习率默认 0.01 对大部分情况是合理的，调低到 0.001 试试；数据的话重点检查标注格式和标签对应关系。

mAP 一直是 0：大概率是标注文件里类别编号和 data.yaml 里的类别列表对不上，或者标注框归一化算错了。

显存溢出：不要一上来就换小模型。先调小 batch，再开 amp，再把 imgsz 从 640 降到 512，一般能解决；实在不行用梯度累积，让 optimizer 每隔几步才更新一次。

6. 从训练到部署：模型导出、Windows GUI 自动化和 RK3588 边缘部署

6.1 导出 ONNX：部署的第一步

训练得到 best.pt 后，部署前一般要导出成通用格式，最常见的导出目标就是 ONNX。命令很简单：

yolo export model=best.pt format=onnx dynamic=True opset=12

dynamic=True 表示输入尺寸是动态的，这样部署时不用固定死输入分辨率。导出后可以用 onnxruntime 做一次推理验证，确保输出和 PyTorch 模式下一致。很多部署问题都是在导出这步引入的，验一遍能少踩很多坑。

导出后要特别注意：ONNX 模型输出的是后处理前的原始张量，NMS 不会包含在内，所以部署端必须自己实现置信度过滤和 NMS，否则你会拿到一堆重叠框。这一步和前面第 2 节讲的后处理流程对应起来，就明白了。

6.2 一个有意思的应用：基于 YOLO 操作 Windows GUI

近几年“基于yolo操作windows gui”成了一个挺热门的方向。思路其实很直观：用 YOLO 识别屏幕上的 UI 控件，比如按钮、输入框、图标，然后根据识别到的坐标驱动鼠标键盘自动操作。这本质上是把目标检测用在桌面自动化上。

具体做法是：先用截图工具截取屏幕，把截图交给 YOLO 检测控件位置，然后用 pyautogui 这类库移动鼠标到框中心坐标并执行点击。我做过一个内部工具，识别浏览器里的几个固定按钮做自动化测试，效果比基于图像匹配的传统方案稳很多。

这个方向有几个要注意的细节。第一，屏幕截图的分辨率和模型训练时的图片分辨率可能不一样，建议先做缩放对齐。第二，Windows 的 DPI 缩放会让截图坐标和实际屏幕坐标不一致，截图时最好用 SetProcessDPIAware 这类 API 关闭程序级缩放。第三，识别模型最好用目标固定、背景简单的数据训练，别拿 COCO 预训练模型直接识别你自定义的控件，效果会很差。

6.3 RK3588 部署：从 ONNX 到 RKNN

边缘端部署是 YOLO 的高频需求，RK3588 是现在很火的边缘计算平台，自带 6 TOPS 算力的 NPU，跑 YOLO 系列模型非常合适。

RK3588 部署的完整链路是：训练 PyTorch 模型，导出 ONNX，然后用 RKNN-Toolkit2 把 ONNX 转成 RKNN 格式，最后在板端用 RKNN 运行时推理。转换时通常要做 int8 量化，否则模型 size 和推理速度都不理想。int8 量化需要一个校准数据集，建议从训练集里随机抽 100-500 张有代表性的图片，覆盖各种光照和场景。

RK3588 部署最大的坑是算子兼容性。YOLOv8 和 YOLOv11 里的一些算子，RNN-Toolkit2 的旧版本可能不支持或者转换效率很差。如果转换报错，优先升级 rknn-toolkit2 到最新版本；如果某个算子实在转不过去，回到模型里把对应部分替换成兼容结构。量化掉点也很常见，一般掉 1-3 个 mAP 点都算正常，如果掉太多，试试：增加校准图片、把部分敏感层保留为 fp16、或者用混合量化。板端推理一般一次前向在几十毫秒级别，比 CPU 快一个量级，做实时检测完全够用。

7. 实例分割与多目标跟踪：理解指标，才能看懂效果好坏

7.1 YOLO 实例分割：检测之外的 mask 头

YOLO 的实例分割模型（YOLOv8-seg、YOLO11-seg）在做检测的同时，还输出每个目标的像素级掩码。它和语义分割不一样：语义分割给每个像素分配类别，同一类目标共用一种标签；实例分割要区分同一类里的不同个体，一个目标的掩码是一份。

实现上，YOLO 系列分割模型在检测头的回归分支旁边接了一个 mask 分支。输出张量里除了 4 个框坐标和类别数之外，还会多出 32 个 mask 系数。这 32 个系数会和一组预先生成的原型 mask 做线性加权，组合出每个目标的二值掩码。后处理时先做检测，拿到框之后再用 mask 系数解码掩码，把掩码裁剪到框的范围内。这就是为什么分割模型的输出通道数是 4 + 1 + 类别数 + 32。实例分割对边缘场景特别有用，比如流水线产品质检，要求的不只是“哪里有问题”，还要知道“这一片问题属于哪个工件”。

7.2 多目标跟踪指标从哪来

多目标跟踪（MOT）是另一个高频需求，热搜里“yolo多目标跟踪的指标怎么得到”问的就是这个。常见思路是 tracking-by-detection：用 YOLO 检测每一帧的目标，再用 ByteTrack、DeepSort 这类关联算法把同一目标在帧间连成轨迹。

但每次有人跟我说“我的跟踪效果不错”时，我都会问一句：你的 MOTA、IDF1、HOTA 是多少？只靠肉眼判断视频效果，很容易被偶尔的 ID 切换骗过去。这几种指标的计算方式如下：

MOTA：衡量整体跟踪准确度，综合考虑漏检、误检和 ID 切换。公式是 1 - (漏检数 + 误检数 + ID切换数) / 真实目标总数。它关心的是“总错误率”有多低。

IDF1：重点关注 ID 保持能力。把所有帧的预测轨迹和 GT 轨迹做最优匹配，计算匹配上的目标占所有目标的比例。如果模型检测得不错但 ID 老跳变，IDF1 会明显偏低。

HOTA：新一代指标，同时评估检测质量和关联质量，比 MOTA 更全面。如果你只在 MOTA 和 IDF1 之间选一个，建议看 HOTA。

指标的计算流程是：先把 GT 标注转成 MOT 格式（就是上一节讲的帧号、ID、框坐标），然后把你的跟踪结果也转成同样格式，用 py-motmetrics 或 TrackEval 工具跑评估，得到各项指标。工具本身不复杂，麻烦的是格式转换。我见过太多人在这一步翻车，转换时把帧号从 0 开始还是从 1 开始搞混了，评估结果直接失去参考价值。

8. 改进方向与进阶玩法：当你不再满足于“能检测”的时候

8.1 网络结构层面的改进：注意力、检测头和骨干替换

YOLO 的改进是个永远聊不完的话题。我见过很多人在 baseline 模型上疯狂叠加改进模块，但效果提升有限，反而训得慢、部署难。这里说几个我实际验证过有效果的方向。

注意力机制是性价比最高的改进手段之一。在骨干网络末层或检测头前加上 SimAM、CA、SE 这类轻量注意力模块，几乎不会增加多少推理开销，但对小目标和遮挡目标的检测常有提升。注意不要一上来就上 Transformer 类重模块，边缘设备扛不住。

检测头的改进在新版本里越来越少见了，因为 YOLOv8 的解耦头已经比较成熟。更多人在骨干上做文章，比如用 MobileNet、ShuffleNet 这类轻量网络替换 CSPDarknet 做骨干，适合端侧和移动端场景；反过来，追求极致精度时也可以换更重的骨干，但要接受推理速度的代价。

8.2 训练策略层面的改进：增强、融合和推理加速

训练层面的改进往往比网络结构改动更稳，而且不影响推理速度。Mosaic、MixUp、Copy-Paste 这些数据增强策略，YOLOv8 已经默认集成了一部分。自己改训练策略时，优先级最高的是多尺度训练，也就是每个 epoch 随机切换不同的 imgsz 尺寸，让模型对不同尺度的目标都更鲁棒。

推理阶段可以用 TTA（测试时增强），对同一张图做多尺度推理后融合结果，mAP 通常能涨 0.5-1 个点，但推理时间成倍增加，适合离线分析场景。如果是小目标特别多的场景，WBF（加权框融合）经常比 NMS 更好用，它把多个模型的预测框按权重融合，能保住更多低置信度但真实的目标。

8.3 我的改进方法论：baseline 先跑稳，改动一次一个

最后分享一点个人经验。我做 YOLO 改进踩过最深的坑，就是“改进点堆叠后无法定位是谁的功劳”。后来我给自己定了一条纪律：任何改进开始之前，先把 baseline 用固定随机种子跑 3 次，记录下 mAP50、mAP50-95 的均值和方差；然后每次只加一个改进，跑完单独记录；整个流程结束后做横向对比。数据先说话，视觉效果只做辅助判断。这一套流程看起来很笨，但恰恰是它让我避开了非常多次“自我感觉良好，实际测试没提升”的无效改动。

YOLO 这个系列能火这么多年，核心在于它把“从原理到落地”的门槛压得很低，但也正因为门槛低，大家反而容易忽视隐藏在简单 API 下的那层复杂性。数据、训练、部署、评估，每一环都有大量细节，任何一个环节出错，最终模型的表现在现场都会如实反馈给你。把这条链路完整走通一遍，你对检测的理解，会比刷一百篇论文都扎实。