注：转载请注明出处

本报告通过对Siri的分析，了解和学习人工智能助手在现有市场的应用情况，为制作机器人产品提供一些思考的方法和方向。

一、产品基本情况

分类

描述

中文名称：

苹果智能语音助手

苹果智能语音助手：

Siri

软件类型：

语音助手

首次面世时间：

2007年作为App Store的一款应用

Apple公司对Siri的宣传广告语：

与 Siri 交谈可让你更加轻松、快速地搞定大小事务。它就在你的 iPhone、iPad、Mac 和 Apple Watch 上，时刻伴你左右，随时为你提供帮助。让 Siri 设置闹钟或路线，为你叫车或预订会议，发送一个邀请或一条爱意满满的信息，甚至是调节你房间的灯光照明。你使用 Siri 的次数越多，它就越懂你的心思。只要说出你想要的，剩下的 Siri 会帮你搞定。

类似明星软件：

1.Facebook M

2.Amazon Echo

3.Google Assistant, Allo

4.Apple Siri

5.IBM Watson

6.Microsoft Cortana

版本更新大事件：

iPhone 4S iOS 5 Siri首次推出

2011年10月13日，苹果发布了iPhone 4S，搭载iOS 5系统，推出了语音助手Siri，尽管当时这款软件被当做玩偶来戏弄。

iOS 6 Siri新增15个国家和地区语言

根据蒙斯特的测试，在iOS 6中，Siri能够理解91%的问题，而在iOS 5系统中为89%；在iOS 6中，Siri回答问题的准确率77%，高于iOS 5的76%。虽然Siri从iOS 5到iOS 6的改善幅度并不大。

iOS7中除了Siri“测试版”字样

2013年6月10日，苹果在iPod、iPhone和iPad设备上正式放出iOS7操作系统更新。减少对Google的依赖，优化声音和中文识别，其中在Siri方面去除了“测试版”字样。在此之前一直是处于“测试阶段”。

iOS8增加唤醒“嘿Siri”

iOS9中Siri增加了彩色元素，在这之前Siri一直是黑白搭配，以智能穿戴为中心的智能家居正在形成

iOS 10 Siri首次开放了权限给第三方应用

从iOS 10开始，可能变化最大的Siri，这一诞生五年的产品第一次被移植到苹果的笔记本电脑上，另外向第三方开发商开放，意味着功能将极大扩充(比如利用Siri购买电影票、机票等)。

在国外Siri首次开放了权限给第三方应用：WhatsApp、领英、Pinterest、Square Cash 和 Slack，也包含一些没有那么响亮的名字，例如 Looklive 和 The Roll。这些应用的体验更多集中在支付、拍照片、发消息等基础交互。

二、背景介绍

Siri的学术化全称为“个人自动智能助理”（Personalized Intelligent Assistant），并非苹果公司自主研发，最初是苹果AppStore的一款应用，苹果公司发现后很快于2010年4月份从斯坦福研究机构国际智能中心（SRI）处收购而来，传言收购价格在2亿美金左右，之后很快Siri从AppStore下架并集成进入IPhone 4S。

三、行业分析

（一）人工智能发展方向

未来所有的政府、公司、军队都是人工智能机构，人工智能将无处不在。美国国防部20年未到访硅谷，而在任国防部长卡特自去年上任以来连续4次密集访问硅谷，对人工智能表示出极大兴趣，直言要将民用AI技术用于改进国防装备体系，帮助美国培育出新型的“钢铁侠”战士，国防部高等研究计划局（DARPA）正在基于人工智能技术研发自动驾驶战车、反潜无人机械船、智能电子战系统、“半人马”人类作战行动辅助系统等。据悉，美国国防部 2017 财年建议的研发预算为120～150亿美元，而被国防部所看重的硅谷科技公司，如谷歌、微软、苹果、脸书和英特尔等巨头也正在不约而同地投入“人工智能优先”战略。

（二）在API困境被解决之前的智能助理困境

