HI,下午好,欢迎来到微信公众号转让!
24小时服务热线: 4000-163-301
请扫码咨询

新闻动态

NEWS CENTER

如何评测语音助手的智能程度(1):意图理解

2020-03-11

从事AI-NLP领域已经一年半了,一直潜心学习。

平日里研究各种各样的语音助手,输出各种类型的调研分析报告,以培养自己的业务敏锐度,同时也研究各种框架型知识以丰富自己的知识库。

在仔细、反复研读完了《Google对话式交互规范指南》、《阿里语音交互设计指南》、《亚马逊语音交互设计规范》三大交互规范后,累积过往的工作过程中所遇见的问题,自己努力尝试着提炼出一个知识框架,并期望把这些规范类的东西,内化成为自己的被动技能,继而为自己以后做出更好用的产品做出积累。

一、我心中的超级人工智能

私以为,最理想的人工智能,就像:

  • 《Her》里面的萨曼莎;
  • 《钢铁侠》里面的贾维斯;
  • 《超能陆战队》里面的大白;
  • 《多啦A梦》里面的机器猫;

这些超级英雄总能解决我们生活中的各种各样的问题。

虽然我们的世界距离这种超级人工智能还非常遥远,也许永远达不到,但是不妨以一种非常高的标准对AI去做出苛求,继而去倒逼自己做出更好的产品。

文章开始前,请先短暂忘记自己是AI从业者这个身份,让我们变成一个小白用户,尽管提要求吧。

简单而言就是一句话——我就想要一个聪明且好用的智能助理,能够满足我生活中的各种需求。

“好用”如何定义?“各种需求”如何满足?难就难在没有边界。

真正意义能符合上面要求的是,可以无限许愿的神灯。

所以我们干脆模块化一些,笔者就智能语音助理这一产品有如下四个大的评判维度,它们依次是【意图理解】、【服务提供】、【交互流畅】、【人格特质】。


亦或者是说,这些指标如果能够得到全部满足,距离我们想要的超级人工智能也就不远了。谁能够提供,谁就可以获得用户的亲睐。

每个评判维度还有对应的细分指标,让我们一步步拆解。

二、【意图理解】维度的5个指标

本文重点定义和讨论第一大模块【意图理解】,即是否能够理解/识别用户表述的意图。

私以为,这个模块是衡量AI智能与否的核心维度。

(1)中控分配意图能力

当前市面上的AI智能助手,往往包含着各种各样的能力。

从业者角度而言,本质是各个技能的集合,而每一项能力都是服务和满足特定领域类的需求,比如听音乐,导航,事项提醒,电影票,机票,火车票什么的。

很多的技能在固定域里面能够表现得非常好,但是集中到一起,表现就未必好了。

核心考量点:准确识别用户需求,并分配到指定技能服务的能力。

用户提出的每个需求,计算机都会做出反馈(文本、语音、图片、功能卡片、多媒体事件等等)。


在反馈之前,是先要做到识别并理解,然后成功分配到指定的技能上,最后由指定的技能完成反馈,即服务行为。

而人类的语言表达千奇百怪,我们期望计算机自然能够通过人的自然表达,成功理解人类的意图,并使用对应的回复衔接业务。

例子:

  • “我想听我想去拉萨”>>>意图应该分配给音乐,然后由【音乐】完成反馈。
  • “我想去拉萨”>>>意图分配导航,然后由【导航】完成反馈。

例子:

  • “提醒我一下我明天帮女朋友买一束花花”>>>意图可以分配给【事项提醒】技能
  • “我想明天帮女朋友订一张到上海的火车票,你早上8点半提醒我下抢票”>>>意图如果分配给【订火车票】技能就错了

这个就是中控分配意图的能力。也是所有AI智能助手,集合各项能力的一个核心能力。做不好中控的意图识别,智能化无从谈起。

市面上,例如腾讯叮当、小爱同学,小度助手这类大生态的集合的处理方案,属于最大的开放域,相当多的技能只能是采用命令词跳转的方式启动,这种对话行动无疑是要等待,而且对话流程冗长,面对着输入的不确定性,所以用户为什么不用GUI(图形交互界面)去完成目标呢。

而一些细分领域的,比如说出行、餐饮、客服、游戏领域的智能助手,这些相对的封闭固定的领域,还用关键词的方式进入指定技能再寻求服务,就显得非常笨了。

如果做不到全开放域的中控,至少也得在固定域里面做好意图需求识别以及分配的能力,这样方便发挥语音输出便捷直达目标的能力,才不至于像个玩具。

(2)句式/话术/词槽泛化度

用大白话来讲:同一个意思,当用户采用不同的表达的时候,AI是否能够正确理解

业内的专业说法是“可识别话术/词槽的泛化程度”。解决方案是“增加更多的语义覆盖”。

泛化有两种,一种是句式,另一种是词槽。

先说句式的例子:

笔者经常观察用户的对话日志后台,发现用户在播放音乐的时候,表述各种各样。

“我想听音乐>>>随便放首歌>>>音乐响起来>>>music走起>>>”

有些能够能理解,【音乐】正确回复随机歌单,有些话术的表述无法理解则被【兜底】给接走了,这种反馈就是助手的失误了。

列举词槽例子:

  • “我想吃711/想吃七十一”/想吃seven eleven/想吃关东煮/想吃好炖>>>
  • 我想吃肯德基/想吃KFC/“想吃开封菜”>>>

笔者的所开发的智能助手有一个【电影票】技能,观察用户对话日志时的一些发现:

  • 《速度与激情8》刚刚上映,用户会表述是“我想看速度与激情、速激、速8等等;
  • 《魔童哪咤》上映的时候,用户的表述是我想看哪咤的电影;
  • 《叶问3》上映的时候,用户的表述会是,叶问。甚至是“甄子丹的那个电影”;

而AI先提取对应的影片名,然后交给接口方去完成查询行为,只有正确填充“指定电影的全称”才能够可查询成功,所以此处就需要做映射关系的特殊处理。

在定电影票例子中,是十分考虑场景和时效性,也就是说,用户在不同的时间点,说我要看《某》系列电影的时候,口语上大概率是绝对不会带上第几部的。

这些要求其实都是生活中的一些例子,既然人类可以做到理解,自然AI也理所应当做得更好。

作为从业者,一定要多看自己的公司业务的对话日志后台,观察用户在对话过程中,究竟是如何去使用我们的产品,这个是我们的迭代产品的重要依据,随时根据用户实际使用情况,做出完善。

就过往的泛化经验而言,结构性的句子变化相对较小,而词语的变化就很多,像分析数据一样经常看用户的对话日志,会有很多的积累。

比如阿里巴巴的天猫精灵是具备线上语音购物的能力的,那么眼下的2020春节,相当多的用户会在我想买口罩这种话术之外,直接表述,我想买3M的口罩甚至会直接问有没有N95卖——毕竟在眼下的这个语境,N95几乎就是口罩的代名词了。

如果这类没有覆盖,那你也只能通过版本迭代去训练,各位AI从业者基于自家产品的版本迭代效率,思考一下差距。

所以“一开始就做好”相比“通过各种渠道反馈发现不好,然后通过迭代去做好”,从产品设计基本功上来看,根本是两种境界。

所以解决方案是,此处应该是有一个动态热词的词库,产品设计和运营方式不展开,不在本篇讨论范围内。

在实际的业务中,很多词汇和句式会被不断地造出来,至于优先级如何选择,如何泛化覆盖词槽和句式,鉴于文章定位,此处不适合展开。