Press "Enter" to skip to content

AutoML 应用探索:如何让 AR 扫福更顺滑?

 

小叽导读 : 2020 年的新春集五福圆满结束,在 AR 扫福的视觉算法研发上,今年完成了 AutoML 的全面落地。借助 xNN-Cloud 平台,实现了网络结构设计的自动化,也完成了研发迭代流程的自动化。在极大节省开发人力成本的同时,模型精度在去年基础上进一步提升1.6%,Android 平台模型推理耗时减少 50%,ios 平台减少 30%,给用户带来更加极致顺滑的扫福、识福体验!整个活动期间,模型在客户端 xNN 引擎的推理次数达到数千亿级别。

 

写在最前

 

下面通过一个两分 钟的视频,来带大家快速了解,”自动化”是如何贯穿在 2020 扫福模型的研发当中的。

 

 

一切都是为了更顺滑!

 

五福已五年陈。除去第一年采用咻一咻方案来完成集福,还未引入图像识福的方案外,今年已是 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 的搜索。

 

Be First to Comment

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注