AI中台：一种敏捷的智能业务支持方案|宜信技术学院沙龙分享实录

内容来源：宜信技术学院第1期技术沙龙-线上直播|AI中台：一种敏捷的智能业务支持方案

主讲人介绍：井玉欣 宜信技术研发中心AI应用团队负责人

本文字数：13479字 阅读用时：34分钟

导读：随着“数据中台”的提出和成功实践，各企业纷纷在“大中台，小前台”的共识下启动了本身的中台化进程，以数据中台、技术中台、业务中台为表明的一系列技术，极大加强了业务的敏捷性，提升了组织效能。同时随着智能技术的发展，AI应用在业务研发中的占比逐渐升高，但AI模型训练的复杂性致使其开发慢、效率低，严重影响了业务的灵活性。

针对这种状况，可否基于中台化思想对业务中AI研发工做进行专门支持，提供对智能需求的迅速实现和灵活试错功能，从而提高企业智能创新能力？AI中台的构建和实施又该如何进行？

本次直播宜信研发中心AI应用团队负责人井玉欣博士结合宜信目前实际业务和中台化战略在宜信的实施状况对以上问题进行了探讨。如下是本次分享的实录。

分享大纲：

1、AI中台的提出

2、AI中台的目标和定义

3、AI中台的实施路线

4、实例分析-智能投顾机器人为例

5、总结

6、Q&A

PPT：https://pan.baidu.com/s/1-nqZ...
视频：https://v.qq.com/x/page/e0856...

分享实录

1、AI中台的提出

1.1 中台战略的兴起

自从中台战略被提出并获得成功实施后，业界反响强烈，国内各家企业纷纷启动了本身的中台化进程。尤为是对于在战略中处于核心地位的数据中台建设，各方都有本身的解读和心得。

但整体来看，业界造成了对中台战略的一些共识，即主张“大中台、小前台”，经过构建中台，沉淀共享服务，提升服务重用率，打破“烟囱式”、“项目制”系统之间的集成和协做壁垒，下降前台业务的试错成本，赋予业务快速创新能力，最终提高企业的组织效能。

不管是在金融、在线交易、资讯、医疗仍是教育行业，业界对中台战略的研讨包括企业平常活动中的各个环节，例如业务中台、技术中台、移动中台等等，但在数据时代，企业中的大量业务都运行于大数据之上，数据的响应能力、处理能力决定了业务效率，因此中台战略中最主要的、也是实施的起点，仍然是数据中台。数据中台实现了组织内数据标准的统一，并打破数据壁垒，构建统一数据实体，对外提供统一的数据服务。经过这三个“统一”实现了组织内的数据资产中心，为前台业务提供了自动化、自助化的敏捷数据能力输出。

自动化的优点是能够极大节省常规数据操做的成本开销，而自助化数据管理能够支持业务用户根据本身需求自助式地获取、处理数据，灵活实现业务需求。但这两个优点相比于传统“烟囱式”数据系统来讲，只是使业务方感受数据服务更加能用、易用而已，想要真正作到好用，甚至让业务方喜欢用，不管是数据中台仍是其余中台服务，都离不开智能化的能力。

1.2 智能业务需求的中台化

业务的智能化需求来自于两方面：

一方面从数据层面来看，随着可获取的数据愈来愈多，咱们对其中有价值信息的辨识、数据关系的发现、数据趋势的把握都将变得愈来愈困难，只有经过智能化的方法对大数据进行治理，才能提高业务，甚至创新业务。基于大数据探索，发现其中的潜在数据联系与趋势，能够为业务优化与创新提供强有力的支持，实现真正的数据驱动业务。所以数据中台必须具有智能化能力，可以为业务提供必定的智能数据分析能力。

另外一方面，除了基于数据自底向上的智能化驱动之外，还存在自上而下的企业智能化理念驱动。近几年来，许多智能技术日趋成熟，相应的智能化理念也深刻人心，大量智能化的成功案例使这些技术逐渐被行业主流接受，甚至成为了实际上的标准解决方案，好比电商须要推荐、金融须要风控，而随之就要求研发人员可以在数据之上准确快速实现前台提出的智能化目标。

上图是一个示例，数据来源于Roland Berger。宜信做为一家金融科技公司，更多面对的是金融领域的智能业务需求。从图中能够看到在金融这一个领域以内就有这么多环节已经造成了标准化的智能应用，可想而知在今天企业业务的发展过程当中智能化正在扮演一个多么重要的角色。

