语音交互:如何设计一个语音技能?

4 评论 1431 浏览 8 收藏 22 分钟

编辑导语:随着科技的快速发展,如今我们的生活越来越便捷,很多时候通过说话便有机器代替我们去完成一些事情,这便是语音技能带给我们的好处。日常生活中,语音技能仿佛无处不在,小到手机、智能音箱,大到机器人,那么,语音已经应该如何设计出来呢?

随着语音交互的普及,我们首先用到的最多的就是语音技能,比如:我们让智能音箱唱歌、查天气、讲笑话等,这些都是语音技能。今天,我们就来聊聊如何从零到一的设计一个语音技能。

1. 基础信息介绍

在设计语音技能之前,我们首先要掌握技能用到的一些基础定义,每家公司可能叫法上面会有区别,但是都大同小异。

1.1 基础定义

我们在聊聊语音技能常见的一些名词和定义,主要有领域(domain)、意图(intent)和槽位(slot),这些都是语音技能必不可少的一些参数内容。

1.1.1 领域

听到这个词,我们就感觉到了约束性,其实领域这个词就是约束语音技能范围的意思。一般一个语音技能,会有一个明确的领域,剩下的内容都在这个领域里面做处理。

1.1.2 意图

顾名思义就是判断用户具体要做什么的意思,领域可以是一个大范围的事情,而意图是领域中的一个小分类。

比如:让机器人跳舞是一个领域的事情,那么“开始跳舞”和“停止跳舞”就是领域下的意图的事情。意图一般会非常明确,会有明确的边界,在自然语言处理中属于封闭域的问题。

1.1.3 槽位

根据槽位的有无,语音技能可以分为有槽位的和没有槽位的。槽位一般就是指我们前面说到的实体词,用来做信息抽取用的,补全和完善用户的意图。

比如:“唱首歌”就是没有槽位的语音技能,只需要知道是唱歌的意图就可以;而查天气是常用的有槽位的语音技能,除了识别出这是一个查天气的意图之外,机器人还要知道要查什么时间、什么地点的天气,时间和地点在这里就是槽位信息。

有槽位信息的一般还会有默认槽位,就是没有槽位信息的时候,直接使用默认的槽位信息,从而保证语音技能的正常。常见的就是“天气预报”,默认的就是当地当天的天气。

1.2 底层逻辑

再聊聊一下目前语音技能的底层逻辑,基于什么能力实现的。

目前大部分做语音技能的公司,都是用正则表达式来写的,就是基于一些文本规则,作为约束条件,筛选出来明确的意图。抽取的槽位也是基于规则,或者穷举的方式。

这样做的好处是改动方便,以及改动后的影响好评估,而且冷启动非常方便,甚至可以做到每天迭代;缺点也同样明确,泛化能力弱,没有学习能力。

也有一小部分公司已经开始使用算法做语音技能了。

语音技能本质是一个意图识别的事情,而意图识别实际上又是一个分类问题,有基于传统机器学习的SVM,基于深度学习的CNN、LSTM、RCNN、C-LSTM等。

槽位识别实际上是一种序列标记的任务,有基于传统机器学习的DBN、SVM,也有基于深度学习的LSTM、Bi-RNN等。用算法做的优点就是泛化能力强,有一定的学习能力;缺点就是成本高,适合复杂技能后期迭代的方向。

正则表达式- HELAY新鲜事

2. 语音技能的定义

在开始动手做语音技能的之前,要先对语音技能进行定义,知道技能的边界,要有明确的反馈逻辑在里面。我们这里用“查天气”这个烂大街,也是最典型的技能来举例子。

2.1 定义技能

我们要明白为什么做“查天气”这个技能,以及要做到多细。

原因可能是我们就觉得这个技能很基础,用户都被教育过了,必须要有;也可能是我们看用户的交互日志,发现每天都有很多人有这个意图,现在是未满足状态,值得单拿出来作为一个技能。

还可能是老板觉得竞争对手有了,我们也要做。

假设我们是觉得是技能很基础,必须要做。接下来我们就要考虑怎么定义这个技能,需要注意以下几点:

2.1.1 要明确技能的边界,就是那些query是该技能要识别的,需要有一个明确的定义

这个看起来很容易,其实执行起来会很纠结,因为自然语言本身就有一定的歧异性。

就拿“查天气”举例子,比如:“今天该穿什么?”、“明天能不能出去玩”算不算查天气的意图,都是要明确的。其实最让你纠结的往往是模糊的语义,算作技能也不为错,不算吧,又觉得用户可能有这个意思。

所以明确的边界的时候,有三种处理逻辑:

2.1.1.1 只处理特别明确的意图,不care模糊的语义

比如:只处理“明天天气”、“查一下天气”等这样的

2.1.1.2 模糊的意图也一起处理,都归为该技能

比如:“明天该穿秋裤吗?”也属于该意图,和“明天天气”一起处理

