目标检测是计算机视觉和模式识别领域的基础问题之一，对计算机视觉和模式识别领域具有重要的应用价值。因此，北京智源人工智能研究院和旷视联合推出了两个检测任务的新基准：Objects365 和 CrowdHuman，它们都是在自然场景设计和收集的。Objects365 基准目标用于解决具有 365 个对象类别的大规模检测。而 CrowdHuman 则针对人群中的人体检测问题。希望这两个数据集能够为推进目标检测研究提供多样化、实用性的基准。

我们邀请到来自好未来（TAL）技术中台视觉部算法专家、CVPR2019 Objects365 通用物体检测竞赛冠军 - 高原，为大家带来 Objects365 上届冠军获奖方案分享。

以下为高原老师带来的 Objects365 上届冠军获奖方案。

首先先简单介绍一下 objects365 数据集，下表是去年的 objects365 数据集和 coco 数据集的对比。目前这种大规模的图像检测的物体检测的数据集除了 objects365，还有 open images。在此将 objects365 与 coco 对比，是因为他们的标注的方法和标准是一致的。这里面的 objects365 数据是去年的结果，图像只有大概 61 万张，今年的数据已经到了 170 万张，可以看见数据的增长还是非常明显的。

后面几个数字包括图片的 box 的平均数，图像的宽高、图像的区域，还要最大的图像的 box 的数量。去年 Full track 有 365 类，60 万张的图片，还有一个 Tiny track，这个今年是没有的，Tiny track 是去年智源和旷视想推进对长尾数据的检测物体的研究和进展所提出的，所以挑选了当时最少的 65 个类别，作为 Tiny track 的数据集，它是 Full track 的一个子集。那么数据量也相应减少，这相当于降低门槛，可以给很多学生或者是个人一些参赛的机会。当然初衷是好的，但从结果上来看，如果想在 Tiny track 上取得比较好的成绩，还是需要在 Full track 上拿到一个比较好的成绩才可以。

最下面的这个是今年的 challenge 的链接，通过扫描右边这是二维码可以了解更多情况。

下面是两张 objects365 的 ground truth。objects365 的数据集的标注是非常花费人力、物力的，是一个非常贵的数据集。旷视和北京智源愿意把它公开分享出来，这是一个非常难得的事情。从图片中可以看到，几乎所有的前景物体都被完整的标注。

这是另外一张图，标注的非常细。比如说人的眼睛都是完整标注的。

object365 数据集是将数据集的所有类别在图片里完整标注。这与 open images 数据集不同，open images 数据集的特点也是数据量较大，类别较多（500 类）。但它因为数据量太大，所以投入了一个省事的方式，只标注了一部分类别。用 positive 类别表示这张图片里面存在的类别，positive 类别会加入 mAP 的考核当中。negative 类别表示不确保这个图片里有没有。如下图所示。

通过与 coco 和 open images 数据集进行对比，说明 object 365 这个数据集是非常有价值且可贵的。

先从 Full track 开始介绍。去年在做 Full track 时最开始选用了当时的 stat-of-art 检测器 Cascade RCNN。选择它的原因是 coco 的 MAP 的评估指标会受到不同值 IOU 检测框的影响。IOU 较大的检测框，对最终 MAP 的贡献的权重较大。因为最终是计算 MMAP 作为评价指标，其表示的是 IOU 从 0.5 到 0.95 的平均值，有可能 0.95IOU 的 box 是正确的，在其他的 IOU 更低的 threshold 的下，它都算是一个 true positive 的结果，所以 IOU 是非常关键的。选择 Cascade RCNN 来作为 baseline，在当时的 validation 集上结果是 MAP=22.73。

在 baseline 的基础上做的第一点改进是 NAS-FPN。这个在去年的时候比较火，当时 Google 正好出了一篇 NAS-FPN，效果非常好，但是当时做 NAS 这方面的工作不是很多，所以没有那么多的资源在如此大的数据集上去搜索连接。所以复现的时候采用 reinforcement learning 的方式来做搜索。因为训练 RL 相当于是要去训练一个 agent，来得到网络连接的输出。所以让 agent 先去一直不断地去 fit Google 的那篇 paper 中搜索出来的 NAS-FPN 的结果，然后让它去 overfit 到这样一个连接的学习结果。

