人机大战机器胜！这次是智能语音识别技术！

昨天，在阿里云的一场年会上，真枪实弹的上演了一场人机大战。一张大屏分两边，一边实时滚动的是出自阿里著名的快男姜毅的文字速记，一边出现的是阿里云iDST的科学家们在短短一年时间打造出来的语音识别系统支持下的语音转文本记录。

人机大战一触即发，随着阿里云总裁胡晓明的演讲展开，屏幕两端实时出现了各自的文本记录，从现场效果来看，难分伯仲。如果不是提前告知，观者很难感知到擂台的一端是机器人，因为可以实时的看到机器人除了记录之外，还能根据演讲人语境的变化，返回来对前面的记录进行调整。结果评估取前八分钟的演讲录音，对比机器人和姜毅出现多字，少字以及错字的情况，出错少的一方获胜。机器人出现了一些词汇错误，而姜毅的正确率从头到尾非常高，但因为漏打了几个字，错失了机会。经过半个小时人工核对结果，机器人以微弱优势险胜姜毅。值得一提的是，前不久，在匈牙利举办的第50届国际速记大赛上，姜毅代表中国队，在文本看打速记比赛项目中以300字/分钟的文字速记速度，勇夺世界亚军。纵然是微弱的优势，但这次机器人战胜的已经是世界级的水平。

虽然是第一次正式亮相，但从去年开始iDST的语音识别系统，已经在阿里巴巴的多个业务场景中应用了。从去年开始，阿里集团与蚂蚁客服每接听一个电话，都会立刻启动一个叫风语者的系统，它就是自动语音识别技术，将语音转变成文字，千分之三的人工抽检可以瞬间升级为100%的自动质检。除此应用场景之外，阿里YunOS、阿里小蜜以及手淘，现在都已经应用到阿里云的语音识别系统。

云栖社区邀请到此次深度参与“人机大战”语音识别项目的阿里云iDST技术总监鄢志杰（智捷），他将和大家分享阿里语音识别技术目前的一些应用，背后的技术难点以及一些重点的技术沉淀。针对项目背后的一些核心技术关键点，例如：基于GPU的快速并行， BLSTM，超大规模语言模型，基于GPU的快速解码等，我们已经邀请到相关技术专家并约稿，会请他们来跟大家分享。请持续关注！

《语音识别助力客服小二：集团语音识别技术在留声机、服务宝项目中的应用》

作者： 智捷

原文地址：https://yq.aliyun.com/articles/8777

“正在为您转接客服小二。为了提高我们的服务质量，您的通话可能会被录音。”我们是这么说的，也是这么做的。每天，集团和蚂蚁的客服小二总共会接听几十万通电话，沉淀的语音数据时长超过数万小时。来自天南海北的客户将需要咨询的问题、需要吐槽的痛点、需要投诉的纠纷通过客服电话源源不断的反馈回公司。这些宝贵的客户心声在阿里会被认真的记录下来，并成为改善我们产品和服务的动力。

那么问题来了：如此大规模的语音数据沉淀下来后，如何才能被挖掘利用？阿里如此大规模的自营和外包客服小二团队，如何才能监测并不断提高小二的服务质量？随着客服系统越来越智能化，能否通过电话客服机器人来帮助客户解决困难？要回答这些问题，第一步就需要一种智能技术，把语音转换成文本，为后续的各个模块提供基础。这种技术就是我们常说的自动语音识别（automatic speech recognition, ASR）。

1 语音识别应用于电话客服

说语音识别是一种黑科技是一点儿都不为过的。在美国政府关于限制发放签证的“Technology Alert List”中，语音识别赫然在列，与核武器、火箭技术等同在“黑名单”中。阿里云iDST语音团队汇集了数位来自国内外语音领域的工业界、学术界高手，在集团此前的积累上继续发力。新系统的第一个落地点，就被选定在客服电话语音识别上。

客服电话语音识别是业务上诸多应用的前置模块。有了语音识别转换出的文本信息做支撑，包括电话质检、电话预警、情绪识别、声纹识别、语音自动结构化、语音输入等各种后续应用都可以开展。例如，电话质检可以帮助我们提升小二的服务质量。例如在我们的服务规范中，“请问你是账户持有者本人吗”、“感谢您的耐心等待”等是必须要问、要说的；客户说“谢谢”小二就需要立即答“不客气”等。

