从Watson看AI平台的架构设计

更新时间:2017-12-13 10:20:11 点击次数:1541次

前言

2016年被认为是人工智能的元年,随着AlphaGo战胜韩国棋手李世石,人工智能产业彻底站到了风口上。然而人工智能研发团队的核心技术人员通常都是掌握了某些核心算法的科学家,他们对于平台的架构设计,工程实施并不一定经验丰富。 如何基于核心AI能力搭建出一套可持续运营又具有业务成长性的企业级AI平台呢? 笔者以IBM的 Watson为案例,来分析架构设计上需要考虑的方方面面。

Watson解决那些问题?

IBM的Watson在2011年在美国危险边缘(Jeopardy)真人秀中以77147分的成绩战胜两位人类选手赢得100万美金头奖而一举成名。在这个故事背后,IBM解决了那些人工智能领域的问题呢?我们先来看看 Jeopardy这个节目的竞赛规则。作为美式智力问答节目,Jeopardy的题目由若干词条或短句组成,让竞赛者找出这些线索所描述的人或事物,答案需要以提问的形式提供给主持人。 例如题目问“在扑克牌游戏中,五张同一花色顺联的牌” 。 选手的正确回答是“什么叫同花顺”?这就要求参赛选手要有知识的广度和抢答的反应速度,并且还需要有脑筋急转弯的联想归纳能力。Watson能在不联网的情况下,处在人类日常的环境当中,去理解、抢答、赢得比赛,主要在人工智能3个领域取得突破:

  1. 理解自然语言的能力。虽然在比赛中Watson为了提高理解的精确度关闭了语音翻译功能,使用文本作为输入方式(游戏规则允许选手阅读显示屏上的问题,所以并不算Watson违规),但它仍然需要准确的解读人类措辞含糊的提问。
  2. 非结构化数据的处理和机器学习能力。接下来Watson要从百科全书般浩繁的文档中学习储备知识。
  3. 快速运算。在比赛中从知识库中找到备选项, 通过复杂的判断逻辑从备选项中选择正确度高的答案。要达到超过人脑的推理运算速度,快速准确的用人类语音给出终答案。

Watson是如何运行的?

从赛后Watson研发团队DeepQA在人工智能领域顶级刊物AI Magazine上的公布论文《Building Watson: An Overview of the DeepQA Project》 (参考1)和维基百科(参考2 ) 上的内容, Watson问题分析的工作流程如图1:

图1

图1

因为国内已有介绍DeepQA这篇论文的文章(参考3),笔者就不详细展开。从上图看Watson的技术架构可以归纳如下(图2):

图2

图2

为了应对挑战,DeepQA团队设计了非结构化信息应用程序框架(Unstructured Information Management applications 缩写 UIMA)。UIMA 对于非结构化文本分析定义了一套记录分析结果的通用分析数据结构Common Analysis Structure(CAS),使不同的算法可以共享对文本的分析结果。 另外,为了缩短Watson思考的时间,DeepQA团队设计了UIMA的异步扩展框架(UIMA-AS)用于将分析过程横向扩展到多台电脑异步并行处理。UIMA-AS使用JMS(Java Messaging Services)和ActiveMQ处理异步消息传递,使答案生成引擎可以方便地部署到多台服务器上并行处理并汇总分析结果。Watson在参加比赛时,基于UIMA-AS把90台IBMPower750服务器连接在一起,把思考时间缩短到3-5秒。可以说Watson主要创新并不在于创建某种新的算法,而是通过UIMA能够同时快速执行数百种成熟的语言分析算法,目前UIMA已经开源给Apache软件基金会,并成为它的顶级项目。

Watson平台化的技术挑战在哪儿?

借助Watson在智能问答领域的成功,IBM努力把它作为一个人工智能品牌推向商用。例如安装在汽上,回答驾驶员有关维修的问题,以及如何提供路况信息和发出安全警示。当汽车故障出现时,Watson可以告诉驾驶员什么地方出了问题, 是否需要预约去4S点修理。