智能助理： Intelligent personal assistant/agent (IPA) 又称为Virtual Personal Assistant/Agent(VPA)——帮助个人完成多项任务或多项服务的虚拟助理，当前讨论的核心驱动力是人工智能。

而“对话式服务（conversational service/commerce）”——这是包含智能助理在内的多个产品形态的统称，核心特点是：

1.对话式：人机交互的方式由图形化交互（GUI-Graphical User Interface）变为以对话作为交互方式（CUI-Conversational User Interface 业界暂时还没有定义，这是我自己瞎编的），就是用说话来代替触摸或者鼠标，操作计算设备。

2.服务：提供服务，解决问题都算，如订机票，购买礼物等。不包括信息查询（如天气）。

截止到2016年6月的时候，在Producthunt上标记为对话式服务（ConvComm）的有一百多个创业项目。

选择Producthunt当中排在最前150位的项目进行分析，其中高达70%的项目定位都在2C的个人助理（agent）上，其中大部分都想做切入服务，包括垂直类的和多任务的。

这些助理服务当中有23.1%是专业类型的服务，主要是在医疗和理财方面。而剩下来的76.9%的助理干的最多的活儿是生活上的综合帮助，出行安排，日程管理，购物订餐厅等等——这一类是坑最大的地方——特别是那些试图把生活上的各种服务都打包进去的产品。

Producthunt上面69.7%的对话式服务都是智能助理产品（但并非所有都具备AI）

多迹象都指向同一个结论：移动互联的高速增长已经饱和。比如用户已经不再愿意下载新的APP。

2016年1月有超过5万个新的APP被提交到了appstore，但是在美国市场有65%的智能手机用户在一个月内下载新APP的数量为0，下了1个新APP的人占8.4%。

回顾过去，最大的几次浪潮基本都伴随着一个规律：核心技术（软硬一堆）的出现和整合，带来全新的人机交互方式 ，在此基础上大量的商业应用应运而生。

从90年代，人机交互的三种变化比如2007年末移动互联开始，核心驱动的硬件是触摸技术、各种sensor的成熟以及整体计算能力的提升和小型化；软件方面则是iOS&Android的颠覆式出现。软硬结合创造出完全颠覆过去的触摸操作的体验，并使其称为真正可用的人机交互方式——让图形化界面的输入工具，从键鼠时代跨越到了更intuitive的触摸，并完美的与后面开放的生态系统结合起来（不得不再次对乔大爷表示敬佩）。

可以看到随着技术的平民化(democratization)，人机交互正不可逆转地向人的方向靠近——不需要学习的人机交互。

为了深入理解这个问题，我们可能要先分析一下，CUI和GUI究竟给用户体验带来什么影响？因为这绝不是现在主流的“把按钮变成语言操控”那么简单的事情。

CUI的特点：

高度个性化，所有用户能做的选择范围，都明确的显示在界面上（所见即所选）

这看上去是一个大家非常熟悉的界面，只是所有用户能做的选择范围，都明确的显示在界面上（所见即所选）。找美食，用户能做的选择基本就是：附近，类型，智能排序（不点开可能还不知道是什么意思）以及排序。当用户自己不知道该如何决策的时候，这些视觉化的框架，给了用户提示该从这些方面根据自己的需求来做筛选和匹配。

但是在智能助理的界面，用户看到的是这样的：

用户对可以做哪些选择一无所知——在没有可视化的参考下，面对如此开放的交互，当用户要找一个餐厅的时候，他们提出的要求，大都不在GUI设定的范围以内。

根据我们实际操作的经验，用户提出的问题是这样的：

1、基于上下文的对话能力(contextual conversation)

在当前，做助理的产品的底层技术基本都是围绕NLU（自然语言理解）打造的，很多还没有涉及到NLP。可是无论是大公司还是小公司的NLU都是让人失望的。举个简单的例子，在大公司的几个产品上提出需求：我下周五要去北京，帮我查一下航班。

需要识别意图：查机票

需要识别entities：时间（下周五），目的地（北京），出发地（无/当前地理位置）

