ASR项目实战-决策点
针对语音识别的产品,分别记录设计、开发过程中的决策点。
实时语音识别
对于实时语音识别来说,客户端和服务端之间实时交换语音数据和识别的结果。
客户端在启动识别时,即开始发送语音数据,期望在等待较短的时间后,即收到最初的识别结果。第一段语音数据和第一个识别结果之间的时延,一般称为首字时延。
客户端在停止识别后,期望在等待较短的时间后,即收到最终的识别结果。最后一段语音数据和最后一个识别结果之间的时延,一般称为尾字时延。
决策点
- 对开发者提供实时语音识别服务时,使用什么样的协议来传输数据。
在实时语音识别的过程中,客户端和服务端均会主动发送数据,因此服务端需要提供一个全双工的协议,以支撑前述要求。
业界常见的方案有gRPC和websocket。二者之间如何选择,是一个问题。需要综合考虑人员技能,实现复杂度,技术成熟度,社区和文档,开源License,交付工作量等,再做具体的选择。 - 实时识别过程,支持的语音数据的格式。
使用设备录制语音数据时,默认产生的是PCM格式的数据。考虑到对语音数据做压缩和解压缩操作会引入额外的资源、时间的消耗,因此一般情况下直接传输PCM格式的语音数据。仅当资源、代价满足要求时,可以考虑使用比如OPUS编码来对语音数据做处理。 - 客户端向服务端发送语音数据时,每个分段的时长,如何确定。
客户端和服务端之间通信时,需要考虑底层数据传输时的RTT,对用户体验的影响。数据传输时的RTT,一般与通信双方之间的距离,以及传输路径中的网络设备相关。为简化问题,可先只考虑通信距离对RTT的影响。
假如语音数据分段的时长过短,传递一定量的语音数据时,会引入较多次的交互,此时RTT对首字时延影响较为明显,将导致首字时延明显变长;但有助于缩短尾字时延。
假如语音数据分段的时长过长,传递一定量的语音数据时,相对会减少交互次数,此时RTT对首字时延的影响不明显;但对于尾字时延的影响比较明显,导致尾字时延变长。 - 实时语音识别,长时间的识别比如时长超出5分钟,应当如何实现。
可行的方案,比如:- 服务端提供短时间(比如X分钟)内的服务能力,客户端每隔一定时间,自动断开通信链接,重新建立会话。
- 服务端提供长时间(比如大于X分钟,小于Y小时)的服务能力,客户端和服务端之间保持链接。
- 客户端与服务端之间创建识别会话之后,服务端如何判定客户端已经失效。
可行的方案:- 客户端定期向服务端发送心跳消息,服务端记录心跳的收到时间,假如服务端在一定时间内没有收到心跳消息,则服务端判定客户端已失效。
- 服务端记录语音数据的收到时间,假如一定时间内没有收到语音数据,则判定客户端已失效。
- 客户端如何确定语音识别的会话可以关闭。
可行的方案,比如:- 客户端提供界面操作入口,供使用人主动关闭识别。
- 服务端在识别过程中,基于VAD实现静音检测能力,当检测到静音时,反馈给客户端,由客户端来决定是否关闭识别会话。
- 服务端如何确定语音识别的会话可以关闭。
在实时识别的过程中,客户端和服务端之间需要保持长链接,为了避免无效客户端或者非法客户端等占用服务端的资源,因此服务端需要有办法检测识别会话是否有效。对于无效的会话,需要及时关闭,降低对服务端资源的占用。可行的方案,比如:- 如前所述,通过检查客户端和服务端之间的心跳消息和语音数据的收到时间,当长时间没有交互,则服务端判定识别会话可以关闭。
- 客户端主动通知服务端,语音识别会话可以安全关闭。
- 计费的依据。
业界通行的方法以识别数据的时长来作为计费的依据。但具体到实际操作,如何计算时长,则存在一些选项,比如:- 依据语音识别的开始时间、结束时间,计算时长。本方式比较直接,与客户端和用户的实际感知一致。考虑到客户端可以在短时间内发送大量的音频数据,这将导致占用服务端过多的算力资源,但并没有收取相应的费用。
- 依据客户端发送的数据量,以字节计算,按照音频格式,还原为音频时长。考虑到客户端可以在短时间内发送大量的音频数据,本方式以服务端实际处理的音频数据量来计算时长,可以很好的规避前述异常。但在前述异常场景下,用户可能会挑战计量数据和费用账单。
参考资料
文件转写
对于时长超出1分钟的语音数据文件,业界提供转写服务时,均使用异步方案。即客户端提交文件,创建文件转写的任务,然后等待转写结束之后,再提取转写结果。完整的流程比较长,因而涉及比较多的决策点。
决策点
服务端如何检测客户端提交的文件转写请求是否有效。
客户端提交的请求消息中,可能包含比如文件URI、音频格式、采样率、位深、时长、文件大小、文件校验值等关键信息。由于此时并没有将文件下载到本地,因此除了常规的取值合法性校验外,其实很难做进一步的检查,比如文件是否存在,文件是否为合法的音频文件,文件的编码格式和请求中的编码格式是否一致,采样率和位深是否准确等。客户端在短时间内提交大量的转写请求,服务端应当如何处理。
不同客户端的业务量、业务高峰期可能存在比较大的差异,因此存在可能性,即某个或者某些客户端在某个特定时间段或者随机的时间段,将提交大量的请求。由于在校验请求有效性方面存在困难,因此在服务端可能会保存大量的文件转写请求的记录。这些记录中,可能包含了合法请求、无效请求等。
服务端应对这个场景,比如可以有如下应对方案:- 定义统一的流控策略,避免短时间内收到大量的请求。即当请求数量超出门限值时,随机放弃一部分请求,直接返回创建失败。
- 记录各客户端在一定时间内的请求量,定义流控策略。当来自某个或者某些客户端的请求数量超出门限值时,可以在一定时间段内,直接返回失败,不允许其创建新的转写任务。
- 针对特定的客户端,定义流控策略。即当特定来自特定客户端的请求数量超出门限值时,随机放弃一部分请求,直接返回创建失败。
上述应对策略中,优先级依次从低到高排列。
服务端在实现文件转写时,任务排队、下载文件,两个操作的先后顺序,可能引发的问题。
服务端在实现文件转写的过程中,可行的操作序列有:
1)校验任务、任务排队、下载文件、预处理、转写、后处理、保存转写结果。
2)校验任务、下载文件、预处理、任务排队、转写、后处理、保存转写结果。序列1可能存在的问题有:
- 客户端提交的文件的URL,可能存在有效期限的限制,因此任务可能在队列中排队时,URL已经超期,导致下载文件的操作失败。
- 考虑到服务端可能对转写任务定义了有效期,假如一定时间内服务端记录的转写任务数量过多,则任务可能在队列中排队时,即已经超期。
- 下载文件时,可能由于各种原因而失败,进而导致转写操作本身失败。
序列2可能存在的问题有:
- 下载文件和语音转写,这两个操作可能分布在不同的机器上,因此使用客户端提交的URL完成下载文件的操作后,可能需要将音频文件提交至内部的公共存储上,保证语音转写操作的服务可以获取到语音文件。与前述序列比,本序列可能隐含了上传语音文件至内部存储、从内部存储下载文件的操作。同时增加了清理音频文件的操作。
转写操作的平均等待时长。
客户端提交的语音文件中,从时长的角度看,存在长、短之分。因此这里提到的平均等待时长,从公平性角度讲,实际上要考虑两个维度,不同客户端之间的平均等待时长,不同转写任务之间的等待时长。
如何才能保证平均等待时长相对比较短,提供比较好的业务体验,这是一个复杂的话题,涉及到不同任务的调度、排序等,值得思考。文件转写操作失败的可能场景。
一般而言,文件转写过程中包含校验任务参数、任务排队、下载文件、预处理、转写、后处理、保存转写结果。因此可能的失败情况有:- 请求参数校验失败。
- 任务排队失败。属于内部错误,需要自动或者人工恢复。
- 下载文件失败。对于文件提供方的问题,需要由客户端来修复。对于网络因素,则需要考虑人工恢复。对于文件大小超出预期,则需要由客户端来修复。
- 预处理失败。比如转换音频编码、重采样、提取音频时长等操作失败,可能和文件自身特点有关,需要和客户沟通。
- 转写失败。需要自动或者人工恢复。
- 后处理。由于涉及对转写结果的处理,一般不会失败。
- 保存转写结果。可以考虑自动或者人工恢复。
服务端执行某个文件的转写任务时,假如失败,应当如何处理。
回答本问题,考虑因素比如有,是否重试、哪些场景需要重试、重试几次、相隔多长时间重试等。文件转写的结果,如何告知客户端。
文件转写操作的结果,通常有:- 转写成功,包括转写进度、转写结果等。
- 转写失败,包括失败原因、修复建议等。
可行的获取方式:
- 服务端提供获取转写结果的接口,客户端主动轮询这个接口。当转写操作完成后,客户端调用接口时,服务端给出成功或者失败的结果。
- 在创建任务的请求中,客户端提供回调接口,服务端在完成转写操作后,使用回调接口,通知客户端转写结果。
- 前述两个方案的结合体。
客户端提供回调,等待服务端使用回调接口告知转写结果。
当超出一定时间后,客户端仍然没有得到回调,此时客户端调用获取转写结果的接口,主动获取转写结果。
使用回调通知客户端,是否包含转写的结果。
考虑到客户端提供的回调接口,可能不一定使用安全通道,因此一般不建议在回调时传递音频文件的转写结果。文件转写任务的有效期。
客户端创建转写任务后,即开始等待转写操作结束,获取转写结果。假如服务器接收到了过多的任务,导致任务在队列中等待的时间过长,远远超出客户端预期。此时服务端再去执行转写,已经没有意义,因为客户端可能已判定该任务失效。
因此服务端在提供服务时,需要明确定义转写任务的有效期,避免客户端傻等,同时服务端增加必要的业务监控能力,当出现任务可能存在超期的风险时,及时通知运维扩容,增加服务端的处理能力,在有效期内完成文件转写。文件转写请求的处理完成时长。
狭义上讲,文件转写的处理完成时长仅包含转写操作自身的时长。
广义上讲,文件转写的处理完成时长包含任务排队、文件下载、文件预处理、文件转写等操作的耗时。
在设计方案时,需要定义好相关指标,控制好客户的预期。文件转写结果的有效期。
考虑到服务端执行文件转写任务时为异步操作,在文件转写完毕后,客户端可能无法及时获知操作已结束,进而及时获取转写结果,因此转写结果可能需要在服务端暂存一段时间。
由于文件转写的结果为客户的数据,为保障客户的数据控制者的权力,服务端需要明示告知相关数据的保存期,提供保存期限的修改方法,删除数据的方法。另外,服务端需要提供清理相关数据的保底方案,保证超出有效期之后,文件的转写结果一定会被删除。关于重复的文件转写请求。
服务端在处理近似的请求时,将会占用硬件资源。关于本话题,包含了几方面的问题:- 服务端是否需要检查收到了重复的文件转写请求。
- 服务端如何判断当前收到了重复的文件转写请求。
对于前述问题,当疑似重复的文件转写请求来自于不同的客户端时,同样需要思考对策。
假如客户端的来源安全可控,则简化服务端的实现,不做任务重复性的检查。
假如客户端的来源复杂,从有效利用硬件资源的角度,可以考虑增加任务重复性的检查,可行的策略,仅供参考:- 对于相同客户端提交的相同请求,假如已完成的任务的转写结果还在有效期,则直接返回结果。假如历史任务已超期或者失效,则针对新任务,按照正常的流程执行转写操作。
- 不同客户端之间提交了相同的文件,不能复用转写结果。
计费的依据。
由于音频文件已经下载到本地,服务端可以计算得到音频文件的音频时长,因此可以直接使用音频时长来作为计费的依据。计费的原则。
转写成功后计费。理论上讲本策略没有问题,但细究起来,特定的转写请求可能会引发DOS攻击,消耗服务端的资源,同时不需要付费,比如:- 服务端可以正常下载文件,但文件的信息不合法,比如文件大小超出预期,或者文件非有效音频文件(比如无法转码、重采样、提取音频时长),此时均会占用服务端的下载带宽、存储资源、算力资源。
- 算法服务在转写文件操作过程中由于数据的原因出现失败,此时将会占用服务端的算力资源。
针对前述问题,可行的应对策略:
- 在计费依据中增加对算力、存储、带宽等因素,但这将明显提升计费算法的复杂程度。
- 及时监测异常请求,对于异常请求的来源,人工介入处理,比如屏蔽请求、封停客户端等。
ASR项目实战-决策点的更多相关文章
- MVC+EFCore 项目实战-数仓管理系统1
项目背景及需求说明 这是一个数据管理"工具类"的系统,计划有三个核心功能: 1.通过界面配置相关连接字符串,查询数据库的表数据. 2.配置相关模板,生成数据库表. 可以界面填报或通 ...
- Web自动化必会知识:「Web基础、元素定位、元素操作、Selenium运行原理、项目实战+框架」
1.web 基础-html.dom 对象.js 基本语法 Dom 对象里面涉及元素定位以及对元素的修改.因为对元素操作当中涉及的一些 js 操作,js 基本语法要会用.得要掌握前端的基本用法.为什么要 ...
- Asp.Net Core 项目实战之权限管理系统(4) 依赖注入、仓储、服务的多项目分层实现
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
- 给缺少Python项目实战经验的人
我们在学习过程中最容易犯的一个错误就是:看的多动手的少,特别是对于一些项目的开发学习就更少了! 没有一个完整的项目开发过程,是不会对整个开发流程以及理论知识有牢固的认知的,对于怎样将所学的理论知识应用 ...
- 【腾讯Bugly干货分享】React Native项目实战总结
本文来自于腾讯bugly开发者社区,非经作者同意,请勿转载,原文地址:http://dev.qq.com/topic/577e16a7640ad7b4682c64a7 “8小时内拼工作,8小时外拼成长 ...
- Asp.Net Core 项目实战之权限管理系统(0) 无中生有
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
- Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
- Asp.Net Core 项目实战之权限管理系统(2) 功能及实体设计
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
- Asp.Net Core 项目实战之权限管理系统(3) 通过EntityFramework Core使用PostgreSQL
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
- Asp.Net Core 项目实战之权限管理系统(5) 用户登录
0 Asp.Net Core 项目实战之权限管理系统(0) 无中生有 1 Asp.Net Core 项目实战之权限管理系统(1) 使用AdminLTE搭建前端 2 Asp.Net Core 项目实战之 ...
随机推荐
- 文心一言 VS 讯飞星火 VS chatgpt (101)-- 算法导论9.3 7题
七.用go语言,设计一个 O(n)时间的算法,对于一个给定的包含n个互异元素的集合 S 和一个正整数k≤n,该算法能够确定 S 中最接近中位数的k个元素. 文心一言: 要设计一个 O(n) 时间的算法 ...
- Python比较字符串格式类型时间大小
已知的格式是 06/24/2021 15:47:01.491 时间比较的思路是,把数据转换成时间戳比较: 第一步是把 06/24/2021 15:47:01.491 格式转换称 2021-06-24 ...
- Ubuntu 22.04上安装docker方法及oracle 11g方法
1.切换到管理员登录 ubt2204@ubt2204-Virtual-Machine:~/database$ su Password: 2.执行安装docker命令 root@ubt2204-Virt ...
- How to Install Bugzilla on Ubuntu 20.04
In this blog post, we are going to explain in step-by-step detail on how to install Bugzilla on Ubun ...
- Java虚拟机(JVM):第一幕:起源,不一定全,但是一定靠谱
在学习JVM之前,先分享一则信息:2009 年4月20日,Orace 宣布正式以74 亿美元的价格收购市值曾超过2000 亿美元的Sun公司,传奇的Sun Microsystems 从此落幕成为历史. ...
- Dash 2.14版本开始支持动态回调注册!
本文示例代码已上传至我的Github仓库https://github.com/CNFeffery/dash-master 大家好我是费老师,就在昨晚,Dash框架发布了其2.14.0新版本,新增的功能 ...
- linux知识点 ROM,RAM,SRAM,DRAM,Flash
参考视频:https://www.bilibili.com/video/BV13L4y1b7So?spm_id_from=333.337.search-card.all.click SRAM,DRAM ...
- 3种web会话管理的方式(session)
阅读目录 https://www.cnblogs.com/lyzg/p/6067766.html 1. 基于server端session的管理 2. cookie-based的管理方式 3. tok ...
- Redis 技术整理
认识Redis Redis官网:https://redis.io/ Redis诞生于2009年全称是Remote Dictionary Server 远程词典服务器,是一个基于内存的键值型NoSQL数 ...
- 一个基于.NET7的开源DNS服务 DnsServer 的部署使用经验分享
前言 接上篇 docker-bind 的使用搭建了一个 dns 服务,本篇将介绍另外一款 DnsServer 的部署和使用,更专注,更轻量. 特点 基于 .NET 7 实现 ,支持 Windows.L ...