为了应对 AI 公司对于算法的快速生产与落地，需要兼顾数据源、数据仓库、标注、算法训练、评价体系、算法使用平台、人力物力算力成本等多方面的限制。也就是需要关注整个算法的生命周期，以及数据闭环。格灵深瞳设计了完整的数据→标注→算法→评测→发布上线的业务体系，具体由3大中台并行协作，分别是数据中台、算法中台和应用中台组合完成的。通过该方案，我们将原来的算法研发速度和交付速度提升到了原来的10倍以上。本文从产品角度、项目角度、研发与架构角度来阐述和描绘算法工业化生产时代到来的必要性和应对之策。本篇文章适合AI产品经理、算法研发、数据研发、标注团队、AI相关项目经理、与AI有关的高级管理人员、算法工程化、算法框架研发、算法应用研发等人员阅读，希望可以带来启发。

一、一切从算法需求开始

人工智能是当今的一个非常热门的领域，随着时间的不断向前推移，越来越多的 AI 需求被提出，也有越来越多的 AI 应用落地在不同的领域，如安防、自动驾驶、AI+医疗、新零售、智能家居等。从 2019 年来看，AI 貌似进入到了一个落地略微缓慢的时期，但是笔者认为，AI 应用正如当年智能机时代的 App 一样，个人 PC 一样，工业革命时代的蒸汽机一样，量子物理与相对论一样，一旦踹开了历史的大门，就永远不会关闭，除非在未来被更加先进的技术替代，一切也都只是时间的问题。

1.算法人的窘境

无论是怎样的行业和怎样的应用，AI 都是从某个算法的需求开始的，落实到实际的实现者，往往是算法人员。下面就是一个算法人员的窘境：

“我是一个算法工程师，我需要实现一个算法”

“哦，看起来我需要让我的算法分数更高”

“或许可以尝试 Paper 中提到的新的方法”

“我发现算法方法达到了瓶颈，我需要更多的数据”

“这些数据看起来需要我全部标注一遍”

“看起来分数还有待提高，我需要把上面的过程再多来几遍”

“…”

“终于算法达到了要求”

“但是…”

“又有 N 个算法的需求在等着我”

上述的情况我想是大家司空见惯的一个流程，一个 AI 算法的实现，都不是直接敲几行代码就可以完成的，往往需要经历一个漫长的探索和转化过程。

“What is the best alogrithm?”

“No Free Lunch Theorems for Optimization”

2.需求驱动下的算法迭代流程

如下图所示，是从项目角度出发的一个算法的迭代流程，数据是算法的燃料和基础条件，算法结构和优化方法是算法实现的优秀工具，目标 Loss 是算法的终点和约束，需要这三者同时迭代，和相互左右才可以一步步推动算法的前进。

3.AI 需求驱动下的需求链演进：

3.1 朴素需求链

在上述的 AI 需求拉动的算法迭代背景下，算法团队（部门）本身也在发生不同的演进，或许您的产品/部门也在这其中的某个阶段：

从上面的分析，从产品所提出的算法需求，衍生出了训练需求和数据需求两部分，而仅仅拥有数据本身是不够的，需要有标注需求对数据打标签（Label），因为通常情况下我们绝大部分的算法需求都是属于有监督学习（Supervised Learning）。通常处在该阶段的算法团队，算法需求的精度要求并不太高，训练、数据、标注需求也都是由算法工程师自己来完成的，属于最初原始期朴素的需求链。

3.2 第一次需求扩张-团队扩张

随着算法种类越来越多，且算法要求的精度也越来越高，训练需求、数据需求、标注需求也跟着进行了进一步的延伸和扩大：

训练需求：需要更多的 GPU 算力设备，于此同时不同的算法框架（Pytorch / Caffe / MXNet / Tensorflow 等）对于环境的要求也不尽相同（OpenCV/Cuda/Cudnn/OpenCL 等），而且无法混合使用，这样便衍生出了多环境支持的需求。

数据需求： 对于数据需求的扩展主要来自于越来越多的数据需要被处理和存储（总体来讲叫做治理），不同的算法有不同的数据采集过程支撑，同一个算法也有不同批次的数据采集流程，因此需要有数据仓库对于数据进行合理的规划存储，于此同时，越来越多的数据的到来，使得算法人员需要花大量的时间进行数据的处理，否则就会造成延期，因此数据自动化处理的需求也孕育而生。

标注需求：最朴素的标注工具就是文件和文件夹，但是随着数量的增大（从千量级变到 100w 量级），则需要重新定义标注工具，并进行开发，使得更多的标注需求可以被更快速的满足。曾经最初的时候所有的标注工具是由算法工程师来兼职做的，目前需要更多专职的标注人员来满足这样的需求。

