目标检测这块RCNN、DETR、YOLO 这三个名字几乎是绕不开的。不管你是刚入门想搞清楚该从哪下手还是已经跑过几个项目想回头把知识体系捋顺这三条技术路线代表的是三种截然不同的设计哲学。RCNN 系列是两阶段检测的开山鼻祖DETR 把 Transformer 引入检测领域做端到端预测YOLO 则一路把单阶段实时检测推到今天仍然是最主流的工程选择。我这些年从 YOLOv3 一路跟到 v8、v11中间也踩过 DETR 训练不收敛、RCNN 环境配到崩溃的坑这篇文章就把这三条线的核心逻辑、实操要点和我自己踩过的坑一次性讲清楚。1. 三条技术路线的本质分歧在哪1.1 从“怎么找目标”这个问题说起目标检测要解决的核心问题就两个目标在哪定位目标是什么分类。三条路线最大的分歧其实在于它们回答“目标在哪”这个问题的思路完全不同。RCNN 系列的思路是“先粗筛再精修”。它先想办法在图上生成一大堆可能包含目标的候选区域Region Proposal然后对每个候选区域单独做分类和边框回归。这个思路非常符合人的直觉——先扫一眼哪里可能有东西再凑近了仔细看。但代价就是慢因为每个候选框都要过一次网络。YOLO 的思路是“一眼定乾坤”。它把整张图切成网格每个网格直接预测自己负责的区域里有没有目标、是什么、框在哪。一次前向传播就出结果所以快。代价是早期版本对小目标和密集目标的效果不如两阶段方法不过后面几代已经把这个差距补得差不多了。DETR 的思路最“另类”——它把检测当成一个集合预测问题。用 Transformer 的编码器-解码器结构直接输出一组固定数量的预测结果然后通过二分图匹配Hungarian Matching把预测和真实标注对应起来。没有锚框没有 NMS 后处理真正意义上的端到端。听起来很优雅但训练收敛慢是它最大的痛点。1.2 一张表看清三者的设计取舍维度RCNN 系列Faster RCNNDETRYOLO 系列检测范式两阶段端到端集合预测单阶段是否需要锚框是RPN 生成否是v8 起有 Anchor-Free 分支是否需要 NMS是否是部分版本可省略推理速度慢中等快小目标效果好一般需多尺度改进中上v8 以后明显提升训练收敛较快很慢500 epoch 起步快部署生态一般一般极其成熟适合场景精度优先、离线处理研究、需要端到端 pipeline实时检测、工程落地这张表不是让你背的而是帮你在选型的时候有个判断依据。我见过太多人上来就问“哪个最好”这个问题本身就不对——没有最好只有最合适。1.3 为什么工程落地几乎都选 YOLO说句实在话如果你是要把检测模型部署到实际产品里YOLO 系列基本是默认选项。原因不复杂部署工具链成熟TensorRT、ONNX、OpenVINO 都有现成方案、社区活跃遇到问题搜得到答案、预训练模型丰富COCO 上直接拿来 fine-tune 就行、推理速度快到可以满足绝大多数实时场景。Faster RCNN 不是不好它在精度上仍然有优势尤其是小目标和遮挡场景。但推理速度摆在那里1080p 图像在 V100 上跑 Faster RCNN 大概也就十几 FPS而 YOLOv8 同等条件下轻松上百 FPS。DETR 就更不用说了原始版本推理速度比 Faster RCNN 还慢虽然后续有 Deformable DETR、DINO 等改进版本但工程部署的便利性还是不如 YOLO。2. RCNN 家族两阶段检测的进化链条2.1 从 RCNN 到 Faster RCNN 解决了什么RCNN 的原始版本流程特别笨重先用 Selective Search 在图上生成约 2000 个候选区域然后对每个区域单独跑 CNN 提取特征最后用 SVM 分类。一张图要跑 2000 次 CNN速度慢到没法实用。Fast RCNN 做了第一个关键改进不再对每个候选区域单独跑 CNN而是先对整张图跑一次 CNN 得到特征图然后通过 RoI Pooling 把候选区域映射到特征图上。这样一张图只需要一次 CNN 前向速度快了很多。但它仍然依赖 Selective Search 生成候选区域这部分在 CPU 上跑成了新的瓶颈。Faster RCNN 的贡献就是用一个可学习的 RPNRegion Proposal Network替代了 Selective Search。RPN 本身也是卷积网络和检测头共享特征提取的 backbone所以整个流程可以在 GPU 上端到端训练。这一步真正让两阶段检测变得实用了。2.2 RPN 的工作机制拆解RPN 的核心是在特征图的每个位置上预设一组锚框Anchor通常每个位置有 9 个锚框3 种尺度 × 3 种长宽比。对每个锚框RPN 做两件事判断这个锚框里有没有目标二分类前景/背景回归锚框到真实框的偏移量dx, dy, dw, dh训练时和真实框 IoU 大于 0.7 的锚框标为正样本小于 0.3 的标为负样本中间的忽略。推理时RPN 输出一堆候选框经过 NMS 筛选后取前 N 个送给后面的 RoI Head 做精细分类和回归。这里有个实操中容易忽略的点锚框的尺度和长宽比需要根据你的数据集调整。如果你检测的都是小目标比如试卷上的文字区域默认的锚框尺度可能偏大需要调小。这个参数在 Detectron2 里是ANCHOR_GENERATOR.SIZES在 MMDetection 里是anchor_generator的配置。2.3 Faster RCNN 训练自己数据的实操要点以 MMDetection 为例训练自己数据的流程大致是这样# 配置文件的核心修改点 model dict( typeFasterRCNN, backbonedict( typeResNet50, depth50, init_cfgdict(typePretrained, checkpointtorchvision://resnet50)), neckdict( typeFPN, in_channels[256, 512, 1024, 2048], out_channels256, num_outs5), rpn_headdict( typeRPNHead, in_channels256, feat_channels256, anchor_generatordict( typeAnchorGenerator, scales[4, 8, 16], # 根据目标大小调整 ratios[0.5, 1.0, 2.0], strides[4, 8, 16, 32, 64])), roi_headdict( typeStandardRoIHead, bbox_headdict( typeShared2FCBBoxHead, num_classes你的类别数, # 这里改成实际类别数 reg_class_agnosticFalse)))数据集按照 COCO 格式组织然后改data_root和ann_file路径就行。训练命令python tools/train.py configs/faster_rcnn/faster_rcnn_r50_fpn_1x_coco.py有几个坑我踩过一是学习率不要照搬 COCO 的配置自己的数据集小的话学习率要降二是如果类别不均衡严重分类损失会被多数类主导可以考虑用 Focal Loss 或者对损失加权三是数据增强不要开太猛尤其是 Mosaic 这种两阶段检测对增强的敏感度和 YOLO 不一样。3. DETR端到端检测的理想与现实3.1 DETR 到底优雅在哪DETR 的论文我第一次读的时候确实觉得设计很漂亮。它完全抛弃了锚框和 NMS用 Transformer 的编码器-解码器结构直接输出预测集合。具体来说CNN backbone 提取特征图展平后加上位置编码送入 Transformer 编码器解码器接收一组可学习的 object queries通常是 100 个通过交叉注意力从编码器输出中提取信息每个 query 经过 FFN 输出一个预测类别 边框多余的 query 预测为“无目标”训练时的核心是二分图匹配用 Hungarian 算法把预测和真实标注做最优匹配然后只对匹配上的对计算损失。这样就避免了 NMS 后处理也避免了锚框带来的重复预测问题。3.2 为什么 DETR 训练这么慢DETR 最被人诟病的就是收敛慢。原始论文在 COCO 上要训 500 个 epoch 才能达到 Faster RCNN 训 100 个 epoch 的效果。原因主要有两个一是二分图匹配的不稳定性。训练初期预测结果很乱Hungarian 匹配出来的对应关系每次都在变导致优化目标不稳定。二是 Transformer 的交叉注意力需要很长时间才能学会关注到正确的区域。object queries 初始是随机可学习的它们要学会“各自负责图像的不同区域”需要大量迭代。Deformable DETR 针对这个问题做了改进用可变形注意力Deformable Attention只关注参考点周围的少量采样点而不是全局注意力。这样收敛速度提升了 10 倍左右小目标效果也好了很多。如果你要用 DETR 做实际项目我建议直接从 Deformable DETR 或者 DINO 开始不要用原始版本。3.3 DETR 训练自己数据的完整流程以 Deformable DETR 为例训练自己数据的步骤第一步准备 COCO 格式的数据集。DETR 系列对数据格式要求比较严格标注文件必须是标准的 COCO JSON 格式。第二步修改配置文件中的类别数# 在 config 中修改 num_classes 你的类别数 # 注意不包括背景类第三步调整学习率和训练轮数。DETR 系列通常用 AdamW 优化器backbone 的学习率要比 Transformer 部分低一个数量级optimizer dict( typeAdamW, lr2e-4, # Transformer 部分 weight_decay1e-4, paramwise_cfgdict( custom_keys{ backbone: dict(lr_mult0.1), # backbone 用 1/10 学习率 }))第四步训练。Deformable DETR 通常 50 个 epoch 就能收敛得不错但如果你数据量小可能需要更多轮。我实际训练的时候遇到过一个典型问题loss 震荡特别厉害尤其是分类 loss。后来发现是 object queries 数量设置不合理——默认 100 个 query但我数据集里一张图最多就十几个目标多余的 query 一直在学“预测无目标”反而干扰了有效 query 的学习。把 query 数量降到 30 之后稳定了很多。4. YOLO 系列工程落地的首选方案4.1 YOLO 的核心设计哲学YOLO 的核心思想就一句话把检测当成回归问题一次前向传播直接输出所有目标的位置和类别。这个思路在 2015 年提出的时候是颠覆性的因为之前大家都觉得检测必须分两步走。YOLOv1 把图像分成 7×7 的网格每个网格预测 2 个边界框和置信度加上 20 个类别的条件概率。虽然精度不如当时的 Faster RCNN但速度达到了 45 FPS碾压级别的快。后续版本的演进主线很清晰v2 引入 Anchor Box 和 Batch Normalizationv3 引入 FPN 多尺度预测和更好的 backboneDarknet-53v4 堆了一堆技巧Mosaic 增强、CIoU Loss、DropBlock 等v5 工程化做得最好自适应锚框、自动学习边界框回归v8 回归 Anchor-Free 并统一了检测/分割/分类框架。4.2 YOLOv8 的训练与部署实操YOLOv8 是目前工程上最推荐的版本Ultralytics 的 API 设计得非常简洁。训练自己数据的流程from ultralytics import YOLO # 加载预训练模型 model YOLO(yolov8n.pt) # n/s/m/l/x 可选 # 训练 results model.train( datamydata.yaml, # 数据集配置 epochs100, imgsz640, batch16, lr00.01, patience20, # 早停 device0)数据集配置文件mydata.yaml的格式path: /path/to/dataset train: images/train val: images/val nc: 3 # 类别数 names: [cat, dog, person] # 类别名标注格式用 YOLO 格式每行类别 x_center y_center width height都是归一化后的值。如果你手里是 VOC 格式的标注可以用官方提供的转换脚本# VOC 转 YOLO python tools/voc2yolo.py --voc_dir /path/to/VOC --output_dir /path/to/yolo4.3 YOLO 损失函数的设计逻辑YOLO 的损失函数是理解它为什么 work 的关键。以 v8 为例损失由三部分组成分类损失用的是 BCE LossBinary Cross Entropy每个类别独立计算二分类损失。这和 Softmax 不同BCE 允许一个目标同时属于多个类别多标签场景也更适合类别不均衡的情况。边界框回归损失用的是 CIoU LossComplete IoU。相比原始的 MSE 直接回归坐标CIoU 考虑了三个因素重叠面积、中心点距离、长宽比一致性。这样梯度更合理收敛更快。置信度损失Objectness也是 BCE判断这个位置有没有目标。# YOLOv8 损失的核心逻辑简化版 loss_cls BCE(pred_cls, target_cls) loss_box CIoU(pred_box, target_box) loss_dfl DFL(pred_dist, target_dist) # Distribution Focal Loss total_loss loss_cls loss_box loss_dfl这里有个实操经验如果你的数据集里小目标特别多可以适当增大 box loss 的权重如果类别极不均衡可以给分类损失加权重或者用 Focal Loss 替代 BCE。4.4 YOLO 部署从 PyTorch 到 TensorRT训练完的模型要部署到生产环境通常需要转成 TensorRT 来加速。以 YOLOv8 为例# 导出 ONNX yolo export modelbest.pt formatonnx opset12 # 导出 TensorRT Engine yolo export modelbest.pt formatengine halfTrue device0导出 TensorRT 的时候有几个参数很关键halfTrue启用 FP16 精度速度提升明显精度损失通常在 1% 以内imgsz640输入分辨率要和训练时一致batch根据你的 GPU 显存调整workspaceTensorRT 构建时的最大工作空间默认 4GB复杂模型可能需要调大关于推理速度有个经常被问到的问题T4 上 1080p 25 帧的视频用 TensorRT 跑 YOLO 640 分辨率检测能支持多少路这个要算一下。T4 上 YOLOv8n 在 640 分辨率下 FP16 推理大概 2-3ms 一帧加上前后处理大概 5ms。25 FPS 意味着每帧 40ms 的预算理论上单路只占 5ms那 8 路以内问题不大。但实际还要考虑视频解码、内存拷贝、后处理 NMS 的开销保守估计 4-6 路比较稳。如果是 YOLOv8m 或更大的模型路数要相应减少。4.5 YOLO 实例分割与检测的区别YOLOv8 除了检测还支持实例分割yolov8n-seg.pt。分割和检测的区别在于分割除了输出边界框和类别还要输出每个目标的像素级掩码。分割的训练流程和检测几乎一样只是标注格式不同——需要多边形标注而不是矩形框。损失函数多了一个掩码损失通常是 BCE训练时间会比纯检测长一些。实际用下来YOLOv8-seg 的分割精度对于大多数应用场景够用了但如果你需要非常精细的边缘比如医学图像分割还是得上专门的分割模型如 SAM、Mask2Former。5. 训练中那些让人抓狂的问题5.1 BN 层崩溃到底怎么回事YOLO 训练中 BNBatch Normalization崩溃是个高频问题表现是 loss 突然变成 NaN或者 mAP 骤降到 0。根本原因通常是某个 batch 内的统计量异常方差为 0 或者极大值导致归一化后的值爆炸。触发 BN 崩溃的常见原因学习率太大梯度爆炸传导到 BN 层统计量被污染batch size 太小BN 依赖 batch 内统计量batch 太小统计量不稳定数据异常输入图像有极端值全黑、全白、损坏文件混合精度训练FP16 的数值范围有限容易溢出解决方案我试过有效的几个降低学习率尤其是 warmup 阶段要足够长增大 batch size或者用梯度累积模拟大 batch检查数据集剔除异常样本用torch.nn.SyncBatchNorm多卡同步 BN混合精度训练时开启loss_scale动态缩放5.2 混淆矩阵总合不唯一的排查思路YOLO 训练完看混淆矩阵有时候会发现行和列的总和对不上。这个问题通常不是 bug而是理解上的偏差。混淆矩阵的行表示真实类别列表示预测类别。对角线是正确预测非对角线是误判。行总和 该类别的真实样本数列总和 被预测为该类别的样本数。两者不相等是正常的因为存在漏检真实有但没预测出来和误检预测有但真实没有。如果你发现某个类别的行总和远大于列总和说明这个类别漏检严重反过来列总和远大于行总和说明误检多。还有一种情况是背景类background的处理方式不同导致的总和不一致这个要看具体实现。5.3 小目标检测效果差的系统性解法小目标检测是目标检测里的老大难问题。YOLO 在小目标上表现不好的原因主要是下采样导致小目标的特征信息丢失严重。一个 16×16 的小目标经过 32 倍下采样后在特征图上就剩 0.5 个像素了。我总结的解法按优先级排列提高输入分辨率从 640 提到 1280小目标像素数翻 4 倍效果立竿见影代价是速度下降用 P2 层特征YOLOv8 默认用 P3-P5加一个 P2 stride4检测头专门管小目标数据增强Mosaic、MixUp 增加小目标出现频率Copy-Paste 直接复制小目标到不同位置切片推理SAHI把大图切成小块分别检测再合并对超大分辨率图像特别有效调整锚框尺度如果用了 Anchor-Based 的版本把最小锚框尺度调小6. 选型建议与学习路径6.1 什么场景选什么模型这个问题我被问过无数次直接给结论实时检测、工程部署YOLOv8 或 YOLOv11没有悬念精度优先、离线处理Faster RCNNDetectron2 版或 DINO需要端到端无后处理Deformable DETR 或 DINO小目标密集场景Faster RCNN FPN或者 YOLO SAHI实例分割YOLOv8-seg速度优先或 Mask2Former精度优先研究/发论文DETR 系列改进空间大YOLO 创新点难找6.2 入门学习路径如果你是刚入门我建议的学习顺序是先跑通 YOLOv8 的官方教程用自己的数据训一个模型出来感受一下完整流程。然后回头理解 YOLO 的损失函数和网络结构搞清楚每个模块在干什么。接着看 Faster RCNN 的论文和代码理解两阶段检测的设计思路。最后再看 DETR 的论文理解 Transformer 怎么做检测。这个顺序的好处是先建立工程直觉再补理论深度。反过来先啃 DETR 论文容易劝退因为涉及的东西太多Transformer、二分图匹配、集合预测没有检测基础很难理解它到底在解决什么问题。6.3 预训练模型下载与使用YOLOv8 的预训练模型在 Ultralytics 的 GitHub Release 页面都能下到也可以直接用 API 自动下载from ultralytics import YOLO model YOLO(yolov8m.pt) # 自动下载Faster RCNN 的预训练模型在 Detectron2 的 Model Zoo 和 MMDetection 的 Model Zoo 都有直接下对应的权重文件加载就行。DETR 系列的预训练模型在 Facebook Research 的 DETR 仓库和 Deformable DETR 仓库有提供但注意这些模型是在 COCO 上训的类别是 COCO 的 80 类用自己数据的时候需要 fine-tune。最后说一个我自己的体会这三个模型看起来是竞争关系实际上在实际项目中经常是互补的。我做过一个电力红外数据集的项目用 YOLOv8 做实时筛查对置信度低的区域再用 Faster RCNN 做二次确认最后 mAP 比单用任何一个都高了 3 个点。所以不要纠结选哪个先把一个跑通再根据实际需求组合使用。