2.1.1.3 还有一种精细化的处理,把明确的意图和模糊的意图分开处理

比如:可以让明确意图直接执行,模糊意图选择反问,用户确认后执行。用户一旦确认后,以后这句话就归位了明确意图。

比如:用户问“今天穿什么出去好呢?”,计算机回答“您是不是想查询今天的天气?”,用户回答“是的”,计算机回答“今天北京气温20度,适合……”;然后下次用户问“今天穿什么出去好呢”,计算机就可以回答“今天北京气温20度,适合……”,反之亦然。

当然如果模糊问的问法比较多,可以专门做意图优化。

2.1.2 明确技能的领域、意图和槽位的信息

就拿“查天气”这个技能为例,领域我们一般设置为“weather”,但是意图定义就会有两种方案:

一种是简单的,只有一个意图,比如意图也是“weather”;还有一种是精细化的处理,有若干饿意图,比如“北京空气质量?”算是“get_haze”,“今天会下雨吗?”算是“get_rain”等,就是每个不一样的问法,对应不同的意图。

本质上越精细化的技能,给用户的体验会越好。


2.1.3 考虑技能内多轮的支持,以及支持的效果

由于自然语言先天是具有多轮属性的,很多时候需要借助上轮的信息,才能理解这句话,在做语音技能的时候,也要考虑到这方面的可能。

比如:用户先说“明天天气”,紧接着,用户又说“后天呢?”,这个时候是否考虑支持,都需要在定义技能的时候明确。像用户隔多久的多轮需要支持,支持的逻辑,我们这里就不展开了。

定义好了技能,就知道了这个技能能干什么,方便后面的测试同学测试,也知道未来要迭代的方向。一般如果没有数据支撑的话,建议先做最基础的就可以,边界越小越好。

2.2 触发技能反馈

反馈这块一方面依赖于产品底层的设计;另一方面依赖于产品形态,按照有无屏幕,可以简单的分为两种产品形态:有屏幕和没有屏幕。这两方面结合,才能设计出一个人性化的体验。

产品的底层设计要考虑意图要不要细化,比如:“今天有雾霾吗?”和“今天天气怎么样?”这两种问法有没有必要分开处理,设置不一样的回复内容。

还要考虑如果槽位超出技能的边界怎么处理,比如:“三年后的天气预报”,这个时候我们需要怎么反馈,都是需要在语音技能定义的时候写清楚。

具体怎么展示以及怎么回复,就要依赖于产品形态考虑。

有屏幕的可能更多的信息会通过屏幕展示,语音只是做到一个提醒的效果,有些场景甚至都不需要语音,而没有屏幕的就要考虑语音播报的表达方式,要注意文字的长度,都播报那些内容,播报的先后顺序,甚至播报的句式的丰富度都要考虑。

技能的反馈,是用户直接能够感受到的,其重要心怎么强调都不为过,这块可以参考语音交互的设计规则。

3. 数据的准备

前面说到的都是产品设计的时候要考虑到的问题,如果你把技能已经设计的差不多的时候,就可以准备这个意图的训练和测试数据,因为我们最终语音技能的开发是基于数据的,数据覆盖的越全面,技能的效果越好。

无论训练数据还是测试数据,简单可以把数据分为两部分,正例和反例。

3.1 正例数据

正例数据指的是正常的触发文本,就是你设计的触发query,像“明天天气怎么样”、“天气预报”、“查询天气预报”等,这些都是我们定义的“查天气”的意图。

一般在准备正例的数据时,最关心的是数据的来源,还有数据的丰富性。

如果是冷启动的话,建议团队内部,或者有专门的数据部门,进行人肉泛化,就是每个人自己写几条符合意图的触发query。

这里亚马逊在做智能音箱的时候有一个要求,就是每个意图的正例训练集的数据,不能少于30条(测试数据也一样)。数据来源就是公司员工制造,数据丰富性就是依靠数据量标准约束。

如果是语音能力已经有了,每天都有大量的交互数据,我们就可以从真实的交互中拿数据。导出交互日志需要逐一标注,从中找到属于该意图的数据。

这些数据的好处就是更加贴近用户真实的情况,缺点就是成本会比较高,但一般都是可控的。

基于现有的交互数据标注,可以轻轻松松准备30该意图的数据,建议越多越好,100条以上为最佳。数据来源就是用户的交互,数据丰富性是依靠用户的。

3.2 反例数据

反例数据指的是非该意图的数据,就是除了正例数据,理论上所有的数据都是反例数据。像“明天要是不下雨就好了”、“我知道现在在下雨”、“我不想查天气预报”等,这些都不是我们定义的“查天气”的意图。

很多时候,我们做语音技能的时候,是很容易忽略反例数据的。

反例数据最好是能够有意图相关的关键词,数据量最好可以和正例数据一样多。在准备反例数据的时候,要注意一些意图相反的操作,比如:“我不想查天气预报”,这是比较典型的反例数据。

