多个唤醒词合并到同一模型的技术实现方法
时间:2026-08-05 | 作者:白桃企划师 | 阅读:0做智能音箱的时候,产品叫“小娜”。但用户从来不会只喊一个名字。有人喊“小娜”,有人喊“你好小娜”,还有人喜欢叠词“小娜小娜”。三个都是自然叫法,总不能要求用户改习惯吧?可问题在于:一个模型通常只能识别一个唤醒词——这是很多人对KWS的默认认知。
最初的想法很简单:三个唤醒词,训三个模型,串行推理。128KB × 3 = 384KB。手机上跑三次勉强能忍,但换到ESP32上,SRAM直接装不下。后来才发现想多了——多唤醒词可以合训成一个模型。135KB,一次推理,三个词全在里面。这篇文章就来聊聊怎么自定义一组唤醒词,合训成一个模型,以及实际效果到底怎么样。
一个产品,三个唤醒词
单唤醒词够用的场景其实不多。大多数产品天然需要多个唤醒入口:
- 不同用户习惯不同。有人喜欢两个字“小娜”,有人习惯在前面加“你好”,有人觉得叠词“小娜小娜”更自然。三个词能覆盖所有用户习惯,一个词只能覆盖一部分。
- 不同场景用不同词。近距离安静环境下“小娜”就行;远场嘈杂时“小娜小娜”双音节发音更长、声学特征更丰富,识别更稳。
- 家庭成员各有名字。智能中控屏,爸爸喊“小迪小迪”,妈妈喊“小鹿小鹿”,小孩喊“小云”。各自叫各自的名字,互不干扰。
- 分级权限。管理员唤醒词和普通用户唤醒词是分开的。喊管理员词能改设置,喊普通词只能操作。这在安防场景特别有用。
怎么合训:三个字概括——"一起练"
训练流程跟单唤醒词基本一样,区别只有一个:输入多个词,逗号分隔。
训练命令:
--words "小娜,你好小娜,小娜小娜" --epochs 60
背后发生的事情:系统自动用TTS合成三个词的正样本,混合负样本目录的噪声数据,训练一个共享Backbone、三个独立分类头的模型。
Mel频谱
│
▼
┌──────────────┐
│共享Backbone │← 只算一次,23K参数
│提取声学特征 │
└──────┬───────┘
│
┌─────┼─────┬─────┐
▼ ▼ ▼
"小娜" "你好 "小娜
小娜" 小娜"
───────────────────
三个词,一次推理,三个概率
关键设计:共享Backbone + 独立分类头。
Backbone负责把音频转成特征向量——三个唤醒词都要做的底层工作,只训一次。每个词只挂一个微型分类头,不到800个参数,独立判断自己的那个词。推理的时候Backbone只跑一遍,三个头同时出结果。
效果怎么样
以“小娜 / 你好小娜 / 小娜小娜”为例:
| 指标 | 数值 |
| 模型体积 | 135 KB |
| 总参数 | ~25K |
| 推理方式 | 1次前向传播出3个概率 |
| 小娜召回率 | ~82% |
| 你好小娜召回率 | ~85% |
| 小娜小娜召回率 | ~80% |
| 跨词误触发 | < 0.5% |
对比一下如果训三个独立模型:
| 三个独立模型 | 一个多唤醒词模型 | |
| 总参数 | 75K | 25K |
| 总体积 | 384KB | 135KB |
| 推理次数 | 3次 | 1次 |
| 跨词误触 | 需要后处理抑制 | 特征空间天然互斥 |
参数少3倍,体积小3倍。更重要的是跨词误触几乎为零——因为三个词的分类头共享同一个Backbone,训练时梯度相互推远,特征空间里天然互斥。
选词也有讲究
选一组唤醒词不是随便挑的。几个经验:
- 词之间要有区分度。“小娜”“你好小娜”“小娜小娜”这组词——小娜是后面两个的子串,理论上容易串。但共享Backbone训练时会把子串关系在特征空间里显式推开,实测跨词误触小于0.5%。
- 如果可能,选词尽量有发音差异。“小娜”和“小呐”——声母韵母一样,只差声调,区分难度就大。但如果场景确实需要这样一对近音词(比如四川话和普通话各一个),加真人录音做数据增强是最好的解法。
- 词长控制在2-6个字。太短区分度不够,太长用户说不完。3-4个字最优。
- 一组词的量控制在10个以内。理论上可以更多,但实际场景中用户也记不住15个唤醒词。
不只是唤醒词
多唤醒词模型跟多命令词模型是同一种技术。区别只在于用法:
| 多唤醒词 | 多命令词 | |
| 数量 | 2-5个 | 3-10个 |
| 作用 | 激活设备 | 触发具体动作 |
| 之后 | 可能接ASR | 直接执行 |
| 举例 | 小娜/你好小娜/小娜小娜 | 开灯/关灯/调亮/调暗 |
两种场景都能合训成同一个模型。
怎么拿到
训练方式跟单关键词一样——输入词,自动TTS合成,数据增强,训练,导出ONNX。十来分钟到半小时出模型。
推理部署用同一个开源引擎,Android/Linux/ESP32/Web全平台。如果是已上线的设备想加新唤醒词,重新生成一个多词模型替换掉原来的文件就行,不需要改硬件,不需要烧固件。
最后
自定义多唤醒词这件事,以前要么每个词训一个模型堆叠着跑,要么只能迁就只用一个唤醒词。现在一个模型搞定——更小、更快、更省资源。如果你的产品还在用一个唤醒词迁就所有用户,可以考虑加几个自然变体了。
免责声明:文中图文均来自网络,如有侵权请联系删除,心愿游戏发布此文仅为传递信息,不代表心愿游戏认同其观点或证实其描述。
相关文章
更多-
- iOS Swift连续present多个页面报错或崩溃解决方法
- 时间:2026-08-21
-
- Dart中如何串联多个数据流实现流式处理
- 时间:2026-08-21
-
- SQL中COUNT DISTINCT统计多个字段的方法与写法
- 时间:2026-08-20
-
- 多个按钮如何分别绑定不同的dialog对话框实现方法
- 时间:2026-08-20
-
- GCC编译多个文件的命令写法与使用方法
- 时间:2026-08-20
-
- Spring项目多个Maven模块循环依赖问题分析与解决方法
- 时间:2026-08-20
-
- Clang编译多个文件找不到头文件的解决方法
- 时间:2026-08-18
-
- 多个来源网站列如何合并为单一列并保留其他字段信息
- 时间:2026-08-17
精选合集
更多大家都在玩
大家都在看
更多-
- 闪烁之光法师及坦克符文推荐
- 时间:2026-10-21
-
- 闪烁之光三灵系玩法解析
- 时间:2026-10-21
-
- 闪烁之光高速爆发流攻略
- 时间:2026-10-21
-
- 闪烁之光食魇天马和金羽鸾适配场景
- 时间:2026-10-21
-
- 闪烁之光永恒纪元钟效果解析
- 时间:2026-10-21
-
- 闪烁之光神装选择思路
- 时间:2026-10-21
-
- PS怎么用魔棒抠图
- 时间:2026-10-21
-
- OBS Studio怎么设置音频输入源
- 时间:2026-10-21