想象你参加一档叫《猜词达人》的综艺节目：一个口齿不清的孩子（CTC语音模型）把你听到的每个音节都报出来，却完全不懂词语和语法。你作为主持人（解码器），要在一群候选答案里，帮他挑出一句完整通顺的话。最简单的主持人只会“每轮选发音概率最高的那个字”——结果往往是每个字单独听都对，串成整句话却荒腔走板。束搜索（Beam Search）则聪明得多：主持人手里始终举着一块“候选答案展示板”，同时保留好几组最有潜力的句子开头，逐字往前推进，遇到相同的部分就合并，走到最后再选出整体得分最高的一句。为了让句子更通顺，还可以请场外的“语文老师”（语言模型）给每一句候选悄悄打分；为了不让游戏拖太长，主持人还会提前淘汰明显没希望的选手（剪枝）。这个故事，就是 CTC 解码与束搜索的全部秘密。

岗位关联

对语音技术工程师而言，掌握 CTC 束搜索等同于拿到“把语音识别准确率从糟糕推向实用”的核心钥匙——从声学模型到最终文字，这一步决定了产品体验的最终天花板。

目录
  1. 可视化演示
  2. 束搜索原理
  3. 语言模型集成
  4. 剪枝策略
  5. 词级与字级
  6. 实时解码优化
  7. 性能与调优
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示CTC解码三模式：束搜索算法（5时间步x3 beam路径网格+前缀合并P0-P2路径+BMW束宽/PRN剪枝/BLK空白/SCN扫描参数）、语言模型融合（AM声学模型→FUSE浅融合←LM语言模型+Score=P(y|x）+αP(y)公式+SHL浅/DPC深/COLD冷/COM组合四策略)、解码优化（CHR字符/WRD词/SUB子词三级对比+THR阈值/BMW束宽/ADP自适应/MRG合并四剪枝+AUD→FBK→AM→DEC→OUT实时增量解码流程+CTC/RNN-T/ATT/HYB变体对比）。

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

CTC束搜索路径展开与合并 5时间步x3 beam路径网格，每步维护多条候选路径 前缀合并：P0+P1相同前缀HEL合并，消除冗余对齐路径 Beam(y) = topK(P(y|x)) 束宽10，准确率92%，延迟50ms

束搜索原理

《猜词达人》第一关：主持人不能只盯一个“看似最强的选手”。他借鉴了综艺节目里“候选展示板”的做法——同时举起三四个候选答案，只要它们都有希望，就一路护送到下一轮。这种“多个备选齐头并进”的思路，就是束搜索的核心。它不冲动下注，而是用广度换稳定性，用并行决策对冲单步判断的风险。

语音识别里，CTC 模型在每一帧都输出一个概率分布（发音候选），但单个时间步上的“最优”未必是整句的“最优”。束搜索把候选句子切成“前缀”，每收到一帧，就把每个前缀分别接上所有可能的 token，再重新比较总分。就像主持人看完新线索后，重新给所有选手排名。

束搜索的本质是维护一个大小固定的候选集合，每一步都从“当前候选 × 全部词表”的笛卡尔积中挑出得分最高的 B 个。由于概率连乘容易下溢到 0，工程上习惯用对数加法代替概率乘法：

回到节目里：主持人维护的展示板就是“束”，板上候选个数就是束宽 B。B 越大，越不容易漏掉正确答案，但主持人也要花更多精力照顾每位选手。聪明的做法是：每轮结束把得分相同的选手合并（去重），避免同一个句子占两个名额——这正是 CTC 解码里“合并重复 token”的朴素来源。

