吃瓜笔记 | 旷视研究院解读Light-Head R-CNN：平衡精准度和速度-CSDN博客

主讲人：黎泽明 | 旷视研究院研究员
屈鑫编辑整理
量子位出品 | 公众号 QbitAI

12月20日晚，量子位·吃瓜社联合Face++论文解读系列第三期开讲，本期中旷视（Megvii）研究院解读了近期发表的Light-Head R-CNN论文。

本篇论文所提出的Light-Head R-CNN，构造了轻量头部R-CNN网络，在COCO数据集上超越当前最好水准，同时还保持了很高的时间效率。

本期主讲人为旷视研究院研究员黎泽明，同时也是COCO 2017 Detection竞赛队主力队员、Light-Head R-CNN论文一作。

量子位应读者要求，将精彩内容整理如下：

Light-Head R-CNN这篇论文主要是探讨了R-CNN如何在物体检测中平衡精确度和速度。论文中提出了一种更好的two-stage detector设计结构，不仅提升精度，同时使除去base model的那部分模型(head)的复杂度变得更加的灵活和可控。

基于resnet101我们达到了新的state-of-the-art的结果40.6，超过了mask rcnn和retinanet。同时如果是用一个更小的网络，比如类似xception145M的小模型，light-head 达到了100+ FPS，30.7mmap，效率上超过了ssd和yolo。

我们首先尝试着去找出two-stage检测方法在速度上不够好的原因。其实two-stage和single-stage都能达到非常高的精度。但在速度方面，single-stage往往更具有优势，比如ssd和yolo。在这篇论文中，我们想表明通过精心的设计，两阶段的物体检测器也能做到特别快，而且精度可以做到更高。

回顾paper结果

相比state-of-the-art 算法拥有更高的精度和效率。

红色的三角形曲线对应论文跑出来的结果。横轴是inference time，就是你的物体检测器在testing时候的速度，单位是毫秒；纵轴是COCO的MMAP，从0.5到0.95，这个范围内取一个平均的Map。最左边这个红色的三角形是用一个小模型跑出来的结果，中间的这个三角形是用ResNet-50跑出来的结果，最上面的红色三角形是用ResNet-101跑出来的结果。可以看到不管是从精度还是效率，论文中所做出来效果达到了state-of-the-art。

关于文章的标题：有网友热心的取了光头r-cnn的绰号，我们的方法其实没有“琦玉老师”那么强，所以内部给它取了一个绰号叫做子弹头。如果从这条结果曲线上来看的话，其实 Light-Head R-CNN它的速度和精度都是特别高的。总结起来这个方法应该是一个快准狠的一个方法。

light-head r-cnn非常灵活和通用，这个在后面讲我那个方法的结构的时候会有所体现。而且框架也非常统一，在light-head rcnn 的角度下，faster 和rfcn结构其实很类似。

另外需要注意的是，我们是在titan xp上测试的，相比老系列的titan x，我们的结果会慢一些，但依然是在蓝色和绿色曲线的上方。然后测试阶段使用1卡一batch。

物体检测的两大类

现在的物体检测比较通用的大概能分为两类：single stage的物体检测；two stage的物体检测方法。

two stage物体检测是基于proposal的，经典的就是R-CNN这一个系列的检测方法；而single stage不依赖于proposal，例如基于anchor的 SSD方法。所以single stage在结构上会少一个proposal的predictor。Two stage往往会引入额外的计算量来对proposal，也就是所谓的ROI进行回归和分类。

也就是说Two-stage的detector比one stage多了一步，对proposal的回归和分类器（R-CNN）。如果单纯说速度,two-stage 肯定是慢于one-stage的.但是诸如retinanet和ssd的single-stage detector也存在一些问题，就是需要对每个anchor进行分类，想比two-stage的rpn而言，anchor预测的channel数会增加。

而在two stage中，第一个stage只是做一个二分类，它的channel就不会很多。同时如果我们降低第二个stage，也就是ROI预测的部分的复杂度，直到相比于前面的base model计算量达到可以忽略不计的程度，那是不是我们也能说第二个stage对网络的速度没有太大的影响。这样在总体的复杂度上就能和single stage的检测效率差不太多了。

所以这篇论文要探讨一个问题，就是怎么样设计第二个stage？就目前情况而言，第二个stage 太厚重了。

