如何评价新出的YOLO v4 ？

很荣幸也很尴尬地做了一个和YOLO v4 中的Mosaic技巧部分撞车的工作，吓得我赶紧把我们的工作放出来。

• Stitcher: Feedback-driven Data Provider for Object Detection

在这个问题下面和大家分享一下我们的工作，正好解释一下我们和YOLO v4 - Mosaic的区别与联系，以及这种类似的做法为什么能涨点，以及其他可以挖掘的点。

• Motivation
  去年打COCO比赛的时候，我负责研究detection的training方式，当时尝试了Multi-scale training的各种settings、SNIP^[1]/SNIPER^[2]、CSN^[3]等。发现Multi-scale training对模型训练是真的很有帮助，即使在接近50 AP的高baseline上还有不俗的提升。然而，普通的Multi-scale training太低效了，而SNIPER是真的复杂，需要处理好label assignments, valid range tuning, positive/negative chip selection，费了我们很大的力气才把它从MXNet源码迁移到我们自己的框架上。这样的心态和需求，迫使我们去研究一种更简洁实用的multi-scale training 方法。
  
  不管是普通训练还是Multi-scale training，我们发现在COCO上训练出来的模型，小物体的AP永远是比中物体和大物体低很多。比如，在最常用的baseline: Faster R-CNN + ResNet 50-FPN (1x) 的结果(AP: 36.7 %, AP small: 21.1 %, AP mid: 39.9 %, AP large : 48.1 %)中，AP small 比 AP large 低了两倍还多。接下来，我们就开始研究，小物体到底出了什么问题，以及怎样解决这样的问题。
  
  首先，我们统计了小物体在数据集中的分布，发现训练集中小物体的数量并不少。如下表所示，在所有boxes中，有41.4 %是小物体，是这三类物体之中最多的；但小物体的分布却非常不均匀，只有52.3%的图片中包含了小物体，而中物体和大物体分布都相对均匀。换句话说，小物体数量很多、但分布非常不均匀，有接近50%的图片中都没有小物体。

接下来，我们又统计了一下，在训练过程中小物体的loss分布。能直接反应模型学习情况的是loss，进一步发现，还是在这个Baseline: Faster R-CNN + ResNet 50-FPN (1x)的训练过程中，有超过50% iterations中，小物体所产生的loss都非常低（不到总loss的0.1）。这说明在模型训练过程中，小物体提供给网络的监督是不足的。

通过上述分析，我们的猜疑链形成：数据集中小物体分布不均匀 --> 训练中小物体学习不充分（Loss不足） --> 训练完的模型小物体精度差。而接下来就是按照这个逻辑逐步设计解决方法。

• Method

在已经有了前面multi-scale training和SNIPER的实验结果后，我们想到可以把图像缩小，并拼接在一起（逆SNIPER而行，SNIPER是裁剪，Stitcher是拼接）。如下图所示，我们把batch内每4张图都缩小到同样大小，之后拼成一张与正常普通同样大小的图作为训练。通过这样的方式，把大物体和中物体缩小成中物体和小物体，来均衡不同Scale物体在训练过程中的分布。

（这里与YOLOv4-Mosaic类似，但不同的是我们没想到拼接的时候可以调整4张图为不同大小。 ）

接下来就是紧张刺激的实验环节，完全采用这种拼接图进行训练，在上文36.7% 的baseline上得到了32.1%的惊人结果。 然而，就算在32.1% 的 AP 中（AP small: 21.9, AP mid: 36.4, AP large: 36.8）的AP small仍然比36.7% 的baseline中的AP small要高，这让我们看到了希望。这说明，拼接图是有用的，只是我们没用好，所以影响了最终效果。

前面对训练过程中loss的分析，给我们提供了一个自然而然的思路，就是直接用loss 作为反馈信号，来指导拼接图的使用。我们采用了一种“缺啥补啥”的简单思路：如果上一个iteration中，小物体产生的loss不足（比例小于一个阈值），则下一个iteration就用拼接图；否则就用正常图片训练。这个思路将32.1%的结果一下子增长到了38.6%，且统计loss比例几乎不需要额外的计算量。

• Experimental Results

（1）我们在Faster R-CNN、RetinaNet的1x / 2x上都进行了实验，有2个点左右的AP提升，且涨点主要来自于AP small。这符合我们最初的Motivation和方法设计。

（2）此外，我们还在更大的backbone / 更高的baseline (ResNext + Deformable) 、其他数据集 (PASCAL VOC)、Instance Segmentation (Mask R-CNN) 等settings上都做了实验验证，都有不同程度的效果提升。