基于这个结果，在 object365 上做 fune tuning。下图右边图就是当时 fune tuning 得到的一个连接，左边这张图就是标准的 FPN，简单解释一下：最左边 C2、C3、C4、C5 的初始值就是 backbone 网络输出来的特征值。然后最右边的 P2、P3、P4、P5、P6 代表着 FPN 每一个不同 level。

然后每一个画红圈的地方就代表的是这一个 level 给 box head 输出的层，可以看到左边这个标准 FPN，通过 C5 后会有一个上采样、下采样，然后会不断的上采样，并和之前的特征进行融合，拿到最终结果。而右边的这个是搜索出来的 NAS-FPN 结果，然后将这个结果叠加到标准的 FPN 之后，会连续的叠加几次。这边有一些数据是当时基于原始的 FPN，搜索了大概 400 的 episode 得到的结果。

下图可以看到，基于 NAS-FPN 叠加到 resnet50 上，大概有将近一个点的提升。在这边要说明一下， NAS LPN 在最终的最强 model 上的贡献比较有限，如果大家算力非常富裕的话可以试一试，如果说算力没有很富裕，这方法不用也可以，它在一个比较低的 baseline 上，可能会有一个比较高的提升，但是在一个很高的 baseline 上可能效果就不是那么明显了。

第二点改进是 class aware sampling，这是做这种大规模的通用物体检测非常重要的一个点。可以看一下下面两张图片。其

实包含了很多的框，可能两张图的框的数量总体来说是差不多的，但是左边这个图中框类别大概有 15 类，右边这张图里面只有 4 类，在正常去训练物体检测器的时候，其实是以相同的概率去采样这两张图片的，但以相同的概率去采用这两张图片，在这种大规模的物体检测上是不太合理了，因为它在类别的分布的不均衡上会越发的严重。

比如一般来说数量最多的类别是人，最少的类别就是通常在日常生活中很难见到的物体，这样就会造成一个问题，它跟最终计算 MMAP 时是不一致的。因为在计算 MMAP 时，第一个 M 可能是不同 IOU 下的 AP 值，然后另外一个 M 是不同类别之间的 MAP 值。也就是说所有类别对于最终指标 MAP 的计算来说贡献的权重是一样的，但是在训练的时候是没有偏向它的，就是说大家又不是以相同的一个概率来采样，这样的话对于计算 MAP 并不是一个很友好的状态。

基于此提出了一个基于检测任务的 class aware sampling ，可以用下面的公式来概括，但实际实现的时候其实是比较简单的。

公式可以简单介绍一下。 Pc 表示 365 个类别中每个类别的先验概率，代表每个类别采用的多少。比如人的类别相对来说比较常见，所以通常就会把该类别的先验概率调低。  代表这张图内是否包含该类别，后边∑这一项可以理解为这张图片包含的所有物体类别的先验概率的总和，需要声明的是，每个类别的 Pc只会取一次，相当于做驱重。另外一张图片中包含的物体越多，这张图片包含的信息就越丰富的，所以乘上一个这样的系数，可以让这张图片采用的概率更大。在实际操作中其实有一些非常简单的实现，比如说做 365 个队列，每一个队列里面放有类别检测框的图片，在训练的过程中，每次均匀分布的从 365 个队列里取图片，这是当时非常简单有效的一个方案。具体实现最后会有一个链接，包含一些加入这个数据后的开源实现。

加入这个方法之后，下图可以看到从模型的精度和收敛速度上都有一个比较明显提升，这边列的是 MAP 的指标。通常做竞赛的话，比较建议大家去做一个 evaluation server，就是专门定期的拉取训练过程中的结果，跑一下 MAP 值。因为往往在做检测任务中，loss 不太能直接反映 MAP 最终的结果，所以比较建议大家去是做这样的 server，对于看这个模型收敛有比较大的帮助。

注意看下图，刚才说到加了 NAS-FPN 和 class aware sampling 之后， MAP 就达到了 25，之后再将 resnet50 替换为一个非常强的 backbone：SENet154。加上一个 group normalization 的操作， group normalization 也是一个比较常见的方式，通常在训练目标检测的时候，如果 batchsize 比较小，只能用一个 fix 的 batch normalization 这样一个操作，但是如果说 batchsize 很大，开启了 batch normalization 的操作来同步的计算 bn，通常 batchsize 可能要大于 32 或者更多。这里的 group normalization 是没有加载 backbone ，就是 SENet154 用的还是一个 fix bn 的这么一个状态，GN 主要是加在 FPN 以及 cascade 的后面的那几个 hidden 上。加上这样一个操作，指标会有一个比较明显的提升，达到了 30.1。

