e-works数字化企业网  »  文章频道  »  基础信息化  »  IT综合

人工智能与软件架构

2017/6/1    来源:CIO智库    作者:佚名      
关键字:人工智能  软件架构  
因为 AlphaGo 的出现,过去的 2016 年可谓是人工智能元年。记得当时我们正在苏州封闭研发The Platform,工作之余讨论到人机对战的真正意义,并不在于技术上的突破,而在于对人们固有知识的影响,人工智能的应用会如雨后春笋般诞生,以后没有人工智能的软件以后你都不好意思开口了。

    应对软件架构分而治之带来集成的挑战,探索智能的连接
 
    什么是软件架构,在InfoQ出版的《聊聊架构》中讲的很清楚(感谢老王,总结非常到位),软件架构就是
 
    (1)根据问题确定系统边界;
 
    (2)按一定原则进行切分;
 
    (3)建立不同模块间的沟通机制;
 
    (4)整体性交付软件功能。
 
    可见,架构的关键是分而治之的哲学,但切分是为了软件研发、运维方便,软件的目标是整体交付,分与合存在这矛盾,这一矛盾是由集成解决的,但是集成往往是复杂的,大家在架构方面的分享,也以如何切分居多,如何集成相对较少。
 
    集成工作的复杂度影响了复杂度系统的研发
 
    Unix的实践无疑对软件架构有着巨大的影响,做一个事情,做到最好,一直是 Unix 风格所倡导的,但“在理想世界中,Unix程序员只愿意手工打造小巧完美的软件宝石,每个都那么小巧、那么优雅、那么完美。然而显示中很不幸的是,太多复杂问题需要复杂的解决方案。仅仅十行的程序,再优雅也无法控制喷气式客机。那儿有太多的装备、太多的通路和界面,太多不同的处理机,太多不同操作人员定义的子系统,他们甚至连基本的约定都无法统一。即使能够成功地将航空系统所有的个体软件部分做的优雅,但拼装结果很可能是一堆庞大、复杂、糟糕的代码···喷气客机的复杂是必然的。
 
    过去有个尖锐的观点,不能为简单性而牺牲功能,因为飞机必须要能飞。正是这个事实,航空控制系统并不会产生关于复杂度的圣战—-Unix程序员往往敬而远之(摘自《Unix编程艺术》)。
 
    不幸的是,我们面临的往往是复杂性的系统,片面理解Unix风格分而治之往往带来更大的集成难度。为了降低集成的难度,我们往往采用巨石型的系统架构,用一个大一统的方式设计系统,仅仅在系统内部进行模块的拆分,用codebase和规范进行约束,走上了和Unix风格背道而驰的道路。当性能和可维护性压力到来后,这样的系统又不得不进行拆分:我过去常常看到,当软件系统达到 100 万行代码规模时,人们会觉得维护困难,产生了强烈的拆分念头;当达到 300 万行代码规模时,人们往往再也按耐不住拆分的欲望;当达到 500 万行代码规模时,再保守的组织也会作出拆分的决定。
 
    软件架构中复杂的集成工作需要利用人工智能方式简化下来
 
    回顾一下解决集成问题的历史,我们会发现较早的集成架构模式来自于 Unix,就是众说周知的管道(Pipe)模式。Pipe模式将数据传递到一个任务序列中,管道扮演者流水线的角色,数据在这里被处理然后传递到下一个步骤。
 
    管道模式作为一种最基本的方式,理论上可以解决所有集成问题,但涉及到具体问题时,就需要针对不同情况做应对,针对各种复杂的情况,可以总结出更多的模式,《企业集成模式》(EIP)一书中围绕消息集成,总结出若干集成模式,可谓是消息集成的集大成式总结。但EIP的集成模式主要针对系统间后台服务的集成,SOA架构提出了以Portal(前端集成)、BPM(流程集成)、ESB(服务集成)、DI(数据集成)以及事件/消息集成的多层面集成体系,更加系统性的为集成工作提供指导。SOA的集成方式需要一系列的集成基础设施支持,属于一种中心化的集成方式,我们可以称之为MiddleBox的方式,在微服务架构提出后,我们会采用把集成逻辑与业务功能部署在一起的去中心化集成方式,可以称之为MiddlePipe的模式。
 
    集成方式一路演进下来,主要是集成的手段上不断翻新,多种框架和基础设施越来越多的解决了非功能需求,例如 ESB 可以解决路由、安全、流控等问题,一定程度上减少了集成的工作量。但集成的业务复杂度还存在很多,这里我列举几个常见的问题:
 
    (1)数据的查找问题
 
    针对业务需求,需要使用已存在的数据和服务,但在企业环境中,系统、服务、数据众多(想象一下具有10多万服务、10多万数据标准的情况),想找到试用的服务和数据,不是一件容易的事情,一般我们都要依赖专家在这方面的知识,通过总体设计指定了数据的流向,这依赖于专家的能力,专家的能力也是慢慢积累起来的。我们需要帮助业务更快速的找到数据和服务,帮助专家快速实现积累,减少重复劳动。
 
    (2)数据的适配问题
 
    通过服务方式进行集成,原子服务往往需要大量的输入参数。举个例子,调用一个发短信的接口,不仅仅是收信人电话号码和短信内容,还要包括很多业务含义的参数,例如发信人的姓名、组织、发信的系统、发信的原因、发信时和客户接触的渠道(客服渠道、网点渠道、网银渠道、自助终端等等)、发信时关联的产品,这些信息是可以用来计算成本、控制次数、避免重复骚扰客户;用户名、密码、验证码、发送时间等这是用作安全验证的;优先级、发送渠道等是用来做流量控制的;流水号、全局业务ID、请求ID、请求时间等等是用来做监控的。上述信息来自与每次发短信的上下文,在实际开发期间就要做很多的赋值、转换工作,将上下文的信息传递给服务,这种转换就像下图那样,典型的面多了加水,水多了加面。我们需要根据当前上下文和服务的特征,自动的进行一些适配,避免人工的重复性劳动。
 
    (3)系统的联动问题
 
    当一个业务事件产生时,有很多相关联的系统都会需要作出关联性反映,例如一个航班延误,就会涉及机票的改签、酒店的改期、接车服务的改期、会议安排的变更、日程计划的变更。一般我们会设计一个事件中心,为各个系统开发出监听的程序,当事件到来时判断上下文信息,决定产生的动作。如果事先没有设定的规则,就无法产生联动,我们期待更加自动化的建立这种联动关系,让计算机智能的产生动作而不仅仅通过人为设置。
 
    类似问题还有很多,我们期待能够更加智能的集成。
 
    需要集成的部分不只是软件本身,软件过程也是一个复杂的集成/协作工作
 
    分而治之的软件需要通过集成方式整体交付,软件的生产过程也是一个多人、多组织协作的过程,也需要集成。把软件看成是一个产品,产品就有策划、研发、运营和退出各个阶段,每个阶段可能由不同的人或组织完成。软件的研发阶段就是一个一个项目的实施过程,包括立项、执行和完工。这样的过程组织起来,就是一条软件生产的流水线。从早期瀑布式的软件研发,到后来敏捷研发过程、CMM,到目前风头正劲的DevOps,都是在解决软件生产流水线不同阶段的协作问题,敏捷针对软件定义、设计、构建(开发)阶段的协作,持续集成是构建(开发)与测试阶段的协作,持续交付是从定义阶段到部署(交付)阶段的协作。
 
    协作中面临的问题,就是集成的问题,我们可以想到很多,这里也举几个例子:
 
    (1)需求、设计与构建(开发)的沟通问题:我们需要把需求/设计的知识图谱化、条目化,自动与开发工作做一定程度的适配,减少需求/设计到代码的转换工作;
 
    (2)构建(开发)与测试的沟通问题:我们需要根据服务和数据特性以及积累的历史数据,自动产生测试用例和测试方法;
 
    (3)运营的沟通问题:我们需要通过应用画像、资源画像等方式,服务与物理资源之间建立连接,快速定位问题,进行容量预测,实现更智能的运维。
 
    在软件架构中应用人工智能的目标:通过增强智能方式实现软件系统与软件工程的智能连接
 
    应对复杂集成的挑战,我们可以引入人工智能的思路,将人与软件之间、物体与软件之间、软件与软件之间、软件生产线各环节之间通过知识使能的方式集成起来,在传统完全依赖规则进行集成的方式基础上,采用新的集成方法:以上下文信息为输入,利用专家已有的知识,通过数据训练和强化学习的方式,让计算机能够理解集成的意图,成为我们的智能助手,帮助我们实现智能的连接,进而可以让计算机探索新的连接知识。这里,我把连接也分为三个层面:机械连接、基于知识连接、创造知识连接。
 
    从智能连接入手探索在软件架构中应用人工智能
 
    从何处入手,探索人工智能在软件中的应用,是大家最关注的话题,这里我把普元在探索人工智能初期经历的几个案例,给大家做一个介绍。普元董事长刘亚东博士早年就从事神经网络的研究,他指出在目前并行计算等技术充分发展的今天,算法已经不是人工智能的瓶颈,应用人工智能需要有两个突破:
 
    (1)找到人工智能应用的切入点
 
    (2)团队具备人工智能应用的思维
 
    所以我们在应用人工智能的时候,不是成立一个专门的小组做研究,而是百花齐放的方式。了解普元的朋友会知道,普元的研发分为云计算&SOA、大数据、移动、工程效率与技术平台、产品支持中心几个团队,我们让每个团队从数据+连接方向上入手,各自探索人工智能在领域上的应用场景,通过找到切入点和初步实践,逐步建立团队的人工智能思维。其中云计算&SOA团队的方向是通过服务画像方式解决微服务的智能运维与智能匹配,大数据团队的方向是通过知识图谱实现数据自服务,移动团队的方向是UI的智能化开发,工程效率与技术平台团队的方向是深度学习在流程与智能制造的应用。由于篇幅有限,这里我只把普元大数据团队和移动团队所做的工作做一个介绍。
 
    案例一:基于知识图谱,实现数据的自服务能力
 
    先简单介绍一下背景:大家经常会听到有人问我们有哪些数据,这些数据在哪里,如何获取数据的问题,能否建立一个平台,让我们象百度搜索一样,根据我们的知识(业务术语)找到相关的数据,提交申请,得到数据,这就是一个获取数据的自助服务。
 
    以往数据在哪里往往通过人工梳理完成,我们希望能够自动化一些,为专家提供一个智能的助手,这里的工作分为三部分:
 
    (1)建立知识图谱
 
    人进行数据搜索是通过业务术语(知识)来搜索的,而知识之间是有相互联系的,例如水果和西红柿是上下位关系(后者是前者的具体体现),搜索是除了要列出直接结果,还需要显示一些关联的知识,这就要建立知识图谱。简单说知识图谱就是概念、属性以及概念之间的关联关系, 这个关系可以手工建立,我们通过对政策、法规、需求、数据库comments、界面等多种来源,采用自然语言处理等方法,可以建立起部分的知识图谱,辅助专家的工作;
 
    (2)梳理技术元数据
 
    整理各个系统内部数据,以及数据之间的关系,形成数据地图。这里的难度是数据之间的关系,例如数据的血缘关系、影响度关系、关联关系、主数据关系等,这里我们采用字段特征的相关性、数据处理逻辑的词法/语法分析等手段,配合强化学习来完成,前面列举的查找外键示例,就是一部分;
 
    (3)建立知识图谱与技术元数据之间的关系
 
    这里就要通过分析界面/服务与代码之间的关联,建立起映射关系。最终效果就是,使用数据搜索,录入希望查找的业务术语,得到相关结果,查看样例数据,如果是需要的数据,提交使用申请,如果不是,继续根据相关知识进行数据探索。提供数据自服务能力,就是在应用的设计师、数据科学家或者业务分析师与数据之间建立起连接,我们的团队就是从连接的思路出发,找到了人工智能的切入点。
 
    实际上,数据自服务包含有找、获、用等众多环节,我这里说的是找的环节如何实现,这种找的方法,也不可能100%准确,还需要专家进行调整,以及通过强化学习等手段不断修正,可以看出,应用人工智能也是一个渐进完善的过程。
 
    案例二:通过深度学习,实现移动UI的智能化开发
 
    移动UI的智能化开发,是我们移动团队应用人工智能的第一个尝试,现在看来,就是在UI设计师与开发工程师之间建立连接。大家会发现,设计师的设计在变成代码实现时总会有偏差,即使一个像素的差异,也会影响界面的效果,以往我们采取不同业务模板的方式,建立一些规范对设计和开发做约束,后来移动团队觉得,可以用深度学习的方式做一些尝试,寻找不同的界面设计效果,首先通过数据标签方式确定页面的风格,再通过图像片段的方式学习和识别设计稿中的组件,最终经过多次的处理,变成一个树状的结构,把这个树状结构与代码进行映射,就产生了和设计图一致的代码。
 
    这个案例中,基于图片的神经网络学习是一个关键技术,但是如果单纯使用这个技术,计算量会无法承受,所以我们将处理过程分成了几个阶段,每个阶段进行分类,每个阶段都可以配合强化学习的方式,由人工指定策略,指导计算机的学习,提高了工程化的能力(类似做法在深蓝对阵卡斯帕罗夫的时候就有应用,有一位特级大师会指导深蓝当前的策略,例如进攻还是防守,具体招数由深蓝决定)。
 
    上述两个案例中,我们首先在各个领域中找到可能的切入点,针对不同场景使用了不同的方案,并不是都采用了深度学习/神经网络的方法。我们没有首先从Tensorflow等框架学起,而是在结构化、半结构化优先使用统计方法,非结构化数据再使用深度学习,而是用业务驱动的方式逐步推进,有效的避免了“深度泛滥”。
 
    总结
 
    未来的软件必将是人工智能的软件,但人工智能是通过技术手段实现智能增强,帮助普通人迅速具备部分专家的技能,帮助专家减少重复性的劳动,探索新的知识,而不是取代人。应用人工智能,应该在数据+连接的模式下,从智能集成入手,探索人工智能在软件中的应用。而这种探索,既包括传统利用规则实现的机械智能,也包括利用统计学和深度学习方法支撑的实现意图智能,还有创造意图/寻找新知识的探索,而统计学方法往往用在结构化数据和半结构化的数据中,深度学习往往要利用非结构化数据。
 
    总之,人工智能是计算机科学、统计学、知识工程、领域知识的一个交叉学科,不能仅仅站在某个角度去理解和尝试,正所谓“君子不器”。
 
责任编辑:李欢
本文为授权转载文章,任何人未经原授权方同意,不得复制、转载、摘编等任何方式进行使用,e-works不承担由此而产生的任何法律责任! 如有异议请及时告之,以便进行及时处理。联系方式:editor@e-works.net.cn tel:027-87592219/20/21。
e-works
官方微信
掌上
信息化
编辑推荐
新闻推荐
博客推荐
视频推荐