• Further Analysis
  除了常规实验以外，还有一些其他的效果分析可供讨论。
  
  1. 只能4张 （平方数） 拼接吗？
  答案是否定的。
  不管是我上文介绍的拼接方式还是YOLO v4，都是在Spatial维度 (h,w)上进行拼接的。如下图(c)中所示，本文还提供了一种在batch维度n上拼接的等价的实现方式，也能达到一样的效果。
  
  这样的做法可以带来如下好处：
  (1) 拼接图像的数目不再需要因为spatial的限制局限于平方数，可以自由选择2、3、4、5、6等张数图像进行拼接。
  (2) 对于那些读写内存有限制的训练设备平台，提供了一定的自由度。

2. 过拟合问题（更长训练时间的增益）

在后续实验中，我们还发现Stitcher可以起到防止过拟合的作用。在不用SyncBN之类的骚操作的情况下，把一个最普通的Faster R-CNN + FPN模型直接训练时间较长（6x）是会有严重的过拟合的（36.7-->35.6），但Stitcher却没有这个问题。因为在Stitcher训练过程中，拼接图像的挑选组合是随机的，拼接图像的多样性防止了过拟合的发生。

3. 计算量代价

（1）对于Inference阶段，Stitcher 没有做任何修改，不需要调multi-scale testing之类的操作。所以，如果使用者只关心Inference time 的话，Stitcher带来的涨点可以说是完全免费的。

（2）对于Training阶段，Stitcher 额外引入的操作包括：image stitching 和 loss ratio calculation这两步。经实测，后者可以忽略不计，额外的耗时集中在于前者对图像的interpolation. 我们在同一台 8 GPUs RTX 2080 TI 的机器上实测，对于Faster R-CNN + ResNet 50 + FPN的baseline上，加上Stitcher需要额外多训练15分钟左右。这相比于8个多小时的训练来说，多等15分钟也是可以接受的。

• Conclusion
  总结一下，我们这篇工作从小物体精度低这个问题入手分析，提出了一种新的multi-scale training方式 Stitcher，在常用的数据集、检测器、训练方式上均涨点明显，没有引入任何Inference负担，有一定的简洁实用性。代码和模型都会在近期开源。
• 欢迎各位大佬对我们的文章提出意见建议！

参考

1. ^An Analysis of Scale Invariance in Object Detection - SNIP http://openaccess.thecvf.com/content_cvpr_2018/papers/Singh_An_Analysis_of_CVPR_2018_paper.pdf
2. ^SNIPER: Efficient Multi-Scale Training https://papers.nips.cc/paper/8143-sniper-efficient-multi-scale-training.pdf
3. ^Consistent Scale Normalization for Object Recognition https://arxiv.org/pdf/1908.07323.pdf

很有价值但没有什么太大的意思，试了很多trick，最后选了一组最优的，相当于帮工程师试了一遍错。其实适用范围有限，工作中用到的数据集很多都是奇奇怪怪的，你怎么就知道这文章的结论适用你的数据集呢？像giou diou, ciou啥的，最后自己还是会亲自试的。

而且这已经不是Yolo系列的风格了，没什么好激动的，甚至让人感到失望。

为啥Yolo这么多人喜欢，工业界用的多（不出意外，应该是最多的），不是因为什么精度速度trade off 最优，比Yolo更快更好的模型多了去了，无数轻量级网络都是以YoloV3为base line的，不打败YoloV3都不好意思发论文。但工业界用的最多的还是YoloV3，主要原因还是简洁。

所谓的简洁，就是结构简单，一眼就懂，随便哪个框架，哪怕caffe 1.0都能顺手写出来。一路conv max pool relu到底，通透。随便接个自己的数据一跑都能work，想要改大改小都很简单。

这感觉很过分，但很多时候都是不得已的，工业界使用的硬件五花八门，各自有各自的支持范围。但无论哪个硬件，他们一定会支持Yolo，Yolo就是所有硬件的交集。你比如一个推销FPGA的厂商要来演示，肯定会演示Yolo，能跑这个，就算保底了，客户也也就没那么多废话可问，Yolo嘛，大家都能背的。

虽然已经2020了，很多硬件都是不支持depth wise conv的，甚至还有硬件只支持relu这一种激活函数的。没有sigmoid，那Attention相关的都可以不用想了。最近新出来的各种激活函数也不用想了，dilated conv是不可能的，什么，你还想Deformable和dynamic conv？怕不是在做梦吧？

所以这个新的Yolo v4，很多工程师大概率就是跟我一样了，极其兴奋的打开论文，然后心越看越凉。。。紧跟时代用新版Yolo秒杀客户的企图就这么泡汤了。。。最终，大家的demo仍然会定格在Yolo V3，然后根据硬件的需要魔改一番。Yolo如果放弃了他简洁通透conv到底的特点，和其他各路检测框架就没区别了，泯然众人矣。

不过有一说一啊，文章本身还是很好的，肯定要细细研读，这对我而言就是目标检测的trick综述，而且还有很多训练端的方法可以用，许多trick我之前都不知道…