这些服务标准是我们对自己的要求、对客户的承诺。但是，在自动语音识别技术应用之前，这些标准很多时候只能是落在纸上、飘在空中而已——集团与蚂蚁每天天量的电话客服量，如果通过人工一个一个听、一个一个质检，是“不可能完成的任务”。事实上，我们每天最多只能做到不到百分之一的人工抽检。如此一来，我们事实上根本无法了解我们的客服质量。极端一点说，哪怕外包客服小二与客户对骂，我们也几乎没有可能发现。这种状态的危险性不言而喻。

有了自动语音识别技术，少量的人工抽检可以瞬间升级为100%的自动质检。当然，自动语音识别不可能做到100%正确、即使语音识别100%准确，质检规则、质检模型也不可能做到100%准确。这些都是我们需要持续努力的方向。短期来看，我们可以通过自动+人工的方式来提高质检准确率：即机器先筛选出可疑的小二问题，再由人工质检来确认。机器来 “大海捞针”，人工来“一锤定音”。实际上，100%的自动质检在客服小二的心理上也产生了化学反应——笔者曾听到小二笑言，现在知道有机器人在后面“偷听”，为客户服务的时候就会更小心谨慎。这也是在做自动语音识别之前没有想到的额外效果。

2 客服电话语音识别的技术难点

我们一开始就选择客服语音识别，不是因为它简单，恰恰是因为它难。相比于iDST承接的其他一些更为垂直的语音识别应用，如手淘语音搜索、天猫魔盒语音搜索而言，客服电话语音识别在技术上的难度相对更大：

一、客户和小二的对话是“spontaneous speech”，即非常随意的、自然的对话。这种说话方式包含大量的“嗯、啊、呃”等语气词，包含“那个……我那个……”这样的犹豫和不完整的句子。除此之外，对话双方打断对方说话的情形很常见，两人同时都在说话的情况也不少。这种类型语音的识别，比在语音搜索中应付单个用户、有准备的想好再说的情况，要困难很多。

二、电话客服对话的多样性较大，即客户和小二对话所涉及到的话题范围相当宽泛，且没有太多合适的文本语料进行语言模型（language model）的训练。与之不同的是，在语音搜索场景下，我们往往能够通过其他途径获得大量有用的文本资源并用于训练语言模型。例如，在天猫魔盒语音搜索场景下，大量的节目名、演员名是可以事先获得的；在手淘语音搜索场景下，用户搜索的内容甚至可以直接从淘宝query log中得到。这种差异，就决定了电话语音识别在语言模型的训练上比垂直的语音搜索要复杂。

三、电话语音在信道（channel）传输和噪声（noise）影响上更复杂。这是因为电话从客户到达我们的呼叫中心，中间通过了无数不同的信道和编解码算法，每一个都会使语音信号失真（distortion）。更不利的是，众多客户在声学特性方面非常多样，有的用固定电话、有的用手机，有的在安静环境下、有的在噪声环境下、还有的在有玻璃墙的强混响环境下。而我们的小二呢，带着头戴式耳麦（既不是手机也不是座机），旁边还坐着别的小二在打电话，这就带来了一个对语音识别最不利的噪声类型：babble noise，即旁边的人声产生的噪音。

客服电话语音识别还有不少与其他语音识别应用有共性的难点，如口音等，在本文就不一一介绍了。iDST在前期选择这样一个难度最大的业务来启动语音识别系统的建设，其重点还是在于构建和夯实技术基础。在此基础上，用同样的技术再应用于较垂直的语音搜索领域，就会显得游刃有余。接下来就重点介绍一些通过留声机和服务宝客服项目推动的重点技术。

3 电话客服语音识别重点技术沉淀

3.1DNN多机多卡声学模型训练工具

通过数据标注工作，我们在留声机和服务宝客服任务上很快积累了成千上万小时的真实电话数据。数据有了，如何快速的、迭代式的训练模型、不断调优，从而体现大数据的价值，就成了一个非常重要的技术课题。

