Live Captioning Engineering：业界首个直播电商 AI 实时字幕系统的端到端实践

在快手电商直播间，大量用户会在通勤、办公或静音环境下观看直播，声音一旦缺失，主播口中的价格、规格、优惠也随之消失。我们花了半年多时间，把”主播说话到字幕上屏”的端到端耗时从 2 秒压到 500 毫秒，字错率从 7.81% 降到 3.51%，并支撑起千万级持续并发。这篇文章是我们踩过的坑、做出的取舍，以及最后沉淀下来的一套实时 AI 工程范式。

核心结果

• 端到端耗时：1.5～2 秒 → 400～500 毫秒
• 识别准确率：CER 7.81% → 3.51%
• 分发规模：支撑千万级持续并发
• 从”识别正确”到”体验成立”，中间隔着一条跨音视频、算法、分发与客户端的实时工程链路。

序章：从一句字幕，到一整套实时系统

在电商直播间，声音不只承载内容，更直接决定成交。但实时字幕的价值并不止于”把语音转换成文字”——它是在音频通道之外，重新建立一条可阅读、可追踪的信息通路，是内容可达性能力，也是提升信息传递和交易转化效率的基础设施。

点播字幕、会议转写和翻译工具已经十分常见，看似只要把主播的声音转成文字再显示到屏幕上即可。然而真正把字幕带进电商直播间、面对海量用户和交易场景时，所需解决的问题远比想象中复杂——行业内尚未有电商直播观看端的大规模实时字幕系统真正跑通。原因在于，该场景面对的是一组相互制约的目标：识别准确率、端到端延迟、媒体同步、持续高并发和端上可读性必须同时成立。延长音频窗口有助于模型获得更完整的上下文，却会增加切句与首字延迟；提高中间结果输出频率可以让字幕更早出现，却会增加文本修订和视觉跳动；强化价格、品牌和优惠词有助于用户快速获取信息，但过度高亮又会破坏画面的信息层级。

从结果看，我们交付的不只是一个字幕功能，而是首次提出并工程化落地了面向直播场景的实时字幕工程范式——Live Captioning Engineering。它覆盖语音识别、媒体时间同步、实时分发与端侧交互等完整链路，推动快手电商率先将实时字幕从辅助功能升级为直播基础能力，并完成了业界首个电商直播间大规模实时字幕系统的落地实践。

一、我们的场景与问题

1.1 为什么电商直播间需要一套原生字幕系统

据项目同期对国内主流头部电商平台产品与公开能力的调研，市面上已有的方案多为点播字幕、主播侧字幕插件或跨语言翻译工具。我们面对的是另一个问题：面向电商直播观看端、聚焦低音量与听障场景，原生观看端、同语种、低延迟、全链路同步和千万级并发同时成立的实时字幕系统。这是业界首个在该场景下完成大规模分发和交易链路验证的方案。

“第一个”的价值不只在上线时间。它意味着团队需要自己定义端到端延迟口径、PTS 对齐方式、流式 revision 协议、级联分发拓扑和端上可读性标准，再通过多轮实验回答字幕是否真正改善用户体验。这是一整套此前不存在的工程范式。

1.2 直播字幕与点播字幕有什么不同

点播字幕可以离线生成，也有统一的播放起点；直播字幕两者都没有。电商直播间语音环境，是一个与带货交易全流程深度绑定、全时段动态变化、多维干扰强耦合的极端复杂声学场景，观众在任意时刻进房，每个人的网络缓冲、播放追帧和清晰度切换状态都不同。与此同时，流式 ASR 会持续追加、回退和修正，字幕还要以高频小消息的形式，长时间推送给大量在线用户。

“三、二、一，上链接”之类的信息具有强时效性。字幕晚一两秒出现，即使每个字都正确，也可能已经失去价值。价格、尺码、材质和优惠规则又容不得明显误识别。直播字幕因此同时受四个目标约束：准、快、齐、稳。

1.3 四个目标为什么互相牵制

• 准：

在快语速、吞音、背景音乐、多人对话、方言等复杂语音环境下也做到准确识别。

• 快：

用户感知的是整条链路，而不是模型推理的一段耗时。

• 齐：

字幕跟随用户真正播放到的媒体位置而声至字现，任何延迟都能被用户感知。

• 稳：

业务高峰持续高并发，在出现热点倾斜、慢消费和节点故障的情况时，系统仍能控制队列长度、限制故障影响范围，并在恢复后迅速回到最新状态。

