想象你坐在同声传译箱里，演讲者话音刚落，你就要把中文译进耳机。你不可能等他说完一整句话再开口，而是听到一个意群就译出一截——甚至他还没说完，你已经开始“抢跑”了。流式语音识别（ASR）做的正是这件事：它不等待完整音频，而是随着麦克风不断涌进来的声音，一边听一边吐文字。这种“边听边译”的能力，就是增量解码。今天这篇文章，我们跟着同传译员小陈的日常工作，把流式 ASR 的增量解码拆开看：怎么把声音切成小份（chunk）、怎么让注意力只看局部、怎么用 online CTC 快速记下草稿、怎么控制翻译的延迟，以及怎么训练和部署这样一个“实时嘴替”。

岗位关联

掌握流式增量解码，是搭建实时会议字幕、语音助手、直播字幕等语音产品的基础能力，也是语音算法工程师进阶绕不开的核心技能。

目录
  1. 可视化演示
  2. 流式识别基础
  3. 音频分块机制
  4. 局部注意力
  5. 在线CTC解码
  6. 延迟控制策略
  7. 流式训练优化
  8. 推理部署实践
  9. AI 应用场景
  10. Python 演示
  11. 常见误区
  12. 面试题

可视化演示

展示神经网络的前向传播信号流和反向传播梯度更新过程，可视化神经元激活、权重连接和训练循环。

本节配有交互动效（进入视口后自动加载，约 3KB）。

前向传播 红色节点为神经元，连线粗细表示权重大小 粉色光晕表示神经元激活强度，脉冲动画展示信号流动 橙色粒子沿连线流动，表示前向传播的激活信号 a^(l) = σ(W^(l) · a^(l-1) + b^(l)) 前向传播逐层计算激活值，σ为激活函数

流式识别基础

小陈刚开始做同传时，习惯等演讲者说完一整个句子再翻译，结果观众盯着他，会场安静得能听见空调声。师傅告诉他：同传不是“听完再译”，而是“边听边译”。流式 ASR 也是一样的道理——传统的离线识别像“先录完整场课再整理笔记”，而流式识别像“一边上课一边记板书”，每听到一个新片段，就立刻更新已输出的文字。

流式 ASR 的核心特征是增量输出。它不会一次性给你整句识别结果，而是随着音频流的到达，逐渐吐出 token（字或词）。这种能力在语音助手、实时字幕、电话客服等场景中至关重要，因为你不可能让用户等一句话说完才看到结果。为了实现实时，模型必须限制自己的“视野”：它只能看到当前时刻之前（以及最多一个很小的未来窗口）的音频，不能像离线模型那样对整句话做全局优化。

流式系统的实时性通常用端到端延迟来衡量。一个典型的流式识别链路，其延迟可以拆成三部分：

理解了这三部分，你就明白为什么流式识别不是越算越快越好——等待时间和计算时间需要一起平衡。小陈后来总结：好的同传不是抢在演讲者之前开口，而是在“信息足够”的那一瞬间开口。流式 ASR 的延迟控制，本质上也是寻找这个“瞬间”。

Dlatency=Dchunk+Dcompute+Dwait\displaystyle D_{\text{latency}} = D_{\text{chunk}} + D_{\text{compute}} + D_{\text{wait}}
端到端延迟等于攒音频块的时间、模型计算时间、以及解码策略故意等待的时间三者之和。
  1. D_latency（端到端延迟）用户说出一个字到界面显示出对应文字之间的总时间，通常是毫秒级。
    Dlatency\displaystyle D_{\text{latency}}
  2. D_chunk（攒块时间）模型必须攒够一个 chunk 的音频才能开始计算，就像译员要等一个意群说完才动笔。
    Dchunk\displaystyle D_{\text{chunk}}
  3. D_compute（计算时间）模型把 chunk 编码并输出候选 token 概率所花的时间。
    Dcompute\displaystyle D_{\text{compute}}
  4. D_wait（策略等待）为了避免说错话，解码策略可能故意再等几个 chunk 才确认最终文字，这部分是“延迟换准确率”。
    Dwait\displaystyle D_{\text{wait}}

音频分块机制

小陈做同译时，并不是一个字一个字地翻译，而是把连续的演讲切成一个个“意群”，每个意群大约 2~3 秒。语音信号也一样，对它来说，最基本的单位不是“字”，而是“帧”。一帧通常是一小段 20~30 毫秒的音频，模型从每一帧里提取声学特征，比如梅尔频谱。

