导读： 5月20日-5月22日，第十三届中国系统架构师大会(SACC2021)在云端以网络直播的形式成功举行。会议的主题为“数字转型、架构重塑”，聚焦业务架构演进、分布式存储、音视频技术、云技术、信息安全等多个领域，云集了国内CTO、研发总监、高级系统架构师、开发工程师和IT经理等技术人群共同参与。

58同城AI Lab架构师王焱受邀出席，并在音视频技术与应用最佳实践专场以《58同城流式语音识别引擎实践》为主题进行了分享。

文本根据分享实录整理而成，欢迎大家阅读分享。

背景

语音是58同城用户之间的重要沟通媒介，58同城C端用户和B端商家之间可以通过网络音视频通话、电话建立连接。58同城数千名销售和客服人员会通过呼叫中心与客户进行电话沟通，这些场景下会产生大量的语音数据，这些语音数据可以通过语音识别技术转换为文本，并做进一步挖掘，以提取有价值的数据。流式语音识别，可以实现“边说话边出转写结果”的功能，应用在与B端商家或者C端用户的语音交互的场景中。语音交互中的服务系统可以“实时”的获取对端用户的转写结果，更快速的进行下一轮的预测、判别，为交互的时效性、流畅度提供重要支持。

举例来说，在与B端商家或者C端用户进行语音沟通时，除了人工销售、客服人员，也使用语音机器人(参见: 人机语音对话技术在58同城的应用实践)进行电话语音沟通。在电话语音沟通的过程中，使用流式识别将对端的语音数据实时转写为文本，以进行意图识别、问题匹配等，然后根据不同意图选择不同的回复内容。

总体架构

流式语音识别引擎的整体架构如下:

(1) 接入层：包含了IOS/Android/Java SDK作为接入调用接口。接入层和语音识别服务建立全双工长连接通信，完成协议交互。

(2) 逻辑层：主要包含语音接入服务、静音检测服务、以及实时语音解码服务。完成和SDK在连接生命周期的协议交互，以及实时解码功能。流式语音识别引擎底层采用开源的语音识别框架Kaldi作为模型训练和解码器的基础。服务中会调用ABTest服务，用于不同模型的效果对比。静音检测服务的模型部署在58自研的WPAI人工智能平台上。

(3) 数据层：服务相关的配置存储在MySQL中，音频文件存储在58自研的音视频存储中间件WOS中，转写结果存储在58自研的KV存储中间件WTable中，Hive用于数据的聚合统计。

流式语音识别的整体流程

了解流式语音识别的整体流程，有助于了解流式语音识别引擎各个部分是如何协作，获取转写结果的。流式语音识别分为握手鉴权、识别开始、识别进行中、识别结束四个阶段。

握手鉴权阶段，客户端调用SDK，发送语音识别请求；语音接入服务，收到请求后，进行鉴权和并发控制，如果是合法的请求就建立连接。

识别开始阶段，客户端发送识别开始状态，服务端通过ABTest服务获取到要调用的模型版本号。语音识别状态为识别开始。

识别进行中阶段，客户端开始发送语音数据流，语音接入服务调用VAD人声检测服务，检测到人声的开始，开始调用实时语音解码服务进行解码。语音识别状态为识别进行中。语音解码服务将语音数据流解码为文本，实时返回给语音接入服务，再返回给客户端。语音识别状态为识别进行中。

识别结束阶段，客户端一句话的语音数据流发送完毕，语音接入服务结束实时解码服务的调用，实时解码服务将一句话的完整结果返回给语音接入服务。语音接入服务返回给客户端。语音识别状态为句子识别结束。客户端结束语音识别的调用，语音接入服务收到信令后，结束和实时解码服务的连接，释放资源。语音识别状态为识别结束。

流式语音识别服务，经过SDK和语音接入服务的交互，通过实时语音解码服务获取转写的结果，最后对转写的句子进行后处理加标点，再返回给调用方。

接入层SDK

接入层SDK，主要是鉴权加密、建立连接，处理服务端返回的事件，以及完成事件对应的回调。

事件，即服务协商好的关于识别的状态，回调就是对于不同识别状态的处理。比如识别开始，即注册一系列的回调函数，在接收到服务端确认消息后，回调函数通知调用方。

流式识别引擎核心功能

流式语音识别引擎的核心功能包括语音接入(交互)服务、静音检测服务、实时语音解码服务。这里重点讲解语音接入服务、实时解码服务。

**语音接入(交互)服务 **

语音接入服务的功能，是实现和客户端SDK建立连接，完成和客户端SDK的协议交互；与实时解码服务建立连接和交互，获取到转写的中间结果，和最终识别结果。中间转写结果，指的是整句话结束前的转写结果。最终识别结果，指的是整句话结束后的完整的识别结果。

语音接入服务完成的主要功能有五种：

（1） 鉴权： 对每个接入的请求，通过秘钥生成的签名进行鉴权对比，只接受合法的请求。

