ASR项目实战-架构设计

120 views

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

需求清单

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

功能需求

  • 文件转写。
    • 长文件转写,时长大于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 Presidentthe president,前者指代现总统,而后者仅为泛指。为了提升可读性,需要对语音识别输出的结果进行处理,增加合理的大、小写形式。

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

针对上述三个特性,决策点有:

  • 实现方案,使用机器学习模型实现,还是使用代码基于一定的规则来实现。
  • 实现位置,在业务网关实现,还是在算法服务实现。


若非注明,均为原创,欢迎转载,转载请注明来源:ASR项目实战-架构设计

关于 JackieAtHome

基层程序员,八年之后重新启航

此条目发表在 工作总结 分类目录,贴了 标签。将固定链接加入收藏夹。

发表评论

电子邮件地址不会被公开。 必填项已用*标注

Protected with IP Blacklist CloudIP Blacklist Cloud