宜信技术学院

1.1 中台战略的兴起

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

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

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

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

1.2 智能业务需求的中台化

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

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

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

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

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

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

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

1.3 从数据中台到AI中台

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

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

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

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

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

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

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

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

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

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

• 机器学习的实施过程通常是高度计算密集型的；

• 所采用算法和模型结构有可能相同，但都需要根据业务数据进行个性化参数训练；

• 训练阶段通常经过多次迭代；

• 除部分非监督学习外，实施环节通常需要人工标注环节的参与；

• 线上模型的运行性能需要监控，需要根据数据演进进行更新。

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

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

这些还都是数据中台本身就已经具备的功能。如果还要用数据中台来做机器学习部分的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模型，例如金融业务领域内的通用自然语言理解模型等。这样我们只需维护、更新这套模型，该领域内的所有智能化相关需求都可以随时地复用该模型库，从而节省大量的任务训练时间。

再进一步，我们甚至可以预先训练一个全领域的横向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中台产生的背景、能力以及定义，本节将重点介绍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中台处于数据模型服务与业务解决方案之间，向上连接业务向下沟通数据，每一个层级都有其可复用的机制。

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

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

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

4.1 智能投顾机器人

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

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

• 智能交互，比如聊天机器人；

• 客户画像，对于已有客户积累的公司来说这部分数据已经具备；

• 筛选产品池，从现有理财产品池中筛选表现最优的产品，目前我们的理财产品池可以实现定时批量处理，自动化筛选出每个时期表现较好的精选产品；

• 风险分析，作为一个金融领域的智能应用，风险分析尤为重要，用户能承受什么样的风险、基于该风险值能取得怎么样的回报等都要有合理的分析；

• 资产配比，宜信目前有很多类型的资产，如基金、股票、房产等，还会进行全球化的资产配比，这就需要科学、理性、量化的分析，纳入风险因子进行综合考量，实现资产配比；

• 投资产品推荐，参考用户画像里的个人信息、风险分析、资产配比等，为用户推荐最优化收益产品。

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

4.2 案例实施

业务理解

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

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

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

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

模型学习

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

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

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

运行监控

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

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

数据处理

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

上图右侧展示的是宜信已经开源的工具，包括DBus、Wormhole、Moonbox、Davinci，可以帮助大家更好地构建数据中台。

五、总结

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

• AI中台的构建可以复用现有的技术、能力和平台，是一种敏捷的智能业务支持方案；

• AI中台是数据/业务智能化发展的产物，以自动化模型代替人工流转，降低资源和人员成本；

• AI平台的能力建设基于数据平台/中台，面向前台业务需求，提升响应业务需求的能力。

• 通过AI中台沉淀技术、共享服务、优化流程、整合资源、降低成本、提升效率是我们构建AI中台的最终目标，要想实现这一目标，还需要一个比较漫长的探索和实践过程。

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

六、Q & A

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

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

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

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

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

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

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

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

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