开发者学堂课程【阿里巴巴智能语音交互技术与应用：人机自然交互平台技术及应用】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/376/detail/4712
人机自然交互平台技术及应用
目录：
一、人机自然交互概念
二、人机自然交互平台
三、人机自然交互平台的应用
一、 人机自然交互概念
（1） 人体自然交互的原因
在2013年底至2014年初这段时间内，我们可感知到两个明显的变化和趋势。
一是互联网服务的深入化，是指互联网服务从传统的媒体延展到服务，从线上延展到线下。比如我们可以通过手机完成打车、叫外卖、实现导航等等线下服务。
二是智能设备的快速发展。智能设备从智能手机延展到智能眼镜，互联网汽车，智能电视，智能音箱，机器人等各种各样的智能设备。
但是用户在设备的体验方面并不是很好，这是由这样两个趋势和变化让我们意识到我们需要做到更自然的人机交互体验，让用户在任何情况下更好的体验自然交互，进而享受到互联网的服务。
（2） 人机交互概念
从两个维度来看，一维度是人机交互是否有明确的目标，如果有明确目标则称为面向 task 的对话，比如打车、听歌、导航等等，若没有明确目标，则称为聊天。
从第二维度来看，分为人机交互是机器主动还是用户主动。
在机器主动时，要求用户严格回答机器的问题，但是此时用户体验感并不是很好，另外一个极端是用户发起且掌控对话，此时由于用户语言的随意性及丰富性，让机器理解用户的思想，是对机器的一个巨大挑战，因此在实际的人机对话的产品当中，都是两种极端的这折中。
从逻辑上来讲，
一个完整的人机自然交互主要分为以下模块：
① 语音识别：把用户的语音转换文字
② 自然语言理解：理解用户的意图，且将意图结构化
③ 对话管理：决定执行何种操作
④ 自然语言生成：根据对话管理的结论，生成一句或一段话，且以语音的形式反馈给用户。
（3） 自然语言理解
概念：将人的自然语言形式化为结构化、完整的语义表示。
例：买张下周二去上海的飞机票，国航的
领域/意图分类→domain:flight_ticket
Intent:search_flight_ticket
属性抽取、 →time：下周二
Destination：上海
Airline：国航
“domain”:”flight_ticket”,
“intent”:”search_flight_ticket”,
“slots”:{
“airline”:”国航”
“time”:”下周二”
“destination”:”上海”
此时语言理解判定用户需要买飞机票，并且将具体信息记录下来。例如出发时间是下周二、目的地是上海、航空公司是国航，进而得到以上完整的语义表示。
自然语言理解的挑战
1、口语语言的多样性：同一个目的，不同的用户会有不同的表达方式
2、语言的歧义性：同一句话可以有不同的理解方式
3、口语的鲁棒性：用户口误、多字少字、别称、不连贯、噪音等等，对于机器来说都是挑战。
（4） 对话管理
概念：给定前一步语言理解的结果，以及完整的对话风格，来决定执行何种操作。
Semantic Representation+Context→DM→actions
将执行操作分为三类：
用于指导语言生成
E.g. ask_slot(time)，“请问你什么时候出发？”
用于调用数据服务
E.g. goto_service(train)
用于客户端的执行
E.g. open_app,set_reminder
过去三年在人机自然交互方向的演进分为三个阶段
口语语言理解：
与 OneSearch 合作，打造智能手机的搜索引擎，可以接受用户的语音及自然语言，并且以精准的搜索结果用卡片的形式呈现给用户。
人机对话系统：
实现了一套面向 task 的人机对话系统，具备 cross·domain 的自由对话能力。例如落地在 YUNOS 小云。这样的系统可以让用户和机器进行自然交互，并且收集用户完整的需求，进而得到更精准的结果，并且帮助用户完成任务。
比如订餐、看视频、打车、导航等等。自由对话能力是指用户在完成一个task的过程中会出现领域之间跳转的需求。
自然交互平台（NUI）
二、 人机自然交互平台
（1） 扩展对话领域或多个端
遇到的困难：
比如开发了地图领域，此时想扩展到音乐领域，需要把音乐领域的知识、词典、对话逻辑、与音乐接入的工作等等加入最初的领域。
（2） 设备端的扩展
比如在手机上开发了多个领域之后，如果想运用到电视、音箱的时候，以音乐为例，由于不同的设备物理特性不同，有的有屏幕，有的没有屏幕，物理特性不一样决定了交互过程不一样，以音乐为例，在电视上，当用户发出语言指令想听刘德华的歌时，产品希望在屏幕上展示刘德华的歌单，进而让用户选择，但在音箱这个设备上产品希望可以快速给出刘德华的一首歌让用户可以听到歌曲。
正是由于不同的设备端带来的交互逻辑的不同，让我们意识到人机对话交互和业务方有很紧密的关系。自然交互最好由业务方开发他们自己的场景交互。
（3） 云+端有机协同自然交互平台
端：客户端（手机） 客户端（车机） … 客户端（IOT）
Speech Client SDK NUI Client Service
云：NUI Gateway
GDS
DM+NLUChi-ChatQnAIntenSuggestion ASR&TTS
概念：
在互联网无网的情况下，开车时还能够支持一定能力的对话交互，同时在有网络时还存在着端和服务端返回结果的融合判断机制，因此这是一个云+端有机协同的自然交互平台。
这个平台的能力更多的是在服务端，有强大的语音识别和 TTS，另外有语言理解、对话、聊天、问答、GDS
（1） Open Dialogue
用户自定义新领域和对话流程的解决方案
① 引擎与业务分离
② 基于 grammar 的语言理解引擎
③ 基于 Task Flow 的对话脚本语言和对话引擎
有了这个引擎之后，业务方只需要写语言的语法以及对话逻辑，以及对服务的调用和返回结果分析，进而能快速的打造出业务特有的对话逻辑。
（2） 四个引擎
语言理解引擎
NLU 领域分类——升级为深度学习模型
采用融合知识的深度卷积网络（CNN）
在14个重点领域的测试集合上，相比 SVM 模型有明显提升
基于 B-LSTM 的属性抽取效果提升显著
对话引擎
基于 Task Flow 的对话脚本语言
Q：为什么要对话脚本语言？
A：把对话逻辑与引擎逻辑解耦，我们可提供核心的引擎层，让业务方通过业务脚本语言来描述对话逻辑
降低开发者的门槛，以简单的方式描述对话过程
Q：为什么基于 Task Flow？
A：对话过程的抽象不够全面
DM1.0主要通过 Ontology 来指导信息收集阶段的对话，对完成 task 的后续过程缺少指导性的框架
对任务的边界划分模糊
缺乏任务的“纲领性”描述，没有任务开始和结束的明显标识
对话过程中，并不清楚位于任务的那个阶段
Task Flow 描述了任务的起始、步骤、流转、结束。
实现了 Carry-over 机制。当用户购买火车票时，要先了解天气如何，此时不需要再说一遍目的地，系统可以自动将目的地 carry over 到下一个 domain 中，实现了两个领域中的 carry over 机制。
任务的打断和返回
打断分为两类，一类是主动打断，另一类是被动打断。上一个例子是主动打断，被动打断是指用户说话的随意性，机器无法理解用户的意思，所以自动跳转到其他领域。
问答引擎
主要解决智能客服场景下，引擎收集‹k，v›对上传到平台上，进而通过计算语义相近的办法去解决问答需求。
单轮问答的关键点在 Q-Q 的相似性计算：CNN 模型、DSSM 模型
聊天引擎
① 基于‹k，v›对的聊天引擎，具备让用户定制的能力
② 基于深度学习模型的 seq2seq 聊天引擎
解什么问题
基于‹k，v›对的聊天模块无法对用户的任意 chat 输入都能够给出回复
三、人机自然交互平台技术及应用
（1）人机自然交互平台的公共领域
娱乐：音乐、视频、影院、应用、休闲娱乐
美食：餐厅
出行：地图、导航、实时路况、火车票、飞机票、酒店、天气
理财：股票
（2）人机自然交互平台的基础组件
把基础组件比喻为乐高积木，有不同的颜色、规格模块，业务方根据不同的业务场景和需求，可以拼装出各种各样的产品。
（3）人机自然交互平台的定制能力
①语言理解
业务领域的词典和 grammar
②业务领域的对话过程
对业务服务的调用以及结果处理逻辑
回复的内容
③ 卡片的展示方式
④ ‹Q,A›对
⑤发音的定制
儿童音、男声、女声
（4）人机自然交互平台应用
互联网汽车
我们的 IDST 正在和 us、上汽、斑马网络一起在多方打造互联网汽车的场景下的语音交互
包含的领域有天气、地图、导航、实时路况、打电话、音乐、电台、有声读物、设置、车辆管理、应用管理等等。
Pepper 机器人
中文的对话交互也是基于平台打造出来的
（2） 下一步工作
让对话交互更流畅
NLU 鲁棒性，对话鲁棒性
让对话交互更智能
知识和记忆的能力
主动对话的能力
持续自学习的能力
