流式语音识别尾字丢失与增量输出异常的排查实践

一、问题背景

最近排查流式语音识别模型时，遇到两个比较影响使用体验的问题：一个是句子快结束时，最后几个字偶尔消失；另一个是模型每次返回的内容看起来正常，但客户端拼接后只剩新增片段，前面已经识别的内容没有保留下来。

这两类问题容易被归结为模型识别效果不稳定，但实际定位后会发现，问题也可能出在推理接口、流式解码、文本后处理以及客户端状态管理等环节。

例如，用户说了一句“今天下午召开项目评审会议”，最终页面可能只显示“项目评审会议”；也可能在某次输出中出现“今天下午召开项目评审会议”，而最后一个“议”没有保留下来。

如果系统只检查最终识别文本，很难直接判断是模型没有识别出来，还是识别结果在传输和拼接时被处理掉了。

因此，这次排查采用了一个比较直接的思路：利用自研 bin 模型推理工具复现问题，再沿着模型输出、文本后处理和客户端展示三个环节逐步定位。

二、先区分两类异常

1. 尾字丢失

尾字丢失通常发生在音频分块边界、流结束或结果提交阶段。

例如，模型某次返回：

今天下午召开项目评审会

下一次返回：

今天下午召开项目评审会议

如果后处理程序错误地将第二次结果当成一段全新的文本，或者在截取公共前缀时计算错误，就可能造成最后一个字被丢弃。

还有一种情况是模型本身输出不完整。比如音频分块结束得过早，解码器没有获得足够的右侧上下文，导致最后一个字没有被正确识别。

这两种情况的修复方式不同，不能简单地统一追加一个字符。

2. 只输出新增片段

假设模型在连续三个时间点返回以下结果：

第1次：今天下午
第2次：今天下午召开会议
第3次：今天下午召开会议讨论项目

如果接口返回的是完整的当前识别结果，那么客户端应该根据完整文本更新显示，而不是把每次结果直接追加到已有文本后面。

反过来，如果推理层返回的是增量片段：

第1次：今天下午
第2次：召开会议
第3次：讨论项目

客户端才应该按顺序追加。

问题的关键不是哪种返回方式更好，而是推理端和消费端必须遵循同一套协议。

三、利用自研 bin 工具定位问题

在模型效果排查过程中，单纯通过业务页面观察现象，往往无法区分模型输出异常和应用层处理异常。

自研 bin 推理工具的价值，在于尽可能绕过业务界面，直接观察模型推理链路的实际行为。

建议将调试信息分为以下几类：

如果 bin 工具支持调试参数，可以增加类似 –debug-stream 的开关。以下是建议实现的参数形式，并非某个现成推理工具的固定参数：

./asr_infer \\
–model ./model.bin \\
–audio ./test.wav \\
–debug-stream

每个分块输出一条日志，例如：

chunk=12
audio_start=24.0
audio_end=26.0
raw_text="今天下午召开项目评审会议"
final_text="今天下午召开项目评审会议"

实际参数和字段需要根据自研工具的接口调整。

排查时，首先让同一段音频分别经过离线推理和流式推理。如果离线结果完整、流式结果缺字，就重点检查分块、缓存和流结束处理；如果 bin 工具输出正常，而业务页面缺字，就继续检查接口序列化和客户端更新逻辑。

四、修复增量输出的核心逻辑

1. 不要直接按字符串长度截取

一种常见的错误写法是：

String delta = current.substring(previous.length());

这段代码只有在 current 一定以 previous 为前缀时才成立。

例如：

previous = 今天下午召开项目评审会
current = 今天下午召开项目评审会议

此时得到的增量是“议”，看起来没有问题。

但如果前一次结果是：

previous = 今天下午召开项目评审会
current = 今天下午召开项目讨论会

两段文本已经发生修订，直接按旧文本长度截取，就会产生错误结果。

因此，必须先明确模型返回的是完整文本还是增量文本。对于允许回滚修订的流式模型，还需要设计提交机制，不能仅依赖字符串长度。

2. 对稳定前缀进行增量计算

如果当前模型返回完整识别结果，可以通过公共前缀识别新增部分。下面给出一个适合基础场景的 Java 实现：

