输入关键词到离线模型：从 Wake Word 到多关键词 KWS 的一条工程链路

假设我们要做一个语音灯控 Demo。设备平时不执行动作，用户先说"你好小灯"，再说"打开灯光"或"关闭灯光"。这个需求看起来像语音识别，实际上可以拆成两个更小的模型问题。

1. 两个模型，各自负责一件事

第一段是 Wake Word：

text 复制代码

麦克风音频 → Wake Word 模型 → wakeup()

第二段是固定命令：

text 复制代码

麦克风音频 → 多关键词 KWS → command_id → 业务回调

命令词不需要先转成完整文本，可以直接映射到业务事件：

text 复制代码

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

如果需求变成"把客厅灯调到 50%"，就需要 ASR 和参数解析。KWS 适合有限、提前定义的词，不负责理解开放式句子。

2. 为什么一个多关键词模型更好管理

最直接的做法是每个命令训练一个模型，再分别做特征提取和推理。命令数量增加后，会出现几个问题：

多个模型占用更多内存；
每个模型都要管理阈值；
多次推理增加 CPU 使用；
不同模型的冷却和去重逻辑容易不一致。

多关键词模型可以共享特征提取和主干推理，输出多个类别。它不是"一个模型理解任意语言"，而是"一个模型识别一组预先定义的短语"。

例如一次推理可以输出：

text 复制代码

打开灯光 → LIGHT_ON
关闭灯光 → LIGHT_OFF
暂停     → PAUSE
继续     → RESUME

产品侧只维护一个模型文件和一组命令映射，但每个关键词仍然要分别测召回、混淆和误触发。

3. 最小推理管线

一个可落地的固定命令管线大致如下：

text 复制代码

音频采集
  ↓
环形缓冲区
  ↓
Mel 特征
  ↓
ONNX/TFLite 模型
  ↓
连续帧确认
  ↓
阈值与冷却时间
  ↓
command_id
  ↓
业务动作

模型输出分数不能直接等价于一次动作。至少要处理连续帧、冷却时间和重复触发。例如一次"打开灯光"可能覆盖多个推理窗口，如果不做冷却，就会执行多次。

伪代码可以写成：

text 复制代码

result = kws.infer(audio_window)

if result.score > threshold:
    if result.label != last_label or now - last_trigger > cooldown:
        dispatch(result.label)
        last_label = result.label
        last_trigger = now

阈值不是越低越好。降低阈值通常能提高召回，但也可能增加误触发。应该用独立的正样本和负样本，在目标设备上记录 FA/h、漏识别和重复触发。

4. 上传真人录音增强目标词

纯合成数据可以快速生成第一版模型，但真实用户的口音、语速、品牌读法和目标麦克风可能与合成数据不同。工程上可以把用户录音作为增强数据重新训练：

text 复制代码

基础模型
  + 真人关键词录音
  + 目标环境录音
        ↓
增强训练
        ↓
重新测试召回与误触发

上传录音时要注意：录音需要获得使用授权，尽量包含不同说话人和真实距离；一段录音不能代表所有用户；增强训练后仍要用独立录音集验证，避免把训练录音本身当成测试结果。

5. 从关键词到模型的工程流程

当团队没有现成训练环境时，可以把训练链路抽象成一个输入输出问题：

text 复制代码

关键词列表 + 语言
        ↓
训练数据与增强
        ↓
单关键词或多关键词模型
        ↓
浏览器/电脑麦克风测试
        ↓
导出 ONNX 或 INT8 TFLite

这里最重要的不是只生成文件，而是生成后能马上用真实声音测试。在线测试能帮助发现关键词太短、发音不清晰或相似词太多的问题，但它仍然只是第一轮验证。

6. 同一个模型可以落到哪些平台

标准 ONNX/TFLite 把训练和运行时解耦。当前支持的目标平台包括：

ESP32：使用 TFLite/TFLite Micro；
Raspberry Pi：使用 ONNX Runtime 或 TFLite；
Android：使用 ONNX Runtime 集成到 App；
Web：使用 ONNX Runtime Web/WASM；
Windows、macOS、Linux：使用对应的 ONNX/TFLite 运行时；
Home Assistant：通过 Wyoming 或本地集成接入。

注意，跨平台不代表音频输入完全相同。桌面端、手机、树莓派和 MCU 的采样率、麦克风、缓冲区和算力都不同。模型可以复用，但音频采集和后处理仍要按目标平台适配。

7. 用一个小场景做验证

建议不要一开始就放二十个命令。先选：

text 复制代码

Wake Word：你好小灯
命令词：打开灯光 / 关闭灯光 / 调亮 / 调暗

验证顺序：

在浏览器或电脑上确认模型能识别；
用不同人、不同距离和不同音量测试；
在目标平台接入真实麦克风；
加入电视、风扇和谈话等背景噪声；
调整阈值、连续帧数和冷却时间；
再考虑增加命令或加入真人录音增强。

8. 什么时候不应该用 KWS

下面这些需求不适合单纯的关键词模型：

用户可以随意表达同一个意图；
需要识别任意数字、地点或名称；
需要连续听写；
需要从句子中提取多个参数。

这时应该使用 ASR，再加意图识别。KWS 的价值在于把固定、低延迟、离线的控制入口做得更小、更容易部署。

如果要快速验证自定义词，可以先输入关键词生成模型，再下载标准 ONNX/TFLite 文件，最后按目标平台接入。模型格式通用，但正式发布前仍需进行目标设备测试。