我们看看结果，首先看三家的回复，从左到右分别是苹果的SIRI, 微软的CORTANA, Google的ALLO。

换一句话来说，没有结合上下文的对话，会造成的最严重的问题就是这个agent基本不能独立完成服务。因为用户不会在一个句子里把所有的条件都列出来。

不能真正理解上下文的对话（机票查询）：

AGENT： 从哪里出发？

用户：上海虹桥机场

AGENT：到哪里？

用户：还是从浦东走吧

AGENT：好的，从虹桥出发到浦东的航班是......

在上面的对话，AI Agent在问第二个问题的时候，不能理解用户对前一个回答的修改（出发地从“虹桥”改为“浦东”），只是按照预先设计对话的顺序，填上命名实体识别得来的entity。继而查询不到结果，给用户的感觉就是笨。

真正理解上下文的对话（机票查询）：

AGENT：从哪里出发？

用户：上海虹桥机场

AGENT：到哪里？

用户：算了，从浦东走吧

AGENT：好的，出发改为浦东。那到达城市呢？

用户：北京

AGENT：好的，从浦东到北京的航班是...（给出正确的结果）

而具备真正上下文理解的对话，agent可以正确理解用户第二个回答的内容（从浦东走），其实是在修改上一问题的回答（出发机场），而不是真的在回答第二个问题（到达地在哪里）。

这只是上下文的例子，而对于服务类agent而言，所有后续的NLP功能都基于上下文对话为前提。这些看上去其实都是非常简单的需求，但是当前没有任何一个2C的agent可以做到。

可能有人会问，大部分用户都应该在第一时间把需求表达出来吧，为什么还需要对话？实际上，真正操作过大量案例的同学就会发现，用户不可能如此”贴心“地按照开发者的设计来提出需求。

“帮我看看下个星期五去北京，下午3点多，从虹桥出发，国航的航班。” ——这一类的表达方式在几乎从来没有出现过。哪怕是在用户最熟悉的场景，也很难确保一个句子的表达里包含了所有必须的检索条件。而且，用户还会不停的补充更多的个性化需求。

对于用户自己比较了解的场景，如：订机票需要提供到达地，用户提出的大多数需求，在最初都是非常简单，然后逐渐开始细化的。所以需要当用户提出不完整需求的时候，根据其意图，结合之前已经给过的条件，通过对话，向用户提出问题，再获得答案来补全剩下还需要的条件，最后再完成服务。

对于用户自己不熟悉的场景，用户根本就不知道自己该提出哪些方面的需求。如：不懂酒的用户，想买一瓶合适的威士忌。他就根本很难提出除了价格以外的需求，比如产地，年份，酿造原料，水源等等。因此，Agent得以合适的方式来提问，引导用户给出偏好，并且用对话提出推荐。

而且对于agent而言，很难判断哪些用户对服务的认知有多深。如果不做识别，就容易问”老手“一些”新手问题“，继而让老手觉得我还不如自己下单；而给新手又留下”你在说什么我都不懂“的印象，也是不聪明。

所以要有好的体验，这是非常困难的。而基于上下文的对话，只是最基础的用户需求之一。

2.理解口语中的逻辑 (logic understanding)

在我们的实践中，我们发现对”逻辑“的理解直观重要。原因也是因为用户的正常对话，大部分都不是开发者预设那样的。

再做一个简单的测试，比如找餐厅，试试：帮我推荐一个附近的餐厅，不要日本菜。

这是一个简单逻辑，但是你看所有的服务，这次包括刚刚那个国内创业公司C一样，都会是一个结果：全部推荐日本菜。测试了亚马逊echo的alexa，结果也无法识别”不要“这个最简单的逻辑。

这次其实比刚刚好多了，至少4家里面除了google allo，都识别出来我的意图是找餐厅——但是，当我明确提出不要日本菜的时候，给出结果的三家全部都是日本菜......也就是说“不要” 两个字被完全忽略了。

观察大量的用户案例表明，当用户越是个性化需求强烈的时候，对话中出现逻辑和指代关系的频次越高。

 “有没有更便宜的？”

