一切都是为了更顺滑！

五福已五年陈。除去第一年采用咻一咻方案来完成集福，还未引入图像识福的方案外，今年已是 AR 扫福链路作为识福入口的第四年。有的同学会问，我去年就已经觉得扫福非常顺畅、识别非常准确了，为什么今年还要继续升级模型呢？这让我想起逍遥子在双十一战场上的一句话，"今年双 11，我最关心的不是销售数字，而是技术峰值"。而对应在扫五福的场景上，如何让用户在 AR 识福的体验上更加顺滑、如何在极低配的手机客户端上依旧可以流畅地扫出福来、如何将端上计算的覆盖率触达更多的用户甚至接近100%，这是我们每年必须要去刷新、去突破的方向。

往年的沉淀

在过去三年扫福的视觉算法侧，我们可以总结为两次突破。第一次突破，来自 18 年 xNN 深度学习引擎的引入，支持了识福深度学习网络在端上的运算，显著降低云端服务压力的同时，更大幅提升了识别算法的精度；第二次突破，来自 19 年云端服务完成了 xNN - x86 版本的升级，使得在端云结合的方案背景下，真正地实现端云一体，端上与云上模型完全统一。技术上的突破，带来体感交互更加流畅、识别结果更加准确，就像下面的动图，如果 17 年他可能还是位"漏洞挖掘专家"，但在 18 年以后再想"偷袭"，恐怕就很难了。

今年的突破

今年为了在用户体验侧、研发流程侧更加顺滑，我们引入了 AutoML。不仅是对训练超参与网络结构的搜索，也是对于整个模型研发流程的自动化。原因可归为如下两点：

网络性能阶越式提升，人工成本高

今年在历年基础上，为了端侧计算触达更多用户、端上资源消耗更低、识别效果更准，我们需要网络模型性能完成进一步的阶越式提升。然而当历年模型已经达到不错的基准水平时，再想单靠人工设计，使得模型性能、精度大幅提升，是需要付出更大的精力与人工成本的。

KA 商户需求、舆情需得到更快速响应

随着 AR 扫商业化的丰富，对于福字识别链路的模型结果，也要快速兼容与满足 KA 商户定向识别的个性化需求。并且对于扫福这种全民参与的活动，遇到识别舆情，快速迭代模型的应急能力，是对于扫福这种活动必须具备的能力。我们需要尽可能地缩短模型迭代的周期，所有的操作、时延、训练时间都是标准可控的，强化模型迭代的应急快反能力。

网络结构设计的自动化

AutoML 能力特性

我们采用了 xNN-Cloud 平台提供的 AutoML 能力，来完成今年福字模型的结构搜索。那么它必须具备如下一些特性：

1）是开箱即用的。在原生的网络结构代码上，无需改造很多，即可使得网络支持搜索。

2）是能够兼顾到端侧指标的。在比较不同搜索实验结果时，不局限于精度，计算量大小 / 参数量大小 / 耗时等因素，也要一同考虑进来。

3）用户交互是友好的。用户只需要关心搜索过程是否符合预期，搜索结果指标是否可以快速比较，而具体的资源调度、GPU 使用等用户无需关心。

下图展示了在 xNN - Cloud 上的一个 AutoML 任务搜索过程的流程图示例，以及指标结果在搜索过程中的动态变化过程。

网络与空间设计

识别链路

检测模型先定位候选目标区域，再由识别模型，来判别区域是否为福。由于检测与识别网络分开，从而遇到定制识别需求(比如识别马老师福)需要模型快速迁移的场景里，可以维持检测模型稳定，只需要在识别模型上进行迁移训练，而不用连带检测网络一同更新。因此总体上，我们有检测与识别两个模型，均需要进行 AutoML 结构搜索。

引入先验

AutoML 搜索，如果训练资源足够多、时间跨度允许足够长，我们会愿意给予机器尽可能多的*，从而可以在更复杂的空间内进行搜索。然而对于扫福这种业务场景，每年从各部门抽同学组成一个临时的集体，到模型参与测试联调，无非一个月左右的时间。而在这么短的时间内，需要对两个网络完成结构搜索。并且还要保证参数量、计算量比往年模型更小，精度比往年更高。因此，我们对于网络框架上，基于在其他相似业务积累的经验，做了一些先验上的选择。

检测模型

