查看原文
其他

人物|王焱:58同城流式语音识别引擎应用实践

58技术 58AILab 2023-12-21

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) 对于保证解码结果准确率的要求,经过在标准测试集上评测,实时解码结果的准确率和离线模型结果的准确率几乎相近。

流式语音识别引擎,除了解码部分的优化,也有关于服务耗时,以及可靠性的一些优化,本文不再做赘述。


总结

流式语音识别引擎,已经全量替换掉了第三方的实时语音识别,在语音机器人外呼、智能问答机器人微聊等场景上都得到了落地应用。本文介绍了流式语音识别引擎的背景、总体架构、服务的核心功能以及优化。后续我们会继续落地流式语音的应用场景,对流式语音识别引擎在应用类型、服务性能上进行进一步的探索和优化。

作者简介

王焱:58同城AI Lab架构师
本文章转载自58技术公众号,欢迎关注。

推荐阅读:



58同城AI Lab简介

58同城AI Lab隶属TEG技术工程平台群,成立于2018年5月,部门前身为TEG智能推荐部,目前部门规模为60人左右,包括产品、后端、算法、数据开发人员。
AI Lab旨在推动AI技术在58同城的落地,打造AI中台能力,以提高前台业务人效、收入和用户体验。
部门介绍,具体见:58同城AI Lab部门介绍
持续招聘,具体见:58同城AI Lab招聘产品经理、开发工程师

欢迎关注部门微信公众号:58AILab


继续滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存