基于人工智能场景的移动平台工程化实践

转载本文需注明出处：微信公众号EAWorld，违者必究。

目录：

一、人工智能的核心是工程化，场景是工程化的关键

二、三类场景化实践

三、总结

持续关注我们公众号的人可能会留心到我们在移动平台和人工智能的结合上进行过多方面的尝试，也发布过两篇专题文章。分别是《智能化的Conversational UI是移动发展的一个趋势》和《使用TensorFlow搭建智能开发系统，自动生成App UI代码》

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

一、人工智能的核心是工程化，

场景是工程化的关键

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

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

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

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

人工智能与数据并非一定强相关

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

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

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

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

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

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

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

技术提升加速AI实践

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

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

客户需要的是智能化应用场景

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

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

基于上述的思考我们抽取了几个场景采用机器学习的方式进行了工程化实践。

二、三类场景化实践

场景一：移动智能开发平台，让工程师快速具备专家80%的开发能力

（视频：移动智能开发平台）

这部分工作在工程化过程中，我们分两部分进行实践：

1、训练阶段

2、应用阶段

如下图所示：

探索：主要是确认了场景后，结合框架、模型以及自有算力，寻求各种模型进行研究和实践。在这个场景中，我们最终选择了基于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中进行体现。

（视频：普元AI智能移动平台工程化版本）

场景二：智能的连接和呈现，以智能化的CUI方式为最终用户提供会话式交互体现。

CUI是移动端最近比较看重的体验方式，相对于传统的CUI，以纯语音、文字的交互，已经演变成语音、文字、事件、连接、视频等多种体验方式。在这个范畴里，我还是比较认可百度DuerOS的负责人说的，有三个方面的工作：听清、听懂、满足，并且对三方面有自身的理解：

听清：将在各种场景下的语音，结合上下文的情况，转换成文字。

听懂：理解文字在特定领域的意义，这里要强调特定领域。我们遇到的一个客户经常提到“寄递”，在该业务领域，这个词语背后代表着一系列安全与法规相关的问题。

满足：为最终用户提供强交互能力的体验。

针对企业市场，“满足”的解决方案没有任何一个公有服务的方式能够很好做支撑的，原因比较简单，企业中大量“满足”最终是通过自身私有的服务得以提供，而这部分必须采用私有部署的解决方案才能做到，也正是我们需要关注的重点。

关于听清的解决方案，我们非常认可现有很多解决方案，都很成熟，包括baidu，最终我们默认的方案中优先选择了讯飞 。

而我们在工程化中，主要围绕着“满足”展开，主要寻求以下两方面的的解决方案支撑：

如何能够调用到最合理的服务。

如何能够提供给最终用户最友好的交互体验。

为此，我们基于关键字、语义等信息与后端Service的调用关系训练模型，支撑智能连接。

同时，我们对服务调用的反馈结果以及移动端UI模型库信息进行训练，以提供智能显示。

UI模型库采用完全动态的方式，以支持各种复杂场景的支撑，从而达到高扩展性的发展。

（视频：移动功能介绍）

在小小的手机屏幕下，容不下越来越多功能的时候，让低频的功能更方便的被使用，除了即用即走的二维码入口的小程序外，CUI应该是一种非O2O更好的选择之一。

场景三：智能推荐和辅助决策，让用户在适当的时间、地点，做“正确”的事情

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

为了支撑上述的场景，移动平台需要的是能够提供统一的数据收集能力。

采用统一前端技术，让自动埋点的越来越容易，更方便用户行为数据的收集。

同时采用统一中台的方式，更加方便进行收集。

四、总结

在移动互联时代，越来越多的App正在智能化，越来越多的场景正在发生，这是一个大的趋势，但并不是所有的场景对移动应用本身冲击都很大。很多AI场景对于移动平台仅仅是一个SDK的问题，比如类似于生物识别（人脸识别），此外，苹果/Andriod 也都提供了基于手机端的AI技术支撑，因此，作为移动应用业者，需要重点考虑的是，如何将人工智能结合具体的场景，进行工程化实践，让AI迅速发挥业务价值。

关于作者：郝振明，现任普元信息移动集成产品部负责人，十多年IT从业经验，一直专注于企业信息化的工作，近五年间一直从事企业移动信息化、移动互联网化的咨询、产品工作，曾主持参与了Primeton Mobile产品研发、联通集团、广东农信、诺亚财富、中信重工、索菲亚等公司的移动信息化工作。在移动平台、微信解决方案、微信小程序、AI与移动的结合以及移动云方案等领域有丰富的经验和独到的认识。