解码器采用束搜索策略，在准确率与速度间取得良好平衡-平芜编程栈

解码器采用束搜索策略，在准确率与速度间取得良好平衡

在语音识别系统走向大规模落地的今天，一个核心矛盾始终萦绕在工程实践中：如何在不牺牲准确率的前提下，让模型“快起来”？尤其是在会议转写、客服质检这类对实时性和精度双高要求的场景中，解码策略的选择直接决定了系统的可用性。

Fun-ASR 作为钉钉与通义实验室联合推出的语音识别大模型系统，正是在这一背景下应运而生。它没有盲目追求理论最优路径，而是选择了一条更务实的技术路线——以束搜索（Beam Search）为核心解码机制，结合热词增强、文本规整等工程优化手段，在真实世界的应用环境中实现了性能与效率的巧妙平衡。

为什么是束搜索？

要理解束搜索的价值，得先看它的对手们。

最简单的解码方式是贪心搜索：每一步都选当前概率最高的词。听起来合理，但问题在于，局部最优未必全局最优。比如音频中有个模糊发音“kāfēi”，模型可能在第一步就误判为“咖啡”而非“卡飞”，后续再怎么调整都无法纠正这个错误。这种“一失足成千古恨”的特性，使得贪心搜索在复杂语境下表现平平。

另一种极端是穷举搜索：遍历所有可能的输出序列，选出整体概率最高的那条。理论上完美，现实中不可行。假设输出长度为100，词表大小为5000，组合数将达到 $5000^{100}$ 级别——即便是超级计算机也无法承受。

于是，束搜索登场了。它像一位经验丰富的侦探，不会只盯着眼前最明显的线索（贪心），也不会把每个角落都翻个底朝天（穷举），而是在关键节点保留多个“嫌疑人”，随着证据积累逐步淘汰弱者，最终锁定最可能的真相。

具体来说，束搜索通过维护一个固定大小的候选集（即“束宽”$B$），在每一步扩展所有活跃路径后，仅保留总得分最高的 $B$ 条路径。这样一来，既避免了指数级爆炸的计算开销，又保留了足够的探索空间来发现那些初始阶段并不显眼但最终更合理的序列。

更重要的是，这种策略天然支持多种工程优化。例如：

长度归一化：防止长句因连乘小概率值导致总分偏低；
提前终止：一旦所有候选均已生成结束符<eos>，立即停止解码；
对数空间运算：用加法代替乘法，规避浮点下溢风险。

这些细节看似微小，实则决定了系统能否稳定运行于生产环境。

def beam_search_decoder(log_probs, beam_width=5, max_len=512): """ 使用束搜索进行解码 :param log_probs: 模型输出的对数概率张量 [T, V]，T为时间步，V为词汇表大小 :param beam_width: 束宽 :param max_len: 最大输出长度 :return: 最优输出序列 """ T, V = log_probs.shape candidates = [([SOS_TOKEN], 0.0)] for t in range(T): new_candidates = [] for seq, score in candidates: if seq[-1] == EOS_TOKEN: new_candidates.append((seq, score)) continue current_log_prob = log_probs[t] for next_token in range(V): new_seq = seq + [next_token] new_score = score + current_log_prob[next_token] new_candidates.append((new_seq, new_score)) new_candidates.sort(key=lambda x: x[1], reverse=True) candidates = new_candidates[:beam_width] if all(seq[-1] == EOS_TOKEN for seq, _ in candidates): break return candidates[0][0]

这段代码虽简洁，却浓缩了解码的核心逻辑。其中使用对数概率而非原始概率，是为了避免多个小于1的小数相乘导致数值下溢；而每次迭代后的排序与截断，则是控制计算复杂度的关键所在。实际部署时，还会引入缓存机制、并行扩展等进一步优化性能。

在 Fun-ASR 中，束搜索不只是算法

如果说基础束搜索解决的是“怎么找最好路径”的问题，那么 Fun-ASR 的真正优势在于：它把束搜索嵌入到了一个完整的工程闭环中，使其能适应多样化的现实需求。

举个例子，你在做一场关于“AI开放平台”的发布会录音转写。如果只是跑标准解码，模型可能会把“OpenAPI”听成“open a pie”或者“欧朋阿皮”。这不是模型能力不足，而是某些专业术语在训练数据中出现频率太低。

这时候，热词融合就派上了用场。

def apply_hotword_bias(logits, hotwords, vocab, bias_value=2.0): for word in hotwords: if word in vocab: idx = vocab[word] logits[idx] += bias_value return logits

原理很简单：在 softmax 前，给指定词汇的 logit 加上一个偏置项。虽然只是一个小扰动，但在束搜索过程中，哪怕是一点点分数提升，也可能让原本排在第6位的正确路径进入前5名的保留名单，从而避免被剪枝丢弃。

这种方法被称为“浅层融合”，实现成本极低，效果却非常显著。尤其适合处理品牌名、产品术语、人名地名等低频但关键的信息。在 Fun-ASR 的 WebUI 中，用户只需输入几个关键词，系统就能动态调整解码倾向，无需重新训练模型。

另一个容易被忽视但极其重要的环节是逆文本规整（ITN, Inverse Text Normalization）。

试想一下，如果你得到的转写结果是：“我们预计二零二五年营收达到一千二百三十四万元”，显然不如“2025年营收达到1234万元”来得清晰易读。ITN 就负责完成这类转换——将口语化的数字、日期、单位自动标准化，极大提升了输出文本的可用性。

有趣的是，ITN 并不在束搜索内部运行，而是作为后处理模块存在。这意味着它可以独立迭代升级，不影响主干解码流程。这种模块化设计，正是工业级系统区别于学术原型的重要标志。

实际应用中的权衡艺术

Fun-ASR 的系统架构清晰体现了这种工程思维：

[用户端浏览器] ↓ (HTTP/WebSocket) [FastAPI 后端服务] ↓ [Fun-ASR 模型引擎] ├── VAD 模块 → 分割音频 ├── Encoder → 提取声学特征 └── Decoder + Beam Search → 生成文本 ├── 热词增强 └── ITN 规整 ↓ [SQLite 数据库] ←→ [历史记录管理]

从前端上传文件，到后端调度推理任务，再到结果存储与追溯，整个链条高度自动化。特别是在批量处理模式下，系统可以一次性完成数十小时的会议录音转写，全程无需人工干预。

但这背后，仍有许多需要权衡的地方。

比如束宽设置。理论上越大越好，但每增加一个候选路径，内存和计算开销都会线性上升。在 GPU 显存有限的设备上，束宽从5调到10可能导致 batch size 减半，反而降低吞吐效率。我们的实践经验是：多数场景下设为5即可获得满意结果；若追求极致准确率且资源充足，可尝试8–10，但超过12后收益急剧衰减。

再如热词数量控制。虽然技术上可以注入上百个热词，但如果太多词汇同时获得加分，相当于没加分——模型会陷入困惑，反而影响正常语义理解。建议优先添加那些发音相近、易混淆的专业术语，总量控制在50以内为佳。

至于硬件适配，我们也做了充分考量：