这四个目标并不能分别优化。切句更长，语义可能更完整，但延迟会上升；中间结果发得更勤，字幕出现更快，但修正和跳字会增多；每位用户直接回源最容易实现，却无法承受大规模并发。项目的核心工作，就是把这些矛盾拆开，再在一条端到端链路中重新平衡。

1.4 三个结构性难题

1. 模型时间和媒体时间不一致。ASR 返回的是相对于识别会话的时间，而用户端展示必须服从实际播放 PTS。若没有统一时间线，不同进房时刻、缓冲和追帧都会让字幕漂移。
2. 单点很快不代表端到端很快。音频回源、解封装、解码、流式识别、时间戳映射、级联分发、网络传输和端上调度，任何一跳都可能成为长尾延迟来源。
3. 一次识别要服务海量用户。字幕是“一份生产、多方消费”的长时间事件流。按用户重复计算或直连源站，在连接数、机器成本和跨地域带宽上都不可持续。

二、我们的目标与设计原则

2.1 目标：让字幕在真实直播里可用

我们没有把目标写成单一 CER 或模型 RT，而是定义为端到端结果：

• 主场景端到端耗时约 400～500 毫秒。
• 字错误率低于 4%，同时关注电商黑话和品牌、材质、功效等商品关键属性。
• 支撑千万级持续并发分发，而不是只通过瞬时QPS压测。
• 字幕与播放器 PTS 同步，支持中间结果修正且不造成明显阅读跳动。
• 用户可以开启、关闭、拖动和调整字号，自动触发不能覆盖手动选择。

2.2 四条核心原则

• 统一媒体时间线。只要 AI 结果需要与直播画面同步，就先映射到 PTS，保障声字同步。
• 一份计算，多方消费。以直播间为单位在源站侧生产字幕，再通过级联网络向不同地域扩散，避免按用户重复推理。
• 把中间结果视为版本流。流式 AI 天然会修正，协议和客户端必须显式支持句子标识、版本覆盖和最终态，而不是把每次返回都当作新句。
• 验证大于单点生产。不只验证模型是否识别正确，还要逐跳验证时间、顺序、可用性和最终可读性；任何阶段未通过，都不能把问题推给下一环节。

三、总体架构：一条链路，两张平面

系统分为控制面和数据面。控制面负责任务启动、选点调度、保活、迁移和清理；数据面负责“拉流—识别—对齐—分发—渲染”的持续流转。

主播音频进入直播源站后，字幕任务只拉取纯音频，依次完成解封装、解码和流式识别；识别结果被重新映射到直播媒体 PTS，封装为房间级字幕事件；事件通过固定两级级联向边缘扩散，客户端再依据播放器 PTS 完成缓存、修正和渐进渲染。

从职责上看，这条链路可以进一步拆成四层：

• 生产层：

从源站提取音频并运行流式 ASR。

• 时间层：

把识别会话时间翻译成媒体 PTS。

• 分发层：

以房间主题聚合事件，通过二级汇聚与一级边缘扩散。

• 体验层：

由播放器驱动字幕合并、校正、吐字和清理。

源站最靠近直播媒体源，ASR 负责内容识别，分发网络负责规模化复制，播放器则掌握用户真正看到的播放进度。

四、全链路拆解分为五层

4.1 生产阶段：在源站侧尽早提取纯音频

• 最初容易想到的方案：

跟随完整音视频链路处理，或者在用户侧按需识别。前者带来不必要的视频回源和解码成本，后者会把相同直播间的计算按用户重复放大。

• 最终的选择：

字幕任务在源站侧只拉纯音频，完成解封装、音频解码和流式识别，所有观众共享一份生产结果。生产链路被抽象为可编排 Pipeline：输入、解封装、解码、ASR、序列化和输出都是独立插件，新场景只需替换或重排能力，不必复制整套服务。

• 为什么有效：

音频生产和字幕结果都在最接近直播源的位置统一完成，减少带宽和无效计算；插件化又把模型和业务场景解耦，为实时翻译、摘要和精彩时刻等能力留下复用空间。

4.2 时间对齐阶段：字幕到底听谁的

• 最初的做法：

直接使用 ASR 返回的相对时间，或尝试用服务端墙上时钟校准。短时间看似可行，但不同用户的进房时刻、缓冲和追帧会持续累积误差。

• 最终的选择：