不管是哪方面的需求，都会碰到一个问题：智能业务需求各类各样、各不相同，一个需求下来，研发团队须要针对性开展数据分析处理、模型的构建训练等，过程复杂繁复，效率不高，从而拖长了需求响应时间，下降了业务敏捷程度，拉高了试错成本。这与在中台战略背景下，业务前台但愿可以专一于业务逻辑、灵活应对变化产生了矛盾，并且随着智能化应用的普遍开展，这个矛盾也愈来愈广泛。

究其缘由，一方面是因为智能化的大规模兴起才短短几年，智能应用研发还处在比较原始的阶段，缺少完整的生命周期管理理论和相应的管理框架工具；另外一方面则反映了咱们的中台能力没有彻底覆盖到前台业务研发中笨重、重复、低效的环节。

那么，咱们天然而然会想到，咱们可否对现有数据中台进行进一步智能化跃迁，解决上述问题呢？若是能，数据中台能够或者应该提供什么样的数据智能化能力？若是不能，中台战略又应该如何敏捷支持智能化业务需求？

1.3 从数据中台到AI中台

咱们先来看看数据中台的智能化支持能力，试分析以下问题：数据中台能经过通用的智能数据模型充分支持当前业务背景下多样的智能需求吗？答案是比较困难，缘由在于业务智能化过程的复杂性。

一般的机器学习任务包括了回归、分类、标注、聚类、推荐等等，每一个算法模型的实现又包括了数据预处理、特征分析、建模、训练、部署等多个环节，实际中的应用更是有可能包括多个模型。

而数据中台以数据为核心，其智能化能力若想支持到以上全部环节，工做量绝对不小，而且会偏离数据中台的原有目标，所以让数据中台承担所有的智能化业务支持是不合适的。

详细来讲，咱们能够从目前人工智能（AI）所涵盖的内容进行分析。广义上人工智能指利用科学方法和技术，研制可以模仿、延伸、扩展人类智能的机器系统，涉及了计算机科学、数学、哲学、心理学等多门学科；而从计算机科学的角度狭义来看，人工智能特指能够接受和处理外部数据，并可以作出类人化分析、决策的计算机系统，涵盖了数据挖掘、机器学习、深度学习、强化学习等多个子领域。如无特殊说明，本文所述人工智能皆指后者。

这几类任务中，机器学习、深度学习、强化学习的目标、实施过程比较类似，所以一般直接统称为机器学习任务，本文也采起这种概略性说法。而数据挖掘任务则与机器学习任务相关又不太相同，他们之间的区别给不少人带来过困扰。

实际上，按照《数据挖掘与预测分析》书中的定义，“数据挖掘是从大型数据集中发现有用的模式和趋势的过程”，这其中包括了数据预处理、数据探索、数据降维、数据统计、关联分析、离群分析等子任务，这些是机器学习工做开展的基础。

而另外一方面，数据挖掘还包含了以后的数据聚类、数据预测、数据分类的一些内容，这些正是机器学习所研究的部份内容；因为机器学习的蓬勃发展和优异性能表现，通常此部分的工做也更多交由机器学习来完成。

总之，二者都是人工智能的重要研究方向，也是企业大数据智能化过程当中的重要环节，彼此相互联系，但侧重点存在不一样：数据挖掘更侧重于“洞察”，而机器学习更侧重于“学习”和“预测”。

从上述分析能够看出，当前业务背景下，从事“洞察”任务的数据挖掘工做将重心放在了数据上，通常不须要人工辅助便可自动化完成；此外因为不涉及数据预测、分类等任务，数据挖掘一般采用比较固定的分析算法和模型，因此该部分工做彻底能够作到自动化、自助化，集成到数据中台内，做为固定的智能数据模型服务提供给业务用户。

另外一方面，从事“学习”和“预测”任务的机器学习工做相对而言更加复杂：

• 机器学习的实施过程一般是高度计算密集型的；
• 所采用算法和模型结构有可能相同，但都须要根据业务数据进行个性化参数训练；
• 训练阶段一般通过屡次迭代；
• 除部分非监督学习外，实施环节一般须要人工标注环节的参与；
• 线上模型的运行性能须要监控，须要根据数据演进进行更新。

了解了人工智能领域分类后，咱们来试图回答一下前面提出的问题。若是数据中台愿意支持业务所提出的智能化需求，那么咱们要怎么对数据中台进行跃迁？或者说数据中台要怎么跃迁本身的能力来支持这些需求呢？