然而训练Watson赢得比赛是一回事,选择怎样的技术架构把Watson打造成能支持同时服务数以万计用户的AI平台,就是另一个问题。 以前述的汽车助手为例, 要构建一个企业级的AI交互问答平台, 就不得不考虑如下实际问题:

  1. 多租户带来的资源隔离。 对于企业用户而言,为了数据的安全性和平台的稳定性均要求对其数据,资源进行隔离不和其它使用者混用。
  2. 企业的需求不一,并且使用的服务不同,如何满足其定制化。
  3. 由于是新应用,企业客户更希望AI平台的计算能力能随着业务量的增长动态提升,让花的每一分钱都用到实处。
  4. 海量的数据存储需求。 大量人机对话产生的语音数据, 需要有廉价安全的存储方式来保存。

什么样的技术架构能解决这些问题?

笔者认为用基于PaaS的容器服务(Container As a Service 缩写 CaaS) + SaaS的架构能很好地解决上述问题。容器服务(CaaS)是一种基于容器的虚拟化形式,其中容器引擎,编排和底层计算资源作为云服务提供给用户。容器服务平台技术近两年已经发展得比较成熟,目前比较流行的实现方式是以Docker为容器化技术,Kubernetes为容器化的应用提供资源调度、部署运行、服务发现、扩容缩容等整一套功能。利用容器服务平台封装、隔离和部署灵活的特性,能很好的解决上述多租户带来的问题。结合云计算SaaS层的租户管理, API管理,计费管理等应用层能力,能很好的解决企业二次开发定制化的需求。PaaS平台对于DevOps的无缝支持以及基础资源(云存储、消息队列、RDS以及镜像),也使问题3和4的解决变得非常容易。完整的企业级AI平台技术架构如下(图3):

这里写图片描述

图3
  1. SaaS应用平台作为和用户的交互界面,负责将AI平台的能力和用户对接。根据AI平台的业务特点,自研发用户管理,计费管理,以及对用户资源的管理模块,研发基于OAUTH, RESTful的 OpenAPI平台。
  2. SaaS平台还要对AI平台的研发和日常监控进行支撑。 搭建AI平台的运营监控和代码管理系统。
  3. PaaS提供平台基础资源。提供RDS,既存放AI平台共享的知识库和训练模型,也存放租户自定义的数据内容;提供云存储,放置各类结构化和非结构化的文档资源,人机对话产生的巨大存储需求也有很好的解决方案;提供消息队列,用于支撑类似于UIMA-AS横向扩容时并行计算的消息传递;提供镜像管理(包含虚机的基础镜像管理和容器服务的容器镜像管理),用于存储各AI子系统模块新的Docker镜像。
  4. PaaS自身支持DevOps。负责平台的代码和软件更新, 通过DevOps推送到PaaS平台的镜像仓库中,交由容器服务平台自动进行升级和回滚。
  5. 基于PaaS的容器服务平台,在部署编排模块的管理下,从PaaS的镜像中获取相关容器镜像,为每个租户部署一套完整的AI生产环境。容器调度模块结合PaaS平台的基础监控,根据租户的资源运行情况,对运行实例进行动态调整。配置管理模块统一管理各租户内部子系统的配置。网络管理用于协调租户内部和外部云平台之间的网络路由和流量分配。
  6. 学习和训练环境也部署在容器服务平台。 因为AI的训练和学习时间不固定,没有必要占用大量资源。在需要时申请,完成计算后释放,能有效得节省计算资源的使用。
  7. 对于每个租户,通过容器服务平台创建完整的Watson系统。容器化的问题生成,答案生成引擎,和答案决策模块可在容器服务平台里动态伸缩,达到资源的合理利用。

总结

随着以Docker和Kubernetes为代表的容器服务技术日益走向成熟,企业利用PaaS容器化平台+SaaS的架构搭建自己的业务平台已经进入了实践阶段, 国内已经涌现出了一些用私有云的容器服务平台搭建自身业务平台的成功案例。目前公有云服务商Azure、AWS、Google和阿里云等都纷纷基于自己的PaaS平台推出了类似CaaS的产品。 这种架构设计利用云平台动态伸缩的优势降低AI平台的初始资源投入,同时保证平台后续没有资源方面的瓶颈,是一种可行的AI平台架构设计解决方案。另一方面,我们也应看到该方案的局限性,对于需要实时使用大量硬件资源(如GPU)的AI应用场景,容器服务化并不能解决全部问题。

本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是一个个人学习交流的平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽,造成漏登,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

回到顶部
嘿,我来帮您!