目标检测这块，RCNN、DETR、YOLO这三个名字几乎是绕不开的。不管你是刚入门想搞清楚该从哪个下手，还是已经跑过几个项目、想弄明白为什么YOLO能这么快、DETR凭什么敢把锚框全扔掉，这篇文章都值得花点时间看看。我从最早拿Faster R-CNN跑自定义数据集，到后来用YOLOv5/v8做边缘部署，再到最近折腾DETR的变体，踩过的坑不算少。下面就把这三条技术路线的核心逻辑、实操细节和选型经验，按我自己的理解捋一遍。
1. 三条技术路线的底层逻辑差异
1.1 RCNN系列：从“先找候选再分类”说起
RCNN这个家族的核心思路其实很朴素：既然不知道目标在哪，那就先撒一大把候选框，再逐个判断框里是不是目标、是什么目标。最早的RCNN用选择性搜索（Selective Search）生成约2000个候选区域，每个区域缩放到固定尺寸后送进CNN提特征，最后用SVM分类。这个流程慢得离谱，一张图要几十秒，因为2000个区域意味着2000次前向传播。
Fast R-CNN做了关键改进：整张图只跑一次CNN，然后在特征图上用ROI Pooling把每个候选区域对应的特征抠出来。这一步把速度提升了一个数量级。但候选区域的生成还是靠选择性搜索，这成了新的瓶颈。
Faster R-CNN的贡献是引入了RPN（Region Proposal Network），用神经网络自己学候选框，彻底摆脱了选择性搜索。RPN在特征图上滑动，每个位置预设9个不同尺度和比例的锚框（anchor），输出每个锚框是前景还是背景、以及框的偏移量。这样整个检测流程就变成了端到端的可训练网络。
我实际用Faster R-CNN训练自己数据的时候，最深的感受是：它对小数据集比较友好，因为RPN的锚框机制提供了很强的先验。但配置文件里的anchor尺度、比例这些参数，如果和你的数据分布不匹配，召回率会很难看。比如你检测的是密集小目标，默认的anchor尺度可能全都偏大，这时候需要根据数据集的标注框尺寸做聚类分析，重新设定anchor。
1.2 DETR：把检测当成集合预测问题
DETR（DEtection TRansformer）的思路和RCNN完全不同。它把目标检测看成一个集合预测问题：输入一张图，输出一个固定长度的集合，每个元素要么是一个目标（包含类别和框坐标），要么是“无目标”（no object）。这个固定长度通常设为100，也就是说模型最多输出100个目标。
DETR用Transformer的编码器-解码器结构。CNN backbone（通常是ResNet）先提取特征图，然后展平加上位置编码送进编码器。解码器接收一组可学习的object queries，通过交叉注意力从编码器输出中提取信息，最后每个query经过FFN输出一个预测。训练时用匈牙利算法做二分图匹配，把预测和真实标注一一对应，然后计算损失。
这个设计最吸引人的地方是彻底去掉了锚框和非极大值抑制（NMS）。NMS这个后处理步骤在密集场景下经常出问题，阈值调不好要么漏检要么重复框。DETR直接输出最终结果，后处理非常干净。
但DETR的收敛速度是出了名的慢。原始论文里要训练500个epoch才能收敛，而Faster R-CNN通常几十个epoch就够了。原因在于匈牙利匹配在训练初期很不稳定，模型需要很长时间才能学会把query和实际目标对应起来。后来Deformable DETR通过可变形注意力机制，把收敛速度提升了10倍左右，这才让DETR系列真正实用起来。
1.3 YOLO：一次前向传播搞定所有事
YOLO（You Only Look Once）的核心哲学是：检测就是一个回归问题。把图像划分成S×S的网格，每个网格负责预测中心点落在该网格内的目标。每个网格输出B个边界框（含坐标和置信度）以及C个类别概率。整张图只需要一次前向传播，速度极快。
从YOLOv1到现在的v8/v9/v10，演进路线很清晰：v1/v2奠定基础，v3引入FPN多尺度预测和更好的backbone（Darknet-53），v4/v5工程化做得越来越好，v8把anchor-free和解耦头变成默认配置，v9/v10继续在训练策略和结构上做优化。
YOLO的损失函数是理解它的关键。以v8为例，损失由三部分组成：边界框回归损失（CIoU Loss）、分类损失（BCE Loss）和目标性损失（BCE Loss）。CIoU Loss不仅考虑中心点距离和宽高比，还加入了重叠面积，比早期的MSE Loss收敛更好。分类和目标性用二元交叉熵，配合标签分配策略（Task-Aligned Assigner），让正负样本的划分更合理。
我见过很多人问“YOLO混淆矩阵总合不唯一”的问题，这通常是因为在验证时置信度阈值和NMS的IoU阈值设置不同，导致同一批数据在不同评估轮次中正负样本数量变化。混淆矩阵的行列总和应该等于验证集的目标总数（乘以某个系数），如果对不上，先检查你的评估脚本是不是在NMS之前统计的，或者类别映射有没有错位。
2. 训练自己的数据：三条路线的实操差异
2.1 数据准备与标注格式转换
不管选哪条路线，数据准备都是第一步。标注工具我用过LabelImg、CVAT和Roboflow，小项目LabelImg够用，团队协作推荐CVAT。标注格式通常是Pascal VOC的XML或COCO的JSON。
YOLO需要的是txt格式，每行class_id x_center y_center width height，坐标都归一化到0-1。从VOC转YOLO的脚本网上一抓一大把，但要注意几个坑：图片和标注文件必须一一对应，文件名不能有中文和空格，类别ID从0开始连续编号。我遇到过因为类别ID跳号导致训练时类别数对不上、loss直接NaN的情况。
Faster R-CNN通常用COCO格式或VOC格式，torchvision的检测模块直接支持这两种。如果用Detectron2，它有自己的数据集注册机制，需要把标注转成COCO JSON再注册。DETR官方实现也是COCO格式，但它的评估脚本对标注的字段名很敏感，比如iscrowd字段缺失会报错。
2.2 Faster R-CNN训练自己数据的配置要点
用torchvision的Faster R-CNN做迁移学习，核心是替换分类头。假设你的数据集有5类（加上背景共6类），需要把model.roi_heads.box_predictor替换成新的FastRCNNPredictor(in_features, 6)。backbone通常冻结前几层，只训练后面的层和RPN。
学习率设置很关键。我一般用SGD，初始学习率0.005，momentum 0.9，weight decay 0.0005。前3个epoch用warmup，学习率从0.001线性升到0.005。如果显存不够，把train_batch_size调到2，同时把学习率按比例降到0.0025。
数据增强方面，Faster R-CNN对水平翻转、颜色抖动比较鲁棒，但慎用随机裁剪，因为裁剪可能把目标切掉导致标注框不完整。我试过用Mosaic增强，效果反而不好，因为Faster R-CNN的RPN对拼接后的图像边界很敏感。
2.3 YOLO训练自己数据的完整流程
YOLO的训练流程相对标准化。以YOLOv8为例，先准备data.yaml：
path: ./dataset train: images/train val: images/val nc: 5 names: ['person', 'car', 'dog', 'cat', 'bicycle']然后一行命令启动训练：
yolo detect train data=data.yaml model=yolov8n.pt epochs=100 imgsz=640 batch=16这里有几个经验值：imgsz设为640是速度和精度的平衡点，如果目标特别小可以提到1280，但显存占用会翻倍。batch根据显存调，V100 32G可以跑到64，消费级显卡8G显存建议16。epochs一般100-300，配合早停（patience=50）防止过拟合。
YOLO预训练模型下载很方便，官方在GitHub Release里提供了n/s/m/l/x五个尺度的权重。nano版适合边缘部署，x版精度最高但推理慢。我一般先用n版快速验证流程，确认数据没问题后再换m或l版正式训练。
训练中BN崩溃是个常见问题。表现是loss突然变成NaN，或者BN层的running_mean/running_var变成异常值。原因通常是batch size太小（比如小于8），导致BN统计量不稳定。解决办法：增大batch size，或者改用SyncBN，或者冻结BN层。如果显存实在不够，可以把batch设为4但开梯度累积，等效batch size还是16。
2.4 DETR训练自己数据的注意事项
DETR训练自己数据需要修改分类头的类别数。官方实现里，num_classes要设成你的类别数（不包括背景，因为DETR没有背景类，用no-object代替）。学习率比CNN系列低很多，backbone用1e-5，Transformer部分用1e-4，权重衰减1e-4。
DETR对数据增强比较敏感。官方用了多尺度训练（短边随机缩放到480-800之间）和随机水平翻转。我试过加颜色抖动，效果不明显。另外DETR需要更长的训练时间，即使用Deformable DETR，也建议至少50个epoch。
评估时要注意，DETR的输出是固定100个预测，其中大部分是no-object。计算mAP时需要过滤掉置信度低于阈值的预测，但DETR的置信度是类别概率，没有单独的目标性分数。通常取每个query的最大类别概率作为置信度，阈值设0.5左右。
3. 推理部署与边缘场景的实战考量
3.1 YOLO在RK3588上的部署经验
RK3588是边缘部署的热门芯片，自带NPU算力。YOLOv8部署到RK3588需要把PyTorch模型转成ONNX，再转成RKNN格式。转换过程中有几个坑：
第一，YOLOv8的输出层在导出ONNX时，默认包含后处理（NMS），但RKNN工具链对动态shape支持不好，建议导出时不带后处理，把NMS放到CPU上做。第二，量化时如果校准集选得不好，精度掉得很厉害。我一般从验证集里随机抽200-500张图做校准，覆盖各种光照和场景。第三，RK3588的NPU对某些算子支持有限，比如SiLU激活函数需要替换成ReLU或Hardswish，否则会回退到CPU推理，速度直接崩掉。
实测下来，YOLOv8n在RK3588上跑640×640输入，NPU推理能到30FPS左右，加上CPU后处理大概25FPS。如果换成YOLOv8s，帧率降到15FPS左右。边缘部署监控场景下，误检率高通常是因为量化精度损失和训练数据与部署场景的域差异。解决办法是在部署场景下采集一些数据做微调，或者用更高的量化精度（比如混合量化）。
3.2 DETR的推理优化思路
DETR的推理速度比YOLO慢不少，主要瓶颈在Transformer的解码器。优化方向有几个：减少object queries数量（从100降到50或30），用Deformable Attention替代原始注意力，或者用知识蒸馏把DETR的能力迁移到小模型上。
我试过用TensorRT加速DETR，效果有限，因为Transformer的算子对TensorRT不太友好。后来改用ONNX Runtime，开启图优化和FP16，速度提升了约40%。如果对实时性要求高，DETR目前还不是首选，除非你能接受较低的帧率。
3.3 Faster R-CNN的部署现状
Faster R-CNN的部署场景越来越少，主要因为它的两阶段结构导致推理速度上不去。但在一些对精度要求极高、对速度不敏感的场景（比如医学影像分析、遥感图像检测），Faster R-CNN仍然有优势。部署时通常用TensorRT或ONNX Runtime，把RPN和ROI Head分开优化。
4. 模型改进与前沿融合方向
4.1 YOLO和Transformer的结合
YOLO和Transformer结合是近两年的热门方向。核心思路是用Transformer的注意力机制增强YOLO的特征提取能力，同时保留YOLO的实时性。具体做法有几种：在backbone末端加Transformer编码器层，用注意力机制替换某些卷积层，或者在neck部分用Transformer做特征融合。
我试过在YOLOv8的neck里加一个轻量级的Transformer模块，参数量增加不多，但在小目标检测上mAP提升了约2个点。代价是推理速度下降15%左右。如果部署平台算力充足，这个 trade-off 是值得的。
4.2 Mamba YOLO的复现体验
Mamba是状态空间模型（SSM）的一种，最近在视觉领域很火。Mamba YOLO的思路是用Mamba块替换YOLO中的某些卷积块，利用SSM的线性复杂度来处理长序列依赖。我复现过一版，在相同参数量下，Mamba YOLO在长宽比差异大的目标上表现更好，但训练稳定性不如纯卷积版本，学习率需要调得更小。
4.3 多模态目标检测的探索
YOLO图文多模态是另一个有意思的方向。基本思路是把文本描述作为额外输入，让模型根据文本提示检测特定目标。比如输入“检测所有红色的车”，模型只输出红色车辆的框。实现上通常用CLIP之类的视觉语言模型提取文本特征，和图像特征做对齐，然后送进检测头。
这个方向目前还在早期，工程落地的案例不多。我试过用YOLOv8加一个文本编码器分支，在自定义数据集上效果还行，但泛化能力有限，换一个文本描述就需要重新调。
5. 常见问题排查与经验汇总
5.1 YOLO训练中的典型故障
BN崩溃：前面提过，batch size太小是主因。另外学习率太大也会导致BN统计量爆炸。建议先用小学习率warmup几个epoch，等loss稳定后再升到正常值。
混淆矩阵总合不唯一：这个问题我遇到过两次。一次是因为评估时用了不同的置信度阈值，导致每轮统计的目标数不一样。另一次是因为数据集中有重复标注，同一个目标被标了两次。检查方法是把评估脚本的阈值固定，然后人工抽查几张图的标注。
loss不下降：先检查数据标注有没有问题，比如类别ID错位、坐标超出0-1范围。然后检查学习率是不是太大或太小。如果用的是预训练权重，确认分类头的类别数和你的数据集一致。
5.2 DETR训练中的典型故障
loss震荡：DETR的匈牙利匹配在训练初期不稳定，loss震荡是正常的。如果震荡幅度太大，可以减小学习率，或者增加warmup epoch。
mAP很低：检查评估时的置信度阈值和NMS参数。DETR不需要NMS，但如果你在评估时加了NMS，反而会降低mAP。另外确认num_classes设置正确，多一个或少一个都会导致评估异常。
显存溢出：DETR的显存占用和object queries数量、特征图尺寸成正比。如果显存不够，减少queries数量或降低输入分辨率。
5.3 部署阶段的通用建议
不管用哪个模型，部署前一定要做端到端的精度验证。训练时的mAP和部署后的实际表现可能有差距，原因包括量化损失、预处理差异、后处理实现不同等。我一般会在部署平台上跑一遍验证集，对比mAP下降幅度，如果超过3个点就需要排查。
另外，边缘部署时要注意内存和功耗限制。RK3588这类芯片虽然NPU算力强，但内存带宽有限，模型太大反而跑不快。YOLOv8n/s是比较稳妥的选择，DETR系列在边缘端目前还不太现实。
6. 选型建议：什么场景用什么模型
如果你要做实时检测，比如视频监控、自动驾驶感知、工业质检，YOLO系列是首选。v8n/s适合边缘设备，v8m/l适合服务器端。训练速度快，部署工具链成熟，社区资源丰富。
如果你对精度要求极高，且可以接受较慢的推理速度，Faster R-CNN仍然值得考虑。特别是在小数据集上，它的迁移学习效果通常比YOLO好，因为RPN提供了更强的先验。
如果你在研究场景，想探索无锚框、端到端检测的新范式，DETR系列是很好的切入点。Deformable DETR在精度和速度上已经比较平衡，适合作为研究基线。但如果你要快速落地一个产品，DETR的工程化成本还是偏高。
最后说一个我自己的体会：不要盲目追新。YOLOv5虽然版本老，但稳定性和社区支持是最好的，很多生产环境还在用。YOLOv8在易用性上提升明显，但某些自定义算子在不同平台上的兼容性还需要验证。选模型的时候，先看你的部署平台支持什么，再看你的精度和速度要求，最后才看论文里的SOTA指标。
