ASR项目实战-架构设计

一般而言，业务诉求作为架构设计的输入。

需求清单

对于语音识别产品而言，需满足的需求，举例如下：

功能需求

文件转写。

长文件转写，时长大于60秒，小于X小时，X可以指定为5。

短文件转写，时长小于60秒。

实时语音识别。

长语音识别，时长大于60秒，小于Y小时，Y可以指定为5。

短语音识别，时长小于60秒。

支持多个语种。

其它功能需求，比如：

前处理

支持多种音频文件格式。

支持多种采样率和位深。

支持去回声和抗噪。

支持在音频文件中处理多个声道。

中间处理

支持VAD。

支持区分音频文件中的多个讲话人。

支持输出文本对应的时间偏移。

支持使用热词提高字准率。

后处理

支持输出标点符号。

支持输出拼音类语言的大、小写。

支持数字、符号的归一化处理。

非功能需求

集成多个合作伙伴。

云云对接，即将请求转发给合作伙伴开放在公网的API服务，通过公网API访问的形式集成其语音识别能力。

集成软件包，即将合作伙伴的语音识别服务部署在相同的机房内，通过内网API访问的方式集成其语音识别能力。

集成算法库，集成合作伙伴的语音识别能力。

集成算法模型，基于相同的算法库，合作伙伴提供模型，进而集成其语音识别能力。

控制并发路数。

通过接口接入的基础设施，限制并发TPS。

基于当前可用的并发路数，限制可以接入的请求数量。

基于各个应用的业务推广情况，定义并发路数的最低、最高配额，保证基本的并发路数。

基于各个应用的业务实际情况，定义调用量的最高配额，控制调用量。

支持扩容。

通过扩容硬件的方式，增加服务能力。

针对某具体应用的实际情况，通过扩容，满足其业务诉求。

针对某具体业务场景的实际情况，通过扩容，满足其业务诉求。

技术指标

文件转写场景下的时延类指标，比如

转写比，即端到端处理时长与语音文件时长的比值。这个指标不是越小越好，需结合投入的硬件成本综合考虑，定义符合预期的指标目标值。

语音识别场景下的时延类指标，比如

首字时延

尾字时延

蹦字时延

模型文件的大小，影响如下：

决定了软件包版本构建的时间、安装服务的时间、启动服务的时间，是影响版本交付效率的直观因素。

模型文件占用的空间越大，则加载模型后，进程占用的内存空间则越大。这对硬件规格和技术方案、部署方案有直接的影响。

一定载荷下可提供的并发路数。

运营类需求

支持记录具体应用使用语音识别服务的业务调用量。

支持基于调用量，对具体应用进行计费。

运维类需求

提供日志，比如：

提供业务调试日志。

提供接口访问日志。

提供监控能力。

提供对基础设施的监控，比如CPU使用率、内存使用率、硬盘使用率等，以及必要的告警。

提供对业务组件的监控，比如进程是否存在，进程的CPU、内存使用率等，以及必要的告警。

提供对关键业务指标的监控，比如当前各服务实例在用、可用的并发路数，各业务可用、在用的并发路数等。

安全类需求

在云服务API层面增加保护，比如：

提供鉴权能力。

提供参数校验能力。

抵御DOS攻击的能力。

对用户数据的管理，包括但不限于：

使用安全通道传输用户数据。

使用加密方式保存用户数据。

允许用户删除数据。

允许用户指定数据的保存周期。

用户未提供数据保存周期时，系统支持自动删除。

架构方案

基于前述举例列出的需求，整体方案中包括如下组件：

业务类组件

接入网关

安全网关

业务网关

算法服务

支撑类组件

运维服务

运营服务

开发者服务

接入网关

主要职责有：

对外提供安全协议的请求通道，比如HTTPS。

限制业务请求的速率。

基于协议规则的请求流控。

安全网关

主要的职责是对外部发来的请求进行鉴权，拦截非法请求。

当鉴权通过时，补充必要的数据字段，比如应用标识等。

业务网关

主要的职责有：

对请求消息中的字段，进行校验，从而拦截非法请求。

依据请求消息，依据一定的业务规则，选择合适的算法服务来提供服务。

依据一定的业务规则，从指定的算法服务的集群中，挑选一个实例来提供服务。

记录业务调用量。

记录计费数据。

记录必要的运维数据。

记录必要的调试日志。

基于业务规则的请求流控。

算法服务

算法服务，提供语音识别的基本能力。

依据与合作伙伴的协作方式，算法服务包含如下类型：