但一帧太短，模型如果每帧都计算一次，计算量巨大且输出极不稳定。所以实际系统中会把若干帧攒成一个 chunk（块），一个 chunk 通常包含 16~32 帧，对应几百毫秒的音频。模型每处理完一个 chunk，就输出一次增量结果。分块大小直接决定了流式识别的“反应速度”：chunk 越大，模型每次看到的信息越多、准确率越高，但延迟也越大；chunk 越小，出字越快，但可能频繁改动之前的结果。

chunk 对应的实际音频时长可以由以下公式计算：

小陈把意群切得短一点，观众觉得他反应快，但偶尔会漏译细节；切长一点，翻译更完整，但反应变慢。流式 ASR 的工程师同样在调节 chunk 大小，寻找“快”与“准”之间的最佳平衡点。

Tchunk=C×hhopfs\displaystyle T_{\text{chunk}} = \frac{C \times h_{\text{hop}}}{f_s}
一个 chunk 的时长等于 chunk 内帧数乘以帧移，再除以采样率。
  1. T_chunk（chunk 时长）一个 chunk 覆盖的真实时间长度，单位是秒。
    Tchunk\displaystyle T_{\text{chunk}}
  2. C（chunk 内帧数）一个 chunk 中包含的特征帧数量，例如 16 帧。
    C\displaystyle C
  3. h_hop（帧移）相邻两帧起始点之间的时间偏移，常见 10ms。
    hhop\displaystyle h_{\text{hop}}
  4. f_s（采样率）音频每秒采样的点数，常见 16000Hz。
    fs\displaystyle f_s

局部注意力

小陈翻译时有一个习惯：他只会竖起耳朵听当前这个意群，以及前一个意群的内容，绝不会去费力回忆半小时前演讲者说过什么。这就是“局部注意力”——你不需要记住整场演讲才能翻译好当前这一句，只要抓住最近的上下文就够了。

传统 Transformer 的自注意力机制会让每个位置去关注整句话的所有位置，计算量随序列长度平方增长。流式场景不允许这样，因为未来还没到来，而且计算耗时不可控。于是出现了 chunk-aware attention：把输入序列切成 chunk，每个位置只允许关注当前 chunk 内部，以及向前看/向后看的少量相邻 chunk。这个“可关注范围”通过注意力掩码（attention mask）实现。

掩码的核心思想是：在计算注意力分数时，把不允许关注的位置的分数设为一个极大的负数，让 softmax 之后这些位置的权重变成 0。公式如下：

小陈把听力范围固定在当前和邻近意群上，翻译又快又稳。chunk-aware attention 也一样：它牺牲了对远处信息的“回忆”，换来了流式所需的实时性和可控计算量。

Attention(Q,K,V)=softmax(QKTdk+M)V\displaystyle \text{Attention}(Q,K,V) = \text{softmax}\left(\frac{QK^{\mathsf{T}}}{\sqrt{d_k}} + M\right)V
注意力权重由 Query 和 Key 的相似度决定，掩码矩阵 M 用来屏蔽“不该看”的位置。
  1. Q、K、V（查询、键、值）每个 chunk 会被编码成三种向量，Q 代表“我想找什么”。
    Q,K,V\displaystyle Q, K, V
  2. QK^T（相似度打分）每个位置与其他位置的匹配程度打分。
    QKT\displaystyle QK^{\mathsf{T}}
  3. √d_k（缩放因子）防止点积过大导致 softmax 梯度过小，让训练更稳定。
    dk\displaystyle \sqrt{d_k}
  4. M（注意力掩码）掩码矩阵中，允许关注的位置为 0，禁止关注的位置为 -∞。
    M\displaystyle M
  5. softmax + 乘 V（加权聚合）把权重归一化后，按权重汇总值向量，得到当前 chunk 的新表示。
    softmax(⋅)V\displaystyle \text{softmax}(\cdot)V

在线CTC解码

小陈手边有一本速记本，他听到关键词会立刻用符号记下来，即使语法还不完整，也不影响他先锁定这些关键信息。CTC（Connectionist Temporal Classification）正是这样一个“速记员”：它让模型在每一帧或每一个时间步，输出一个字符标签，或者一个特殊的 blank（空白）标签，表示“这一帧什么都没说”。

普通的 CTC 解码需要在整段语音结束后，把所有帧的输出对齐、去重，再得到最终文本。但流式场景需要“边听边译”，于是有了 online CTC 解码：它一边接收新的 chunk，一边更新已确认的前缀。当模型连续对某个 token 给出较高置信度时，这个 token 就被“确认”进草稿列表；blank 被跳过，重复出现的连续 token 会被合并。