从上图能够看出，数据中台自己具有以数据为核心、算法固定、有必定的自动性等特征，咱们彻底能够在数据中台里利用其流式计算能力、批量计算能力、数据可视化技术等来为相应的业务需求提供支持。

这些还都是数据中台自己就已经具有的功能。若是还要用数据中台来作机器学习部分的AI项目支持，还须要具有哪些能力呢？如上图所示，一圈一圈地往外扩展。首先须要复杂的特征工程支持能力、模型训练能力；其次须要数据标注能力、模型部署能力、性能监控能力。

每一项能力都须要耗费大量的人力物力和时间来进行开发，并且由内而外的能力扩展与数据自己的相关性是由强至弱的，也就是说随着能力层次的不断扩充，数据中台逐渐偏离了其“以数据为核心”的宗旨，并且也会使得数据中台变得臃肿复杂，在对接前台业务需求的时候，也可能会带来更多复杂性的问题。所以数据中台能够必定程度上支持智能化业务需求，但若是想单靠数据中台来支持全部智能化业务需求显然不是最佳选择。

那么咱们要怎么作呢？将AI中台与数据中台进行分离。

如上图，咱们将数据中台外面套着的几层能力抽象剥离出来，整合造成一个独立的中台层，依托数据中台进行必定的协做，共同应对前台的智能化业务需求。数据中台主要集成数据挖掘、数据洞察智能算法和模型；新的中台主要承担复杂的学习预测类智能需求研发。这一中台咱们称之为“AI中台”。

上图是AI中台与数据中台分离的结构化图表，自上而下分别是业务前台、AI中台和数据中台，还有底层一些相关的计算存储资源。

• 数据中台提供基本能力，包括数据标准化、数据实体化、数据服务统一化等；还支持部分数据处理的智能需求，包括智能数据模型、关联分析、主成分分析、异常点分析等。数据中台主要承担数据探索的职责。
• AI中台提供模型设计训练、模型/算法库、复用标注管理、监控服务等一系列相关AI紧耦合的能力支持。AI中台从事的是学习预测的任务。
• 业务前台则是包括了各类须要中台提供敏捷性支持的需求，好比业务智能需求、用户细分需求、个性推荐需求等。

值得注意的是，上图所示结构只是一个示例，中台主要面向业务，是为了更敏捷地响应业务需求，所以中台体系应该针对业务来设置，好比有一些前台业务不须要AI中台能够直接落到数据中台来进行处理。

至此咱们已经回答了前文的问题，单纯依赖数据中台来支持业务智能化需求的敏捷实施是不够的，但咱们能够在其基础之上构建专门的AI中台来提供这一能力。中台化战略中不能单独依赖数据中台来实现中台化转型，阿里的共享服务中心也是包括了业务、技术、数据等多个层面的内容，各企业应该按照本身的业务结构与流程，合理抽象构思本身的中台服务模型并加以实施。

2、AI中台的目标与定义

前文经过对智能化业务需求和数据中台的分析解释了建设AI中台的背景和缘由，但AI中台的目标到底是什么？其基本要求和能力有哪些？接下来咱们将对此进行详细讨论。

2.1 AI任务划分与敏捷需求

AI中台须要灵活地支持各种AI任务，解决各种任务敏捷化过程当中的需求与痛点。当前，企业智能化需求各不相同，致使相应的AI任务也种类繁多。

对AI任务类型有许多种划分方法，例如经典地按任务目标可分为回归、分类、聚类、标注等等。

这里咱们采用另外一种划分方式，认为全部的AI任务均可以划分红为两类：

• 一种是针对某个业务领域内特定类型数据，提供对此类数据的基础AI学习、预测、分析能力的“横向”任务，例如计算机视觉、天然语言处理任务等；
• 另外一种则是面向业务具体需求的、相对特殊化与个性化的“纵向”任务，例如金融领域的智能风控、电商领域的产品推荐以及比较常见的用户画像构建等。

就这两类AI任务来讲，不管哪类任务均可以独立对外服务，也能够混合起来相互之间集成、组合，造成AI解决方案来支持更复杂的业务场景。咱们构建智能化业务应用的核心就是将智能化需求分解、映射为具体的AI任务并一一实现，最后再进行合理地编排组合，实现任务目标。

但另外一方面，在两类任务的实施过程当中，其敏捷化需求存在着不一样，对AI中台应该提供的服务需求也不一样。相对而言，横向任务的敏捷化比较容易实现。

