ASR项目实战-产品分析

这篇具有很好参考价值的文章主要介绍了ASR项目实战-产品分析。希望对大家有所帮助。如果存在错误或未考虑完全的地方,请大家不吝赐教,您也可以点击"举报违法"按钮提交疑问。

分析Google、讯飞、百度、阿里、QQ、搜狗等大厂的ASR服务,可以罗列出一款ASR服务所需要具备的能力。

产品分类

ASR云服务产品,从用户体验、时效性、音频时长,可以划分为如下几类:

  • 实时短音频转写,可以用于支撑输入法、搜索、导航等场景。
  • 实时长音频转写,可以用于支撑视频字幕、图文直播、会议直播等场景。
  • 文件短音频转写,或者一句话语音识别,可以用于支撑输入法、搜索、导航等场景。
  • 文件长音频转写,或者录音文件转写,可以用于支撑视频字幕、会议记录等场景。

产品特性

从特性上讲,一款ASR产品,在语音识别的过程,可划分为前、中、后,三个阶段,相关的特性可依据不同阶段的特点进行划分,如下是简单的说明。

前处理

在对音频进行识别前,做一些必要的准备工作,增强算法引擎的适应场景,同时减轻算法引擎的负担。

  • 多音频格式的支持
    默认情况下,算法引擎只能处理PCM格式的音频,而前端输入的音频格式多种多样,比如mp3、aac(m4a)、wma、opus等。为了处理多种多样的音频编码,增强算法引擎的适应性,增加使用场景,因此需要将输入的音频数据,转码为算法引擎支持的PCM格式。
  • 重采样
    当前主流的训练数据,采样率以16K、位深以16B居多,因此通过训练得到的引擎,只能处理采样率为前述指标的输入数据。
    输入的音频数据,采样率从8K~48K,位深以8B~24B,范围比较大,不一定能完美匹配算法引擎的要求,因此在将音频数据传递至算法引擎时,需要对音频数据进行重采样,将采样率和位深调整至算法引擎可支持的标准。
  • 多声道的处理
    对于某些特定场景下录制的音频,比如从视频中提取的音频,从会场、公开课等场景收集到的音频数据,由于录制设备存在多个源,因此天然存在多个音频channel。在将数据传递至算法引擎前,需要将多个channel的数据提取出来,分别送给算法引擎,这样才能满足识别的要求。
  • 降噪和去回声
    一般情况下,在录制设备端做这两项工作,效果、效率均有保障。
    在软件层面同样可以实施这项工作,但对处理算法的要求比较高,投入的精力较大,可能影响识别的整体工作投入。

中处理

语音识别的主要工作汇集在本阶段。

  • 语音识别
    对输入的PCM格式的音频进行处理,输出文本。本阶段针对不同的训练算法和推断框架,可能会有不同的划分。对于传统的声学模型和语言模型配合的方案,可能包含:
    • 声学特征提取,从输入的音频中按照一定的算法。
    • 将特征转换为音素的序列。
    • 使用语言发音词典,将音素的序列划分为音素的组合。
    • 语言模型,音素的组合,转换为汉字,并选择最有可能的字的序列。
  • 热词
    在特定场景下,通过使用指定的热词,可以有效的改善识别准确率。难处在于,特定的场景下,热词的数量可能会比较多,而算法引擎未必能支撑那么多。
  • 文本的时间偏移
    输出文本的同时,在字、词、句的粒度,输出开始、结束的时间偏移值。
  • 讲话人识别
    依据音频中不同讲话人的声纹特征,对音频中出现的讲话人,打上不同的标签,便于后处理环境做进一步的分析和处理,以支撑特定业务。

后处理

