http://www.0913wn.com

基于人工智能场景的挪动平台工程化

  本文主要是将我们在2017年相关的实践做个总览式的分享,希望能够给各位一定的启发。首先总结一下,我们在做人工智能与移动互联结合的时候,最重要的目标是:人工智能工程化。

  本文主要是将我们在2017年相关的实践做个总览式的分享,希望能够给各位一定的启发。

  首先总结一下,我们在做人工智能与移动互联结合的时候,最重要的目标是:人工智能工程化。

  做GPU的英伟达、提供开源的基础框架TensorFlow的Google、研究各种算法的科学家,与我们分处人工智能产业链的不同环节,而我们的目标是寻找合适人工智能的场景,结合行业的一些经验,形成工程化的解决方案。

  人工智能(AI)赋能企业移动信息化建设,其本质上就是人工智能在企业移动信息化过程中工程化落地。

  支撑人工智能工程化的过程需要依赖与数据、技术、场景的三者结合,并结合软件工程化的思想将其融合。而这三者之中,场景是关键。

  这里提到的是“数据”,而不是大家经常提到的“大数据”,主要原因是“大数据”三个字很容易让更多的技术团队束缚思想让自己无法从事于人工智能的工程化中。

  甚至早期的人工智能都被某些技术社区划归到了大数据频道,当然去年他们也剥离出来了,我认为人工智能跟大数据没有必然直接的关系。

  后面我们的场景中,并没有强调大数据,而且从数据的角度可以通过主动学习(Active Learning)的方式来部分解决。

  特别是当去年AlphaGo Zero 出现后,让我也重新审视了我对人工智能的理解,数据到底是否还有原有的大家理解的价值。

  AlphaGo Zero 在完全脱离人类经验的情况下,一盘棋谱也没有学习,完全超越以人类经验为基础的AlphaGo,同时创造了很多人类棋手原来未曾想到的棋局。以至与着名的棋手柯洁有意无意中都在模仿AlphaGo Zero的经验来应对人类棋手。简单点说,人类正在向机器学习。

  AlphaGo Zero的出现,对于人工智能界,我认为最大的触动是证明了零数据的强化学习的巨大可能性和未来的空间。

  我认为,未来的人工智能,技术(模型)的价值远超数据(已有经验)的价值必将成为共识。

  这就回到了技术,技术离不开软件、硬件、算法的迅速发展,技术上的提升,让人工智能(AI)加速落地。技术上,主要围绕在框架、算法、算力几个维度去组建。

  在后续的场景中,我们主要采用的是基于Google TensorFlow的平台上,一些成熟算法或者模型上的应用,基于我们的算力和性价比,我们也会做出些取舍,比如用Faster-RCNN代替RCNN等。

  在企业进行移动信息化/移动互联的建设中,都需要经过建设期、运维期、运营期等一系列阶段,从用户角度看,本质上需要的是一个个的智能化的应用Intelligent Apps(参见Gartner: Top 10 Strategic Technology Trends for 2018)。

  对于工程化的落地,我们认为场景更重要,我们到底需要什么样的智能化,支持我们做什么事情。

  探索:主要是确认了场景后,结合框架、模型以及自有算力,寻求各种模型进行研究和实践。在这个场景中,我们最终选择了基于CNN的分类算法以及基于Faser-RCNN的目标检测算法。考虑到数据的标签工作量的问题,我们采用了迁移学习的方式。训练:根据探索确定的方向,构造标签化的数据。在这个场景中,我们采用分类的标签化工作和目标检测的标签化的工作。关于为什么采用上述工具大家可浏览我上一篇文章《使用TensorFlow搭建智能开发系统,自动生成App UI代码》。上述过程中是一个不断调整不断循环的工程,最终我们会选取一个模型。用于人工智能服务化(AIaas)和产品化的工程。这个工程中主要采用的软件工程的方式进行,需要考虑的是AIaas的工程中并发对算力的要求,我们采用的是AIaas之前增加了队列和调度,这里就不赘述。

基于人工智能场景的挪动平台工程化

  如上图,CNN(VGG)、Softmax、Faster-RCNN等都是基于Google TensorFlow的搭建的,并且主要的工作围绕在基于GPU架构下进行。Basic Component、Complex Component、DSL Generator、DSL Code、Compiler、Runtime等部分,是主要基于传统的CPU架构下的软件思路整合。通过AIaaS化,我们将基于TensorFlow的智能服务隐藏在基于Java 的SaaS服务之后,最终,开发工程师可以通过IDE的方式进行访问,同时让我们更新模型对于最终用户无法感知,最终以“智能代码助手”的试图(view)在IDE中进行体现。场景二:智能的连接和呈现,以智能化的CUI方式为最终用户提供会话式交互体现。

基于人工智能场景的挪动平台工程化

  CUI是移动端最近比较看重的体验方式,相对于传统的CUI,以纯语音、文字的交互,已经演变成语音、文字、事件、连接、视频等多种体验方式。在这个范畴里,我还是比较认可百度DuerOS的负责人说的,有三个方面的工作:听清、听懂、满足,并且对三方面有自身的理解:听懂:理解文字在特定领域的意义,这里要强调特定领域。我们遇到的一个客户经常提到“寄递”,在该业务领域,这个词语背后代表着一系列安全与法规相关的问题。针对企业市场,“满足”的解决方案没有任何一个公有服务的方式能够很好做支撑的,原因比较简单,企业中大量“满足”最终是通过自身私有的服务得以提供,而这部分必须采用私有部署的解决方案才能做到,也正是我们需要关注的重点。关于听清的解决方案,我们非常认可现有很多解决方案,都很成熟,包括baidu,最终我们默认的方案中优先选择了讯飞 。而我们在工程化中,主要围绕着“满足”展开,主要寻求以下两方面的的解决方案支撑:

基于人工智能场景的挪动平台工程化

  为此,我们基于关键字、语义等信息与后端Service的调用关系训练模型,支撑智能连接。同时,我们对服务调用的反馈结果以及移动端UI模型库信息进行训练,以提供智能显示。UI模型库采用完全动态的方式,以支持各种复杂场景的支撑,从而达到高扩展性的发展。在小小的手机屏幕下,容不下越来越多功能的时候,让低频的功能更方便的被使用,除了即用即走的二维码入口的小程序外,CUI应该是一种非O2O更好的选择之一。场景三:智能推荐和辅助决策,让用户在适当的时间、地点,做“正确”的事情

基于人工智能场景的挪动平台工程化

  从业务场景角度看,推荐、辅助等模型在技术维度和互联网公司的“猜你喜欢”等并没有太多差异性,需要说明一点的是,在做企业市场的时候,我们建议的方式,不是基于用户,而是基于组织机构(比如岗位)去进行分析。原因很简单,如果基于用户习惯,会导致一个喜欢迟到的人,总是在迟到的时间点推荐其打卡,这显然既不符合用户的个人诉求,也不符合企业的利益。

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。