对于横向任务，除部分场景外，不少时候其自己并不直接解决业务需求，常做为基础模型对数据进行初步加工，再由一些纵向任务来对接需求。这也给算法实施团队充足的时间对横向任务模型进行充分的雕琢，对其敏捷性进行完善。

因为业务领域内数据的通用性，咱们彻底能够预训练出一套经常使用的业务领域专用横向AI模型，例如金融业务领域内的通用天然语言理解模型等。这样咱们只需维护、更新这套模型，该领域内的全部智能化相关需求均可以随时地复用该模型库，从而节省大量的任务训练时间。

再进一步，咱们甚至能够预先训练一个全领域的横向AI模型库，这样即便咱们进入到一个全新的业务领域，基于这个预训练库，也能迅速地打造出领域内通用横向模型，例如计算机视觉领域的ImageNet项目、天然语言处理领域Google推出的BERT技术等都是如此。

所以，横向的基础性AI任务自己可以经过提高模型的通用性、可复用性来敏捷支撑智能化业务需求，一个基本的AI共享服务平台（或者说咱们但愿构建的AI中台）应该为其提供一个方便的可复用解决方案设计与自动展开结构，完善的模型库、算法库管理系统，以及稳定的模型运行环境等。

对于纵向任务来讲，状况就变得比较复杂。纵向任务需求普遍，多为定制化开发，数据多种多样，很难像横向任务那样经过构建通用化模型来响应需求；项目的开发须要专门的人工标注，模型须要反复地训练与调优，这些无一不须要大量时间与精力，最终致使项目大多数时间成本均花费在这些环节之上，形成AI应用项目研发缓慢。

更为重要的是，实际中前台面对业务的瞬息万变，对智能化应用的最大要求不必定是性能的最优化提高，而是快速研发、迅速上线、当即产生效果，在很多状况下甚至能够对性能进行必定的容忍，显然大多数纵向任务的开发速度是没法知足这一需求的，这就产生了前台业务快速推动与后台研发缓慢的激烈矛盾。AI服务若是要中台化，那么咱们的AI中台必须可以解决纵向任务研发缓慢这一最大痛点。

纵向任务的这一痛点关键在于其研发过程的复杂性：

• 在目前大多数纵向任务项目中，因为需求的不一样，算法团队每次都会依次经历数据获取、处理、分析、建模、标注，模型训练、调优、验证、部署、监控、更新等一系列环节；
• 而每一个环节内还有本身的复杂性，如数据接入管理、特征工程的开展、标注过程的人工介入、训练调优的反复迭代等；
• 此外，整个环节还有众多角色的介入，如数据分析师、算法工程师、标注工程师、业务分析师等，对角色的管理一样复杂。

因此针对这类复杂任务问题的研究重点就在于其全生命周期的科学化管理，以及研发流程和每一个环节的优化。经过对研发过程当中各环节的拆分，咱们可以在必定程度上优化任务编排顺序，清楚定位各环节参与角色，经过任务并行与角色协做缩短期开销；而对于每一个环节或局部环节的深刻探讨，能够抽象出自动化操做和可复用的流程，进一步提升业务响应速度。

此外，无论横向任务仍是纵向任务，二者对AI中台都有一些共同的基本需求。

首先，智能模型对数据的统一访问需求。智能模型在训练阶段须要必定量的训练数据，上线以后须要对接生产数据，之后的监控、更新还须要更多数据，但在实际中每一个项目的数据来源通常都各不相同，这就致使研发人员每次都要根据项目状况人工去申请、获取、清洗、预处理数据，十分影响效率。若是可以对接统一的数据服务平台甚至数据中台，那么这一过程将节省下大量时间与精力。

其次，智能模型须要稳定的模型部署、运行平台，还有相应的模型监控系统来时刻追踪模型的性能表现。固然，便捷的模型更新机制也应具有，便于咱们根据须要不断更新、升级模型。

再次，智能模型在开发过程当中，须要一系列的运算、存储等资源。在大多数企业实体中，不少项目都是项目组本身提供运算资源训练模型，上线时再申请生产资源对环境进行配置、对项目进行部署。这种各自为政的资源管理模式不可避免地会形成资源使用的不协调与浪费，须要一套可靠的资源管理系统对计算资源进行集中管控，并提供弹性化的计算资源调度能力。

综上，咱们能够基于前文对两类AI任务的分析，对AI中台究竟要作什么，应具有什么能力进行一下总结。