除了大床房以外的房间有么？”

“后天会比今天更冷么？”

“就要刚刚的那个2千多的吧。”

“除了廉价航空，其他的航班都可以。”

以上这些需求是提需求的时候，在对话中经常出现的表达方式，而且看似简单，但是目前没有任何一个NLU的系统或产品能够正确的理解。主要的阻碍就是对逻辑的理解，还有在基于上下文对话中的指代关系的理解失败。

3. NLP不是全部，还要有能力履行（API困境）

NLU并不是智能助理发展的瓶颈，供给端的数据才是。

我们假设如果有一个黑科技出现，使得NLP有了极大的进步，以至于两个条件：1）基于上下文场景的对话；2）口语逻辑，都能被理解了，甚至还能基于场景和上下文用NLG来生成各类问题——它能理解我们所有讲出来的需求。

在用户熟悉的范围内，它能结合所有的过去的对话，历史记录等等内部外部条件，帮助用户尽可能的实现“不用开口，就知道我在这个的需求”。比如当用户提出“推荐餐厅的需求”：

用户：“女朋友周日过生日，推荐一个餐厅，找有江景的，最好桌子旁边有一个大落地窗户，能看到外面的夜景。吃的不要太贵，环境好点，有现场音乐的最好是爵士，不要太吵的。”

Agent：“菜系有偏好么？”

用户：“意大利餐和法餐都可以，对了不要离外滩太远了”

agent解析出以下选择餐厅的条件：

1.周日晚（营业）

2.适合女朋友过生日

3.有江景

4.有大落地窗

5.不要太贵

6.环境好

7.有现场音乐，爵士

8.不能太吵

9.意大利餐或者法餐

10.距离外滩不能太远

然后它去哪里找到这样的餐厅呢？在地图服务提供商，或者点评的API提供的信息里只有8，9，两项能找到数据。假设评论中有这样的数据，该用什么方式来传递呢？接口提供的都是结构化的数据，而“环境好”这样的非结构化数据，最多以标签的方式来做，但是这样的话，标签就会有无止境的多也不现实。

这就是我们所谓的“API困境”——当前基于API的数据传递方式，只能1）承载结构化数据；2）承载数量非常有限的结构化数据。

当前基于GUI的产品，都是用API来传递结构化数据。但大量个性化数据往往是非结构化的，以当前API的方式很难被处理。这还是在使用场景或者服务比较简单的情况下。

在用户不熟悉的场景下，agent面对稍微专业一点的服务，就会遇到知识图谱的问题。简单来讲，agent要做推荐的前提是对推荐的内容得先有了解。好比，要向一位不懂酒的用户推荐一款威士忌，那就不能依赖这位用户自己提出的问题（很可能提不出要求），而得依赖“懂行”的自己对威士忌的理解的方方面面来引导用户做合适他的选择。一个助理显然无法拥有所有服务所需的知识图谱。

从知识图谱的结构来看，是相对可被结构化。一个服务可以以各种方式被拆解成很多个方面，但大量的方面在当前是没有结构化数据的（比如我们没有每家餐厅的”营业面积“的数据）；甚至很多方面无法用结构化数据来表达（比如每家餐厅有否”适合浪漫约会“的环境）。

因此，智能助理就算有了强大的NLP，还需要全面的知识图谱（结构化数据）和处理并传递非结构化数据的能力——而这两点，在目前是无解的。

总结

在“API困境”解决之前，再加上NLP本身还有很长的路要走，基于人工智能的多任务服务agent不大可能达到C端满意的水平。

四、使用技术

（一）技术来源

Siri 技术来源于美国国防部高级研究规划局所公布的 CALO 计划：一个让军方简化处理一些繁复庶务，并具学习、组织以及认知能力的数字助理，其所衍生出来的民用版软件 Siri 虚拟个人助理。现在它采用了Nuance公司的语音识别技术。

（二）Siri的整体技术架构猜想

