ASR项目实战-决策点

133 views

针对语音识别的产品,分别记录设计、开发过程中的决策点。

实时语音识别

对于实时语音识别来说,客户端和服务端之间实时交换语音数据和识别的结果。
客户端在启动识别时,即开始发送语音数据,期望在等待较短的时间后,即收到最初的识别结果。第一段语音数据和第一个识别结果之间的时延,一般称为首字时延。
客户端在停止识别后,期望在等待较短的时间后,即收到最终的识别结果。最后一段语音数据和最后一个识别结果之间的时延,一般称为尾字时延。

决策点

  • 对开发者提供实时语音识别服务时,使用什么样的协议来传输数据。
    在实时语音识别的过程中,客户端和服务端均会主动发送数据,因此服务端需要提供一个全双工的协议,以支撑前述要求。
    业界常见的方案有gRPC和websocket。二者之间如何选择,是一个问题。需要综合考虑人员技能,实现复杂度,技术成熟度,社区和文档,开源License,交付工作量等,再做具体的选择。
  • 实时识别过程,支持的语音数据的格式。
    使用设备录制语音数据时,默认产生的是PCM格式的数据。考虑到对语音数据做压缩和解压缩操作会引入额外的资源、时间的消耗,因此一般情况下直接传输PCM格式的语音数据。仅当资源、代价满足要求时,可以考虑使用比如OPUS编码来对语音数据做处理。
  • 客户端向服务端发送语音数据时,每个分段的时长,如何确定。
    客户端和服务端之间通信时,需要考虑底层数据传输时的RTT,对用户体验的影响。数据传输时的RTT,一般与通信双方之间的距离,以及传输路径中的网络设备相关。为简化问题,可先只考虑通信距离对RTT的影响。
    假如语音数据分段的时长过短,传递一定量的语音数据时,会引入较多次的交互,此时RTT对首字时延影响较为明显,将导致首字时延明显变长;但有助于缩短尾字时延。
    假如语音数据分段的时长过长,传递一定量的语音数据时,相对会减少交互次数,此时RTT对首字时延的影响不明显;但对于尾字时延的影响比较明显,导致尾字时延变长。
  • 实时语音识别,长时间的识别比如时长超出5分钟,应当如何实现。
    可行的方案,比如:

    • 服务端提供短时间(比如X分钟)内的服务能力,客户端每隔一定时间,自动断开通信链接,重新建立会话。
    • 服务端提供长时间(比如大于X分钟,小于Y小时)的服务能力,客户端和服务端之间保持链接。
  • 客户端与服务端之间创建识别会话之后,服务端如何判定客户端已经失效。
    可行的方案:

    • 客户端定期向服务端发送心跳消息,服务端记录心跳的收到时间,假如服务端在一定时间内没有收到心跳消息,则服务端判定客户端已失效。
    • 服务端记录语音数据的收到时间,假如一定时间内没有收到语音数据,则判定客户端已失效。
  • 客户端如何确定语音识别的会话可以关闭。
    可行的方案,比如:

    • 客户端提供界面操作入口,供使用人主动关闭识别。
    • 服务端在识别过程中,基于VAD实现静音检测能力,当检测到静音时,反馈给客户端,由客户端来决定是否关闭识别会话。
  • 服务端如何确定语音识别的会话可以关闭。
    在实时识别的过程中,客户端和服务端之间需要保持长链接,为了避免无效客户端或者非法客户端等占用服务端的资源,因此服务端需要有办法检测识别会话是否有效。对于无效的会话,需要及时关闭,降低对服务端资源的占用。可行的方案,比如:

    • 如前所述,通过检查客户端和服务端之间的心跳消息和语音数据的收到时间,当长时间没有交互,则服务端判定识别会话可以关闭。
    • 客户端主动通知服务端,语音识别会话可以安全关闭。
  • 计费的依据。
    业界通行的方法以识别数据的时长来作为计费的依据。但具体到实际操作,如何计算时长,则存在一些选项,比如:

    • 依据语音识别的开始时间、结束时间,计算时长。本方式比较直接,与客户端和用户的实际感知一致。考虑到客户端可以在短时间内发送大量的音频数据,这将导致占用服务端过多的算力资源,但并没有收取相应的费用。
    • 依据客户端发送的数据量,以字节计算,按照音频格式,还原为音频时长。考虑到客户端可以在短时间内发送大量的音频数据,本方式以服务端实际处理的音频数据量来计算时长,可以很好的规避前述异常。但在前述异常场景下,用户可能会挑战计量数据和费用账单。

