快手直播字幕技术:400毫秒低延迟、3.5%高准确率,千万并发稳得住
的实时字幕工程范式,把直播字幕这件事从能出字推进到了实时出、准出字。降到3.51%,背后还要撑住千万级的持续并发——这在以高并发、强实时著称的电商直播场景里,第一次有了一套成体系的工程打法。四段串起来,才算完成说话—出字的闭环,任何一段拖沓都会直接体现在观众看到的延迟上。
快手团队把直播字幕从端到端的延迟时间从两秒降低到了四百毫秒, 同时把字符错误率从百分之七点八一削减到了百分之三点五一, 并且这套系统还需要经受住千万级别并发量的考验, 所以这一套被称为Live范式的做法, 实际上是电商直播场景里面第一个形成的、具备完整体系的实时字幕工程处理方案。
延迟减半背后动了什么
过去直播字幕采用的是录制完毕之后再输出的这种思路, 主播说完了一段话之后, 模型要攒够了上下文信息才肯把字吐出来, 结果呢, 观众看到字幕的时候, 主播的嘴都已经闭上好一会儿了。
快手Live这个平台, 就把整个链路改成了流式处理的方式, 声音还在播放着, 文字已经在往外推了, 就这样从“能出字”变成了“实时出字”。
400到500毫秒这样的延迟水平, 是意味着观众能够几乎和主播同时去看到那些字幕内容, 所以在电商直播里这种边说边刷的场景下面, 这个速度会直接决定观众到底能不能跟得上促销的一个节奏, 进而还会影响到最终的转化率。
四段接力各管一段
把字幕交付这个工作拆成四部分去做。第一步, 用语音识别模型把声音转变成文字。第二步, 用 PTS 对齐的方式把文本和音视频的时间戳紧紧地绑定在一起。第三步, 通过级联分发的方法把结果推送给海量的客户端。第四步, 在端侧利用渲染技术最后把字写到画面里去。把这四段流程串起来就组成了完整的闭环。
你只要是在哪个地方拖延了一点时间, 观众那边看到的延迟累积起来就会越来越严重。要是PTS没有对齐的话, 字幕和人张嘴的形状就对不上, 大概会有半拍那么大的差距。
分发链路里面只要再多出一个中间节点, 那一点点在毫秒级别里的优势就已经白白浪费掉了。所以说, 这四个环节中的每一个, 都必须要同时把住时间上的那些预算要求, 不能够有丝毫的马虎。
流式修订才是真难点
直播语音是连续流, 模型边听边改。前一句三二一上链接说到后半句可能被修正成三二一上链接三。系统必须分清哪句话、第几版修订、该排在时间轴哪个位置, 不能把新旧版本混在一起。
普通视频的字幕文件最终确定之后再次发布, 其实只需要修改一次并且进行覆盖就可以了。但是直播场景下的处理方式却是属于那种在不断输出的同时还在不断进行修改的类型。
对于同一句话而言, 在仅仅两秒的时间段之内可能会被修订达三四次之多。针对每一次修订操作, 都必须向播放器明确传达当前的这个内容是第二个版本, 需要使用它来替换掉之前的第一个版本。在整个过程当中, 还要避免出现屏幕闪动的现象。
三件套把修订钉在帧上
我们需要锁定那一句完整的句子。我们使用Revision标记来表示已经改到了哪一版。播放器时间线决定了经过修订之后的字幕究竟会在屏幕画面的哪一帧上进行刷新。这三者必须很好地配合在一起。唯有如此,修订过的字幕才能够稳稳当当地贴合在画面上面。这样就不会出现闪烁的情况了。同时也不会发生串行错误。
如果没有了Lock, 修订的内容可能会跑偏到下一句话里去;如果没有了Revision, 新旧版本就会交替出现, 令人眼花缭乱;如果没有了时间线, 刷新的时机就无法确定, 观众看到的文字就会出现跳跃的现象。这三样东西, 缺了哪一样都不行。
千万并发不是加机器就行
在电商进行大型促销活动的时候, 同时在线的人数轻轻松松就能突破一千万大关, 而且每一个观看直播的观众都必须要能够实时地收到字幕数据流。如果我们按照一种叫做“一对一推送”的模式来设计这个级联分发系统的话, 那么网络带宽和计算机计算的开销都会直接爆掉, 从而导致系统无法运行。
为了解决这个问题, Live团队采用了分级缓存加上增量推送的技术方案, 这种方案的好处是只把那些发生变化的部分数据传输下去, 而不用把所有数据都传一遍, 这样就大大节省了资源并提高了效率。
端侧渲染这个部分也降低了要求, 针对那些性能不太好的低端手机, 系统会自己主动切换到只用静态字幕的模式, 这样的做法是宁愿损失一点点实时性的好处, 也要保住播放的流畅感觉。
这一整套系统都在运行于快手自己研发的音视频基础支撑设施上面, 为了做压力测试所定的目标是让系统的处理量达到平时最高峰值的一点五倍。
对做实时AI的团队意味着什么
很多团队在搞实时字幕的时候, 总是卡在识别准确率这个坎儿上, 于是就没完没了地去调那个模型。
但是按照Live那边的经验来说的话, 就算模型的CER已经降得非常低了, 如果工程链路里面PTS没有对齐好, 或者数据分发又多转了一手的话, 然后观众最终的体验依然是非常差的。所以说啊, 工程方面的水平才会去决定最终体验的那个下限是多少。
把流式、修订、对齐这三件重要的事情彻底讲清楚, 这比单纯地去刷那些指标要具有更大的迁移价值。无论是做会议字幕的工作, 还是做体育解说的任务, 抑或是进行播客转录的操作, 这套方法范式都能够被直接进行套用使用, 从而节省掉大量需要去踩坑所花费的时间。
你所在的团队在进行实时字幕制作的时候, 真正让人觉得最卡脖子、最困难的是哪一部分呢? 是语音识别这一步, 还是文字对齐步骤!再或者是内容分发环节? 又或者是最后的渲染工作? 欢迎在评论区跟大家聊一聊你的看法, 如果你觉得这个回答比较有用, 请记得点赞收藏转发。