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