热词怎么配：让 ASR 认出你的专有名词

2026-08-24

会议录音丢给识别系统，日常对话转得挺顺，一到自家产品名、客户公司名、同事姓名就开始胡写——这是语音识别落地最高频的一类抱怨。

问题不在于模型”不行”。通用 ASR 模型对某个词的先验概率来自训练语料，而你的专有名词在那份语料里几乎不出现。 它不是听不清，是在几个发音相近的候选里选了更”熟”的那个常见词。

上下文偏置（contextual biasing），俗称热词，就是纠正这种先验偏差的机制，作用在识别管道的解码与后处理环节（管道分环见语音识别是怎么工作的）。

热词到底在改什么

解码本质上是在一堆候选文字序列里挑得分最高的那条，得分由声学得分（这段音有多像这串字）和语言得分（这串字作为一句话有多合理）构成。

假设你的产品叫”启连”。声学上”启连”和”其联""气链”几乎无法区分，但模型见过”其联”远多于”启连”，于是”其联”被顶到第一。

热词做的事，就是在打分环节给指定的词额外加一笔分，让它有机会翻盘。 由此可推出三条结论：

热词不改变声学模型，只在候选排序阶段起作用。音频糊到听不清的词，热词救不回来。
热词是加分不是强制。提高的是概率不是保证，“配了还偶尔错”属正常。
加分有代价。给某个词加分，等于同时给它的发音近邻减分——这就是后面要讲的误触发。

三类主流做法

做法	作用位置	生效方式	典型适用
解码期浅融合	解码打分时	命中热词的路径提高权重	端到端模型的通用方案
WFST 词图增强	解码图构建时	把热词编进解码图	传统混合系统的经典路径
提示注入	模型输入时	喂一段含专名的上下文文本	能接受文本提示的模型

解码期浅融合（shallow fusion） 是端到端系统里最常见的一条路。它不动模型权重，只在束搜索的每一步检查候选路径是不是正在拼出某个热词，是就加分。好处是热词表可按请求动态传入——接客服会话时传客户名单，接技术评审时传产品术语表。

WFST 词图增强 是混合系统的老办法。声学模型、发音词典、语言模型三者用加权有限状态转换器（WFST）编译成一张解码图，加新词就是给词典补发音、给语言模型补概率，再重新编译。公开可查的例子是 WeNet——其 README 提到基于 WFST 的解码与语言模型融合，并说明代码借鉴自 Kaldi。

提示注入 门槛最低：识别前喂一段上下文，比如”以下音频来自某公司的产品评审会，参会者包括……”，不需要改解码器。代价是不如前两种可控，模型未必严格照办，表现要靠实测。

KWS 不是热词偏置

这两个概念在中文语境里常被混着叫，一混就会选错技术方案。KWS（keyword spotting，关键词检测/唤醒词） 和热词偏置是两件完全不同的事：

	KWS / 唤醒词	热词偏置
回答的问题	这段音频里有没有出现某个词	完整转写里这个词写得对不对
输出形态	触发信号（有 / 无，外加时间点）	一整段转写文本
模型	通常是独立的小模型，只认几个词	依附于完整的识别系统
部署位置	常年在设备端低功耗常驻监听	在识别请求的解码阶段
关心的指标	误唤醒率、漏唤醒率	字错误率、专名召回

举例就很清楚：你对音箱说”小X小X，把张伟的会议纪要发给我”。“小X小X”走的是 KWS——设备只判断有没有听到唤醒词，判断为”有”就亮灯开始录音，压根不需要转写出这四个字。“张伟”走的是热词偏置——系统必须完整转写整句，并且要在”张伟/章伟/张威”里选对。

由此带出一个常见误读：一些开源语音工具包提供 keyword spotting 能力，比如 sherpa-onnx 的 README 里多处提到 keyword spotting。这是 KWS，只能当作唤醒词/关键词检测的例子，不能拿来论证它支持热词偏置。 把选型建立在这个误读上，做到一半才会发现要的东西根本不在那儿。