2.2 AI中台的目标与能力

AI中台致力于解决目前企业智能应用研发过程当中存在的响应缓慢、效率低下问题，包括但不限于：

• “烟囱式”开发，项目成本高、不易集成，过程重复，缺少能力沉淀；
• 研发环节繁多，缺乏优化、协同、自动化辅助，业务响应缓慢；
• 模型研发缺少标准指导，服务接口混乱，难以维护管理；
• 缺乏统一的数据访问渠道，数据获取难、标准不一致，重复的数据预处理与特征工程；
• 缺乏统一的模型运行、监控平台，以及更新、维护机制；
• 基础资源分散管理，未获得充分利用，形成浪费。

以上问题广泛存在，能够说如今的许多算法研发团队更像是算法外包团队，根据不一样业务部门的需求各自构建阵地，逐步攻克目标，过程重复、效率有限。而AI中台则努力提供一个强大的AI能力支持中心，根据业务须要快速提供火力支援，迅速达成目的。因此，AI中台应具有的能力包括：

• 多层次可复用。对于算法、模型的标准化研发指导，以及可复用服务封装能力；
• 服务统一化。统一的服务接口规范，支持服务的动态编排组合；
• 流程角色优化。研发流程拆分优化，清晰的研发角色定义，支持任务并行与角色协做，构建AI产品研发流水线；
• 自动化迭代。具有研发环节内部、环节之间的自动化迭代、流转功能；
• 对接数据平台。数据中台或其余基础数据服务对接，迅速接入标准化数据，乃至预处理数据；
• 运行监控。提供统一的模型运行环境和监控能力，以及模型更新机制；
• 资源管控。统一资源管理，包括计算资源、存储资源等，支持资源弹性调度。

结合上述能力，咱们针对AI中台给出一个探讨性的定义：

AI中台是一套完整的智能模型全生命周期管理平台和服务配置体系，基于数据平台服务，经过对智能服务的共享复用、对智能服务研发相关角色进行管理，以及研发流程的标准化、自动化，对前台业务提供个性化智能服务的迅速构建能力支持。

3、AI中台的实施路线

前文咱们介绍了AI中台产生的背景、能力以及定义，本节将重点介绍AI中台的实施路线。

3.1 AI中台的主要成分

上图展现的是AI产品研发的生命周期，业务需求进来，要通过业务理解、模型学习、数据处理和运行监控四个大的步骤。

这四个步骤加上中台管理构成了AI中台主要成分：

• 业务理解，根据业务需求设计实施方案，服务编排，通用方案模板管理；
• 数据处理，包括数据获取和数据准备与分析；
• 模型学习包括特征工程、模型训练和模型评估，以及可复用模型库、算法库管理；
• 运行监控包括模型自动部署运行、性能监控和对外服务接口管理。
• 此外，为了便于对AI中台进行角色、权限统一控制和资源管控，咱们还设置了中台管理模块。

3.2 从平台到中台的构建

构建数据中台时咱们通常会采用从平台到中台演进的策略，AI中台的构建也是如此。

从平台到中台的跃迁过程当中须要参考常见的机器学习平台，包括训练平台，部署/运行平台、监控平台、标注平台、建模平台、数据处理平台等。

咱们能够根据现有平台完成AI中台的构建。建模平台具有业务建模、服务/模型建模的功能，可用于业务理解和模型学习的环节；训练平台具有模型自动化训练优化评估功能，可用于模型学习环节；数据处理环节须要进行数据分析、样本分析，能够用到数据处理平台和标注平台；而部署/运行平台和监控平台可为运行监控环节提供支持。因而可知，咱们可以根据现有平台完成AI中台的构建。

上图是AI中台的能力图谱。

• 不论企业仍是AI训练团队，最先都是从基础设施出发，包括数据接入、高性能计算资源、运行环境资源等；
• 而后在保障稳定的基础之上得到训练工具，包括模型训练追踪能力、算法框架支持能力等，实现过程的自动化；
• 有了训练工具的支撑，咱们能够把经常使用的业务和环节进行聚拢和集中配置，造成AI平台，包括模型/服务结构可配置化、模型算法可复用化等，造成标准化的AI研发过程；
• AI中台其实是对现有能力进行整合串联，实现生命周期的管理，包括服务编排共享能力、方案可复用能力、全流程管理能力等，在标准之上实现提效，达到高效的目的。

上图将AI中台能力分别与成分、平台进行映射，而且以颜色进行区分与对应。

