人工智能工程化丨中小企业AI中台落地指南
人工智能几乎是近几年最火热的技术名词。仿佛一夜之间，不谈人工智能就是落伍，不搞人工智能产品就表示没能站在风口上。
但是当很多中小型团队冲入人工智能领域时，他们会发现，一开始以为是“拦路虎”的算法问题并不是最关键的痛点，而找到一个好的人工智能工程化落地场景，以及快速搭建人工智能工程化技术方案，变成了巨大的、难以跨越的鸿沟。
究其本质，取得人工智能核心算法的突破性进展是非常漫长且学术化的行为，尤其是在深度学习领域，有人调侃称，每年发表的论文堆起来比东方明珠塔还高。可以说，深度学习依然是不可解释的、依靠经验调参的“炼金术”。在这种背景下，绝大部分中小型企业并不具备在核心算法上取得突破性进展的能力。
对于绝大部分公司来说，能够找到一个准确的场景来应用人工智能算法，进而实现算法落地，实现人工智能工程化，才是最明智的。
人工智能工程化的重要一环便是人工智能中台化。
站在公司的整体战略上，大中台、小前台的设计让企业沉淀共享服务，打破系统壁垒，提高业务创新能力，让团队到第一线去迎接炮火，同时让大后方有坚强的中台能力支撑。
那么在中小型企业中应该如何落地和实践人工智能中台呢？
一个中小型企业的前中后台架构一般包括聚焦业务的业务中台、聚焦移动 App 快速交付的移动中台、聚焦数据沉淀和数据湖沉淀的数据中台、聚焦底层 IaaS/PaaS 能力的技术中台。
各个中台整合支撑前台业务
传统的数据中台在承接面向人工智能的业务需求的时候，往往会面临以下一系列问题。
1）智能化方兴未艾，研发处于较原始的阶段，缺乏完整的生命周期管理理论和相应的管理框架，导致人工智能产品烟囱式开发、项目成本高、不易集成、过程重复、缺乏能力沉淀。同时研发环节繁多，缺少优化、协同、自动化辅助，业务响应缓慢。
2）数据中台没有完全覆盖前台业务研发中笨重、重复、低效的环节，缺乏对人工智能研发过程的敏捷支持，导致模型研发缺乏标准指导、参与角色众多，难以有效地管理沟通协作。同时缺乏统一数据访问渠道，数据获取难、标准不一致，存在大量重复的数据预处理与特征工程。
3）数据中台没有为人工智能业务提供底层的技术支撑能力，导致模型交付难，缺少统一的模型运行监控平台，缺乏服务管理接口及更新维护机制。同时 GPU 资源管理混乱，基础资源管理分散，未得到充分的资源调度和利用，造成严重的资源浪费。
为了满足复杂的学习预测类智能研发需求，集成数据挖掘/数据洞察智能算法和模型，我们从数据中台中抽象升华出人工智能中台，用人工智能中台覆盖从业务场景分析、数据获取到模型部署、性能监控的全流程人工智能流水线，如下图。
人工智能流水线
人工智能中台在技术上需要实现以下功能点。
服务的可复用性模型库：充分使用算法服务和模型，支持自动展开能力，对算法库提供有效、方便的管理和多层次的复用。
人工智能开发的敏捷的流水线：能够缩短人工智能产品开发周期，面对需求优化模型研发流程，提高各环节自动化程度，对参与角色进行科学管理协调。
稳定的运行平台：实现数据统一访问管理、计算资源统一管理、GPU/CPU 混合云的统一调度、稳定的训练运行环境。
便捷的服务接口：提供完全自助式的服务市场，供用户一键式搜索、一键式使用和订阅人工智能服务接口，同时提供安全的权限认证和灵活的计费功能，提供服务的资源调度和动态编排能力，供业务以即插即用的方式组装人工智能产品。
对于人工智能中台整体产品，或者说人工智能产品化矩阵，笔者根据常见的人工智能产品化需求整理了如下内容。
我们可以把人工智能中台看成是基于 IaaS 基础上的人工智能 PaaS 平台。在人工智能中台上灵活搭建各种人工智能基础服务，如人脸识别算法能力、语义识别算法能力、语音合成算法能力、布局决策能力等。然后在这些基础人工智能能力之上，进行服务编排和组织，就可以形成语音转文本、文本转语音、智能推荐等带有业务色彩的人工智能服务。包装和组织这些带有业务色彩的人工智能服务，最后就能包装出各种垂直的人工智能解决方案。从 IaaS 到人工智能统一门户这几个层次，我们统称为人工智能中台。
一个典型的中小型企业人工智能中台整体架构
整个人工智能中台要解决的核心业务重点就是打通算法开发、训练、发布各环节，形成自动化流程，形成人工智能的DevOps 闭环。
在每个环节中需要注意的技术要点如下：
模型开发：集成Python/scale 编辑器的背后实现；把深度学习设计变成图形化拖曳。 模型训练：实现分布式机器学习框架和一键训练；实现深度学习分布式框架；实现 GPU池化和一键训练。 模型发布：实现机器学习的CI/CD；实现深度学习模型文件的大文件仓库。 模型服务化：机器学习算法服务化；深度学习模型服务化。 模型评估：人工智能统一门户采集模型的调用数据反馈。
上图是以俯视的角度看整个人工智能中台的应用架构，那么在 IaaS 层、PaaS 层和 SaaS层这三个层次之间，几个系统之间的模块是如何相互支撑的呢？
人工智能内部的系统模块图
在 IaaS 层，基于Docker+CUDA 技术实现 GPU 资源的虚拟化；在PaaS 层，底层由Kubernetes+Jenkins 实现自动化部署和自动化调度，在此之上，我们封装实现数据标注平台、算法建模/训练平台、模型仓库和算法工程化平台等几大基础支柱性平台系统。在PaaS 平台之上，我们通过人工智能统一门户这种自助服务的SaaS 平台模式对外提供服务，让用户可以自由编排、自由接入自助缴费，即插即用，方便快捷地使用人工智能服务。
再进一步聚焦PaaS 层的核心平台系统，看一下它们之间是如何联动的，如何互相支撑的。
数据标注平台、算法训练平台和服务部署平台之间的联动
整体上这几个核心平台系统支撑了如下功能点。
◆ 负责公司人工智能基础平台建设、前沿底层人工智能技术预研，为上层业务提供平台技术保障服务。
◆ 建设稳定、可靠、易操作且规范化的人工智能开发平台，在规范开发流程、保障数据安全的同时，持续提高算法建模的效率。
◆ 围绕算法建模全过程，提供数据、算法建模和模型服务化部署这一整条链路的能力建设，实现数据（数据标注平台）、工具（算法训练平台）、模型（模型仓库管理）和服务（人工智能服务市场）的整体贯通，从而建设闭环的基础算法平台。
几个核心平台系统之间的模块图
从上图中可以看到，数据标注平台负责整理搜集标注数据，标注之后的数据将交给算法训练平台用来做训练，自动建模平台用来图形化生成的算法模型，并将其交给算法训练平台做自助训练，训练完成的算法将交由服务部署平台做自动化服务，而这其中所有涉及 CPU/GPU 资源调度和资源分配的任务都交给资源管理平台管理。
几个核心平台系统之间的用例图
算法人员在本地调试开发算法源码，然后把代码保存在 Git 仓库中，再把本地测通的代码提交到算法训练平台，在算法训练平台上引用数据标注平台上打标的训练数据做模型训练，待模型训练完成之后将模型发布到模型仓库，然后由业务人员在自动建模平台上选择模型发布模式，推送到服务部署平台做服务化暴露，直接插拔到人工智能统一门户上对外暴露。
综合以上内容，我们可以用一张功能概要图从产品功能化清晰地总结一下每个平台需要实现的功能点和能力。当然，对于中小型企业而言，将其中的所有功能点都实现是不现实的。
几个核心平台系统之间的产品功能架构
上图中包含必需的功能点、附加功能点、较有难度的功能点，具体如下。
必需的功能点：
产品服务中心、解决方案中心、系统配置管理、管理控制台、账户管理、权限管理、计量计费管理、离线数据集成、脚本清洗、数据质量管理、运维信息统计、元数据管理、数据检索、任务运维管理、数据预标注、Web IDE、自定义算法、模型评估管理、资源管理、算法模板管理、代码构建、CPU 容器部署、部署环境管理、模型部署、发布流程管理、GPU 容器服务、CPU 容器服务、数据卷管理、对外资源管理服务、资源配额管理、资源调度策略管理。
附加功能点：
人工智能服务市场、文档支撑中心、工单中心、消息中心、内容发布管理、实时数据集成、SDK 清洗、数据血缘管理、计费策略管理、结算管理、数据类目管理、模型压缩优先、公共模型库、训练任务管理、私有模型库、模型评估管理、数据接入管理、系统配置管理、模型版本管理、GPU 容器部署、服务灰度发布、服务效果跟踪。
较有难度的功能点：
图像标注、任务管理、数据集管理、文本标注、质检管理、源数据管理、语音标注、团队管理、视频标注、实验管理、机器学习算法、数据接入管理、画布管理、私有镜像仓库、组件管理、运维管理、服务上下线。
如想了解这些平台的能力定位和架构或是进一步了解关于人工智能中台化战略的内容，包括人工智能中台的数据能力、业务能力、硬件能力、平台能力等核心知识，请关注新书《人工智能工程化：应用落地与中台构建》
本书清晰解答了人工智能工程化的应用场景是什么，并且着重介绍了如何搭建人工智能中台，能够带给相关从业者非常有用的经验。
/ 作者简介 /
蒋彪
曾任东京日立情报株式会社软件工程师、苏宁易购DevOps研发中心高级架构师、苏宁人工智能研究院高级架构师，现任福特中国车联网高级产品架构师。《Docker微服务架构实战》作者，发表过多篇技术论文，兼任多所大学客座讲师，在软件研发流程管理、DevOps实践、企业中台构建等领域有独到见解。王函
资深微服务架构师，拥有15年软件开发、架构设计经验。曾负责研发日本移动音乐门户www.music.jp、淘房365等互联网产品，现投身于国内知名金融机构，从事大规模高并发客户营销系统架构设计相关工作。在微服务架构、云计算、人工智能工程化等技术领域有着深入见解。 ▼ 扫码获取本书详情 ▼
如果喜欢本文欢迎 在看丨留言丨分享至朋友圈 三连
热文推荐
▼点击阅读原文获取本书详情！