（2）并发限制： 并发限制是保证系统可用性的一种手段，由于资源的限制，预先对每个业务方分配了最大可用并发路数，如果并发路数超过阈值，则拒绝该请求。

（3）事件和回调： 事件对应于开始、进行中、结束、失败等状态，与SDK进行协商。不同的事件对应于不同的回调函数，用于控制不同阶段的识别状态，返回不同阶段的解码结果。

（4）数据流交互： 用于处理上游SDK发送的数据，以及返回下游的实时解码服务的结果。

（5）后处理： 后处理是将实时解码出的结果，调用标点服务，添加上标点符号。

语音接入服务，还会调用ABTest服务，以及静音检测服务。按照降级分级来说， ABTest服务、后处理服务归类于低一级别的服务，而SDK、语音接入服务、实时解码服务之间的功能和交互属于高一级别的核心服务。如果系统的压力较大，低一级别的服务会作为降级选项进行调用限制，从而降低对系统的影响。

**实时语音解码服务 **

实时解码服务，是整个流式识别引擎的核心功能，完成将语音流实时“翻译”为文字的功能。实时解码服务，依赖于两个方面:模型和解码器。模型，即语音识别的声学模型、语言模型。解码器，即可以将音频特征转为文本的对象。对于流式识别引擎来说，要求解码器的转写能有较低耗时，需要毫秒级的响应，实时率越低越好。

我们是基于开源的Kaldi语音识别框架，结合业务标注数据，由算法同学离线训练出了准确率高于第三方语音识别引擎的模型，即上文说的声学模型和语言模型。声学模型，可以简单的认为是音频帧和音素的一种映射；语言模型，可以简单的认为是音素和字的一种映射。基于两个模型，即可以完成由音频帧到文字的预测。解码，是音频特征在解码网络中搜索出最优路径的过程，解码器就是完成的这个过程。解码的网络，就是声学模型和语言模型构造的网络。

实时语音解码服务的整体流程：

(1) 在服务初始化时，加载服务配置、模型，以及声学模型、语言模型，初始化N个解码器到同步队列中去。

(2) 在音频流请求到来时，取出其中的一个解码器，提取音频特征，输入模型搜索出最优路径，并将结果输出。实时解码器，不必等待整句话的音频输入完毕后进行转写，而是对流输入的音频数据进行实时转写。

实时语音解码服务，有三个基本要求：

(1) 服务应该有并发请求处理能力。并发请求是互联网微服务请求的基本特征，并发处理能够充分利用服务端资源。

(2) 服务能够达到低延时的转写要求。在并发路数一定的情况下，解码服务耗时越低，服务的吞吐量就会越大，服务调用方也能更快的处理其它业务逻辑。

(3) 能够保证解码结果的准确率。实时解码结果的准确率要保证和离线模型的准确率相近。

相对于实时解码服务的三个要求，我们的解决方法如下：

(1) 对于服务并发解码的要求，由于原生的Kaldi解码器，没有并发处理能力，不能直接作为服务处理请求。我们的解决办法是初始化了N个解码器到同步队列中去，每个请求线程独占一个解码器，解码器间互相无状态，N个解码器可以并行处理数据流。

(2) 对于服务低延时的要求，我们优化了解码的耗时，使得获取中间转写结果，以及最终转写结果的耗时有了很大的改善。这些优化如下：

  • 优化解码服务的最大并发路数，进一步提升解码效率

在介绍语音接入服务时，我们提到了并发限制，说明整个流式语音识别引擎对于并发是敏感的。我们在最开始的系统测试时，发现在系统的资源使用率不高的情况下，解码耗时随着并发路数的增加而逐步增大。

通过优化解码器参数，降低beam和lattice-beam以降低网络搜索规模、优化内存操作的分配和释放方式以减少内存碎片，降低内存操作耗时、优化解码路径选取以降低在网络中操作和搜索的耗时等，使得并发解码路数和耗时之间的关系解耦，将服务支持的最大并发路数提高了一倍。在相同测试集下的最终转写结果解码耗时，优化前平均耗时567ms，优化后平均耗时97ms。在优化解码器参数的过程中，尽可能的保证了识别的准确率，优化后相比优化前的识别准确率基本持平。

  • 优化流式语音识别获取中间转写结果的耗时

流式语音识别，是不断的输入语音流，不断产生中间结果，达到边说边出转写效果的识别系统。

在原始的解码器版本中，获取中间结果的耗时较高，并且和发送的语音时长相关，之前每次获取中间的转写结果时，都需要从头从整个lattice中搜索最优路径，耗时比较高，这里优化为从已经走过的最优路径中回溯出一条最优的路径，使得获取中间结果时不受耗时、以及发送时长的影响(发送时长越短耗时越高)。在相同测试集下获取结果时的耗时，每次发送100ms音频流，优化前平均耗时104ms左右，优化后平均耗时18ms左右，且不受发送时长的影响。

(3) 对于保证解码结果准确率的要求，经过在标准测试集上评测，实时解码结果的准确率和离线模型结果的准确率几乎相近。

流式语音识别引擎，除了解码部分的优化，