【AI笔记】讯飞人机智能交互平台（AIUI）的武林秘籍
先说下，这篇不是标题党，在体验了讯飞的人机智能交互平台（以下简称AIUI）后，感觉这货和武侠小说特别的像。
emmm，是真的很像……不信往下看。
一、AIUI简介
1）简介
体验时间：2018-03-10
wiki：http://aiui.xfyun.cn/help/whitepaper
先看下官方解释
AIUI是科大讯飞提供的一套人机智能交互解决方案， 旨在实现人机交互无障碍，使人与机器之间可以通过语音、图像、手势等自然交互方式，进行持续，双向，自然地沟通。
2）AIUI结构
AIUI是怎么为产品提供人机智能交互的解决方案的呢？
看下图（以下为个人理解后画出的结构图，如有误望指出，thanks）
AIUI主要提供了两大能力
1. AIUI硬件
通过AIUI的麦克风阵列，实现精准唤醒，语音的降噪，回声消除等。
2. AIUI开放平台
通过AIUI平台，将上传的语音转化为文字，同时去匹配AIUI中事先预定义好的各种技能。如有需要的时候，还可以通过“云函数”调用产品服务端，传递服务端处理的结果给前端。
通过上述的AIUI硬件+AIUI开发平台，实现了“响应语音+语音转化+自然语音处理+命令处理+前端响应”的产品闭环体验。
对于硬件，还可以使用讯飞的TTS能力，将文字转化为语音响应用户。
二、AIUI开放平台的结构
本次只体验了AIUI平台，先讲讲结构
1）AIUI开放平台结构
在AIUI开放平台上，可以看做由“应用+技能”两部分组成，其中“技能”除了自己创建的外，还有一个“技能商店”，可以选中他人已经制作好的技能，添加到自己的应用中。
2）应用
开发者可以针对不同的使用场景，创建不同的应用，通过在应用配置页内添加技能或者问答来实现应用的功能。
所以 ，应用可以理解为技能的一个壳，应用装上了不同的技能，就能实现不同的能力
也可以理解为武侠中的人物（例如张无忌），学习了不同的技能（例如乾坤大挪移），就能发出不用的招式拉。
3）技能
技能是AIUI开放平台的核心，这里先简单带下，下面细讲
技能能实现不同的功能，实际是识别出了用户不同的意图，然后根据不同的意图做出不同的反应。
所以，技能是意图的集合
例如“点歌”这个技能，包含了“搜索歌曲”，“播放歌曲”，“切换歌曲”，“”切换播放方式（随机/单曲/顺序）”，调整音量”等意图。
这里的技能还可以理解为《倚天屠龙记》中的各种武林秘籍，武林秘籍可以自创，也可以使用前辈留下来的。
4）云函数
云函数实际属于技能的一部分，官方定义如下
为了扩展自定义技能的能力，AIUI 提供了云函数帮助开发者实现丰富的自定义功能，云函数位于语义理解引擎之后，运行环境为 NodeJS ，可以直接与万维网通信。
一张会晕的图
简单的讲，当识别出用户意图后，要做的事情，可以通过云函数去调用服务端的接口来实现。
例如上面例子中，“播放音乐”的技能，识别了“播放王菲的《红豆》”，进行后处理，通过接口去调用“网易云音乐”，实现歌曲播放。
这里的云函数就是意图识别成功后的后续处理程序逻辑（简称后处理）
所以，通过AIUI开放平台，我们能实现
让一个应用包含多个技能，通过技能去识别用户的意图，再通过云函数进行意图识别后的后处理，最终实现应用的各种功能。
三、技能
下面细讲下技能
技能分类
通过上图，能了解到，技能分为2大类“问答型技能”和“非问答型技能”
问答型技能
问答型技能，针对指定问题给出指定答案
好比微信公众号中的自动回复，提前设置好问答对，只要匹配中的提问的关键词，就会自动回复对应内容。
又例如张无忌小时候在蝴蝶谷带病习医，学习了大量的医术，这时候你问他一些疾病知识，立马能照本宣科的回答出来。
非问答型技能
非问答型技能提供了强大的自定义能力，开发者可以用它自定义语义、自定义业务处理逻辑、自定义上下文关联、自定义对话管理，以及进行信源查询等等。（目前仅开放了自定义语义）
非问答型技能，能实现各种复杂的逻辑判断，例如张无忌学习的《九阳真经》和《乾坤大挪移》，能力强大，也是重点，下面细细讲。
技能也细分为四类“自定义问答库”、“开放问答库”、“自定义技能”、“开放技能”。
1）自定义问答库
通过创建问答对，当用户输入指定的问题的时候，匹配中的时候就回复对应的答案。
支持如下能力
1. 非全匹配
例如设定“你是谁？”，输入“你是谁”、“不知道你是谁？”，也能触发
2. 多对多回复
能实现一个问题多种回复，或多个问题一个回复，或多个问题多种回复。但是回复是随机的
3. 预置情感属性（默认/中立/生气/高兴/悲伤）
这个感觉更像一个冗余的属性字段。。。方便后期一些功能的拓展
2）开放问答库
除了自己创建预定义问答外，还可以导入官方的问答库
3）自定义技能
（重点来了，考试必考，敲黑板！敲黑板！）
自定义技能中，需要提到“意图”、“语料”、“实体”和“云函数”
这里不容易理解，先举个例子
《九阳真经》中有各种招式，例如“借力打力”（以下是为了讲解瞎编的武林秘籍，具体秘籍内容去问金庸老先生）
其中招式有他的适用范围，例如“借力打力”，肯定是近身才能用，别人来源发个气功你怎么借力打力？
这个适用范围下，有多个不同的实际场景
例如“少林寺高僧赤手空拳在3米内攻击”，“武当派弟子在2米内持刀攻击”等等。
但是可以把这些具体场景抽象出二三个抽象场景，上述的例子，“2米”，“3米”就可以抽象为“近身”，“赤手空拳攻击”和“持刀攻击”可以抽象为“攻击”
所以就有的一个抽象的场景，敌方近身攻击时
最终，在某个抽象的场景下，我们还要知道运用这个招式的他的能力是什么
大家记住上面的招式，类比到AIUI开放平台中的技能，就是如下
1. 意图
意图，指技能中一类说法的集合，表示用户同一个目的或者触发同一个操作。
每个自定义的技能，都可以有多个意图（好比一本秘籍中有多个招式）
2. 语料
语料，在每个意图下，根据用户可能的说法，可以有多个提问的方式。
每个意图都有自己的作用域，实现特定的功能（好比招式的解释）
而每个意图，可以有不同的表述方式，例如“播放[某某歌手]的[某某歌曲]”和“我想听[某某歌手]的[某某歌曲]”，都可以归纳到“播放歌曲”这个意图。
所以一个意图可以供多个语料识别出来，一个语料就是一个抽象的场景，其中的[某某歌手]是一个变量，可以填入不同的值。
3.实体
在用户提问语料中或许会涉及到一些可变的内容，类似于编程语言中的变量，我们称之为语义槽，这个时候需要指定语义槽对应的值，这个值就是实体。
每个抽象的场景中，都可以填充具体的值，成为具体的场景，这个具体的值就是实体（好比借力打力中，“近身”可以填充的实体是“2米”，“攻击”可以填充的实体是“用刀攻击”）
4. 词条
在“播放[某某歌手]的[某某歌曲]”中，我们可以填充实体不同的值，形成例如“播放孙楠和韩红的《美丽的神话》”或“播放孙燕姿的《天黑黑》”。
所以，实体是词条的集合，一个实体可以对应多个词条。
这里的实体还可以理解为字典，例如song这个实体，其实可以表示为歌曲的字典
静态实体和动态实体
实体根据不同的使用场景，可以分为静态和动态，共5种。
讲述完上述的秘籍内容后，整体的脉络就清晰了
如果照粒度从大到小划分：应用>技能>意图>语料> 实体>词条
结构
一个应用可以含有多个技能；
一个技能可以含有多个意图；
一个意图可以含有多个语料；
一个语料可以含有多个实体槽；
一个语料槽（实体槽）被一个实体填充；
一个实体可以含有多个词条。
4）开放技能
和开放问答库相同，除了自己自定义技能外，还可以加入开放的技能
5）技能关系
上述我们讲完了应用的4个技能类型。
假设一个用户问到的问题，4个技能都能匹配到的时候，应该输出哪个呢？
AIUI开放平台的规则是
· 自定义 > 开放
· 技能 > 问答库
所以优先级为：自定义技能>自定义问答库>开放技能>开放问题库
四、评价下AIUI开放平台
1）优点
优点1：模块化逻辑清晰
整个平台模块化逻辑清晰，应用>技能>意图>语料> 实体>词条 的结构易懂，我这种小白都能很快的上手。
优点2：针对狭隘的封闭域对话，可快速搭建
创建一个简单的技能，只要穷举所有可能的意图，加上尽可能多的语料，就能覆盖该技能下用户可能的问题。所以对于狭义的封闭域对话，能实现快速搭建，快速上线使用。
优点3：云函数支持后处理，自由度高
支持后处理，意味着当识别用户意图后，后续所有的判断都可以自定义，结合产品自身服务端的各种接口，能实现各种个性化的功能。
2）缺点
缺点1： 模糊匹配，而非真“学习”，效果不佳
AIUI开放平台最大的遗憾，是采用了模糊匹配，而非RNN。
举几个测试的例子
· 模糊语义测试
AIUI开放平台上，每一个技能要完整覆盖意图，要去考虑不同空缺值的情况。
例如预约挂号“booking_register”这件事情，在具体场景中，“帮我预约北大医院{hospital} 黄林医生{docname} 明天上午 {time} 的号源”，需要三个语义槽才能完成预约挂号这件事情
所以有三个语义槽
· {hospital} 医院
· {docname} 医生
· {time} 时间
考虑到3个值可能空缺的情况，就需要2^3=8种意图
但是仅仅有完整意图还是不够，因为AI在识别的时候，是按照语料的句子结构去识别的！
例如上图中
“预约北大医院明天号源”和“明天帮我预约北大的号源”，这两句话都有“北大”和“明天”两个实体。
都应该匹配到【booking_register_w_docname】这个意图。
但是仅仅修改了语序（这个语序在语料中没有），“明天帮我预约北大的号源”就错误的匹配到了【booking_register_w_timeAndDocname】上。。。。。
可见在AIUI开放平台上，是依据模糊匹配来识别具体的意图，并非真正的机器学习。
猜测可能模糊匹配的原理如下
猜测可能模糊匹配的的方式，是通过匹配实体，拿到实体组顺序，再将实体组顺序和语义中的各个语义槽顺序进行匹配，最终匹配上的时候，再找到关联的意图。（以上都是自己瞎脑洞的结果，不清楚真正的流程）
实际我们期望的RNN
上述采用模糊匹配，当某个词汇是在实体的词组中不存在的时候，就没法命中词组！
但采用RNN的机器学习，即使词汇是此前没见过，通过学习也能达到将词汇归到正确的词槽中，机器学习的效果显然是更好的。
缺点2：人力成本高
假设上面的逻辑是可能的模糊匹配的逻辑，那么意味着
1. 有n个语义槽，就需要有2^n个意图才能完整覆盖；
2. 意图中的语义槽排序必须穷尽，否则匹配的效果会很差
3. 实体中的词条必须穷尽，就无法命中实体；
再加上每个意图都需要执行不同的命令（例如“booking_register_w_hospital”需要让用户完善hospital的词槽，“booking_register_w_docname”需要让用户完善docname的词槽），这样一来，开发的成本实在太高了！
后期要维护意图，维护语义槽，维护词条，维护意图对应的后处理，维护成本也很高！
3）总结
AIUI开放平台，确实让创建一个人机对话的变得简单，值得肯定。
但是追根溯源，并非真正的机器学习，还是原有的if else模式，仅仅通过模糊匹配，减少一些语料数。
针对简单的封闭域对话，AIUI能帮助开发者迅速的搭建起对话服务；
而对于复杂的对话，通过AIUI开放平台，不但开发成本高，后期维护成本也非常高，不推荐使用，通过机器学习的方式才是正道。
最后打个分
· 易用性：5星
· 智能性：2星
· 开放性：4星
以上内容如有错误之处，希望各位看官指出，我也还在学习中，thanks ：）