3.3 第二次需求扩张-平台化

在上一节的需求分裂归根接地来自于算法/产品需求和交付压力，但是即使是扩大团队本身也会出现诸多问题：

训练方面：显卡因为高成本，但是无论租用/购买多少，都觉得不够；多人复用 GPU 环境，造成环境依赖紊乱，环境冲突，需要 Case By Case 的进行环境的修复，给算法的训练造成了非常大的影响

数据方面：越来越多的数据自动化需求，且逐步增加了精细化数据清洗的需求，单机无法完成，使得算法人员陷入到了数据处理的困境当中无法自拔；巨大的数据量日益增加，无论是数据存储，数据存储复杂度，还是数据量，都变得更加复杂，同时还需要考虑数据运维和数据备份的策略

标注方面：越来越多的不同类型的标注需求使得对于标注工具的开发需求日益增多，同时逐步增加的标注成本，对于标注人员的日产出量也有了很高的要求。

至此，算法团队的算法工程师们已经无法满足上面的诸多变化了，也因此造成了算法交付的延期。至此，对于平台的需求呼之欲出。

从最初的人工维护，变成了平台支撑，是一步巨大的跨越，同时也开启了工业化生产的第一步——基础生产设备的研发

3.4 面向更大规模生产的业务中心化

随着平台越做越大，为了支撑整个体系的算法业务研发，数据平台、训练平台标注平台逐步向中台演进，于此同时需求的增加，衍生出了算法发布中心、监控中心、用户权限中心、集成中心和应用中心等需求。

所有的资源都需要有监控和权限管理，因此增加了监控中心和用户权限管理中心的业务，至此，从需求来看，作为一个成熟的 AI 公司，至少需要以上的内部研发业务需求才可以支持更加大规模的模型生产。但是上述各个中心都是独立的吗，如果不是有怎样的联系？是否可以进行业务归并？到底需要怎样规模的若干个项目来支撑上述呢？下面的章节将会从实现的角度，将算法生产流程拆分成不同的阶段，进而演化成为数据、算法、应用三大中台。

二、AI 生产阶段化

上一个章节是从原始的需求进行了演化和梳理，本章节从微观的角度来描述数据是如何转化成应用的。

对于当前的深度学习来讲，任何算法都要来源于数据，而数据本身也需要大致经过采集、清洗、入库、挖掘、标注等步骤变成一个可供学习的训练集。就算法本身而言，需要至少经过训练、评测这两个阶段生产出符合要求的模型，同时还要考虑不同的深度学习框架所带来的影响。产出模型之后，有时候我们需要在不同的 GPU 硬件平台（P 卡、T 卡、NPU 等）运行我们的模型，那么我们就需要将模型针对所要适配的平台进行转换和加密。服务程序通过载入模型，生成 API，供应用使用。

1.数据阶段

我们都知道一个深度学习的模型是需要从训练集开始作为输入的，但是训练集本身也不是现成的很快获得的产物，是需要进行一个生产流程才可以完成。而且训练集本身表征了算法的拟合目标的复杂程度，越复杂的目标，越需要更加大量、多变的数据来尽量表征全部的情况。

“All Data for All Conditions Is The Best Solution”

除了现成的公开数据集，我们的算法往往需要更多的自采集数据集，然而这些采集来的数据往往不具有直接可学习性，因此需要一个流程进行数据的有效性转化，最终生产出可用的训练集，这个转化的过程特别像是“美酒酿造”的过程，从最初的原料采集，到杂质的一层层过滤，通过一些蒸馏、萃取的办法，逐步获得纯净的美酒佳酿。如下图就是训练集的生产阶段：

数据业务层：通过不同的采集业务（离线/在线/切分/日志/爬虫）等将粗略的数据原料进行大量的收集，这里的数据量大，复杂，包含大量信息，但是不可学习，同时也并不需要太过频繁的访问。

数据 ETL 层：数据的 ETL 也就是数据的抽取[Extract],转换[Transform],入库[Load]的过程。不同的方式有不同的抽取方法，抽取的目的就是为了从海量原始数据中提取有用的有效的信息，记性数据的清洗和过滤。数据转换的流程是为了将抽取出来的有用的信息进行结构化的表征，通过这样的结构化（时间信息、空间信息、蕴含的初步知识信息等），有用的数据具有了初步的含义和特征，方便后面的精细化操作。数据的入库则是将数据记录到数据仓库中。数据的 ETL 层与数据采集层一样都包含了诸多的自动化/半自动化业务线，通常这些业务可以通过任务触发的方式或者是自动化定时任务进行。

数据仓库层：数据仓库层用来进行大规模数据治理和索引，目的是为了确保数据的快速查找、稳定不丢失、可被随意入库出库，灵活的数据动态组织。

