从数据中台到AI中台

文章发布于公号【数智物语】 （ID：decision_engine），关注公号不错过每一篇干货。

转自 | ThoughtWorks商业洞见

作者 | 白发川

企业对数据的利用有三个阶段：响应运营，响应业务，创造业务。数据中台解决的是响应业务的问题，第三阶段“创造业务”，则需要AI中台。

01

数据中台的意义

数据中台对一个企业，起着至关重要的作用。在数据中台这个称谓成型之前，各个企业也都在用不同的方式来尽可能地利用数据产生价值。只是在这个过程中，也不得不处理着数据带来的各种问题，比如各个业务系统经年累月以烟囱架构形式存在而导致的数据孤岛、数据隔离、数据不一致等等。因为这些问题实在是过于繁杂，企业开始建立数据团队，或者数据部分开始继续数据整顿工作，因此数据仓库、数据湖、主数据治理等一系列的工作职能应运而生。

本质上，这些工作都是因为业务需要不得不进行的一系列数据治理的动作，对于如何利用数据来发力，并没有形成一个强有力的底座。有点像“头痛医头、脚痛医脚”：各个业务系统规范不一致了，于是开展了元数据治理；数据分析的时候数据关联不上了，于是不得不进行主数据治理。

这样的数据治理工作在进行了很多年后，数据中台这个概念逐渐有人提出了，阿里的《企业IT转型直到：阿里巴巴中台战略思想与架构实践》这本书更是把用中台战略把这个概念推向了一个极致。中台战略中，人们常说：大中台，小前台。在这种模式下，频繁出现的字眼是：共享。那么，到底共享的是什么？答案便是数据的服务。中台战略，并不是搭建一个数据平台，但是中台的大部分服务都是围绕数据而生，更加巧妙的地方是中台战略让数据在数据平台和业务系统之间形成了一个良性的闭环。于是，数据和业务系统融为了一体。

（图1 数据中台所解决的问题）

过去，数据依赖于手工进行，没有软件；有了数据中台，以功能驱动，固定的数据输入，得到固定的数据输出，构建出能用的服务变得更快速、更加的标准化，解决了业务侧的“能用”问题。但是，如何以固定的输入，以产生更灵活多变的输出，提供比如个性化的服务，做到“好用”，数据中台并没有给出答案。

在建立了数据中台架构之后，我们逐步认识到，原来数据的价值并不只是个运营出个参考的分析报表，做一系列的预算。数据中台为大型企业数据利用最大化提供了一个初始的参照方向。当我们发现，深度学习、机器学习等等一系列技术开始在这个平台下施展拳脚的时候，我们可能已经清晰地认识到：中台并不是数据分析利用的终点。

02

企业利用数据的三个发展阶段

如果回顾数据分析的历程，可以归纳发现数据利用大概有如下三个阶段：

响应运营

响应业务

创造业务

（图2 企业对数据的利用，有三个发展阶段）

01

第一阶段：响应运营

响应运营是数据分析最直接也是最原始的诉求。没有谁不关心自己的用户留存率，没有谁不关心自己的营收额；出现了故障、如何分析定位，如何预测预防，运用数据分析自然不过。但是在运营分析过程中，也发现了另外一系列的问题，比如各个业务系统的数据存储格式、存储介质都不相同，在进行基本的运营分析的时候，无法流畅的进行。此时，不得不进行一系列的数据治理。常见的主数据、元数据治理就是发生在这个阶段，只是数据仓库将主数据和元数据治理进行了规范化。

02

第二阶段：响应业务

数据分析停留在运营阶段的时候，对企业来讲最大的感受就是投入产出比不对称。这个问题在大数据爆发的时间点上，更为凸显。例如在今天的业务场景下，传统的数据仓库已经解决不了海量数据、异构数据等一系列问题，而大行其道的大数据分析技术，硬件要求高、学习门槛高。要实施一个大数据平台，成立一个大数据团队，这是一个不小的成本开销，更何况现在有不少数据分析团队要借助机器学习等手段，来对数据做分析来响应运营，这导致基础设施成本、整体门槛进一步提高。

于是像数据中台这样的思想就被提了出来：既然数据是从业务系统产生的，那么是否业务系统也需要数据分析结果呢？对于数据平台来说，数据平台本身提供两大能力：数据存储和数据计算的能力。那么业务系统的数据存储和数据计算能力是否可以剥离到数据平台，仅仅让业务系统很轻量的维护自己的业务流程操作？所以利用中台剥离了复杂的业务环境，再配合微服务等技术，一下子让人感受到了“数据服务的共享”。