online CTC 解码过程中，一个核心操作是“前缀概率更新”。假设我们已经确认了长度为 s 的前缀，在 t 时刻收到新的一帧输出 token y，则前缀概率可以近似地递推为：

小陈的速记本上，已经写下的关键词不会再被擦掉；只有那些还没写下的内容，他才会在脑中反复权衡。online CTC 解码也是这样：已确认的文字被锁定，未确认的部分随着新 chunk 不断更新概率，最终形成一份“边听边写”的实时转写稿。

αt(s)=(αt−1(s)+αt−1(s−1))⋅yt(s)\displaystyle \alpha_t(s) = \left(\alpha_{t-1}(s) + \alpha_{t-1}(s-1)\right) \cdot y_t(s)
这是前缀概率更新的简化表达：当前前缀概率，等于上一时刻保持该前缀的概率加上从更短前缀扩展过来的概率，再乘以当前 token 的发射概率。
  1. α_t(s)（当前前缀概率）到时刻 t 为止，已经识别出前 s 个 token 的累积概率。
    αt(s)\displaystyle \alpha_t(s)
  2. α_{t-1}(s)（保持原前缀）上一时刻已经达到同样的前缀，当前帧不增加新 token。
    αt−1(s)\displaystyle \alpha_{t-1}(s)
  3. α_{t-1}(s-1)（扩展前缀）上一时刻前缀还只有 s-1 个 token，当前帧新增一个 token，变成 s 个。
    αt−1(s−1)\displaystyle \alpha_{t-1}(s-1)
  4. y_t(s)（当前发射概率）模型在 t 时刻预测当前 token 为第 s 个标签的概率。
    yt(s)\displaystyle y_t(s)

延迟控制策略

小陈最怕两种局面：一种是他太着急，话还没听全就开口，结果说错被观众纠正；另一种是他太谨慎，等所有信息都齐了才开口，结果冷场。同传里这叫“抢话”和“压节奏”。流式 ASR 的延迟控制，就是在两者之间找平衡。

最简单的策略是固定窗口：每个 chunk 到达后，解码器固定等待 N 个 chunk 才输出一个最终 token。这种策略实现简单、延迟可控，但不够聪明——有时模型已经非常确定某个词，却还要傻等；有时模型还一头雾水，却被迫作出输出。更先进的策略是动态窗口：解码器根据当前模型的置信度决定是否立即输出。如果连续若干帧对同一个 token 的置信度都超过阈值，就立刻确认；否则继续等待。

在实际工程中，系统会持续监控延迟，并用指数滑动平均（EMA）平滑延迟抖动，避免因为某次偶发的计算卡顿导致整体判断失真：

小陈在实战中学会“该抢时抢，该等时等”。流式 ASR 的延迟控制也是如此：固定窗口是基本功，动态窗口是进阶技巧，而延迟预算则是保障用户体验的底线。没有一个策略是万能的，关键是理解你面对的场景：是直播字幕，还是语音助手？不同场景的延迟预算完全不同。

Lavg=α⋅Lcur+(1−α)⋅Lprev\displaystyle L_{\text{avg}} = \alpha \cdot L_{\text{cur}} + (1 - \alpha) \cdot L_{\text{prev}}
平均延迟由当前延迟和上一时刻平均延迟加权得到，α 控制对最新延迟的敏感度。
  1. L_avg（平滑后平均延迟）用于监控的稳定延迟指标。
    Lavg\displaystyle L_{\text{avg}}
  2. L_cur（当前延迟）最近一次解码的端到端延迟。
    Lcur\displaystyle L_{\text{cur}}
  3. L_prev（历史平均延迟）上一时刻计算得到的平滑延迟。
    Lprev\displaystyle L_{\text{prev}}
  4. α（权重系数）通常取 0.1~0.3，越大越关注近期波动，越小越平滑。
    α\displaystyle \alpha

流式训练优化

小陈不是天生就会同传的，他每天都要做“跟读训练”：一边听录音，一边跟着翻译，刻意训练自己在信息不完整时快速反应的能力。流式 ASR 模型也需要这样的“跟读训练”，否则训练和推理就会脱节。