S(y1:T)=∑t=1Tlog⁡p(yt∣x, y1:t−1)\displaystyle S(y_{1:T}) = \sum_{t=1}^{T} \log p(y_t \mid \mathbf{x},\, y_{1:t-1})
它把“一句话有多像”变成“每个字选对的对数概率之和”，求和比连乘更稳定、更高效。
  1. 总得分定义S(y₁:T) 表示从第 1 个词到第 T 个词整个候选句子的总得分，得分越高，说明这句话越受“欢迎”。
    S(y1:T)\displaystyle S(y_{1:T})
  2. 逐字累加公式中的 Σ 从第 1 帧一直加到第 T 帧，每一帧都贡献一部分得分，像主持人每轮给选手加一次分。
    ∑t=1T\displaystyle \sum_{t=1}^{T}
  3. 预测概率p(yₜ | x, y₁:t₋₁) 表示“在听到声音片段 x、且已确定前面几个字的前提下，下一个字选 yₜ 的概率”。
    log⁡p(yt∣x, y1:t−1)\displaystyle \log p(y_t \mid \mathbf{x},\, y_{1:t-1})
  4. 对数妙用log 让连乘变成连加，既避免了成千上万个小概率相乘导致的数值下溢，也让后面的剪枝比较变得更直观。
    log⁡\displaystyle \log

语言模型集成

节目进入第二关，主持人发现：只靠“发音像不像”还不够。选手报出的字眼经常音对字错，比如把“科技”报成“颗粒”。这时场外的语文老师（语言模型）出手了——他知道哪些词更常见、哪句话更像人话。主持人的策略是：让语音模型的“发声分”和语文老师的“通顺分”按一定比例相加，共同排名。

语言模型集成解决的是 CTC 的一个先天短板：CTC 假设每一帧的预测相互独立，它只关心“这个音像哪个字”。“马冬梅”听成“马达妹”若只按发音打分，两者难分伯仲；但语文老师知道“马冬梅”是个人名，常见搭配会把它顶上来。融合公式通常写成：

如果想让语文老师更多参与“重打分”，还可以在束搜索扩到一定长度后，再对幸存候选做一次完整句子级评分——这就像节目决赛时请三位评委集体亮分。语言模型不是越大越好，权重要像调味料一样拿捏：放少了句子别扭，放多了发音变形。

log⁡p(y∣x)=log⁡pCTC(y∣x)+λlog⁡pLM(y)\displaystyle \log p(y \mid \mathbf{x}) = \log p_{\text{CTC}}(y \mid \mathbf{x}) + \lambda \log p_{\text{LM}}(y)
这是“发音分”与“通顺分”的加权求和，λ 决定语文老师有多大的话语权。
  1. 总目标log p(y | x) 是融合后每个候选句子的最终得分，束搜索按这个分数重新排序。
    log⁡p(y∣x)\displaystyle \log p(y \mid \mathbf{x})
  2. 发声分log p_CTC(y | x) 来自 CTC 声学模型，代表“这句话的发音与声音匹配度”。
    log⁡pCTC(y∣x)\displaystyle \log p_{\text{CTC}}(y \mid \mathbf{x})
  3. 通顺分log p_LM(y) 来自外部语言模型，代表“这句话的用词与语法通顺度”。
    log⁡pLM(y)\displaystyle \log p_{\text{LM}}(y)
  4. 融合权重λ 控制语文老师的“嗓门大小”，λ 越大，句子越通顺但越冒险，可能忽视真实发音。
    λ\displaystyle \lambda

剪枝策略

《猜词达人》进行到三分之一，展示板上的候选越来越多：每个选手后面都能接几十个新字，主持人再厉害也忙不过来。他只好立下规则：与当前最高分相差太多的选手，直接淘汰（剪枝）。这不是偏心，而是让资源集中在真正有希望的候选人身上。术语里，这个策略叫 pruning。

束搜索的计算量约等于“束宽 × 词表大小 × 帧数”，在嵌入式设备上常常爆炸。于是工程师设计了两种典型的剪枝手段：硬阈值剪枝，分数低于某个绝对门槛就直接踢掉；相对剪枝，与当前最高分比较，分差超过一个容忍度 β 的选手出局。后者更常用，因为它能动态适应不同音频的置信度分布：