此外又加了些常规的操作，OHEM 和 Deformable 操作。OHEM 有一些开源的实现，包括现在 mmdetection 实现度上是比较完整的。当时 Deformable 包括两种，一个是 Deformable conv，一个是 Deformable  LYpooling。在实际操作中，我们发现 Deformable  LYpooling 相比于 Deformable LYonline 来说提升更明显，而 Deformable conv 在 C3、C4、C5 加上去之后，提升并不是特别明显，这个也可能有实验的问题。

下图右边是 OHEM， 一般在两阶段里面用的会比较多，在 RPN 之后有一个 proposal 会提前去看一下，最终的 grounding box 的 loss 和分类 loss 的结果，基于这个结果，考虑把两个 loss 值加到一起进行排序，然后再送到第二个 stage 做细粒度的回归时，就可以只取 topN 的结果。通常来说在 COCO 这样标注标准的数据集下是非常有用的。但相反在 open image 这种缺少一些数据标注的情况下，往往就会造成 rpn 出来后却发现 ground truth 里没有该类别。那么 OHEM 反而会起到一些有害的作用。

除了 OHEM 之后，还考虑加了一个把图片分辨率放大，即 LY 的分辨率放大。考虑到这个操作主要是在最终预测的时候，把图片分辨率放大。所以即便训练的时候，没有将图片分辨率放大，预测时把它放得很大，也是有比较明显的收益的。加上很多物体框标注的是比较密集，希望它在做第二阶段 box head 时更细粒度的回归能保留比较多的信息。另外一方面把 7×7 的 LY 之后的结果改成 9×9 之后，之前 4 个 3×3 的 conv，感受也会相对差一些，所以就额外加了一个 3×3 的 conv，然后接上 GN 加上 conv, 这个操作的效果是比较明显的。当然如果大家有条件的话，batchsize 调大，用个 sink BN 的操作，可能效果会更理想的。

加上这一个更大的 resolution head 后，指标大概从 30.7 提升到 30.9，大家可能觉得提升不是很明显，但其实在 object365 的数据集下，指标有 0.2 的提升，是一件很不容易的事情了。包括今年的结果，虽然数据集加了很多。但目前来看，估计大家指标最后还是在 30 上下，很难达到 40 这么一个状态。

另外一个调整的策略是基于 cascade RCNN。cascade RCNN 大家可能已经比较熟悉了，会有一个多 stage 的方式。其有很多实现的方式，参考 detection 的实现把最终预测出来的第三个 stage 的框，重新去过一下 H1、H2、H3，前两个 stage 的 conv 拿到它的分数，基于这三个分数求平均，有点类似于得到一个最终的分数。

基于 detection 结果的框架做了一些改进，因为在训练的时候，每一个 stage 拿到的框的分布是不一样的，比如说在 H1 的时候，往往拿到的这个框就不是很紧致的，到 H3 的时候，拿到框通常来说比较紧致，IOU 已经很高了。所以在预测过程中应该是保持跟训练过程中同样的方式，重新让 head 的部分在预测的过程中，去预测符合训练过程中的 box 的分布，拿到这个分数再做平均。

当时也是把这个做了一些修改，大概也是有一个 0.2 的提升，可以看下图。

基于这样的一个结果，最后又做了一个 multi-scale 的 training 跟 testing，有一个非常稳定的提升，但是非常浪费算力的，如果开了 multi-scale 的 training 和 testing，往往这个训练时间可能至少要一倍以上，才能让这个模型完整地收敛。当时在 validation 集上拿到的最好的 single model 的指标 MAP=33.1。

这里面再说一些细节，第一个是在 coco 上 pretrained model，这个 model 是一个 cascade mask rcnn，将 mask 分支砍掉，MAP 大概是 52.9。COCO 数据只有 13 万，object365 有 68 万，13 万的数据相比于 68 万的这样一个数据，还是有一些贡献在里面。当时事实也证明，它至少在收敛速度上还是有起到一定帮助的。而今年 object365 数据集已经到 170 万了，很有可能 coco 数据集已经没有什么太大的帮助了。另外 training scale size 一般短边变化是从 400 到 1400，长边不能超过 1600，这是当时在训练时的设定。

