设计任务导向型对话场景是一项关乎人类最自然的对话和AI最智能的技术结合的复杂而有趣的工作,希望这篇文章对从事语音交互产品设计的同学们有所帮助。 5月10日,微软Build大会发布智能音箱Invoke, 6月6日,苹果WWDC发布HomePod, 7月5日,上午10点,百度AI开发者大会发布DureOS开放平台, 同一天,下午2点,阿里人工智能实验室发布天猫精灵…… 这个夏天,被人工智能骄阳炙烤着的智能语音交互市场,热度可谓一路飙升。 语音交互的主要能力在于开放式domain的聊天型功能与任务导向的技能型功能。如果说快捷高效、轻松自然是语音交互的独特优势,那么任务导向型功能就是这些优势的完美落点,一个量好的语音交互产品,自然是技多不压身,能够cover的domain多越好,能够get的技能越强大越好。 那么,作为语音产品设计人员,如何以短平快的方式设计一个任务导向型对话场景呢? 当然,和传统交互设计工作一样,前期调研是很有必要的。你想设计的这个功能是否能满足产品目标、是否具备相关技术和数据能力支持以及符合用户实际需求?如果有两个场景摆在你设计的智能音箱面前,一个是订外卖,而另一个是星座速配,你会选择优先做哪个? 一旦确定了要设计某个场景,接下来就可以着手设计工作了。具体来说就是三个步骤:理清对话逻辑(Chat Flow)、设计语法(Grammer)以及设计应答 (Confirmation)。 第一步:对话逻辑——从哪里来,到哪里去? 如同图形用户界面以点击-触发为各个节点的交互逻辑,VUI也需要一从query到answer的流转逻辑,将一个场景的对话流程流畅的贯穿起来。 假设你设计的对话场景是查询空气质量,请考虑在这番对话中可能出现的任何情况以及相应的反馈动作: 下图展现了该场景可能的Chat Flow 即便是询问天气这样看上去很简单的对话场景,也可以设计出十分复杂的对话逻辑,根据该场景在你产品中的重要程度决定细节逻辑的粒度。 第二步:设计语法 ——用户会对你说什么? 语法就是用户输入的指令集,对话设计者需要设计对话的意图(Intent),以及尽量考虑用户可能表达方式,将其中最核心、最常用的表达方式提取为指令集模板。设计的指令集越多越全面,对话覆盖率就会越高。 想象场景还是查询空气质量,请考虑用户会用怎样的表达方式来提出自己的要求: "帮我查询空气质量" "北京空气质量指数" "今天PM2.5值是多少" "我需要戴口罩吗" "今天的空气怎么样" …… 中华语言,博大精深,简单的查询空气质量,就有茫茫多的问法。不过不用着急,你只需要提取一些最典型的句式,至于"么""吗""呢"这些语气词,或者虚词、助词等,语义理解模块(NLU)会帮忙泛化。 下图为查询空气质量对话指令集,其中<place>和<time>是槽位(Slot)。Slot是NLU从用户指令中抽取的关键信息点,NUL模块通过这些关键信息及其取值定义(Slot-Value),理解用户指令的具体要求。</time></place> 第三步:设计应答——你要如何回答用户? 语音交互中最主要的应答方式是TTS(Text To Speech),就是将设计者写好的应答脚本,通过TTS引擎转化为语音播放出来。应答带给用户最直观的感受,应答的好坏,直接关系到语音产品的体验。鉴于过长的语音内容会增加用户的记忆负载,设计应答时应该尽量简洁。同时,如果你的语音产品具备自己的个性特点,在应答时也请按照该特点的语言风格撰写脚本,保持角色的一致性。 还是查询空气质量的例子,在第一步,设计对话逻辑的过程中,我们已经定义了该对话可能出现的几类应答。分别是: A1.询问用户想查询哪里的空气质量 A2.反馈没有查到相关地区相关时间的空气质量 A3.根据空气质量级别的优劣反馈相应提示 接下来,你只需要在对话脚本(script)文档里,发挥你强大的语言天赋,进行完型填空就可以了。 "script"有"撰写电影脚本"的含义,而整个设计对话过程确实很像设计电影脚本,有来言有去语,通过问答的互动形式帮助用户完成任务。 综上所述,设计任务导向型对话场景是一项关乎人类最自然的对话和AI最智能的技术结合的复杂而有趣的工作,希望这篇文章对从事语音交互产品设计的同学们有所帮助。