# 模型部署和应用
## 一、概述
训练好的机器学习模型如何更好、更快、更简易、更稳定地运用到生产环境，这是一个非常具有挑战性的问题，也是一个非常重要的问题。我们可能用各种数分析工具以及模型搭建和训练的框架来构建好我们的机器学习模型，用这样的模型在生产中做定义好的前向推理计算，最终得到我们想要的预期结果。那么这万里长征的最后一步模型部署和应用就是特别讲究的，既要能够满足现实各种生产环境，也需要达到模型设计之初时的精度和速度要求，这里面可以展开的内容太多太多了。
从网络文章所知，工业上机器学习系统是庞大数据基础架构的一部分，端到端的机器学习应用其实是穿插在这些基础架构中的，这就让本身机器学习模型应用变得愈加的复杂化。更有一部分人的观点是，机器学习并不一定要取代人类的决策，它主要是起到辅助人类做出复杂的更为明智的决策。
## 二、需求金字塔
需求AI金字塔是什么？越来越多的企业使用机器学习和AI来改善他们的服务并在竞争中领先。不幸的是，许多企业在没有适当的数据平台的情况下进行了AI转换，也没有对部署ML模型的理解。首先应满足几个大数据和数据科学技术需求：
- 大数据基础架构，用于在通常由数据工程师处理的系统的不同部分之间收集，提取，存储，清理和移动数据
- 分析策略，用于探索，可视化，转换和预处理数据为有用的ML输入变量
- 一个框架，用于试验算法，对其进行协作并在跟踪所有模型的参数，准确性和性能的同时进行部署
- 用最简单的数据科学算法建立基准
除此之外，您还需要牢记ML平台的一些重要特征：
- 与业务流程的深度集成
- 连续交付（CI / CD）像任何经典代码一样
- 闭环反馈
这些需求用金字塔表示，类似于马斯洛的需求层次结构。
## 三、端到端ML的挑战
ML工作流应解决*金字塔*所有*层次的问题，*以确保它不会招致*潜在的技术债务*。为了总结演讲的前半部分，可以确定端到端ML工作流中的三个主要挑战：复杂性，规模和试验。挑战不是排他的，它们都是相互关联的。
1. 复杂
企业机器学习工作流程要求：
- 数据基础架构和大量数据处理为ML模型提供了准备好的数据
- 通过多次实验构建ML模型
- 将ML模型部署到生产中并进行监视的大量工作
上面列出的点可以与三个不同的专业相关：数据工程师，数据科学家和DevOps工程师。他们对项目有不同的看法，对输出有不同的期望，并使用不同的工具。ML系统中存在的示例技术是 Hadoop，Kafka，Spark，Tensorflow，xgboost，Docker 和 Kubernetes。这些工具必须集成，并且必须实现在它们之间安全移动数据的机制。
人们的推理和工具集之间的差异可能导致可能破坏整个项目的问题。例如，数据科学家倾向于使用无法并行化且不能在生产环境中使用的笔记本和软件包来生成代码，因为它们无法部署在分布式系统上。笔记本就像是所需输出模型（蛋糕）的规格（配方））。由于数据工程师和 DevOps 并不是数据科学领域的专家，因此他们可能会误解该食谱，并烤出另一块蛋糕。仅仅由于团队之间的错误解释，生产中的ML模型可能会导致与预期产品不匹配，并且无法满足用例。由于每个用例需要不同的特定ML模型，不同的数据准备以及部署的特殊考虑因素，因此增加了复杂性。
2. 规模
大规模是工业机器学习的重要特征。机器学习解决方案可能需要扩展才能为数百万个客户提供服务，这意味着需要庞大的数据集。预处理这些大数据集并将其用于训练ML模型需要大量的计算能力。大数据技术通常用于在安全集群环境中通过并行计算来提供该计算能力。将训练有素的机器学习模型大规模部署到生产中也意味着需要DevOps策略和工具。
3. 实验性
创建ML模型是一个涉及许多实验的渐进过程。ML面临的一个独特挑战是跟踪这些实验。必须向数据科学家提供一种手段，用于预订模型每次训练的信息：模型参数，使用的库，版本等。
CI工具和系统必须足够健壮，才能为不同的ML模型（每个都有特定的依赖性）提供灵活性，并具有兼容性，以在生产中快速扩展，升级和降级ML模型。然后，必须监视和管理许多ML模型。
4. 端到端ML工作流程的策略和生命周期
ML工作流的三个部分将得到解决：
- 版本化和可复制的ML模型训练
- ML模型部署
- 生产中的ML模型管理
重要的一点是，无论使用什么工具来开发ML模型，最好避免移动数据。处理数据所在的位置。无需跨多个平台发送数据，而是选择单个可扩展的分布式解决方案，例如在内部部署环境或云环境中。
最好避免移动数据，例如在数据驻留的内部部署环境或云环境内部。
5. 版本化和可复制的ML模型训练
最终模型之前应有一系列先前模型元信息的快照，例如创建模型的人员和时间，模型的代码，依赖项配置，参数，注释等。
## 四、ML模型部署
部署应快速并适应业务需求。部署的模型应该受到监控并且易于管理。根据业务用例，可以采用三种主要的部署模式：
- 批处理部署-ML模型以脱机方式使用。例如，生成带有预测的每日报告，以帮助管理人员做出决策。
- 实时部署-ML模型用于自动执行对时间敏感的决策。例如，在推荐系统和欺诈检测系统中。
- 边缘部署-ML模型用于对时间要求严格的系统中，需要立即做出决策。先前的两种部署类型都有一个运行ML模型的中央单元，而边缘部署的模型则直接在外部系统上执行。例如，在自主无人机中。
ML模型可以部署为例如Java/C++/Python应用程序，Spark应用程序或RESTful API。与基于API的模型部署相比，将模型作为应用程序进行部署的成本更高且速度较慢，但可提供更高的可靠性，更高的速度和更好的安全性。部署格式仍然是很大程度上取决于用例的决定。用例确定哪种模式部署适用，这又决定了部署格式和使用的工具。例如，在批处理部署方案中，可以选择在Hadoop集群上运行的Scala Spark作业。在实时场景中，需要一种流处理引擎，例如 Flink 或 Kafka Stream。最后，在边缘部署可能需要重写为C / C ++和特定的处理器体系结构。
## 五、生产中ML模型管理
与在训练阶段跟踪实验类似，应在生产ML中跟踪ML模型。
- 在部署时，应收集所有元数据：模型的部署者和部署时间，模型是什么，模型的版本，参数等。
- 必须监视已部署模型的性能，并收集各种度量标准，例如准确性，F1分数（用于衡量测试的准确性），业务KPI，资源使用，响应时间等。需要确定降级模型并分析其性能度量标准。哪个指标发生了漂移，出现了多少，何时出现等情况。
在生产中对ML模型的跟踪使数据科学家可以重新评估模型并重新考虑所选的学习算法。同样，可以部署模型的一些变体并进行比较。应该根据用例的性能，统计意义和实际意义进行比较。
如前所述，每种模型部署格式都对应于特定的用例，并具有许多特定的要求：语言，框架，库，包。通常，这些依赖项必须具有特定版本。这创建了许多不同的软件先决条件，通常是相互冲突的。由于依赖性和其他软件冲突之间的版本不匹配，因此在群集的节点上安装不同的软件可能是一个障碍。容器化可以是一种解决方案。我们可以利用容器化在已打包所有必需软件的隔离Docker环境中托管ML模型。可以将不同版本的项目代码打包到具有不同Docker 映像的多个Docker 容器中。Kubernetes是部署和管理可伸缩容器化应用程序的绝佳工具。