同一段会议录音，普通话转写看起来没有问题，换成企业内部的项目代号、产品型号或流程缩写，错误就会明显增多。做过语音项目的人通常不会把这件事简单归结为“模型精度不够”。很多时候，模型听到了一个相近的音，只是没有足够的业务上下文帮助它做选择。
一张词表，往往比一轮泛泛的调参更有用
整理词库时，最容易犯的错误是把所有词都堆进去。真正能帮上忙的词表，应该能说明词的读法、出现的场景和容易混淆的写法。
比如项目代号“极光”，在会议里可能和“激光”同时出现；某个产品型号里有字母和数字，口头表达又可能有多种读法。把这些情况记录下来，再配上几段真实录音，后面的验证才有依据。只给出一串词，不说明词在什么句子里出现，通常很难判断它到底有没有起作用。
词表还需要分层。部门名称、产品名、客户名和临时项目名的更新频率不同，应该分开维护。长期不变的词可以进入基础配置，季度变化的词放到业务词表，临时会议中的专名则适合通过任务级配置传入。这样做的好处是回滚简单，也不会因为一次临时活动把常规转写弄得过于敏感。
热词能解决什么，不能解决什么
热词机制通常是在解码阶段提高某些候选词的优先级。它对专名、缩写和固定短语很有效，但它不是重新训练模型。音频质量很差、说话速度很快，或者句子的上下文已经明显指向另一个词时，单纯提高权重反而可能带来新的误识别。
实际使用中，热词最好设一个观察期。上线前用包含目标词和相似词的录音做一轮对照，上线后抽取少量错误样本，看看是目标词漏识别多，还是相似词被误替换多。如果后一种情况变多，就需要降低词权重、补充上下文，或者重新检查录音采集环节，而不是继续增加词表数量。
没有标注数据时，先把文本校验做扎实
不少企业手里有大量业务文档，却没有成规模的人工标注语音。这个阶段可以先把识别结果接入文本校验流程：检查专名是否被拆开、型号中的数字是否丢失、部门和人名是否出现异常替换，再把高频错误回写到词表中。
文本校验适合处理格式稳定的内容，例如产品编号、合同编号、药品名称和固定部门名称。它不适合替代声学模型，对口音、重叠说话和远场噪声造成的错误，仍然需要从麦克风、降噪、切分和模型本身去排查。把所有问题都交给后处理，最后往往会得到一套越来越复杂、却很难维护的替换规则。
有条件的团队可以从高价值片段开始做小规模标注。不必一上来就标几万小时，先选出最常错的几十个术语，覆盖不同说话人、不同设备和不同噪声环境，做成一组固定回归集。每次更换模型、调整热词或升级推理服务，都用同一批音频重跑，结果会比凭印象判断可靠得多。
本地部署还要考虑词库的权限和版本
涉及客户名称、项目代号或内部流程的词表，本身就可能属于敏感业务资料。放在离线 ASR 环境里时，词库文件、更新日志和测试音频应当跟模型配置一样纳入权限管理。谁提交了词，谁审核过，哪次发布生效，都要能追溯。
部署在内网并不等于维护工作消失。服务器更换、驱动升级、推理框架切换，都可能改变热词效果。比较稳妥的做法是把词表和模型版本拆开记录，发布前先在一台验证节点上测试，再逐步切换生产节点。遇到效果回退时，可以快速判断是词表、模型还是运行环境发生了变化。
企业 ASR 适配很少靠一个“自学习按钮”完成。更实用的路径，是把术语整理、音频抽检、识别结果复核和版本发布接成一个小闭环。这个闭环足够简单，业务人员愿意参与，技术人员也能在出现问题时找到具体的排查入口，系统才会随着业务变化稳定下来。
