从Watson看AI平台的架构设计

本文转自：https://blog.csdn.net/dev_csdn/article/details/78426133

摘要：本文分析IBM Watson在技术架构上所面临的问题及解决办法，总结了人工智能平台在走向产品化需要面对的诸多挑战。最后提出了以云计算PaaS容器服务平台为基础，上层使用SaaS的服务架构来搭建企业级AI平台，是技术上可行也是较经济的一种解决方案。

前言

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

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

图2

• 问题生成模块：系统尝试了解问题是什么，并执行初步分析，以确定问题将如何由系统的其余部分处理。首先分析问题，对问题的类型，回答方式等进行分类，再把问题分解成一系列假设可能的子问题。
• 答案生成引擎： 对于输入的假设，在答案源进行搜索、过滤掉评分过低的备选答案、根据备选答案搜索证据、最终把备选答案和证据合并汇总到统一的数据模型中。可以说这是Watson最具挑战的部分，因为：
  
  • 第一，答案的准确度必须很高，单一分析算法很难达到要求。DeepQA团队通过漫长的实验和摸索最终选择了上百种算法从不同的维度分析备选答案，如类型、时间、空间、流行度、来源可靠度、语义相关度等。每种分析都产生一些特征和评分，如何融合不同维度的分析结果并给出评分是一个巨大的挑战。
  • 第二，计算答案的时间很短。人类选手几秒就能思考出答案并做出抢答动作。而Watson要执行多步计算：把问题分解成N个假设、每个假设又会去查询N多可能的证据、对N*N的查询结果进行合并、最后分析出答案。DeepQA团队承认最初Watson单机计算一个回答需要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软件基金会，并成为它的顶级项目。

• 答案决策模块。将对备选答案生成的成千上万的成绩保存在CAS数据结构中，汇总得到最终成绩和自信度。DeepQA团队使用Jeopardy以往比赛的题库和模拟题库训练出一系列的中间模型，统计出不同成绩和自信度的答案在题库中的正确率。 Watson使用中间模型统计出的正确率，筛选出最有可能的备选答案。
• 游戏策略模块。依据Jeopardy游戏的规则，结合场上各个选手的比分，问题的难易度来为Watson制定最优的抢答策略。DeepQA团队通过历史比赛和模拟比赛的数据，针对不同的问题和场景，训练出一系列的中间模型，统计出在某种情况下采取何种策略最有利。
• 学习&训练模块。DeepQA的工程师将近20T的各类文档，来源包括百科全书，词典，叙词表，新闻文章和文学作品等，存储在Hadoop的HDFS中。利用Hadoop的MapReduce引擎并行分析这些非结构化、半结构化和结构化的文档，分析结果以UIMA的数据结构存储在数据库中作为答案库和证据库供Watson比赛时查询和检索。

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的架构搭建自己的业务平台已经进入了实践阶段， 国内已经涌现出了一些用私有云的容器服务平台搭建自身业务平台的成功案例（参考4）。目前公有云服务商Azure、AWS、Google和阿里云等都纷纷基于自己的PaaS平台推出了类似CaaS的产品。 这种架构设计利用云平台动态伸缩的优势降低AI平台的初始资源投入，同时保证平台后续没有资源方面的瓶颈，是一种可行的AI平台架构设计解决方案。另一方面，我们也应看到该方案的局限性，对于需要实时使用大量硬件资源（如GPU）的AI应用场景，容器服务化并不能解决全部问题。

更多案例请关注“思享会Club”公众号或者关注思享会博客：http://gkhelp.cn/