ASR项目实战-决策点

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

实时语音识别

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

决策点

• 对开发者提供实时语音识别服务时，使用什么样的协议来传输数据。
  在实时语音识别的过程中，客户端和服务端均会主动发送数据，因此服务端需要提供一个全双工的协议，以支撑前述要求。
  业界常见的方案有gRPC和websocket。二者之间如何选择，是一个问题。需要综合考虑人员技能，实现复杂度，技术成熟度，社区和文档，开源License，交付工作量等，再做具体的选择。

• 实时识别过程，支持的语音数据的格式。
  使用设备录制语音数据时，默认产生的是PCM格式的数据。考虑到对语音数据做压缩和解压缩操作会引入额外的资源、时间的消耗，因此一般情况下直接传输PCM格式的语音数据。仅当资源、代价满足要求时，可以考虑使用比如OPUS编码来对语音数据做处理。

• 客户端向服务端发送语音数据时，每个分段的时长，如何确定。
  客户端和服务端之间通信时，需要考虑底层数据传输时的RTT，对用户体验的影响。数据传输时的RTT，一般与通信双方之间的距离，以及传输路径中的网络设备相关。为简化问题，可先只考虑通信距离对RTT的影响。
  假如语音数据分段的时长过短，传递一定量的语音数据时，会引入较多次的交互，此时RTT对首字时延影响较为明显，将导致首字时延明显变长；但有助于缩短尾字时延。
  假如语音数据分段的时长过长，传递一定量的语音数据时，相对会减少交互次数，此时RTT对首字时延的影响不明显；但对于尾字时延的影响比较明显，导致尾字时延变长。

• 实时语音识别，长时间的识别比如时长超出5分钟，应当如何实现。
  可行的方案，比如：

  • 服务端提供短时间（比如X分钟）内的服务能力，客户端每隔一定时间，自动断开通信链接，重新建立会话。
  • 服务端提供长时间（比如大于X分钟，小于Y小时）的服务能力，客户端和服务端之间保持链接。

• 客户端与服务端之间创建识别会话之后，服务端如何判定客户端已经失效。
  可行的方案：

  • 客户端定期向服务端发送心跳消息，服务端记录心跳的收到时间，假如服务端在一定时间内没有收到心跳消息，则服务端判定客户端已失效。
  • 服务端记录语音数据的收到时间，假如一定时间内没有收到语音数据，则判定客户端已失效。

• 客户端如何确定语音识别的会话可以关闭。
  可行的方案，比如：

  • 客户端提供界面操作入口，供使用人主动关闭识别。
  • 服务端在识别过程中，基于VAD实现静音检测能力，当检测到静音时，反馈给客户端，由客户端来决定是否关闭识别会话。

• 服务端如何确定语音识别的会话可以关闭。
  在实时识别的过程中，客户端和服务端之间需要保持长链接，为了避免无效客户端或者非法客户端等占用服务端的资源，因此服务端需要有办法检测识别会话是否有效。对于无效的会话，需要及时关闭，降低对服务端资源的占用。可行的方案，比如：

  • 如前所述，通过检查客户端和服务端之间的心跳消息和语音数据的收到时间，当长时间没有交互，则服务端判定识别会话可以关闭。
  • 客户端主动通知服务端，语音识别会话可以安全关闭。

• 计费的依据。
  业界通行的方法以识别数据的时长来作为计费的依据。但具体到实际操作，如何计算时长，则存在一些选项，比如：

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

参考资料

• gRPC

• WebSocket 教程

• HTML5 WebSocket

• WebSocket

• WebSocket其实没那么难

• WebSocket实践——Java实现WebSocket的两种方式

• java WebSocket的实现以及Spring WebSocket示例代码

• 八种 WebSocket 框架的性能比较

• Netty学习之实战WebSocket框架

• Java WebSocket

• grpc-java

• gRPC-java实践

• Java 开发 gRPC 服务和客户端

• GRPC-JAVA

文件转写

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

决策点

• 服务端如何检测客户端提交的文件转写请求是否有效。
  客户端提交的请求消息中，可能包含比如文件URI、音频格式、采样率、位深、时长、文件大小、文件校验值等关键信息。由于此时并没有将文件下载到本地，因此除了常规的取值合法性校验外，其实很难做进一步的检查，比如文件是否存在，文件是否为合法的音频文件，文件的编码格式和请求中的编码格式是否一致，采样率和位深是否准确等。

• 客户端在短时间内提交大量的转写请求，服务端应当如何处理。
  不同客户端的业务量、业务高峰期可能存在比较大的差异，因此存在可能性，即某个或者某些客户端在某个特定时间段或者随机的时间段，将提交大量的请求。由于在校验请求有效性方面存在困难，因此在服务端可能会保存大量的文件转写请求的记录。这些记录中，可能包含了合法请求、无效请求等。
  服务端应对这个场景，比如可以有如下应对方案：

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

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

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

序列1可能存在的问题有：

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

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

