从“打开灯光”看 KWS 多关键词语音控制是怎么工作的

很多语音控制 Demo 一上来就使用 ASR：录音、转文字、字符串匹配、执行动作。这个流程当然能工作，但如果设备只需要"开灯、关灯、调亮、调暗"几个固定命令，使用完整 ASR 可能有些重。

这篇文章从一个智能灯场景出发，拆开唤醒词、关键词识别和 ASR 的分工。

1. 先区分三条链路

唤醒链路

连续音频 → 唤醒词模型 → 检测到"你好小灯" → 打开后续控制

唤醒词模型只负责判断一个短语是否出现。它通常需要低功耗常驻运行，不能太大。

固定命令链路

连续音频 → KWS 多关键词模型 → command_id → 执行动作

例如：

打开灯光 → LIGHT_ON
关闭灯光 → LIGHT_OFF
调亮     → BRIGHTNESS_UP
调暗     → BRIGHTNESS_DOWN

模型不需要先生成文字，应用层拿到命令 ID 后直接执行动作。

自由语音链路

音频 → ASR → 文本 → 意图识别 → 参数提取 → 执行动作

例如"把客厅灯调到 50%"，除了识别文本，还要提取房间、设备和亮度参数。这就已经不是单纯关键词识别的问题了。

2. KWS 为什么适合固定命令

KWS 的目标不是理解所有语言，而是在音频流中判断某个预定义短语是否出现。它的输出更接近一个按钮：

检测到目标词 → 返回 true / command_id
没有检测到 → 继续监听

对于固定命令，KWS 有几个工程优势：

• 模型可以比通用 ASR 小很多；
• 常驻运行的功耗更容易控制；
• 不需要维护大量文本匹配规则；
• 可以完全离线运行；
• 适合 MCU、手机后台和边缘设备。

但它也有边界：命令词需要预先定义，不能自然理解用户从未训练过的表达。

3. 多关键词单模型的意义

传统做法可能是每个词一个模型：四个命令就加载四个模型，或者依次运行四次推理。

多关键词单模型可以让一套模型同时输出多个结果：

输入一段音频
        ↓
一次特征提取和推理
        ↓
LIGHT_ON / LIGHT_OFF / UP / DOWN

这样可以减少重复加载和重复特征提取。但工程上仍然要关注：

• 关键词之间是否容易混淆；
• 每个命令的召回率是否均衡；
• 相似词是否容易互相触发；
• 模型大小是否适合目标芯片；
• 多个输出的阈值和冷却时间怎么设置。

4. 召回率和误触发不是同一个指标

召回率回答的是：用户真的说了目标词，模型能不能检测到。

误触发回答的是：用户没说目标词，模型会不会错误触发。

调低阈值通常会提高召回，但也可能增加误触发；调高阈值则可能漏掉真实命令。实际产品不能只展示一个"识别率"，而应该在真实设备上记录：

• 正确触发次数；
• 漏唤醒次数；
• 每小时误触发次数；
• 不同距离和角度；
• 不同说话人和口音；
• 音乐、风扇和人声背景噪声。

5. 一个最小的产品架构

麦克风
  ↓
音频缓冲区
  ↓
Mel 特征提取
  ↓
KWS 模型
  ↓
连续帧判断 / 冷却时间 / 能量过滤
  ↓
命令 ID
  ↓
产品业务逻辑

这里最容易被忽略的是最后两层。模型输出一个分数，不等于产品应该立刻执行动作。还需要连续帧确认、冷却时间、背景能量和业务状态判断，避免一次语音触发多次操作。

6. KWS、ASR 怎么选

可以用下面的规则快速判断：

需求	方案
唤醒设备	Wake Word / KWS
少量固定命令	多关键词 KWS
自由表达	ASR
数字、地点、参数	ASR + 意图解析
电池设备常驻监听	小型 KWS

如果设备只需要十个以内的固定命令，不一定要先部署几十 MB 的 ASR。先用 KWS 做一个可验证的 PoC，通常更容易判断这条路线是否适合产品。

7. 如何快速做 PoC

一个可执行的验证顺序是：

1. 列出产品真正需要的关键词；
2. 删除可以由按钮或状态机解决的命令；
3. 为剩余关键词生成单模型或多关键词模型；
4. 在浏览器或电脑麦克风上测试；
5. 在目标设备和真实噪声中测试；
6. 再决定是否加入真人录音和困难负样本优化。

Voicute 的在线流程就是把训练和第一次验证前置：输入自定义关键词，训练后直接测试，再导出标准 ONNX/TFLite 模型。配合开源推理代码，可以继续接入 Web、Android、Python、ESP32-S3 等运行环境。