值得注意的是，这里咱们只列出了部分中台能力，根据中台对业务的支持须要还可能会包含其余能力，须要咱们去建设；此外，平台对中台的支持也是有限的，缺少的功能或不全面的功能都要咱们去丰富。

3.3 AI中台的流程及架构

上图从前台业务需求出发，根据AI中台的五个成分列出AI中台建设所需的主要功能组件。

• 业务理解部分包括方案模板管理、方案设计、服务编排、服务共享等；
• 数据处理部分包括数据展现、数据访问、数据分析、数据标注等；
• 模型学习部分包括服务设计、特征处理、模型训练、模型追踪、模型库、算法库等；
• 运行监控部分包括具体的产品封装、自动部署、性能监控、访问接口管理、模型更新和发布测试等；
• 中台管理部分包括角色权限、资源管理、租户管理和流程控制等。

将前文所述的功能构件映射到AI项目生命周期中得出上图所示的整体运转流程。

• 从业务需求开始，对业务进行理解，包括方案模板参考、方案设计、服务编排、服务共享等，若是须要复用其余服务，能够在这里进行访问配置；
• 数据处理部分的工做经过数据中台来完成，数据中台向上提供数据参考、向下提供模型训练及监控的支持；
• 模型训练部分造成比较复杂的循环，由于其自己就是一个自动化迭代的过程；
• 封装部分涉及到监控和对外提供访问接口等功能；
• 中台管理在底部提供构建支持。

下文将对各部分运转流程进行详细拆解。

业务理解中心

业务理解中心的运转流程如上图所示：

• 业务需求进来以后，先从数据处理中心获取数据分析和参考，采集数据样本提供可视化支持；
• 而后进行方案选择：是否具有可复用的方案模板？“是”即直接复用方案，只需改变数据；“否”即进行方案设计。
• 接下来是分解方案到各个服务中，并对服务进行合理有效的编排。此处还需考虑哪些服务可供复用；
• 最后输出三个方面的内容：向数据处理中心输出数据获取要求；向运行监控中心输出产品封装指导；向模型学习中心输出模型训练任务。

业务理解中心运转流程主要涉及三个角色：

• 业务分析师，分析相关方案设计、服务编排；
• 数据分析师，提供数据建议、方案设计建议；
• 算法工程师，考虑服务编排、服务之间的数据接口等。

数据处理中心

数据处理中心的运转流程如上图所示：

• 从业务处理中心获取数据要求规范，经过数据访问对接数据中台；
• 基于数据中台向上提供数据分析功能、数据展现及功能可视化；
• 经过数据展现得到参考，对数据进行标注；
• 操做数据访问，返回到数据中台，对数据进行从新加工。
• 最后对对外输出三个方面的内容：向业务理解中心输出数据分析参考；向模型学习中心输出模型训练数据；向运行监控中心输出生产数据。

数据处理中心运转流程主要涉及四个角色：

• 数据分析师，要求对其中主要环节都有涉猎；
• 业务分析师和算法工程师主要关注数据展现；
• 标注工程师，主要参与数据标注环节。

模型学习中心

模型学习中心是算法工程师的主要阵地，该部分的运转流程如上图所示：

• 接收来自业务理解中心的模型服务任务、数据处理中心的训练数据、运行监控中心的性能矫正信息，进行服务设计。服务设计时要考虑须要多少个模型？模型之间如何串联？算法库和模型库中是否有可供复用的算法与模型？
• 服务流程设计完成后进行特征处理；
• 将特征输入模型进行编码和训练；
• 将模型训练结果输入模型追踪的功能组件进行模型评估；
• 通过迭代得到最优训练模型输出到运行监控中心，同时输出数据操做到数据处理中心。

运行监控中心

运行监控中心是与业务用户直接相关的一环，由运维人员进行模型更新和性能监控。该部分的运转流程如上图所示：

• 接收数据处理中心提供的生产数据，经过访问接口处理输出，写回到数据处理中心；
• 接收模型学习中心的已训练模型服务、业务理解中心的产品封装指导，对产品服务进行串联封装、部署、发布、测试；（若是要封装的产品是对已有产品的更新，则先经过模型更新机制对现有模型进行合理启停更新操做以后再部署发布测试。）
• 向上将交互数据提供给访问接口，并对访问接口进行配置；向下提供性能指标给性能监控，若是发现问题及时报警，并反馈到模型学习中心进行从新训练。

AI中台层级架构

