ASR项目实战-产品分析

举报
JackieAtHome 发表于 2020/06/05 23:16:19 2020/06/05
【摘要】 语音识别相关的分析。

分析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使用量、内存使用量,进而选取一个合适压力值,构建能力基线值,指导生产环境部署,以及后续的性能优化。

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

    本指标和成本相关,因此在工程实践角度,需要花费大量的时间对云服务、推断框架、模型进行打磨,持续优化,改善硬件的占用规模。



    若非注明,均为原创,欢迎转载,转载请注明来源:ASR项目实战-产品分析

    链接地址:http://www.jackieathome.net/archives/961.html


    【版权声明】本文为华为云社区用户原创内容,转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息, 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
    • 点赞
    • 收藏
    • 关注作者

    评论(0

    0/1000
    抱歉,系统识别当前为高风险访问,暂不支持该操作

    全部回复

    上滑加载中

    设置昵称

    在此一键设置昵称,即可参与社区互动!

    *长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

    *长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

    举报
    请填写举报理由
    0/200