直播回顾 | 一文带你看透模型开发与部署
11月24日下午15：00顶象第十期业务安全系列大讲堂系列课程《Xintell 模型平台 》正式开讲。
顶象人工智能专家&研发总监无常从模型平台的现状与需求出发，带大家了解了模型平台的开发环境与部署环境，并且就顶象的Xintell 模型平台 为大家做了演示。
模型平台的现状与需求
在我们的日常生活中。可以说每时每刻都在认知世界做决策，比如读什么专业，找什么工作，什么样的人结婚等等。决策的依据通常可以分为两种，一种是规则，另一种是模型。
相比模型，规则的优势是灵活、直接，但规则也有自身的不足。
一方面，规则依赖于专家经验的总结与知识提炼。
另一方面，人脑仅能处理非常有限的2~3个变量。且规则对于文字和图片难以提出有效的特征。
这也促使各行各行将规则进化到模型，模型数量也不断攀升。
模型指的是基于目标群体的大规模采样数据，挖掘出某个实际问题或客观事物的现象本质及运行规律，利用抽象的概念分析存在问题或风险，计算推演出减轻、防范问题或风险的对策过程，并形成一套体系化的策略或规则集。
那么，模型的开发与部署有哪些差异呢？
模型开发与部署的差异
我们先来看模型开发。
模型开发是算法建模人员对历史数据进行建模，数据是在数据集市或数据仓库中，数据完整也容易获取，建模人员常用的编程语言是 Python、Spark，可以应用各种python算法库等。
而模型部署是工程研发人员将模型进行在线部署，应用到实时的业务决策中。
相比历史数据，业务的实时数据不容易获取，经常需要跨系统取数。而工程研发人员擅长的编程语言是Java或C++等，这就意味着研发人员对程序的执行效率以及系统代码的可维护性要求更高，同时这也是模型部署较为困难的原因。
目前有2个开源的模型标准化协议，一个是PMMML，另一个是 ONNX。
PMML 是对传统机器学习的模型定义的一个标准，支持 LR、决策树、贝叶斯、K近邻，评分卡等模型。
ONNX 最近几年流行起来的一个新标准，不仅支持传统机器学习，也支持深度学习模型，功能比 PMML 灵活与强大。
以模型开发普遍存在的典型模式为例。
在建模初期，我们需要先申请一台高配置的机器，然后安装各种算法包，再经过漫长的数据申请与获得，接着开始做模型开发。经过长时间的分析与验证，开发出模型，然后找工程研发人员来部署与应用需要，协调服务器资源，最后将模型部署成可以供其他业务系统调用的一种服务。
一旦模型升级更新，此时就需要工程研发人员深夜暂停业务更新模型，对于工程研发人员而言，这是非常艰难与耗时的，且效率较低。
不难看出，相较现在普遍存在的模型开发典型模式，我们更需要一个协同高效的模型平台，快速实现开发与部署。
我们可以将模型开发简单理解为在底层的数据与计算资源之上，建模人员获取数据，然后编写与调试代码，最后进行部署执行。
为了让模型开发高效，一个平台应该具备以下特点：
在取数阶段。可以直接从数据仓库中直接取数，增量数据可以增量处理，还要具备数据的权限管理。
在编码与测试阶段，代码逻辑可以拆分，多人可以协同开发代码，具备版本管理，支持复用，中间结果可以存储与复用，各种工具包可以直接使用。而且还需要具备可以复用的算法模块。
在部署与执行阶段，应该具备编排代码执行的先后顺序。定时执行可以周期跑批，在交互界面中就可以实现模型的部署。
而模型部署的标准化也存在难点。
模型部署的一个关键难点是，在实现的应用中，模型部署不仅仅是部署算法模型，它还包括：数据预处理、数据加工、特征归一化、结果的进一步处理。
对于算法模型，它是数量是有限的，逻辑也是固定的，除了新出现的有些算法外，是较容易转换为 PMML 与 ONNX 的。但是对于数据处理与加工，它是灵活多变的，100个场景的模型，可能有100种不同的数据处理与加工的前置条件，毕竟建模的大部分工作是数据加工与处理。
而这些不同情况的数据加工与处理，是构成模型部署难的关键问题。
前文中，我们曾介绍到算法建模人员依赖工程研发人员来帮助他们进行模型部署，并且经典模式也存在很多问题：
- 单节点部署，随时可能会因为系统软硬件的问题，导致模型不可用；
- 业务不可用，旧模型升级，新模型增加，都需要在深更半夜去暂停服务；
- 只要模型数量在 4-5 个以上，模型管理就会非常痛苦与低效。
而一个模型的部署，跟任意的一个软件系统部署类似，要考虑很多工程化的问题，除了通用的系统部署问题以外，还有很多模型特有的管理需求，这些需求有：
模型的A/B test、模型的多版本管理、模型版本更新、业务无感知、不中断业务服务、模型在不同环境之间的迁移、模型的离线跑、周期调度、高可用模型在多台服务器的分布式部署、根据模型的访问量弹性扩容模型的监控等。
怎样让模型开发高效？
模型开发在软件体系中的位置可以参考下图。
最底层是数据采集，各行各业的数字化、信息化可以收集到大量的可用于智能决策的数据。
数据采集之后应该统一存储与管理，也就是数据中台，负责数据的存储与计算，通常由hadoop生态来搭建
模型平台是构建在数据中台之上，它是数据挖掘与建模的一系列工具，这些工具最关键的两个目标是高效的写代码与灵活的调度与执行。
最上层是场景应用，可以广泛应用于制造业、化工、物流、医疗、金融等行业。可以认为，任意有数据的企业都应该有一套高效协同的模型平台，特别是数字化与信息化已经开展的企业。
此外，建模平台构建在数据中台之上，最常用的建模工具有三种： SQL、Python、低代码 （低代码也可以说是 可视化或模块化建模)。
但这3种工具各有所长，如果想构建一款高效的模型平台，让它适应各行各业的任意场景，这3者是必不可少的。
SQL建模适合做数据存取、数据更新、增量与分区管理，还可以做数据查询、数据聚合、数据join等操作,可以直接在数据中台中执行。
Python建模的特点是具备丰富的数学库，比如Pandas、numpy、sclpy；并且具备丰富的建模框架，如tensorflow\keras\pytorch\scilit_learn等。可以自由写代码，处理任意的数据，实现任意的逻辑。
而低代码可视化建模，它的特点是高效率，大大缩减模型开发的周期；低门槛，降低建模的门槛，让懂数据、了解算法原理而不具备编程的人快速建模，且逻辑清晰，易于运维管理。
我们先来看低代码可视化建模。
它的最大特点就是高效率、低门槛、逻辑清晰。它将建模全流程涉及的数据处理逻辑封装成一个一个算子模块 (这些算子包括：数据存取、特征工程、机器学习、模型评估等等)
算法建模人员根据建模目标，直接从算子库中挑选所需的模块，通过拼接搭建 数据处理 Pipeline，从来实现模型的开发与评估。
Python 建模可以通过 Notebook 工具来编写与调试代码，对于做数据挖掘的人来说，应该都知道这个工具，也知道一些列可用的算法库，比如：pandas、numpy、scikit_learn、tensorflow、pytorch 等。
它的特点是：自由灵活、有大量开源的建模框架与工具包，可以直接使用。
SQL数据加工，是数据处理必不可少的工具。
除了图片与视频外，几乎都是结构化或半结构化的，而SQL就是为了处理结构化数据而生的工具。
数据中台里，通常使用Hive作为数据仓库，但是这里特别要提一下 Impala，Impala 是为Hive设计的分布式计算引擎，相比Hive的其他执行引擎 MapReduce、Tez、Spark ，它的速度要快很多。
模型部署环境怎样让模型部署简单？
正如前文中提到，模型部署涉及到非常多的工程化需求。
而这张图就是为了解决上一张图设计的一个系统光卡，这个也是顶向的核心专利，它的关键点是实现了在N台服务器上智能部署X模型外版本。
它能根据模型的数量、不同模型的性能以及它的业务请求量、还根据服务器的负载情况，实现模型的智能分配。在这张图上我们可以看到有三个服务器，11个模型。共计16个版本的一种分布部署图。
其中：模型1有3个版本，部署在引擎1与2上，模型234有2个版本，1版本部署在引擎1上，2版本部署在引擎2与3上。
中间部分是模型管理的各种业务需求，包括多版本管理、A/B Test、版本切换、模型调试、模型监控、模型迁移等。
需要注意的是：不管是新增模型、还是对模型的版本进行切换、或者开启模型的A/B Test，整个过程：
1.业务是无感知的，不会中断线上业务，不再需要深更半夜去更新模型。
- 任意一台服务器出现故障，也不会影响线上业务，故障机器的业务请求，会自动转发给其他机器进行处理。
- 模型也会自动从故障机器迁移到其他正常的机器。
最左侧是 交互界面 与 对外API，模型管理人员通过交互界面管理模型，外部系统通过API访问模型。
这是模型仓库，统一管理3种模型，3种模型的格式分别为：Xintell模型、Python模型、PMML模型
Xintell 模型：是低代码可视化建模工具，开发出来的模型；
Python 模型：是 Python 编码开发出来的模型；
PMML 模型： 是前面讲过的一个通用标准的模型。
展示的信息包括：模型名、模型格式、当前版本、标签分类信息、模型的状态(离线或在线)、模型今日调用次数、平均耗时等。
PMML的模型可以直接上传文件，直接导入到模型仓库。导入后，平台会向用户展示模型的入场有哪些字段，以及模型的返回参数是什么。
任意的Python模型都可以导入到平台，这个也是顶象平台的核心专利，不仅支持将scikit_learn 开发的模型，也支持 tensorflow 或 pytorch 等框架开发出来的模型，还支持ONNX格式的标准模型
对于Python模型，顶象定义了一个新标准，这个标准比ONNX标准会更简单与灵活。
这三种模型的部署方式、交互体验是完全一致的，通过上传可以看到路程和返回值。通过界面就可以实现模型的智能化部署。
接下来我们看一下模型管理的其他方面的需求，如模型的多版本管理。
上图展示一个模型的多版本信息，以及版本的创建时间、版本的说明信息。下图展示模型的版本切换，为了避免让业务出现中断，模型必须要部署在2台服务器以上，才允许进行版本切换，在一台服务器上切换时，其他机器可以继续提供服务，从而实现模型的模型升级的业务部感知。
再来看下模型的AB test。
模型平台应该支持模型的A/B Test。模型A/B Test：是用新开发的版本B，与当前正在提供服务的A版本，进行对比，
最常用的是“分流模式”，比如：分出 2% 的流量调用测试版本B，其余 98% 的流量继续使用当前版本A。
除了分流模式，我们还设计了一种 “灰度模式”，在灰度模式下，模型总是输出当前版本A的结果，但是会在部分流量中附带测试版本B的结果作为参考。
模型接口调试：模型部署到模型仓库之后，会自动生成一个对外可用的API地址，外部系统可以通过该API地址调用模型，为了验证模型是否正常，或者对模型的推理进行调试，我们提供一个接口调试界面，在界面中，填写模型的入参，就可以进行测试。
当然，模型监控也是非常重要的，这张图我们可以看到模型的今日调用量、平均耗时，还有单位的调用量以及最近30天的调用趋势等信息。在模型调用出现失败或者是模型性能耗时很长的时候，系统可以触发邮件通知，以邮件或短信的方式通知模型开发人员。
最后再给大家简单介绍下顶象业务安全大讲堂。
顶象业务安全大讲堂汇集了业内大咖，分享万亿级业务安全攻防经验，打造时下最专业的业务安全直播课，通过“技术+方案+实践”三大核心专题，带您全面了解金融、互联网、航旅出行、跨境电商以及目前大热的NFT等各类业务风险及防范手段，深入解析背后的产品技术，抽丝剥茧攻防实战，助您打造零风险的数字业务。
下期顶象将会重磅推出顶象业务情报中心并举办线上发布会，现场福利多多，请大家提前锁定直播间，预约起来吧！
11月24日下午15：00顶象第十期业务安全系列大讲堂系列课程《Xintell 模型平台 》正式开讲。
顶象人工智能专家&研发总监无常从模型平台的现状与需求出发，带大家了解了模型平台的开发环境与部署环境，并且就顶象的Xintell 模型平台 为大家做了演示。
模型平台的现状与需求
在我们的日常生活中。可以说每时每刻都在认知世界做决策，比如读什么专业，找什么工作，什么样的人结婚等等。决策的依据通常可以分为两种，一种是规则，另一种是模型。
相比模型，规则的优势是灵活、直接，但规则也有自身的不足。
一方面，规则依赖于专家经验的总结与知识提炼。
另一方面，人脑仅能处理非常有限的2~3个变量。且规则对于文字和图片难以提出有效的特征。
这也促使各行各行将规则进化到模型，模型数量也不断攀升。
模型指的是基于目标群体的大规模采样数据，挖掘出某个实际问题或客观事物的现象本质及运行规律，利用抽象的概念分析存在问题或风险，计算推演出减轻、防范问题或风险的对策过程，并形成一套体系化的策略或规则集。
那么，模型的开发与部署有哪些差异呢？
模型开发与部署的差异
我们先来看模型开发。
模型开发是算法建模人员对历史数据进行建模，数据是在数据集市或数据仓库中，数据完整也容易获取，建模人员常用的编程语言是 Python、Spark，可以应用各种python算法库等。
而模型部署是工程研发人员将模型进行在线部署，应用到实时的业务决策中。
相比历史数据，业务的实时数据不容易获取，经常需要跨系统取数。而工程研发人员擅长的编程语言是Java或C++等，这就意味着研发人员对程序的执行效率以及系统代码的可维护性要求更高，同时这也是模型部署较为困难的原因。
目前有2个开源的模型标准化协议，一个是PMMML，另一个是 ONNX。
PMML 是对传统机器学习的模型定义的一个标准，支持 LR、决策树、贝叶斯、K近邻，评分卡等模型。
ONNX 最近几年流行起来的一个新标准，不仅支持传统机器学习，也支持深度学习模型，功能比 PMML 灵活与强大。
以模型开发普遍存在的典型模式为例。
在建模初期，我们需要先申请一台高配置的机器，然后安装各种算法包，再经过漫长的数据申请与获得，接着开始做模型开发。经过长时间的分析与验证，开发出模型，然后找工程研发人员来部署与应用需要，协调服务器资源，最后将模型部署成可以供其他业务系统调用的一种服务。
一旦模型升级更新，此时就需要工程研发人员深夜暂停业务更新模型，对于工程研发人员而言，这是非常艰难与耗时的，且效率较低。
不难看出，相较现在普遍存在的模型开发典型模式，我们更需要一个协同高效的模型平台，快速实现开发与部署。
我们可以将模型开发简单理解为在底层的数据与计算资源之上，建模人员获取数据，然后编写与调试代码，最后进行部署执行。
为了让模型开发高效，一个平台应该具备以下特点：
在取数阶段。可以直接从数据仓库中直接取数，增量数据可以增量处理，还要具备数据的权限管理。
在编码与测试阶段，代码逻辑可以拆分，多人可以协同开发代码，具备版本管理，支持复用，中间结果可以存储与复用，各种工具包可以直接使用。而且还需要具备可以复用的算法模块。
在部署与执行阶段，应该具备编排代码执行的先后顺序。定时执行可以周期跑批，在交互界面中就可以实现模型的部署。
而模型部署的标准化也存在难点。
模型部署的一个关键难点是，在实现的应用中，模型部署不仅仅是部署算法模型，它还包括：数据预处理、数据加工、特征归一化、结果的进一步处理。
对于算法模型，它是数量是有限的，逻辑也是固定的，除了新出现的有些算法外，是较容易转换为 PMML 与 ONNX 的。但是对于数据处理与加工，它是灵活多变的，100个场景的模型，可能有100种不同的数据处理与加工的前置条件，毕竟建模的大部分工作是数据加工与处理。
而这些不同情况的数据加工与处理，是构成模型部署难的关键问题。
前文中，我们曾介绍到算法建模人员依赖工程研发人员来帮助他们进行模型部署，并且经典模式也存在很多问题：
- 单节点部署，随时可能会因为系统软硬件的问题，导致模型不可用；
- 业务不可用，旧模型升级，新模型增加，都需要在深更半夜去暂停服务；
- 只要模型数量在 4-5 个以上，模型管理就会非常痛苦与低效。
而一个模型的部署，跟任意的一个软件系统部署类似，要考虑很多工程化的问题，除了通用的系统部署问题以外，还有很多模型特有的管理需求，这些需求有：
模型的A/B test、模型的多版本管理、模型版本更新、业务无感知、不中断业务服务、模型在不同环境之间的迁移、模型的离线跑、周期调度、高可用模型在多台服务器的分布式部署、根据模型的访问量弹性扩容模型的监控等。
怎样让模型开发高效？
模型开发在软件体系中的位置可以参考下图。
最底层是数据采集，各行各业的数字化、信息化可以收集到大量的可用于智能决策的数据。
数据采集之后应该统一存储与管理，也就是数据中台，负责数据的存储与计算，通常由hadoop生态来搭建
模型平台是构建在数据中台之上，它是数据挖掘与建模的一系列工具，这些工具最关键的两个目标是高效的写代码与灵活的调度与执行。
最上层是场景应用，可以广泛应用于制造业、化工、物流、医疗、金融等行业。可以认为，任意有数据的企业都应该有一套高效协同的模型平台，特别是数字化与信息化已经开展的企业。
此外，建模平台构建在数据中台之上，最常用的建模工具有三种： SQL、Python、低代码 （低代码也可以说是 可视化或模块化建模)。
但这3种工具各有所长，如果想构建一款高效的模型平台，让它适应各行各业的任意场景，这3者是必不可少的。
SQL建模适合做数据存取、数据更新、增量与分区管理，还可以做数据查询、数据聚合、数据join等操作,可以直接在数据中台中执行。
Python建模的特点是具备丰富的数学库，比如Pandas、numpy、sclpy；并且具备丰富的建模框架，如tensorflow\keras\pytorch\scilit_learn等。可以自由写代码，处理任意的数据，实现任意的逻辑。
而低代码可视化建模，它的特点是高效率，大大缩减模型开发的周期；低门槛，降低建模的门槛，让懂数据、了解算法原理而不具备编程的人快速建模，且逻辑清晰，易于运维管理。
我们先来看低代码可视化建模。
它的最大特点就是高效率、低门槛、逻辑清晰。它将建模全流程涉及的数据处理逻辑封装成一个一个算子模块 (这些算子包括：数据存取、特征工程、机器学习、模型评估等等)
算法建模人员根据建模目标，直接从算子库中挑选所需的模块，通过拼接搭建 数据处理 Pipeline，从来实现模型的开发与评估。
Python 建模可以通过 Notebook 工具来编写与调试代码，对于做数据挖掘的人来说，应该都知道这个工具，也知道一些列可用的算法库，比如：pandas、numpy、scikit_learn、tensorflow、pytorch 等。
它的特点是：自由灵活、有大量开源的建模框架与工具包，可以直接使用。
SQL数据加工，是数据处理必不可少的工具。
除了图片与视频外，几乎都是结构化或半结构化的，而SQL就是为了处理结构化数据而生的工具。
数据中台里，通常使用Hive作为数据仓库，但是这里特别要提一下 Impala，Impala 是为Hive设计的分布式计算引擎，相比Hive的其他执行引擎 MapReduce、Tez、Spark ，它的速度要快很多。
模型部署环境怎样让模型部署简单？
正如前文中提到，模型部署涉及到非常多的工程化需求。
而这张图就是为了解决上一张图设计的一个系统光卡，这个也是顶向的核心专利，它的关键点是实现了在N台服务器上智能部署X模型外版本。
它能根据模型的数量、不同模型的性能以及它的业务请求量、还根据服务器的负载情况，实现模型的智能分配。在这张图上我们可以看到有三个服务器，11个模型。共计16个版本的一种分布部署图。
其中：模型1有3个版本，部署在引擎1与2上，模型234有2个版本，1版本部署在引擎1上，2版本部署在引擎2与3上。
中间部分是模型管理的各种业务需求，包括多版本管理、A/B Test、版本切换、模型调试、模型监控、模型迁移等。
需要注意的是：不管是新增模型、还是对模型的版本进行切换、或者开启模型的A/B Test，整个过程：
1.业务是无感知的，不会中断线上业务，不再需要深更半夜去更新模型。
- 任意一台服务器出现故障，也不会影响线上业务，故障机器的业务请求，会自动转发给其他机器进行处理。
- 模型也会自动从故障机器迁移到其他正常的机器。
最左侧是 交互界面 与 对外API，模型管理人员通过交互界面管理模型，外部系统通过API访问模型。
这是模型仓库，统一管理3种模型，3种模型的格式分别为：Xintell模型、Python模型、PMML模型
Xintell 模型：是低代码可视化建模工具，开发出来的模型；
Python 模型：是 Python 编码开发出来的模型；
PMML 模型： 是前面讲过的一个通用标准的模型。
展示的信息包括：模型名、模型格式、当前版本、标签分类信息、模型的状态(离线或在线)、模型今日调用次数、平均耗时等。
PMML的模型可以直接上传文件，直接导入到模型仓库。导入后，平台会向用户展示模型的入场有哪些字段，以及模型的返回参数是什么。
任意的Python模型都可以导入到平台，这个也是顶象平台的核心专利，不仅支持将scikit_learn 开发的模型，也支持 tensorflow 或 pytorch 等框架开发出来的模型，还支持ONNX格式的标准模型
对于Python模型，顶象定义了一个新标准，这个标准比ONNX标准会更简单与灵活。
这三种模型的部署方式、交互体验是完全一致的，通过上传可以看到路程和返回值。通过界面就可以实现模型的智能化部署。
接下来我们看一下模型管理的其他方面的需求，如模型的多版本管理。
上图展示一个模型的多版本信息，以及版本的创建时间、版本的说明信息。下图展示模型的版本切换，为了避免让业务出现中断，模型必须要部署在2台服务器以上，才允许进行版本切换，在一台服务器上切换时，其他机器可以继续提供服务，从而实现模型的模型升级的业务部感知。
再来看下模型的AB test。
模型平台应该支持模型的A/B Test。模型A/B Test：是用新开发的版本B，与当前正在提供服务的A版本，进行对比，
最常用的是“分流模式”，比如：分出 2% 的流量调用测试版本B，其余 98% 的流量继续使用当前版本A。
除了分流模式，我们还设计了一种 “灰度模式”，在灰度模式下，模型总是输出当前版本A的结果，但是会在部分流量中附带测试版本B的结果作为参考。
模型接口调试：模型部署到模型仓库之后，会自动生成一个对外可用的API地址，外部系统可以通过该API地址调用模型，为了验证模型是否正常，或者对模型的推理进行调试，我们提供一个接口调试界面，在界面中，填写模型的入参，就可以进行测试。
当然，模型监控也是非常重要的，这张图我们可以看到模型的今日调用量、平均耗时，还有单位的调用量以及最近30天的调用趋势等信息。在模型调用出现失败或者是模型性能耗时很长的时候，系统可以触发邮件通知，以邮件或短信的方式通知模型开发人员。
最后再给大家简单介绍下顶象业务安全大讲堂。
顶象业务安全大讲堂汇集了业内大咖，分享万亿级业务安全攻防经验，打造时下最专业的业务安全直播课，通过“技术+方案+实践”三大核心专题，带您全面了解金融、互联网、航旅出行、跨境电商以及目前大热的NFT等各类业务风险及防范手段，深入解析背后的产品技术，抽丝剥茧攻防实战，助您打造零风险的数字业务。
下期顶象将会重磅推出顶象业务情报中心并举办线上发布会，现场福利多多，请大家提前锁定直播间，预约起来吧！
