随着机器学习，尤其是深度学习在复杂数据上的表现越来越优秀，很多开发者希望能将其应用到自己的服务或产品中。然而即使是使用预训练模型或开源框架，对于很多不太了解机器学习算法工程的开发者而言还是有非常大的挑战。此外，若机器学习不是产品的核心技术，额外维护机器学习算法团队的成本又非常高。因此，很多时候我们需要一种能快速使用高性能深度学习的方法。
从整体而言，构建我们自己的机器学习应用首先需要收集数据，并执行复杂而繁琐的数据预处理，随后如何选择模型与各种层出不穷的修正结构也非常困难。在训练中，需要经验的调参过程与各种技巧也会对模型性能造成影响，更不用说需要根据数据情况选择与修正最优化方法了。因此即使不考虑工程化问题，将机器学习模型部署到客户端也有非常大的成本。
其实目前在 GitHub 上有很多优秀的机器学习开源项目，例如各种预训练深度卷积网络、高度封装的算法以及大量开放数据集，不过要想复现以及根据实际情况调整这些项目，开发者还是需要一些 ML 领域知识。此外，很多项目的文档说明与技术支持都有待提高，它们需要开发者一点点调试与试错才能正确搭建。更重要的是，将训练后的模型部署到移动端等平台会遇到非常多的困难，这主要还是当前流行的深度学习框架并不能完美支持模型部署。
所以对于不太了解 ML 的开发者而言，最好将上述这些过程都自动化。例如我们只需要收集少量和任务相关的数据，并直接在平台上完成标注，然后让系统帮我们选择合适模型与超参数进行训练，最后已训练模型还可以直接部署到云 API 或打包成安装包。其实现在也已经有一些平台能完成这一些过程，例如谷歌的 AutoML 和百度的 EasyDL 等。
EasyDL 主页：http://ai.baidu.com/easydl/
如下所示为 EasyDL 训练模型的基本流程，整个过程都是图形化操作，且如果是上传已经处理好的数据，那么强大的迁移学习系统会在几分钟内完成模型的训练。百度 AI 开放平台文档中心对 EasyDL 的建模过程有详细的描述，因为这一图形化的系统非常简明，所以文档也通俗易懂。
如上所示，EasyDL 将整个服务精炼为四个步骤，并且可以在不需要机器学习背景知识的情况下开发模型。创建模型只需要选择我们任务所属的类别，例如图像分类或目标检测等。训练模型只是选择我们创建的任务与数据，再点击训练就行了，系统会自动搜索各种模型架构和超参数。最后上线模型同样也只需要确定到底是获取云端 API 还是离线 SDK，整个过程不会涉及到复杂的算法与工程方面问题。
EasyDL 在 2017 年 11 月初上线了定制化图像识别服务，并在业内展开公开测试。在 2018 年 4 月、5 月和 7 月陆续发布了定制化物体检测服务、定制化模型设备端计算和定制化声音识别等多个定制化能力方向，并形成了从训练数据到最终定制化服务的一站式端云一体平台。目前 EasyDL 的各项定制能力在业内广泛应用，累计过万用户，在包括零售、安防、互联网内容审核、工业质检等等数十个行业都有应用落地，并提升了这些行业的智能化水平和生产效率。
主要技术手段
EasyDL 的主要优势在应用案例的累积、简明的产品设计与操作流程、支持移动端计算与部署等，而支持这些优势的是 EasyDL 背后各种主要技术手段。例如 AI Workflow 统一大数据工程系统与分布式训练系统，为 EasyDL 提供稳定的系统和流程支持；采用 PaddlePaddle 作为基本框架，为模型的搭建提供基础；采用 Auto Model Search 自动搜索模型超参数，支持获得更好的训练效果；采用迁移学习训练较小的用户数据集，从而大大加强训练效率与效果等。
AI Workflow 与 PaddlePaddle
AI Workflow 是百度对机器学习从训练到上线构建的工作流引擎，它是一个将大数据成熟的工程系统与人工智能分布式模型训练相结合的引擎。它覆盖了从训练数据的存储，ETL（抽取、交互转换和加载）、模型训练任务的发起、训练集群资源调度、训练状态监控同步、模型自动部署、服务发布上线等全部环节，并实现了全自动流程。
总体而言，AI Workflow 的主要流程可以分为四个阶段。首先第一阶段是对数据进行预处理，例如对图像实现归一化、大小裁剪与数据增强等。随后第二阶段是模型的训练，或者说是学习过程，这一阶段会基于百度研发的深度学习框架 PaddlePaddle 进行分布式训练。训练完模型后，第三阶段就需要验证模型的效果，也就是说用户可以上传小规模的测试数据，并对模型的召回率与精度等指标进行验证。最后第四阶段为服务的上线或模型的部署，在这个过程中我们可以将已训练模型加载到云端并对外提供服务，也可以打包为一组移动端开发套件，为进一步集成到其它任务中提供接口。
整个 AI Workflow 在系统层面和服务层面同样也会有一些优化，例如 PaddlePaddle 团队会对模型的训练阶段做很多优化，包括 GPU 的内核融合和利用 RDMA 优化分布式训练等。而 EasyDL 团队这边也会在服务层面做一些优化，例如在推理阶段中，他们需要优化任务调度，并加速模型推理速度。
在 AI Workflow 中，整个训练和推理阶段都是使用 PaddlePaddle 框架，它包含了许多高性能的模型算法实现, 为最终出色的效果提供了强有力的支撑。虽然 EasyDL 的用户不需要了解与使用 PaddlePaddle，但其多年的 AI 技术积累以及大量的业务使用验证，使得框架对于各种任务都非常安全稳定。
此外针对于移动端部署，Paddle-Mobile 设计之初就对嵌入式的性能、体积、能耗、硬件平台覆盖等方面做了考虑。而 EasyDL 的端计算版本也是使用该框架设计更紧凑与高效的模型，并将其发布到移动端。
自动模型搜索与迁移学习
目前 EasyDL 采用了 Auto Model Search 的算法，即系统会同时发起多个模型结构和超参数不同的训练，并采用对应算法进行最终模型的筛选，从而确保更优的模型效果。Auto Model Search 与后文介绍的 AutoDL 在功能上是相近的，但百度的 AutoDL 是一种神经架构搜索方法，它关注于利用强化学习从头构建神经网络。
Auto Model Search 是指对于同一方向的定制能力，也就是说它会采用多个经典模型以及不同的超参数配置，并分别进行训练。然后再按一些策略挑选出比较好的结果，并完成模型的上线。其中系统可调的超参数包含神经网络类型的选择，例如对于图像分类可以选择 Inception、ResNet 或者其他。而对于每一个模型，可选的超参数包含批量大小、迭代数量和卷积核大小等。在确定模型架构，并配置完超参数后，每一个单独的模型都会并行的训练，并按一定策略选择效果最好的模型。
其实 Auto Model Search 是针对特定用户数据的，在用户上传与他们任务相关的数据后，EasyDL 会抽取多个已训练深度网络，并采用迁移学习和不同的超参配置精调这些深度网络。如下所示在用户确定好小型数据集后，EasyDL 可能会选择 Inception v3/v4 和 ResNet 等，在固定这几个网络前面层级的权重后，系统会根据用户数据以及不同的批量大小和学习率训练网络。
EasyDL 大量采用了迁移学习技术，各种基础模型会在百度大规模数据集上进行预训练，并将从中学习到的知识（Knowledge）运用到用户提交的小规模训练数据集上，从而实现出色的模型效果和快速的模型训练。迁移学习的主干是非常大的网络，而一般我们每一类只需要使用 20 到 100 多张图像就能完成对后面层级的训练，且 EasyDL 也会采用 Early Stopping 等正则化手段降低模型过拟合的风险。
图像的迁移学习可能比较好处理，但 EasyDL 的声音分类并不需要太关注序列上的长期依赖关系，因此它也能使用迁移学习。声音分类的迁移主要会采用 MFCC 或加上快速傅立叶变换将音频的时域数据转换为频域的图，然后再利用与计算机视觉相类似的迁移方法传递与音频相关的知识。而以后在处理语音识别等存在长期依赖性的数据时，主体模型可能会继续用到其它迁移知识的技术。
此外对于图像方面的迁移学习，如果用户需要区分非常精细的图片或执行细粒度识别任务，那么一般迁移学习主要会获取图像的全局信息，它很难抽取精细特征。EasyDL 其实也能处理这些细粒度识别任务，但迁移效果很大程度上会受到用户数据的影响。因此训练集图片需要和实际场景要识别的图片环境一致，且对于细粒度识别这种具有很多相似图像的任务，用户需要增加更多的训练图像。
最后，为了提升模型迁移效果，EasyDL 会做一些特别的数据增强操作，即增加一些图像以加强模型的迁移效果。例如假定用户希望系统能识别两个类别，并为这两个类别提供了特定的数据，那么系统会自动增加其它一些数据，并作为第三个类别。在训练中，系统不仅需要识别用户的数据，同时还需要识别自动添加的数据为第三类别。
神经架构搜索
EasyDL 即将引入百度领先的 AutoDL 技术，这是一种 AutoML 的技术，它实现了深度学习网络结构的自动搜索和设计。百度的 AutoDL 是工业界中的一个项目，因此它主要由三部分组成，首先第一部分是从头开始搜索神经网络架构，即神经架构搜索。第二部分是神经网络的自动适配，也就是说根据不同的任务目标与需要进行适配，比如说目标是部署模型到移动端，那么系统就需要考虑正确率、参数量和计算量等条件来适配网络。第三部分是设计网络的迁移能力，AutoDL 希望搜索出具有强大迁移能力的一般性神经网络架构。实际上架构搜索与迁移能力是存在相对关系的，系统花大量计算资源希望搜索到针对特定数据有强大能力的架构，而可迁移性又希望系统找到的架构能推广到其它更多的数据。
在架构搜索策略上，目前比较流行的有进化策略、强化学习和基于梯度的连续空间搜索方法。而百度的 AutoDL 主要是基于强化学习，其核心思路是希望能搜索到尽可能广的空间。为了将神经架构搜索构造为强化学习问题，神经架构的生成可以视为智能体对动作的选择，动作空间也就相当于搜索空间。智能体获得的奖励会根据已训练架构在验证数据上的性能评估而定义。
不同的 RL 方法在表示智能体的策略和如何优化它们存在差异：Zoph 等研究者使用循环神经网络（RNN）策略对一个字符串进行序列采样，该字符串反过来对神经架构进行编码。Baker 等人利用 Q-learning 训练策略，该策略依次选择层的类型和对应的超参数。这些研究，包括谷歌大脑早期提出来的 NASNet，它们都引入了非常强的先验知识。
例如 NASNet 规定了网络实际上有多少单元，这些单元的搭建方式也是手动设计的，系统只需要自动设计单元的具体结构。而设计具体的单元结构也会存在一些先验知识，例如限制单元必须是两个操作输出一个结果等。AutoDL 主要的方向是希望搜索任何有向无环图结构，这样模型的表达能力和搜索空间就远远大于之前的方法。此外由于降低了搜索的先验知识，因此计算力会变得非常大，这也就对强化学习的采样效率有非常高的要求。
三阶段的层级架构表征，组成有向无环图。
除了神经架构搜索，模型的适配也是非常重要的方向。AutoDL 会将很多目标添加到强化学习的反馈值，例如我们考虑一些多任务学习，模型会有一套衡量参数量、计算量与正确率的方法，并最终反馈到强化学习，从而修正搜索方向。
AutoDL 采用的是一种 Hierarchical RL，它同样也是基于 on policy。因为 AutoDL 的搜索空间非常大，系统需要一些结构性的探索，因此搜索空间的探索才回更有效率一些。NASNet 之前第一个版本是基于策略梯度（PG），第二版本是基于近端策略优化（PPO），虽然它们的抽样效率比较低，但它们确实展示了强化学习在这一方面的能力。所以总体而言，AutoDL 主要还是沿着 NASNet 所开辟的方法，并利用其它技术与技巧提高采样效率。
模型部署与设备端计算
目前 EasyDL 有两种发布服务的方式，即生成在线 API 和离线 SDK。从应用场景来说，在线 API 能让开发者更方便地与业务系统整合，因为在线 API 毕竟是 HTTP 层面的接口。而离线 SDK 有更低的调用延迟，对互联网的依赖性也没有那么强，它可以利用本地计算资源实现更安全与稳定的计算。而从技术实现来看，在线 API 是云计算的形式，离线 SDK 是端计算的形式，它们主要的差别在于是不是需要对性能与能耗做权衡。
目前可以实现在 Android、iOS 等系统的 GPU、NPU 等芯片上对定制模型预测阶段计算的加速。
在线 API 的能耗主要出现在服务端，系统不需要做太多的量化或者模型剪枝等优化，模型也不需要做特定的压缩。此外，在线 API 对于芯片端的优化也只需要考虑各种云端 GPU 来做一系列的推理加速。但是移动端的话选择非常丰富，例如可以是针对高通系列的芯片、也可以针对神经网络 NPU 或者针对可插拔的 Intel Movidius 加速卡进行优化。因此离线 SDK 的技术实现相对而言要难一些。
一般对于机器学习开发者而言，在云端训练一个模型，并部署为一个服务已经比较成熟。但将模型迁移到设备端仍然会面临很多困难，开发者需要考虑硬件兼容、能耗与性能等非常具体的问题。EasyDL 在发布离线 SDK 的过程中就已经自动做了很多工程优化，包括对轻量模型的选择和对计算阶段的量化等。其中选择轻量架构可以大幅度降低模型大小，量化可以大量降低包体大小，它们都能加速应用在内存中的加载。
总的而言对于设备端计算加速，首先 EasyDL 会选择 MobileNet 和 ShuffleNet 等轻量级的模型，例如在目标检测中，系统可能会使用 MobileNet 代替 SSD 中的主干网络，因而获得更高能效比。第二点是系统会通过模型剪枝将不太重要的网络参数去掉，例如去掉 CNN 中权重小于某个阈值的连接或直接去掉不太重要的卷积核。第三点会采用量化操作加速推理阶段的计算，其主要思想是降低卷积运算中数值的精度，从而降低整体的计算量与参数存储空间。
设备端加速第四点会采用很多指令集，包括 ARM 和 Neon 等，其中 Neon 是一种单指令多数据的指令集，系统可以通过一条指令加速多条数据，这些都是硬件层面的加速。最后设备端还能从计算单元的角度进行加速，例如 GPU 和 NPU 等。
