想设计智能语音产品，你得先学会这3类基础知识

对话是人与人之间交换信息的普遍方式。人可以在交流时通过判别对方的语气、眼神和表情判断对方表达的情感，以及根据自身的语言、文化、经验和能力理解对方所发出的信息，但对于只有0（false）和1（true）的计算机来讲，理解人的对话是一件非常困难的事情，因为计算机不具备以上能力，所以目前的语音交互主要由人来设计。有人觉得语音交互设计就是设计怎么问怎么答，看似很简单也很无聊，但其实语音交互设计涉及系统学、语言学和心理学，因此它比 GUI 的交互设计复杂很多。

要做好一个好的语音交互设计，首先要知道自己的产品主要服务对象是谁？单人还是多人使用？第二，要对你即将使用的语音智能平台非常了解；第三是考虑清楚你设计的产品使用在哪，纯语音音箱还是带屏幕的语音设备？了解完以上三点你才能更好地去设计一款语音产品。考虑到目前市场上 Alexa、Google Assistant、DuerOS、AliGenie 等语音智能平台都有各自的优缺点，以下讲述的语音交互设计将是通用、抽象型的，以及不会针对任意一款语音智能平台进行设计。

一、语音交互相关术语

在设计语言交互之前，我们先了解一下与语音交互相关的术语。

1. 技能（Skill）

技能可以简单理解为一个应用。当用户说「Alexa，我要看新闻」或者说「Alexa，我要在京东上买东西」时，用户将分别打开新闻和京东购物两项技能，而「新闻」和「京东」两个词都属于触发该技能的关键词，也就是打开该应用的入口，后面用户说的话都会优先匹配该项技能里面的意图。由于用户呼喊触发词会加深用户对该品牌的记忆，因此触发词具有很高的商业价值。

「Alexa」是唤醒语音设备的唤醒词，相当于手机的解锁页面，同时也是便捷回到首页的 home 键。目前的语音设备需要被唤醒才能执行相关操作，例如「Alexa，现在几点？」、「Alexa，帮我设置一个闹钟」。这样设计的好处是省电以及保护用户隐私，避免设备长时间录音。

2. 意图（Intent）

意图可以简单理解为某个应用的功能或者流程，主要满足用户的请求或目的。意图是多句表达形式的集合，例如「我要看电影」和「我想看2001年刘德华拍摄的动作电影」都可以属于同一个视频播放的意图。意图要隶属于某项技能，例如「京东，我要买巧克力」这个案例，「我要买巧克力」这个意图是属于京东这个技能的。当用户说「Alexa，我要买巧克力」，如果系统不知道这项意图属于哪个技能时，系统是无法理解并且执行的。但是，有些意图不一定依赖于技能，例如「Alexa，今天深圳天气怎么样」这种意图就可以忽略技能而直接执行，因为它们默认属于系统技能。当语音设备上存在第三方天气技能时，如果用户直接喊「Alexa，今天深圳天气怎么样」，系统还是会直接执行默认的意图。我们做语音交互更多是在设计意图，也就是设计意图要怎么理解以及执行相关操作。

3. 词典（Dictionary）

词典可以理解为某个领域内词汇的集合，是用户与技能交互过程中的一个重要概念。例如「北京」、「广州」、「深圳」都属于「中国城市」这项词典，同时属于「地点」这项范围更大的词典；「下雨」、「台风」、「天晴」都属于「天气」这项词典。有些词语会存在于不同词典中，不同词典的调用也会影响意图的识别。例如「刘德华」、「张学友」、「陈奕迅」都属于「男歌星」这项词典，同时他们也属于「电影男演员」这项词典。当用户说「我要看刘德华电影」的时候，系统更多是匹配到电影男演员的「刘德华」；如果用户说「我想听刘德华的歌」，系统更多是匹配到男歌星词典里的「刘德华」。如果用户说出「打开刘德华」模棱两可的话术时，那么这句话究竟是匹配视频意图还是歌曲意图呢？这时候就需要人为设计相关的策略来匹配意图。

4. 词槽（Slot）

词槽可以理解为一句话中所包含的参数是什么，而槽位是指这句话里有多少个参数，它们直接决定系统能否匹配到正确的意图。举个例子，「今天深圳天气怎么样」这项天气意图可以拆分成「今天」、「深圳」、「天气」、「怎么样」四个词语，那么天气意图就包含了「时间」、「地点」、「触发关键词」、「无义词」四个词槽。词槽和词典是有强关系的，同时词槽和槽位跟语言的语法也是强相关的。例如「声音大一点」这句话里就包括了主语、谓语和状语，如果缺乏主语，那么语音智能平台是不知道哪个东西该「大一点」。在设计前，我们要先了解清楚语音智能平台是否支持词槽状态选择（可选、必选）、是否具备泛化能力以及槽位是否支持通配符。词槽和槽位是设计意图中最重要的环节，它们能直接影响你未来的工作量。