数据精加工层：数据精加工层主要的目的不是为了筛选数据，而是为了将数据打上有用的标签（Labeling）。通常这一层可以有 2 中不同的工作方式，一种是数据标注体系，一种是数据挖掘体系，当然这两种体系也有混合使用的情况。通常数据挖掘有两个目的：

（1）为了节省数据标注的资源消耗，因为数据标注归根结底是人力成本的消耗，使用数据挖掘是希望通过数据本身的特征、相关性、时空关系等进行标签的批量生成。

（2）数据挖掘是为了发现蕴藏在数据中的新的特征规律，这些规律未来会演化成“数据智能”的方法和产业，不在此篇文章中描述。

数据集市层：数据集市层其实也是一种数据的仓库，但是这样仓库是专门为了之后的算法训练而准备的。因为我们希望数据尽量覆盖全部场景下的全部情况，所以数据集市本身是面向不同算法的，多种版本的训练集、评测集的集合。

2.模型阶段

模型阶段如下图所示，共分为训练层、评测层、模型转换层以及模型发布层：

训练层：训练层主要的目的其实是载入训练集，编写训练代码，进行模型训练。在训练层主要考虑的问题有训练集载入、GPU 的资源使用、算法框架的使用和编写、模型的训练、分布式训练、神经架构搜索、模型优化方式等。

评测层：评测层相对简单，在模型训练的时候本身是存在验证集（ValidationSet）的验证的过程的，但是这样的过程无法说明模型本身就是优秀的，正如 Kaggle 竞赛中一样，总是会有评测集（TestSet）被保存下来，不会引入到模型的训练流程中，在模型产出后希望向后续进行的时候，会进行评测验证，在这一层还需要考虑的问题是评测方法是怎样的例如常见的方法（RoC / PR / AUC / F-Score / mAP 等）。

模型转换层：产出的模型即使通过验证，往往也需要支持在不同的显卡和平台上运行，例如 Turing、Pascal、NNIE、ARM 等，因此需要模型可以被转换到些平台上进行专门的加速；于此同时模型还可能会进行压缩，目的是为了提高效率例如 mimic、Distilling、Prunning、Int8 Quantization 等；还有些时候我们需要对模型进行加密输出。

模型发布层：对于模型的发布事实上是一种库的管理，基于这样的库来记录模型的版本，位置，访问权限等

3.应用阶段

集成层：集成层主要是为了将算法进行工程化改造，将“数学模型”改造成工程代码中易用的“函数”，因此集成层的主要输出是 SDK，通常这些 SDK 的目的是为了支持不同语言、不同平台（云或者嵌入式设备）、不同应用需求（基于不同的应用会有不同的 pipeline 或者算法组合）。

应用层：应用层较为灵活，主要有两种形态存在，一种是服务，中是 AI 应用（手机端、云端、Saas、系统）。该层主要的核心，应该在于模型的快速打包上线，以及运维部署。

4.数据-模型-应用的转化图

一个完整的算法周期如下图所示，总共分为三个阶段，分别是数据阶段、模型阶段、应用阶段，这三个阶段代表了一个算法的需求从提出到最终解决所经历的所有“工序”，而且无论对于怎样的企业，怎样的算法团队，这样的工序中的每一步使用怎样的工具、基础设施和人才，这样的转化流程是客观存在的，我们叫它数据-模型-应用流转图。

数据-模型-应用流转图

根据三种不同的阶段，可以将真个 AI 生产业务拆分成为数据中台、算法中台、应用中台三部分。下面的章节将对于这三大中台进行技术架构分析。

三、数据中台体系与架构

数据中台架构如下图所示：

底层的原始数据有在线和离线，但是为了做好自动化，需要有Airflow或者Azkaban这样的计划任务管理作为支持。但是面对不同的业务线，随时会用源源不断的原始数据流入，因此，对于原始数据的实时（分布式）处理显得尤为重要。Kafka/Nsq充当了任务异步下放或者数据总线的角色。Nsq极易操作，在架构早期或者是突发数据业务，建议使用，后期由于中台业务的发展，对于业务吞吐有了一定的要求以及集群资源的扩充，可以延伸至Kafka。

对于数据仓库，可以使用多种不同的方式同时存储，因为不同的存储各有所长，不过基本上的搭配是“结构化搭配非结构化”，“分布式搭配集中式”。

结构化搭配非结构化，例如，Postgres+Weedfs 或者 HDFS+HIVE 或者 WeedFS +HIVE + HBase 属于结构化搭配非结构化。这么做的原因是结构化数据与非结构化数据的特性以及读写需求不同，因此需要在存储上进行各自区别存储。非结构化数据磁盘占用量大，只需要key作为唯一索引，读取次数较少（在训练以前），对于存储需要频繁写操作，因此只需要选用对象存储即可。结构化数据对于索引、关联需求较大，所占空间较小，因此可以选型SQL类型的关系数据库。事实上在后续的数据挖掘过程中，非结构化数据（图像、视频、语音等）通常访问很少，大部分只用到了结构化信息。