我们从单阶段检测器(SSD)结构出发，增加了 Pyramid Pooling Network(PPN) 的结构，用于在不增加额外参数的情况下，快速获取不同尺度空间上的特征。并且在框位置/类别的回归分支上，使用了权值共享卷积，来将不同尺度上的信息特征，使用相同的权重进行学习，使网络能够对不同尺度下的目标，都有较好的表现。在此基础上，我们以 MobileNet V1 结构为初始 base network，搜索各层的通道宽度以及卷积核大小，并且为了预测 head 可以与 base network feature 匹配的更好， shared tower 回归层的通道宽度，也加入到搜索空间当中。从而使得网络的特征提取与预测 head，在福字检测这个场景均达到最佳适配。

识别模型

我们从 MobileNet V2 结构出发，并且参考 EfficientNet 的方式，在一个较小的网络下搜索，然后通过网络宽度、深度、输入大小的 scaling，来使得基于小模型上搜索出的优秀结构，可以快速扩充模型的容量。并且 Google 的 Searching for MobilenetV3，也是以搜索的方式在 MobileNet V2 基础上，将移动端识别模型做到更加极致。后文也给出了我们 AutoML 的结果与如果直接使用 MobileNet V3 结构的结果比较。下图中展示了，最终结构搜索得到的检测与识别网络结构。

搜索目标

伴随着 AutoML 的搜索过程，会涉及每个 Trial 的结果好坏比较。从而选择相对更优的结构，去进一步在此基础上搜索或者训练。比较的目标基准，在扫福这个任务上，我们要考虑的不仅仅是精度。因为模型最终要在客户端运行，模型的计算量 (FLOPS)、模型的参数量大小 (Model Size)，也会成为我们必须关注的指标。因此，在指定比较基准时，我们设计了一个将多种因素同时考虑进来的方式，来对比 AutoML 过程中的不同 Trail。其中 T_f 和 T_s 是期望的目标值，w_f 和 w_s 是用来控制 FLOPS、ModelSize 与 Accuracy 之间的一个 trade-off。

搜索策略

由于搜索资源一定是有限的，因此我们选用了资源消耗、搜索效率上相对最优的 Hyperband 算法。该算法让前序搜索的 Trial，先训练较少步数后比较目标函数，然后从中逐级选择较优的结构，再使用更大的步数进行训练，从而能在搜索结构的训练步数和整体资源之间找到一个平衡。同时为了防止陷入一定概率的局部最优解，在选择首次随机的参数空间时，也会采用多级随机选择。从而整体来看，在保证随机性的同时，也保证了较优结构训练更大步数，最终得到收敛情况最好的模型。

在搜索算法实现上，xNN-Cloud 与蚂蚁人工智能部 ALPS 团队合作，完成了 ALPS-AutoML 框架 Python SDK 的集成，其中超参搜索算法部分，支持 grid、random、bayesian、racos 等各种超参搜索算法；也支持 hyperband、medianstop 等 EarlyStopping 机制；支持灵活的超参数组合配置。同时 ALPS-AutoML 在机器学习其他场景，也支持 xgboost 模型的元学习、高效的自动特征工程等非常丰富的自动机器学习能力。

模型性能

速度更快，大小更小，精度更高

安卓客户端上以 19 年的 top50 机型、ios 客户端上以 19 年的 top20 机型，来作为对比两年推理耗时的基准。从去年和今年的真实线上环境数据来看，安卓平台上相比去年降低了50%以上，平均耗时达到了 100 毫秒内；ios 上降低了 30% 以上，平均耗时40毫秒以内。模型大小上，较去年进一步减少 80K。在耗时、参数大小都比去年更低的情况下，精度较去年进一步提升了 1.6%。这些均来自于在 AutoML 搜索过程中，对于精度、参数量、计算量的综合考虑，使得搜索得到的最终模型结构，可以在这三方面，均得到兼顾。

识别模型 vs Mobilenet-v3

我们也将搜索出的识别网络结构，与 Mobilenet - v3 结构，在福字识别场景做了对比。可以看到当计算量相差不大时(mnv3-small-065)，我们 NAS 得到的参数量大小只有 mn-v3 的结构的 1/10。然而对于集五福这种对端上资源大小，也有非常严格限制的业务场景上，原生 mn-v3 的模型大小明显是不合适的。而如果为了尽量减小mn-v3的模型大小，将一些 advanced blocks 舍去，并且将宽度倍率进一步降低时 (mnv3-small-minimalistic-025)，模型计算量的确会进一步减少，但是精度上会引来非常明显的下降。因此，这也进一步证明了福字识别 AutoML 搜索结果，对于精度、计算量、参数大小综合考虑的有效性、以及网络对于业务场景的更高适配性。