AI中台的层级架构如上图，AI中台处于数据模型服务与业务解决方案之间，向上链接业务向下沟通数据，每个层级都有其可复用的机制。

中间部分从上而下分红业务理解、模型学习、数据处理三大板块；右侧的运行监控对产品和模型进行统一封装、对外统一的访问接口等；左侧是贯穿于整个流程始终的平台管理，包括角色权限、租户管理、流程控制、资源管理等。

4、实例分析-智能投顾机器人

上文对中台实施路线进行了较为详细的介绍，本节将结合宜信内部智能投顾机器人的实践案例分析AI中台如何解决实际业务中的智能化需求。（因为智能投顾机器人是一个比较大的解决方案，此处作了适当抽象和缩减。）

4.1 智能投顾机器人

智能投顾是经过人工智能算法，在线提供自动化的资产组合配置建议和财富的管理服务。例如宜信旗下的智能理财产品：投米RA，就是经过智能化的方式帮助用户作科学的资产配置，从而实现财富管理方式的升级。

智能投顾机器人涉及的AI服务及数据：

• 智能交互，好比聊天机器人；
• 客户画像，对于已有客户积累的公司来讲这部分数据已经具有；
• 筛选产品池，从现有理财产品池中筛选表现最优的产品，目前咱们的理财产品池能够实现定时批量处理，自动化筛选出每一个时期表现较好的精选产品；
• 风险分析，做为一个金融领域的智能应用，风险分析尤其重要，用户能承受什么样的风险、基于该风险值能取得怎么样的回报等都要有合理的分析；
• 资产配比，宜信目前有不少类型的资产，如基金、股票、房产等，还会进行全球化的资产配比，这就须要科学、理性、量化的分析，归入风险因子进行综合考量，实现资产配比；
• 投资产品推荐，参考用户画像里的我的信息、风险分析、资产配比等，为用户推荐最优化收益产品。

了解了智能投顾机器人的特征以后，咱们结合AI中台的运转流程具体来看该案例的实施。

4.2 案例实施

业务理解

在业务理解环节，首先须要考虑业务方案是什么样的？是否可复用？假设有可复用的方案，直接接入数据便可；若是没有可复用的方案，则须要设计新的方案。

如上图右侧的设计导图所示，须要考虑数据接口配置和数据源/角色配置。好比方案的数据接口有哪些？涉及到哪些服务？如何返回？每一个结构里相关的角色有哪些？等等。

最重要的是考虑哪些服务是可复用的？假设公司内部已经有了一个聊天机器人，那么这里彻底能够用它来接待客户，承担智能聊天的功能；此外财富产品画像服务也已经有了，直接把筛选产品词这部分产生的数据源接入进来便可；而资产配比服务，咱们可能有相关的线下模型，而且已经将它进行服务化封装。以上这些服务均可复用，风险分析服务及后续投资产品推荐服务须要新建。

可复用的服务、需新建的服务明确以后，各个团队能够并行开发，角色配置也是如此，如此很快即可进入下一阶段，提升了开发的效率。

模型学习

延续上一阶段的实践，对风险分析服务进行实际模型设计与训练。

从方案设计获取模型服务job，设计服务流程，它的输入是一个筛选后的用户画像，如上图右侧的结构所示，设计了两个比较简单的模型：一个是风险承受能力测评模型，这个模型之上还复用了一个已有的特征筛选模型，配合将用户画像里适合模型的有用特征提取出来并输入到模型中；另外一个是流动性需求模型，评估资产需求，这里加了一个Python的代码片断对用户画像的数据进行加工再输入模型中。底下还新建了一个模型，对数据进行合并和输出。

该模型可进行自动训练、可视化追踪。模型编排肯定后，任务自动发送给工程师，能够在终端上经过交互式编程界面进行开发，以后对代码进行上传，在托管服务器能够将代码直接发布到训练集群上，自动进行训练，以后将训练结果推送到追踪服务器上，获取相关数据进行模型调优反复迭代，同时追踪服务器会记录每一次指标及模型，可选择最优的模型发布给监控中心。

运行监控

运行监控主要对服务和方案进行封装、测试、发布，包括接口配置。能够单个服务测试，也能够整个方案一块儿进行测试。

服务上线以后，经过提供可视化支持以及相关统计报表对整个性能进行合理监控，如上图所示，一旦发现报警，可回到模型学习中心，进行从新训练。

数据处理