很多团队一开始偷懒，用普通的离线数据训练模型，推理时再用 chunk 掩码去限制注意力。结果模型在线上表现糟糕——因为它从没见过“被遮住未来”的输入。正确的做法是训练时就模拟流式推理：在输入序列上随机施加 chunk 掩码，让模型学会在只能看到部分上下文的情况下做预测，这个过程叫“时间同步训练”或“掩码仿真”。

为了让模型在流式和离线两种模式下的表现尽量一致，还可以加入一致性正则。具体做法是：同一个输入，分别用“带 chunk 掩码”的模型和“看完整上下文”的模型计算预测分布，然后惩罚两者的差异。总的训练损失是两项损失的加权和：

小陈的跟读练习越多，临场反应越自然。模型也一样：训练时让它习惯“看不见未来”的约束，推理时它才能在相同的约束下稳定发挥。掩码仿真和一致性正则，就是给模型做“边听边译”的刻意训练。

L=λ⋅Lchunk+(1−λ)⋅Lfull\displaystyle L = \lambda \cdot L_{\text{chunk}} + (1 - \lambda) \cdot L_{\text{full}}
总体损失由带掩码的流式损失和看全上下文的完整损失加权组成。
  1. L_chunk（流式损失）模型在 chunk 掩码约束下预测结果的交叉熵损失。
    Lchunk\displaystyle L_{\text{chunk}}
  2. L_full（完整损失）模型看到完整上下文时的交叉熵损失。
    Lfull\displaystyle L_{\text{full}}
  3. λ（权重系数）控制流式损失和完整损失的相对重要性，通常 λ 在 0.5 附近。
    λ\displaystyle \lambda

推理部署实践

小陈上工前会做一系列准备：调整耳机音量、把速记本放在最顺手的位置、和搭档约定轮换节奏。这些看似琐碎的准备，决定了他在台上的表现。流式 ASR 的推理部署，同样需要精心调优才能让模型高效跑起来。

在服务端，一个流式 ASR 服务通常同时服务多个用户。如果每个用户来的音频帧都单独触发一次模型计算，GPU 利用率会很低。更好的做法是批处理流水线：把多个用户同一时间段到达的 chunk 拼成一个 batch 一起计算，充分利用并行能力。同时，由于流式推理中相邻 chunk 的计算存在大量重复的中间状态，系统可以把已经算好的“前缀编码”缓存下来，下一个 chunk 只需要计算新增部分，这就是 prefix cache（前缀缓存）。

部署时，工程师还需要给系统设置一个延迟预算。端到端延迟可以表示为：

小陈的准备工作越多，现场出错的概率越低。流式 ASR 的工程师同样需要把网络、算力、策略三个环节都纳入延迟预算，提前做好缓存和批处理设计，才能让“实时”真正落地。

De2e=Dnet+Dmodel+Dpolicy≤Dtarget\displaystyle D_{\text{e2e}} = D_{\text{net}} + D_{\text{model}} + D_{\text{policy}} \leq D_{\text{target}}
系统总延迟等于网络传输、模型推理和策略等待之和，必须控制在目标延迟之内。
  1. D_e2e（端到端总延迟）用户说话到收到识别结果的完整耗时。
    De2e\displaystyle D_{\text{e2e}}
  2. D_net（网络延迟）音频上传和结果下发的网络耗时。
    Dnet\displaystyle D_{\text{net}}
  3. D_model（模型推理延迟）模型处理一个 chunk 的计算时间。
    Dmodel\displaystyle D_{\text{model}}
  4. D_policy（策略等待延迟）动态窗口等策略主动引入的等待时间。
    Dpolicy\displaystyle D_{\text{policy}}
  5. D_target（目标延迟预算）业务要求的延迟上限，例如会议字幕要求在 800ms 内。
    Dtarget\displaystyle D_{\text{target}}

AI 应用场景

实时会议字幕

阶段：模型推理与部署优化

解决的问题：传统会议录音都是会后转写，与会者无法实时跟上发言内容。AI 流式 ASR 通过 chunk 增量解码，边开会边出字幕。

具体案例：在跨国视频会议中，演讲者说一句，字幕跟着出一句。系统用 chunk-aware attention 控制局部上下文，用 online CTC 逐字确认，并把端到端延迟控制在 800ms 以内，确保字幕与语音基本同步。

智能语音助手打断检测

阶段：在线解码与延迟控制

解决的问题：用户说出“你好小薇”时，助手必须尽快识别出唤醒词，而不是等一整句话说完。

具体案例：手机助手持续接收麦克风音频流，每 320ms 一个 chunk 被送入流式 ASR。模型使用固定窗口 + 动态置信度阈值，在 3 个 chunk 内确认唤醒词，然后立刻触发后续交互。

