跳到正文

流式识别与离线精修：延迟和准确率怎么取舍

DataArc 技术团队发布于 · 阅读约 7 分钟

实时字幕有两个互相拉扯的要求：话刚出口，字就要上屏；一句话说完，字又要尽量准。流式模型擅长前者，离线模型擅长后者。我们两个都用：边说边出字靠流式识别，句末再把这一句的音频交给离线模型精修，用精修结果替换原来的文字。本文讲两段结果怎样合并，界面怎样过渡，以及哪里会出错、出错时怎样退回。

1. 延迟和准确率为什么互相拉扯

流式模型要在话还没说完时给出文字，只能依据已经听到的部分，加上很短的后续上下文。但很多词要等后面几个字才能确定：同音词要看后文，数字要看单位，泰语没有空格，词在哪里断也要看后文。离线模型一次能看完整句，这些歧义大多能靠上下文消掉。

所以“更快”和“更准”其实是同一个选择：等多久再下结论。等得短，字出得快，判断依据少；等得长，依据多，用户盯着空白屏幕的时间也长。流式识别的办法是不等：先给一个暂定的结果，之后允许它被改。

延迟也要分开看。一个是首字延迟，从开口到屏幕上出现第一个字。另一个是定稿延迟，从一句话说完到它变成不再改动的文字。精修只影响后者，不会拖慢首字。

2. 三种文字：partial、final 和精修结果

  • partial：当前这一句目前听到的全部文字。每来一条新的 partial，就整条替换上一条，不是在后面追加，内容也可能是空的。已经显示的字可以被改掉。
  • final：说话人停顿大约两秒之后，服务端把这一句定稿。连接保持打开，继续等下一句。
  • 精修结果：浏览器本地一直缓存着刚发出去的音频。final 到达时，从中切出这一句并转成 WAV，交给与文件转写相同的离线识别模型，重新识别并加上标点后返回。

怎么切出“这一句”，是个实现细节：我们不向服务端要音频，而是在本地找第一次出现 1.5 秒以上静音的位置，从第一个有声的帧切到那里，前后各留一点余量，剩下的音频留给下一句。

  • partial：ผมจะส่งรายงานให้
  • final：ผมจะส่งรายงานให้ภายในวันสุก
  • 精修：ผมจะส่งรายงานให้ภายในวันศุกร์
  • 含义：我会在周五之前把报告发给你。
同一句话的几个阶段，文字为示意，用来说明机制。

这个例子里，“ศุกร์”（周五）和“สุก”（熟）读音相同。流式阶段后面还没有更多上下文时，写成哪个都有可能；整句在手之后，离线模型更容易选对。

3. 合并规则

  1. partial 整条覆盖当前句，不累加。
  2. 每个 final 成为一个有编号的句子，追加在已有的句子后面。
  3. 精修按句子编号替换，而不是按位置替换。精修回来时，后面的句子可能已经出现，也可能同时有几个精修在途，所以每个结果只改自己的那一句，谁先回来都无所谓。
  4. 精修没有结果时保留流式文字：音频不足 0.25 秒时不发请求；返回为空、请求失败、额度用完，或者超过 12 秒仍没有回来，也都保留。精修是锦上添花，不是依赖。
  5. 对屏幕阅读器，定稿的句子在到达时在独立的朗读区域里念一次，之后精修的替换不再重复朗读，避免同一句听两遍。

4. 界面过渡：从蓝色到主色

三个状态对应三种样子：

  • 正在说的一句是蓝色，末尾带闪烁的光标。
  • 已经 final、精修还没回来的句子仍是蓝色。
  • 精修回来（或者放弃）之后，文字替换，颜色用约 0.8 秒渐变成主色。

颜色表达的是“确定程度”，而不是“句子类型”。读者看到蓝字，知道它可能会变；看到主色，知道它不会再变。如果文字被悄悄换掉而没有任何信号，读者会以为自己看错了。

动的只是颜色，不是版面。字幕区只显示最近几行，旧句子自然滚出视野，所以被改动的永远是屏幕上最新的一两句，读者的视线本来就停在那里。系统设置了减少动画时，光标不再闪烁。

5. 会出错的几种情况

  • 客户端和服务端对“一句”的切法不一致。服务端按它自己的静音判断定稿，客户端按 1.5 秒静音切音频。句子中间有较长停顿，或者服务端在连续说话中间切开时，精修的音频可能多一截或少一截。更稳妥的办法是用服务端返回的句子起始时间来对齐，这需要先确认两端的时间在重连之后仍然一致，目前我们按停顿切。
  • 连续说很久不停。本地只缓存最近 30 秒的音频，更长的句子，开头那段不会进入精修，精修结果可能少掉句首。
  • 声音很轻。低于底噪阈值的帧不算有声，整句可能被当成静音，没有音频可精修，保留流式文字。
  • 连接中断。服务端正常关闭连接时，网页端会自动重连，连续最多三次；网络异常断开则不重连，直接提示网络错误。
  • 试用的时长上限。到时服务端用专门的关闭码通知，页面显示对应的说明，而不是笼统的“出错了”。

6. 怎么衡量

首字延迟按这个口径计：

首字延迟
= 第一个非空 partial 到达的时刻
− 第一个有声帧的起点

计时在浏览器里完成，所以包含三段：采集缓冲、网络和服务端处理。采集以 2048 个采样为一帧，一帧多长取决于浏览器的采样率：16 kHz 下是 128 毫秒，48 kHz 下约 43 毫秒。精修耗时同样是浏览器端的往返时间：编码 WAV、上传、识别、返回。服务端自己报告的处理时间会更短。

要衡量精修的收益，就得把两种结果分开算：定稿时的 final，和精修之后的文字，各自在同一个测试集上算 CER，两者的差才是精修带来的改进。只看最终字幕的准确率，分不出这一点。各项数字、测试集和硬件见公开评测页。

DataArc 技术团队

相关文章