PTS Queue。解码器输出 PCM 帧时，系统把每段音频的 PTS 和duration依次写入队列；同一批 PCM 同时送入流式 ASR。识别结果返回后，根据文本覆盖的音频时长，在队列中定位对应帧区间，得到原始直播时间线上的起止 PTS，再把句级或词级 PTS 写入字幕事件。客户端不再猜“现在应该显示哪句话”，而是由播放器 PTS 回调驱动字幕出现、追加和消失。无论用户何时进房，只要播放器和字幕使用同一条媒体时间线，就能保持声画字同步。

• 工程门禁：

队列消费必须单调；修正可以覆盖文本，但不能让时间倒退；检测到音频帧缺失、媒体时间线跳变或源站迁移时，立即丢弃旧映射并重新建立基准。

4.3 ASR 阶段：准确率不是一次调参

直播电商的难点不仅是噪声。品牌、材质、尺码、价格和直播术语高度集中，一个数字或商品名识别错误，就可能直接改变用户理解。只看通用语料上的总体 CER，很难代表真实体验。

我们把优化拆成五个抓手：动态 VAD 在出字速度与语义完整性之间调节切句；从商品和线上错例中持续挖掘热词；针对背景音乐与多人说话增强人声；使用电商直播数据做领域微调；最后把高频错例重新回流训练和评测集合。

大量无标注音频，怎样变成可用训练数据

核心方法是多教师伪标注。多个高能力教师模型对同一段行业音频分别生成候选文本，经过规范化后做字级对齐和局部融合。我们没有采用“整句选优”，因为一句话里可能同时存在正确片段和局部误识别；字级融合可以保留各模型真正有优势的部分。

局部置信度综合多模型一致性、编辑稳定性、领域词命中、上下文合理性、音频质量和模型自身置信度。高置信完整样本进入主训练，高置信局部片段用于关键词增强，低置信片段进入人工复核与bad case池。

训练分阶段推进：先降低整体错误率，再对品牌、品类、材质、尺码和数字样本加权；随后加入术语正例、负例与混淆例，兼顾召回和误触发；最后混入通用中文和跨行业数据做回归训练。任何专项优化都必须通过“通用能力不回退”的硬门禁。

4.4 分发阶段：一份生产，怎样抵达千万用户

• 最初容易低估的问题：

字幕单条消息很小，看起来只需要一条普通推送链路。但字幕频率高、持续时间长，按用户直连源站会同时放大连接数、跨地域带宽和故障影响面。

• 最终的选择：房间事件 + 固定两级级联。

系统按“直播间 × 事件类型”组织主题。字幕先进入事件源站，二级节点聚合房间事件，一级节点靠近用户并承接大量客户端连接。首位用户完成级联调度，后续用户优先复用已有主题的边缘节点。客户端使用适合单向持续推送的流式连接。事件携带递增 ID 和重试提示，支持断线续接、去重与快速恢复；字幕句子同时携带 sentenceId + revision，用于合并中间结果和最终结果。

• 为什么有效：

二级节点尽可能只维护一份房间上游事件，一级节点再按地域向用户扩散，同时减少回源数、机器成本和跨地域流量。压测也从单一 QPS 转向连接数、消息频率、消息大小和持续时长的组合模型。

级联拓扑通过 Subscription Coalescing、一致性哈希和热点 Sharding 控制房间倾斜；有界队列出现背压时，优先合并可被 revision 覆盖的 Partial，Final 始终保持最高优先级。

4.5 客户端阶段：最后500毫秒之外的体验

流式 ASR 会不断追加文字，也可能修正刚刚输出的内容；手机直播画面却只有有限的一行或两行空间。客户端若简单覆盖文本，会出现整句跳变、尾部丢失和已读内容反复回退。

端上处理流程包括：按 PTS 缓存未来短时间窗内的事件；使用 sentenceId 和 revision 合并同一句的中间态和最终态；依据词级 PTS 渐进吐字；发生修正时只更新尚未过期的句子；文本超出单行容量后，从稳定断点续显；展示、切换和缓存清理由播放器 PTS 统一驱动。

产品交互同样是技术方案的一部分。自动展示可以与媒体音量联动，但必须尊重用户手动选择；拖拽、字号和关闭状态需要记忆；关键词高亮只用于真正影响扫读的价格、优惠或商品关键属性，避免让字幕本身成为新的视觉噪声。

五、验证体系：让每一跳都可观察、可回退

5.1 延迟按每一跳治理