我们的结论是：在一般的情况下，两阶段的检测方法会在精度更具优势，但是因为它引入了比较厚重的第二个阶段，所以对速度会有一点影响。但相比one-stage物体检测,如果两阶段检测对精度有所提高，我们就能牺牲更多的精度去换取速度的提升。

为什么这么说？因为比速度都是固定的精确度的情况下，如果能达到同样的精确度，速度比另一种方法快，这个就是比较合理情况。在论文的后半部分提到会用一个小模型来替换前面的base model，就是因为小模型它会牺牲一定的精确度来提升性能。

也就是说在同样的精确度的情况下，速度如果能和single stage相匹敌，那么two stage依然是有它的优势。

所以如果能把第二个stage的计算量给减下去，而且相比single stage而言，性价比足够高，那么就可以考虑引入第二个stage。

如何提高速度

我们回顾一下Fast和R-CNN，其实它两个大体上结构都差不太多，一个是把计算量放在了ROI操作的后面，一个是把计算量放在了ROI操作的前面。也就是在Head那部分,其实他们两个都引入了一些比较大的计算量。

先具体分析下导致Faster R-CNN 和R-FCN在小模型上不够快的原因。Faster R-CNN 用两个厚重的fc（或者resnet 的第5个stage）做proposal的预测，而R-FCN则通过制造了一个 (类别数x7x7)channel的大score map。除去basemodel的那部分，两个方法都引入了比较大的计算量。

基于前面的观察，我们设计了更灵活通用的框架。里面最重要的点，就是把pooling的feature map变得特别薄。为什么要把它变薄呢？因为Head那一部分，复杂度有两个因素决定：pool的feature map的厚度；以及对pool出来的feature进行分类和回归的那一部分，如果这部分逻辑比较多，它依然会对于整体的网络效率有所影响。

然后涉及到一个问题：pooling的feature map能不能变得很薄？

我们做过一些验证的实验。最早的时候在原本的R-FCN上做了一次实验。我们试过把它压到10×P×P，相当于把原来3900多个channel，压到了490个channel。然后发现掉的点几乎没有。我们在VOC上做过一系列的实验，压成10×P×P是根本不会掉点的。在COCO上面只会掉零点几，再把它压得更多一点，压成5×P×P也只是掉零点几。

这个地方补充一句，feature map被压薄了之后，是没办法直接Average voting出来最后的结果的。但是可以通过在后面加一个到81类的全连接层来出最后的结果。

Table 中的B1是原来的 R-FC baseline 32.1，然后直接加10×P×P的feature map，实现出来有31.4，只会低零点几个点。

B2是reproduce的RFCN baseline，是用FPN paper中的setting，另外讲R-CNN中regression的loss 乘了两倍。基于B2即便是减到10×P×P，MMAP也是掉了零点几。其实如果把它减到5×P×P的channel的话，结果和减到10×P×P也差不太多，和10×P×P相比不到0.2的损失。

本来也想做一组基于faster R-CNN的把feature map变薄的实验。但是这个实验其实不能直接这么比。这是为什么呢？因为第二个stage的两个全连接层计算量挺大的，不能直接把pooling的feature map给减小；即便是要减小，也要把第二个stage的计算量给砍下来。本来pool的feature就比较薄，如果再引入一个比较厚重的第二个stage，这个网络就会变得很突兀。然后和faster的比较可以和后面加入了cheap R-CNN的结果上得到。

Head的第二个部分，也就是在第二个stage的预测部分，我们引入了一个额外的全链接层，大概是2048个channel。两个组合起来，就是文章里面所谓的Light-Head的那部分了，其实这个时候Head已经变得更加的灵活和可控。因为pooling的feature map很薄了，所以可以上一个比较大一点的卷积层，这个也会带来一点点性能的提升。

这个表对比了下现在市面上的baseline，我们的结果在单尺度训练下是39.5，multiscale-train是40.8,超过了以往的所有state-of-the-art，比如retinanet和mask rcnn。我们也尝试了加入feature pyramid，大概是41.5。

讲讲得到这个结果的过程。前面的baseline已经达到了37.7，然后把pooling做一个alignment，大概能涨1.3个点；我们在训练的时候用的是0.3的NMS，换成0.5之后，能涨0.5左右；然后加multiscale train也能涨一个点。也就是最后的40.8的结果。

