聊到目标检测，绕不开三个名字：RCNN、YOLO、DETR。它们分别代表了两阶段检测、单阶段检测、端到端Transformer检测三种思路，也是工业落地、竞赛刷分、学术研究里最常被拿来做对比的三大流派。很多新手一上来就急着跑YOLO训练，但遇到精度瓶颈、部署延迟、小目标漏检这些问题时，往往是因为不清楚三种方案背后的设计逻辑。这篇文章我按自己的理解把三者的核心原理、损失函数、训练细节和部署坑点串起来讲一遍，读完你至少能明白：某个业务场景下，到底该选哪个方案，以及选完之后训练和部署有哪些必须避开的坑。
1. 两阶段检测器：RCNN系列是怎么一步步把“检测”拆成两个工序的
两阶段的核心思路一句话就能概括：先把可能有物体的区域找出来，再对这些候选区域挨个做分类和框回归。整个过程像一场筛选面试，第一轮海选先圈定重点，第二轮精面再逐个确认。这个思路从RCNN一路进化到Faster RCNN，每一步都在解决一个明确瓶颈。
1.1 RCNN的开山思路：区域提议加分类，为什么当年能跑通
2014年RCNN提出的时候，目标检测还没有一个统一的可训练框架。当时大家的做法是把检测拆成候选区域生成、特征提取、分类三个独立步骤。RCNN用的是Selective Search，先在图上融合颜色、纹理、大小等相似区域，生成大概2000个候选框，然后对每个候选框裁剪缩放成固定尺寸，分别送进CNN提取特征，最后接一个SVM分类器和一个框回归器。
这里有一个关键点：RCNN的训练是分阶段进行的，CNN分类器、SVM、框回归器是分开优化的，不是端到端。我见过不少刚接触这个时期论文的人不理解为什么要这么做。理由是当时的GPU算力和数据规模都不支持端到端的联合训练，而且SVM在小样本上有优势。这套思路虽然精度在当时很惊艳，但速度非常感人——每张图片在GPU上也要跑几十秒，因为2000个候选框每个都要独立过一次网络，完全没有共享中间计算。
1.2 Fast RCNN的共享卷积与RoI池化：让提速成为可能
Fast RCNN最大的改进在于解决了“重复计算”的问题。它把整张图只过一次CNN，得到完整的特征图，然后把Selective Search生成的候选框映射到特征图对应的区域上，再通过RoI池化把每个区域统一成固定尺寸，送到后面的全连接层做分类和回归。
RoI池化的逻辑值得好好理解。它把候选区域在特征图上划分成固定格数，比如7x7，然后对每个格子做最大池化。这样一来，不管候选框原始大小怎么变，输出的特征尺寸都是7x7，后面的全连接层就可以接收定长输入。这个设计让一张图上所有候选框共享了底层的卷积计算，检测速度比RCNN高了差不多两个数量级。Fast RCNN还顺手把SVM换成了Softmax，把分类和框回归放进同一个网络里做多任务训练，这时候已经非常接近后来的工业落地形态了。
1.3 Faster RCNN的RPN：把“找框”也变成网络的一部分
Faster RCNN的贡献是把“候选区域生成”这件事也从外部算法换成了网络结构。它引入了一个轻量级的RPN（Region Proposal Network），直接在特征图的每个位置预置若干不同尺度和长宽比的anchor框，然后网络同时输出这个anchor是前景还是背景，以及相对真实框的偏移量。这一步相当于让“找框”也变成可以梯度优化的环节。
RPN和Fast RCNN检测头在训练的时候是交替优化的，推理时两个阶段串起来用。第一阶段RPN从几万个anchor里粗筛出几百个候选区域，第二阶段检测头再对候选区域精分类并修正框的位置。整个过程就是一个完整的、可训练的端到端模型，精度和速度均衡，也是后面很多工业方案的基础。
1.4 两阶段模型怎么选：Faster RCNN的适用场景和性能参考
正常情况下，同等骨干网络下，Faster RCNN的精度要好于大部分单阶段模型，因为两阶段相当于多了一次“精修”机会，对小目标和遮挡场景更友好。参考公开报告的数据，以ResNet50-FPN为骨干的Faster RCNN在COCO val上的mAP大概在37到40之间，而同一批骨干的YOLOv4或YOLOv5类似量级的模型，在速度领先的情况下，精度大约在33到38之间。当然具体要看训练策略和数据，不能只看单组benchmark就下死结论。
选择上我的经验是：如果你的任务里目标尺寸跨度大、小目标比例高，或者你手里只有小规模数据集，需要稳定可控的训练过程，那Faster RCNN系列更稳。反之，如果目标是实时视频流、边缘设备、快速迭代，那单阶段方案更合适。两阶段最大的代价是速度和结构复杂度，部署时要多写不少前后处理逻辑，这一点后面讲部署的时候会再展开。
2. YOLO系列：单阶段把检测当成回归问题做
YOLO的出现可以说是对两阶段方案的一次彻底反叛。它不在第一阶段生成候选区域，而是把整张图划分成网格，直接在每个网格上预测目标的类别和框坐标。整套检测被压缩成一次前向推理，从图像输入到最终输出之间没有任何中间筛选环节，所以速度天然占优。
2.1 YOLOv1的核心思想：网格划分、边界框与宽高开根号的用意
YOLOv1把输入图片划分为S x S的网格，比如7x7。每个网格负责预测若干个边界框，比如2个，每个框输出中心坐标、宽高、置信度，再加上网格对所有类别的分类概率。如果一个物体的中心落在某个网格内，那么这个网格就负责预测这个物体。
这里有个很多人忽略的设计细节：损失函数里对宽高做了开根号处理。原因是原始宽高的数值方差很大，大物体的几像素偏移和小物体的几像素偏移在误差数值上差异巨大。对大框来说，2像素偏差稀松平常，但对小框来说这可能是致命的。开根号的作用是压缩大尺寸和高数值的误差权重，让模型不太容易被大框带偏。这个小技巧后来也被很多单阶段模型沿用。理解了这一点，再看后面版本对损失函数的各种改动就容易多了。
2.2 从v2到v8的演进主线和每个版本的典型改动
YOLO系列的演进脉络非常清晰，每个版本都在解决前一个版本的突出短板。YOLOv2引入了anchor机制和Batch Normalization，让模型开始具备相对稳定的训练过程；YOLOv3引入了多尺度预测和FPN结构，不同尺寸的特征图分别负责大中小目标的检测，小目标召回率第一次有了明显改善；YOLOv4和YOLOv5时期，工程细节开始主导，比如Mosaic数据增强、CIoU损失、CSP结构、EMA权重等，这些改动让训练更方便、部署更容易。
到了YOLOv8，Ultralytics做了许多结构性调整，把anchor-free机制变成了默认配置，检测头不再依赖预设anchor，而是直接在特征图上预测中心和宽高，配合DFL（Distribution Focal Loss）和CIoU损失，整体训练更简洁。我自己的体感是，v8对新手最友好，文档全，API统一，但它的某些结构细节和训练技巧直接沿用v5也不是不行，选择标准应该看你自己的数据量、硬件资源和团队习惯，不必盲目追新。
2.3 YOLO损失函数全景：分类、框回归和置信度分别怎么算
YOLO的损失函数长期以来由三部分组成：分类损失、边界框回归损失、置信度损失。分类损失通常用交叉熵，判断每个网格预测的类别和真实类别是否一致；置信度损失是判断预测框中是否有物体，并与真实IoU进行对比；框回归损失则负责让预测的坐标尽可能贴合真实框。
早期的YOLOv1用的是均方误差来做框回归，YOLOv3之后大家普遍换成IoU系列损失。IoU损失有个天然问题是当两个框完全不重叠时，损失梯度为0，所以后来又演化出GIoU、DIoU、CIoU这些变体。YOLOv5和v8最常见的组合是CIoU加上DFL，其中DFL负责让框回归变成一种分布预测而非单点预测，这在处理边界模糊目标时很有帮助。训练的时候一般让这三个损失的权重保持默认即可，但如果你发现某一类任务表现明显失衡，比如框位置总是偏大或偏小，可以先试着调整框回归损失的权重，而不是一上来就改学习率。
2.4 什么时候果断选YOLO，什么时候要犹豫
YOLO最适合的场景是视频级实时检测，比如监控、车载、工业质检流水线。原因是单阶段前向一次出结果，部署到TensorRT之后，帧率可以做得非常高。加上生态极其成熟，标注格式、导出onnx、TensorRT脚本、各种平台支持都非常完善，几乎从训练到上线是一条龙。犹豫的场景通常是极致的精度竞赛和小目标密集场景。如果图片里有大量微小目标，比如几十个像素的远处行人，YOLO多尺度预测虽然能覆盖一部分，但相比DETR这类全局建模的模型，它在上下文理解上会偏弱，需要靠多尺度增强和加大输入分辨率来补救。
3. DETR：Transformer进入检测，把目标检测变成集合预测
DETR是2020年Facebook提出的端到端检测框架，它彻底改变了前面这些模型的设计语言。它不再使用anchor、不再使用NMS、也不需要RPN，而是把检测看作一个“从N个候选查询到N个预测结果”的集合预测问题，用Transformer的去重能力直接产出最终框。
3.1 取消anchor与NMS的底层逻辑：匈牙利匹配和object queries
DETR整体的流程是这样的：CNN骨干提取特征后，把特征图展平成序列输入Transformer的Encoder；Decoder输入的是一个固定数量的可学习object queries，比如100个；这些query通过交叉注意力从Encoder特征里“查询”出各自感兴趣的目标，最终每个query输出一个框和一组类别概率。
由于这一百个query都可能被用于预测目标，训练时就必须做匹配。DETR用匈牙利算法在预测结果和真实框之间做二分匹配，确保每个真实框只对应一个最优预测，其他预测则被分类为“无目标”。正是这种显式的匹配机制，让模型在推理时自然避免了重复预测，NMS因此被扔掉。理解了这一点，你再看DETR的工作过程就不会觉得神秘：它本质上是让网络自己学习把目标与query一一对应起来。
3.2 用DETR训练自己的数据：收敛速度、epoch设置和骨干冻结技巧
DETR训练自己数据时，最大的体感就是慢。原始论文用了500个epoch在COCO上训练，普通GPU实在耗不起。如果只是在自己业务数据上微调，我建议先加载COCO上预训练的checkpoint，然后把骨干网络冻结住，只训练Transformer部分。这样既能保留骨干的特征提取能力，又能显著减少训练时间。
数据规模上，DETR对数据量的要求比YOLO高。这是因为Transformer的全局注意力需要大量样本才能学到稳定的匹配关系。如果你只有一两千张自定义数据，建议先在类似领域做预训练，或者用Deformable DETR这类收敛更快的变体。还有个容易踩的坑是输入分辨率。DETR默认把图片变成固定尺寸送入网络，如果业务图本身很大且目标很小，不能像YOLO那样简单调个imgsz就完事，需要确认Encoder里特征序列长度是否超出显存预算，必要时裁剪或切块训练。
3.3 DETR的变体与改进：Deformable、DINO和RT-DETR的实用价值
原版DETR的问题主要集中在收敛慢、小目标弱、计算量大，业界很快给出了一系列改进。Deformable DETR把注意力变成了稀疏采样，只在参考点附近选取少量采样点，大幅降低计算量，收敛速度提升约10倍。DINO则在Deformable的基础上做了对比去噪训练，把收敛速度和精度进一步拉高，是当前很多实验室做端到端检测的首选基线。
真正让DETR进入工程视野的是RT-DETR，它把Encoder的复杂计算做了重构，引入了高效的混合编码器和IoU-aware查询选择，依靠视觉特征主导而非decoder交叉注意力来生成查询，从而在DETR系列里达成了实时性能。实测下来，RT-DETR在相似延迟下精度可以和YOLOv8掰掰手腕，而且免去了NMS，部署链路更短。如果说DETR代表了学术上的完整形态，RT-DETR就是把这个形态商业化的那个版本。
4. 从训练到部署：YOLO工程落地的完整链路
前面花了不少篇幅讲原理，现在说说我实际训练和部署时最常用的一套流程。这部分以YOLO为主，因为它的生态最成熟，也最容易踩到具体问题。整个链路从数据准备开始，到训练参数、评估指标，再到TensorRT部署和多路并发估算，每一环都有讲究。
4.1 数据准备：标注格式转换、数据集划分与真实场景数据采集
数据是检测项目的天花板。无论选哪个模型，数据质量不过关，后面的训练和调参基本都是白费。YOLO训练用的最标准格式是每个图片对应一个同名txt文件，每行内容为“类别编号 cx cy w h”，其中cx、cy、w、h都是相对图像宽高的归一化坐标。如果拿到的数据是VOC格式的xml或者COCO格式的json，需要先做转换，这个环节我建议写一个脚本统一处理，不要手动改。
数据集划分上，我习惯按8:1:1划分训练、验证、测试，并且用随机种子固定下来，保证多次实验可以公平对比。划分的时候要注意同一张图片的不同增强版本不能同时出现在训练集和验证集中，否则会天然抬高评估分数。还有一点容易被忽略：公开数据集如中餐菜品、电力红外设备这类特定领域，最好先做一轮真实业务场景的数据采集，再补充公开数据。公开数据集往往场景单一，直接拿到业务里用，很容易出现域差异导致的精度骤降。
4.2 训练参数的选择：预训练权重、batch size与学习率
YOLO训练时最省事的做法是加载官方预训练权重，比如yolov8s.pt，在此基础上微调。这样做的好处是骨干网络已经具备通用的特征提取能力，即使你的数据量不大，也能在较少的epoch内达到不错的效果。训练命令可以用下面最基本的方式启动：
yolo detect train data=data.yaml model=yolov8s.pt epochs=100 imgsz=640 batch=16 device=0,1这里比较关键的是batch size。batch太小会出现一个很典型的训练问题——BN统计量不稳定，也就是很多人说的BN崩溃，后面我会专门讲。batch大则相对稳定，但会占用更多显存。当显存不够时，我优先建议降低分辨率而不是强行减小batch，或者使用梯度累积。学习率方面，用官方默认配置通常没问题，但如果发现loss抖得厉害，可以考虑把初始学习率从0.01降到0.003左右，再配合warmup来稳定前几个epoch。
4.3 评估指标怎么看：混淆矩阵、mAP和“总和不为1”的真相
训练完要看模型好坏，离不开混淆矩阵和mAP。YOLO训练结束后会在验证集上输出混淆矩阵，每一行代表真实类别，每一列代表预测类别，对角线是正确分类的比例。很多人会拿这个矩阵去算行和或列和，发现无论如何都不为1，于是怀疑程序出了问题。其实检测任务的混淆矩阵和分类任务完全不同。
检测里的一个真实框既有可能被预测匹配，也可能因为置信度低于阈值而没有被匹配，没匹配上的会被计入背景类。同一张图里还可能存在预测框和真实框的IoU刚好卡在阈值边缘，导致归类不一致的情况。所以单看混淆矩阵的行和列，总和不为1是非常正常的，它受置信度阈值、IoU阈值、NMS设置共同影响。真正要关注的是对角线上的数值：行归一化之后，对角线数值代表每一类有多少比例被正确检出。
mAP也是同理，它把Precision-Recall曲线下的面积做一个积分，兼顾了不同阈值下的表现。我平时更习惯分开看：mAP50看整体框得准不准，mAP50-95看框和类别的综合精细度。如果你的业务是精准计数，就多关注mAP50；如果业务要求精细分割级别的框质量，那mAP50-95更有参考价值。
4.4 TensorRT部署与多路视频流的并发估算
YOLO训练完之后，下一步就是部署。常见的流程是先导出onnx，再用TensorRT转成engine，FP16是性价比最高的选择。导出onnx时要注意opset版本和动态尺寸设置，务必把动态batch和动态分辨率打开：
yolo export model=best.pt format=onnx dynamic=True opset=12 trtexec --onnx=best.onnx --saveEngine=best.engine --fp16 --minShapes=images:1x3x640x640 --optShapes=images:8x3x640x640 --maxShapes=images:16x3x640x640这里再解释一下很多人关心的“T4跑1080P25帧每秒视频流能支持多少路”。先看单路负载，假设每路视频用640分辨率YOLOv8s做检测，TensorRT FP16推理一帧大约5到8毫秒，加上视频解码、缩放预处理、后处理NMS，单帧完整处理链路保守估计在10到12毫秒。一路视频每秒25帧，意味着单路每秒要吃掉约250到300毫秒的GPU时间。T4整卡一秒只有1000毫秒，所以按同步串行处理的话，理论并发在3到4路之间。但如果把多路视频的帧组成batch一次推理，GPU利用率能显著提升，配合DeepStream这类方案，实际并发可以做到8到10路甚至更高。所以这个问题没有标准答案，它取决于模型规格、是否batch化、预处理是否搬到了GPU上、是否用了硬解。
5. 常见问题与排查技巧实录
最后这部分是我这些年踩坑的集合。很多问题在文档里找不到标准答案，但遇到的时候一旦不会排，整个项目节奏就卡住了。
5.1 训练不收敛或loss为nan，按优先级查这四件事
第一查数据：确认标注框里没有出现负值坐标、宽高为0、类别索引越界这类低级问题。第二查学习率：初始学习率过大是loss爆炸最常见的元凶，尤其当你换了大模型或大batch时，原来的学习率可能已经不适用。第三查BN：如果batch size小于8，BN统计量极不稳定，loss会出现周期性震荡，建议加大batch或用SyncBN。第四查硬件：混合精度训练时，某些显卡驱动版本和CUDA版本不匹配，会偶发nan值，可以先用FP32跑几个epoch验证一下。
BN崩溃值得多说一句。我实际遇到过训练到一半loss突然飙高，之后再也降不下来的情况，排了一圈发现是数据里混了少量全黑的图片，走归一化之后特征方差为0，BN的running stats被污染了。从此我所有数据集都会在训练前写一段脚本做min-max检查，把异常图片单独拎出来看一眼。
5.2 小目标漏检严重：分辨率、P2层与多尺度训练
小目标漏检是YOLO系列的老问题。先看特征金字塔，YOLO默认从P3开始往下融合，P3对应的是下采样8倍的特征图，每个特征点大约对应原图8x8像素。如果目标本身就小于8x8像素，那么在特征图里几乎没有可用的特征点，检不出来是必然的。
最简单的缓解办法是提高输入分辨率，把imgsz从640提到960甚至1280，小目标的特征点变多了，精度会明显改善，代价是推理变慢。如果再不够，那就需要增加P2层，即把下采样4倍的特征图也接入检测头。P2层对显存和计算量都不友好，一般只在高精度场景中使用。还有一个常用组合是开启多尺度训练，训练时随机在0.5到1.5倍分辨率之间切换，让模型对小目标更鲁棒，但理解上要清楚这只是正则化手段，不会凭空增加信息量。
5.3 RTSP监控视频流检测：拉流、抽帧与断流处理
做监控类项目时，输入不是一张张图片，而是RTSP视频流。最直接的方式是用FFmpeg拉流，按固定间隔抽帧送入检测模型。抽帧间隔取决于你的业务要求，每秒抽1帧和每秒抽5帧对CPU、GPU的消耗差别很大。
这里有个关键设计：抽帧一定要放到独立线程或进程，否则解码卡顿会直接阻塞检测主循环。视频流还有个常见问题是网络抖动导致断流，重连逻辑一定要做成指数退避，几十秒就疯狂重试只会让服务器负载雪崩。如果机器网卡和CPU都比较紧张，可以考虑GPU硬解，把解码这一步也从CPU搬走。我习惯用带异步队列的解码框架，解码线程塞满队列，检测线程从队列取帧，这样即使偶发解码延迟，检测侧也不至于空等。
5.4 模型加速瘦身：蒸馏、剪枝和CLIP辅助的新玩法
训练好一个大模型之后，直接用大模型做部署当然精度最高，但成本也高。我常用的一条路线是“大模型训，小模型学”，也就是知识蒸馏。具体做法是把YOLO大模型的输出概率或特征图当作老师，让一个小模型在同样的数据上通过损失函数来模仿老师的输出。温度系数通常取3到5，蒸馏损失和真实标签的损失按0.5比0.5加权。这种方式在边缘设备上能拿到比直接训练小模型高几个点的精度。
剪枝的思路则是把不重要的通道裁掉。有些框架可以自动分析BN层缩放因子，把gamma小的通道认为是冗余通道，剪掉之后微调恢复精度。这个方案在YOLOv5时代很流行，v8上因为结构改动，剪枝工具没有跟上，所以用的人相对变少。最近还有一个很有意思的方向是YOLO加CLIP，利用CLIP的图文对齐能力实现开放词汇检测，也就是模型不用事先固定死类别，输入一段文本描述就能去找对应的目标。现阶段它还不能完全替代标准YOLO，但做预筛选和新品类探测场景，已经很有实用价值了。
我个人目前在实际项目里最常用的组合还是“YOLOv8做主干检测，DETR系做复杂场景复检，Faster RCNN作为精度基准线”。这三个流派不是互相替代的关系，而是同一问题的三个求解角度。你在选型时可以先拿公开权重在你的验证集上跑一轮，用数据说话，再决定往哪个方向投入调参时间。检测这个领域不缺少理论，缺的是把理论落到自己数据和业务场景里的耐心。