通常而言,狭义的语音识别不包括本阶段的工作。本阶段的工作,主要目的在于将算法引擎的输出结果,还原为对人而言具备良好可读性的文本。

  • 分词
    对于英语、法语等拉丁语系的拼音类文字,单词之间以空格分隔,这一点和中文(普通话)有非常大的不同。
  • 断句
    多数人在讲话时,不同的句子之间会使用暂停来断句。算法引擎在识别时,可以借助这个特点,对识别结果加上特征标签,便于后续处理。
  • 标点符号
    标点符号的形式和语种存在关联。
    以中文(普通话)为例,书面表达时有逗号(,)、句号(。)、问号(。)、感叹号(!)等标点符号;同样的,英语、法语等拉丁语系的拼音类文字,同样存在类似的标点符号,如逗号(!)、句号(!)、问号(!)、感叹号(!)。因此在输出识别结果时,需要专门做特殊的处理。
    针对本问题,目前了解到的解决方法有:
    • 训练一个语言模型,将标点符号一同作为特征输入到训练算法中,进而得到一个模型,可以针对输入的文本,进行断句和加标点。
      本方法在难点在于需要大量的标记数据用于训练,以及选择恰当的训练算法,进而得到有效的模型。
      另外,训练语言模型时,大量可用的语料基本为书面表达用语,因此训练得到的模型适应书面表达方式。而语音识别的输入为口语,表达方式非常灵活,因此在断句、标点时,实际效果和预期存在一定的差距。
    • 针对不同标点符号,人讲话时的停顿时长存在一定的差异。基于这个假设,可以为不同的标点符号指定停顿时长的范围,同时要求算法引擎在输出识别结果时,同步输出字、词之间的停顿时长,然后依据前述规则,将停顿时长匹配不同的标点符号。
      本方法的问题在于,只能适配简单的标点,比如逗号、句号。此外,不同讲话人的语速不同,而且在同一段录音内,讲话人的语速有可能是变化的。因此本方法的使用场景相对比较受限。但不失为一个简单、可用的方法。
  • 大、小写
    对于英语、法语等拉丁语系的拼音类文字,相同单词、不同大小写,意义可能不同,因此需要基于语言特征,对单词的大小写进行修复。
    这一点和中文(普通话)也不同。
    针对本问题,目前了解到的解决方法有:
    • 训练一个语言模型,用模型来实现大、小写的识别。本方法在难点在于需要大量的标记数据用于训练,以及选择恰当的训练算法,进而得到有效的模型。
    • 基于规则,利用前述断句和标点符号环节提供的信息,方法如下。
      • 对于句首的单词,首字母大写。
      • 利用关键字的信息,针对指定单词的大、小写的处理。
        本方案的问题在于,语言的特殊用法非常多,只能针对给定的业务场景做处理,对于通用场景,则由于投入过大、回报过低。
  • 数字归一
    数字在人类生活中无处不在,应用场景非常多。数字归一的目的是将算法引擎输出的文本中的数字,转换为原始文本中的阿拉伯数字。
    以中文(普通话)为例,假设原始文本为2019年,一般的讲法为二零一九年,算法引擎正常时,识别的原始结果为二零一九年,归一化之后,应当修正为2019年。
    不同语种,在数字的习惯表达法上各有特点。从大类上讲,一般可以划分为如下几类:
    • 连续数字,对应电话号码、社保号码等。
    • 车牌号码、火车车次、飞机航班编号等。
    • 计算机类用语,比如IP地址、邮箱地址、URL地址等。
    • 带有量词的数字。
    • 数学公式、物理公式。
    • 日期、时间。
      不同的语言有各自特殊的表达方式。比如1:58,英语里可以表达为two to two,算法引擎和后处理均需要对这种情况做特殊的处理,否则归一化无法正常工作,得不出正确的结果。
    • 习惯表达法。
      比如2000,一般的读法为两千,少有人会读为二千,但对应的阿拉伯数字均为2000。
      又比如1800,多数人的讲法为一千八,少部分人会读为一千八百,但归一化后的结果都应为1800。
    • 特殊场景。
      以中文为例,成语、诗句、年号、歇后语、俗语等中存在大量的数字,而这部分数字,一般不应转写为阿拉伯数字。
  • 语速检测
    类似于输入法提供的输入速度的检测,输出一段时间内,讲话的平均语速。
    语速和语种、讲话人强相关。比如对于使用中文(普通话)的人群来说,每秒钟一般2~4个字。
  • 情绪检测
    在特定场景下,需要从音频中提取到讲话人的情绪的特征。
    人的情绪,分类方法有很多种,因此这个判定主观性很强,一般从使用场景出发,对识别结果进行判别。

NLP

通常的语音识别产品一般不包含本阶段。

  • 敏感词
  • 基于语义的校正
    • 标点符号
    • 大、小写
    • 数字归一
    • 文本
  • 语义识别
    将人的语音,转换为某种设备的行为,比如智能音箱的开机、关机、播放等。
  • 情绪检测
    结合语言、语速等信息,