P.S. 上述表格中展示的识别精度，为线下 9 万张测试用例在 threshold = 0.9 下的图像级精度。在业务场景实际调用时，是基于视频流识别的方案，会有多帧结果的融合与校验，使得总体的线上识别精度几乎趋近于 1。在整个扫福活动期间，没有引起任何规模化的识福舆情的产生与传播。

算法研发流程的自动化

平台基础

xNN-Cloud 提供了一站式视觉算法研发的能力，提供了丰富的功能与算法开发特性(如上图)，这也给扫福模型研发流程的自动化，提供了巨大的便利与帮助。

算法开发

内置标准的分类、检测、OCR 等算法包模板，且配合参数配置，无需任务额外代码的情况下，就可以训练得到优质的模型。有定制优化需求时，仅需完成 Common API 的几个抽象接口开发，即可将自定义的网络结构、损失函数、优化方法等，应用在模型训练当中。

模型压缩

配置化的模型压缩能力，极大降低用户感知模型压缩能力的成本。集成的 xQueeze 模型压缩工具链，提供强大的自动剪枝、模型量化、定点化的能力。

数据预览

不局限于看标注结果，同时可以结合模型在数据集的评测结果，做到更多维展示。如分类任务，可以快速查看预测类别与 GroundTruth 类别之间的交叉结果；检测任务，能够直观展示多组预测结果与 GroundTruth 之间的 IoU 情况。

多机多卡

尽可能降低用户使用多机多卡能力的复杂度。通过接入 Kubeflow MPI Operator，帮助用户轻松运行分布式训练。不管在哪种算法场景类型上，用户仅需要选择卡数，即可使用上多机多卡的训练能力，而无需将额外精力放在代码如何在多机上运行起来的、各卡上的梯度是如何汇总更新。

模型评测

整个扫福期间，自动化训练产出上千个模型。如何快速地从这些模型中，选择出较优的那个，是能够大大减少时间成本的。通过评测，可以观察到在独立测试集上的精度结果、PR 曲线等。而且可以将多个模型的结果，放置在同一个面板当中。

真机测试

模型要在客户端侧运行，除了模型大小以外，也需要耗时、CPU/内存占用等指标，来判断模型是否满足端上的运行性能需求。通过接入 EdgePerf 与云测平台，快速实现真机上的模型实测，提供真实、直观的运行性能指标。

模型快反

五福活动期间，如果模型上线之后，根据用户实际扫福的情况，发现需要增加对于定向类别的识别。并且产品还希望在 1 小时内模型能上线。从数据组织到模型训练到格式转换再到模型评测，如果有一步不小心人为操作疏漏了，会有很大风险耽误模型的更新上线时间。然而借助将整个数据准备、训练、评测流程，全部平台化、自动化，那么可想到的犯错机会，与人为离线训练相比，将大大降低! 从而完成在特殊业务需求下的模型快反。

在扫福模型上线之前，我们在 xNN-Cloud 模拟了根据定向图片类型，进行模型快反的训练流程。只需要将定向识别的数据集上传之后，克隆之前的模拟训练任务，并且将新的数据集添加进来，再加上平台提供的多机多卡的能力，从而最终模型训练过程，可以控制在 15 分钟以内。不仅保证了模型结构、大小与预期完全相符，识别结果上也在保持原先其他类别不受影响的前提下，增加了对定向图片的识别。整个过程全部在掌控之中，不再有人为失误的可能，只需要交给平台。这个能力也在鼠年马老师福、商家特定福识别的迁移训练上，得到了应用。在很短的时间内，就在基准模型基础上，迭代出了最终上线的版本，完成模型的快反。

结语

扫福模型的训练，依托于 xNN-Cloud 平台，今年在节省大量人力的情况下，产出了比往年都要更优秀的模型。这离不开 xNN-Cloud 平台提供的 AutoML 与自动化训练的能力。目前 xNN-Cloud 也在将真机测试与搜索过程直接打通，用最接近真实环境的运行指标，指导 AutoML 的搜索。

更多关于 xNN-Cloud 平台，可点击阅读：不写一行代码，完成机器视觉算法的研发