除了剪枝，“历史缓存”也是隐藏加速器：CTC 解码时很多候选前缀在多个时间步重复出现，把它们的中间得分缓存下来，避免重复计算。剪枝与缓存的结合，让束搜索在手机、车机这类算力紧张的环境里也能跑得动——计算复杂度从“全量搜索”降为 O(B × V × T)，B 才是真正的开关。

keep(i)={1,si≥smax⁡−β0,si<smax⁡−β\displaystyle \text{keep}(i) = \begin{cases} 1, & s_i \ge s_{\max} - \beta \\ 0, & s_i < s_{\max} - \beta \end{cases}
这条规则的意思是：不是跟零比，而是跟“当前的状元”比，差距太大就没有留下来陪跑的必要。
  1. 是否保留keep(i) 是保留标记，1 表示第 i 个候选继续留在展示板上，0 表示退场。
    keep(i)\displaystyle \text{keep}(i)
  2. 最高分基准s_max 是当前所有候选中的最高得分，充当“领头羊”。
    smax⁡\displaystyle s_{\max}
  3. 容忍差值β 是主持人设定的容忍度，β 越大，淘汰越宽松，候选越多、计算越慢。
    β\displaystyle \beta
  4. 比较判断条件 s_i ≥ s_max − β 成立才保留，实质是“你跟第一名差得还不太远，还有翻盘机会”。
    si≥smax⁡−β\displaystyle s_i \ge s_{\max} - \beta

词级与字级

主持人遇到新难题：选手应该一个字一个字的报名，还是一个词一个词地报名？如果按“字”来，遇到“蓝瘦香菇”这种新造词也能硬拼出来，但整句意思容易散；如果按“词”来，句子自带词典知识、更像人话，可万一用户说的是词典里没有的地名或人名，就当场卡壳。

这是解码单元（decoding unit）的选择困境。字级（character-level）解码把 CTC 模型的输出直接当字序列处理，词表小、搜索快、能覆盖任意词汇；词级（word-level）解码则在词典约束下把连续的字聚合成词，用词法知识大幅削减发音混淆。两者的得分可以互相折算，比如一个词由多个字组成，可以按字的平均对数概率给出词的粗略得分：

工程实践中，主流方案是“混合解码”：基础层用字级束搜索保证覆盖率，当拼出的字序列能匹配词典里的词时，就把它们的路由合并到词级候选上。这就像节目里允许选手先一个一个字地突破，组成词后自动获得“词法导师”的额外资助。字级保证不抛弃任何用户的表达，词级保证最常见的表达足够准——两全其美。

score(w)=∑c∈wlog⁡p(c∣x)+log⁡plex(w)\displaystyle \text{score}(w) = \sum_{c \in w} \log p(c \mid \mathbf{x}) + \log p_{\text{lex}}(w)
词的得分 = 组成它的每个字的成绩之和 + 词典给出的“词法加分”。
  1. 词得分score(w) 是候选词 w 的最终分数，用于在束搜索里对词级候选排序。
    score(w)\displaystyle \text{score}(w)
  2. 逐字累分Σ 对词 w 里的每个字 c 求和，把字的发音分数合并成词的发音分数。
    ∑c∈wlog⁡p(c∣x)\displaystyle \sum_{c \in w} \log p(c \mid \mathbf{x})
  3. 词典加分log p_lex(w) 是词典/词法模型给的额外奖励，常见词加分、生僻词不加分。
    log⁡plex(w)\displaystyle \log p_{\text{lex}}(w)

实时解码优化

如果节目是现场直播，主持人可没法等所有选手跑完全程再宣布结果。真实场景中的语音助手也是这样：用户话音刚落，系统最好已经显示出大部分文字——毕竟没人愿意对着空气等三秒。实时解码的本质，是把“全句听完再解码”改成“边听边解”的流式增量计算。

流式束搜索不再每帧重头计算，而是把上一帧已经算好的候选前缀和得分保存下来，新音频帧到达时，只对幸存候选做一次扩展。这种“增量更新”让每次新增的计算量大幅下降。同时，延迟本身也要被量化管理：

优化还有另外两板斧：缓存复用——把 CTC 每一帧的前向计算结果暂存，帧与帧之间共享；并行加速——把束搜索中“每个候选独立扩展”的操作分给多个计算核，反正各候选之间互不干扰。实际产品里，实时解码器常配合“端点检测”，检测到一句话说完才发布最终结果——相当于主持人听选手说完一整句，才亮出展示板上的最终答案。

Latency=1N∑n=1N(tnout−tnin)\displaystyle \text{Latency} = \frac{1}{N}\sum_{n=1}^{N} \left( t^{\text{out}}_n - t^{\text{in}}_n \right)
它统计的是“第 n 个字说出来的时刻”与“第 n 个字被识别输出的时刻”的平均差，衡量用户到底等了多久。
  1. 平均延迟Latency 是所有 N 个输出单元的平均等待时间，是实时语音体验的 KPI。
    Latency=1N∑n=1N\displaystyle \text{Latency} = \frac{1}{N}\sum_{n=1}^{N}
  2. 输出时刻t_out(n) 是解码器输出第 n 个结果的时间点，越早越好。
    tnout\displaystyle t^{\text{out}}_n
  3. 输入时刻t_in(n) 是音频里第 n 个字的实际发出时刻。
    tnin\displaystyle t^{\text{in}}_n
  4. 差值含义两者相减如果接近 0，说明几乎“零延迟”；为负则说明系统提前预判（常见于缓存输出）。
    tnout−tnin\displaystyle t^{\text{out}}_n - t^{\text{in}}_n

性能与调优

节目收官之前，主持人要复盘：这一季的猜词到底准不准？观众等得久不久？同样，工程师上线一个识别系统，不能用“感觉变好了”来交付，得用指标说话。语音识别最常用的评判标准之一是字错误率（CER），它统计识别结果和标准答案之间需要多少步“修改操作”才能对上：

调参的艺术在于理解权衡。增大束宽 B 通常能降低 CER，因为保留的候选更多，但推理时间接近线性上涨；语言模型权重 λ 过小等于没请语文老师，过大则把声音拗成“书面腔”；剪枝阈值 β 太激进会误杀正确答案，太宽松又拖慢实时性。优秀工程师的做法是：先在离线测试集上画“束宽-CER”曲线，找到收益拐点，再上真机验证延迟——就像主持人先内部彩排找节奏，再决定现场淘汰规则。最终，解码器不是一个孤立组件，而是与声学模型、语言模型、产品场景共同演奏的合奏。

CER=S+D+IN\displaystyle \text{CER} = \frac{S + D + I}{N}
分子是“替换错字 + 漏掉的字 + 多出的字”的总数，分母是标准答案的总字数——比值越低，识别越准。
  1. 指标公式CER 是字错误率（Character Error Rate），数值越低越好，0 表示完美识别。
    CER=S+D+IN\displaystyle \text{CER} = \frac{S + D + I}{N}
  2. 替换错误S 是替换（Substitution），指认识错的字，比如“是”识别成“事”。
    S\displaystyle S
  3. 删除错误D 是删除（Deletion），指漏掉的字，比如“谢谢”只剩一个“谢”。
    D\displaystyle D
  4. 插入错误I 是插入（Insertion），指多出来的字，比如“好的”被识别成“好你的”。
    I\displaystyle I
  5. 归一化N 是标准句子的总字数，把错误总数除以它，才能公平比较长短不同的句子。
    N\displaystyle N

AI 应用场景

场景 1：智能音箱实时语音助手

阶段：模型推理与解码（实时推理链路）

解决的问题：传统方案等用户说完一整句才开始识别，交互延迟高达 3-5 秒；而流式 CTC 束搜索把延迟压到 300 毫秒内，同时用语言模型修正“订闹钟”这类高频命令的发音歧义。

具体案例：用户对智能音箱说“帮我订明早七点的闹钟”。音箱的 CTC 解码器在用户说完“订”字时已开始扩展候选前缀，边听边把“订/定/顶”等发音候选交给语言模型打分，最终输出正确的“订”，用户体验几乎无感。

场景 2：会议转写与字幕生成

阶段：离线后处理（高精度解码）

解决的问题：会议音频里有大量专业术语、人名和英文缩写，纯 CTC 解码容易听错；离线场景允许更大的束宽、更重的语言模型和词级词典约束，换取更低的 CER。

具体案例：某会议转写服务将束宽从 4 调到 16，并融入行业术语词典和语言模型重打分，人名的字错误率从 18% 降到了 7%，虽然推理时间增加了 2 倍，但对离线字幕场景完全可接受。

场景 3：车载语音免唤醒命令

阶段：端侧实时解码（资源受限优化）

解决的问题：车机芯片算力有限，且不能依赖云端。通过把束宽压缩到 3、启用相对剪枝 β=1.5、并复用上一步的历史缓存，可以让 CTC 解码在 200ms 内完成，且准确率几乎不下降。

具体案例：某车载系统识别“打开空调”“播放音乐”等固定命令时，采用词级词典约束——解码器只在这些命令的候选里搜索，把误唤醒率降低了 40%。

Python 演示

python43 行
import math def greedy_decode(probs, blank=0):    seq = [max(range(len(frame)), key=lambda v: frame[v]) for frame in probs]    out = []    prev = blank    for token in seq:        if token != blank and token != prev:            out.append(token)        prev = token    return out def beam_search_decode(probs, blank=0, beam_size=3, vocab_size=3):    beams = [(tuple(), 0.0)]    for frame in probs:        new_beams = {}        for prefix, score in beams:            for token in range(vocab_size):                if frame[token] <= 0:                    continue                new_prefix = prefix                if token != blank and (not prefix or prefix[-1] != token):                    new_prefix = prefix + (token,)                new_score = score + math.log(frame[token])                key = new_prefix                if key not in new_beams or new_score > new_beams[key]:                    new_beams[key] = new_score        beams = sorted(new_beams.items(), key=lambda item: item[1], reverse=True)[:beam_size]    best_prefix, best_score = max(beams, key=lambda item: item[1])    return list(best_prefix), math.exp(best_score) if __name__ == "__main__":    probs = [        [0.6, 0.3, 0.1],        [0.4, 0.5, 0.1],        [0.2, 0.6, 0.2],        [0.7, 0.2, 0.1]    ]    vocab = ["<blank>", "a", "b"]    g = greedy_decode(probs, blank=0)    b, prob = beam_search_decode(probs, blank=0, beam_size=3, vocab_size=3)    print("greedy:", "".join(vocab[i] for i in g))    print("beam:  ", "".join(vocab[i] for i in b), "score=", round(prob, 4))
目的：用一个小概率矩阵直观演示 CTC 贪心解码与束搜索解码的差异，前者只看局部最优，后者保留多个候选整体比较。
  1. beams = [(tuple(), 0.0)]束搜索的初始状态：一个空前缀，得分为 0（对数概率起点）。
  2. for frame in probs:逐帧扫描 CTC 输出的概率分布，模拟音频随时间推进。
  3. for token in range(vocab_size):每个候选前缀尝试接上词表里的所有可能的字，展开候选。
  4. if token != blank and (not prefix or prefix[-1] != token):CTC 去重规则：blank 跳过，连续重复字只保留一个。
  5. new_score = score + math.log(frame[token])对数概率累加，即“候选句子总得分”。
  6. beams = sorted(...)[:beam_size]按得分排序并截取前 B 个，这就是束宽的意义所在。

常见误区

误区我以为束宽是“越大越无敌”，把束宽从 4 调到 64，识别率肯定蹭蹭涨，反正机器算力足够。

正解束宽越大，搜索越充分，但收益递减甚至反弹：过大的束宽放大了语言模型对低频词的偏好，把正确但少见的词挤下去；同时推理时间线性上涨。调束宽应该画“准确率-延迟”曲线，找拐点，而不是无脑调大。

为何常见：直觉上“搜索空间越大越接近全局最优”，忽略了候选质量分布和计算成本之间的平衡。

误区CTC 输出概率已经挺准，每帧取最大概率再合并重复字，何必搞复杂的束搜索？

正解CTC 的独立假设让每一帧只看到局部声音，贪心解码在谐音字、同音词上经常“每个字都对、整句全错”。束搜索通过候选整体比较挽回了这类错误，这是贪心无法做到的。

为何常见：因为小测试集上贪心错误率看起来还好，掩盖了同音词和高噪声场景的崩坏。

误区语言模型能让句子通顺，那我就把 λ 调到 5，让语文老师全权做主。

正解λ 过大时，解码结果会被语言模型“洗脑”成高频模板句，用户说的专名、口语、方言都被强行拗成常见词。λ 需要在开发集上实验，通常 0.3~1.0 之间，以小步长扫描确定。

为何常见：因为在普通话标准音频上“通顺”和“正确”高度一致，让人误以为语文老师永远是对的。

误区反正输出都是文字，用字还是用词只是格式问题，我直接拿模型的单元改改就行。

正解两者机制完全不同：字级解码词表小、能拼出任意词，但缺少词法约束；词级解码依赖词典，生僻词直接 OOV（越界）失败。混合解码才兼顾两者。

为何常见：模型内部输出单元是字，让人误以为“以字为单位”天然更好，忽略了工程上的词典知识可以大幅纠错。

误区把离线束搜索的代码优化一下、用上 GPU，不就是实时了吗？

正解实时解码的核心是流式增量——每新到一帧只更新候选前缀的扩展，而不是重算整句；同时要管理延迟、复用历史缓存。离线优化再怎么提速，算法结构不对，延迟依然会线性累积。

为何常见：很多人把“快”和“流式”混为一谈，没意识到“边输入边输出”是结构性约束，不是简单的性能问题。

面试题

Q1. CTC 贪心解码最大的缺陷是什么？

单选题 · easy

  • A.计算速度太慢，无法实时运行
  • B.每帧只取局部最优，忽略整体句子的合理性← 正确答案
  • C.需要额外训练一个语言模型才能使用
  • D.无法处理空白符（blank）的跳过规则

答案：B。贪心解码逐帧取最大概率 token，像每轮只选当前最快选手，忽视了前后文的整体搭配，导致同音词错误率高。它其实很快，B 项正确；C、D 都不是贪心特有的缺陷。

Q2. 束搜索中的“束宽”（beam size）指什么？

单选题 · easy

  • A.训练神经网络时的批处理大小
  • B.每轮同时保留的候选答案数量← 正确答案
  • C.音频帧的采样率
  • D.语言模型的词汇表大小

答案：B。束宽就是主持人展示板上同时保留的候选句子数量，它决定搜索的广度。束宽越大，候选越多越准但越慢；与批大小、采样率、词表无关。

Q3. 关于 CTC 束搜索中的“去重合并”，下列说法正确的有？

多选题 · mid

  • A.连续重复的相同 token 在拼接前缀时只保留一个← 正确答案
  • B.空白符（blank）不会拼接到前缀中← 正确答案
  • C.相同前缀的多个路径可以共享同一个候选位置← 正确答案
  • D.去重会让束宽自动变大

答案：ABC。CTC 解码规则是“合并连续重复、丢弃 blank”，所以 A、B 正确；相同前缀合并后共享分数是束搜索的重要优化，C 正确；去重是合并而非扩充，束宽由参数固定，D 错误。

Q4. 语言模型集成公式中，λ 的作用是什么？

单选题 · mid

  • A.控制声学模型的学习率
  • B.决定语言模型打分的权重大小← 正确答案
  • C.调节音频采样率
  • D.设置束搜索的候选数量

答案：B。λ 是融合权重，决定语文老师的话语权。λ 太小等于没请老师，太大则发音被拗成模板句。它与学习率、采样率、束宽无关。

Q5. 相对剪枝策略"keep(i) = (s_i ≥ s_max − β)"中，β 增大时会怎样？

单选题 · mid

  • A.淘汰更多候选，速度更快但更冒险
  • B.保留更多候选，速度变慢但更稳妥← 正确答案
  • C.束宽自动减小
  • D.语言模型权重自动增大

答案：B。β 是容忍度，越大意味着“跟第一名差得远也能留下”，候选更多、计算更慢、更不容易误杀正确答案。A 描述的是 β 减小的效果。

Q6. 下列哪些是词级解码相对字级解码的优势？

多选题 · mid

  • A.能识别任意新造词，不受词典限制
  • B.借助词法知识降低同音词错误← 正确答案
  • C.搜索结果天然符合词典边界，更像人话← 正确答案
  • D.词表更小，搜索速度更快← 正确答案

答案：BCD。词级解码的词典约束让候选词落在常见词范围内，降低同音混淆并提升通顺度，B、C 正确；词表比字级大，但搜索时按词合并反而路径更少，推理更快，D 正确；A 是字级解码的优势，词级恰恰有 OOV 问题。

Q7. 流式束搜索与离线束搜索最本质的区别是什么？

单选题 · hard

  • A.流式版的束宽必须小于等于 2
  • B.流式版需要增量更新前缀，而不是每帧重算全句← 正确答案
  • C.流式版完全不需要语言模型
  • D.流式版只能用词级解码单元

答案：B。实时场景要求“边输入边输出”，因此解码器要保存上一帧的候选状态，只对新帧做扩展和重排序，这就是增量更新。B 正确；束宽与解码单元都不受流式限制，A、D 错误；语言模型在流式里照样可用，C 错误。

Q8. CTC 解码中，为什么常用对数概率累加而不是概率连乘？

单选题 · hard

  • A.对数可以让概率大于 1，便于计算
  • B.多个小概率连乘容易下溢为 0，对数加法更稳定← 正确答案
  • C.对数能把乘法变成除法，加快推理
  • D.语言模型只能输出对数概率

答案：B。CTC 每帧概率通常远小于 1，几百帧连乘后趋近于 0，造成浮点下溢。log 把连乘变成连加，保证数值稳定且比较排序不变。A、C、D 都不符合数值计算的基本原理。

Q9. 在嵌入式设备上优化 CTC 束搜索，下列哪些手段有效？

多选题 · hard

  • A.启用相对剪枝，让落后的候选早点退场← 正确答案
  • B.缓存复用历史前缀的中间得分← 正确答案
  • C.把束宽无限调大以提高准确率
  • D.对每个候选前缀做并行扩展← 正确答案

答案：ABD。剪枝减少计算量，缓存避免重复计算，并行扩展利用多核加速，A、B、D 都是有效优化；无限调大束宽会让延迟爆炸，在嵌入式设备上不可行，C 错误。

Q10. 某测试集标准句有 100 个字，识别结果有 3 个替换错字、2 个漏字、1 个多字，则该结果的 CER 是多少？

单选题 · extreme

  • A.2%
  • B.6%← 正确答案
  • C.4%
  • D.5%

答案：B。CER = (S + D + I) / N = (3 + 2 + 1) / 100 = 6/100 = 6%。这相当于主持人的错误操作总数占标准答案的比例，B 正确；其余选项直接把分子分母算错。