最大似然序列估计（MLSE）实战拆解：从维特比搜索到工程落地

最大似然序列估计这个词，第一次看到的人多半会被“最大似然”四个字劝退，觉得又是概率论里那套绕来绕去的东西。但如果你做过数字通信接收端的活儿，尤其是信道存在记忆性、当前符号会被前面若干个符号拖累的场景，你就会发现MLSE其实是绕不开的一块硬骨头。它的核心任务很朴素：接收端拿到一串被噪声和码间干扰污染过的采样值，要反推出最可能发送的是哪一串符号序列。注意是“序列”，不是单个符号——这个区别正是它和逐符号判决的根本分水岭。

我打算把这篇写成一份偏实战的拆解，面向两类人：一类是通信、信号处理方向的学生或刚入行的工程师，想搞明白MLSE到底在算什么、为什么这么算；另一类是已经在做接收机实现、被均衡器性能卡住、想回头补理论的人。全文会从它要解决的问题讲起，把维特比搜索这条主干拆开，再落到度量计算、状态设计、复杂度控制这些真正决定能不能跑起来的细节上，中间穿插我自己踩过的坑和几条不那么写在教科书里的经验。读完你应该能自己搭一个能跑的小demo，也知道工程上哪些地方最容易翻车。

1. 先搞清楚MLSE到底在跟谁较劲

1.1 码间干扰才是这事的起因

要理解MLSE，得先接受一个现实：在带宽受限的信道里，你发一个脉冲出去，它不会老老实实只占一个符号周期。脉冲成形滤波器、信道本身的频率响应、接收端滤波器，这几样东西叠在一起，前一个符号的“尾巴”会拖到后面好几个符号的位置上，这就是码间干扰（ISI）。直观地说，就像你在一个回声很重的房间里说话，每个字都会在后面留下几道残响，接收的人听到的是当前字和前面若干字残响的叠加。

传统的逐符号均衡思路是：想办法在采样点上把干扰压掉，让当前采样值尽量只跟当前符号有关。线性均衡、判决反馈均衡都是这个路子。问题是压制干扰这件事本身有代价——它会放大噪声，而且当信道畸变比较严重时，残余干扰怎么都清不干净。MLSE换了个思路：我不去强行消除干扰，我承认干扰存在，并且我知道干扰是怎么产生的（信道的记忆结构），那我就把所有可能的发送序列都过一遍“信道模型”，看哪一个产生的理想波形跟实际收到的采样最吻合。谁的似然最大，就判谁。

这个思路的转变很关键。它把“均衡”问题转化成了“序列检测”问题。代价是计算量，收益是在同样信噪比下更低的误码率，尤其是在严重ISI信道上，这个差距可以拉到好几个dB。

1.2 为什么是“序列”而不是“符号”

很多人第一次接触会问：既然每个时刻都有采样值，为什么不逐时刻做最大似然判决？原因在于信道记忆。当前采样值里混着前面若干个符号的贡献，你单独看某一个采样，根本无法把当前符号的贡献和前面符号的残留分开。换句话说，单个采样携带的信息是“纠缠”的，只有把一整段序列联合起来看，这种纠缠才能被解开。

举个具体例子。假设信道记忆长度是2，也就是当前采样受当前符号和前一个符号影响。你在时刻k收到一个偏大的值，这可能是因为当前符号大，也可能是因为前一个符号大而当前符号中等。单看时刻k你分不清。但如果把时刻k-1的采样也纳入考虑，约束就出来了：时刻k-1的采样同样受它前一个符号影响，两个方程联立，符号的可能性空间就被大幅压缩。序列越长，这种联合约束越强，判决越可靠。这就是MLSE必须“成串”处理的根本原因，也是它天然适合用动态规划来解的原因。

1.3 它和维特比译码是什么关系

这里要澄清一个常见混淆。MLSE本身是一个“准则”——最大似然序列准则；维特比算法是一个“工具”——在网格图上做最短路径搜索的动态规划方法。两者不是一回事，但在ISI信道这个特定场景下，MLSE的最优解恰好可以用维特比算法高效求出，因为信道记忆结构天然构成一个有限状态机，状态数等于“记忆长度上所有可能符号组合”的数量。