5. 泛化（Generalize）

一个语音智能平台的泛化能力能直接影响系统能否听懂用户在说什么以及设计师的工作量大小，同时也能反映出该平台的人工智能水平到底怎么样。究竟什么是泛化？泛化是指同一个意图有不同表达方式，例如「声音帮我大一点」、「声音大一点」、「声音再大一点点」都属于调节音量的意图，但是表达的差异可能会直接导致槽位的设计失效，从而无法识别出这句话究竟是什么意思。目前所有语音智能平台的泛化能力较弱，需要设计师源源不断地将不同的表达方式写入系统里。词槽和槽位的设计也会影响泛化能力，如果设计不当，设计人员的工作可能会翻好几倍。

6. 通配符（Wildcard Character）

通配符主要用来进行模糊搜索和匹配。当用户查找文字时不知道真正的字符或者懒得输入完整名字时，常常使用通配符来代替字符。通配符在意图设计中非常有用，尤其是数据缺乏导致某些词典数据不全的时候，它能直接简化制作词典的工作量。例如「XXX」为一个通配符，当我为「视频播放」这项意图增加「我想看XXX电影」这项表达后，无论XXX是什么，只要系统命中「看」和「电影」两个关键词，系统都能打开视频应用搜索XXX的电影。但是，通配符对语音交互来说其实是一把双刃剑。假设我们设计了一个「打开XXX」的意图，当用户说「打开电灯」其实是要开启物联网中的电灯设备，而「打开哈利波特」是要观看哈利波特的系列电影或者小说。当我们设计一个「我要看XXX」和「我要看XXX电影」两个意图时，很明显前者包含了后者。通配符用得越多会影响词槽和槽位的设计，导致系统识别意图时不知道如何对众多符合的意图进行排序，所以通配符一定要合理使用。

7. 自动语音识别技术（ASR，Automatic Speech Recognition）

将语音直接转换成文字，有些时候由于语句里某些词可能听不清楚或者出现二义性会导致文字出错。

△ 图源：Ani

二、语音智能平台如何听懂用户说的话

语音交互主要分为两部分，第一部分是「听懂」，第二部分才是与人进行交互。如果连用户说的是什么都听不懂，那么就不用考虑后面的流程了。这就好比如打开的所有网页链接全是404一样，用户使用你的产品会经常感受到挫败感。因此能否「听懂」用户说的话是最能体现语音产品人工智能能力的前提。

决定你的产品是否能听懂用户说的大部分内容，主要由语音智能平台决定，我们在做产品设计前需要先了解清楚语音智能平台的以下六个方面：

当前使用的语音智能平台 NLU（Natural Language Understanding，自然语言理解）能力如何，尤其是否具备较好的泛化能力。NLU 是每个语音智能平台的核心。

了解系统的意图匹配规则是完全匹配还是模糊匹配？以声音调整作为例子。假设声音调整这个意图由「操作对象」、「调整」和「状态」三个词槽决定，「声音提高一点」这句话里的「声音」、「提高」和「一点」分别对应「操作对象」、「调整」和「状态」三个词槽。如果这时候用户说「请帮我声音提高一点」，这时候因为增加了「请帮我」三个字导致意图匹配不了，那么该系统的意图匹配规则是完全匹配，如果能匹配成功说明意图匹配规则支持模糊匹配。只支持词槽完全匹配的语音智能平台几乎没有任何泛化能力，这时候设计师需要考虑通过构建词典、词槽和槽位的方式实现意图泛化，这非常考验设计师的语言理解水平、逻辑能力以及对整体词典、词槽、槽位的全局设计能力，我们可以认为这项任务极其艰巨。如果语音智能平台支持词槽模糊匹配，说明系统采用了识别关键词的做法，以刚刚的「请帮我声音提高一点」作为例子，系统能识别出「声音提高一点」分别属于「操作对象」、「调整」和「状态」三个词槽，然后匹配对应的意图，而其他文字「请帮我」或者「请帮帮我吧」将会被忽略。模糊匹配能力对意图的泛化能力有明显的提升，能极大减少设计师的工作量，因为我们尽可能选择具备模糊匹配能力的语音智能平台。