云云集成，请求转发至合作伙伴开放在公网的API服务。

软件包集成，合作伙伴的软件包和自有的组件部署在相同的基础设施上，算法服务与其通过内网API的方式集成。

算法库集成，使用JNI方式，算法服务集成合作伙伴提供的算法库文件。

算法模型集成，算法服务集成模型，提供服务。

运维管理服务

主要职责是供运维人员管理、分析业务系统运行情况，包含的内容比较广，比如：

软件仓库

部署管理

配置管理

运维数据管理

采集系统

离线监控系统

在线监控系统

告警系统

运营服务

主要职责是供产品、运营人员分析业务运行现状，比如：

运营数据管理

采集系统

报表系统

告警系统

开发者服务

主要职责是供开发者管理业务的运行情况，比如：

订阅服务

计费报表

技术决策点

划分业务组件中各个组件的职责时，存在一些决策点，对设计方案存在影响，因此需要深入考虑。

语音识别过程可以划分为前、中、后三阶段的处理操作，依据前述架构方案，结合业务场景，需要思考这三个阶段在分别哪个业务组件上交付。

关于前处理

对于实时语音识别，假如使用手机作为录音设备，则可以限定录制时使用的音频文件格式、采样频率、位深、声道的数量，去回声和搞噪可以交给录音设备来完成，因此不涉及复杂的前处理。

对于文件转写，则无法限定音频数据文件的录制设备、文件格式、采样频率、位深、声道数量、录制环境等，因此需要支持前处理。相关的前处理特性，可能的实现位置有业务网关或者算法服务。

假如前处理在业务网关组件上实现，则下载文件、提取音频时长、记录计费数据、记录计量数据、基于业务规则的请求流控等可以一并实现。前处理的音频文件，需要将上传至公共存储，由算法服务下载。

本方案的优点：

在业务网关层面可以实现文件有效性的检查，避免将非法文件传递至算法服务，浪费算法服务器的算力。

在业务网关层面实现基于业务规则的请求流控，提前拦截非法请求，避免浪费算法服务的算力。

本方案的缺点：

业务网关和算法服务需要通过存储服务来传递音频文件，算法服务多了一次下载文件的操作。

假如前处理在算法服务上实现，业务网关组件只需转发请求，而下载文件、提取音频时长、记录计费数据、记录计量数据、基于业务规则的请求流控等特性均需要在算法服务来实现。

本方案的优点：

只涉及一次下载文件的操作。

本方案的缺点：

算法服务组件的数量比较多，假如音频文件保存在公网的存储服务上，则均需要开放外网访问权限。

对于文件有效性的检查延迟到了算法服务组件，恶意的请求可能会占用算法服务的算力资源。

基于业务规则的请求流控延迟到了算法服务组件，同样占用了算法服务的算力资源。

关于提取音频文件中音频数据的时长，处理音频文件中多个声道，目前比较简单的方案是使用开源软件FFmpeg来实现。但这款软件存在一些问题，比如：

License非商业友好。

处理音频文件时，比较消耗CPU。

为支持某些特定的音频格式时，需要增加一些额外的编码、解码库，编译FFmpeg的过程比较曲折。此外，音频格式涉及到的开源软件，其License可能非商业友好。此外，部分项目的代码比较旧，长期无人维护，遇到问题时会比较尴尬。

偶尔会不稳定，对音频文件执行操作时会失败，但事后使用相同的音频文件重现问题时，发现问题无法复现。

关于后处理

语音识别的结果中没有标点符号，作为书面形式阅读时会增加很多障碍，不同的句读可能会产生不同的理解，从而出现不必要的歧义。对于中文而言，这个现象尤其严重。因此为了提升可读性，需要在语音识别输出的结果进行处理，增加必要的标点符号，比如句号、逗号、探号、问号等。

对于拼音类语言，比如英语、法语等，相同的单词在不同场景下，其大小写形式可能会不同，比如the President和the president，前者指代现总统，而后者仅为泛指。为了提升可读性，需要对语音识别输出的结果进行处理，增加合理的大、小写形式。

对于数字、单位等词汇，语音识别的结果中均表示为文字，与通常使用的书面表达形式不同，阅读体验比较差，因此有必要依据一定的规则或者场景将其还原为常见的表达形式，改善阅读体验。

针对上述三个特性，决策点有：

实现方案，使用机器学习模型实现，还是使用代码基于一定的规则来实现。

实现位置，在业务网关实现，还是在算法服务实现。

架构设计 一句话识别

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。