所以你会看到很多资料直接把MLSE和维特比均衡混着说。严格讲，MLSE是目标，维特比是实现手段。理解这个区分有实际意义：当状态数爆炸、维特比跑不动的时候，你做的各种简化（比如减少状态、做序列截断）本质上是在“近似MLSE”，而不是在改维特比算法本身。这个视角能帮你在做工程取舍时不迷失。

2. 把信道记忆翻译成网格：状态与转移的设计

2.1 状态到底该存什么

维特比能在MLSE里跑起来，前提是把“信道的记忆”表达成一个有限状态。最自然的做法是：状态就存最近L个已发送符号，L是信道记忆长度。比如符号取自M元星座，记忆长度L，那状态总数就是M的L次方。当前状态加上“下一个要发的符号”，唯一确定了下一时刻的状态，也唯一确定了当前时刻应该观测到的理想采样值。

这里有个容易搞混的点：状态里存的到底是“已经发过的符号”还是“将要发的符号”。不同教材约定不同，实现时一定要统一，否则度量和转移会对不上。我个人的习惯是让状态表示“影响当前及未来采样的历史符号”，也就是时刻k的状态存的是s(k-1)、s(k-2)……s(k-L)。这样从状态i在输入符号s(k)下转移到状态j时，j就是s(k)、s(k-1)……s(k-L+1)，转移关系非常直观，写代码时不容易错。

2.2 网格的规模是怎么涨起来的

状态数是M^L，这个指数关系是MLSE所有复杂度问题的根源。举几个实际数字感受一下：QPSK（M=4）配记忆长度3，状态数64，很轻松；换成16QAM（M=16）配记忆长度4，状态数就是65536，每个时刻还要对每个状态尝试M个输入分支，单时刻分支度量计算量到了百万量级。再往上，比如64QAM配长记忆，基本就没法直接跑了。

这张表不是吓唬人，是让你在动手前先算清楚预算。我见过有人上来就按理论公式搭了个16QAM、L=4的完整网格，跑起来发现一帧要算到天荒地老，回头才发现状态数根本没评估过。先算状态数，再决定要不要做简化，这个顺序不能反。

2.3 分支度量：欧氏距离为什么够用

在加性高斯白噪声假设下，给定发送序列，接收采样服从以理想采样值为均值的高斯分布。取对数似然，与序列相关的项化简下来就是“接收采样与理想采样之差的平方和”，也就是欧氏距离的累加。所以分支度量直接用欧氏距离平方就行，不需要真的去算概率密度。

具体到时刻k、从状态i输入符号s转移到状态j这个分支，理想采样值由信道模型给出：把状态i里的历史符号和当前输入符号一起，跟信道冲激响应做卷积，得到该时刻的期望采样。分支度量就是实际采样减去这个期望值再平方。这里有个实操细节：信道冲激响应从哪来？工程上通常是信道估计模块给的，估计误差会直接反映到度量里，所以MLSE的性能天花板很大程度上被信道估计精度卡着，这一点后面还会展开。

提示：如果你的噪声不是高斯的（比如存在明显脉冲干扰），欧氏距离就不再是最优度量，需要考虑稳健度量或者加限幅预处理。别默认高斯假设永远成立。

3. 维特比搜索的实操骨架

3.1 前向递推的三件事

维特比在MLSE里的每一次递推，本质上就干三件事：算分支度量、做路径度量累加比较、记下幸存路径。用文字描述清楚这三件事，比直接甩公式有用得多。

第一件，对每个状态、每个可能的输入符号，算出这个分支的度量，也就是刚才说的欧氏距离平方。第二件，对每个目标状态，把所有能到达它的分支的“前驱路径度量加上本分支度量”算出来，取最小的那个，作为该状态新的路径度量，同时记下是哪个前驱状态赢的。第三件，把赢的那个前驱记进幸存路径表，供回溯用。整个前向过程走完，每个时刻每个状态都保留了一条“到目前最优”的路径。

这里的关键洞察是：路径度量是可以增量累加的，不需要每步重算整段序列的似然。这正是动态规划省算力的地方——它把“枚举所有序列”这种指数级暴力，压成了“每步只保留每个状态的最优前缀”这种多项式级操作。理解这一点，你就理解了维特比为什么能救MLSE。

3.2 回溯与序列截断的取舍

