2020年5月9日星期六

Google Assistant 给智能助手提供的新思路

Google Assistant 给智能助手提供的新思路
Google Assistant 作为目前公认最「聪明」的智能语音助手,在 5 月 9 日的 Google I/O 2019 上又得到了诸多提升和新能力:
  • 它的响应速度快到没有响应动画;
  • 智能的方式也不再局限于「语音」;
  • 甚至开始用大量的数据积累改善体验。
Google Assistant 的每项更新都展现了对于「智能助手该做什么」的思考。让我们一起回顾和分析 Google I/O 2019 上的 Google Assistant 吧:

Duplex on the web

相信大家都记得去年的 Google I/O 大会上 Google Duplex 的表现。它能自然且流畅地对话,甚至真人都无法察觉。去年带来的演示是 Duplex 替你拨打餐厅电话,和服务员沟通并预订座位。今年的 Duplex 不再局限在语音上面,而是帮你完成网络上较为复杂且机械性的操作,让我们来看一下现场的演示视频:
1.00 « - + » x
Duplex on the web 视频介绍
我们看到,只需要说「为我的下次行程租个车」,Duplex on the Web 就会自动打开租车网站,快速走完所有流程,等你按下最后的「确认」键。我第一次看到演示的时候,感觉既惊讶又熟悉,感叹它神奇的同时又觉得其原理在情理之中。于是我分析了一下 Duplex on the Web 租车的过程中到底做了什么。

Google Duplex 是如何租到车的?

如果我们一步一步看租车过程的演示,就能发现 Duplex on the Web 主要做了两件事:一是信息获取,二是自动填表(Auto-fill)。
首先,是信息获取。用户发出「在 National Car Rental 网站上为我的下次行程租个车」命令后,Duplex 需要知道「下次行程」的相关的信息,于是它从日历和邮件中获取了「下次行程」的日期和地点等信息。
获取行程信息
之所以要从日历和邮件中获取旅行信息,是因为宾馆和航班的确认信息都会发邮件给客户,邮件中又包含了日期和地点等必要信息。而日历则会包含用户主动创建或者被他人邀请的事件信息。所以这两个服务正是用户行程信息的「一手消息源」。
接下来,便是一系列的自动填表。自动打开租车网站,带着上一步拿到的信息,填写地点,日期,等等信息。
自动填表,等待确认,自动点击下一步
这种操作大家一定不陌生, 我们在网站上填写用户名密码甚至更复杂的表单时,浏览器会根据储存的信息自动帮我们写好,Duplex on the Web 也做了同样的事情,不同的是这个「表单」的信息需要有信息支撑
浏览器上的自动填表功能已经在帮我们填写表单
最后,对于是否需要婴儿座椅这种超纲问题,Duplex 交给了用户主动填写。按下确认,车就租好了。虽然不是完全自动的,但也给我们节省了绝大部分的手指关节运动。
这样看下来 Duplex on the Web 租车无非是一系列操作的自动化,iOS 的捷径已经在操作系统层面上做到了自动化,Bixby 甚至在第三方应用也实现了自动化,他们有什么不一样呢?

和「传统自动化」有什么不同?

我这里说的「传统自动化」,是指捷径,Bixby,Automator 以及 IFTTT 等等。Duplex on the web 的自动化和传统自动化最大的不同就是有信息支撑,这让自动化体验高出了一个等级。
各路来源的信息作为支撑
在租车这个案例中,如果 Duplex 不知道你什么时候出发,去哪里等等数据支撑,那就失去了意义。我们分析一下租车需要哪些信息:
  1. 行程信息(通过邮件或日历获取,比如日期和地点)
  2. 用户身份信息(获取用户填过的表单数据,比如联系方式和登录密码)
  3. 支付信息(获取用户保存过的支付方式信息,比如信用卡号和安全码)
  4. 车型喜好信息(获取类似情况的邮件,比如上次租车的确认邮件中的车型)
所以 Duplex on the Web 的实现远不是「技术」能解决的,它是更像是「信息的充分利用」。这也是为什么 Google 会去做这个事情,因为 Google 有 Gmail、Google Calendar、Google Maps、Chrome 等互联网基础服务。这些服务用户量庞大,经手的信息都非常重要,租一台合适的车是足够用了,而「传统自动化」获取这些信息相对困难。
另外,「传统自动化」通常需要用户去定义每一步的操作过程以及触发条件,甚至需要一些编程常识。而 Duplex on the web 用起来更加简单无脑,只需要下命令就好。但这个事儿不好说,它有可能是真的智能,也有可能是谷歌工程师帮你定义了每一步操作。

「智能助手」的新思路