1. 下载文件和语音转写，这两个操作可能分布在不同的机器上，因此使用客户端提交的URL完成下载文件的操作后，可能需要将音频文件提交至内部的公共存储上，保证语音转写操作的服务可以获取到语音文件。与前述序列比，本序列可能隐含了上传语音文件至内部存储、从内部存储下载文件的操作。同时增加了清理音频文件的操作。

• 转写操作的平均等待时长。
  客户端提交的语音文件中，从时长的角度看，存在长、短之分。因此这里提到的平均等待时长，从公平性角度讲，实际上要考虑两个维度，不同客户端之间的平均等待时长，不同转写任务之间的等待时长。
  如何才能保证平均等待时长相对比较短，提供比较好的业务体验，这是一个复杂的话题，涉及到不同任务的调度、排序等，值得思考。

• 文件转写操作失败的可能场景。
  一般而言，文件转写过程中包含校验任务参数、任务排队、下载文件、预处理、转写、后处理、保存转写结果。因此可能的失败情况有：

  • 请求参数校验失败。
  • 任务排队失败。属于内部错误，需要自动或者人工恢复。
  • 下载文件失败。对于文件提供方的问题，需要由客户端来修复。对于网络因素，则需要考虑人工恢复。对于文件大小超出预期，则需要由客户端来修复。
  • 预处理失败。比如转换音频编码、重采样、提取音频时长等操作失败，可能和文件自身特点有关，需要和客户沟通。
  • 转写失败。需要自动或者人工恢复。
  • 后处理。由于涉及对转写结果的处理，一般不会失败。
  • 保存转写结果。可以考虑自动或者人工恢复。

• 服务端执行某个文件的转写任务时，假如失败，应当如何处理。
  回答本问题，考虑因素比如有，是否重试、哪些场景需要重试、重试几次、相隔多长时间重试等。

• 文件转写的结果，如何告知客户端。
  文件转写操作的结果，通常有：

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

可行的获取方式：

* 服务端提供获取转写结果的接口，客户端主动轮询这个接口。当转写操作完成后，客户端调用接口时，服务端给出成功或者失败的结果。
* 在创建任务的请求中，客户端提供回调接口，服务端在完成转写操作后，使用回调接口，通知客户端转写结果。
* 前述两个方案的结合体。  

客户端提供回调，等待服务端使用回调接口告知转写结果。
当超出一定时间后，客户端仍然没有得到回调，此时客户端调用获取转写结果的接口，主动获取转写结果。

• 使用回调通知客户端，是否包含转写的结果。
  考虑到客户端提供的回调接口，可能不一定使用安全通道，因此一般不建议在回调时传递音频文件的转写结果。

• 文件转写任务的有效期。
  客户端创建转写任务后，即开始等待转写操作结束，获取转写结果。假如服务器接收到了过多的任务，导致任务在队列中等待的时间过长，远远超出客户端预期。此时服务端再去执行转写，已经没有意义，因为客户端可能已判定该任务失效。
  因此服务端在提供服务时，需要明确定义转写任务的有效期，避免客户端傻等，同时服务端增加必要的业务监控能力，当出现任务可能存在超期的风险时，及时通知运维扩容，增加服务端的处理能力，在有效期内完成文件转写。

• 文件转写请求的处理完成时长。
  狭义上讲，文件转写的处理完成时长仅包含转写操作自身的时长。
  广义上讲，文件转写的处理完成时长包含任务排队、文件下载、文件预处理、文件转写等操作的耗时。
  在设计方案时，需要定义好相关指标，控制好客户的预期。

• 文件转写结果的有效期。
  考虑到服务端执行文件转写任务时为异步操作，在文件转写完毕后，客户端可能无法及时获知操作已结束，进而及时获取转写结果，因此转写结果可能需要在服务端暂存一段时间。
  由于文件转写的结果为客户的数据，为保障客户的数据控制者的权力，服务端需要明示告知相关数据的保存期，提供保存期限的修改方法，删除数据的方法。另外，服务端需要提供清理相关数据的保底方案，保证超出有效期之后，文件的转写结果一定会被删除。

• 关于重复的文件转写请求。
  服务端在处理近似的请求时，将会占用硬件资源。关于本话题，包含了几方面的问题：

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

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

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

* 对于相同客户端提交的相同请求，假如已完成的任务的转写结果还在有效期，则直接返回结果。假如历史任务已超期或者失效，则针对新任务，按照正常的流程执行转写操作。
* 不同客户端之间提交了相同的文件，不能复用转写结果。

• 计费的依据。
  由于音频文件已经下载到本地，服务端可以计算得到音频文件的音频时长，因此可以直接使用音频时长来作为计费的依据。

• 计费的原则。
  转写成功后计费。理论上讲本策略没有问题，但细究起来，特定的转写请求可能会引发DOS攻击，消耗服务端的资源，同时不需要付费，比如：

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

针对前述问题，可行的应对策略：

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