评价指标

评价ASR云服务准确率的指标,比如

  • 字错率,WER
  • 句错率,SER

处理时延

  • 对于实时语音识别,可细化为
    • 首字时延。
    • 蹦字时延,包括平均值,最大值,方差等。
    • 尾字时延。
  • 对于文件转写,可细化为实时率,即处理时长/音频时长 * 100%

单路请求场景下的指标,比如

  • 处理时延
  • 硬件资源占用情况,比如
    • CPU占用率
    • 内存占用率
      在一定的并发场景下,考核
  • 处理时延
  • 并发路数
  • 硬件资源占用情况,比如
    • CPU占用率
    • 内存占用率

准确率的指标

本指标通常用于对ASR的模型进行评估。
常用指标为WER,包括插入错误、删除错误、多字错误,指标值的计算方法为三类错误数量总和与字数的比值。从定义可知,本指标可能会超出100%,此时的语音识别系统完全不具备可用性。
业界也有场景可能会使用到SER,原理类似。
WER是一个相对的指标,和测试集强相关。当测试集和训练集同分布,则指标会比较好看;当测试集和训练集的特征有差距时,则指标可能会让人很失望。
在项目实战时,可以依据通用场景、特定领域场景来分别构建测试集合,进而对ASR模型进行打分。

衡量一个语音识别系统是否具备商用的条件,通常可以使用如下指标值来度量:

  • 通用测试集,WER小于10%。
  • 特定领域测试集,WER小于5%。
  • 客户给定的测试集,WER小于2%。

处理时延

对于实时音频识别,目前业界通常基于流式通信协议如websocket来实现客户端和云服务端之间的全双工通信。在客户角度观察,可以计算的指标有首字时延、蹦字时延、尾字时延。

  • 首字时延,计算方法为第一个响应的时间点和第一个数据请求的时间点,二者之间的时间差。
  • 蹦字时延,计算方法为两次响应之间的时间差,求平均值、最大值和方差。
  • 尾字时延,计算方法为最后一个响应的时间点和最后一个数据请求的时间点,二者之间的时间差。

注意:

  • 前述计算方法仅供参考,不同的项目、不同的测试集,可能要求会有不同。
  • 使用流式通信协议传输数据时,不同的数据分片大小,网络RTT时间,均可能对前述指标值产生影响。
  • 为便于分析产品的业务体验,同时制订合理的配置参数,需要在客户端和云服务端同时计算上述指标。

对于音频文件转写的场景,上述指标并不重要,一个名为实时率或者转写比的指标更加重要。

  • 实时率,计算方法为转写音频文件花费的时间和音频文件总时长之间的比值。

并发能力

由于音频数据的识别需要花费时间,因而传统业务的TPS指标并不适合此类场景,因此需要定义单独指标用于说明ASR云服务产品的并发能力,即并发路数,表示同一时间点,允许同时活动的会话的数量。
一般而言,本参数对于给定的单台比较有意义,不同的模型和推断框架,在不同的硬件之上得到的数据,没有可比性。

硬件资源

在给定的硬件设备上,CPU、内存、总线、IO等能力已固化,在给定的压力下,可以验证ASR云服务、推断框架、模型在负载场景下,占用的CPU使用量、内存使用量,进而选取一个合适压力值,构建能力基线值,指导生产环境部署,以及后续的性能优化。

需要说明的是,本分类下的指标,在实际验证时,和测试集也有相关性。因而不同测试集下给出的测试结果,只具有参考意义,没有可比性。

本指标和成本相关,因此在工程实践角度,需要花费大量的时间对云服务、推断框架、模型进行打磨,持续优化,改善硬件的占用规模。文章来源地址https://www.toymoban.com/news/detail-764269.html

到了这里,关于ASR项目实战-产品分析的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处: 如若内容造成侵权/违法违规/事实不符,请点击违法举报进行投诉反馈,一经查实,立即删除!

领支付宝红包 赞助服务器费用

