一个流式语音转文字的演示版本通常做起来不复杂。接上麦克风，把音频帧发出去，再接收部分转写结果，整个过程看起来几乎是实时的。真正进入生产环境之后，情况会变得棘手得多。

生产环境与演示环境的差别

打开网易新闻 查看精彩图片

真实用户并不总是拥有稳定的网络。WebSocket 连接会断开，音频包会延迟到达，部分转写结果可能乱序返回。重新连接还可能产生重复文本。下游系统也需要一套机制来判断某段转写是否可信。一个面向生产环境的流式转写系统，必须主动处理这些故障模式。

这篇指南围绕几个关键问题展开：流式语音转文字系统如何处理音频、网络中断后如何恢复、如何在不破坏转写内容的前提下重连、如何去除重复片段，以及如何实时评估转写质量。

流式转写的基本工作方式

流式转写并不是简单的“请求—响应”流程，而是一条持续的双向连接。音频帧被发送给识别引擎，引擎处理进入的音频流，随后异步返回部分转写片段和最终转写片段。多数生产系统会采用 WebSocket 这类持久连接，以避免反复建立连接带来的开销。

一条典型链路可以描述为：麦克风采集音频帧，音频帧进入流式连接，语音识别引擎处理后，输出中间结果和最终结果片段，再由应用逻辑消费这些片段。

流式系统通常返回两类结果。一类是中间结果，它们是临时预测，适合用于实时字幕、实时界面和语音助手。随着更多音频到达，这些中间结果可能发生变化。另一类是最终结果，它们是已经确认的转写片段，应当用于存储、搜索索引、合规流程和数据分析管道。把中间结果当作最终结果使用，是造成转写体验不可靠的常见原因之一。

中断事件的处理

当连续音频流被打断时，就会发生中断。常见原因包括 WebSocket 断开、数据包丢失、服务器超时、麦克风权限变化、设备切换，以及移动应用进入后台。首先要衡量的不只是连接是否断开，还包括中断持续了多长时间。

一种实用做法是：短时间中断通常可以通过缓冲音频恢复；中等时长中断可能需要重建上下文；较长时间的中断一般应触发一次全新会话。

客户端音频缓冲有助于从临时中断中恢复。生产实现应当维护一个滚动音频缓冲，记录断开开始和结束时间，为转写片段保存时间元数据，并向应用层发送连接状态事件。元数据可以包含会话标识、片段编号、时间戳和状态标记。目标不只是重新建立网络连接，而是保持转写内容的连续性。

重连与去重

重连逻辑需要避免在恢复连接后把已经返回过的片段再次写入下游。实现时应当以片段编号和时间戳作为依据，识别已经处理过的内容。对于中间结果，重连后可以丢弃旧预测，等待新的预测到达；对于最终结果，则需要确认哪些片段已经提交，哪些尚未提交。

重复片段的来源通常有两个：一是客户端在不确定服务端是否收到时重发音频，二是服务端在连接恢复后重新发送了部分历史结果。去除重复片段的关键在于为每个片段保留稳定标识，并在应用层做幂等处理。

实时质量评估

下游系统需要判断一段转写是否可信。可以依据连接状态、音频缓冲情况、片段状态以及时间元数据来评估。例如，经历过长时间中断后产生的最终结果，其可信度可能低于连续音频流中产生的最终结果。系统可以将这些信号组合起来，为下游提供更明确的判断依据。

生产级流式语音转文字系统需要把断线、重连、去重和质量评估作为设计的一部分，而不是事后补救。只有把这些故障模式纳入处理流程，转写结果才能在真实用户环境中保持稳定和可用。