这个设定也有个前提，当时用的是 32g 的显存的 v100，其实过了一年，现在好像显存最大的基本也还是 32g 的 v100。因为在训练的时候，可能还要考虑一个 batchsize 的问题，希望单卡的 batchsize 能是 2，这样的话一台机器如果是 8 卡 v100 的话，batchsize 就能到 16，有两台机器就能到 32。batchsize 大一点，训练还是能快一点，这里面还是要遵从 learning rate scale  rule。batchsize 越大，learning rate 相对来说也要放的更大，然后总的 step 数量可以减少，过的 epoch 数量保持一致，这也是前两年 Facebook 的一篇 paper。如果大家看一些开源的 Faster RCNN 都是遵循的设定来做，这样还是能比较有效的减少一些时间。

最终 testing 阶段 max size 的设置的是 2100，在 test 阶段图片还是越大越好，我们只做了 2100，因为再大的图片显存就爆掉了。然后这可能跟框架有关系，如果框架优化的好，batchsize 可以再大一点。还是比较建议大家如果条件允许的话越大越好，当然看他们有人说 v100 确实做这种大规模的通用物体检测，它都是一个非常吃计算资源的。当时我们用的是一个 8 卡 v100 32gb 的，用了两个，当然我们实际同时在跑的可能还不止这两台机器，可能会有五六台一起在训练，因为要去尝试各种各样的策略，要去做各种相关的实验。当然大概一周的时间，从从一个 coco 的 pretrain 去完整去训完 object365 的结果。

下一条是 weight standardization, 这是去年一篇 paper，因为当时打比赛的时候看到这篇 paper，它是要跟 GN 去做一些组合的，具体操作其实就是在这个 GN 之前，对 Weigh 做一个简明除方差的操作，其实当时也没有太多时间去思考，是否有效。只是觉得说因为在做比赛，要看一个最终的结果，自然免不了要做各种各样的模型的 example。事实证明当然加了之后简单的去训一下，在做 example 之后还是有一些效果的。

最后 NMS，这边是用了 SoftNMS，其实现在 NMS 方法很多，有很多比 SoftNMS 更有效，速度也更快的方法，大家也可以多去尝试一些，因为这种后处理的方式其实提升指标还是比较直接的，就是减少很多去训练的时间。

最后 example 了 5 个模型，其实并不多，但是确实是计算资源比较有限，example 了 5 个模型之后，最终的指标在 validat 集上是 36.5，还是有挺多提升的。像这样的提升认为还是整个类别太大了，Object365 类别太多了，365 类，其实在 coco 上觉得很难 example 三个多点的这样一个提升。

这里是一些当时最好的 single model 的一些 visualization，可以看到，其实效果还是蛮好的，但是也能看到一些误检和没有检到的东西，比如说纰漏，像重叠比较大的情况下，它就没有检到。后面其实还有一个，但像左边它就检到了。

下面是另外一张图，包括看后面这个人，他身上这边可能是一个手表还是什么东西，检测的还是比较准的，当然这个都非常依赖有一个非常大的分辨率的这个图片放到网络里面，它才有可能去看到。

简单说一下 Tiny track。因为 Tiny track 今年的比赛里面并没有了，其实也非常理解今年为啥没有，因为从去年结果来看 Tiny track 拿到比较好名次的这么的前几名，基本都是要在 Full track 上有一个非常强的 pretrained model。其实也另外一层说明了 Object365 数据集它有它自己实际的意义，从另一方面来说，Tiny track 因为它最终划分数据集的时候，它就属于 Full track 的一部分的子集，一张图片里面在 Tiny track 里面只标注了这 65 类，在 Full track 里面其实这张图片里面其他类别它也是被标注了的，如果只用 Tiny track 这个数据，其实就比较吃亏了。

下面有一个表格，可以看一下。如果 Tiny track 仅仅用一个 coco pretrain，在 Tiny track 上的 validation 上了 MAP 大概是 28.9，如果这会用一个 Object365，就是完整的用 Full track 的数据集，结果一下就到 33 了，这一下就是 4.1 个点的差距，这 4.1 个点的差距，如果不搞 Full track 的话，其实是非常难通过其他方法来得到一些提升的。