相关文章

  • ASR项目实战-架构设计

    一般而言,业务诉求作为架构设计的输入。 对于语音识别产品而言,需满足的需求,举例如下: 功能需求 文件转写。 长文件转写,时长大于60秒,小于X小时,X可以指定为5。 短文件转写,时长小于60秒。 实时语音识别。 长语音识别,时长大于60秒,小于Y小时,Y可以指定为

    2024年02月04日
    浏览(43)
  • ASR项目实战-数据

    使用机器学习方法来训练模型,使用训练得到的模型来预测语音数据,进而得到识别的结果文本,这是实现语音识别产品的一般思路。 本文着重介绍通用语音识别产品对于数据的诉求。 相关要求,如下: 地域,需要覆盖使用人群所在的地域,且数据的比例适中。 口音,需要

    2024年02月04日
    浏览(41)
  • ASR项目实战-决策点

    针对语音识别的产品,分别记录设计、开发过程中的决策点。 对于实时语音识别来说,客户端和服务端之间实时交换语音数据和识别的结果。 客户端在启动识别时,即开始发送语音数据,期望在等待较短的时间后,即收到最初的识别结果。第一段语音数据和第一个识别结果

    2024年02月04日
    浏览(50)
  • ASR项目实战-方案设计

    对于语音识别产品的实施方案,给出简易的业务流程,仅供参考。 如下流程图,可以使用如下两个站点查看。 web chart Web Sequence Diagrams 创建文件转写任务 执行文件转写任务 获取转写结果 有两个方案,分别如下。二者差别,比如: 在语音识别的过程中,语音数据是否需要经

    2024年02月04日
    浏览(41)
  • ASR项目实战-构建Kaldi

    软件清单如下: bzip2 python3 automake libtool cmake gcc g++ gfortran git subversion 不同平台安装软件的方式不同,比如可以使用 yum 或者 apt-get 等。 软件清单如下: Libunwind glog OpenFST OpenBLAS Kaldi 按照一定的规则,将下载后的文件放在指定目录,如下是样例 build.sh 的内容,如下为样例:

    2024年02月04日
    浏览(40)
  • ASR项目实战-前处理

    本文深入探讨前处理环节。 首先介绍一些基本的名词,比如 文件名后缀 文件格式 音频格式 采样率和位深 常见的音频文件,比如 .wav 、 .mp3 、 .m4a 、 .wma 等,这些都代表什么? 仅仅是这类音频文件的后缀而已,不一定和音频文件的编码、音频数据的编码相关。 举例说明:

    2024年02月04日
    浏览(45)
  • ASR项目实战-交付团队的分工

    对于通常的软件项目,参与角色,比如可以有用户,消费者,产品团队,研发团队(研发团队包括开发和测试),运营团队,运维团队,管理团队。 通常认为,用户,负责购买服务的群体,而消费者,负责使用业务的群体。这两个群体,不在本文的讨论范围之内,因此后续的

    2024年02月04日
    浏览(35)
  • ASR项目实战-交付过程中遇到的内核崩溃问题

    当前参与交付的语音识别产品服务,算法模块基于经典的Kaldi,算法中的一部分运行在GPU之上。 算法团队采用的是声学模型+语言模型的1-pass方案。这个方案的特点在于,语言模型数据文件(HCLG文件)的大小,和训练语料的丰富程度正相关,即语言文本的语料越多,经过训练

    2024年02月03日
    浏览(69)
  • ASR项目实战-交付过程中遇到的疑似内存泄漏问题

    基于Kaldi实现语音识别时,需要引入一款名为OpenFST的开源软件,本文中提到的内存问题,即和这款软件相关。 考虑到过程比较曲折,内容相对比较长,因此先说结论。 在做长时间的语音识别时,集成了Kaldi和OpenFST的进程将会占用远超出预期的内存,这个现象可能和OpenFST、

    2024年02月03日
    浏览(63)
  • ASR项目实战-任务队列在文件转写特性中的应用

    转写时长超出60秒的语音文件,业界的竞品通常会使用创建异步转写任务的方式来提供支持。 一个简单、直接的实现方案,即: 网关服务接收到来自客户的转写请求时,将任务信息持久化至任务队列中。 由算法服务的实例从任务队列中提取任务,并执行转写操作。 待执行完

    2024年02月04日
    浏览(63)

觉得文章有用就打赏一下文章作者

支付宝扫一扫打赏

博客赞助

微信扫一扫打赏

请作者喝杯咖啡吧~博客赞助

支付宝扫一扫领取红包,优惠每天领

二维码1

领取红包

二维码2

领红包