智能语音交互(Intelligent Speech Interaction)是AI的入口，智能语音交互之于VUI，正如鼠标键盘之于GUI。但什么是智能语音交互呢？这个名词并非每位同学都能望文生义，我试着给出个最简练的解释：让机器能听懂我们的话，并能给出相应的反馈。
这其中包括了唤醒、声纹、语音识别(ASR)、语义理解(NLU)、知识库(QAS)、多轮对话(Dialog)、语音合成(TTS)等诸多端上和云上的能力，这前面还包括了从麦克风整列、声学信号处理到端上唤醒、免唤醒等能力。
为什么会有这篇的分享呢？
先来听听"一小撮"客户的声音：A公司有ASR，B公司有NLU，C公司有TTS，他们看起来都不错，我都想用，我来把这些攒起来，然后根据具体情况，选择ASR用A家还是阿里的、NLU用B家还是你们的……端上呢，向我的服务发起请求，我来做上帝。
是的，客户永远是上帝。只要你喜欢，这种攒的方案总是可以搞出hello world的，这是事实。曾经，我们非常理解客户的心情，也这样提供给用户这样的单组件输出的服务。但是，"智能"服务的核心是智能，也就是准——准确地被采集、被唤醒、被识别、被理解，并给出最佳的反馈路径和相关内容。单组件输出的问题我不(YU)好(KU)乱(WU)讲(LEI)，看完本篇你自然会懂。
为了秉承精品输出理念，我们最终选择了几乎"偏执"的解决方案——整体能力的输出。这是不断被折磨、蹂躏、挑战、逼迫，险些放弃并最终坚持的观点。
海尔五代项目在阿里巴巴大文娱的鼎力支持和合作下，我们共同贯彻了整体能力输出的目标。有幸作为参与者，我将从语义理解和对话管理开发者的角度，与大家分享我在海尔五代项目上的观察和思考。
1 联合优化
一致的数据
一切智能始于数据。没有数据就没有模型，而模型是智能的大脑。
从开始在阿里云大数据团队到今天，我时常听到的一句交流是"你是怎么解决冷启(Cold Start)的？"，也就是说，没有数据就无法训练出有效的模型，这是智能服务最不智能的阶段。
日更
我们生活在数据大爆炸的时代，大文娱领域的影视作品、当红艺人等；新零售领域的商品名称、促销别名等，大交通领域的车站名称、路名等，这些数据的更新非常频繁。为了满足海尔五代项目的需求，我们确认了数据更新的频率为日更。
为了满足日更的目标，我们必须建立一套自动化pipeline基础设施，以实现从数据到语言模型(LM)、实体(Entity/Tag)+词典(Dict)、理解模型(model-based NLU)、理解规则(grammar-based NLU)的每日上线，否则从业者累死也跟不上这样的节奏。(注意：并非全自动化、无人参与。由于智能行业的特殊性，依然需要人的参与，众包和标注要靠人来最终确认。）
我们在原有自动化pipeline的输入源上增加了大文娱的日更数据，输出是上线的识别和理解的能力。因为我们为海尔五代输出的是整体能力，因此ASR和NLU共享源头数据，确保了更新的内容和处理时间一致性、人工和处理程序的方式的一致性，避免了人工标注的重复劳动，最终热更新的词典、规则、模型的上线时间也是一致的(最矬也是精确到天啊，不要问我差多少个ms)。
用户自定义词典
通过我们的对话技能定制平台，用户可以定制自己业务场景的对话技能，每个技能包括了细粒度的语义理解和对话管理的定制。其中，用户自定义的词典是解决用户特定技能下的语义理解的。举个例子，要理解"帮我订下阿里日全天的问天涯"，就要知道"阿里日"是日期(5月10日)、"问天涯"是阿里的会议室名称。虽然系统词典提供了日期和地理信息的词典，但无法支撑语义理解服务解这个特定业务的query。
用户对自定义词典的改动是随时随地的，而且默认期望是随即生效的。我们提供的技能建设能力会在用户保存修改后，自动处理相关数据并最终同时对ASR和NLU服务做热更新。得到我们整体能力输出的客户，ASR会准确识别"阿里日"和"问天涯"两个词，NLU会正确理解这两个词的含义。
注意，用户改动自定义词典的这一过程，无论ASR还是NLU都不需要我们人工介入。对海尔五代的产品经理来说，省去了与(平台和引擎的)研发同学的沟通成本和等待人工的时间成本。
数据闭环
整体能力输出不止是引擎服务，还包括集团赋予我们的能力，比如全链路日志建设。
当客户反馈某个query没有得到预期的结果时，我们通过全链路日志可以很快地定位和解决问题。但这还不是全链路日志最有价值的地方。
无论规则还是模型都无法覆盖全部场景(open dialog和open Q&A已经证明是行不通的)，服务会有矬的时候。当一个query的理解结果为unknown时，用户得到的结果通常是"我没懂"一类的话术。
通过全链路日志，我们可以得到unknown对应的query，通过周期性的人+自动化的pipeline修正能让服务越来越懂，换句俗话就是让机器通过学习变聪明。这个过程就是数据闭环。
数据闭环推动了服务能力的可持续改进，但这个改进很难通过单组件输出体现出来。
- 只输出ASR，识别对了可能依然是unknown的理解结果；
- 只输出NLU，如果语音识别错了NLU几乎无法理解(后面会讲到纠错，但也是整体输出才能体现效果)，NLU会很冤，通常在出现unknown时，NLU会首先背锅，没有强大的运维能力，这锅就扣住了，最后定位到ASR的问题，还是解不了。
一致的规则
如果模型是饭，那么规则就是水。
"你是怎么解决冷启(Cold Start)的？"
"写规则啊"
说者理直气壮，问者会心一笑，不知者不屑一顾。
从业者都知道，在模型没有被足够的数据训练好之前(可能就不存在这样一个时间点)，基于规则的识别、基于规则的理解就如水一样，是智能服务的生命之源。"工程"出身的人通常羡慕"算法"的是训模型，觉得实现规则没啥牛的，这感觉对错并不重要，重要的是规则很重要。规则是启动(boost)一个智能服务的源水。
任何同时拥有ASR和NLU的公司或者团队，都不会同时使用两套定义规则的语法，也就不会搞两套规则解析器(grammar-based decoder)。
在海尔五代项目中，ASR和NLU的规则引擎和规则定义是一套，同步改进理解能力和解析速度。当请求遇到"准"相关的问题时，我们会去看基于同一语法的识别规则和理解规则，同步改进规则书写的逻辑；当遇到"快"相关的问题时，我们会去看底层统一的规则解析器，改进算法或者实现；遇到"稳"相关的问题时，我们会去分析并改进统一的服务架构。
2 互相补位
阿里巴巴机器智能技术实验室的科学家说：智能服务引擎的输入和输出都应建立在基于概率的假定之上，健壮的引擎不能假设输入是100%确定的。
我来个小白的解释：ASR不是万能的，NLU不要相信他；NLU不是万能的，Dialog不要相信他。
2.1 NLU补位ASR
纵然前述讲到数据的一致更新，但由于两者对细节的考虑和处理不同依然存在差异的。比如如下同音不同字的情况：
- 我想看熊出没之雪岭熊风
- 请播放变四
先从人类的角度看上面两个用例。如果你家没有熊孩子，那么你不会看熊出没，也应该没听过"雪岭熊风"。那么当你听到这四个字时，最直觉的识别就该是"雪岭雄风"。如果你不知道"变四"是指"变形金刚第四部"，你应该无法识别是哪两个字；你知道这个词也可以书写成"变四"或者"变4"，两者没有错对。
再从机器的角度说海尔五代项目中的真实案例。一开始，ASR对上面两句的识别是"雪岭雄风"和"变四"，而NLU的热词分别是"雪岭熊风"和"变4"。从NLU的角度看，ASR都"错"了。NLU引擎服务中实现了纠错，自动将"雪岭雄风"更正为"雪岭熊风"，并将"变四""转成了"变4"。在我们的整体输出能力中，NLU的这一改变，ASR是可以通过对应的日志最终感知的，反哺ASR的持续改进。ASR可以决定是否跟着NLU的纠错进行修改，比如可以接收"雪岭雄风"但坚持"变四"。
2.2 Dialog和NLU互补
一个query送给NLU，NLU不能保证每次都返回最正确(N-Best)的结果。最正确的返回应该是携带置信度的domain/intent/slot列表，而不是只根据置信度打分返回分数最高的值。因为，词槽对应的实体标签是和对话上下文强相关的。比如，"成都"可以是"城市名称"也可以是"歌曲名称"。如果当前query之前的意图值是"旅行"，那么"城市名称"更接近用户的意图；如果是"音乐"，那么用户应该是想听赵雷的歌。
依靠对话上下文来判断的能力是对话管理的本职。但是，Dialog也不是万能的，仅靠这一个因素是不够的，还需要理解结果中的置信度。只有理解和对话深度共建，在书写对话逻辑的时候，才能尽量合理地使用理解结果中的置信度，否则你无法确认一个0.9的结果和另一个0.8的结果，哪个更值得相信。
Dialog的结果会根据具体业务以及端的类型返回最佳反馈或者最好的一组反馈。对于音箱这类无屏的端，一般会返回最佳反馈，在海尔五代项目这类大屏业务中，可以返回一组反馈，便于用户选择和确认。这里的核心技术点是，Dialog需要让NLU知道，在上一轮、多轮的结果中，Dialog最终采用了哪个或者哪几个理解结果，以便NLU对当前轮的query做出更合理的理解。
此外，在我们的整体解决方案中，客户除了可以定制业务相关的对话技能和意图，还可以定制问答对知识库。对于闲聊、电视产品说明书、百科等业务来说，使用NLU不是正确的打开方式。此时，Dialog对NLU的补位是通过知识库实现的。
NLU和Dialog一起负责智能服务中的"懂"和"做"。这一工作是非常艰苦和持续的。原因是AI技术远未发展成熟，人类对此的共同探索在未来的很长一段时间恐怕都是孜孜以求却求而不得的状态。
但人类不会因为没有发明出发动机而放弃马车。只有NLU和Dialog一起发展并不断补位，才能在科技水平存在瓶颈的阶段做出最好的反馈。根据Conway定律，NLU和Dialog同宗同源才能更好地打造马车时代的精品。
2.3 唤醒的端+云补位
相信用过语音智能产品的同学都有体会，智障并不是智能产品最无法接受的，夜里被误唤醒并讲出可怕的故事或者发出灵异的声音才是天理难容的。
因此，唤醒成为了智能语音交互的双刃剑。无唤醒意味着从麦克风到语音上云的链路是从不关闭的，那么智能产品除了费电、占带宽，还会不断地告诉你他听不懂或者乱打岔。因为他不知道那句话是对他说的。因此，唤醒是必备功能。那么，唤醒词就是"芝麻开门"的作用，这个词多家设计为以"小"字开头。
被误唤醒的根源是智能产品把请求query或者某种听得见听不见的音频流当做了唤醒词。相信是这个道理：如果一家能根治的问题，最终对其他家来说也不是问题。那么说明，以现在的科技能力，没有能真正解的技术。
于此同时，为了满足海尔五代项目的业务需要，我们需要支持免唤醒功能——支持热门影视作品的随说即达。比如我们直接对电视说"我要看羞羞的铁拳"，电视会被自动点亮并直接播放该片。当然，"羞羞的铁拳"必须是热门影片并且你得有收看该片的权限。
这个对用户来说很牛的功能把本就不成熟的唤醒功能逼上了绝路。于是，被逼的我们，为整体解决方案设计了端+云的补位(详情请付费收看，开个玩笑，这不是本篇重点)。有了云+端的联合判断，不但有效降低了误唤醒，还实现了上述的免唤醒影视直达的狠功能。
3 技能的完整性
通用技能的共享和建设是智能服务各个领域都非常看重的。一个技能包含了语义理解、对话管理和内容服务三部分的能力输出。我们以海尔五代项目中的音乐技能为例：
- 语义理解：用户的任何有关播放音乐的query都能被理解为音乐领域
- 对话管理：以最收敛的方式确认是音乐播放意图并确认所需的全部参数，并从内容服务获取资源返回给端
- 内容服务：根据关键字或者标签计算出相关资源并返回给调用方
从这个例子可以看出，整体输出能够得到最完整和最流畅的服务能力。攒服务是无法做到通用技能联合建设联合打磨、调优的，更无法做到零开发成本的(与其他厂商之间的)技能共享。
对话管理是通用技能中最关键的环节。像讲故事、播放内容这些技能，对话路径比较容易设计，因为这些技能的业务相关性比较弱，无论业务方是全屋智能、智能电视还是智能汽车，我们都比较容易以相同的对话路径实现统一的交付。但像旅游、酒店等技能，我们无法预先想好一个泛领域的路径，以适用各个业务方。
因此，我们的管理平台提供了预置理解能力和内容服务的能力，用户只需在管理平台上实现对话函数(fn-based dialog)或者对话任务(taskflow-based dialog)即可实现业务相关的技能建设，并且可以共享给业务类似且对话路径相同的其他用户。
整体输出的另一个好处是内容聚合。举个例子，由于数据安全和知识产权等原因，我们可以获得大文娱的首屏热门资源列表这种日更数据，外部的NLU或者Dialog服务无法享受这个自动化服务。那么如果一个依赖大文娱优酷的电视厂商，不走我们整体输出，他们的NLU和Dialog就缺少这块的数据更新，势必会影响其热门影视作品的理解和对话管理能力。再举个例子，如果用户要看优酷、听虾米、上淘宝、走飞猪、吃盒马，那么集团里谁有语音识别、语义理解、对话技能建设的整体输出能力，谁就有资格代表阿里输出智能语音交互服务。
今年只是AI一年(2017年被定义为AI元年)，人类在AI领域要走的路还很长，智能语音交互的整体能力输出当然也在其中。最后，我纯票友畅想一下语音交互持续的整体能力输出黑科技：ASR+TTS的联合能力、Dialog NLG+TTS的联合能力、方言整体输出能力。