public class StreamTextUtil {

public static int commonPrefixLength(
String previous, String current) {

if (previous == null || current == null) {
return 0;
}

int max = Math.min(
previous.length(), current.length());

int i = 0;
while (i < max
&& previous.charAt(i) == current.charAt(i)) {
i++;
}

return i;
}

public static String getDelta(
String previous, String current) {

if (previous == null) {
previous = "";
}

if (current == null) {
return "";
}

if (current.startsWith(previous)) {
return current.substring(previous.length());
}

// 发生修订时，不能将当前文本简单视为纯增量。
return current;
}
}

这里需要注意：发生修订时返回完整的 current，意味着调用方必须把它当成一次文本替换事件，而不是直接追加到原文后面。

此外，Java 的 String.length() 和 substring() 使用 UTF-16 代码单元计数。对于包含部分特殊 Unicode 字符的文本，生产系统如果需要精确处理用户可见字符，还应考虑码点边界。

3. 用明确的事件协议区分追加和替换

比起让客户端猜测每次返回的内容属于哪种类型，更稳妥的做法是明确事件语义。

例如：

{
"type": "partial",
"seq": 12,
"mode": "replace",
"text": "今天下午召开项目评审会议"
}

如果返回的是新增片段，则使用：

{
"type": "partial",
"seq": 13,
"mode": "append",
"text": "讨论项目预算"
}

客户端根据 mode 选择替换或追加，并通过 seq 检查事件顺序，避免网络延迟导致旧结果覆盖新结果。

这里的 JSON 仅用于说明协议设计，实际字段应与现有服务接口保持一致。

五、尾字丢失应该怎样修复

增量输出逻辑修正后，还需要检查流结束时的文本提交机制。

对于支持修订的模型，可以将识别结果分成两部分：

• 稳定文本：已经确认，不再参与后续修订。

• 临时文本：仍可能被后续音频修正。

例如，当前识别结果为“今天下午召开项目评审会”，系统可以暂时保留句尾部分，等待下一块音频到达后再次解码。

但不能简单地把最后一个字永久删除，也不能无条件把旧结果的最后几个字重新追加，否则会制造重复文本。

建议在以下几个时机执行检查：

如果底层模型采用缓存式流式推理，还要检查最后一块音频是否满足模型的输入长度要求，以及必要的补零、右侧上下文和缓存刷新逻辑是否正确。

重点是保留模型原始输出，通过日志证明尾字在哪一步消失，再针对对应环节修复。

六、建立可重复的回归测试

这类问题很容易出现“修好了一个例子，又在另一个句子上复发”的情况，因此需要将问题音频沉淀为固定测试集。

建议至少覆盖以下场景：

下面是一个简单的增量输出单元测试示例：

import org.junit.Test;
import static org.junit.Assert.*;

public class StreamTextUtilTest {

@Test
public void testNormalAppend() {
String delta = StreamTextUtil.getDelta(
"今天下午",
"今天下午召开会议");

assertEquals("召开会议", delta);
}

@Test
public void testRevisionMustNotBeTreatedAsDelta() {
String delta = StreamTextUtil.getDelta(
"今天下午召开项目评审会",
"今天下午召开项目讨论会");

assertEquals("今天下午召开项目讨论会", delta);
}

@Test
public void testFinalCharacter() {
String text = "今天下午召开项目评审会议";

assertEquals("议",
text.substring(text.length() – 1));
}
}

最后一个测试只是字符提取示例，不能代替真实的流式尾字回归测试。实际验证还应将模型最终输出与人工校对的参考文本进行对比，并检查每次事件的拼接结果。

在实际项目中，可以将这些用例接入 CI，确保修改后处理代码时，不会重新引入尾字丢失或增量拼接错误。

七、总结

流式语音识别出现尾字丢失、只输出新增片段等问题时，不宜第一时间认定模型本身存在缺陷。模型解码、音频分块、文本后处理、接口事件协议和客户端状态管理，都可能影响最终展示。

这次排查思路的核心是利用自研 bin 推理工具缩短定位链路：先获取原始输出，再对比后处理结果，最后检查客户端拼接行为。确认问题环节后，分别修复增量计算、文本修订和结束阶段提交逻辑，并通过固定音频样本持续回归。

对于需要在本地环境运行的智能会议产品，例如熙瑾会悟，流式结果的稳定性不仅影响识别体验，也会影响会议记录的完整性。相比单纯追求更快的首字输出，保证每次文本更新语义明确、最终结果完整，同样是推理工程中不可忽视的一环。

需要说明的是，文中的代码是用于解释和验证修复思路的示例，具体实现仍需结合实际模型的解码方式和接口协议调整。