读完这些,你可能会想「国内也用不了啊」。就算网络访问顺畅,国内的情况也确实非常不同,不说 Gmail 用户多少,我们是不习惯使用邮件发送确认信息的,更多是用短信,App 通知甚至微信的服务消息。所以 Duplex on the web 的启发意义要大于实际意义,毕竟国内也有类似谷歌这样的信息大头,比如阿里系和腾讯系,甚至 MIUI 之类的定制 Android 系统也有机会去做。
Duplex on the web 的「自动化」本质决定了它的使用场景,这也是为什么它会先对租车和订电影票这些场景下手,他们对人来说相对简单,操作相对机械化。不过不要小看这些场景,我们日常生活中的飞机票、火车票、电影票、水电费、电话费、房租等等可都是 Duplex on the web 发挥的时候。
目前 Duplex on the web 的上线日期还没有定数,官方给出的预期是「今年晚些时间会有更多细节」(预测很有可能是在下一代 Pixel 手机发布期间),我们可以期待支持更多的网站,甚至作为系统级应用,应付手机上所有的机械操作。

驾驶模式

目前很多车主的导航方式都是将手机架在中控台上。这种情况下的手机界面不仅要保持在地图界面,而且操作起来也很不方便,让我们看看 Google Assistant 的驾驶模式是如何用类似 Duplex on the web 的新思路提升手机导航体验的:
1.00 « - + » x
Google Assistant 驾驶模式演示
Google Assistant 的驾驶模式界面有着巨大的按钮方便点击,也会建议一些动作比如开车回家,常用的联系人等,而且在导航时也可随时语音控制,音乐切换也非常方便。

不止大按钮,更是懂你的驾驶模式

驾驶模式的主旋律一定是大按钮,因为它可以降低驾驶时对操作精度的需求,三星、华为和锤子都有做过:
其他的驾驶模式
不过 Google Assistant 驾驶模式可不只是让手机变得更适合在驾驶途中使用,而是让驾驶途中的手机知道你想做什么。在驾驶模式长达两屏半的界面中,只有最顶上的三个图标是手动操作,下面的所有按钮都是智能的建议操作。包含了最近的地点,推荐联系人,推荐的音乐或播客。
可以看出,Google Assistant 驾驶模式基本上就是一个「建议操作大合集」,类似驾驶版「Siri 的建议」:
驾驶模式界面总览
它并不希望你进行两步及以上的操作(即便在优化过的界面上),而是通过数据猜出你想去的地方,你想听的音乐甚至你要联系的人。于是将建议的操作按照重要程度(导航 > 通讯 > 娱乐)排列下来,传统的操作已经作为「留一条后路」存在了。
显然,点击「回家」按钮要比点击搜索框,输入地址,开始导航要快得多。不过这样的驾驶模式必须猜得准才能好用,Google Assistant 通过什么保证呢?
答案就是 Google Maps,至少在美国它是导航的首选。根据 Google 官方和 CapitalIQ 的统计,Google Maps 在全球有 10 个亿的月活跃用户,日平均导航覆盖里程 10 亿公里,存有 20 多亿的点评信息。Google Maps 的信息详细程度也比他人强很多,举几个例子:Google Maps 可以根据你去过的饭店预测你对新饭店的好感度;统计一个地方每个时段的繁忙状况以及平均逗留时间;某个地方的基础设施详情……
Google Maps 的好感度预测,繁忙时段,以及基础设施详情
当然,「智能建议」类的功能都是越用越准。Google Maps 数据只能让导航相关的建议更加准确,对于通讯,音乐,驾驶模式还是需要学习才能好用。
是时候让「国内不能用」理论上场了。确实,不仅国内不能用,非 Google Maps 的用户可能也感到不好用。不过这确实是一个「驾驶模式」的新思路:不是大按钮也不是车载系统,而是将你要的命令摆在手边,减少步骤。
今年夏天,支持 Google Assistant 的安卓手机就能用上驾驶模式。

Google Assistant 大提速

下一项,是实实在在的速度提升,这次 Google Assistant 的速度提升了十倍。 Google 称之为「Next generation Assistant」,先来感受一下它的速度:
1.00 « - + » x
Google Assistant 的速度演示
可以看出其速度显著提高,快要赶上真人对话的速度了,而且它不仅支持简单的语音命令,还支持相对复杂的命令以及邮件撰写等功能。

一个更「可用」的助手

你可能注意到,演示视频中的甚至连表示「正在听」的动画都没有了。这里要提到交互设计中一个重要的数值:400 毫秒
这就是所谓的「多尔蒂门槛(Doherty Threshold)」,即「操作(比如在桌面上点击一个 App 的图标)」和「响应(比如 App 被打开)」的间隔应该控制在为 400 毫秒以保持用户注意力并且提高生产力。
1.00 « - + » x
响应速度超过 400 毫秒时与正常情况对比
如果超过 400 毫秒这个门槛,用户就需要等待,进而怀疑操作是否有误或者手机是不是坏掉了。问题是,对于依赖网络运行的应用来说,400 毫秒根本无法加载完成,比如语音助手。于是大家就通过精致的动画缓解尴尬,保持用户耐心。比如 Neverthink 的视频加载动画和 Netflix 的开启动画:
Neverthink 视频加载动画、Netflix 加载动画
对于语音助手,就是炫彩音波,花式转圈……意思是「我马上就能懂你……」,但「Next generation Assistant」已经快到不需要动画了。速度对于现阶段的语音助手有多重要呢?
想一想为什么你不喜欢在 AirPods 上呼唤 Siri?不都是因为慢嘛。而「Next generation Assistant」由于速度提升,在越来越多的情况下,语音的速度已经比点按要快了。比如「找到所有风景照」,「写邮件给某某人」等需要多次点按才能实现的操作,用语音助手要快的多。
回想一下,你为什么喜欢用 Siri 新建闹钟?因为要比手动新建快上很多。这个来自 Lifehacker 的视频对比了「自己动手」和「用语音助手帮忙」在各种场景中的用时情况。很显然,如果语音助手比自己动手还慢,我们更愿意自己来。
所以只有在足够快的基础上,我们才愿意去用语音助手,才有可能讨论「语音交互能否改变手机操作方式」之类的问题。那么,如此显著的速度提升是如何实现的?