热词表怎么整理

热词表的质量，比选哪种做法影响更大。

值得加的词：

高频专名：公司名、产品名、项目代号，尤其是”看起来像普通词组”的那些。
行业术语：领域内高频、通用语料里低频的词。
常出现的人名：会议、客服场景里反复出现的固定名单。
易混的英文缩写：转写系统对字母序列本来就弱。

不该加的词：

本来就识别得对的词。零收益，还白白挤占近音词的空间。
单字、极短的词，或整句长短语。前者发音近邻太多必然误伤，后者按词粒度命中率低。
发音相互冲突的一组词。把”启连”和”其联”都加进去，等于让它们互相打架。
一次性词汇。只在某一场音频出现的名字，走按请求动态传入，别进全局表。

权重怎么试：

从低往高调。先用系统默认或偏低的权重跑一遍基线。
一次只动一个变量。要么调权重，要么改词表，一起改就没法归因。
盯住两条曲线：热词召回（该对的有没有对）和整体错误率（有没有为此赔上别处）。只看第一条会越调越糟。
找到拐点就停。权重上调时召回先快升后趋平，而整体错误率会在某点后开始恶化，拐点前的位置就是你要的。

效果怎么验证：

准备两个测试集：含专名的目标集验证热词生效，不含专名的对照集验证有没有伤到正常内容。建集方法见语音识别测试集怎么建。
中文按字算 CER，理由见中文语音识别为什么用 CER 不用 WER。
不要只看平均值，热词的收益集中在少数几句上，要单独统计专名的识别情况，并把前后对比数据留档。

副作用：权重开大了会误触发

热词权重开得过大，系统会把发音相近的普通词强行识别成热词。 把”启连”设成高权重热词，音频里说的”其实”也可能被拽过去。原本只是一个专名错，现在换来满篇普通词错——总错误率反而升高。

同理，热词表不是越大越好。词表膨胀会让候选空间里的加分项变多、误触发概率上升，有些实现的解码开销还随词数增长。把整本产品手册塞进去，往往比精挑二三十个词更差。

一个可操作的判据：加了某个热词后若对照测试集错误率上升，这个词就该拿掉或降权，无论它看起来多重要。

热词救不了的两类情况

第一类：同音字。

“张伟”和”章伟”发音完全相同，声学信号里没有任何信息能区分。热词在这里无能为力——两个都加，系统还是只能二选一；只加一个，另一个人名必然写错。这不是热词的失败，是任务本身信息不足。 出路只能靠上下文：接入参会者名单、结合前文的部门信息，或允许用户事后修正。

第二类：端到端模型加新词的固有麻烦。

混合系统加新词很直接：改词典、改语言模型，声学模型不用动。端到端模型没有独立的词典和语言模型可改，两类知识糅在同一套权重里，想让它认识新词，要么重训，要么依赖外挂的偏置机制——这正是热词在端到端时代变得重要的原因。两条路线的取舍见端到端 ASR 和传统混合系统，差别到底在哪。

常见问题

问：配了热词，专名还是偶尔错，是不是没生效？

热词是提高概率，不是强制替换，偶尔错属于预期。判断生效与否要对比加热词前后的测试集数据，而不是抽查一两句；若毫无变化，再排查传参格式或这个词有没有进解码路径。

问：热词能不能修正数字格式和标点？

不能，那是另外两个环节的事。“二零二五年”变”2025 年”属于 ITN 逆文本规范化，逗号句号属于标点恢复，它们是独立的后处理模型，混在一起调很容易改错地方。

问：按请求传热词表，和配一份全局热词表，选哪个？

只要接口支持，优先按请求动态传入。场景相关的词表更短、更准，误触发风险低。全局表只放跨场景都成立的词，比如公司自己的名字。至于词表能做多大没有通用答案，取决于具体实现，而且大小本身不是目标。