Siri是一个功能繁复的综合AI框架，Siri里包含的众多数据、模型和计算模块划分为输入系统、活跃本体、执行系统、服务系统和输出系统五个子系统。其在解析用户输入时候遵循一定的执行顺序，以此来理解用户的真正意图并提供有用服务。

Siri的资源主要分为资源类和计算类两大类，其中属于资源类的包括;

属于计算资源的包括：

Siri的输入系统支持多模态输入，即不仅仅支持众所周知的语音识别，也允许用户进行文本输入、GUI界面操作以及事件触发等。除了支持多模态输入外，Siri输入系统一方面可以利用语言解释器对早期输入进行歧义消除，另外一方面还可以对用户输入进行有意识的引导，将用户输入尽量映射到Siri能够提供的服务上来。这样对于用户和Siri来说才可相得益彰，Siri 可体现其价值，用户可获得帮助。

举例，想象一下，当你在骑行的时候，Siri在你耳边提醒你临近会议的准确时间和地点，并为你语音导航，同时为你口述刚刚收到的短信息——所有的动作都没有打断你的骑行运动，这就是语音交互的优势所在。

（三）前端方面技术

前端方面，即面向用户，和用户交互（User Interface，UI）的技术，主要是语音识别以及语音合成技术。语音识别技术是把用户的口语转化成文字，其中需要强大的语音知识库，因此需要用到所谓的“云计算”技术。iOS10.3系统的Siri经测试证明必须在有网络的情况下才可以使用。

（四）后台技术

这些其实才是真正的大角色。这些技术的目的就是处理用户的请求，并返回最匹配的结果，这些请求类型很多，千奇百怪，要处理好并不简单。基本的结构猜测可能是分析用户的输入（已经通过语音转化），根据输入类型，分别采用合适的技术（合适的技术后台）进行处理。这些合适的后台技术包括，①以Google 为代表的网页搜索技术；②以Wolfram Alpha为代表的知识搜索技术（或者知识计算技术）；③以Wikipedia 为代表的知识库（和 Wolfram Alpha 不同的是，这些知识来自人类的手工编辑）技术（包括其他百科，如电影百科等）；④以Yelp 为代表的问答以及推荐技术。

（五）网页搜索

在大陆Siri以百度为搜索结果，且每次只展示5条搜索情况。

传言Siri试图摆脱Google的搜索技术

Siri一直被视为苹果语音搜索的未来，同时也被视为Google搜索的潜在竞争对手，然而这一切最终的竞逐场都在数据库。而在最近的一项测试中，Siri回答问题的准确度只有62％，与Google相差甚远。

与iOS 5相比，在iOS 6中苹果大幅增加了自己产品的比例，包括其刚刚推出的地图服务，而来自Google的数据大幅降低。在美国投资银行Jaffray的分析师Gene Munster发布的一份有关Siri和Google搜索准确性的
报告中，提到了以下三个关键点：

*Google能理解100%的问题，回答问题的准确度为86%

*Siri在嘈杂的环境中能理解83%的问题，在安静的环境中能理解89%的问题

*Siri在嘈杂问题中回答问题的准确度仅为62%，安静环境中回答问题的准确度为68%

从苹果最近的一系列动作来看，它急于摆脱对Google在某些方面的依赖。但是在搜索这一块，借助于强大的数据库，要撼动Google地位谈何容易。虽然其语音搜索产品比苹果的Siri晚，但是依靠搜索建立起的强大数据库，Google 事实上已经给出了答案。而在最新的iOS 6中，Siri仍有近一半的数据来自Google。

（六）知识计算

五、使用数据

备注：以下数据只做对比，其参考性随着时间的推移逐渐减小。

苹果是智能语音助手先锋，但发展速度一直很慢。虽然Siri现在已经被集成在了可穿戴设备中（Apple Watch和AirPods），但Siri仍然缺少机器学习功能和用户数据，Siri不支持这些的主要原因是苹果更看重数据隐私和安全性。

这次调查中有超过1000位英国智能手机用户参与。语音助手最大的用户群是年轻的男性。用户选择语音助手的三大原因分别是：方便、简单和比如输入更快。第四个原因竟然是有趣，很多人经常让语音助手给自己讲笑话。