如果我们用一般的单机单卡DNN训练工具来训练语音识别声学模型，那么即使是对一个不算大的、5000小时训练数据库而言（在语音领域相当于1.8 billion个训练样本），迭代数遍至收敛，将会需要2到4周的时间。这样的周转周期对于互联网时代快速迭代更新模型上线的要求而言，显然是无法接受的。

以 DNN 声学模型训练为契机和推动，为了应对今后训练数据急剧增长、训练周期越发不可控的风险，我们开发了 GPU 多机多卡 DNN 模型训练工具。在实验的 5000 小时训练集上，使用 4 机 8 卡相对 baseline 的单机 2 卡取得了 3.6 倍的训练加速。训练出的模型在某测试集上的识别准确率指标上与baseline 一致。在 DNN 训练部分所用时间从 7 天半缩短到 2 天。详细的实验结果可见下表：

这样的加速在技术上是如何实现的呢？这就需要重点介绍我们开发的GPU多机多卡middleware了。

3.2GPU 多机多卡middleware

关于GPU多机多卡middleware的话题，我们另有@镭铭同学的专文加以详细阐述，在这里只作简单介绍。GPU多机多卡middleware是如下图的一层抽象，它的主要功能是将GPU集群的硬件资源加以整合，提供通用的通讯、scheduling、数据分发、模型参数更新等模块，从而使得某个现成的单机版GPU程序通过较少的修改插入middleware后，就可以变身多机多卡程序。

具体来说，GPU多机多卡middleware提供如下一些通用的基础功能：

1.通讯：通过包装MPI，提供计算节点之间p2p通讯（包括send / recv）和collective通讯（包括AllReduce等），并通过包装GPU Direct RDMA提高通讯效率。使得单机GPU程序不用考虑通讯的细节，通过简单调用middleware的通讯API即可实现高速多机通讯。

2.Scheduling：协调各个GPU卡，决定哪块卡计算哪一份数据，实现data parallelism和多轮迭代。

3.数据分发：根据scheduling的结果，输送训练数据到GPU卡，并实现智能的按需缓存，在运算的后台下载下一份训练数据，使得GPU不会“停工待料”。

4.模型参数更新：支持主流的模型参数更新方案，包括ASGD、MA（model averaging）等，使得单机版GPU程序把自己算出的gradients或model parameters通过简单的调用middleware API即可完成模型的更新、同步。

我们选择开发GPU多机多卡middleware，而不是一个全能的多机多卡训练工具，是基于如下的设计理念：目前deep learning的研究和工程实践方兴未艾，各种新的模型结构、训练工具层出不穷，很难有一个“one size fits all”的工具同时满足所有人的需求。例如，在图像处理领域比较流行的caffe和cuda-convnet，在LSTM模型上比较流行的CURRENNT和RNNLib，都是各有各的优势与不足，并各有各的拥趸。更有意思的时，我们了解到很多用户在使用这些open source工具时，都或多或少对它们进行了自己的改造、升级与扩充，这样就产生了无数基于这些工具的变体。

但相同的是，这些林林总总的工具的变体在处理大数据时，都有将它们变身多机版、从而提高训练速度的需求。我们的GPU多机多卡middleware就基于这样的需求来设计抽象，使得以上的程序都可以通过插入middleware较快的实现基于ASGD或MA的多机多卡训练。对于用户来说，在插入middleware后，他们此前各自基于open source工具所做的独有修改都可以得以充分保留。他们熟悉的环境、已经生成的训练测试数据、乃至单机baseline都可以复用并与新的多机版本互相参照。一句话，middleware不是给你一个新的工具，而是将你手头熟悉的工具插上多机多卡的翅膀。

我们通过GPU多机多卡middleware将我们用于语音识别的DNN、LSTM、BLSTM等单机版程序通通插上了多机多卡的翅膀，并每天在训练模型；我们用middleware帮助iDST-NLP团队将聊天LSTM模型训练变为多机，创造了一个有趣的聊天机器人；我们用middleware和YunOS同学合作，将他们的改版caffe变为多机多卡版，训练CNN进行相册分类……我们希望middleware能够插入更多的已有单机版程序，并实现更大的业务价值。