阿里云AI专家陈一宁：别被语音识别率的数字所“骗”、语音交互产品大多很鸡肋

雷锋网按：近日，阿里云人工智能专家陈一宁在 2016 云栖大会惠州峰会中给语音识别和语音交互领域泼了三盆冷水，陈一宁的观点如下：

• 众多公司对外宣称其语音识别率多高多高，但严格意义上讲这只能叫做在“在××数据集上的识别率”。而且语音识别和交互应紧紧与应用场景相结合，而在具体的相应场景中，识别率往往会受到很大的影响。

• 现在智能语音交互硬件产品往往存在外观差、语音交互不智能等问题。

• 相关创业公司商业模式不清晰，做出伪需求产品、产品解决问题的能力有限。有 To  VC 的嫌疑。

随后，陈一宁从计算方案、声学模型和产品落地三大方向解读语音识别技术和语音交互的项目解决方案，由雷锋网根据陈一宁演讲进行编辑。

2016 年各家公司均公布自家的语音识别率已达到 97%，除此之外，智能硬件也层出不穷。其次，做聊天集成的公司，去年从只有几家、十几家，到今年已经达到上百家。然而市场上各个公司的质量却良莠不齐。

给语音市场泼盆冷水

从三个方向泼冷水：

• 识别率真有数字所写的那么准吗？

• 语音交互硬件产品外观差、语音交互不智能。

• To  VC 式的创业方式：商业模式不清晰，伪需求产品、产品能解决的问题有限等。

语音识别率这块着重提及一下。识别率一般是这么定义的，100% 错误率比较好理解。而错误率分三种，替代、删除和插入。错误这个词如果把他识别成错误率了，实际上没有替代错误。这里有一个插入错误，这个地方会有一个特点，实际上错误率是可以小于 1 或者小于 0 的。这里强调一点，识别率的全称一般是在某某数据级上测了一次，统计之后有了识别率。我可以负责任的说，任给我一个语音识别系统，我都可以找一个测试集让他的识别率是负的，都不用说这个识别率是 0。

任给一个语音识别系统我都可以做到，大家都可以很容易试，很多时候错的比对的都多。我们更多是要看还有哪些问题是不能解决的，应该扎扎实实的去看，哪个任务上我们的识别率做到什么程度了，那这个任务上我们到底还有什么空间可以改进。

实际上语音识别是一个强场景化的技术，而脱离场景谈识别率，那就是耍流氓。因为各种各样的情况，都会严重影响识别率的变化。

严重影响识别率的第一个因素是环境和设备。如录音设备是什么？距离有多远？环境是安静的还是嘈杂的？大家在看演示的时候，我是跟大家说“噓…，大家现在小声一点，我开始做演示了”，还是说这个环境是发生在一个嘈杂的咖啡馆里面，比如在咖啡馆里做一个采访，可能在饭馆里头，这个识别率是会有天差地别。

第二个影响因素是友好度。这其中包括口音、说话的方式、吐字不清以及语种、方言等等。另外所识别内容所处的领域也非常关键，如科技领域和医疗领域之间是有很大区别的，因为这两个领域上专业名词有非常大的差别。

阿里云 ET 语音识别系统

这些问题都在提示我们要找哪些人去做，怎么去解决，而不是说我们拿出一些识别率的数字来说话。传统意义上有两种解决方式：一种是归一化方式，另外一种是增加 Variance 的方式。以噪声为例，比如我们把噪声去掉；第二种是说既然要解决有噪声情况下的语音识别问题，我们就要刻意制造一些噪声到数据里面，让模型去“接触”所有的噪声。就跟人类一样，学过就知道，没学就不知道。通过这样的方式解决问题。 雷锋网(公众号：雷锋网)

阿里巴巴 CTO 王坚博士这样总结：阿里云语音技术的突破，在于我们充分利用了云计算和大数据平台的能力，在不到两年的时间，完成了通常需要 20 年或者更长时间积累的工作，构建出强大的基于模型、数据和计算能力的学习系统。

接下来，我会分三个事情分别讲一下解决问题的技术方案。

一、计算方案

先谈谈计算。计算通常分为两部分：离线计算和在线计算。

离线计算

离线计算在深度学习领域里通常使用 GPU 较多，阿里利用基于 GPU 多机多卡的一种中间件，使得任何单机的深度学习模型，通过非常小的修改就可以自动做到在一个多机多卡集群上去跑。

从下图可以了解到，这里有分布式存储，有 GPU 集群，上面的所有东西均是通过 Max Compute 平台来做 CPU 集群混合管理，上面包含各种通讯、控制、数据分发、辅助组件，这套组件可以使得运算速度变得非常快，非常灵活。

GPU 和 CPU 各有优缺点，GPU 计算能力更强，而 CPU 更灵活、数据存储更好。我们通过交换机把他们完整的联合在一起，用 Max Compute 做混合管理，使得数据可以在 GPU 和 CPU 之间任意流动，让数据流变得很通畅。现在业界的常见情况是，通过深度学习算法本身让速度变快，但现实是一个系统项目不能只靠深度学习，因为上下游一切东西都有可能导致整个流程变慢，深度学习并不能解决所有问题。

而通过 CPU 和 GPU 混合管理，就可以避免这些情况的发生。

在线计算

刚我们提到，脱离领域、脱离场景谈在线计算本身就是耍流氓。实际上因为我们的架构，可以对每一个租户提供自己的模型，然后在每个租户之上，我们还可对这些租户的每个用户提供模型。

