CTC解码核心：Prefix Score递推与Beam Search实战-北京尧图网络

CTC训练好之后真正麻烦的反而是解码。模型在你手上给的只是一张按帧算好的概率表看起来像一团迷雾每一帧上哪个字符的概率最高贪心取一下、再把连续重复和空白去掉不就是结果吗很多新手都是这么干的跑出来以后发现错得离谱。真正跑过语音识别或者OCR解码的人都知道预测阶段正确的思路是基于“前缀分数”Prefix Score的动态规划搜索也就是常说的Prefix Beam Search。这篇我把CTC Prefix Score计算的来龙去脉、数学递推、可直接改的Python实现以及工程上容易踩的坑一次性讲透。拿一个实际例子说某次我试着把一段几十帧的音频丢给训练好的CTC模型先跑了贪心解码输出是“aaa_bb__ccc”这种带下划线的原始帧标签序列折叠完也确实能变成一个词。但换一句更复杂的音频贪心输出就出问题了——漏字、重复、多出来的噪声帧全混在里面怎么折叠都不对。而改用Prefix Score去做Beam Search之后同样的模型效果一下子就正常很多。原因在于贪心只看“每一帧单点最大概率”根本没考虑不同候选路径之间的概率累计而Prefix Score干的事情就是把“所有能够折叠成某个前缀的路径概率”全部加起来让搜索老老实实地沿着全局概率最大的方向走。1. 从CTC解码的死胡同说起为什么不能简单取argmax1.1 模型输出的是帧级概率不是文本CTC模型Connectionist Temporal Classification在训练时输入是一段序列比如语音的梅尔频谱帧、OCR里按列切好的图像特征输出是每个时间步在各个标签上的概率分布。这里有一个容易混淆的点模型从头到尾都没有直接输出“这段音频说的是什么字”它输出的只是一张形状为[T, C]的矩阵T是时间帧数C是字符类别数包含一个特殊的blank符号通常下标是0。blank符号是CTC里最容易被误解的东西。它不是“空格”更不是“静音”而是专门用来分隔相邻重复字符的分隔符。举个最简单的例子标签序列是ab如果模型在连续两帧都输出字符a那么这两帧必须被blank隔开才有可能折叠成单个a。要是没有blankaa折叠后会被压缩成a就少了字符。所以任何提到CTC解码的讨论都绕不开blank这个特殊角色。1.2 贪心折叠为什么经常翻车既然模型只给帧级概率最简单的解码方式就是对每一帧取概率最大的标签得到一条“最佳路径”比如a _ b b _ c然后把连续重复的字符合并再把blank删掉就得到abc。这条路径通常叫greedy decode。很多框架甚至直接提供了这个功能看起来又快又稳。但问题在于这条单一路径的概率最大不等于折叠后文本的概率最大。举个具体例子若某个字符a在帧1概率0.4、帧2概率0.4而blank在第1帧概率0.35、第2帧概率0.35单看每一帧a都是赢家贪心会输出aa折叠后是a。但另一条路径a _ a的概率是0.4×0.35×0.40.056而贪心路径a a a的概率是0.4×0.4×0.40.064确实更大。可一旦概率分布没那么“尖锐”有大量中间路径同时指向同一个文本结果单条路径的概率就完全不能代表最终文本概率了。CTC整个设计的基本思想就是把所有能折叠成目标序列的路径全部加起来。如果你在解码时只取一条路径等于把CTC最核心的“总和”机制丢掉了。1.3 需要的是一个能累计“多路径”的前缀分数所以解码的正确姿势是在时间步t上维护一个正在生成的前缀prefix计算“到目前为止所有可能折叠成这个前缀的路径概率之和”。这个和就是本文的主角——Prefix Score。有了前缀分数你可以这样搜索从空前缀开始每走一帧就尝试在当前前缀后面追加一个字符或者保持当前前缀不变计算所有候选前缀的分数按分数排序保留top K个继续往下走这就是Prefix Beam Search。它和整句暴力枚举不同不是等路径完整生成后再折叠而是一边累积一边折叠每一帧都在维护“已经折叠好的前缀文本”以及对应的累计概率。这是CTC解码里最核心也是最值得抠明白的算法。2. Prefix Score的数学骨架两组状态递归2.1 记号先约定清楚为了避免后面公式看得云里雾里先统一定义几个符号T时间帧数总共有1...T帧。C字符类别数包括blank。blankblank符号的索引约定为0。labels当前要计算的前缀标签序列长度为L比如[a, b, c]。P(k, t)模型在第t帧输出字符k的概率。p_b(i, t)到第t帧为止已经生成的前缀为labels[0:i]并且第t帧的输出是blank时的累计概率。p_nb(i, t)到第t帧为止已经生成的前缀为labels[0:i]并且第t帧的输出是labels中的某个非blank字符时的累计概率。这里labels[0:i]是前缀的前i个字符注意都是在“去掉blank并折叠重复字符之后”的文本前缀不是原始帧标签序列。举个实例如果labels [a,b]i1那么前缀就是a。2.2 核心递推式延续与扩展Prefix Score的递推本质上只有两个动作延续和扩展。每个时间步上要用新的概率去更新。先看延续。在时间步t如果当前前缀已经确定为labels[0:i]那么为了保持这个前缀不变第t帧可以输出blank也可以直接输出labels[i-1]。为什么输出labels[i-1]也算延续因为前缀是折叠后的文本帧标签序列里连续出现同一个字符折叠后还是同一个字符。所以上一时刻分数为p_b(i, t-1)和p_nb(i, t-1)这一帧乘上对应输出符号的概率就是延续到现在的分数。再看扩展。前缀本来就是一步一步“追”出来的当前时刻加入第i个字符labels[i-1]意味着上一时刻前缀还只有i-1个字符。这个扩展动作只能在本帧输出labels[i-1]时发生对应的上一帧状态是p_b(i-1, t-1)和p_nb(i-1, t-1)。都加上求和就能得到递推式p_b(i, t) (p_b(i, t-1) p_nb(i, t-1)) * P(blank, t) p_nb(i, t) (p_b(i, t-1) p_nb(i, t-1)) * P(labels[i-1], t) Γ * P(labels[i-1], t)其中Γ是扩展项。关键分歧点在于Γ怎么取和“当前要加入的字符与已存在前缀的最后一个字符是否相同”直接相关若i 1表示向空前缀添加第一个字符扩展项来自空前缀状态Γ p_b(0, t-1) p_nb(0, t-1)。若i 1且labels[i-1] labels[i-2]也就是准备添加的字符和前一个字符相同比如前缀是a准备加一个a变成aa。这时候扩展项只能从p_b(i-1, t-1)来因为两个相同字符之间必须隔着blank否则a a会被折叠成a和aa不符。若i 1且labels[i-1] ! labels[i-2]则扩展项可以同时来自p_b(i-1, t-1)和p_nb(i-1, t-1)。这就是标准化CTC前缀递推里最容易被写错的细节后面我专门用例子演示一下。2.3 为什么要区分blank结尾和非blank结尾很多人刚开始看这个递推很不适应分开维护两个数组不是多此一举吗其实这是整个递推能否正确工作的关键。原因在于折叠过程会对路径做“模糊化”处理一个最终文本前缀可能对应非常多不同的原始帧标签序列它们的最后一个可见符号既可能是blank也可能是某个真实字符。在下一帧延续时这两种状态的自由度不一样。如果上一状态以blank结尾下一帧输出任何字符都是自由的。如果上一状态以非blank字符X结尾下一帧仍然可以输出X因为连续XX折叠后还是X但如果下一帧输出与X不同的字符Y前缀就要扩大为XY这和“延续当前前缀”是两码事。硬把这两类状态合并成一个数字就丢失了“上一帧最后输出是不是blank”这个关键信息导致那些需要靠blank隔开的字符路径没法正确累积。所以两个数组缺一不可。2.4 一个小例子看路径是怎么被“算”进去和“排除”掉的假设只有3帧labels [a, b]blank记为_模型给出的概率如下帧1P(a)0.4P(b)0.2P(_)0.4帧2P(a)0.3P(b)0.5P(_)0.2帧3P(a)0.2P(b)0.4P(_)0.4初始化t1空前缀p_b(0,1) P(_, 1) 0.4p_nb(0,1) 0前缀ai1p_b(1,1)0p_nb(1,1) P(a,1) 0.4其余为0。到t2先看空前缀p_b(0,2) p_b(0,1) * P(_, 2) 0.4*0.20.08。前缀ai1p_b(1,2) p_b(1,1)*P(_,2) p_nb(1,1)*P(_,2) 0.08。p_nb(1,2) (p_b(1,1)p_nb(1,1))*P(a,2) (p_b(0,1)p_nb(0,1))*P(a,2) 0.4*0.3 0.4*0.3 0.24。前面一项对应延续已有的a后面一项对应从空前缀扩展出a。这里两条路径都折叠成前缀a。前缀abi2p_b(2,2) 0。p_nb(2,2) (p_b(2,1)p_nb(2,1))*P(b,2) (p_b(1,1)p_nb(1,1))*P(b,2)。第一项为0第二项为0.4*0.50.2这对应原始帧路径a b直接拼出ab。到t3这些分数各自继续滚动。可以看到ab的前缀分数最后会把a b b、a _ b、a b _ b之类的路径都累积进来同时像a a b这种路径因为在折叠后是ab也会进入计数。这就是“把所有能折叠成目标前缀的路径总和”的直观体现。3. 一份可直接运行的Python实现以及和暴力枚举的对拍验证3.1 输入准备仿真一张CTC概率矩阵为了演示我先生成一张完全随机的概率矩阵并且保证每一帧概率归一。后面你也可以直接把真实模型的输出替换进来接口不变。import numpy as np np.random.seed(42) T 6 # 时间帧数 C 5 # 字符数0blank, 1a, 2b, 3c, 4d labels [1, 2, 3] # 目标前缀是 abc # 随机生成概率矩阵并做按帧归一化 raw np.random.rand(T, C) probs raw / raw.sum(axis1, keepdimsTrue) print(probs.round(3))这个矩阵可以理解为模型在某段6帧输入上给出的输出概率分布。3.2 Prefix Score核心实现下面这段代码把第二节的递推式原样翻译成Python。为了清楚起见我用了new_pb和new_pnb两个新数组避免原地更新时出现脏读。def ctc_prefix_score(probs, labels, blank0): probs: shape [T, C]已经按帧归一化的概率矩阵 labels: 标签索引序列不含blank 返回: 前缀折叠后等于 labels 的总概率 T, C probs.shape L len(labels) # p_b[i]表示到当前帧为止前缀labels[:i]且最后一位是blank的累计概率 # p_nb[i]表示到当前帧为止前缀labels[:i]且最后一位是非blank的累计概率 p_b [0.0] * (L 1) p_nb [0.0] * (L 1) # 初始化 t1 p_b[0] probs[0, blank] # 空前缀最后一帧输出blank if L 0: p_nb[1] probs[0, labels[0]] # 空前缀扩展出第一个字符 for t in range(1, T): new_pb [0.0] * (L 1) new_pnb [0.0] * (L 1) # 空前缀只能持续输出blank new_pb[0] (p_b[0] p_nb[0]) * probs[t, blank] for i in range(1, L 1): cur_char labels[i - 1] # 保持当前前缀不变上一帧输出blank或继续输出当前字符 keep_blank (p_b[i] p_nb[i]) * probs[t, blank] keep_char (p_b[i] p_nb[i]) * probs[t, cur_char] # 从前缀labels[:i-1]扩展出当前字符 if i 1: extend_char (p_b[0] p_nb[0]) * probs[t, cur_char] elif cur_char labels[i - 2]: # 和前一个字符相同必须由blank结尾状态扩展 extend_char p_b[i - 1] * probs[t, cur_char] else: extend_char (p_b[i - 1] p_nb[i - 1]) * probs[t, cur_char] new_pb[i] keep_blank new_pnb[i] keep_char extend_char p_b, p_nb new_pb, new_pnb return p_b[L] p_nb[L]核心就是循环里的四五条式子。你直接把真实CTC模型的输出概率矩阵传进来把当前要计算分数的字符序列传给labels返回的就是Prefix Score——整个前缀labels在整段输入上折叠后的总概率。3.3 对拍验证把每一条路径都拆开算一遍为了确认这段实现没有写错最可靠的方式是暴力枚举。对于6帧、5个字符所有可能的原始路径组合一共是5^6 15625条完全可以枚举。from itertools import product def collapse(path): 把帧标签序列折叠成文本标签序列去连续重复删blank。 out [] prev None for sym in path: if sym ! blank and sym ! prev: out.append(sym) prev sym return out def brute_force(probs, labels, blank0): T, C probs.shape total 0.0 for path in product(range(C), repeatT): prob 1.0 for t, sym in enumerate(path): prob * probs[t, sym] if collapse(list(path)) labels: total prob return total total_prefix ctc_prefix_score(probs, labels) total_brute brute_force(probs, labels) print(prefix score:, total_prefix) print(brute force :, total_brute) print(diff:, abs(total_prefix - total_brute))只要两个数值在小数精度误差内一致就说明递推逻辑没问题。实际跑的时候绝大多数情况都能对得上。如果你自己改动过递推建议保留这个对拍函数作为回归测试后面改代码再也不怕改坏。简单解释一下对拍设计的思路暴力枚举的“基准答案”是绝对正确的因为它直接按CTC折叠定义算而Prefix Score是用动态规划压缩复杂度后的结果。两者能对上说明压缩过程没有丢掉路径、也没有重复计算。以后你在工程里改成了log域计算、加快beam search也要记得用真实小样例跑一跑这个对拍防止引入隐蔽的精度或逻辑错误。4. 把它搬进Beam Search工程上的组织方式与优化4.1 Beam里如何用前缀分数做剪枝明白了单条前缀的分数怎么算下一步就是把整个搜索树铺开。Prefix Beam Search的基本结构是维护一个字典beam键是目前的前缀标签序列值是(p_b, p_nb)两个浮点数。对每一帧把beam里每一个前缀使用类似上面的递推公式扩展出一个“保持当前前缀”的分数以及若干个“追加一个新字符”的分数。把所有新前缀放到一起按总分排序只保留Top K条。这里有一个容易迷惑的地方beam里的前缀不是原始帧路径而是已经折叠好的文本前缀。比如既有原始路径a _ b又有a b _都会折叠成ab于是它们在字典里的键都是ab概率自动合并。这就是前缀分数天然支持beam search的原因它已经把“同文本不同路径”的概率合并好了搜索时只需要比较文本前缀而不是去比较海量原始路径。4.2 合并相同前缀字典和“上次发射字符”的配合实际工程实现时每个beam条目至少要记录三样东西prefix当前文本前缀比如[a, b]p_b以此前缀结尾、且最后一帧输出blank的累计概率p_nb以此前缀结尾、且最后一帧输出非blank的累计概率为什么不用单独记忆“最后一帧输出的是什么字符”因为非blank状态一定对应前缀的最后一个字符而blank状态没有任何字符所以这两个状态已经完整表达了所需信息。扩展时只需从prefix的最后一个字符判断能不能直接追加相同字符。如果候选新字符和前缀最后一个字符相同就只能从p_b扩展否则可以从p_b p_nb扩展。在我的工程实现中扩展新字符时并不会真的对每个字符都去算一次递推而是先从当前帧的概率分布里挑出Top M个非blank候选字符。因为大部分字符的概率都很小全部展开只会浪费算力。这个Top M一般取beam宽度的2到3倍就够用了如果你有词典约束再进一步过滤。4.3 Log域计算的必要性以及数值下溢上面写的Python实现直接用概率值做乘法短序列没问题但CTC的输入动辄几百帧甚至上千帧每条路径要连续乘几百个小于1的数概率很容易下溢到0。工程上必须把乘法换成加法全程在log域计算。log域的核心操作有两个log乘log(a*b) log(a) log(b)这个直接加。log加log(ab)不能直接算要写成log_add(log_a, log_b)实现如下import math def log_add(log_a, log_b): if log_a float(-inf): return log_b if log_b float(-inf): return log_a if log_a log_b: log_a, log_b log_b, log_a return log_a math.log1p(math.exp(log_b - log_a))math.log1p比log(1 ...)更稳当指数部分很小时也几乎不丢精度。beam search里所有p_b、p_nb的相加都要换成log_add所有概率相乘都要换成加法。我之前有个项目贪心解码正常、暴力的概率乘法都快归零了导致输出全是空白改成log域后立刻恢复正常这是CTC解码里最常见的问题之一。4.4 加入语言模型和外挂词典的时机生产环境的语音识别和OCR通常不会只靠CTC的声学/视觉概率还要叠加一个语言模型分数让输出的句子更通顺。很多教程会直接把语言模型分数加到beam排序上这个简单粗暴的做法会引起一个严重问题Prefix Score是中间前缀的累计概率而语言模型通常只对完整句子评分你拿整句的语言模型分加到一半前缀上长度失配。比较稳妥的做法是引入一个“外挂语言模型”分数在每次扩展新字符后给prefix追加该字符然后计算一个基于该前缀的语言模型增量分并把它加到beam分数里。因为语言模型通常有token级别的条件概率这个增量分可以表示为lm_score(prefix char) - lm_score(prefix)这样既保留了前缀分数的结构又把LM的歧视信息一点点织进去。需要特别注意的是beam排序用的“总分”和“Prefix Score本身”是两回事。总分是为了剪枝排序用的真要输出最终完整句子的置信度还得把扩展过程中的LM增量分数也累积起来并在末尾进行归一化否则不同长度的句子分数没有可比性。5. 实战中踩过的坑和调试经验5.1 时间维度和标签维度的边界条件边界条件是我每次重写Prefix Score最容易翻车的地方。具体来说有三个位置一是t1的初始化。如果第一帧概率分布里某个字符概率特别小也不影响因为没有别的路径可走它就是从空前缀出发的第一跳。二是p_b[0]必须单独更新不能混进普通循环因为空前缀没有“非blank状态”它永远只能输出blank。三是当i访问到labels[i-2]时要保证i2否则越界。下面这个场景我遇到过好几次把前缀长度枚举从1循环到L却忘了i0的空前缀状态结果所有从空前缀扩展出来的路径全部丢失导致分数比真实值小。排查方法也很简单拿一个极短的样例人工推一遍或者用前面的暴力枚举对拍。5.2 连续相同token的“只允许发射一次”规则连续相同字符的扩展限制是CTC里最反直觉的一条。前缀a追加字符a变成aa时扩展项只能来自p_b[i-1]也就是上一时刻前缀为单个a且最后输出是blank的路径。为什么不能用p_nb[i-1]因为如果上一帧最后输出的是非blank字符a本帧再输出a原始帧序列是a a折叠后还是a根本得不到aa。只有上一帧输出blank原始帧序列是a _ a折叠后才是aa。这个限制在代码里就是一行if cur_char labels[i - 2]的判断但很多人一开始写会忽略。漏掉这条规则的直接后果是重复计数本帧输出a既被算作“延续前缀a”又被算作“扩展成aa”同一批路径在两个状态里各算了一遍最终分数虚高。如果你测出来的分数比暴力枚举大十有八九就是这个原因。5.3 空前缀与首字符是blank的情况再强调一遍CTC的blank符号是blank0的独立符号不是空格。解码时空前缀的p_nb恒为0因为它没有任何非blank输出而空前缀的p_b会随着时间累积。很多人在扩展第一个字符时会用p_b[0]或p_nb[0]单独挑一个这不对应该是两者相加——虽然p_nb[0]通常是0但写在一起才是语义完整的状态。反过来如果扩展出来的第一个字符是blank那就不是“扩展”而是“空前缀延续”必须回到new_pb[0]分支否则会平白多出一堆以blank开头的伪路径。5.4 别把解码算法和CTC Loss混为一谈另外还有一个认知层面的坑CTC Loss在训练时的前向计算其实和Prefix Score递推有相似之处但目的完全不同。训练时我们不知道最终文本需要穷举所有能折叠成目标标签的路径来最大化概率解码时我们在已知模型输出的情况下搜索最可能的文本。两者都用到了前缀累积技巧但训练时“允许跳过某些字符”没有上限解码时则必须维护一个明确的beam集合并排序。如果你把训练过程里的前向变量直接挪来做解码经常会出现分数偏高且搜索空间失控的情况。真要做解码仍然是Prefix Beam Search这一套更合适。5.5 带中间矩阵打印的调试代码最后送一段我常用的调试片段。当分数对不上、又不想靠肉眼盯时把每个时间步的p_b、p_nb打印出来对照手工推导检查。def debug_ctc_prefix_score(probs, labels, blank0): T, L probs.shape[0], len(labels) p_b [0.0] * (L 1) p_nb [0.0] * (L 1) p_b[0] probs[0, blank] if L 0: p_nb[1] probs[0, labels[0]] print(t1) print(pb :, [round(x, 4) for x in p_b]) print(pnb :, [round(x, 4) for x in p_nb]) for t in range(1, T): new_pb [0.0] * (L 1) new_pnb [0.0] * (L 1) new_pb[0] (p_b[0] p_nb[0]) * probs[t, blank] for i in range(1, L 1): c labels[i - 1] new_pb[i] (p_b[i] p_nb[i]) * probs[t, blank] new_pnb[i] (p_b[i] p_nb[i]) * probs[t, c] if i 1: new_pnb[i] (p_b[0] p_nb[0]) * probs[t, c] elif c labels[i - 2]: new_pnb[i] p_b[i - 1] * probs[t, c] else: new_pnb[i] (p_b[i - 1] p_nb[i - 1]) * probs[t, c] p_b, p_nb new_pb, new_pnb print(ft{t1}) print(pb :, [round(x, 4) for x in p_b]) print(pnb :, [round(x, 4) for x in p_nb])每次改完递推我都会先用一张很小的随机概率矩阵跑这个函数再配合暴力枚举对拍。只要T不超过5、字符数不超过5枚举完全跑得动几分钟就能确认实现是否正常。这段代码也是我自己在新项目里复用率最高的片段之一。CTC Prefix Score计算看着只是几行递推真正掌握后解码端的很多问题都能迎刃而解。无论你是做语音识别、OCR还是手写识别只要模型输出的是帧级标签概率前缀分数的计算思路都是一样的。先把不带beam的朴素前缀分数跑通再往上加beam宽度、语言模型、词典约束每一步都拿小样例验证方向就不会跑偏。

CTC解码核心：Prefix Score递推与Beam Search实战

相关推荐

instagram-private-api 创建群聊线程响应详解：DirectRepositoryCreateGroupThreadResponseUsersItem 接口字段全解析

ASP.NET Core实现苹果登录后端验证：identityToken验签与token换取实践

PyTorch加载训练模型预测新数据的四大关键断层与工程化实践

更多资讯

caveman：极简轻量级工具集的“穴居人”哲学

SSM+Vue旅游管理系统毕业设计全栈开发指南

如何安装Shrimply：Flatpak、Docker与源码构建的3种快速上手指南

T100 ERP客制化实战：导入jar包并调用方法的完整指南

Java二次开发JMeter构建分布式压测平台

开火车种果树任务全攻略：玩法拆解、组队效率与避坑经验

今日更新

防关联浏览器哪个好？三款产品实测差异解析

2026钢铁行业AI转型系统选型对比：多基地排产、大宗原燃料采购与质量追溯，六家厂商能力差异在哪里

影刀RPA深度实战：大模型Fine-tuning定制RPA专用Prompt与指令生成

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？