分布式搭配集中式，分布式如ceph、hdfs等都属于典型的分布式文件系统，集中式例如postgres、weedfs本质上更适合集中式管理，当然如果基于数据的Domain做成类分布式，但是本质一样。两者搭配首先对于数据进行了冗余存储，分布式易于快速访问，以及上层的分布式挖掘计算，集中式写稳定，易于进行后续的备份、数据质检、对于断电重启容忍度较高，不用关心Re-Balance等分布式事务带来的诸多困扰。

四、算法中台体系与架构

算法中台体系如下图所示：

之所以是混合云环境，是因为这样可以合理利用好云上和云下的优缺点，云上具有极好的资源可扩展性，通常分布式训练，神经架构搜索，自动化调参，大规模机器学习实验因为其要求时间较长，且对于集群的稳定性和速度具有极高的要求，因此最适合在云上进行；而云下更加适合保密性的且与数据相关的操作。对于混合云架构可以使用双重加密方法，既数据型加密和网络型加密，数据型加密保证了云上所在的数据具有不可逆性，无法被直接访问或者解码，网络型加密例如防火墙白名单、IPSec、SSL 层都是类似，使得对于云上设备通信进行信道的加密和权限的管理。

Kubenetes 作为当前最好用的云原生管理平台，可以很好的保证 GPU 资源的动态分配和再利用，基于它和周围的组件使得交互式的实验环境、离线训练方法、分布式训练、大规模训练得到了有效的利用。

还有一点就是训练中台事实上是 GPU 云的任务下放中台，对于数据集（盘）的动态分配显得尤为重要，这里可能会有三种方式：SSD-NFS 方式、Ceph-RBD 方式以及对象存储 OSS 方式。

五、应用中台

此部分可以略去架构图，因为不同的企业和方案对应的应用中台是不同的。总体架构图如下：

模型的载入层提供接口进行动态模型的下载，计算资源动态规划有两种，分别是程序内的动态资源规划与平台级动态资源规划，如果是程序内的动态资源规划需要决定显存中模型的存放位置和大小，动态释放不用的模型，来保证对于热模型的快速调用，而平台级动态资源规划，则是把一个载入模型的服务作为一个 Deployment 资源，交给 Kubernentes 进行动态的分配。通常情况下模型的本身应该是被加密过的，因此在载入的时候需要进行模型的编解码，于此同时，数据也是如此，为了保护用户数据防止泄漏，真正存储的数据是需要被加密的，只有在读入的时候进行解密。

六、面向 AI 的工业化生产体系——AI 大脑

根据前文所述，整体的 AI 生产业务架构如下图所示：

而这三大中台本身的实现有慢慢会向一个非常大的平台融合，这个“大平台”本身不应该是一个一贯的（例如一个 repo、一份代码、一种编程语言）开发的平台，而是多个平台形成的多个中台的上层业务合并，根据我们前面梳理的业务，笔者总结出了大脑的业务地铁图，从数据到模型再从模型到应用，最终从应用又回到了数据，这样的一个数据流、算法流、应用流形成的闭环就是 AI 大脑。

说几个宏观一点的指标，在整个深瞳大脑构建的项目中，我们成功的将整个数据业务到训练集生产的进度从之前的遥遥无期（2月为单位）压缩到2周内，算法模型的发布流程从月为单位压缩成天为单位（提升10倍以上），GPU集群平均使用率从15%提升至70%（4倍以上），GPU显卡资源使用量压缩到原来的60%，但是仍然很好的支撑全公司的算法生产业务。

七、结束语与未来展望

本文主要介绍的是以深度学习为核心的大规模 AI 生产的演化过程以及其衍生结果算法中台、数据中台以及应用中台的架构设计以及业务流程设计，通过描述最早期原始的算法手工作坊的方式到后面数据中台、算法中台、应用中台三大中台配合的方式，演绎了面向算法研发效率提升的迭代改进。当前的算法生产还是在面临成本高，产出小，周期长的问题，但是随着越来越多的中台和自动化引入，会将算法的流程不断加快，成本不断降低，只有在数据、算法、应用三者紧密配合的前提下，才可以有效的提升整个AI业务的流程。

作者介绍：

黄严，格灵深瞳深瞳大脑项目负责人/皓目行为分析仪研发负责人

创作场景

格灵深瞳 AI 大脑进化史：算法工业化生产如何将研发和交付速度提升 10 倍以上？