前向走完，理论上要从最终最优状态往回一路回溯到起点，才能拿到完整的最优序列。但实际系统里帧可能很长甚至连续不断，不可能等整段结束再回溯。工程上的标准做法是“截断回溯”：只保留最近D个时刻的幸存路径信息，每过一个符号就回溯D步，输出最早那个符号的判决。D取多大？经验上取记忆长度的4到5倍通常够用，信道越恶劣、信噪比越低，D要适当加大。

这个截断会带来一点点性能损失，但通常可以忽略。我实测过在QPSK、L=3的配置下，D取15和取全长的误码率曲线几乎重合，再小到D=8就开始能看出差距了。所以D不是拍脑袋定的，建议在你的具体配置下扫一遍D，找到性能拐点，别盲目照搬别人的数字。

3.3 一个能跑的最小实现

下面这段是纯Python的骨架，故意写得直白，方便你对照上面的逻辑。它不追求速度，追求的是把状态转移、度量累加、回溯这三件事讲清楚。

import numpy as np from itertools import product def mlse_viterbi(rx, h, constellation, L, D=None): """ rx: 接收采样序列 h: 信道冲激响应，长度 L+1 constellation: 符号集合 L: 记忆长度 D: 回溯深度，None 表示全长回溯 """ M = len(constellation) states = list(product(constellation, repeat=L)) state_idx = {s: i for i, s in enumerate(states)} n_states = len(states) if D is None: D = len(rx) # 路径度量初始化为0，其余为inf pm = np.zeros(n_states) # 幸存路径表：survivor[k][state] = 前驱状态索引 survivor = [] for k in range(len(rx)): new_pm = np.full(n_states, np.inf) new_surv = np.zeros(n_states, dtype=int) for si, state in enumerate(states): if np.isinf(pm[si]): continue for sym in constellation: # 当前时刻的符号序列：sym 加上历史 seq = (sym,) + state # 理想采样：与信道卷积 expected = sum(seq[i] * h[i] for i in range(L + 1)) bm = abs(rx[k] - expected) ** 2 # 下一状态：丢掉最老的符号 next_state = seq[:L] ni = state_idx[next_state] cand = pm[si] + bm if cand < new_pm[ni]: new_pm[ni] = cand new_surv[ni] = si pm = new_pm survivor.append(new_surv) # 回溯 best = int(np.argmin(pm)) path = [best] for k in range(len(rx) - 1, 0, -1): best = survivor[k][best] path.append(best) path.reverse() # 每个状态对应最后输入的那个符号，取状态元组第一个元素 return [states[p][0] for p in path]

这段代码有几个地方值得说。seq = (sym,) + state这个拼接顺序必须和你的状态定义严格一致，我前面说状态存“历史符号”，这里就是把新符号放最前面。expected那行是信道卷积，如果你的信道模型更复杂（比如有非线性或者分数间隔），这里要相应替换。回溯部分从最后时刻的最优状态往回走，每一步查幸存表，最后把状态元组的第一个元素取出来作为该时刻的发送符号——这个“取第一个元素”的约定同样依赖状态定义，改状态定义就得改这里。

跑通这段之后，你可以拿一个已知的发送序列、过一个带ISI的信道、加高斯噪声，然后看MLSE能不能把原序列恢复出来。信噪比高的时候应该几乎全对，信噪比降下去会开始出错，这个行为符合预期就说明骨架对了。

4. 复杂度压不下来时怎么办

4.1 减少状态：RSSE的思路

状态数M^L压不住的时候，最直接的思路是“少记一点历史”。减少状态序列估计（RSSE）的核心就是：不再完整保留L个历史符号，而是只保留其中一部分，剩下的用某种方式“折叠”或者“近似”。最粗暴的做法是只保留最近L'个符号（L'<L），把更早的历史当成不影响当前采样——这当然会引入模型误差，度量算得不准，但状态数从M^L降到M^L'，可能是从跑不动到跑得动的差别。

这个取舍的本质是：你用一部分检测精度换计算可行性。实际效果取决于信道能量在记忆长度上怎么分布。如果信道冲激响应的能量主要集中在前面几个抽头，后面抽头很小，那砍掉后面的历史损失有限；如果能量分布很分散，砍了就会明显掉性能。所以做RSSE之前，先看一眼信道估计出来的冲激响应，能量集中在哪，决定了你能砍到多短。

4.2 判决反馈：把历史“定”下来

