1. 三大目标检测框架的演进脉络与选型逻辑目标检测这个方向从2014年RCNN横空出世到现在十年时间里经历了从两阶段到单阶段、从CNN到Transformer、从学术benchmark到边缘端落地的完整演化。RCNN、DETR、YOLO这三条技术路线基本代表了三种截然不同的解题哲学。我这些年在这三个框架上都做过项目从最早的Faster RCNN训练电力红外数据集到后来用DETR做小样本检测再到现在主力用YOLOv8做边缘部署踩过的坑和积累的经验足够写一本小册子。先说清楚这三者各自解决什么问题。RCNN系列的核心思路是“先找候选区域再分类回归”精度高但速度慢适合对实时性要求不高的离线分析场景。DETR把检测问题直接建模成集合预测问题用Transformer的注意力机制端到端出结果省掉了锚框和NMS后处理但收敛慢、小目标效果一般。YOLO则是“一眼看全图”单阶段直接回归边界框和类别速度极快从v1到v8再到v10工程化程度越来越高是目前工业部署的主力选择。选哪个框架本质上是在精度、速度、部署成本、数据量这四个维度上做权衡。我见过太多人一上来就问“哪个最好”这个问题没有标准答案。你手头只有几百张标注图DETR的收敛特性会让你怀疑人生你要在RK3588上跑实时检测Faster RCNN的推理速度根本扛不住你要做视频流里的密集小目标检测YOLO的anchor设计又需要仔细调。所以这篇内容我会把三条路线的核心原理、训练细节、部署要点都拆开讲结合我自己在电力红外、火灾监控、手势识别这些场景里的实际经验给出一套可复现的选型和实操方案。2. RCNN系列从候选区域到端到端的两阶段检测2.1 RCNN到Faster RCNN的核心演进逻辑RCNN的原始版本思路非常直接用Selective Search在每张图上生成约2000个候选区域把每个区域缩放到固定尺寸送进CNN提取特征再用SVM分类最后用回归器修正边界框。这个流程在2014年确实惊艳但问题也很明显——2000个区域意味着2000次CNN前向传播一张图推理要几十秒训练更是要分四步走工程上几乎不可用。Fast RCNN做了关键改进整张图先过一次CNN得到特征图然后把候选区域映射到特征图上做ROI Pooling这样CNN只跑一次。但候选区域的生成还是依赖Selective Search这个环节在CPU上跑成了新的速度瓶颈。Faster RCNN的突破在于引入了RPNRegion Proposal Network用神经网络来生成候选区域整个检测流程终于可以端到端训练了。RPN的本质是在特征图的每个位置上预设一组锚框然后预测每个锚框是前景还是背景以及相对于真实框的偏移量。这里有个关键参数需要理解锚框的尺度和长宽比。在Faster RCNN的原始实现中每个位置预设9个锚框3种尺度×3种长宽比这个设计对最终精度影响很大。我在电力红外数据集上训练时因为目标大多是细长的绝缘子和均压环把长宽比调整为[0.2, 0.5, 1.0, 2.0, 5.0]之后召回率提升了将近8个百分点。2.2 Faster RCNN训练自己数据集的完整流程训练自己的数据集第一步永远是数据格式转换。Faster RCNN的标准输入是VOC格式的XML标注或COCO格式的JSON。如果你手头是YOLO格式的txt标注需要先转成VOC。转换脚本的核心逻辑是读取每张图的txt文件把归一化的中心点坐标和宽高还原成绝对坐标再写入XML。这里有个容易忽略的细节YOLO格式的坐标是归一化到0-1的转换时一定要乘以原图的宽高否则框会全部挤在左上角。环境配置方面我推荐用PyTorch版本的Faster RCNN实现torchvision里自带预训练模型省去了很多麻烦。但要注意torchvision的版本和PyTorch版本的对应关系我遇到过torchvision 0.15配PyTorch 1.13时ROI Align的CUDA核编译失败的问题换成0.14就正常了。如果要用mmdetection配置文件的继承机制需要花点时间理解但灵活度更高适合做模型改进。训练参数上学习率是最关键的。Faster RCNN对学习率非常敏感太大直接梯度爆炸太小收敛慢到怀疑人生。我的经验是如果batch size是2单卡V100通常只能开到2初始学习率设在0.001到0.002之间用SGD优化器momentum 0.9weight decay 0.0005。前500个iteration用warmup把学习率从0.0001线性升到初始值之后每3个epoch降一次降幅0.1。这个配置在电力红外数据集上大概120个epoch收敛mAP能到0.72左右。数据增强方面Faster RCNN对水平翻转、随机裁剪、颜色抖动都比较鲁棒但要注意翻转时标注框的坐标也要同步翻转。我一般用albumentations库来做增强它的BboxParams能自动处理坐标变换比手写靠谱得多。另外如果数据集里小目标多建议把输入分辨率调到800×1333这是Faster RCNN的默认设置再大显存扛不住再小小目标特征会丢失。2.3 Faster RCNN的调参经验与常见崩溃场景训练Faster RCNN最常遇到的问题就是loss不下降或者震荡。我排查过很多次总结下来无非几个原因学习率太大、正负样本比例失衡、锚框尺寸和数据集不匹配。正负样本比例这块Faster RCNN默认采样256个ROI正负比例1:3但如果你的数据集里目标特别密集正样本会远超这个比例这时候需要调整sampler的参数否则模型会偏向预测背景。另一个高频问题是BN层崩溃。Faster RCNN的backbone通常是ResNet50里面有很多BN层。当batch size太小比如单卡只能开2时BN的统计量估计不准训练后期loss会突然变成NaN。解决办法有两个一是冻结BN层用预训练模型的统计量二是换成GroupNorm。我一般选前者因为冻结BN对精度影响很小但训练稳定性提升明显。还有一个坑是显存溢出。Faster RCNN的显存占用和输入分辨率、ROI数量都相关。如果遇到OOM先把输入短边从800降到600再把RPN的post_nms_top_n从2000降到1000通常能省下2-3GB显存。如果还不够就只能减小batch size或者换更小的backbone了。3. DETRTransformer在目标检测上的端到端尝试3.1 DETR论文的核心思想与架构拆解DETRDEtection TRansformer是2020年Facebook AI提出的它的核心贡献是把目标检测变成了一个直接的集合预测问题。传统检测器需要锚框、需要NMS后处理DETR把这些全部去掉了。它的流程是CNN backbone提取特征展平后加上位置编码送进Transformer编码器再用一组固定的可学习query通过解码器输出N个预测框最后用匈牙利算法做二分匹配计算loss。这个设计最优雅的地方在于它真正实现了端到端。你不需要调锚框尺寸不需要设NMS阈值模型直接输出最终的检测结果。但优雅的代价是收敛极慢。DETR论文里提到需要500个epoch才能收敛而Faster RCNN通常几十个epoch就够了。原因在于匈牙利匹配在训练初期非常不稳定每个query对应的目标一直在变模型很难学到稳定的特征。DETR的另一个问题是小目标检测效果差。因为Transformer的注意力是全局的高分辨率特征图上的小目标经过编码器后特征会被稀释。论文里的解决方案是在backbone后面加一个空洞卷积模块把特征图分辨率提上去但这又增加了计算量。后来Deformable DETR通过可变形注意力机制只关注参考点周围的稀疏采样点既提升了小目标效果又把收敛速度拉到了50个epoch左右。3.2 DETR训练自己数据的实操要点用DETR训练自己的数据数据格式必须是COCO格式的JSON。如果你手头是VOC的XML需要先转成COCO。转换时要注意COCO的category_id必须从1开始0是背景这个和VOC不一样。另外COCO的bbox格式是[x_min, y_min, width, height]不是[x_min, y_min, x_max, y_max]转换时别搞错了。环境配置上DETR的官方实现依赖比较重需要PyTorch 1.5以上、torchvision 0.6以上还要装pycocotools。我建议用conda建一个独立环境因为DETR对CUDA版本也有要求和YOLO的环境经常冲突。如果要用Deformable DETR还需要编译CUDA算子这一步在Windows上特别容易失败建议直接在Linux下搞。训练参数方面DETR的初始学习率非常小backbone是1e-5Transformer部分是1e-4这是为了适配Transformer的训练特性。优化器用AdamWweight decay设1e-4。学习率调度用step decay在第200个epoch降一次。batch size尽量大因为匈牙利匹配是全局的batch size太小匹配会很不稳定。我试过batch size 2训练loss震荡得根本没法看换成8之后才正常。还有一个关键点是数据增强。DETR对数据增强很敏感官方的增强策略包括随机水平翻转、随机缩放裁剪、颜色抖动。但要注意DETR的缩放裁剪是同时作用于图像和标注的而且裁剪后的图像要保证至少有一个完整的目标否则这个样本的匹配会出问题。我一般用官方提供的RandomHorizontalFlip和RandomResizeCrop参数用默认的就行。3.3 DETR的收敛问题与改进方向DETR收敛慢的根本原因在于匈牙利匹配的稳定性。训练初期query和目标的匹配关系一直在变导致梯度方向不一致。改进思路主要有两个方向一是引入先验知识比如Deformable DETR用参考点初始化query让每个query从一开始就关注某个区域二是改进匹配策略比如DN-DETR引入去噪训练给query加上噪声让模型学会恢复真实框。另一个改进方向是和多模态结合。最近有个热词叫“yolo图文多模态”其实DETR在这方面更有优势因为Transformer天然适合处理多模态输入。我试过把CLIP的文本特征和DETR的视觉特征做交叉注意力在开放词汇检测上效果不错但训练成本很高需要多卡A100才能跑起来。如果你只是想用DETR做常规检测我的建议是直接用Deformable DETR或者DINO收敛速度和精度都比原版DETR好很多。DINO在COCO上12个epoch就能达到49.4 mAP这个水平已经和Faster RCNN打平了而且端到端的流程更干净。4. YOLO系列从v1到v8的工程化落地之路4.1 YOLO的核心设计哲学与版本演进YOLOYou Only Look Once的核心思想是把检测问题当成回归问题一张图只过一次网络直接输出所有目标的边界框和类别。这个设计让YOLO的速度远超两阶段检测器v1版本在Titan X上能跑到45 FPS而Faster RCNN只有5 FPS。但v1的精度不行尤其是小目标和密集场景漏检很严重。v2引入了Anchor Box和Batch Normalization精度大幅提升同时提出了Darknet-19 backbone。v3是YOLO的巅峰之作引入了FPN结构做多尺度预测backbone换成Darknet-53在COCO上mAP达到33.0速度还有30 FPS。v4和v5主要是工程优化v4引入了CSPDarknet53、Mish激活、CIoU Loss等trickv5则是Ultralytics做的工程化封装提供了极其方便的API和部署工具。v6和v7是美团和AlexeyAB的版本v8是Ultralytics的集大成之作支持分类、检测、分割、姿态估计多个任务而且提供了从训练到部署的全套工具链。现在最新的v10在v8基础上做了进一步优化主要是去掉了NMS但工程成熟度还不如v8。我目前主力用v8因为它的生态最完善遇到问题容易找到解决方案。4.2 YOLOv8环境搭建与训练自己数据集的完整步骤YOLOv8的环境搭建非常简单官方提供了pip安装方式。但要注意ultralytics包会自动安装PyTorch如果你的机器上已经有特定版本的PyTorch可能会被覆盖。我建议先手动装好PyTorch和CUDA再用pip install ultralytics --no-deps然后手动装依赖。训练自己的数据集第一步是准备YOLO格式的标注。每张图对应一个txt文件每行格式是class_id x_center y_center width height坐标都是归一化到0-1的。如果你用labelImg标注导出时选YOLO格式就行。数据集目录结构要按官方要求来datasets目录下建images和labels两个文件夹各自再分train和val子文件夹。配置文件方面需要建一个data.yaml里面指定train、val、test的路径以及nc类别数和names类别名称列表。这个文件路径一定要用绝对路径相对路径经常出问题。模型配置文件可以用官方的yolov8n.yaml、yolov8s.yaml等n是最小的s是smallm是mediuml是largex是extra large。如果要做实例分割用yolov8n-seg.yaml。训练命令很简单yolo train datadata.yaml modelyolov8n.pt epochs100 imgsz640 batch16。但这里有几个参数需要根据实际情况调整。imgsz是输入分辨率640是默认值如果小目标多可以调到1280但显存占用会翻倍。batch根据显存来V100 32G可以开到64消费级显卡8G只能开到8。epochs一般100到300如果数据集小可以少一点但要注意早停。4.3 YOLO损失函数与训练中的BN崩溃问题YOLOv8的损失函数由三部分组成分类损失、回归损失、DFL损失。分类损失用的是BCEWithLogitsLoss回归损失用的是CIoU LossDFL是Distribution Focal Loss用来学习边界框的离散分布。这三个损失的权重在代码里是硬编码的box7.5cls0.5dfl1.5。如果你要改需要修改ultralytics/utils/loss.py里的对应参数。训练中最常见的问题是BN崩溃表现为loss突然变成NaN或者mAP骤降到0。原因通常是batch size太小BN的统计量估计不准。YOLOv8默认在训练时冻结BN的running mean和var用预训练模型的统计量这个策略在大多数情况下是有效的。但如果你的数据集和预训练数据分布差异很大冻结BN反而会限制精度。这时候可以解冻BN但要把batch size调到至少16否则崩溃概率很高。另一个高频问题是“yolo混淆矩阵总合不唯一”。这个问题的本质是验证时同一张图被多次统计。YOLOv8在验证时会做数据增强如果开启了TTATest Time Augmentation同一张图会被推理多次混淆矩阵就会重复累加。解决办法是在验证时关掉TTA或者用val.py单独跑验证不要用train.py里的验证。4.4 YOLO边缘部署与RK3588实战经验YOLO在边缘端的部署目前最火的平台是RK3588。这块芯片有6TOPS的NPU算力跑YOLOv8n能到30FPS以上功耗还低。但部署流程比较繁琐需要把PyTorch模型转成ONNX再转成RKNN格式。转换过程中有几个坑一是ONNX的opset版本要和RKNN工具链匹配我一般用opset 12二是输入尺寸必须是32的倍数640×640没问题但608×608就会报错三是后处理里的NMS最好放到CPU上做NPU对NMS的支持不太好。部署到RK3588之后最常见的问题是误检率高。我排查过很多次原因主要有三个一是量化精度损失INT8量化后小目标的特征会丢失解决办法是用混合量化对敏感层保持FP16二是输入预处理不一致训练时用的归一化参数和部署时不一致这个一定要对齐三是后处理阈值没调好conf_thres和iou_thres需要根据实际场景调我一般从0.25和0.45开始试。如果要在树莓派上跑YOLO建议用YOLOv8n或者YOLOv5n用NCNN推理框架速度能到5-10FPS。但树莓派的CPU性能有限输入分辨率要降到320否则帧率会掉到1以下。另外树莓派的散热是个问题长时间跑会降频最好加个风扇。5. 三大框架的横向对比与选型决策表5.1 精度、速度、数据需求的多维度对比维度Faster RCNNDETR (Deformable)YOLOv8COCO mAP42.046.253.9推理速度 (V100)5 FPS15 FPS80 FPS训练收敛epoch50-10050100-300最小数据量500张1000张200张小目标效果好一般好部署难度中高低端到端否是否边缘端支持差差好这张表是我根据实际项目经验整理的数据可能和论文有出入但趋势是对的。Faster RCNN的精度在早期是标杆但现在已经被YOLOv8和Deformable DETR超越了。DETR的优势在于端到端和Transformer的扩展性但部署难度确实高。YOLOv8在精度、速度、部署便利性上取得了最好的平衡这也是它成为工业界首选的原因。5.2 不同场景下的选型建议如果你做的是离线分析比如电力巡检的红外图像检测对速度没要求但要求高召回率Faster RCNN或者Deformable DETR都可以。我做过一个电力红外数据集的项目用Faster RCNN训练mAP 0.72召回率0.85满足业务需求。但如果要实时监控比如火灾实时监控手机摄像头那必须用YOLO而且要用nano版本否则手机端跑不动。如果你做的是小样本检测比如只有几十张标注图那三个框架都不太适合直接训练。我的建议是用预训练模型做微调YOLOv8的预训练模型下载很方便官方提供了在COCO上预训练的权重微调时冻结backbone只训练head效果通常不错。DETR的预训练模型也有但微调时需要更大的学习率和更长的训练时间。如果你要做多模态检测比如图文多模态目标检测DETR是更好的选择因为Transformer天然支持多模态输入。我试过用CLIPDETR做开放词汇检测虽然训练成本高但效果确实好。YOLO在这方面也有尝试比如YOLO-World但成熟度还不如DETR系列。5.3 模型改进与前沿方向YOLO的改进方向很多常见的有换backbone比如用MobileNet、EfficientNet、加注意力机制SE、CBAM、改损失函数Focal Loss、GHM、加辅助训练头。我试过在YOLOv8里加CBAM注意力mAP提升了1.2个点但推理速度降了15%性价比一般。最近有个热词叫“mamba yolo复现”Mamba是状态空间模型比Transformer的复杂度低适合长序列建模但在检测任务上的效果还有待验证。DETR的改进方向主要是收敛速度和中小目标。Deformable DETR、DAB-DETR、DN-DETR、DINO这几个工作把DETR的收敛速度从500 epoch拉到了12 epoch精度也超过了Faster RCNN。如果你要用DETR我建议直接从DINO开始它是目前DETR系列里综合表现最好的。YOLO和Transformer的结合也是一个热点。我试过把YOLOv8的backbone换成ViT但效果不如CNN因为ViT需要大量数据预训练在小数据集上容易过拟合。更好的方式是在neck部分加Transformer模块比如用Transformer Encoder替换PANet这样既能利用Transformer的全局建模能力又不会破坏CNN的局部特征提取。6. 实操中的高频问题与排查技巧实录6.1 训练不收敛的排查思路训练不收敛是最高频的问题我总结了一套排查流程。第一步看loss曲线如果loss从一开始就震荡得厉害大概率是学习率太大先把学习率降10倍试试。第二步看数据用可视化工具把标注框画到图上确认标注没问题。我遇到过标注文件里坐标是归一化的但没乘宽高导致所有框都在左上角模型根本学不到东西。第三步看预训练权重如果是从头训练收敛慢是正常的加载预训练权重能快很多。如果loss下降但mAP不涨那可能是过拟合了。解决办法是加数据增强、加正则化、减小模型复杂度。我遇到过训练集mAP 0.9但验证集只有0.3的情况后来发现是数据集划分有问题训练集和验证集有重叠。重新划分之后验证集mAP到了0.65。6.2 部署时的精度损失与对齐技巧训练时mAP 0.8部署后掉到0.5这种精度损失在边缘部署中很常见。原因通常是量化损失、预处理不一致、后处理差异。量化损失可以通过混合量化缓解把敏感层保持FP16。预处理不一致需要仔细核对训练和部署时的归一化参数、通道顺序、输入尺寸。后处理差异主要是NMS的阈值和实现方式训练时用的NMS和部署时的NMS要一致。我一般会在部署前做一个对齐测试用同一张图分别在PyTorch和部署框架上推理对比输出的边界框和置信度。如果差异超过5%就要逐层排查。常见的问题是部署框架的resize方式和PyTorch不一致PyTorch默认是bilinear有些部署框架默认是nearest这个一定要对齐。6.3 数据集构建的避坑指南数据集的质量直接决定模型的上限。我踩过的坑包括类别不平衡、标注不一致、背景样本过多。类别不平衡的解决办法是过采样少数类或者用Focal Loss。标注不一致需要制定详细的标注规范比如边界框要贴紧目标边缘遮挡目标怎么标这些都要提前定义好。背景样本过多会导致误检率高解决办法是控制背景图的比例一般不超过总数据的10%。还有一个容易被忽略的点是数据集划分。训练集、验证集、测试集要按场景划分不能随机划分。比如你做校园检测如果随机划分同一场景的图可能同时出现在训练集和验证集验证集mAP会虚高。正确的做法是按场景划分比如用A教学楼的图做训练B教学楼的图做验证这样验证集mAP才能反映真实泛化能力。6.4 常见问题速查表问题现象可能原因排查方法解决方案loss变NaN学习率太大/BN崩溃检查学习率、冻结BN降学习率、冻结BNmAP不涨过拟合/数据问题看训练验证曲线加增强、重新划分数据部署后精度掉量化损失/预处理不一致对齐测试混合量化、对齐预处理误检率高背景样本多/阈值低看混淆矩阵控制背景比例、调阈值小目标漏检输入分辨率低/特征丢失可视化特征图提高分辨率、加FPN训练速度慢batch size小/数据加载慢看GPU利用率加num_workers、用缓存这张表是我这些年排查问题的经验总结基本上覆盖了80%的常见问题。遇到新问题的时候我一般先看loss曲线再看数据可视化最后看部署对齐这个顺序能解决大部分问题。7. 从训练到部署的完整项目实战建议7.1 项目启动前的技术选型清单在启动一个检测项目之前我一般会先问几个问题数据量有多少标注质量怎么样推理硬件是什么实时性要求多高精度要求多高这几个问题的答案基本决定了技术选型。数据量少于500张优先考虑YOLOv8微调数据量在1000-5000张三个框架都可以看部署需求数据量超过10000张可以考虑从头训练或者用DETR做端到端。硬件方面如果部署在服务器GPU上三个框架都可以如果部署在边缘设备上YOLO是唯一选择如果部署在手机端YOLOv8n或者YOLOv5n是首选。实时性要求30FPS以上必须用YOLO要求10FPS左右Deformable DETR也可以要求5FPS以下Faster RCNN也能接受。7.2 训练过程中的监控与调优策略训练过程中我一般会监控几个指标loss曲线、mAP曲线、学习率曲线、GPU利用率。loss曲线看收敛情况mAP曲线看泛化能力学习率曲线确认调度策略生效GPU利用率看数据加载有没有瓶颈。如果GPU利用率低于50%说明数据加载是瓶颈需要加num_workers或者用更快的存储。调优策略上我一般先调学习率和batch size这两个对结果影响最大。学习率用LR Finder找最优值batch size在显存允许范围内尽量大。然后调数据增强增强太弱会过拟合太强会欠拟合需要根据验证集mAP来平衡。最后调模型结构比如换backbone、加注意力、改损失函数这些改动对精度的影响通常在1-3个点。7.3 部署上线的检查清单部署上线前我一般会做以下检查模型输入输出对齐、预处理对齐、后处理对齐、性能测试、稳定性测试。输入输出对齐是确认部署模型的输入尺寸、通道顺序、归一化参数和训练时一致。预处理对齐是确认resize、padding的方式一致。后处理对齐是确认NMS的阈值和实现一致。性能测试是测推理速度、显存占用、CPU占用。稳定性测试是连续跑24小时看有没有内存泄漏或者崩溃。还有一个容易忽略的点是版本管理。训练用的PyTorch版本、CUDA版本、部署框架版本都要记录清楚否则后面复现或者升级的时候会很麻烦。我一般用conda env export导出环境用git管理代码用DVC管理数据集和模型权重。7.4 持续迭代与模型更新的经验模型上线不是终点而是起点。实际场景中的数据分布会随着时间变化模型精度会逐渐下降。我一般会定期收集线上数据人工标注后加入训练集做增量训练。增量训练时要注意新数据要和旧数据混合不能只用新数据否则会灾难性遗忘。混合比例一般是新数据占30%-50%旧数据占50%-70%。模型更新时我一般会做A/B测试新模型和旧模型同时跑一段时间对比精度和速度。如果新模型精度提升但速度下降太多需要权衡是否值得。如果新模型精度下降需要排查是数据问题还是训练问题。我遇到过新模型在验证集上精度更高但线上效果更差的情况后来发现是验证集和线上数据分布不一致重新划分验证集之后问题解决了。7.5 给不同阶段从业者的学习路径建议如果你是刚入门的新手我建议从YOLOv8开始因为它的文档最完善社区最活跃遇到问题容易找到答案。先跑通官方示例再训练自己的数据集最后尝试部署到边缘设备。这个过程大概需要1-2个月。如果你已经有一定基础想深入理解检测原理我建议读三篇论文Faster RCNN、DETR、YOLOv3。这三篇分别代表了两阶段、Transformer、单阶段三种范式读完基本能建立完整的知识体系。然后可以尝试复现一些改进工作比如Deformable DETR、YOLOv8的注意力改进等。如果你要做工程落地我建议重点学习部署相关的技能ONNX导出、TensorRT加速、RKNN转换、NCNN推理。这些技能在实际项目中比调参更重要。我见过很多模型在PyTorch上精度很高但部署后完全不能用就是因为部署环节没做好。最后分享一个我个人的习惯每次做完一个项目我都会把踩过的坑和解决方案整理成文档下次遇到类似问题直接查文档效率高很多。这个习惯坚持了几年现在我的排查文档已经有上百页了基本上覆盖了目标检测项目从训练到部署的所有常见问题。
1. 三大目标检测框架的演进脉络与选型逻辑目标检测这个方向从2014年RCNN横空出世到现在十年时间里经历了从两阶段到单阶段、从CNN到Transformer、从学术benchmark到边缘端落地的完整演化。RCNN、DETR、YOLO这三条技术路线基本代表了三种截然不同的解题哲学。我这些年在这三个框架上都做过项目从最早的Faster RCNN训练电力红外数据集到后来用DETR做小样本检测再到现在主力用YOLOv8做边缘部署踩过的坑和积累的经验足够写一本小册子。先说清楚这三者各自解决什么问题。RCNN系列的核心思路是“先找候选区域再分类回归”精度高但速度慢适合对实时性要求不高的离线分析场景。DETR把检测问题直接建模成集合预测问题用Transformer的注意力机制端到端出结果省掉了锚框和NMS后处理但收敛慢、小目标效果一般。YOLO则是“一眼看全图”单阶段直接回归边界框和类别速度极快从v1到v8再到v10工程化程度越来越高是目前工业部署的主力选择。选哪个框架本质上是在精度、速度、部署成本、数据量这四个维度上做权衡。我见过太多人一上来就问“哪个最好”这个问题没有标准答案。你手头只有几百张标注图DETR的收敛特性会让你怀疑人生你要在RK3588上跑实时检测Faster RCNN的推理速度根本扛不住你要做视频流里的密集小目标检测YOLO的anchor设计又需要仔细调。所以这篇内容我会把三条路线的核心原理、训练细节、部署要点都拆开讲结合我自己在电力红外、火灾监控、手势识别这些场景里的实际经验给出一套可复现的选型和实操方案。2. RCNN系列从候选区域到端到端的两阶段检测2.1 RCNN到Faster RCNN的核心演进逻辑RCNN的原始版本思路非常直接用Selective Search在每张图上生成约2000个候选区域把每个区域缩放到固定尺寸送进CNN提取特征再用SVM分类最后用回归器修正边界框。这个流程在2014年确实惊艳但问题也很明显——2000个区域意味着2000次CNN前向传播一张图推理要几十秒训练更是要分四步走工程上几乎不可用。Fast RCNN做了关键改进整张图先过一次CNN得到特征图然后把候选区域映射到特征图上做ROI Pooling这样CNN只跑一次。但候选区域的生成还是依赖Selective Search这个环节在CPU上跑成了新的速度瓶颈。Faster RCNN的突破在于引入了RPNRegion Proposal Network用神经网络来生成候选区域整个检测流程终于可以端到端训练了。RPN的本质是在特征图的每个位置上预设一组锚框然后预测每个锚框是前景还是背景以及相对于真实框的偏移量。这里有个关键参数需要理解锚框的尺度和长宽比。在Faster RCNN的原始实现中每个位置预设9个锚框3种尺度×3种长宽比这个设计对最终精度影响很大。我在电力红外数据集上训练时因为目标大多是细长的绝缘子和均压环把长宽比调整为[0.2, 0.5, 1.0, 2.0, 5.0]之后召回率提升了将近8个百分点。2.2 Faster RCNN训练自己数据集的完整流程训练自己的数据集第一步永远是数据格式转换。Faster RCNN的标准输入是VOC格式的XML标注或COCO格式的JSON。如果你手头是YOLO格式的txt标注需要先转成VOC。转换脚本的核心逻辑是读取每张图的txt文件把归一化的中心点坐标和宽高还原成绝对坐标再写入XML。这里有个容易忽略的细节YOLO格式的坐标是归一化到0-1的转换时一定要乘以原图的宽高否则框会全部挤在左上角。环境配置方面我推荐用PyTorch版本的Faster RCNN实现torchvision里自带预训练模型省去了很多麻烦。但要注意torchvision的版本和PyTorch版本的对应关系我遇到过torchvision 0.15配PyTorch 1.13时ROI Align的CUDA核编译失败的问题换成0.14就正常了。如果要用mmdetection配置文件的继承机制需要花点时间理解但灵活度更高适合做模型改进。训练参数上学习率是最关键的。Faster RCNN对学习率非常敏感太大直接梯度爆炸太小收敛慢到怀疑人生。我的经验是如果batch size是2单卡V100通常只能开到2初始学习率设在0.001到0.002之间用SGD优化器momentum 0.9weight decay 0.0005。前500个iteration用warmup把学习率从0.0001线性升到初始值之后每3个epoch降一次降幅0.1。这个配置在电力红外数据集上大概120个epoch收敛mAP能到0.72左右。数据增强方面Faster RCNN对水平翻转、随机裁剪、颜色抖动都比较鲁棒但要注意翻转时标注框的坐标也要同步翻转。我一般用albumentations库来做增强它的BboxParams能自动处理坐标变换比手写靠谱得多。另外如果数据集里小目标多建议把输入分辨率调到800×1333这是Faster RCNN的默认设置再大显存扛不住再小小目标特征会丢失。2.3 Faster RCNN的调参经验与常见崩溃场景训练Faster RCNN最常遇到的问题就是loss不下降或者震荡。我排查过很多次总结下来无非几个原因学习率太大、正负样本比例失衡、锚框尺寸和数据集不匹配。正负样本比例这块Faster RCNN默认采样256个ROI正负比例1:3但如果你的数据集里目标特别密集正样本会远超这个比例这时候需要调整sampler的参数否则模型会偏向预测背景。另一个高频问题是BN层崩溃。Faster RCNN的backbone通常是ResNet50里面有很多BN层。当batch size太小比如单卡只能开2时BN的统计量估计不准训练后期loss会突然变成NaN。解决办法有两个一是冻结BN层用预训练模型的统计量二是换成GroupNorm。我一般选前者因为冻结BN对精度影响很小但训练稳定性提升明显。还有一个坑是显存溢出。Faster RCNN的显存占用和输入分辨率、ROI数量都相关。如果遇到OOM先把输入短边从800降到600再把RPN的post_nms_top_n从2000降到1000通常能省下2-3GB显存。如果还不够就只能减小batch size或者换更小的backbone了。3. DETRTransformer在目标检测上的端到端尝试3.1 DETR论文的核心思想与架构拆解DETRDEtection TRansformer是2020年Facebook AI提出的它的核心贡献是把目标检测变成了一个直接的集合预测问题。传统检测器需要锚框、需要NMS后处理DETR把这些全部去掉了。它的流程是CNN backbone提取特征展平后加上位置编码送进Transformer编码器再用一组固定的可学习query通过解码器输出N个预测框最后用匈牙利算法做二分匹配计算loss。这个设计最优雅的地方在于它真正实现了端到端。你不需要调锚框尺寸不需要设NMS阈值模型直接输出最终的检测结果。但优雅的代价是收敛极慢。DETR论文里提到需要500个epoch才能收敛而Faster RCNN通常几十个epoch就够了。原因在于匈牙利匹配在训练初期非常不稳定每个query对应的目标一直在变模型很难学到稳定的特征。DETR的另一个问题是小目标检测效果差。因为Transformer的注意力是全局的高分辨率特征图上的小目标经过编码器后特征会被稀释。论文里的解决方案是在backbone后面加一个空洞卷积模块把特征图分辨率提上去但这又增加了计算量。后来Deformable DETR通过可变形注意力机制只关注参考点周围的稀疏采样点既提升了小目标效果又把收敛速度拉到了50个epoch左右。3.2 DETR训练自己数据的实操要点用DETR训练自己的数据数据格式必须是COCO格式的JSON。如果你手头是VOC的XML需要先转成COCO。转换时要注意COCO的category_id必须从1开始0是背景这个和VOC不一样。另外COCO的bbox格式是[x_min, y_min, width, height]不是[x_min, y_min, x_max, y_max]转换时别搞错了。环境配置上DETR的官方实现依赖比较重需要PyTorch 1.5以上、torchvision 0.6以上还要装pycocotools。我建议用conda建一个独立环境因为DETR对CUDA版本也有要求和YOLO的环境经常冲突。如果要用Deformable DETR还需要编译CUDA算子这一步在Windows上特别容易失败建议直接在Linux下搞。训练参数方面DETR的初始学习率非常小backbone是1e-5Transformer部分是1e-4这是为了适配Transformer的训练特性。优化器用AdamWweight decay设1e-4。学习率调度用step decay在第200个epoch降一次。batch size尽量大因为匈牙利匹配是全局的batch size太小匹配会很不稳定。我试过batch size 2训练loss震荡得根本没法看换成8之后才正常。还有一个关键点是数据增强。DETR对数据增强很敏感官方的增强策略包括随机水平翻转、随机缩放裁剪、颜色抖动。但要注意DETR的缩放裁剪是同时作用于图像和标注的而且裁剪后的图像要保证至少有一个完整的目标否则这个样本的匹配会出问题。我一般用官方提供的RandomHorizontalFlip和RandomResizeCrop参数用默认的就行。3.3 DETR的收敛问题与改进方向DETR收敛慢的根本原因在于匈牙利匹配的稳定性。训练初期query和目标的匹配关系一直在变导致梯度方向不一致。改进思路主要有两个方向一是引入先验知识比如Deformable DETR用参考点初始化query让每个query从一开始就关注某个区域二是改进匹配策略比如DN-DETR引入去噪训练给query加上噪声让模型学会恢复真实框。另一个改进方向是和多模态结合。最近有个热词叫“yolo图文多模态”其实DETR在这方面更有优势因为Transformer天然适合处理多模态输入。我试过把CLIP的文本特征和DETR的视觉特征做交叉注意力在开放词汇检测上效果不错但训练成本很高需要多卡A100才能跑起来。如果你只是想用DETR做常规检测我的建议是直接用Deformable DETR或者DINO收敛速度和精度都比原版DETR好很多。DINO在COCO上12个epoch就能达到49.4 mAP这个水平已经和Faster RCNN打平了而且端到端的流程更干净。4. YOLO系列从v1到v8的工程化落地之路4.1 YOLO的核心设计哲学与版本演进YOLOYou Only Look Once的核心思想是把检测问题当成回归问题一张图只过一次网络直接输出所有目标的边界框和类别。这个设计让YOLO的速度远超两阶段检测器v1版本在Titan X上能跑到45 FPS而Faster RCNN只有5 FPS。但v1的精度不行尤其是小目标和密集场景漏检很严重。v2引入了Anchor Box和Batch Normalization精度大幅提升同时提出了Darknet-19 backbone。v3是YOLO的巅峰之作引入了FPN结构做多尺度预测backbone换成Darknet-53在COCO上mAP达到33.0速度还有30 FPS。v4和v5主要是工程优化v4引入了CSPDarknet53、Mish激活、CIoU Loss等trickv5则是Ultralytics做的工程化封装提供了极其方便的API和部署工具。v6和v7是美团和AlexeyAB的版本v8是Ultralytics的集大成之作支持分类、检测、分割、姿态估计多个任务而且提供了从训练到部署的全套工具链。现在最新的v10在v8基础上做了进一步优化主要是去掉了NMS但工程成熟度还不如v8。我目前主力用v8因为它的生态最完善遇到问题容易找到解决方案。4.2 YOLOv8环境搭建与训练自己数据集的完整步骤YOLOv8的环境搭建非常简单官方提供了pip安装方式。但要注意ultralytics包会自动安装PyTorch如果你的机器上已经有特定版本的PyTorch可能会被覆盖。我建议先手动装好PyTorch和CUDA再用pip install ultralytics --no-deps然后手动装依赖。训练自己的数据集第一步是准备YOLO格式的标注。每张图对应一个txt文件每行格式是class_id x_center y_center width height坐标都是归一化到0-1的。如果你用labelImg标注导出时选YOLO格式就行。数据集目录结构要按官方要求来datasets目录下建images和labels两个文件夹各自再分train和val子文件夹。配置文件方面需要建一个data.yaml里面指定train、val、test的路径以及nc类别数和names类别名称列表。这个文件路径一定要用绝对路径相对路径经常出问题。模型配置文件可以用官方的yolov8n.yaml、yolov8s.yaml等n是最小的s是smallm是mediuml是largex是extra large。如果要做实例分割用yolov8n-seg.yaml。训练命令很简单yolo train datadata.yaml modelyolov8n.pt epochs100 imgsz640 batch16。但这里有几个参数需要根据实际情况调整。imgsz是输入分辨率640是默认值如果小目标多可以调到1280但显存占用会翻倍。batch根据显存来V100 32G可以开到64消费级显卡8G只能开到8。epochs一般100到300如果数据集小可以少一点但要注意早停。4.3 YOLO损失函数与训练中的BN崩溃问题YOLOv8的损失函数由三部分组成分类损失、回归损失、DFL损失。分类损失用的是BCEWithLogitsLoss回归损失用的是CIoU LossDFL是Distribution Focal Loss用来学习边界框的离散分布。这三个损失的权重在代码里是硬编码的box7.5cls0.5dfl1.5。如果你要改需要修改ultralytics/utils/loss.py里的对应参数。训练中最常见的问题是BN崩溃表现为loss突然变成NaN或者mAP骤降到0。原因通常是batch size太小BN的统计量估计不准。YOLOv8默认在训练时冻结BN的running mean和var用预训练模型的统计量这个策略在大多数情况下是有效的。但如果你的数据集和预训练数据分布差异很大冻结BN反而会限制精度。这时候可以解冻BN但要把batch size调到至少16否则崩溃概率很高。另一个高频问题是“yolo混淆矩阵总合不唯一”。这个问题的本质是验证时同一张图被多次统计。YOLOv8在验证时会做数据增强如果开启了TTATest Time Augmentation同一张图会被推理多次混淆矩阵就会重复累加。解决办法是在验证时关掉TTA或者用val.py单独跑验证不要用train.py里的验证。4.4 YOLO边缘部署与RK3588实战经验YOLO在边缘端的部署目前最火的平台是RK3588。这块芯片有6TOPS的NPU算力跑YOLOv8n能到30FPS以上功耗还低。但部署流程比较繁琐需要把PyTorch模型转成ONNX再转成RKNN格式。转换过程中有几个坑一是ONNX的opset版本要和RKNN工具链匹配我一般用opset 12二是输入尺寸必须是32的倍数640×640没问题但608×608就会报错三是后处理里的NMS最好放到CPU上做NPU对NMS的支持不太好。部署到RK3588之后最常见的问题是误检率高。我排查过很多次原因主要有三个一是量化精度损失INT8量化后小目标的特征会丢失解决办法是用混合量化对敏感层保持FP16二是输入预处理不一致训练时用的归一化参数和部署时不一致这个一定要对齐三是后处理阈值没调好conf_thres和iou_thres需要根据实际场景调我一般从0.25和0.45开始试。如果要在树莓派上跑YOLO建议用YOLOv8n或者YOLOv5n用NCNN推理框架速度能到5-10FPS。但树莓派的CPU性能有限输入分辨率要降到320否则帧率会掉到1以下。另外树莓派的散热是个问题长时间跑会降频最好加个风扇。5. 三大框架的横向对比与选型决策表5.1 精度、速度、数据需求的多维度对比维度Faster RCNNDETR (Deformable)YOLOv8COCO mAP42.046.253.9推理速度 (V100)5 FPS15 FPS80 FPS训练收敛epoch50-10050100-300最小数据量500张1000张200张小目标效果好一般好部署难度中高低端到端否是否边缘端支持差差好这张表是我根据实际项目经验整理的数据可能和论文有出入但趋势是对的。Faster RCNN的精度在早期是标杆但现在已经被YOLOv8和Deformable DETR超越了。DETR的优势在于端到端和Transformer的扩展性但部署难度确实高。YOLOv8在精度、速度、部署便利性上取得了最好的平衡这也是它成为工业界首选的原因。5.2 不同场景下的选型建议如果你做的是离线分析比如电力巡检的红外图像检测对速度没要求但要求高召回率Faster RCNN或者Deformable DETR都可以。我做过一个电力红外数据集的项目用Faster RCNN训练mAP 0.72召回率0.85满足业务需求。但如果要实时监控比如火灾实时监控手机摄像头那必须用YOLO而且要用nano版本否则手机端跑不动。如果你做的是小样本检测比如只有几十张标注图那三个框架都不太适合直接训练。我的建议是用预训练模型做微调YOLOv8的预训练模型下载很方便官方提供了在COCO上预训练的权重微调时冻结backbone只训练head效果通常不错。DETR的预训练模型也有但微调时需要更大的学习率和更长的训练时间。如果你要做多模态检测比如图文多模态目标检测DETR是更好的选择因为Transformer天然支持多模态输入。我试过用CLIPDETR做开放词汇检测虽然训练成本高但效果确实好。YOLO在这方面也有尝试比如YOLO-World但成熟度还不如DETR系列。5.3 模型改进与前沿方向YOLO的改进方向很多常见的有换backbone比如用MobileNet、EfficientNet、加注意力机制SE、CBAM、改损失函数Focal Loss、GHM、加辅助训练头。我试过在YOLOv8里加CBAM注意力mAP提升了1.2个点但推理速度降了15%性价比一般。最近有个热词叫“mamba yolo复现”Mamba是状态空间模型比Transformer的复杂度低适合长序列建模但在检测任务上的效果还有待验证。DETR的改进方向主要是收敛速度和中小目标。Deformable DETR、DAB-DETR、DN-DETR、DINO这几个工作把DETR的收敛速度从500 epoch拉到了12 epoch精度也超过了Faster RCNN。如果你要用DETR我建议直接从DINO开始它是目前DETR系列里综合表现最好的。YOLO和Transformer的结合也是一个热点。我试过把YOLOv8的backbone换成ViT但效果不如CNN因为ViT需要大量数据预训练在小数据集上容易过拟合。更好的方式是在neck部分加Transformer模块比如用Transformer Encoder替换PANet这样既能利用Transformer的全局建模能力又不会破坏CNN的局部特征提取。6. 实操中的高频问题与排查技巧实录6.1 训练不收敛的排查思路训练不收敛是最高频的问题我总结了一套排查流程。第一步看loss曲线如果loss从一开始就震荡得厉害大概率是学习率太大先把学习率降10倍试试。第二步看数据用可视化工具把标注框画到图上确认标注没问题。我遇到过标注文件里坐标是归一化的但没乘宽高导致所有框都在左上角模型根本学不到东西。第三步看预训练权重如果是从头训练收敛慢是正常的加载预训练权重能快很多。如果loss下降但mAP不涨那可能是过拟合了。解决办法是加数据增强、加正则化、减小模型复杂度。我遇到过训练集mAP 0.9但验证集只有0.3的情况后来发现是数据集划分有问题训练集和验证集有重叠。重新划分之后验证集mAP到了0.65。6.2 部署时的精度损失与对齐技巧训练时mAP 0.8部署后掉到0.5这种精度损失在边缘部署中很常见。原因通常是量化损失、预处理不一致、后处理差异。量化损失可以通过混合量化缓解把敏感层保持FP16。预处理不一致需要仔细核对训练和部署时的归一化参数、通道顺序、输入尺寸。后处理差异主要是NMS的阈值和实现方式训练时用的NMS和部署时的NMS要一致。我一般会在部署前做一个对齐测试用同一张图分别在PyTorch和部署框架上推理对比输出的边界框和置信度。如果差异超过5%就要逐层排查。常见的问题是部署框架的resize方式和PyTorch不一致PyTorch默认是bilinear有些部署框架默认是nearest这个一定要对齐。6.3 数据集构建的避坑指南数据集的质量直接决定模型的上限。我踩过的坑包括类别不平衡、标注不一致、背景样本过多。类别不平衡的解决办法是过采样少数类或者用Focal Loss。标注不一致需要制定详细的标注规范比如边界框要贴紧目标边缘遮挡目标怎么标这些都要提前定义好。背景样本过多会导致误检率高解决办法是控制背景图的比例一般不超过总数据的10%。还有一个容易被忽略的点是数据集划分。训练集、验证集、测试集要按场景划分不能随机划分。比如你做校园检测如果随机划分同一场景的图可能同时出现在训练集和验证集验证集mAP会虚高。正确的做法是按场景划分比如用A教学楼的图做训练B教学楼的图做验证这样验证集mAP才能反映真实泛化能力。6.4 常见问题速查表问题现象可能原因排查方法解决方案loss变NaN学习率太大/BN崩溃检查学习率、冻结BN降学习率、冻结BNmAP不涨过拟合/数据问题看训练验证曲线加增强、重新划分数据部署后精度掉量化损失/预处理不一致对齐测试混合量化、对齐预处理误检率高背景样本多/阈值低看混淆矩阵控制背景比例、调阈值小目标漏检输入分辨率低/特征丢失可视化特征图提高分辨率、加FPN训练速度慢batch size小/数据加载慢看GPU利用率加num_workers、用缓存这张表是我这些年排查问题的经验总结基本上覆盖了80%的常见问题。遇到新问题的时候我一般先看loss曲线再看数据可视化最后看部署对齐这个顺序能解决大部分问题。7. 从训练到部署的完整项目实战建议7.1 项目启动前的技术选型清单在启动一个检测项目之前我一般会先问几个问题数据量有多少标注质量怎么样推理硬件是什么实时性要求多高精度要求多高这几个问题的答案基本决定了技术选型。数据量少于500张优先考虑YOLOv8微调数据量在1000-5000张三个框架都可以看部署需求数据量超过10000张可以考虑从头训练或者用DETR做端到端。硬件方面如果部署在服务器GPU上三个框架都可以如果部署在边缘设备上YOLO是唯一选择如果部署在手机端YOLOv8n或者YOLOv5n是首选。实时性要求30FPS以上必须用YOLO要求10FPS左右Deformable DETR也可以要求5FPS以下Faster RCNN也能接受。7.2 训练过程中的监控与调优策略训练过程中我一般会监控几个指标loss曲线、mAP曲线、学习率曲线、GPU利用率。loss曲线看收敛情况mAP曲线看泛化能力学习率曲线确认调度策略生效GPU利用率看数据加载有没有瓶颈。如果GPU利用率低于50%说明数据加载是瓶颈需要加num_workers或者用更快的存储。调优策略上我一般先调学习率和batch size这两个对结果影响最大。学习率用LR Finder找最优值batch size在显存允许范围内尽量大。然后调数据增强增强太弱会过拟合太强会欠拟合需要根据验证集mAP来平衡。最后调模型结构比如换backbone、加注意力、改损失函数这些改动对精度的影响通常在1-3个点。7.3 部署上线的检查清单部署上线前我一般会做以下检查模型输入输出对齐、预处理对齐、后处理对齐、性能测试、稳定性测试。输入输出对齐是确认部署模型的输入尺寸、通道顺序、归一化参数和训练时一致。预处理对齐是确认resize、padding的方式一致。后处理对齐是确认NMS的阈值和实现一致。性能测试是测推理速度、显存占用、CPU占用。稳定性测试是连续跑24小时看有没有内存泄漏或者崩溃。还有一个容易忽略的点是版本管理。训练用的PyTorch版本、CUDA版本、部署框架版本都要记录清楚否则后面复现或者升级的时候会很麻烦。我一般用conda env export导出环境用git管理代码用DVC管理数据集和模型权重。7.4 持续迭代与模型更新的经验模型上线不是终点而是起点。实际场景中的数据分布会随着时间变化模型精度会逐渐下降。我一般会定期收集线上数据人工标注后加入训练集做增量训练。增量训练时要注意新数据要和旧数据混合不能只用新数据否则会灾难性遗忘。混合比例一般是新数据占30%-50%旧数据占50%-70%。模型更新时我一般会做A/B测试新模型和旧模型同时跑一段时间对比精度和速度。如果新模型精度提升但速度下降太多需要权衡是否值得。如果新模型精度下降需要排查是数据问题还是训练问题。我遇到过新模型在验证集上精度更高但线上效果更差的情况后来发现是验证集和线上数据分布不一致重新划分验证集之后问题解决了。7.5 给不同阶段从业者的学习路径建议如果你是刚入门的新手我建议从YOLOv8开始因为它的文档最完善社区最活跃遇到问题容易找到答案。先跑通官方示例再训练自己的数据集最后尝试部署到边缘设备。这个过程大概需要1-2个月。如果你已经有一定基础想深入理解检测原理我建议读三篇论文Faster RCNN、DETR、YOLOv3。这三篇分别代表了两阶段、Transformer、单阶段三种范式读完基本能建立完整的知识体系。然后可以尝试复现一些改进工作比如Deformable DETR、YOLOv8的注意力改进等。如果你要做工程落地我建议重点学习部署相关的技能ONNX导出、TensorRT加速、RKNN转换、NCNN推理。这些技能在实际项目中比调参更重要。我见过很多模型在PyTorch上精度很高但部署后完全不能用就是因为部署环节没做好。最后分享一个我个人的习惯每次做完一个项目我都会把踩过的坑和解决方案整理成文档下次遇到类似问题直接查文档效率高很多。这个习惯坚持了几年现在我的排查文档已经有上百页了基本上覆盖了目标检测项目从训练到部署的所有常见问题。