从主播发声到字幕出现，链路覆盖音频回源、解封装与解码、流式识别、时间戳映射、级联分发、网络传输和端上调度。只盯模型推理，很容易把真正的长尾延迟隐藏起来。

我们为字幕事件增加阶段性内部时间戳，统一观察生产发出、事件入口接收、二级转发、一级转发和端上可展示等关键节点。性能优化因此从“凭经验猜瓶颈”变成“定位哪一跳、验证哪一跳”。

主要动作包括：源站只拉纯音频；ASR 持续输出中间结果而不等待完整句；生产、事件入口和播放器之间建立专用实时链路；主题级联复用上游事件；边缘节点裁剪重复公共字段；客户端预取短时间窗并按 PTS 本地调度。

经过多轮迭代，主场景端到端耗时从约 1.5～2 秒降低到约 400～500 毫秒。这里的“端到端”指主播音频进入处理链路，直到字幕事件到达并具备客户端展示条件。

5.2 把字幕任务当作长生命周期服务

直播可能短暂无声、断播续播、迁移源站，也可能发生节点异常和客户端重连。字幕任务不能在每次抖动后都从头开始，更不能让旧字幕在恢复时集中补发、遮挡当前内容。

控制面保证任务启动和停止幂等，覆盖保活、延迟清理、故障迁移与自动拉起；数据面通过递增事件 ID、版本号、重试提示和过期策略完成去重、恢复与淘汰。短暂无声时保持会话，时间线断裂时重建基准，过旧字幕宁可丢弃，也不在恢复后追赶式补发。

5.3 三层效果门禁

技术层关注 P50/P95/P99 延迟、CER/WER、关键字段准确率、任务可用性、乱序率、恢复耗时和单位成本；体验层关注遮挡、跳字、回退幅度、声字同步、可读性和用户控制；业务层通过多轮 A/B 与反转实验观察内容理解、低音量覆盖、停留和交易链路变化。

六、我们踩过的坑

坑一：把模型识别准确率当成主要验收标准

项目早期最容易陷入的误区，是把字错率作为字幕质量的主要判断依据。CER下降当然重要，但它回答的只是“识别结果是否准确”，无法回答字幕是否在正确的时间、以稳定的形态出现在用户面前。

直播字幕本质上是一条持续修正的增量结果流。为了获得更完整的上下文，模型可以延长切句窗口，但代价是首字延迟上升；为了让字幕尽早出现，服务端可以高频输出中间结果，但客户端会看到文本不断追加、回退和改写。即使最终结果完全正确，如果“三二一，上链接！”在商品切换后才出现，或者用户刚读完的内容被大幅回退改写，这条字幕在体验上仍然有问题，最终影响转化效果。

我们后来不再孤立地优化CER，而是把字幕质量拆成一组相互制约的端到端指标：首字延迟、最终态延迟、P95/P99 尾延迟、声字偏移、单次回退长度、中间结果修订频率，以及价格、品牌、型号等商品关键属性的识别准确率。系统优化的目标，也从“生成一条正确文本”转变为“生成一条可被稳定消费的实时事件流”。

具体实现上，服务端采用动态 VAD 和增量解码尽早产出结果，并通过 sentenceId + revision + isFinal 显式表达字幕的版本语义；客户端按照单调递增的revision幂等合并，只允许改写尚未稳定的文本后缀，尽量保护用户已经阅读过的稳定前缀。字幕时间戳则统一映射到媒体 PTS，由播放器进度决定展示时机，避免识别会话时间、系统时钟和用户实际播放位置相互漂移。

带来的认知：实时字幕的交付物不仅仅是文本，而是带有时间、版本和状态语义的流式数据。模型准确率只是其中一个维度，真正需要验收的从字幕生产到最终渲染展示的全链路各节点指标。

坑二：用短请求服务的容量模型，设计长连接分发系统

最初评估字幕分发能力时，我们沿用了常规接口的思路，重点关注平均延迟和峰值QPS。实际运行后发现，这两个指标远远不够。业务高峰期通常会持续数小时，系统负载不仅取决于单位时间内发送了多少消息，还与在线连接数、消息大小、连接时长以及房间热度分布直接相关。