直播实时字幕

阶段：流式训练优化与推理调优

解决的问题：直播场景中弹幕和口播速度很快，离线转写完全没有时效性，观众需要边看边读字幕。

具体案例：直播平台对主播声音做流式识别，训练时用 chunk 掩码仿真提升鲁棒性，部署时用 prefix cache 避免重复计算。结果显示，字幕延迟降低 40%，而准确率仅下降 1%。

Python 演示

python52 行
import random  class OnlineCtcDecoder:    """流式 CTC 增量解码器（教学简化版）"""     def __init__(self, blank="_", window=3, confirm_threshold=2):        self.blank = blank        self.window = window        self.confirm_threshold = confirm_threshold        self.history = []        self.confirmed = []        self.candidate = None        self.candidate_count = 0        random.seed(42)     def _simulate_probs(self, chunk_id):        """模拟模型对当前 chunk 输出的 token 概率分布"""        tokens = ["今", "天", "天", "气", "真", "好", self.blank]        probs = {t: 0.08 for t in tokens}        probs[tokens[chunk_id % 6]] = 0.72        probs[self.blank] = 0.12        return probs     def feed(self, chunk_id):        probs = self._simulate_probs(chunk_id)        token = max(probs, key=probs.get)        self.history.append(token)        if len(self.history) > self.window:            self.history.pop(0)        if token != self.blank:            if token == self.candidate:                self.candidate_count += 1            else:                self.candidate = token                self.candidate_count = 1        else:            self.candidate = None            self.candidate_count = 0        if self.candidate_count >= self.confirm_threshold:            if not self.confirmed or self.confirmed[-1] != self.candidate:                self.confirmed.append(self.candidate)            self.candidate = None            self.candidate_count = 0        return list(self.confirmed)  if __name__ == "__main__":    decoder = OnlineCtcDecoder()    for i in range(8):        result = decoder.feed(i)        print(f"chunk {i}: 已确认输出 {result}")
目的：演示一个简化版的流式 CTC 增量解码器，每收到一个 chunk 就更新已确认文字，并模拟了局部上下文窗口和延迟确认策略。
  1. probs = self._simulate_probs(chunk_id)模拟模型对当前 chunk 的输出概率分布。
  2. token = max(probs, key=probs.get)取概率最高的 token，模拟 CTC 贪心解码。
  3. if len(self.history) > self.window: self.history.pop(0)只保留最近 window 个 chunk，体现 chunk-aware attention。
  4. if token != self.blank:CTC 跳过空白帧。
  5. if token == self.candidate: self.candidate_count += 1连续出现同一 token 则累计候选次数。
  6. if self.candidate_count >= self.confirm_threshold:达到阈值才确认输出，这就是延迟控制策略。

常见误区

误区流式 ASR 既然叫“流式”，就应该是每个音频帧进来都立刻吐一个字，所以延迟能做到极低。

正解实际上流式 ASR 是以 chunk 为基本单位工作的。模型需要攒够若干帧（一个 chunk）才有足够信息做一次前向计算，很少逐帧输出。逐帧输出既不经济也不稳定，容易频繁修改已输出内容。

为何常见：“流式”这个词容易让人联想到“逐帧”，但工程上为了平衡准确率和计算效率，一定会有 chunk 缓冲。

误区chunk-aware attention 就是把注意力限制在当前这个 chunk 内部，完全不看其他内容。

正解它允许关注当前 chunk 以及附近的历史 chunk，有时还包括一个很小的未来 chunk。不是“只关注自己”，而是“关注一个局部窗口”。同传译员翻译当前句子时，也必须依赖刚刚说过的那句话。

为何常见：“局部”被误理解为“唯一”，忽略了上下文窗口的存在。

误区既然 CTC 目标函数是一样的，那离线 CTC 和 online CTC 的解码算法也应该完全相同。

正解离线 CTC 可以在整段语音结束后使用完整的束搜索；online CTC 必须按时间顺序增量更新前缀概率，无法使用未来帧，也不能在后期翻盘。它需要额外设计“确认”机制，避免已输出的文字被频繁推翻。

为何常见：大家更熟悉 CTC 训练时的公式，容易忽略推理阶段流式与离线之间的巨大差异。

误区用户要实时，那就把 chunk 切到最小、确认阈值降到最低，让文字以最快的速度蹦出来。