为什么语音助手慢?

要让语音助手提速,我们先了解一下语音识别为什么慢:用户的语音被手机录制 → 语音上传到服务器 → 服务器分析 → 服务器把结果返回到手机。其中「上传到服务器」和「服务器把结果返回到手机」的网络传输过程需要很长的时间,如果网络不好就得多欣赏一会儿「我马上就能懂你……」动画了。
那么为什么需要在服务器上进行语音识别呢,不能放在本地么?这就要提到目前语音识别保证准确度的技术——深度学习(Deep Learning)。
简单来说,深度学习的学习方式是分析数据并寻找其中的特征,这和人脑的认知方式非常类似。比如一个手写的数字图片丢给神经网络,神经网络会先将其抽象为像素点(以下图片来自视频《深度学习之神经网络的结构》):
首先抽象为像素
下一步,在像素点的基础上找规律,将其抽象为各种个小曲线和直线:
抽象为小曲线
下一步,基于小曲线和直线再找规律,将其抽象为圆圈和直线的组合:
抽象为圆圈和直线的组合
最后,基于这些组合给出结果:
图像识别数字的过程
语音识别也是类似,将一段音频拆分成若干小节,然后一层一层分析出这段语音到底在说什么。
深度学习在语音识别上的应用
以上这只是深度学习方式的浅显的解释,实际操作中还会有很多干扰因素。而且深度学习的模型不止一种,比较知名的有卷积神经网络,循环神经网络,递归神经网络等等。如果你想继续了解深度学习,这个视频推荐给你:
综上所述,这种复杂的深度学习导致软件体积巨大,按照谷歌的说法,它足有 100GB 大小。放到本地运行显然过于奢侈。这也是为什么离线听写效果糟糕的原因,因为没有足够的储存空间,只能用阉割版。
所以要想语音助手提速,要么是让网速更快,要么是让语音识别软件小到可以直接放在本地。谷歌选择了后者。

为什么可以这么小?

根据 Google I/O 的现场解释,他们使用了深度学习技术将 100GB 的数据压缩并合并到了 500MB,将其放到了本地。这是如何做到的呢?我们在 Google AI 官方博客找到了一些线索。
这篇今年三月份发布,名为《An All-Neural On-Device Speech Recognizer》的博文中写到:从 2012 年开始,谷歌的语音搜索功能就开始使用深度学习来大幅度提高语音识别的准确性。其后的每一年都会有新的模型结构研发出来,不断提高准确度。
通过不断的优化模型,Google 尝试将语音识别引擎离线工作,而最新成果则是运用训练过的 RNN-T(循环神经网络传感器),将服务器级别的语音识别模型缩减到了 450MB。这与 Google I/O 2019 上提到的大小类似。而进一步压缩的语音识别模型只有 80MB,已经用在新版 Gboard 上面了。
服务器版本与本地版本语音识别速度对比
关于发布时间,大提速过的谷歌助手会在新 Pixel 手机上首次亮相。

小结

Google Assistant 应当是 Google I/O 2019 获得掌声和欢呼声最多的产品更新。现在,我们仍然需要等待这些更新的上线以及完善,不过这次 Google Assistant 的更新内容,让我看到了 Google 对于「智能助手该做什么」的思考:
如同 Google Assistant 的标语「Your own personal Google」,它和 Google 一样强大的同时更加定制化。Google Assistant 聚合了邮件,日历,浏览器,地图等各路 Google 应用庞大且多元的用户数据并加以运用,实现了 Duplex on the web 的自动化租车,自动化订票,以及懂你的驾驶模式的智能建议。这种将现有数据聚合并运用,正是这次 Google Assistant 的新思路之一。它让「自动化」更智能实用,让原本属于「驾驶界面设计」的问题得到正解,也侧面显示了我们在互联网上留下的数据如果被聚在一起,运用起来后有多大的潜能。
另外,Duplex on the web 和驾驶模式表明:智能助手带来便利的方式可不只是用语音回答用户提出的问题。也可以是减少机械化操作,让界面交互变得更加直接。这一定程度上打破了「智能助手」的刻板印象。它不止会交流,更能解决问题。所以我们可以期待「智能助手」的更多应用场景。
相比 Siri,Alexa 和 Cortana,Google Assistant 已经不止在响应速度上取得领先,让我们共同期待它的下一次更新。
3


没有评论:

发表评论