随着 AI 技术的发展，不同业务涉及的 AI 技术越来越多样，同时 AI 模型参数量逐年爆发式增长，如何克服 AI 算法落地面临的开发成本高、对人工依赖强、算法不稳定及落地周期长等问题，成为困扰人工智能从业者的难题。而“自动机器学习平台”是解决 AI 落地压力的关键方法。今天会和大家分享下度小满在搭建自动机器学习平台 ATLAS 的实践经验。
首先介绍一下度小满机器学习平台的背景、发展过程以及现状。
度小满是一家金融科技公司，公司内部的业务场景主要分为三个方面：
由于业务涉及的 AI 技术非常多样，给 AI 算法落地带来了很大的挑战。
AI 算法落地存在一个不可能三角：很难同时实现算法开发的高效率、低成本和高质量。
面对这些AI落地的难题，我认为唯一的解决方案是使用机器学习平台。
下面从 AI 算法的生产流程来理解 AI 算法落地过程中遇到的具体困难。
AI 算法落地主要分为数据管理、模型训练、算法优化及部署发布四个部分，其中模型训练和算法优化之间是一个反复迭代的过程。
在算法开发的每一个步骤里面，对参与该步骤的人员的技术要求的差异很大：
从各个步骤需要的技术栈可以看出，很难有一个或者两三个技术人员完全掌握所有的技术，并且每一个涉及人工的步骤，都是造成生产不稳定的生产瓶颈。而使用机器学习平台可以解决这两个问题。
我们的机器学习平台 ATLAS 贯穿 AI 生产的全流程，旨在替代 AI 算法落地过程中的人工参与，达到高效产出、给 AI 算法研发提能增效的目标。
ATLAS 涉及以下四个平台：
这四个平台之间也是循环迭代的关系。下面分别介绍这几个平台的设计细节及运转过程。
数据与训练部分涵盖了标注平台、数据平台和训练平台。
(1) 标注平台
标注平台主要为 AI 算法的训练提供标注数据，自从深度学习诞生以来，模型已经具有了很高的复杂度，AI 算法效果的瓶颈从模型设计上转移到了数据质量和数量上，所以数据的高效生产是在 AI 算法落地中至关重要的环节。
ATLAS 的数据标注平台主要有两方面的能力特性：多场景覆盖和智能标注。
(2) 数据平台
数据平台主要实现大规模数据治理，在治理的过程中能够兼顾灵活性，动态地匹配样本。在保存了上亿用户的5000维度以上的特征的基础上，可以做到一个在线的实时查询。动态匹配样本可以满足不同场景的样本选择和数据的选择要求。
(3) 训练平台
训练平台是一个很重要的设施，分为五个层：
我们的部署采用类 Serverless 的架构，之所以说它是类 Serverless 是因为它并不是完全的 Serverless 的服务。因为我们的服务面向的并不是广泛通用的应用场景，只面向模型的在线服务，所以不需要考虑更多的场景兼容。
在 API 接口这一层提供了模型会接触到的三个部分：
对于用户来说，只有图中橙色部分是用户需要关注的，平台提供的 API 可以减少开发成本，并且可以兼容几乎市面上所有的算法。借助 API 开发一个模型，从开发完成到落地上线可以在一天之内甚至半天之内完成。在此之上我们通过集群管理，可以为平台提供很好的稳定性保障、流量管理和容量管理。
下面演示在 ATLAS 上的两个优化迭代的场景。
例如在一个 OCR 模型的落地过程中，旧模型部署之后会产生一些 bad case，这些 bad case 和已有的标注数据融合之后成为新的数据集，再通过 AutoML 优化流水线优化旧模型产生新模型，新模型部署之后再循环往复。通过这样的循环可以让模型保持额外的1%的准确率的提升，由于 OCR 的模型精度很高，一般会在95%以上，所以1%也是很大的提升。
对于简单重复的优化流程使用全流程 AutoML 替代，对需要专家经验参与的场景使用AutoML 作为辅助优化，并且使用全流程 AutoML 的结果作为 Baseline，选择最优的模型部署上线。在我们公司内部有60%以上的场景通过这样的优化方式获得性能提升，提升效果从1%到5%不等。
下面介绍一下我们运用了哪些 AutoML 的技术，以及我们所做的改进。
首先介绍一下 AutoML 相比传统的专家建模有哪些优势。
AutoML 的优势分为三个方面：
下面来介绍一下 AutoML 中常用的技术。
AutoML 常用的技术包括三个方面：
在实际工作过程中，会根据不同的任务场景选择不同的技术，且这些技术可以联合使用。
下面几个部分分别介绍这三方面的技术。
首先是超参优化部分。实际上在我们的自动优化流水线当中，是将整个机器学习流水线作为自动优化的目标，而不仅仅是针对超参优化。包括自动化的特征工程、模型选择、模型训练和自动集成等，这样相比单独的超参优化，降低了过拟合的可能性。
除此之外，我们自己实现了一个 AutoML 的框架 Genesis，来兼容主流的 AI 算法和AutoML 工具，且对扩展友好，能够把平台中不同的能力模块相互正交，使得他们之间可以自由组合，实现更加灵活的自动优化流水线。
我们的系统中也使用了元学习方法，下面介绍一下元学习方法的必要性和应用的重点场景。
(1） 元学习的必要性
在积累了大量实验数据之后，我们发现数据集在元特征空间呈现明显的聚集性，所以我们假设在元特征空间分布接近的数据集的最优解也会接近。基于这个假设，我们使用历史任务的超参指导新任务的参数优化，发现超参搜索收敛速度会更快，且在有限的预算下，算法效果可以额外提升1%。
(2） 应用场景
在大数据的应用场景中，有时会需要对已有数据集进行合并，例如将数据集 A 和数据集 B 合并产生新的数据集 C，如果用数据集 A 和数据集 B 的超参作为数据集 C 的冷启动来指导数据集 C 的超参优化，一方面可以锁定搜索空间，另一方面可以达到最优的参数优化结果。
在实际开发过程中有时会需要对数据集进行采样，再对采样后的数据集进行超参优化，因为采样后的数据的元特征空间分布与原始数据是接近的，所以用原始数据集的超参去指导采样数据的超参优化，就可以提高优化效率。
最后是我们针对深度学习场景所做的自动优化。分为超参优化和对 NAS 的探索两个方面：
深度学习的开发瓶颈在于训练时间，一次迭代时间需要数小时到数天，那么使用传统贝叶斯优化需要迭代二、三十次，训练时长长达一个月到几个月。所以我们会在深度学习超参优化的部分使用 Hyperband 方法为贝叶斯优化提供种子，加速超参搜索进程。在此基础之上，我们还会运用历史数据的信息来优化冷启动，以及用历史的替代模型做集成，都会比随机初始化以更快收敛速度达到全局最优解。
实际开发场景中，不同的部署场景对模型的规模和时间性能要求不同，其次神经网络结构的优化是模型优化的重要部分，我们需要排除这个步骤里的人工干扰。所以我们提出了这个基于权重纠缠的 One-shot NAS 的方法，搜索效率可以达到经典的 DARTS 方法的3倍以上的，并且搜索到的子网模型的参数量和计算成本都是可控的，我们可以在目标之内选择合适的模型。除此之外，我们还支持 MobileNet、ResNet 等多样空间来满足不同的 CV 任务需求。
最后来讨论一下我们在机器学习平台建设过程中碰到的规模和效率的问题。
我们之所以会关注规模和效率问题，是因为深度学习面临着模型规模和计算需求之间的冲突。
更多的模型参数意味着更好的模型表现是行业的共识。而深度学习存在如下的摩尔定律：
所以高速增长的计算需求与硬件性能之间的鸿沟必须通过优化来解决。
最常用的优化方法就是并行，包括数据并行、模型并行等。其中最常用的是数据并行的技术。
ATLAS 平台的数据并行技术有以下特征：
还有一些模型不能只靠数据并行解决训练效率问题，还需要引入模型并行技术。
ATLAS 的模型并行主要分为两个方面：
一些网络模型的全连接层参数规模非常大，如 arcFace 的分类规模高达几十、上百万甚至上千万，这样的一个全连接层不可能通过一张 GPU 卡覆盖。这时需要引入层内并行技术，不同节点计算同一张量的不同部分。
同时也会用到层间并行技术，即在不同的节点上面计算网络的不同层的数据，将没有依赖的计算前置来减少计算过程中的 IDLE（GPU 等待时间）。
除了可以用张量描述的线性数据以外，我们做了一些图数据并行训练的探索。
对图数据来说，不管是采样还是其他操作都需要动态跨节点，而且图数据一般规模都很大，我们内部的图数据达到了百亿的规模，这样的图数据的计算很难在单机上完成。
图数据分布式计算的瓶颈在于映射表，传统的映射表的空间复杂度为 O(n)，如10亿个点10亿条边的图数据占内存160GB，形成分布式训练的规模天花板。我们提出了一个空间复杂度为 O(1)的方法，通过重排节点和边的 ID，只保留映射边界，达到图并行训练规模可任意扩展的效果。
同时我们也做了一些训练效率方面的优化。
GPU 的很多时间都消耗在读取数据，GPU 空等，通过事前培训、事中监控预警、事后分析可以使 GPU 平均使用率提升一倍。
我们还使用了反向传播重计算技术。对于一些参数非常多的模型，在正向传播的过程中，我们并不保存所有的层的计算结果，仅保留部分节点的 checkpoint，在反向传播时空白参数节点从 checkpoint 开始重新计算。通过这种方式可以减少50%以上的内存资源，训练效率提高35%以上。
最后谈谈在机器学习平台的建设中的经验和思考。
我们总结了如下一些经验：
因为我们 AI 算法落地涉及到的，技术和内容是方方面面的，我不可能要求任意任一个环节上的同学都会了解整个全局，那我们一定要有一个平台能提供这些基础的能力来帮助大家去解决这些问题。
因为只有把自动化或者 AutoML 的应用做得好了，才能够更有效的去解放算法专家的生产力，让算法专家可以去做一些更深入的算法，或者能力的建设来提高机器学习的上限。
A1：开源的 AutoML 框架现在用的比较多的就是 Optuna，还尝试过 Auto-Sklearn 和 AutoWeka，然后给大家推荐一个网站是 automl.org，因为其实现在做这个领域的人还是比较少的，这个网站是几个在 AutoML 领域的专家教授建的一个网站，上面有很多的 AutoML 的开源学习资料，大家都可以去参考。开源框架我们比较推荐的是我们用的 Optuna 去做调参，因为它的算法的来说的话就不是就这种最基础的贝叶斯优化，它是一个 TPE 的算法，比较适合参数量非常大的一些场景，贝叶斯优化还是更适合参数比较少的一些场景，不过我的建议是说大家可能针对不同的场景尝试一些不同的方法，因为就做更多尝试之后，大家可能会对什么场景适合什么方法更有经验。
A2：我们的机器学习平台从建设开始到现在已经经过3、4年的时间。最开始我们先解决部署应用的问题，然后后面是开始建设我们的生产能力，比如计算和训练。如果从零开始搭建的话，我建议大家可以参考一些开源的框架先搭建起来，然后看看在使用过程中，针对自己的业务场景会遇到什么样的问题，好明确后面的开发方向。
A3：这可能是一个更具体的算法优化的问题，但在我们的优化流水线里面，我们是通过采样的方法来训练的，通过这样的方式让我们的任务能够见到数据集的更多的角度，或者说方面，然后再通过把这些采样之后训练得到的 top 模型集成起来，来让我们的模型有更强的泛化能力，这在我们的场景里面也是非常重要的一个方法。
A4：这个开发周期刚才讲过，大概是三到四年的时间。然后人员投入的话，目前是有六七个同学，在早期的话比这个人数还要少。
A5：首先这个同学提到的虚拟化 GPU，应该是指资源的分割和隔离吧。我们做机器学习平台的话，虚拟化 GPU 应该是一个必须的能力，就是说我们一定要把资源做到虚拟化，才能做更好的资源调度和分配。然后在这个基础之上的话，我们可能还会把我们的 GPU 的显存和它的计算资源去做分割，然后把不同大小的资源块去分给不同任务使用，但这一点实际上我们没有在训练里面去用，因为训练的任务通常会对计算的能力有更高的要求，不会是一个更小的资源消耗的应用场景，我们在推理的场景里面是会用到的。我们在实际应用过程当中发现虚拟化技术没有很好的开源免费的方案，有部分的云服务厂商会提供一些收费的方案，所以说我们自己在部署上使用的是分时复用的方案，就是把一些计算要求高的任务和一些计算要求低的任务去做混布，来做到分时的复用，在一定程度上能达到提高容量的效果。
A6：我们是可以接近一个线性的加速比的，就是我们自己测的话，比较好的时候大概可以达到一个80到90的程度。当然，如果节点数量非常多，可能还会需要做进一步的优化，现在可能大家发论文或者看到论文里面会提到说32个或者64个节点可以达到80、90的加速比，那可能是要有一些更专门的优化。但我们在机器学习平台里面的话，有可能会要针对更广泛的场景，在实际的场景里面，大多数的训练可能是4个 GPU 卡、8个 GPU 卡，最多16个 GPU 卡就能够满足要求。
A7：我们的 AutoML 最理想的情况，用户是不需要配置任何参数的。当然我们会根据用户的需求，允许用户自己去调整，或者确定一些参数。时间消耗的话，就是我们所有的 AutoML 场景，我们的目标都是希望能在一天之内去完成优化。然后算力的话，如果是一般的大数据建模，比如树模型 XGB、LGBM 这些的话，就是一台机器都可以搞定；如果是 GPU 的任务的话，要看这个 GPU 任务本身的一个规模，基本上就是原有的训练规模的2到3倍的算力，就可以完成 AutoML 的训练。
A8：这个问题刚才提到过，就是像 Optuna，Auto-Sklearn 还有 AutoWeka 这些都是可以参考的。然后刚才有说到那个 automl.org 的这个网站，上面有很多资料，大家可以去学习一下。
A9：EasyDL 是百度的，我们这个框架是完全自研的。
今天的分享就到这里，谢谢大家。
以上是度小满自动机器学习平台实践的详细内容。更多信息请关注PHP中文网其他相关文章！