举一个例子，这里的领域模型可以指的是类似法院的模型、医疗的模型、金融的模型等等。租户的模型可能是说不同的法院模型。再往上的话，每审一个案子都可以有不同的设计，案子里到底原告是谁？被告是谁？这样的信息都可以加到模型里，使得这个识别率变得非常准确，否则这些人名是不可能事先被知道的。这种框架使得环境变得非常的好。

数据

阿里云的数据主要为电话数据、App 数据、电商数据和搜索数据。

电话数据即大量客户打电话进来，我们收集的这些语音数据。其次阿里拥有众多 App，App 的语音交互也会产生语音数据。电商就不用提了，阿里有自己全网搜索。所有这些数据合在一起，构成阿里云很大的数据池。这些数据池通过各种“脱敏”，去掉一些真正跟用户相关的信息，然后就进入我们的整个训练流里，使得我们最终的社会识别率变得非常的好。

二、声学模型

在模型层面，阿里云做了一些独特的工作。这个是比较常见的（英文  13：10）的混合的声频模型，实际上是阿里云第一个把这个技术投入到真实的生产环境中去。大家知道技术从写出来到做出来是有很大的差异。第二个事情是很多技术我们在解码器上面做很多的工作。

上图中，左边是每个子的单元，这个地方有意思的是，大家看到最左边有一个叫遗忘，每个东西是人神经网络记忆的单元，这个网络不仅能学会记忆，也能学会遗忘。如果永远不遗忘的话，网络会不断记录所有内容，最终逐步膨胀，直到网络爆炸掉。我们添加遗忘功能就是让它在该遗忘的时候遗忘，不该遗忘的时候不遗忘。与此同时，大家看到右边闭合的地方是双向的，它知道收的话，从前往后是有关系的，那从后往前也是有联系的。所以说，双向的网络可以使得识别率会有进一步的提升。

当然，双向既有优点也有缺点。因为识别的时候是单向的，如果成为双向的话，需要拿到后面的信息。实际上不可能在这一时刻拿到后面的信息，那此时就需要做一个延时，然后后面再识别回来。该技术通过一些数据的推导，证明说后面实际不用那么长，只需一小段，就可以达到与前面一样好的效果，让延时变得非常可控，而非直到结束才能得到一个很好的结果。

下图是比较传统的深度神经网络模型，右边是混合的，先有三层的BLSTM的模型，再录了两层 DN 模型，从而达到一个非常好的效果。

高速解码器

刚才讲的实际上是一个离线的过程，学术界和工业界最大的差异不在于离线的的训练，因为离线的训练，即便有时候跑得慢一点也能跑得出来。但是在线就不一样了，在线如果跑得慢的话，就无法投入工业生产，会有很大延时。就像我们在大会上做语音识别转写如果有延时，讲完一句话后十秒钟才出来就没法看了。所以这个地方最重要的是能够做一个在线解码，解码器实际上就是说把实时的声音进来，并能实时转出去。

实际上业界有很多的想法，即到底用 CPU 做、GPU 做还是用 FPGA 去做？其实这个地方要做到通用性和效率的平衡。通用性可以使得整个体系的灵活性和效率达到最优。我们在 FPGA 上做一些非常个性化的东西，有时候似乎有一些好处，但是实际上它带来的问题会使通用性变差，最终在部署上会带来更多问题。所以我们最终在解码上选择了最通用性的方式，采用了 CPU 的方案，同时我们与英特尔有过很多合作，在 CPU 上得到极大的提速。

下面这个技术是我们最近研发出来的 Low-Frame-Rate 的技术，这项技术实际上是个很有意思的想法。最传统的语音识别会把一秒钟切为一百帧，每一帧去做解码的过程。现在 Low-Frame-Rate 技术并不是这样去做，因为人类听声音也没必要听得那么细才能知道语音是什么。因此我们把帧数的跨度变成三倍，通过三倍的跳桢，使得整个速度变成原来三倍。这样 Low-Frame-Rate 的 TM 模型可以使得我们在单台 CPU 的机器上达到上百线的处理能力。

三、应用场景和产品落地

智能硬件

其实阿里云在智能硬件这块，更多的是跟云 OS 或者跟一些合作伙伴来做。

其实阿里云更多提供底层技术，在消费级产品实际落地方面则会跟上面业务方做合作。软银 Pepper 机器人跟阿里云合作做了一些工作，利用语音技术可以做到远程唤醒和交互。但是它的交互除了眨眼、转动，转头、走路外，很多交互表现在它胸口的屏幕上。

智能硬件需要想到一些刚需的场景切入，包括对机器人、车机、音箱等等。在国内，对智能音箱的需求不是很高，但是车机方向确是一块越来越有价值的市场。

问答平台

后来阿里云也进行了 Bot 实践，阿里云做了自己的 Bot ET 问答平台。该问答平台会我们提供给合作伙伴，让他们为用户去建立自己的问答机器人。

除了一个问答机器人本身以外，我们这个系统可以让用户去根据用户场景去设定他的自己的对话管理，并且可以把各种知识库、问答对、表格等等知识库输入到系统里面去。同时闭环的流程可以通过用户反馈，对数据进行纠正。因为知识库大了一定会出现各种各样的问题，而人在没有辅助的情况下基本上不大可能一遍写对。

为了解决这一问题，阿里做了很多解决冲突的工具去查找问题。数据回流时系统就可知道到底在问什么，通过各种各样的方式，包括自定义可使得真正做得比较好用的机器人。但是这件事情上，阿里云有一个确定的点，其做这件事情不是为了代替，而是希望把有限的人力投入到几个真正最难解决的问题上去把一些机械的事情，通过机器去把他干掉。

。