参考资料

文件转写

对于时长超出1分钟的语音数据文件,业界提供转写服务时,均使用异步方案。即客户端提交文件,创建文件转写的任务,然后等待转写结束之后,再提取转写结果。完整的流程比较长,因而涉及比较多的决策点。

决策点

  • 服务端如何检测客户端提交的文件转写请求是否有效。
    客户端提交的请求消息中,可能包含比如文件URI、音频格式、采样率、位深、时长、文件大小、文件校验值等关键信息。由于此时并没有将文件下载到本地,因此除了常规的取值合法性校验外,其实很难做进一步的检查,比如文件是否存在,文件是否为合法的音频文件,文件的编码格式和请求中的编码格式是否一致,采样率和位深是否准确等。
  • 客户端在短时间内提交大量的转写请求,服务端应当如何处理。
    不同客户端的业务量、业务高峰期可能存在比较大的差异,因此存在可能性,即某个或者某些客户端在某个特定时间段或者随机的时间段,将提交大量的请求。由于在校验请求有效性方面存在困难,因此在服务端可能会保存大量的文件转写请求的记录。这些记录中,可能包含了合法请求、无效请求等。
    服务端应对这个场景,比如可以有如下应对方案:

    • 定义统一的流控策略,避免短时间内收到大量的请求。即当请求数量超出门限值时,随机放弃一部分请求,直接返回创建失败。
    • 记录各客户端在一定时间内的请求量,定义流控策略。当来自某个或者某些客户端的请求数量超出门限值时,可以在一定时间段内,直接返回失败,不允许其创建新的转写任务。
    • 针对特定的客户端,定义流控策略。即当特定来自特定客户端的请求数量超出门限值时,随机放弃一部分请求,直接返回创建失败。

    上述应对策略中,优先级依次从低到高排列。

  • 服务端在实现文件转写时,任务排队、下载文件,两个操作的先后顺序,可能引发的问题。
    服务端在实现文件转写的过程中,可行的操作序列有:
    1)校验任务、任务排队、下载文件、预处理、转写、后处理、保存转写结果。
    2)校验任务、下载文件、预处理、任务排队、转写、后处理、保存转写结果。序列1可能存在的问题有:

    1. 客户端提交的文件的URL,可能存在有效期限的限制,因此任务可能在队列中排队时,URL已经超期,导致下载文件的操作失败。
    2. 考虑到服务端可能对转写任务定义了有效期,假如一定时间内服务端记录的转写任务数量过多,则任务可能在队列中排队时,即已经超期。
    3. 下载文件时,可能由于各种原因而失败,进而导致转写操作本身失败。

    序列2可能存在的问题有:

    1. 下载文件和语音转写,这两个操作可能分布在不同的机器上,因此使用客户端提交的URL完成下载文件的操作后,可能需要将音频文件提交至内部的公共存储上,保证语音转写操作的服务可以获取到语音文件。与前述序列比,本序列可能隐含了上传语音文件至内部存储、从内部存储下载文件的操作。同时增加了清理音频文件的操作。
  • 转写操作的平均等待时长。
    客户端提交的语音文件中,从时长的角度看,存在长、短之分。因此这里提到的平均等待时长,从公平性角度讲,实际上要考虑两个维度,不同客户端之间的平均等待时长,不同转写任务之间的等待时长。
    如何才能保证平均等待时长相对比较短,提供比较好的业务体验,这是一个复杂的话题,涉及到不同任务的调度、排序等,值得思考。
  • 文件转写操作失败的可能场景。
    一般而言,文件转写过程中包含校验任务参数、任务排队、下载文件、预处理、转写、后处理、保存转写结果。因此可能的失败情况有:

    • 请求参数校验失败。
    • 任务排队失败。属于内部错误,需要自动或者人工恢复。
    • 下载文件失败。对于文件提供方的问题,需要由客户端来修复。对于网络因素,则需要考虑人工恢复。对于文件大小超出预期,则需要由客户端来修复。
    • 预处理失败。比如转换音频编码、重采样、提取音频时长等操作失败,可能和文件自身特点有关,需要和客户沟通。
    • 转写失败。需要自动或者人工恢复。
    • 后处理。由于涉及对转写结果的处理,一般不会失败。
    • 保存转写结果。可以考虑自动或者人工恢复。
  • 服务端执行某个文件的转写任务时,假如失败,应当如何处理。
    回答本问题,考虑因素比如有,是否重试、哪些场景需要重试、重试几次、相隔多长时间重试等。
  • 文件转写的结果,如何告知客户端。
    文件转写操作的结果,通常有:

    • 转写成功,包括转写进度、转写结果等。
    • 转写失败,包括失败原因、修复建议等。

    可行的获取方式:

    • 服务端提供获取转写结果的接口,客户端主动轮询这个接口。当转写操作完成后,客户端调用接口时,服务端给出成功或者失败的结果。
    • 在创建任务的请求中,客户端提供回调接口,服务端在完成转写操作后,使用回调接口,通知客户端转写结果。
    • 前述两个方案的结合体。
      客户端提供回调,等待服务端使用回调接口告知转写结果。
      当超出一定时间后,客户端仍然没有得到回调,此时客户端调用获取转写结果的接口,主动获取转写结果。
  • 使用回调通知客户端,是否包含转写的结果。
    考虑到客户端提供的回调接口,可能不一定使用安全通道,因此一般不建议在回调时传递音频文件的转写结果。
  • 文件转写任务的有效期。
    客户端创建转写任务后,即开始等待转写操作结束,获取转写结果。假如服务器接收到了过多的任务,导致任务在队列中等待的时间过长,远远超出客户端预期。此时服务端再去执行转写,已经没有意义,因为客户端可能已判定该任务失效。
    因此服务端在提供服务时,需要明确定义转写任务的有效期,避免客户端傻等,同时服务端增加必要的业务监控能力,当出现任务可能存在超期的风险时,及时通知运维扩容,增加服务端的处理能力,在有效期内完成文件转写。
  • 文件转写请求的处理完成时长。
    狭义上讲,文件转写的处理完成时长仅包含转写操作自身的时长。
    广义上讲,文件转写的处理完成时长包含任务排队、文件下载、文件预处理、文件转写等操作的耗时。
    在设计方案时,需要定义好相关指标,控制好客户的预期。
  • 文件转写结果的有效期。
    考虑到服务端执行文件转写任务时为异步操作,在文件转写完毕后,客户端可能无法及时获知操作已结束,进而及时获取转写结果,因此转写结果可能需要在服务端暂存一段时间。
    由于文件转写的结果为客户的数据,为保障客户的数据控制者的权力,服务端需要明示告知相关数据的保存期,提供保存期限的修改方法,删除数据的方法。另外,服务端需要提供清理相关数据的保底方案,保证超出有效期之后,文件的转写结果一定会被删除。
  • 关于重复的文件转写请求。
    服务端在处理近似的请求时,将会占用硬件资源。关于本话题,包含了几方面的问题:

    • 服务端是否需要检查收到了重复的文件转写请求。
    • 服务端如何判断当前收到了重复的文件转写请求。

    对于前述问题,当疑似重复的文件转写请求来自于不同的客户端时,同样需要思考对策。

    假如客户端的来源安全可控,则简化服务端的实现,不做任务重复性的检查。
    假如客户端的来源复杂,从有效利用硬件资源的角度,可以考虑增加任务重复性的检查,可行的策略,仅供参考:

    • 对于相同客户端提交的相同请求,假如已完成的任务的转写结果还在有效期,则直接返回结果。假如历史任务已超期或者失效,则针对新任务,按照正常的流程执行转写操作。
    • 不同客户端之间提交了相同的文件,不能复用转写结果。
  • 计费的依据。
    由于音频文件已经下载到本地,服务端可以计算得到音频文件的音频时长,因此可以直接使用音频时长来作为计费的依据。
  • 计费的原则。
    转写成功后计费。理论上讲本策略没有问题,但细究起来,特定的转写请求可能会引发DOS攻击,消耗服务端的资源,同时不需要付费,比如:

    • 服务端可以正常下载文件,但文件的信息不合法,比如文件大小超出预期,或者文件非有效音频文件(比如无法转码、重采样、提取音频时长),此时均会占用服务端的下载带宽、存储资源、算力资源。
    • 算法服务在转写文件操作过程中由于数据的原因出现失败,此时将会占用服务端的算力资源。

    针对前述问题,可行的应对策略:

    • 在计费依据中增加对算力、存储、带宽等因素,但这将明显提升计费算法的复杂程度。
    • 及时监测异常请求,对于异常请求的来源,人工介入处理,比如屏蔽请求、封停客户端等。


若非注明,均为原创,欢迎转载,转载请注明来源:ASR项目实战-决策点

关于 JackieAtHome

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

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

发表评论

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

Protected with IP Blacklist CloudIP Blacklist Cloud