而对业务场景来说，很多时候是需要数据服务的，例如用户的基本信息管理、用户的行为数据分析，这些数据不但可以暴露给业务系统使用，甚至可以直接丢给终端用户自行使用。类似这种契合点，让数据平台变成了一个服务，提供给业务系统。而对数据服务的使用者来说，在消费数据的同时也在继续产生数据，这样在数据平台和业务系统之间就构成了一个良性的闭环。

03

第三阶段：创造业务

业务不会总停滞不前，因为人的生活会改变，想要的体验会改变。过去，大家到视频平台看视频，利用通用的数据服务，不同的用户看到的视频推荐都是一样的；很快，我们就会发现根据用户的偏好，推荐个性化的视频几乎是必不可少的体验要求。然后，我们就开始思考：数据是否可以变成个性化服务提供给终端用户？这是一个非常简单、常见的例子。当这样的个性化数据服务越来越多之后，各种服务不断组合，就会创造出很多可能性，进而提供创新的个性化体验和新的业务模式，这就是数据服务用于创造业务的阶段。

虽然有了数据中台，但是当有大规模的、基于智能算法的数据服务需要落地实现时，依然会碰到以下挑战。

1. 如何对规模化的智能服务进行管理：当只是零星三两个智能服务的时候，通过手动人工管理等方式，不会有太大的问题；然则，当智能服务成千上万的时候，如何管理、如何构建、如何高效维护，就会成为很大的麻烦。

2. 没有良好的工程实践来保证质量和流畅性：对于常规的应用软件开发我们有TDD、自动化测试、CI/CD等成熟的工程实践做保障；但是在智能服务这一块，无论是编程开发、还是服务构建，都没有成熟的工程实践，也没有良好的基础设施支撑，非常依赖于构建这个服务的数据工程师的个人能力，导致在实施过程中，问题难以复现，难于定位。

3. 数据安全、治理和数据量不充分：数据中台的价值点，在于提供了数据的计算和存储的能力，但是在智能服务构建下，光有计算和存储还不够。治理到什么程度的数据，才能较好的支撑服务的构建？个性化的服务与数据安全冲突的时候，如何抉择？数据量不足导致算法模型泛化能力太差，怎么办？

（图3 创造业务阶段，数据中台面临的挑战）

03

从数据中台到AI中台

01

什么是AI中台？

数据中台本身还是围绕数据服务来进行的，而非围绕智能服务来进行的。未来的操作系统，一定会越来越个性化，甚至每一个人看到的登录界面都不一样，系统可以根据对应的终端用户自行呈现符合该用户习惯的系统界面。那么对于这样的场景和服务，我们需要怎样的平台？整个软件开发架构和流程是否也都会相应重造？

回到创造业务的需求。以简单的销售业务为例，数据中台提供的服务本质如下图所示：

（图4 软件平台的业务模式）

这是目前最常见的软件平台的运作方式，开发人员开发出了对应的软件服务后，提供给终端用户使用，虽然会有销售售卖该服务。这种方式，好比是拿着一个锤子找钉子，而不是给钉子快速制作一把合适的锤子再去售卖。

能不能这样：将整个软件组装出来的服务，包装成个性化的产品一样去售卖，提供量身定做的服务？那么整个运营模式就变成：平台提供了一种快速构建智能服务的过程，服务售卖者利用这个平台，自己动手构建出服务，拿出去售卖，类似一个提供“智能业务服务的PaaS”。

（图5 引入AI中台的软件平台业务模式）

如果尝试给AI中台下个定义：

AI中台是一个用来构建大规模智能服务的基础设施，对企业需要的算法模型提供了分步构建和全生命周期管理的服务，让企业可以将自己的业务不断下沉为一个个算法模型，以达到复用、组合创新、规模化构建智能服务的目的。

借助一个平台，将软件的服务个性化的创造，这将是未来的发展趋势。

04

从数据中台演进到AI中台

从AI中台落地实施的方式来看，AI中台可以是数据中台的进一步延伸，从数据中台一步一步演进过去。

01

首先，从基础设施角度，可以将数据中台智能化

所谓的智能化，是指将在数据中台进行的一系列的数据服务构建操作进行智能化实现，让数据的接入、存储、分析展现、训练、到构建管道（pipeline）都更加自动化。例如，对于通用的CI/CD来说，测试不过则会构建失败，那对于AI中台下，就要考虑一个推荐模型构建失败的条件是什么？答案可能是“本次模型的准确率低于上一次构建的准确率”的时候，CI应该被构建失败。在实践中，这可能是CI构建过程的维度之一，还会有很多其他指标和维度。我们就需要在现有的数据平台的CI中，实现并自动化这些指标和维度，使之更加智能化。