我们设计的初衷，就是要让第二个stage变得更加灵活和可控。所以又试了另外一种方法：把前面的base model部分替换成一个比较小的模型。然后设计了一个145兆的一个类似xception的网络。

大模型和小模型基本上没什么太大的区别，比较大的区别是在第五个stage：大模型是用了atrous algorithm，小模型没有用。小模型把RPN convolution数砍到了只有256。小模型的结果如下表,可以看到Light-head r-cnn在效率上超过了所有的速度模型包括ssd和yolo。

其实Light-Head R-CNN还可以继续砍，我们就又补了一些新的实验，把pooling的feature map channel砍到5×P×P，结果没什么变化。然后kernel也没有必要用15那么大，减到7结果也不会掉点。即便是把出feature map那个大kernel扔掉，直接用1×1，精确度也不会掉太多，也就一个点以内。

所以如果使用Light-Head，它的第二个stage(除去base model那部分Head)复杂度就会更加的可控，以及更加的灵活。这是我们最后跑的大模型以及小模型的结果对比的样例图。

最后放一段大模型和小模型的检测对比的视频。

class="video_iframe" data-vidtype="2" allowfullscreen="" frameborder="0" data-ratio="1.7647058823529411" data-w="480" data-src="http://v.qq.com/iframe/player.html?vid=u05242si8d3&width=670&height=376.875&auto=0" style="display: block; width: 670px !important; height: 376.875px !important;" width="670" height="376.875" data-vh="376.875" data-vw="670" src="http://v.qq.com/iframe/player.html?vid=u05242si8d3&width=670&height=376.875&auto=0"/>△ xception145 class="video_iframe" data-vidtype="2" allowfullscreen="" frameborder="0" data-ratio="1.7647058823529411" data-w="480" data-src="http://v.qq.com/iframe/player.html?vid=d0524yu035a&width=670&height=376.875&auto=0" style="display: block; width: 670px !important; height: 376.875px !important;" width="670" height="376.875" data-vh="376.875" data-vw="670" src="http://v.qq.com/iframe/player.html?vid=d0524yu035a&width=670&height=376.875&auto=0"/>△ res101

一则招人硬广：
希望加入旷视科技一起登上CV巅峰的同学可以投简历至俞刚：yugang@megvii.com，长期招聘算法实习生。实习优秀者，更有直接跳过面试阶段，入职megvii研究院的机会。

Q&A

速度上来说，是简化Head提升更多还是简化base model的提升更多？

如果你是resnet 101这样大网络，即使把后端减得特别小，也不会对你的网络速度提升特别多，因为有很大的计算量是在base model的那部分。在这样的前提下，你就需要先把你的base model给砍得特别小，比如把它做到145M这样的一个很高效的Xception的网络。如果是在小模型情况下，就需要简化Head。需要根据不同的情况下，具体来比较两种方法。

这个会开源吗？

肯定是会开源的，我们这次的实验结果中所有的大模型结果都出来了，但是还有一小模型细节需要调试一下，因为TensorFlow和旷视自己的平台有一些差异的地方。

为什么Light-Head可以比two-stage要好？

Light-Head的结果比R-FCN和Faster R-CNN这样的two-stage结果要高。这个是怎么样达到比别人高的呢？相比R-FCN，我们其实是在第二个stage上加了一个廉价的只有一个全联接层的子网络，这个子网络能提1.8个点。在前面我们还加了一个比较大的kernel，因为我们pooling的feature map比较薄，所以可以上一个比较大的kernel size，然后这个也会对你的结果提0.6个点左右(对faster也同样会涨点)。

ROI的数量设多少？

我们用的是一千个ROI做测试。Light-Head R-CNN对ROI的数量的敏感度是介于R-FCN和Faster R-CNN之间的。因为R-FCN是一个在第二个stage没有计算量的框架，而faster它是在第二个stage上堆了很多计算量。而我们的第二个stage很轻量，但也并不是没有计算量。

如果用的是ROI pooling的话，跟RFCN网络所说的位置敏感性的初衷有所冲突吗？

如果用ROI pooling 后面直接voting出最后结果确实不太好，没有位置敏感性，但是Light-Head里面有一个轻量的fc来处理全局的位置信息。