当前使用的语音智能平台对语言的支持程度如何。每种语言都有自己的语法和特点，这导致了目前的 NLU 不能很好地支持各种语言，例如 Alexa、Google Assistant 和 Siri 都在深耕英语英文的识别和理解，但对汉语中文的理解会相对差很多，而国内的 DuerOS、AliGenie 等语音智能平台则相反。

有些词典我们很难通过手动的方式收集完整，例如具有时效性的名人词典还有热词词典。如果收集不完整最终结果就是系统很有可能不知道你说的语句是什么意思。这时候我们需要官方提供的系统词典，它能直接帮助我们减轻大量的工作。系统词典一般是对一些通用领域的词汇进行整理的词典，例如城市词典、计量单位词典、数字词典、名人词典还有音乐词典等等。因此我们需要了解当前使用的语音智能平台的系统词典数量是否够多，每个词典拥有的词汇量是否齐全。

了解清楚语音智能平台是否支持客户端和服务端自定义参数的传输，这一项非常重要，尤其是对带屏幕的语音设备来说。我们做设计最注重的是用户在哪个场景下做了什么，简单点就是 5W1H，What（什么事情）、Where（什么地点）、When（什么时候）、Who（用户是谁）、Why（原因）和 How（如何），这些都可以理解为场景化的多个参数。据我了解，有些语音智能平台在将语音转换为文字时是不支持传输自定义参数的，这可能会导致你在设计时只能考虑多轮对话中的上下文，无法结合用户的地理位置、时间等参数进行设计。为什么说自定义参数对带屏语音设备非常重要？因为用户有可能说完一句话就直接操作屏幕，然后继续语音对话，如果语音设备不知道用户在屏幕上进行什么样的操作，可以认为语音智能平台是不知道用户整个使用流程是怎么样的。在不同场景下，用户说的话都可能会有不同的意图，例如用户在爱奇艺里说「周杰伦」，是想看与周杰伦相关的视频；如果在 QQ音乐里说「周杰伦」，用户是想听周杰伦唱的歌曲。因此，Where 除了是用户在哪座城市，还有就是用户目前在哪个应用里。

当前使用的语音智能平台是否支持意图的自定义排序。其实，意图匹配并不是只匹配到一条意图，它很有可能匹配到多个意图，只是每个意图都有不同的匹配概率，最后系统只会召回概率最大的意图。在第五点已提到，在不同场景下用户说的语句可能会有不同的意图，所以意图应该根据当前场景进行匹配，而不只是根据词槽来识别。因此语音智能平台支持意图的自定义排序非常重要，它能根据特定参数匹配某些低概率的意图，实现场景化的理解。当然，只有在第五点可实现的情况下，意图自定义排序才有意义。

当前使用的语音智能平台是否支持声纹识别。一台语音设备很有可能被多个人使用，而声纹识别可以区分当前正在使用设备的用户到底是谁，有助于针对不同用户给出个性化的回答。

△ 图源：Ani

三、设计「能听懂用户说什么」的智能语音产品

当我们对整个语音智能平台有较深入的理解后，我们开始设计一套「能听懂用户说什么」的智能语音产品。为了让大家对语音交互设计有深入浅出的理解，以下内容将是为带屏设备设计一款智能语音系统，使用的语音智能平台不具备泛化能力，但是它可以自定义参数传输和意图自定义排序。以下内容分为系统全局设计和意图设计。

全局设计主要分为以下步骤：

如果跟我们对话的「人」性格和风格经常变化，那么我们可能会觉得这「人」可能有点问题，所以我们要对产品赋予一个固定的人物形象。首先，我们需要明确我们的用户群体是谁？再根据我们用户群体的画像设计一个虚拟角色，并对这个角色进行画像描述，包括性别、年龄、性格、爱好等等，还有采用哪种音色，如果还要在屏幕上显示虚拟角色，那么我们要考虑设计整套虚拟角色的形象和动作。完整的案例我们可以参考微软小冰，微软把小冰定义成一位话唠的17岁高中女生，并且为小冰赋予了年轻女性的音色以及一整套少女形象。

考虑我们的产品目的是什么，将会为用户提供哪些技能（应用），这些技能的目的是什么？用户为什么要使用它？用户通过技能能做什么和不能做什么？用户可以用哪些方式调用该技能？还有我们的产品将会深耕哪个垂直领域，智能家居控制？音乐？视频？体育？信息查询？闲聊？由于有些意图是通用而且用户经常用到的，例如「打开XXX」这个意图，「打开电灯」属于智能家居控制意图，而「打开QQ音乐」属于设备内控制意图，「打开哈利波特」有可能属于电子书或者视频意图，所以每个领域都会有意图重叠，因此我们要对自己提供的技能进行先后排序，哪些是最重要的，哪些是次要的。在这里我建议把信息查询和闲聊最好放在排序的最后面，理由请看第三点。

