让模型认识一个行业词，没想象中简单
“把模型调得更懂行业”听起来很顺，但工程团队真正开始做时，往往先遇到数据问题。录音来自不同设备，音量和采样率不一致；同一个设备名称在不同部门有不同叫法；人工转写稿里还可能混着简称、错别字和没有时间戳的整段文字。这样的数据直接拿去训练，模型学到的未必是行业知识，也可能只是某批录音的特殊噪声。
FunASR 及其相关模型可以作为中文语音项目的技术基础，但它不会替项目方自动完成数据清洗、词表管理和效果验收。真正有价值的工作，是把这些环节拆开，让每一次调整都能说明原因。
先整理语料，再决定要不要微调
一套可用的行业语料至少需要四类信息：音频文件、人工校对文本、说话起止时间，以及场景标签。场景标签可以记录电话、会议室、车间或户外采集，也可以记录是否存在多人抢话、背景音乐和方言。
整理时应先统一编码和采样率，再处理静音、重复上传和过短片段。长录音不能只按固定时长切开，最好结合语音活动检测保留完整的句子边界。切片前后都要保存原文件索引，否则一旦发现某个词的效果下降，很难回到原始音频重新确认。
文本校对也要有规则。数字、单位、英文缩写、机构名称和人名，应当提前约定写法。若同一个词出现多种写法，训练集和测试集必须保持一致，否则评测结果会被格式差异干扰。
热词表能解决什么
不是所有识别错误都需要训练模型。设备型号、项目名称、药品名和固定机构名，通常可以先用热词或后处理规则验证。这样改动小、回滚快，也方便业务人员参与维护。
但热词的作用有边界。它更适合处理稳定的词汇，不适合解决持续噪声、口音变化和复杂句式。热词权重设得过高，还可能把普通词误替换成专业词。上线前要专门抽查“正确命中”和“错误强行替换”两类结果，不能只统计命中数量。
把词表按业务线和版本拆开也很重要。金融部门的客户名称，不应自动进入医疗部门的识别规则；临时项目编号过期后，应当能够被撤下。规则更新记录要跟着任务保存，之后才能解释某次转写为什么和上周不同。
微调改变的是分布，不是魔法
当错误持续出现在同一类发音、口音或句式里，才有必要考虑微调。训练数据不必追求数量堆积，覆盖真实场景更重要。安静朗读样本很多，却没有会议抢话、电话压缩和远场混响，模型上线后仍然会遇到原来的问题。
LoRA 等参数高效方法可以减少训练资源，但仍需要明确训练集、验证集和独立测试集。三者不能简单随机切分同一段录音，否则相邻片段泄漏会让结果看起来过好。模型版本、训练参数、数据版本和词表版本都应记录在案。
验收时至少看四个方面：普通词是否被误改，行业词是否稳定，句子是否出现重复，以及时间戳是否仍然可信。若模型把某个术语识别对了，却把周围句子切得七零八落，业务人员未必会认为它变好了。
离线验证要接近真实环境
实验室里跑通并不代表内网部署顺利。正式验证应使用最终硬件、最终驱动和最终音频接入方式，测试断网、服务重启、任务重试和磁盘占满等情况。批量任务和实时任务同时运行时，还要观察队列是否互相影响。
对于高风险场景，识别结果不能直接代替人工判断。司法记录、医疗录入和金融质检都需要保留原音频、时间戳和修订过程，必要时由业务人员确认关键字段。系统的责任边界写得越清楚，后续维护越容易。
行业微调真正改变的，不只是模型权重，还包括数据规范、评测方法和上线后的反馈循环。采用哪一个开源模型只是起点，能否把错误收集回来、把规则管起来、把版本退得回去，才决定这套语音系统是否适合长期使用。
还有一个实际问题是数据代表性。能源巡检录音里可能有风机和泵组的持续噪声，法庭录音有翻页、咳嗽和多人插话，医疗语音则会出现医生口述、患者回答和设备提示音。把这些音频都归到一个“行业数据集”里，模型很难知道哪些声音应该忽略，哪些词必须保留。
训练前后可以做小规模的消融测试：只换词表，观察术语变化；只换音频预处理，观察噪声条件变化；只换微调模型，观察句式和口音变化。这样虽然慢一些，却能分辨效果究竟来自哪里，避免把所有改善都归到微调头上。
交付时还要把数据脱敏和删除流程写清楚。用于训练的录音可能包含姓名、账号和案件信息，未经处理就进入训练目录，会给项目带来新的风险。脱敏后的样本、校对稿和版本记录应当分开存放，项目结束后能够按清单清理。
行业适配是一项持续工作，不是上线前的一次训练。业务词会变，设备会换，录音环境也会变化。系统需要给业务人员一个反馈入口，让错误样本能够回到评测集；技术团队则要定期判断，哪些问题适合规则修正，哪些问题值得重新训练。