往往反例数据比正例数据要难收集,尤其是高质量的反例数据,一般交互日志是最好的资源。

正例数据可以保证准确率,而反例数据可以减少误召回,提高召回率。

4. 语音技能的实现

训练数据准备好之后,就是技能的实现了,这块需要工程师的支持。有些公司是工程师直接写语音技能的逻辑,有些公司是会提供一个平台,通过培训,让产品经理和运营同学也可以写。

这里就会用到一些基础能力,当一句query传过来,首先会使用中文分词对这句话进行分词。

比如:“北京明天天气怎么样”,会被分为“北京”、“明天”、“天气”、“怎么样”,然后就是命名实体识别;比如:“北京”就是地点实体,“明天”就是时间实体,对应的就是语音技能的槽位。

最后就是匹配我们写的正则表达式,这里就不过多赘述,感兴趣的同学可以搜搜看。

中文分词:为什么叫中文分词呢?因为英文是以词为单位的,词和词之间是依靠空格和标点隔开的,而中文是以字为单位的,一句话的所有字是连在一起的。

所以就需要算法把一句话切分成有意义的词,这就是中文分词,也叫切词,主要为了NLU后面处理做准备。了解锤子手机的人可能知道上面有一个叫做“大爆炸”的功能,就是基于该算法的。

这是NLU最底层的能力,一般都是用的开源的算法,大家能力相差不大,基本可以保证准确率在90%以上。

命名实体识别:词性标注是把每个词的词性标注出来,而命名实体识别是指识别文本中具有特定意义的实体,包括人名、地名、时间等。

一般来说,命名实体识别的任务就是识别出待处理文本中三大类(实体类、时间类和数字类)、七小类(人名、机构名、地名、时间、日期、货币和百分比)命名实体。

这个一般会根据本身业务的需求进行调整,不做明确的限制。

还有比较简单的实现方式,就是通过穷举实体+写正则的方式,而不需要用到模型去做处理。

比如:“查天气”这个技能,我们通过穷举的方式,把表达地点和时间的词语都穷举出来,然后分别存到词典里面。最后使用这两个词典写一些正则表达式,用来覆盖我们准备的训练集。

这样做的的前提需要是实体词是可以穷举的,否者就会遇到召回率很低的问题。除了实现方法,我们还要考虑实现过程的效率,以及实现效果怎么样。

5. 测试验收效果

一般的语音技能开发会比较快,开发完成之后就是验收了,验收最关心的指标是精准率和召回率。

5.1 验收指标介绍

本质上就是计算机判断了一次,然后人工判断了一次,默认以人工判断的为真实标签,计算机判断的为预测标签,如下表:

5.1.1 精准率(Precision)

计算机认为对的数据中,有多少判断对了。

精准率表示的是预测正例的样本中有多少是真正类,预测为正例有两种可能,一种就是真正类(TP),另一种就是假正类(FP),公式表示如下:

5.1.2 召回率(Recall)

的样本中,有多少被计算机找出来了。

召回率表示的是样本中的正例有多少被预测正确了。也只有两种可能:一种是真正类(TP),另一种就是假反类(FN),公式表示如下:

其实就是分母不同,一个分母是预测标签的正例数,另一个真实标签的正例数。一般情况这两个指标都会在0-1之间,越趋近于1,语音技能的效果越好。

5.2 验收步骤

验收这里分为两个步骤:一个NLU批量验证;一个是端到端验证,都可以用测试集来验证。

NLU批量验证就是把测试集的query,全部通过语音技能的逻辑跑一边,一般用来验证技能在NLU上面的效果。通常这一步只会测试新增的技能,单独测试这个技能的效果,主要关心的是精准率和召回率,这一步理论上来说,必须这两个指标都要达到95以上。

端到端验证是模拟用户正常使用,需要把技能放在整个语音链路上面,来观察语音技能在实际情况中的表现。

通常这一步才会发现一些问题,比如:语音技能之间的冲突,甚至会发现ASR识别不对的情况。这一步主要关心响应时间、语音技能是否正常等情况。

测试一定要把好最后一道关卡,保证语音技能的精准率和召回率,同时也要测试技能之间优先级的关系,是否技能之间会出现优先级的问题。如果有多轮的语音技能,也要测试多轮的效果。

6. 总结

做一个语音技能,产品首先要有一个明确的定义,其次就是基于产品定义准备训练集和测试集,然后基于训练集完成技能的开发,最后使用测试集进行验证。

 

本文由 @我叫人人 原创发布于人人都是产品经理。未经许可,禁止转载

题图来自Unsplash,基于CC0协议。

给作者打赏,鼓励TA抓紧创作!
更多精彩内容,请关注人人都是产品经理微信公众号或下载App
评论
评论请登录
  1. 你是那家单位的?讯飞,百度,or其他?

    回复
    1. 其他,哈哈哈

      回复
  2. 点赞!!!

    回复
    1. 谢谢

      回复