建立合适的兜底策略。兜底方案是指语音完全匹配不上意图时提供的最后解决方案，可以这样认为：当智能语音平台技术不成熟，自己设计的语音技能较少，整个产品基本听不懂人在说什么的时候，兜底策略是整套语音交互设计中最重要的设计。兜底方案主要有以下三种：

A. 以多种形式告知用户系统暂时无法理解用户的意思，例如「抱歉，目前还不能理解你的意思」、「我还在学习该技能中」等等。这种做法参考了人类交流过程中多变的表达方式，使整个对话不会那么无聊生硬。这种兜底策略成本是最低的，并且需要结合虚拟角色一起考虑。如果这种兜底方案出现的频率过高，用户很有可能觉得你的产品什么都不懂，很不智能。

B. 将听不懂的语句传给第三方搜索功能。基本上很多问题都能在搜索网站上找到答案，只是答案过多导致用户的操作成本有点高。为了有个更好的体验，我建议产品提供百科、视频、音乐等多种搜索入口。以「我想看哈利波特的视频」这句话为例子，我们可以通过正则表达式的技术手段技能挖掘出「视频」一词，同时将「我想看」、「的」词语过滤掉，最后获取「哈利波特」一词，直接放到视频搜索里，有效降低用户的操作步骤。这种兜底策略能简单有效地解决大部分常用的查询说法，但用在指令意图上会非常怪，例如「打开客厅的灯」结果跳去了百度进行搜索，这时候会让用户觉得你的产品非常傻；还有，如果在设计整个兜底策略时没有全局考虑清楚，很有可能导致截取出来的关键词有问题，导致用户觉得很难理解。

C. 将听不懂的语句传给第三方闲聊机器人。有些积累较深的第三方闲聊机器人说不定能理解用户问的是什么，而且提供多轮对话的闲聊机器人可以使整个产品看起来「人性化」一点。由于闲聊机器人本身就有自己的角色定位，所以这种兜底策略一定要结合虚拟角色并行考虑。而且第三方闲聊机器人需要第三方 API 支持，是三个兜底策略中成本最高的，但效果也有可能是最好的。

由于是听不懂才需要兜底策略，所以以上三种兜底方案是互斥的。为了让整个产品有更好的体验，我们不能完全依赖最后的兜底策略，还是需要设计更多技能和意图匹配更多的用户需求。人与机器的对话可以概括为发送指令、信息查询和闲聊三种形式，以上三种兜底方案在实际应用时都会有所优缺点，设计师可以根据实际需求选择最合适产品的兜底策略。

查看语音智能平台是否提供了与技能相关的垂直领域官方词典，如果没有就需要考虑手动建立自己的词典。手动建立的词典质量决定了你的意图识别准确率，因此建立词典时需要注意以下几点：

• 词汇的覆盖面决定了词典质量，所以词汇量是越多越好。
• 该词典是否需要考虑动态更新，例如名人、视频、音乐等词典都应该支持动态更新。
• 该词汇是否有同义词，例如医院、学校等词汇都应该考虑其他的常用叫法。
• 如果想精益求精，还需要考虑词汇是否是多音字，还有是否有常见的错误叫法。有时 ASR（Automatic Speech Recognition，自动语音识别）会将语音识别错误，因此还需要考虑是否需要手动纠正错误。

在场景的帮助下，我们可以更好地理解用户的意图。由于我们的大部分设备都是使用开源的安卓系统，而且语音应用和其他应用都相互独立，信息几乎不能传输，所以我们可以通过安卓官方的 API 获取栈顶应用信息了解用户当前处于哪个应用。如果用户当前使用的应用是由我们设计开发的，我们就可以将用户的一系列操作流程以及相关参数传输给服务器进行分析，这样有助于我们更好地判断用户的想法是什么，并前置最相关的意图。

撰写脚本就像电影或戏剧里一样，它是确定对话如何互动的好方法。可以使用脚本来帮助确认你可能没考虑到的情况。撰写脚本需要考虑以下几点：

