1. 目标检测三大技术路线的整体脉络做目标检测的人早晚都要面对RCNN、YOLO、DETR这三个名字。它们不是三代产品的关系而是三条各走极端的路线RCNN系列代表“两阶段、先粗后精”的经典思路YOLO是“单阶段、一步到位”的极致追求DETR则用Transformer把检测整个重写了一遍。我最早接触目标检测是从Faster RCNN入门的后来被YOLO的实时性带走再后来被DETR的端到端设计惊艳到三条路线走下来各自的门道和坑都踩过不少。先给没接触过目标检测的读者打个底。目标检测要解决的核心问题是“什么东西在哪”也就是同时完成分类和定位。传统方法那套滑动窗口加手工特征效率太低2012年之后深度学习全面接管了这一领域主线任务就是围绕“怎么把候选区域找出来”“怎么把框回归做准”“怎么让速度跑起来”这三个问题展开的。RCNN系列把检测拆成“生成候选框对每个框做分类回归”两步精度高但天然慢YOLO把检测当作回归问题一步搞定牺牲一点精度换来了极致的速度DETR抛弃了所有锚框和候选区域的概念让模型直接从图像集合预测目标集合彻底端到端。这三条路线的适用场景差异很大但彼此之间又互相渗透——现在很多改进工作都是YOLO骨架加Transformer模块或者Faster RCNN框架引入注意力机制所以懂一条路线的底层逻辑再看其他方向会轻松非常多。这篇文章不打算复述论文原文而是从工程落地和训练实战的角度把三条路线的核心原理、训练自己数据集时的关键坑、损失函数的设计逻辑以及部署时需要注意的问题都梳理一遍。无论你是刚入门想选一个方向的初学者还是已经在用某个框架想横向对比选型的工程师这份总结应该都能给你省不少弯路。1.1 为什么目标检测会形成三足鼎立的局面从2014年RCNN提出到2015年YOLO v1横空出世再到2020年DETR登场中间不过六年时间但三条路线的核心矛盾一直是同一个精度和速度的取舍。RCNN系列走的路线是“宁可慢一点也要准”它的两阶段设计让分类和回归都有充足的时间“细看”尤其在检测小目标和密集目标时优势明显。YOLO走的是“快就是王道”直接把图像分成网格每个网格负责预测目标这种设计在实时场景中无可替代。DETR则试图用attention机制彻底替代手工设计的组件让模型自己学会“该看哪里”代价是训练收敛慢、对超参数敏感。三条路线在视觉任务中的地位一直此消彼长。早期COCO榜单上两阶段方法霸榜后来YOLO系列不断优化精度缩小了和两阶段的差距再后来DETR及其变体如Deformable DETR又把精度刷到新高。本质上它们都在解决同一个问题只是解的路径不同。理解这个格局你才能根据项目需求做出合理选型。1.2 三条技术路线的本质区别用最直白的方式概括RCNN系列先找“可能是目标”的区域约2000个候选框然后逐个确认。候选框的质量决定了精度的上限。YOLO系列把全图划分成网格每个网格直接预测目标一步到位。速度极快但在密集小目标场景下容易漏检。DETR用Transformer对整幅图像做全局建模通过可学习的query去“查询”目标再结合二分图匹配直接输出检测结果。把NMS都省掉了真正端到端。这几条路线在训练难度、数据需求、部署成本上的差异非常大。接下来逐个拆解。2. RCNN系列两阶段检测器的起承转合2.1 从RCNN到Faster RCNN的演进逻辑RCNN的思路很朴素先用选择性搜索算法在图像上生成约2000个候选区域把它们一个个裁剪出来缩放到统一尺寸再送入CNN提取特征最后用SVM分类、用回归器修正框。这个方案在当时效果惊艳但致命缺点是慢——一张图要跑2000次CNN前向。Fast RCNN的核心改进是共享卷积特征。整张图只过一次CNN得到特征图每个候选区域通过RoI Pooling在特征图上抠出对应区域再共享后续的分类和回归网络。这样一张图只跑一次CNN速度提升了一个量级。Faster RCNN又往前走了一步把候选区域生成也交给神经网络——这就是Region Proposal NetworkRPN。RPN在特征图的每个位置上生成多种尺度和长宽比的锚框然后判断这些锚框里有没有目标、并调整它们的坐标。至此整个检测流程全部网络化精度和速度都达到了新的平衡点也是我建议初学者第一个深入理解的检测框架。2.2 Faster RCNN训练自己数据的关键细节我自己用Faster RCNN训练过不少自定义数据集踩得最多的是下面几个坑。第一个是锚框尺寸的设置。如果你检测的目标是小的工业零件默认的anchor_size参数一套用上去召回率直接拉胯。正确做法是对训练集的标注框做一次统计分析算出宽高分布的中位数和范围再反推锚框的设计。第二个是多任务损失的平衡问题。Faster RCNN的损失由RPN的分类损失、RPN的回归损失、头部网络的分类损失、回归损失四部分组成。默认的权重都是1但实际训练中回归损失往往比分类损失大很多导致训练不稳定。我的习惯是在配置里给回归损失加一个0.5到0.8的系数让训练更稳。第三个是RoI Pooling的数值精度问题。在需要精确定位小目标的场景比如医疗影像或工业缺陷检测RoI Pooling两次取整损失的信息不容忽视。换成RoIAlign双线性插值能明显改善定位精度这也是Mask RCNN的核心贡献之一。如果你用的框架是基于Faster RCNN的记得检查默认实现是Pooling还是Align。2.3 RCNN系列在2024年的适用场景很多人觉得两阶段检测器过时了这个判断并不准确。虽然YOLO在论文榜单上风头正劲但在实际工程中Faster RCNN依然在不少场景占据一席之地。当你检测的目标尺寸差异极大比如一幅画面里既有几十米远的车辆又有几米近的行人或者遮挡严重导致密集目标之间的边界模糊时两阶段方法的“先粗筛、再精修”策略确实能拿到更好的效果。精度不是唯一考量训练稳定性和可控性也很重要。Faster RCNN的训练比YOLO更“规矩”不会出现BN崩溃、损失爆炸这些让人头疼的问题这对生产环境来说是一个加分项。如果数据量不大几千张Faster RCNN往往比YOLO更容易收敛到可用的水平。3. YOLO系列单阶段检测的统治力3.1 YOLO算法从v1到v8的迭代逻辑YOLOYou Only Look Once的核心思想是“把检测当作回归问题”。YOLO v1把图像划分成SxS网格每个网格负责预测固定数量的边界框和类别概率。这个思路够简单但精度很低——相邻目标无法区分小目标大片漏检。YOLO v2引入了Batch Normalization、锚框和更合理的网络结构DarkNet-19mAP大幅提升。YOLO v3的贡献更深远引入特征金字塔结构在三个不同尺度上做预测让小目标检测能力得到质的飞跃同时网络主体改成DarkNet-53。我当时项目里用v3跑1080P视频流的实时检测效果已经很能打了。YOLO v5没有官方论文但工程化做得极好带来了一个重要的生态变化不再只有模型还有了训练、验证、导出、部署一整套工具链甚至是自动锚框计算、自动学习率调度这些非常工程化的功能。后来YOLOX引入了无锚框解耦检测头和解耦头结构YOLO v7在训练效率和精度上继续打磨YOLO v8则把检测和实例分割统一到了一个框架里成了目前应用最广的版本。3.2 YOLO损失函数详解YOLO的损失函数在目标检测的三大路线中属于最复杂的那类因为所有目标都要在一个损失函数里“算总账”分类损失、定位损失、置信度损失三大块互相影响。分类损失从最初的BCE发展为今天主流的BCE-with-Logits或Focal Loss变体。定位损失经历的路线是从原始的MSE到IoU Loss再到GIoU、DIoU、CIoU的演进。CIoU是实际应用中最常选用的版本因为它不仅考虑重叠区域还考虑中心点距离和长宽比一致性。但如果你的数据里存在极端长宽比的目标比如条形物体、塔吊、车道线CIoU的惩罚项反而会导致训练震荡这时换成EIoU最小化边长差异或SIoU加入角度惩罚可能更合适。置信度损失在单阶段检测器里地位极其特殊。它要区分“这里真的有目标”和“这里只是背景”但在锚框与真实框的匹配策略下大量锚框是负样本损失会严重偏向背景。YOLO的解决方案是只对“与真实框有足够IoU匹配”的锚框计算分类损失和回归损失其余锚框只参与置信度损失这样正负样本的不平衡问题被限制在置信度损失一个维度里。如果你在调整YOLO损失函数时发现训练初期损失下降极快而中后期几乎不动大概率是三个损失之间的平衡没有做好——这个我在第五节还会展开。3.3 YOLO预训练模型下载与训练自己数据的实操要点从实际角度说用YOLO训练自定义数据集的流程已经非常标准化了。用一个实际命令示例来说明以YOLOv8为例pip install ultralytics # 准备YOLO格式数据集 # data.yaml内容示例 # train: /path/to/train/images # val: /path/to/val/images # nc: 2 # names: [cat, dog] # 下载官方预训练权重v8 COCO预训练 yolo detect train datadata.yaml modelyolov8n.pt epochs100 imgsz640 batch16几个关键的默认参数配置直接影响结果imgsz640适合大多数场景但如果你的数据里小目标很多把输入尺寸提高到1280代价是会显著增加推理耗时和显存占用batch的调整取决于显存大小理想情况下GPU利用率应保持在80%以上epochs的设置建议从100起步观察验证集mAP如果还在明显上涨就继续加。训练完以后需要关注几个文件best.pt是验证集上效果最好的权重last.pt是最后一轮的权重前者的泛化性通常更好。若要做推理部署用yolo export导出为ONNX格式实测性能开销很低。关于预训练模型的选择我经常用这样一个策略如果自定义数据的目标类别和COCO有较大重合比如行人、车辆就用YOLOv8 COCO预训练权重在自定义数据上微调收敛速度极快如果数据是完全新奇的类别完全从零训练也不慢但需要更多的epochs并且要把学习率适当调高比如0.01起步否则训练会非常漫长。数据标注的规范性对YOLO影响极大。YOLO格式的坐标是“中心点x、中心点y、宽、高”且全部归一化到[0,1]很多新手把中心点坐标写成“左上角”导致训练结果莫名其妙。另外标注框稍微偏大偏小问题不大但类别标签不能出错否则模型在推理阶段会稳定输出错误分类。3.4 YOLO部署与性能量化分析YOLO的部署问题在真实项目中永远是最关注的部分。以热搜词里的“t4 1080p25帧每秒用TensorRT yolo 640分辨率检测可以支持多少路”来看这个问题非常工程化。我先给一个大概的量化。T4是16GB显存、单卡算力约65TOPSINT8的专业推理卡。以最常被部署的YOLOv8s模型输入分辨率640x640为例FP16精度下单帧推理约2-4ms加上输入图像缩放和NMS等预处理每路25FPS的总开销约15ms单卡可轻松支持5路以上的并发推理如果用异步批处理会更高。如果你要的是10路以上重点不是提高单张推理速度而是引入动态批处理dynamic batching——把多路视频中时间接近的帧拼成一个batch送入GPU这样GPU利用率大幅提升T4上跑到10到12路并不夸张。在实际部署中有两处性能瓶颈常被忽视图像缩放和NMS。之前在一个项目里检测模型推理只要2ms但图像缩放的CPU实现耗时10ms成了整个链路里最慢的一段。解决方案是换成GPU端的cudaResize或者降低预处理分辨率。NMS则建议用TensorRT自带的EfficientNMS插件或者基于CUDA的NMS实现比PyTorch的NMS快一个数量级。4. DETRTransformer如何颠覆检测范式4.1 DETR的核心原理与二分图匹配机制DETRDetection Transformer是2020年Facebook AI提出来的端到端检测方案它的核心思路是把检测完全建模成“集合预测问题”。整体结构分为三部分CNN骨架通常是ResNet负责提取特征Transformer编码器对特征做全局建模解码器通过一组可学习的object queries去查询图像中的目标最终输出固定数量比如100个的预测结果。DETR最颠覆的地方是没有锚框、没有候选区域、没有NMS。它用二分图匹配Hungarian Algorithm在预测结果和真实框之间建立一对一的对应关系直接计算损失。这意味着模型学到的东西是“整体上预测这100个目标哪些该保留、哪些该丢弃”一旦训练收敛输出天然就是稀疏且去重后的结果。这个思路解决了锚框设计中大量超参数调优的问题。但代价是数据需求量大、训练收敛慢——通常需要500个epoch以上才能在COCO上达到与Faster RCNN相当的水平这对工程项目的资源开销是巨大的考验。4.2 DETR训练自己数据的注意事项基于我训练DETR的几次经验这里列一下最容易踩的坑。第一输出数量queries的设定。DETR默认设置100个object queries如果你的单张图中目标数量极少比如只有两三个100个预测中绝大多数会输出“无目标”这会拖慢训练且浪费计算。根据数据集中最多目标数量加一些余量设定即可比如最多出现5个目标就设置20个query。第二学习率的设置。DETR对学习率极其敏感学习率太高会导致早期训练完全无法收敛太低又会让注意力矩阵更新缓慢。默认的1e-4配合AdamW比较安全但需要根据批次大小和数据规模微调。batch size小的时候建议把学习率适当调低避免梯度噪声过大。第三训练轮数。不要指望几百个epoch内收敛到生产可用的精度DETR的维护成本和资源消耗确实高于YOLO。如果你不是实验室环境或者没有足够GPU资源我更建议用Deformable DETR或者Conditional DETR它们收敛速度更快更友好。第四目标尺寸和Transformer的“不耐烦”问题。DETR在处理小目标上表现不佳如果自定义数据中存在大量小目标应该考虑提高输入分辨率如从800变成1000或在特征金字塔结构上增加高分辨率支路。4.3 Transformer与YOLO的合流趋势“yolo和transformer结合”是这两年微热的方向核心思路是保留YOLO的速度框架在具体模块中用注意力机制替换传统卷积。实际热词里提到的“mamba yolo复现”则是把状态空间模型Mamba引入YOLO的一种尝试本质上是探索比Transformer更高效的算子。为什么大家都在做YOLOAttention因为Transformer的全局建模能力对“目标与场景关系”的理解有天然优势比如“车辆在道路上”“人站在车旁边”这类依赖上下文信息的检测注意力机制捕捉得更准确。但直接把整张图丢进Transformer又太重所以轻量方案是只在高层特征或检测头上加几个自注意力模块。我实测过在YOLOv5s的基础上增加一层C3STRTransfomer块做实验推理速度只有轻微下降约10%但在一个光照变化剧烈的数据集上mAP提升了两个多点。这算是一个低成本高回报的改进方向但要注意训练时需要加大数据增强尤其是随机光照、随机遮挡否则注意力模块很容易过拟合。5. 硬核问题排查实录三个典型错误速查5.1 YOLO训练中的BN崩溃问题搜索关键词里出现了“yolo训练中bn崩溃”这是我见过特别多训练事故的诱因之一。所谓BN崩溃具体表现为训练过程中loss突然变成NaN或者换一个batch训练结果差异极大导致模型无法收敛。最典型的原因是batch size过小。Batch Normalization在小batch下对均值和方差的估计非常不稳定——理想情况下BN的mini-batch统计量要接近全局统计量但batch size只有4或8时统计量抖动很大极端情况下方差趋近于零导致梯度爆炸。处理办法有几种按优先级排列尽量把batch size调到16以上如果是显存受限用梯度累积模拟更大的batch关闭BN层的训练更新把track_running_statsFalse改用固定统计量把BN层替换为GroupNorm或LayerNorm在模型初始化后做一次“warmup”预热让BN统计量平稳过渡。5.2 YOLO混淆矩阵总和不为1“yolo混淆矩阵总合不唯一”这个问题会吓到不少新手。实际上这是正常的——混淆矩阵的行代表“真实类别”列代表“预测类别”对角线是预测正确的数量。当目标检测的真实框和预测框数量不同时比如一个真实框被漏检一个目标被重复预测后NMS没有完全消除非对角线上的计数并不会自动补齐矩阵行和自然不等于1。需要关注的指标是每一类的Recall和Precision以及整体mAP。如果某个类别的精确率和召回率差异过大比如精确率高但召回率低说明模型对这个类别的定位能力还行但是漏检严重应当补充更多该类别目标的数据或者调整置信度阈值。5.3 Faster RCNN系列训练收敛慢的排查相比YOLOFaster RCNN训练踩坑的体验大多是“收敛慢”而不是“直接崩溃”。最常遇到的状况是训练了十几个epoch后验证集mAP几乎不动但训练损失已经降得很低了。此时优先怀疑是否“在过拟合小数据集”或者“特征提取能力不足”。第一步看训练集与验证集的数据分布是否一致。比如训练集中全是白天场景验证集中大量出现夜间数据那模型自然学不到域不变的鲁棒特征。第二步检查RPN训练是否正常。Faster RCNN中RPN的收敛是头网络收敛的前提如果RPN损失长时间不减可以尝试增大RPN训练的batch大小或者调整正负样本采样比例。第三步用可视化工具检查特征图和候选框分布。我在项目中用TensorBoard展示RPN生成的候选框如果发现候选框全部集中在图像边缘、或全部是相似尺度说明锚框设置与数据分布不匹配。6. 三条技术路线怎么选从实际项目需求出发现在项目选型的时候我会先问三个问题你的场景是实时还是离线数据量有多大目标大小和密度如何做实时视频流分析比如工地安全帽检测、城市交通监控首选YOLO系列这是它的绝对主场。做离线高清分析比如卫星图像目标检测、医学影像辅助诊断Faster RCNN可能更合适。数据量极大、算力充足、追求极致精度上限可以考虑Deformable DETR或其变体。还有一个常被忽略的维度团队的维护能力和生态成熟度。YOLO的生态最完整从标注格式、训练到导出PB/ONNX/TensorRT的流程已经高度标准化一个初级工程师按文档十几天就能跑通全流程。Faster RCNN在学术社区拥有深厚积累各种变体多如牛毛遇到问题很容易找到答案。DETR因为训练难度高、调试成本大更适合有扎实深度学习功底的团队。根据我个人经验如果是中小型团队从零启动一个视觉项目YOLO几乎永远是最稳妥的第一选择等后续精度收益不足时再去尝试更复杂的框架。7. 最后分享几个容易踩的通用细节这些细节无论你选用哪条技术路线都会遇到。第一训练集图像分辨率不要五花八门。YOLO训练时会统一缩放但分辨率差距太大时缩放到相同尺寸后长宽比畸变也会影响模型性能。尽量统一输入尺寸或保持相近的比例。第二训练过程中的随机种子记得固定。深度学习训练有大量随机性固定随机种子虽然不能保证完全复现但至少能在参数调优时让变量间差异不受随机因素污染。第三数据增强幅度要合理。在较小的数据集上激进的增强策略比如大规模MixUp往往会掩盖特征本身的辨识度导致验证集指标虚高、真实场景泛化差。先跑baseline再逐步增加增强强度。我在实际工作中一直信奉一个原则先有一个能稳定复现的baseline再谈优化。无论你选择的是RCNN、YOLO还是DETR先把官方的预训练模型在标准数据集上跑通再迁移到自己的数据上这个节奏始终不会错。