另一个常用手段是判决反馈式的状态缩减：对更早的历史不再保留多种可能，而是直接用已经做出的判决固定下来。这样状态数同样能降，而且比单纯砍历史更“聪明”，因为它利用了已经积累的判决信息。代价是存在误差传播风险——早期判错了，后面会被带偏。工程上常见的折中是混合方案：最近几个符号保留完整状态（保证关键记忆被正确处理），更早的符号用判决反馈固定，兼顾性能和复杂度。

我个人的经验是，误差传播在信噪比不太低的时候问题不大，但在低信噪比或者信道深衰落时会明显恶化。如果你的系统工作点经常落在低信噪比区，判决反馈要慎用，或者配合某种重传/重估机制。

4.3 降低每状态分支数：集合划分

除了减状态，还能减“每个状态要试多少个输入”。集合划分的思路是把星座点分组，先用组级别的粗判决缩小候选，再在组内细判。这本质上是把一次大搜索拆成层次化的搜索，牺牲一点最优性换速度。这类方法在星座阶数很高（比如64QAM以上）时比较有意义，因为那时候每状态的分支数本身就是个大头。

需要提醒的是，所有这些简化都会让结果偏离“真正的最优MLSE”，你在评估性能时不能拿理论MLSE的误码率曲线当基准去要求简化版本，而要拿你的实际需求和可接受损失来权衡。我见过团队为了追那零点几个dB，把复杂度堆到硬件根本吃不消，最后还得推倒重来，这个教训值得记。

5. 那些教科书不写但会咬人的细节

5.1 信道估计误差是隐形杀手

前面提过一句，这里展开说。MLSE的度量计算完全依赖信道冲激响应h，h估得准不准，直接决定理想采样算得对不对。如果h有偏差，你算出来的“最像”的序列可能根本不是真正发送的序列，而且这种错误是系统性的，不是靠提高信噪比能救回来的。实际系统里，信道估计通常用已知的训练序列或者导频来做，估计精度受训练长度、信噪比、信道变化速度共同制约。

一个实用的做法是：在MLSE之外加一层“度量可靠性”的判断，当路径度量的区分度不够（比如最优路径和次优路径的度量差很小）时，标记这个判决为低置信度，交给上层做重传或者软判决合并。这个机制在实测中能明显降低那些“看起来正常实则错误”的隐蔽错误。

5.2 定时和相位没对齐，全盘皆输

MLSE假设你拿到的采样是“符号对齐”的，也就是每个采样点正好对应一个符号周期的理想位置。如果定时有偏差，采样点落在符号过渡区，理想采样模型就对不上，度量全乱。相位偏差同理，会让星座整体旋转，欧氏距离算出来全是错的。所以MLSE前面通常要有可靠的定时恢复和载波恢复，这两块的精度要求比逐符号检测更高，因为序列检测对系统性偏差更敏感。

我踩过的一个坑是：定时环路收敛慢，帧头部分采样没对齐，结果MLSE在帧头连续判错，虽然中段收敛后恢复正常，但帧头那几个错误符号触发了上层重传，整体吞吐反而下降。后来在MLSE前加了个短的前导对齐窗口，问题才解决。这个细节在纯算法仿真里根本遇不到，只有上了实际链路才会暴露。

5.3 初始状态和边界处理

维特比搜索在序列开头，各状态的初始路径度量怎么设？标准做法是：如果知道起始状态（比如发送端每帧开头有已知的同步符号），就把对应状态初始化为0、其余为无穷大；如果不知道，就全部初始化为0，让搜索自己收敛。这两种做法在帧较长时差别不大，但帧很短时，初始化的选择会明显影响帧头几个符号的判决。工程上如果有已知前导，一定要用上，这是白送的先验信息。

序列末尾同理，如果知道结尾状态，回溯时直接从那个状态起回溯，比从全局最优状态起回溯更准。这些边界处理看着琐碎，但在短帧、高可靠性要求的场景里，往往是那最后一点性能的来源。

5.4 数值精度与度量溢出

路径度量是累加的，帧一长，数值会一直涨。用浮点时问题不大，但用定点实现时要注意位宽和饱和处理。度量之间的“相对大小”才是关键，绝对数值大小无所谓，所以可以每个时刻把所有路径度量减去当前最小值做归一化，防止溢出。这个技巧在定点实现里几乎是标配，但仿真时用浮点很容易忽略，等到上硬件才发现溢出，回头改架构很痛苦。