• 保持互动简短，避免重复的短语。
• 写出人们是如何交谈的，而不是如何阅读和写作的。
• 当用户需要提供信息给出相应的指示。
• 不要假设用户知道该做什么。
• 问问题时一次只问一个信息。
• 让用户做选择时，一次提供不超过三个选择。
• 学会使用话轮转换（Turn-taking）。话轮转换是一个不是特别明显但是很重要的谈话工具，它涉及了对话中我们习以为常的微妙信号。 人们利用这些信号保持对话的往复过程。缺少有效的轮回，可能会出现谈话的双方同时说话、或者对话内容不同步并且难以被理解的情况。
• 对话中的所有元素应该可以绑定一起成为简单的一句话，这些元素将是我们意图设计中最重要的参数，因此我们要留意对话中的线索。

最后我们要将脚本转化为决策树。决策树跟我们理解的信息架构非常相似，也是整个技能、意图、对话流程设计的关键。这时候我们可以通过决策树发现我们整个技能设计是否有逻辑不严密的地方，从而优化我们整个设计。

以上是全局设计的相关内容，以下开始讲述意图设计。意图设计主要包括以下内容：

在前面提到，意图识别是由词槽（参数）和槽位（参数数量）决定的。当一个意图的槽位越多，它的能力还有复用程度就越高；但是槽位越多也会导致整个意图变得更复杂，出错的概率就会越高，所以意图设计并不是槽位越多就越好，最终还是要根据实际情况而决定。当我们设计词槽和槽位时，请结合当前语言的语法和词性一起考虑，例如每一句话需要考虑主谓宾结构，还有各种的名词、动词、副词、量词和形容词。

当语音智能平台泛化能力较弱时，我们可以考虑手动提升整体的泛化能力。主要的做法是将常用的表达方式抽离出来成为独立的词典，然后每个意图都匹配该词典。

如果设计的是系统产品，我们应该考虑全局意图的设计。例如像带屏智能音箱、投影仪都是有实体按键的，我们可以考虑通过语音命令的方式模拟按键操作从而达到全局操作，例如「上一条」、「下一个」、「打开xxx」这些语音命令在很多应用内都能用到。

以下通过简单的案例学习一下整个意图是怎么设计的，我们先从「开启关闭设备」意图入手：

首先我们设计「执行词典」和「设备词典」，词典如下：

设计「执行设备」的词槽为「执行」+「设备」。无论用户说「开灯」或者「打开光管」时都能顺利匹配到「Turn_on」+「Light」；而用户说「关掉彩电」或者「关电视」都能顺利匹配到「Turn_off」+「Television」，从而执行不同的命令。

为了增加泛化能力，我们需要设计一个「语气词典」，词典如下：

增加意图槽位。这时候把「执行」和「设备」两个槽位设置为必选槽位，意思是这句话这两个词槽缺一不可，如果缺少其中之一需要多轮对话询问，或者系统直接无法识别。接着增加两个可选槽位，同时为「语气」，可选槽位的意思是这句话可以不需要这个词都能顺利识别。这时候用户说「请开灯」、「能不能帮我开灯」都能顺利匹配到「Please」+「Turn_on」+「Light」以及「Please」+「Turn_on」+「Light」+「Suffix」，由于「Please」和「Suffix」都属于「语气」可选词槽的内容，所以两句话最后识别都是「Turn_on」+「Light」。通过参数相乘的方式，我们可以将整个「开启关闭设备」意图分别执行4种命令，并泛化数十种常用表达出来。

刚刚也提到，对轮对话的目的是为了补全意图中全部必选词槽的内容。当用户家里存在数盏灯时，系统应该将刚才的常用表达升级为「Please」+「Turn_on」+「Which」+「Light」+「Suffix」。当用户说「打开灯」的时候，系统应该询问「您需要打开的哪一盏灯」，再根据用户的反馈结果执行相关命令。

以上的案例只是整个意图设计中的一小部分，还有很多细节需要根据实际情况进行设计。完成整个全局设计和意图设计后，我们应该邀请用户进行实践与测试，这时候们很有可能发现用户会用我们没想到的话术进行语音交互，我们要尽可能地完善意图以及对话设计，避免产品上线后出现问题。最后，关于创建用户故事、撰写脚本和对话流程设计，请阅读 Google 的《Actions on Google Design》和Amazon的《Amazon Alexa Voice Design Guide》两份文档以及相关的语音智能平台的官方使用文档，里面会更详细地介绍相关细节。

欢迎关注作者的微信公众号：「薛志荣」

图片素材作者：Hooman Hatefi

「如何设计出优秀的语音交互」

• 《语音交互智能产品该如何做设计？这篇可能是最全面的总结了！》
• 《阿里设计师：语音交互设计的流程及方法全面总结》
• 《语音交互设计中，如何创建角色画像？》