正解过低延迟会让模型在信息不足时就做出决定，导致错误率上升和频繁修正。用户体验反而更差。正确做法是设置合理的延迟预算，在可接受延迟内尽量提升准确率。

为何常见：产品经理强调“实时”，工程师容易只盯着延迟指标，忽略准确率与稳定性的代价。

面试题

Q1. 流式 ASR 与离线 ASR 最关键的区别是什么？

单选题 · easy

  • A.离线模型更小
  • B.边输入边输出← 正确答案
  • C.不使用神经网络
  • D.不需要音频特征

答案：B。流式 ASR 的核心是边输入边输出，像同传译员一样实时吐字；离线 ASR 则等整句话说完再输出。其他选项并非两者本质区别。

Q2. chunk-aware attention 可以关注的范围是以下哪种？

单选题 · mid

  • A.整个句子任意位置
  • B.当前块及附近上下文← 正确答案
  • C.只关注当前一个块
  • D.只关注未来音频块

答案：B。chunk-aware attention 通过掩码把注意力限制在当前 chunk 和相邻的历史（及有限未来）块上，既保证局部性又保留必要上下文。

Q3. online CTC 中，blank 符号的主要作用是什么？

单选题 · hard

  • A.表示删除已确认文字
  • B.表示静音或暂停帧← 正确答案
  • C.表示句子结束标记
  • D.表示请求重听音频

答案：B。CTC 的 blank 用于填充帧与帧之间的“无输出”位置，对应同传速记中“没听到关键词”的时刻，解码时会跳过它。

Q4. 想要直接降低流式识别的延迟，最直接的方案是？

单选题 · easy

  • A.增大 chunk 尺寸
  • B.减小 chunk 尺寸← 正确答案
  • C.增加模型层数
  • D.扩大词表规模

答案：B。chunk 越小，模型等待攒音频的时间越短，出字越快。但要注意准确率可能下降，因此需要权衡。

Q5. 训练流式模型时为什么要加 chunk 掩码？

单选题 · mid

  • A.减少训练数据量
  • B.模拟推理时看不见未来← 正确答案
  • C.增加模型参数量
  • D.提升音频采样率

答案：B。训练和推理上下文不一致会导致模型崩溃，掩码仿真让模型在训练时就适应“只看局部”的约束。

Q6. 以下哪些属于流式增量解码的延迟控制策略？

多选题 · hard

  • A.固定窗口控制← 正确答案
  • B.动态窗口调整← 正确答案
  • C.随机裁剪音频
  • D.延迟预算监控← 正确答案

答案：ABD。固定窗口和动态窗口分别代表“固定等 N 块”和“按置信度决定等待时长”的策略，延迟预算监控则是工程侧的约束方法。随机裁剪音频与延迟控制无关。

Q7. 关于 online CTC 解码，下列说法正确的是？

单选题 · mid

  • A.必须等整句结束才输出
  • B.可以跳过空白并合并重复← 正确答案
  • C.每个 token 只能输出一次
  • D.过程中不允许修改结果

答案：B。online CTC 跟随 chunk 增量更新，跳过 blank、合并连续重复 token。确认后的前缀尽量不改，但未确认内容仍可更新。

Q8. 端到端延迟公式 D = D_chunk + D_compute + D_wait 中，D_wait 代表什么？

单选题 · mid

  • A.网络传输等待时间
  • B.解码策略的额外等待← 正确答案
  • C.音频特征提取时间
  • D.用户思考等待时间

答案：B。D_wait 是解码策略为了降低错误率而故意多等的时间，比如动态窗口在置信度不足时继续等待，而 D_chunk 和 D_compute 分别代表攒块和计算耗时。

Q9. 部署流式 ASR 时，使用 prefix cache 的主要目的是？

单选题 · hard

  • A.减少已处理 chunk 的重复计算← 正确答案
  • B.增大语音识别词表
  • C.降低音频采样率
  • D.提高模型训练精度

答案：A。prefix cache 将已处理 chunk 的中间编码结果缓存下来，新 chunk 只需要计算增量部分，大幅降低推理耗时。

Q10. 为什么训练与推理上下文不一致会导致流式模型性能下降？

多选题 · extreme

  • A.注意力分布失配← 正确答案
  • B.解码状态传递错误← 正确答案
  • C.模型参数变得更大
  • D.训练数据变得不足

答案：AB。训练时能看全句而推理时只能看局部，模型学到的注意力分布与推理时不匹配（失配），解码状态也可能积累错误；这本质是分布差异问题，与参数数量和训练数据量无直接关系。