6. 从仿真到落地：我的几条实操建议

6.1 先搭链路级仿真，别急着写高效代码

我强烈建议第一步用最直白的方式把整条链路搭出来：随机比特、映射、过信道（带ISI）、加噪声、MLSE检测、比对误码。这个阶段代码丑一点、慢一点都无所谓，目的是验证算法逻辑对不对。等误码率曲线跟理论或者预期对上了，再去优化速度。反过来，一上来就追求向量化、追求高效，结果逻辑里藏了个状态定义不一致的bug，调试起来会非常痛苦，因为高效代码的可读性通常很差。

6.2 用已知答案做单元测试

MLSE这种带状态机的算法，最容易出的错是状态转移和回溯对不上。我的做法是构造几个“必然正确”的测试用例：无噪声、信道理想（只有主抽头）、发送序列已知，这时候MLSE必须100%恢复。再加一个有噪声但信噪比极高的用例，也应该几乎全对。这几个用例过了，再逐步加噪声、加ISI、加信道估计误差。每加一个因素，观察误码率是不是按预期恶化，而不是突然崩掉——突然崩掉通常意味着某个环节的假设被打破了。

6.3 复杂度评估要趁早

前面表格已经说了状态数的指数增长。我的建议是：在算法设计阶段就把目标配置的状态数、分支数、每帧运算量算出来，跟你的硬件预算（每秒能跑多少次乘加、内存能放多少幸存路径）对一遍。如果对不上，就在设计阶段决定用哪种简化，而不是等实现完了发现跑不动再回头改。幸存路径的存储也是个容易被低估的开销：状态数乘以回溯深度，再乘以每个状态要存的比特数，这个内存量在状态数大、回溯深度深的时候相当可观。

6.4 别忽视软输出的价值

很多现代系统里，MLSE后面还接着信道译码，这时候硬判决（直接输出符号）会丢掉信息。更好的做法是让MLSE输出软信息，比如每个比特的对数似然比。从维特比网格里提取软输出有成熟的方法（比如SOVA或者BCJR类算法），代价是复杂度上升。但如果你的系统有译码环节，软输出带来的增益往往比在检测端抠那零点几个dB更划算。这个取舍要放在整个接收链路的层面看，而不是孤立地看检测模块。

6.5 实测和仿真的差距要留余量

仿真里信道是理想的数学模型，实测里信道有估计误差、有时变、有各种非理想因素。我的一般做法是：仿真得到的性能作为上限，实际系统设计时留出1到2个dB的余量，具体留多少取决于信道估计的精度和信道变化的速度。这个余量不是保守，是给那些仿真里没建模的效应留空间。吃过亏的人都知道，仿真曲线漂亮但实测拉胯，排查起来最费时间的就是那些“理论上不该有”的损失。

7. 一个值得动手的练手项目

如果你想把上面这些东西串起来，我建议做一个小而完整的练手：固定一个短记忆信道（比如3个抽头），用QPSK，发送一段几百个符号的随机序列，加不同信噪比的高斯噪声，分别用“无均衡直接判决”和“MLSE”去检测，画出两条误码率曲线对比。这个项目不大，但能让你亲眼看到MLSE在严重ISI下相对逐符号检测的优势，也能让你在调参过程中体会状态定义、回溯深度、信道估计这些细节的实际影响。

做完基础版，可以往上加：把信道换成时变的，看MLSE性能怎么退化；把信道估计换成带误差的，看误差怎么传导；把状态数人为砍一半做RSSE，看损失多少。这几个扩展做下来，你对MLSE的理解就不是停留在公式层面了，而是有了手感——知道哪个环节最脆弱、哪个参数最敏感、哪种简化在什么条件下可接受。这种手感，是看多少篇论文都换不来的。

最后分享一个我自己反复验证过的小体会：MLSE这类算法的难点从来不在“公式推导”，公式在教科书里写得清清楚楚；难点在于把公式翻译成能跑、跑得动、跑得对的代码，而这个翻译过程里藏着大量约定和边界条件。状态怎么定义、回溯怎么截断、度量怎么归一化、软输出怎么提取，每一个选择都会在最终性能上留下痕迹。把这些约定在动手前想清楚、在代码里写明白，比事后调bug省太多时间。