调查中还发现，22%的用户感觉在公众场合与自己的设备说话很尴尬，人们更喜欢在家中使用语音助手

以下附一篇网站的数据报告，作为参考，可登陆该网址查看详细的数据：http://www.sojump.com/report/12301070.aspx；

六、产品分析

（一）产品功能分析

Siri被使用最多的的功能：在线搜索、播放音乐、查看天气情况和导航。

功能框架图如下：（备注：可放大查看）

内容对应下图：

对应下图：

最糟糕的是，已经被去掉“测试阶段”名号的Siri在10.3系统上仍然存在bug，要达成任务仍然存在难度。

搜索

搜索功能在界面展示上来说，对于Siri是一个鸡肋，Siri追求的极简界面，和Siri 统一风格的UI界面，让在大陆的百度搜索最多只能展示五条结果，暂且不谈搜索的内容是否符合用户的预期，这种展示方式便不适合于查看搜索引擎的内容，且经过多次跳转才能达到目的地，又无返回机制，所以搜索功能就如其他第三方插件一样始终是作为一个插件存在，并无法正在的与Siri融为一体，更无从谈起与Google抗衡，那一天的到来首先要解决的便是这种多模态的交互方式。

Siri针对百度百科做了一些专门的图形化表达处理，以便于能够用百度百科简单的回答用户的问题，展示了一定的差异化，在界面上Apple公司总是超越其他产品。

在本地嵌入式调用操作这一层可以看出，Siri正在朝着分析用户数据的方向来发展，例如给用户的照片添加标签：拍摄时间、拍摄地点、人物等，可以完成一些简单的查找功能，对Siri说：查找我今年在雅安的照片，得出了如下的结果：

（二）产品性能方面

语音方面：合成痕迹很重

中文识别能力：仅次于科大讯飞

优势：作为一款手机助手拥有调用root权限的天然优势，是一切其他助手无法比拟的；

劣势：出于害羞，和不打扰其他人的心理，我更需要戴着耳机使用Siri，但是不能通过耳机麦克风唤醒，只能对着手机唤醒（此处可能涉及回升消除造成的影响）；

调用第三方插件的速度有待提高；

虽然Siri在中国向QQ、滴滴出行、Keep这几款开放了接口，但是也是一时可用，一时不可用，用户可通过Siri与这些第三方接口产生的操作也仅限于浅层次的发消息、打开应用等能一步或者简单操作完成的步骤，并不能对用户使用这些应用的日常行为产生什么影响，而且90%以上的中国大陆用户并不知道可以通过Siri来操作QQ或者滴滴。

（三）产品交互设计分析

沿用iOS系统的设计，尽量保持一致

设闹钟和提醒，直接在界面显示开关按钮，沿用设置界面

打电话

调用打电话应用需要一定时间，感觉上并不十分快速；

 

发短信

如果出现设置按钮同样会被取消，这样已经成为历史的消息就只能是历史，再无法进行操作，不会带来界面上多按钮操作的流程上的错综复杂，坚持了简单的聊天界面，我想这也是音乐播放一定要采用插架方式的原因；

 

比赛、天气等

百度搜索结果最多只显示5个，但是提供一些建议说法给用户；

 

声音的交互设计：

1、在播报时和提醒用户说话时采用不同的声音提醒用户；

2、在触发应用完成时发出应用原本的声音提醒用户，例如发短信时有短信发送的声音。

七、未来猜测

从上文的分析结果来看，人工智能或者说智能助理要颠覆现有的移动终端设备的触摸式人机交互方式目前来说很不现实，不具备上下文理解的能力、逻辑处理能力技术上的局限性、API本身的局限性带来的困境，人工智能未来将走向何方，仍然有很多未知领域需要探讨。Siri在苹果公司坚持的这7年里有很大变化，但是总体来说发展很缓慢，也许这一点恰好说明了AI在目前的市场环境下存在非常大的局限性。

1、以下几个方面是个人认为Siri目前最迫切需要解决的问题：