内容来源:宜信技术学院第1期技术沙龙-线上直播|AI中台:一种敏捷的智能业务支持方案
主讲人介绍:井玉欣 宜信技术研发中心AI应用团队负责人
本文字数:13479字 阅读用时:34分钟
导读:随着“数据中台”的提出和成功实践,各企业纷纷在“大中台,小前台”的共识下启动了自己的中台化进程,以数据中台、技术中台、业务中台为代表的一系列技术,极大增强了业务的敏捷性,提高了组织效能。同时随着智能技术的发展,AI应用在业务研发中的占比逐渐升高,但AI模型训练的复杂性导致其开发慢、效率低,严重影响了业务的灵活性。
针对这种情况,能否基于中台化思想对业务中AI研发工作进行专门支持,提供对智能需求的迅速实现和灵活试错功能,从而提升企业智能创新能力?AI中台的构建和实施又该如何进行?
本次直播宜信研发中心AI应用团队负责人井玉欣博士结合宜信目前实际业务和中台化战略在宜信的实施情况对以上问题进行了探讨。以下是本次分享的实录。
分享大纲:
一、AI中台的提出
二、AI中台的目标和定义
三、AI中台的实施路线
四、实例分析-智能投顾机器人为例
五、总结
六、Q&A
PPT:https://pan.baidu.com/s/1-nqZMnEogF2DeBS49lkxOA
视频:https://v.qq.com/x/page/e0856o2su0x.html
分享实录
一、AI中台的提出
1.1 中台战略的兴起
自从中台战略被提出并得到成功实施后,业界反响强烈,国内各家企业纷纷启动了自己的中台化进程。尤其是对于在战略中处于核心地位的数据中台建设,各方都有自己的解读和心得。
但总体来看,业界形成了对中台战略的一些共识,即主张“大中台、小前台”,通过构建中台,沉淀共享服务,提高服务重用率,打破“烟囱式”、“项目制”系统之间的集成和协作壁垒,降低前台业务的试错成本,赋予业务快速创新能力,最终提升企业的组织效能。
无论是在金融、在线交易、资讯、医疗还是教育行业,业界对中台战略的研讨包括企业日常活动中的各个环节,例如业务中台、技术中台、移动中台等等,但在数据时代,企业中的大量业务都运行于大数据之上,数据的响应能力、处理能力决定了业务效率,所以中台战略中最主要的、也是实施的起点,仍然是数据中台。数据中台实现了组织内数据标准的统一,并打破数据壁垒,构建统一数据实体,对外提供统一的数据服务。通过这三个“统一”实现了组织内的数据资产中心,为前台业务提供了自动化、自助化的敏捷数据能力输出。
自动化的优势是可以极大节省常规数据操作的成本开销,而自助化数据管理可以支持业务用户根据自己需求自助式地获取、处理数据,灵活实现业务需求。但这两个优势相比于传统“烟囱式”数据系统来说,只是使业务方感觉数据服务更加能用、易用而已,想要真正做到好用,甚至让业务方喜欢用,无论是数据中台还是其他中台服务,都离不开智能化的能力。
1.2 智能业务需求的中台化
业务的智能化需求来自于两方面:
上图是一个示例,数据来源于Roland Berger。宜信作为一家金融科技公司,更多面对的是金融领域的智能业务需求。从图中可以看到在金融这一个领域之内就有这么多环节已经形成了标准化的智能应用,可想而知在今天企业业务的发展过程中智能化正在扮演一个多么重要的角色。
无论是哪方面的需求,都会碰到一个问题:智能业务需求各种各样、各不相同,一个需求下来,研发团队需要针对性开展数据分析处理、模型的构建训练等,过程复杂繁复,效率不高,从而拖长了需求响应时间,降低了业务敏捷程度,拉高了试错成本。这与在中台战略背景下,业务前台希望能够专注于业务逻辑、灵活应对变化产生了矛盾,而且随着智能化应用的广泛开展,这个矛盾也越来越普遍。
究其原因,一方面是由于智能化的大规模兴起才短短几年,智能应用研发还处在比较原始的阶段,缺乏完整的生命周期管理理论和相应的管理框架工具;另一方面则反映了我们的中台能力没有完全覆盖到前台业务研发中笨重、重复、低效的环节。
那么,我们自然而然会想到,我们能否对现有数据中台进行进一步智能化跃迁,解决上述问题呢?如果能,数据中台可以或者应该提供什么样的数据智能化能力?如果不能,中台战略又应该如何敏捷支持智能化业务需求?
1.3 从数据中台到AI中台
我们先来看看数据中台的智能化支持能力,试分析如下问题:数据中台能通过通用的智能数据模型充分支持当前业务背景下多样的智能需求吗?答案是比较困难,原因在于业务智能化过程的复杂性。
通常的机器学习任务包括了回归、分类、标注、聚类、推荐等等,每个算法模型的实现又包括了数据预处理、特征分析、建模、训练、部署等多个环节,实际中的应用更是有可能包括多个模型。
而数据中台以数据为核心,其智能化能力若想支持到以上所有环节,工作量绝对不小,并且会偏离数据中台的原有目标,因此让数据中台承担全部的智能化业务支持是不合适的。
详细来说,我们可以从目前人工智能(AI)所涵盖的内容进行分析。广义上人工智能指利用科学方法和技术,研制能够模仿、延伸、扩展人类智能的机器系统,涉及了计算机科学、数学、哲学、心理学等多门学科;而从计算机科学的角度狭义来看,人工智能特指可以接受和处理外部数据,并能够做出类人化分析、决策的计算机系统,涵盖了数据挖掘、机器学习、深度学习、强化学习等多个子领域。如无特殊说明,本文所述人工智能皆指后者。
这几类任务中,机器学习、深度学习、强化学习的目标、实施过程比较相似,因此通常直接统称为机器学习任务,本文也采取这种概略性说法。而数据挖掘任务则与机器学习任务相关又不太相同,他们之间的区别给很多人带来过困扰。
实际上,按照《数据挖掘与预测分析》书中的定义,“数据挖掘是从大型数据集中发现有用的模式和趋势的过程”,这其中包括了数据预处理、数据探索、数据降维、数据统计、关联分析、离群分析等子任务,这些是机器学习工作开展的基础。
而另一方面,数据挖掘还包含了之后的数据聚类、数据预测、数据分类的一些内容,这些正是机器学习所研究的部分内容;由于机器学习的蓬勃发展和优异性能表现,一般此部分的工作也更多交由机器学习来完成。
总之,两者都是人工智能的重要研究方向,也是企业大数据智能化过程中的重要环节,彼此相互联系,但侧重点存在不同:数据挖掘更侧重于“洞察”,而机器学习更侧重于“学习”和“预测”。
从上述分析可以看出,当前业务背景下,从事“洞察”任务的数据挖掘工作将重心放在了数据上,一般不需要人工辅助即可自动化完成;此外由于不涉及数据预测、分类等任务,数据挖掘通常采用比较固定的分析算法和模型,所以该部分工作完全可以做到自动化、自助化,集成到数据中台内,作为固定的智能数据模型服务提供给业务用户。
另一方面,从事“学习”和“预测”任务的机器学习工作相对而言更加复杂:
了解了人工智能领域分类后,我们来试图回答一下前面提出的问题。如果数据中台愿意支持业务所提出的智能化需求,那么我们要怎么对数据中台进行跃迁?或者说数据中台要怎么跃迁自己的能力来支持这些需求呢?
从上图可以看出,数据中台本身具备以数据为核心、算法固定、有一定的自动性等特征,我们完全可以在数据中台里利用其流式计算能力、批量计算能力、数据可视化技术等来为相应的业务需求提供支持。
这些还都是数据中台本身就已经具备的功能。如果还要用数据中台来做机器学习部分的AI项目支持,还需要具备哪些能力呢?如上图所示,一圈一圈地往外扩展。首先需要复杂的特征工程支持能力、模型训练能力;其次需要数据标注能力、模型部署能力、性能监控能力。
每一项能力都需要耗费大量的人力物力和时间来进行开发,而且由内而外的能力扩展与数据本身的相关性是由强至弱的,也就是说随着能力层次的不断扩充,数据中台逐渐偏离了其“以数据为核心”的宗旨,而且也会使得数据中台变得臃肿复杂,在对接前台业务需求的时候,也可能会带来更多复杂性的问题。因此数据中台可以一定程度上支持智能化业务需求,但如果想单靠数据中台来支持所有智能化业务需求显然不是最佳选择。
那么我们要怎么做呢?将AI中台与数据中台进行分离。
如上图,我们将数据中台外面套着的几层能力抽象剥离出来,整合形成一个独立的中台层,依托数据中台进行一定的协作,共同应对前台的智能化业务需求。数据中台主要集成数据挖掘、数据洞察智能算法和模型;新的中台主要承担复杂的学习预测类智能需求研发。这一中台我们称之为“AI中台”。
上图是AI中台与数据中台分离的结构化图表,自上而下分别是业务前台、AI中台和数据中台,还有底层一些相关的计算存储资源。
值得注意的是,上图所示结构只是一个示例,中台主要面向业务,是为了更敏捷地响应业务需求,因此中台体系应该针对业务来设置,比如有一些前台业务不需要AI中台可以直接落到数据中台来进行处理。
至此我们已经回答了前文的问题,单纯依赖数据中台来支持业务智能化需求的敏捷实施是不够的,但我们可以在其基础之上构建专门的AI中台来提供这一能力。中台化战略中不能单独依赖数据中台来实现中台化转型,阿里的共享服务中心也是包括了业务、技术、数据等多个层面的内容,各企业应该按照自己的业务结构与流程,合理抽象构思自己的中台服务模型并加以实施。
二、AI中台的目标与定义
前文通过对智能化业务需求和数据中台的分析解释了建设AI中台的背景和原因,但AI中台的目标究竟是什么?其基本要求和能力有哪些?接下来我们将对此进行详细讨论。
2.1 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中台的实施路线
前文我们介绍了AI中台产生的背景、能力以及定义,本节将重点介绍AI中台的实施路线。
3.1 AI中台的主要成分
上图展示的是AI产品研发的生命周期,业务需求进来,要经过业务理解、模型学习、数据处理和运行监控四个大的步骤。
这四个步骤加上中台管理构成了AI中台主要成分:
3.2 从平台到中台的构建
构建数据中台时我们一般会采用从平台到中台演进的策略,AI中台的构建也是如此。
从平台到中台的跃迁过程中需要参考常见的机器学习平台,包括训练平台,部署/运行平台、监控平台、标注平台、建模平台、数据处理平台等。
我们可以根据现有平台完成AI中台的构建。建模平台具备业务建模、服务/模型建模的功能,可用于业务理解和模型学习的环节;训练平台具备模型自动化训练优化评估功能,可用于模型学习环节;数据处理环节需要进行数据分析、样本分析,可以用到数据处理平台和标注平台;而部署/运行平台和监控平台可为运行监控环节提供支持。由此可见,我们能够根据现有平台完成AI中台的构建。
上图是AI中台的能力图谱。
上图将AI中台能力分别与成分、平台进行映射,并且以颜色进行区分与对应。
值得注意的是,这里我们只列出了部分中台能力,根据中台对业务的支持需要还可能会包含其他能力,需要我们去建设;此外,平台对中台的支持也是有限的,缺乏的功能或不全面的功能都要我们去丰富。
3.3 AI中台的流程及架构
上图从前台业务需求出发,根据AI中台的五个成分列出AI中台建设所需的主要功能组件。
将前文所述的功能构件映射到AI项目生命周期中得出上图所示的总体运转流程。
下文将对各部分运转流程进行详细拆解。
业务理解中心
业务理解中心的运转流程如上图所示:
业务理解中心运转流程主要涉及三个角色:
数据处理中心
数据处理中心的运转流程如上图所示:
数据处理中心运转流程主要涉及四个角色:
模型学习中心
模型学习中心是算法工程师的主要阵地,该部分的运转流程如上图所示:
运行监控中心
运行监控中心是与业务用户直接相关的一环,由运维人员进行模型更新和性能监控。该部分的运转流程如上图所示:
AI中台层级架构
AI中台的层级架构如上图,AI中台处于数据模型服务与业务解决方案之间,向上连接业务向下沟通数据,每一个层级都有其可复用的机制。
中间部分从上而下分成业务理解、模型学习、数据处理三大板块;右侧的运行监控对产品和模型进行统一封装、对外统一的访问接口等;左侧是贯穿于整个流程始终的平台管理,包括角色权限、租户管理、流程控制、资源管理等。
四、实例分析-智能投顾机器人
上文对中台实施路线进行了较为详细的介绍,本节将结合宜信内部智能投顾机器人的实践案例分析AI中台如何解决实际业务中的智能化需求。(由于智能投顾机器人是一个比较大的解决方案,此处做了适当抽象和缩减。)
4.1 智能投顾机器人
智能投顾是通过人工智能算法,在线提供自动化的资产组合配置建议和财富的管理服务。例如宜信旗下的智能理财产品:投米RA,就是通过智能化的方式帮助用户做科学的资产配置,从而实现财富管理方式的升级。
智能投顾机器人涉及的AI服务及数据:
了解了智能投顾机器人的特征之后,我们结合AI中台的运转流程具体来看该案例的实施。
4.2 案例实施
业务理解
在业务理解环节,首先需要考虑业务方案是什么样的?是否可复用?假设有可复用的方案,直接接入数据即可;如果没有可复用的方案,则需要设计新的方案。
如上图右侧的设计导图所示,需要考虑数据接口配置和数据源/角色配置。比如方案的数据接口有哪些?涉及到哪些服务?如何返回?每个结构里相关的角色有哪些?等等。
最重要的是考虑哪些服务是可复用的?假设公司内部已经有了一个聊天机器人,那么这里完全可以用它来接待客户,承担智能聊天的功能;此外财富产品画像服务也已经有了,直接把筛选产品词这部分产生的数据源接入进来即可;而资产配比服务,我们可能有相关的线下模型,并且已经将它进行服务化封装。以上这些服务都可复用,风险分析服务及后续投资产品推荐服务需要新建。
可复用的服务、需新建的服务明确之后,各个团队可以并行开发,角色配置也是如此,如此很快便可进入下一阶段,提高了开发的效率。
模型学习
延续上一阶段的实践,对风险分析服务进行实际模型设计与训练。
从方案设计获取模型服务job,设计服务流程,它的输入是一个筛选后的用户画像,如上图右侧的结构所示,设计了两个比较简单的模型:一个是风险承受能力测评模型,这个模型之上还复用了一个已有的特征筛选模型,配合将用户画像里适合模型的有用特征提取出来并输入到模型中;另一个是流动性需求模型,评估资产需求,这里加了一个Python的代码片段对用户画像的数据进行加工再输入模型中。底下还新建了一个模型,对数据进行合并和输出。
该模型可进行自动训练、可视化追踪。模型编排确定后,任务自动发送给工程师,可以在终端上通过交互式编程界面进行开发,之后对代码进行上传,在托管服务器可以将代码直接发布到训练集群上,自动进行训练,之后将训练结果推送到追踪服务器上,获取相关数据进行模型调优反复迭代,同时追踪服务器会记录每一次指标及模型,可选择最优的模型发布给监控中心。
运行监控
运行监控主要对服务和方案进行封装、测试、发布,包括接口配置。可以单个服务测试,也可以整个方案一起进行测试。
服务上线之后,通过提供可视化支持以及相关统计报表对整个性能进行合理监控,如上图所示,一旦发现报警,可回到模型学习中心,进行重新训练。
数据处理
前面几个部分都跟数据处理相关,数据处理的部分直接交给数据中台来完成,AI中台只提供数据中台的访问接口,主要操作包括:通过数据中台的可视化工具观察数据,利用数据中台数据模型预处理数据,标注平台开展各模型数据标注。其最终目标是支持模型训练过程中访问数据中台绑定训练数据,比如文件、数据库以及其他数据存储系统。
上图右侧展示的是宜信已经开源的工具,包括DBus、Wormhole、Moonbox、Davinci,可以帮助大家更好地构建数据中台。
五、总结
以上部分介绍了AI中台产生的背景、目标、定义、实施路线。
从平台到中台,面向业务一步步实现跃迁,这是一个循序渐进的过程,不可一蹴而就。企业实施落地中台化战略,最重要的是从自己的业务实际、具体的研发条件出发,以共享服务、整合资源、降低成本、提升效率为目标,建立符合业务需求的中台体系和方法论。
六、Q & A
Q1: AI中台要从哪些维度来评估需求的重要程度?业务需求多种多样,如何设计可复用的AI模型?
A: 评估需求的部分不应交由AI中台来完成,在业务前台将需求提交过来时应该与业务分析专家、需求分析专家进行合理的讨论确定项目的优先级,评定的维度主要从业务的重要性、影响客户的范围、时间紧迫性等维度出发综合评估,一般在专门的需求分析系统中完成。
AI模型的可复用设计问题实在太泛化了,主要从业务中自行体会,对于有经验的架构师可以比较容易地识别出不同粒度下的复用方案设计。这里简单从不同层次讨论一下。算法级不必多说,而模型级别主要考虑单个模型的功能粒度,一般来说我们不建议一个模型过于复杂,过于复杂的功能我们通常会采用多个模型分别实现各功能,再在服务设计中通过模型编排来实现;模型的通用性需要定义好模型的数据接口,以及模型结构,考虑模型重训练和增量训练的机制,便于复用时进行模型适应;此外模型的功能通用性同样需要关注。服务级别的复用相对比较容易识别,是比较固定和独立的场景服务,例如聊天机器人、客户风控等等,一般需要复用的服务基本不需要过多的重训练和调整,相对固定,直接调用或简单配置后调用即可,服务的复用设计类似于SOA过程中web服务的设计,增加考虑服务的可配置性。方案级别的复用比较少,因为解决方案已经是一套相对固定的产品了,我们主张的复用也更类似于一种模板和指导架构,中间的服务模型填充由用户自己实现,所以方案级别的复用设计可以直接从重要的产品抽象。
Q2: 这些平台都已经落地了吗?对业务提升的效果是怎样的呢?
A: 已经部分落地,不断完善中,研发速度快了,工程师省事了,效率高了,对业务输出的智能化产品也多了:)
Q3: 请问你们这边AI中台是否对外输出,是否支持本地化部署?
A: AI中台在发育成熟后会考虑将部分能力以工具的形式对外发布,本地化部署当然在我们的考虑之内。
Q4: 前台和中台是否会出现分工不明确的问题,怎么才能更好的解决?
A: 映射到我们的研发流程里,前台和中台的划分还是很明确的,前台在确定研发计划时,将只负责前台业务逻辑的设计和交互管理,对于其余的数据功能、AI功能会直接推送到技术中台、数据中台、AI中台等中台模块获取支持;而前台和中台的划分在组织架构层面得到了更加清晰的划分,业务团队的不同反映了工作性质的不同,两者唯一可能出现交叉的人员角色就是业务分析专家了,可能来自于前台团队,但其权限也是有限的,角色分工完全通过中台管理进行配置,各个环节所能映射的角色是不同的,所以不会出现前台业务人员介入算法工作的情况,也可以管理技术人员参与业务分析的程度。总而言之,前台和中台的划分是企业中台化战略的一个重要环节,不光要从业务流程上梳理,还要对组织架构、人员职责进行统一的调整。
【以上为井玉欣博士分享的全部内容】