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