02

其次，对于中台使用者来说，将烟囱式模型构建过程改造为可复用的模型构建过程

目前基于数据中台的一个智能服务模型开发来说，流程如下：

（图6 烟囱式模型构建过程）

这基本类似于一个横向的烟囱架构，导致目前对一个基于算法模型产生的服务进行拆分的时候，都不是特别地顺畅。如果大部分业务场景依旧以流程为主还好，如果新业务需要引入多的智能服务，那么一系列的问题就会暴露出来：

1. 借助于现有数据平台手工进行数据操作。

2. 烟囱架构开发，对人员能力要求高。

3. 环节无法有效拆分，响应周期慢。

4. 智能场景规模化，管理复杂。

5. 训练，部署，发布依赖于手工部署缺乏有效的流水线。

6. 和数据平台孤立，缺乏统一的数据服务接口。

7. 基础设施隔离，无法动态进行资源的分配和管理。

AI中台需要具备构建智能服务的能力，就要求我们对服务构建的过程进行如下拆分：

（图7 可复用的模型构建过程）

首先需要从基础设施层面进行集成。常规的数据中台依赖于大量的CPU和内存，相反，机器学习模型对GPU的依赖反而更高，但是又不能脱离数据中台，因为它依旧需要利用数据中台的存储和计算能力来处理大量的数据。所以如何通过一个接口、一个调度器、一个管道pipeline来集成整个工作流，就成了需要考量的事情了。

AI中台至少应该分为以下几个层级：

1. 基础设施：对CPU做虚拟化的技术已经相对成熟，但是智能服务依赖的更多的是GPU，那么GPU如何做虚拟化，算法模型训练和数据是否需要共同使用相同的机器，还是集群相互隔离，都是需要在一开始设计好的。

2. 资源管理：一切都是资源，无论是网络、内存，还是数据、服务，都是资源。对于模型构建者，关注的只是算法本身，如果该构建者需要数据，那这样的数据就是一个资源而已，无论资源是以环境变量的方式提供、还是以服务的方式提供，构建者本身并不需要关心。此时，必须一个资源管理系统，对数据服务进行统一管理。

3. 中台和模型：中台有数据的计算和存储能力外，还应该具备算模型的能力，这里的模型指的是一些业界通用的、或者企业级通用算法模型。它可能是一个算法、可能是一个别人已训练好的模型，可以使用迁移学习的方式去使用。对于中台来说，它都是一个数据集的体现，不应该和一个表，一个文件有特别的区分。

4. 流水线：流水是构建规模化智能服务非常重要的一个环节，工作如其名，让我们构建智能服务的时候，可以像流水线工作一样，达到这样的效果，则需要对整个任务进行非常详细的分解。

5. 智能应用层：智能应用层直接面向终端，怎么利用元数据等功能，组合各自不同模型提供的服务，构建出组合效应的创新服务。

（图8 AI中台的架构层次）

在数据中台的基础上，扩展对GPU级别资源的管理和整合能力，调度层提供统一的任务、服务、智能CI/CD等服务，来实现AI中台。这样以来，就可以达到：

1. 和数据平台结合，利用数据平台的能力作为数据支撑，最大化的发挥数据平台的价值

2. 拆分服务构建环节，智能服务开发流程化，快速响应业务需求

3. 利用元数据管理方式，提供统一的标准格式，场景可以多人协同配合开发

4. 基础设施共享化，模型的训练和发布与数据平台有效绑定，服务的构建自动化

5. 统一的元数据管理系统，模型的全生命周期可管理

6. 通用AI能力平台化，降低人员要求，提升协作效率

也即，利用算、模型、框架，动态、快速地组装服务，创造出新的个性化体验和新的业务新的业务模式，解决“好用”的问题。

05

结语

数据中台提供的是存储和计算的能力，基于不同的业务场景，构建出了用来支撑不同业务的数据服务，依托于强大的计算力，可以快速缩短获得结果的周期。而AI中台则是将算法模型融入进来构建为服务，让构建算法模型服务，更加快速高效，以更加面向业务。但无论是数据中台还是AI中台，都是一层基础设施，做好基础设施只是第一步，如何让它的价值最大化，还要依托于AI中台不断结合业务来持续优化，做到“持续智能”。