头部直播间的问题尤其突出。一条字幕需要同时推送给大量在线用户，如果每个客户端都直接回源，源站需要重复完成序列化和网络发送，连接数与跨地域带宽也会随在线人数快速增长。更麻烦的是客户端的消费速度并不一致，少量弱网或卡顿连接就可能拖慢共享发送队列，引发内存积压、线程阻塞，并将局部延迟逐步传导到整条链路。节点恢复期间，大量客户端集中重连，如果再叠加历史消息补发，很容易形成新的流量高峰。

为此，我们把字幕设计成房间级Topic。源站只生产一份字幕事件，L2节点负责聚合同一房间的订阅，L1节点再面向不同地域的用户完成扇出。这样既减少了源站的重复计算与回源流量，也能把头部房间带来的压力控制在相对有限的故障域内。

级联分发并不能自动解决所有问题，背压仍然需要明确的处理规则。各级节点采用有界队列，并结合Watermark和Token Bucket控制流量；当消费者持续落后时，系统会主动降采样、丢弃过期中间态，必要时断开慢连接。Final结果和仍有展示价值的事件始终保持更高优先级，避免某个慢消费者拖住整个房间的分发。

消息一致性同样采用偏务实的方案。传输层按照At-least-once设计，允许重试和少量重复；客户端通过事件ID、sentenceId 和单调递增的 revision完成幂等合并。节点恢复后，系统不会补发全部历史字幕，而是直接收敛到当前仍然有效的最新状态。对实时字幕而言，晚到十几秒的“完整数据”已经没有消费价值，保留它反而会干扰用户正在观看的内容。

相应地，容量评估也不再只做峰值QPS压测。测试模型同时覆盖连接数、房间数、消息频率、平均载荷、连接持续时间、热点集中度和故障恢复速度；延迟则拆到生产、汇聚、边缘分发和端上调度各个阶段，分别观察P50、P95和P99。

带来的认知：真正的挑战不是短时间扛住一次流量峰值，而是在高负载持续存在，并伴随热点倾斜、慢消费者和节点故障的情况下，系统仍能控制队列长度、限制故障影响范围，并在恢复后迅速回到最新状态。

七、给同行的实践清单

• 先看链路，再看模型： 不要先纠结”优化哪个 ASR 模型”，先测算清楚从主播发声到字幕上屏的完整链路和每一跳延迟，单点最优不等于端到端最优。
• 用媒体 PTS 锚定时间：统一以播放器 PTS 为字幕同步基准，不要让墙上时钟承担声画字同步；在协议设计之初就把 sentenceId、revision、最终态、事件 ID 和过期策略一并确定，避免后续返工。

• 模型优化是长期工程：动态 VAD、热词挖掘、人声增强、领域微调、错例回流需要整体持续优化，不能只做一次专项调优。
• 按房间生产，按地域扩散：一份生产多方消费，按房间生产、按主题聚合、按地域扩散，避免按用户重复计算和回源；压测同时覆盖连接数、消息频率、消息大小与持续时长，不要只看峰值 QPS。

• 三层指标逐个验收：技术层（延迟、CER、可用性）、体验层（遮挡、跳字、声字同步）、业务层（A/B、停留、交易链路）任何一层不通过，最终用户体验和业务结果都会受影响。

八、写在最后：模型能力与系统工程的双轮驱动

实时字幕表面上是”声音转文字”，本质上却是一项跨媒体、算法、分发和交互的系统工程——模型能力决定系统能听懂多少，工程能力决定这些结果能否及时、同步、稳定地抵达用户，产品体验则决定用户愿不愿意继续看。

我们最终得到的不是一个孤立字幕功能，而是一组可复用的实时 AI 基础能力：统一媒体时间线、房间级事件、可编排 Pipeline、版本化中间结果、级联分发网络和端到端可观测体系；沿用这套底座，实时翻译、直播摘要、精彩时刻和内容理解都可以建立在同一架构上。

首创的真正含义，是第一次把问题完整地定义出来。 电商直播间字幕不能复用点播字幕的离线范式，也不是在 ASR 后面拼接一个 UI——它必须是一套以媒体时间为基准、以版本化事件为语义、以级联网络为规模底座、最终由真实用户体验验收的实时系统。把模型、系统和体验放在同一条链路上持续验证，才是实时 AI 规模化落地的真正门槛，也是团队交付的、一条可以继续承载多模态交互的技术路径。

九、团队介绍

快手电商直播技术团队长期服务大规模直播场景，围绕媒体生产、实时传输、内容理解与客户端体验持续建设基础能力。本次实践是团队将AI模型能力与直播工程体系协同落地的一次系统性复盘。