画红框的这块是想说明如果在 Full track 上，拿到了一个更好的 pretrained model，因为随着时间推进， Full track 的稳定性的效果会越来越好。当达到 32.9 的时候，再在 Tiny 的 validation 上去做一个 fune tuning，发现又高了一点多个点，等于在 Full track 上高了 2.2 个点，然后在 Tiny track 上还能再高 1.8 个点，这跟 COCO 来比已经是差了 6 个点了。最终在 Tiny track 上没有花太多的时间去做这个 track，当时也是一直在做 Full track，所以在 Tiny track 这个上面，最终就是简单的把每一个 Full track 上的模型在 Tiny track 上去 fune tuning，之后再做 example。

example 涨点的并不多，因为当时在这 Tiny track 做的比较晚，大概是最后一周到两周，因为 Tiny track 训的很快，几个小时能训完，大概是涨了 3 个点左右，2.8 个点。但是最后 Tiny track 没有拿到第一名，只拿到第二名，Tiny track 的结果并不是太理想，最后在 test 这集上是 29.0，好像跟第一名差了 0.1，其实当时如果 Full track 出来的效果可能更好一点，或者是多在 tiny 上研究一下长尾工作的一些问题的话，也许能做的更好。

另外当时也同样用了 multi scale 的 input，还要做一些 flip，在 training 跟 testing 之间。如果做 multi scale 的 flip 和 testing，速度比较慢，往往预测一遍，可能都要一晚上或者一天的时间，整个时间花费比较久。

当时用的框架是百度开发了 PPDetection ，如果大家有兴趣也可以用一下，这上面有一些我们去年开源的一些模型的结果和一些 pretrained model，大家有兴趣可以扫码看一下。

最后有一些 tips，主要从下面几个方面来说。

第一个是数据预处理，觉得如果参加这样的一个比赛来说，其实是需要花费比较多的时间在这个数据的。因为 Object365 这个数据集，它和 COCO 数据集是非常像的， COCO 可以认为是 Object365 的非常小的缩影，通常来说数据标注的标准是一致的话，在 COCO 上有效，通常在 Object365 上也会有效，可是大家也知道就是在 COCO 数据上每年有这么多研究人员做 research，但每年实际提升的点并不多。比较有说服力的一点，比如说大家可以看一下今年 coco 的检测 detection track，目前已经没有很多人刷了，但是第一名必然还是用了很多今年的新方法的，但可以看到最终的结果，并没有去年理想。coco 其实每年做的创新很多，所以很难在一个月之内做出创新，当然能有最好。如果想在短时间内做一个比较有效的提升，还是要在数据上多下一些功夫。常见的操作有：data augmentation，或者 data balance，为什么这么说？object365 和 coco 比较明显的区别，主要就是类别和数据量，在这个空间上做 data balance 效果非常明显的。建议大家去看一看 data balance 其他的论文，关于做数据均衡的，可以参考一下做 open images 如何做数据均衡的。因为 open images 与 object365 数据集有很类似的一个状态。还有一些比如叫 soft balance 方法都可以参考一下。

第二个是 model diversity，其包括两个层面，一个是模型的，像刚才说的，通过调整一下 weight，加上 standardization 做最终的 example。觉得可能用不同的检测的框架来做 example 更有效的。比如说像今年 anchor free 的方法其实发展得很快，很多 anchor free 的方法也能做到 coco 上指标可以做到 50 多，也值得一试。还有现在将 transformer 用到 CV 里面，包括前阵子好像商汤已经发出相关的 paper，在 transformer 上也能做到非常高的指标，如果有条件其实可以去试。

另外一个是 post processing，这些都是不需要训练模型就可以做的一些事情。同时大家也可以去看一下最新的 NMS 的方法，包括一些做 instance segmentation 里面的一些方法，都可以相应的调整或者修改一下，应用到纯检测中。看有同学问去掉 NMS 操作，其实对这方面的操作，看的比较少，之前其实有试过 relation network ，其实相当于通过一个端到端的方式，把 NMS 这种操作去掉，让它整体是端到端可以训练的，但是结果并不是特别理想，包括从 paper 中的指标也能看到。而且在 NMS 上，其实每年都还是有发展的。当然现在有 tranformer 方面之后，可能情况又不一样了，在这上面目前来说没有太多研究了，所以这块也确实不好说。但是从之前来看， 想用一个端到端的方法把 NMS 去掉，还是比较难的。