前面几个部分都跟数据处理相关，数据处理的部分直接交给数据中台来完成，AI中台只提供数据中台的访问接口，主要操做包括：经过数据中台的可视化工具观察数据，利用数据中台数据模型预处理数据，标注平台开展各模型数据标注。其最终目标是支持模型训练过程当中访问数据中台绑定训练数据，好比文件、数据库以及其余数据存储系统。

上图右侧展现的是宜信已经开源的工具，包括DBus、Wormhole、Moonbox、Davinci，能够帮助你们更好地构建数据中台。

5、总结

以上部分介绍了AI中台产生的背景、目标、定义、实施路线。

• AI中台的构建能够复用现有的技术、能力和平台，是一种敏捷的智能业务支持方案；
• AI中台是数据/业务智能化发展的产物，以自动化模型代替人工流转，下降资源和人员成本；
• AI平台的能力建设基于数据平台/中台，面向前台业务需求，提高响应业务需求的能力。
• 经过AI中台沉淀技术、共享服务、优化流程、整合资源、下降成本、提高效率是咱们构建AI中台的最终目标，要想实现这一目标，还须要一个比较漫长的探索和实践过程。

从平台到中台，面向业务一步步实现跃迁，这是一个按部就班的过程，不可一蹴而就。企业实施落地中台化战略，最重要的是从本身的业务实际、具体的研发条件出发，以共享服务、整合资源、下降成本、提高效率为目标，创建符合业务需求的中台体系和方法论。

6、Q & A

Q1: AI中台要从哪些维度来评估需求的重要程度？业务需求多种多样，如何设计可复用的AI模型？

A: 评估需求的部分不该交由AI中台来完成，在业务前台将需求提交过来时应该与业务分析专家、需求分析专家进行合理的讨论肯定项目的优先级，评定的维度主要从业务的重要性、影响客户的范围、时间紧迫性等维度出发综合评估，通常在专门的需求分析系统中完成。

AI模型的可复用设计问题实在太泛化了，主要从业务中自行体会，对于有经验的架构师能够比较容易地识别出不一样粒度下的复用方案设计。这里简单从不一样层次讨论一下。算法级没必要多说，而模型级别主要考虑单个模型的功能粒度，通常来讲咱们不建议一个模型过于复杂，过于复杂的功能咱们一般会采用多个模型分别实现各功能，再在服务设计中经过模型编排来实现；模型的通用性须要定义好模型的数据接口，以及模型结构，考虑模型重训练和增量训练的机制，便于复用时进行模型适应；此外模型的功能通用性一样须要关注。服务级别的复用相对比较容易识别，是比较固定和独立的场景服务，例如聊天机器人、客户风控等等，通常须要复用的服务基本不须要过多的重训练和调整，相对固定，直接调用或简单配置后调用便可，服务的复用设计相似于SOA过程当中web服务的设计，增长考虑服务的可配置性。方案级别的复用比较少，由于解决方案已是一套相对固定的产品了，咱们主张的复用也更相似于一种模板和指导架构，中间的服务模型填充由用户本身实现，因此方案级别的复用设计能够直接从重要的产品抽象。

Q2: 这些平台都已经落地了吗？对业务提高的效果是怎样的呢？

A: 已经部分落地，不断完善中，研发速度快了，工程师省事了，效率高了，对业务输出的智能化产品也多了:)

Q3: 请问大家这边AI中台是否对外输出，是否支持本地化部署？

A: AI中台在发育成熟后会考虑将部分能力以工具的形式对外发布，本地化部署固然在咱们的考虑以内。

Q4: 前台和中台是否会出现分工不明确的问题，怎么才能更好的解决？

A: 映射到咱们的研发流程里，前台和中台的划分仍是很明确的，前台在肯定研发计划时，将只负责前台业务逻辑的设计和交互管理，对于其他的数据功能、AI功能会直接推送到技术中台、数据中台、AI中台等中台模块获取支持；而前台和中台的划分在组织架构层面获得了更加清晰的划分，业务团队的不一样反映了工做性质的不一样，二者惟一可能出现交叉的人员角色就是业务分析专家了，可能来自于前台团队，但其权限也是有限的，角色分工彻底经过中台管理进行配置，各个环节所能映射的角色是不一样的，因此不会出现前台业务人员介入算法工做的状况，也能够管理技术人员参与业务分析的程度。总而言之，前台和中台的划分是企业中台化战略的一个重要环节，不光要从业务流程上梳理，还要对组织架构、人员职责进行统一的调整。

【以上为井玉欣博士分享的所有内容】