然后再说算力这个问题。其实大多数参赛的同学，其实算力都还是比较有限的，所以建议大家对算力有一个合理的分配。根据算力去调整尝试的方法，如果算力很少，就尽量去减少模型的训练，多去尝试一些预处理和后处理的事情。如果算力非常丰富，建议去做这个叫 expert system，即专家系统。这个大家可以看 2018 年的 object365 的亚军和去年的 object365 的亚军，他们就是采用的这个方法。专家系统是首先把 365 类别划分开，类似 Tiny track 一样，然后每一个模型去训练它其中的一部分。当然这个数据怎么划分，它是有一个比较讲究的地方的。

具体大家可以去看一下这个论文，把整个数据集去划分成多个子数据集之后，每一个模型 capacity 所需要承担的任务相当于就变轻了，等于每一个模型只需要把这个人检测好，或者把这个狗检测好，就完成任务了，这就是专家系统这么样一个概念。这样每一张图片过来，可能每个专家都会有一个自己的结果，最后再通过融合这些结果，大家一起投票，从中得到一个最终的一张图片上结果，可以看到它专家系统提升还是直接非常明显的。如果有算力这肯定是一个好方法。觉得这个对做这种大规模的数据是一个蛮不错的思路，尤其今年数据有非常大，如果有算力还是非常推荐，但我们当时还是用一个 one model 来搞的，一个是算力的问题，其实主要就是算力的问题。如果没有算力或者再多一点的人力，其实我们也会尝试这样的方法。

另外一个就是经验，去年参加参赛的时候就会出现一个问题，大家了不了解 coco 的评分标准。其实每张图最多只能提交 100 个框，超过 100 个框，后面的框就不算了。但即便是在这样的情况下。由于 test 数据集太大，跑下来的所有结果后再去做一次 example 过程中还有个问题，是因为 example 通常我们去年用的还是 softNMS 有一个特点，它会把框保留，把分数砍掉，但不把框扔掉，会把框保留。就会造成框会很多，当然这个毕竟还是有效的，还是保留了。这样会造成什么？即便有一个每张图片 100 个框的限制，最后 example 出来这个文件结果也会特别特别大。可能去年的话，印象中一个提交文件大概要 1 个 G 到两个 G 之间，在 Full track 上差不多这样一个情况。这导致提交到这个系统里面去，会发现每次提交结果都不成功，当然返回的都是一些乱七八糟的错误，就是说格式有问题这种，当时也是费了很大的劲联系到了平台，当时也没几天了，连夜去查到底是什么问题？因为觉得我们格式没有问题。

查了半天，最后发现是说这个文件太大了，它们在解析和在判断、判定计算 MAP 最终结果的时候，它们的 CPU 的内存是 out of memory 了。其实因为当时看也看到除了我们队，还有很多其他队也有这个问题，这就不得不说一下，其实评测的平台还是蛮关键的。比如说我们之前做 open images，它是在 kaggle 上面，我们个人认为这个评测过程可能是一个分布式系统，它可以在非常短的时间内，几分钟就把一个非常大的文件处理完了，如果这东西放到本地拿一个非常好的机器跑，可能都要跑很久，跑好几个小时，在这个网站上可能几分钟就给结果了，这是非常难的一个事情。

所以建议大家也要注意一下文件的提交大小，也建议主办方去关注一下这个问题，主要是平台的问题。

我们这边也是在持续地做一些招聘，现在是好未来的 AI 中台视觉部，包括的方向有很多，几乎涵盖了所有的视觉方向，包括物体检测、分割、人脸的，还有一些 GAN 相关的，也会做一些很多虚拟形象的，包括图像的、质量的。另外一个大方向就是 OCR，OCR 也是在教育场景下运用非常广泛的这么一套 CV 技术。大家如果有兴趣的，不管是社招的，或者 researcher 有意愿做论文研究的，做比赛的，或者是一些实习生，这边都是非常欢迎的，大家可以把简历发给，邮箱就在下面，[email protected]，大家也可以扫这二维码去看一下招聘网站。

End

如需配套 ppt，请通过公众号回复关键词 “ppt” 或点击对话框工具栏按钮获取。

本文校对、编辑：lyy、林檎、郑然

数据实战派希望用真实数据和行业实战案例，帮助读者提升业务能力，共建有趣的大数据社区。

扫描二维码 ｜ 关注我们