用ONNX打造离线语音控制：自定义唤醒词与多命令识别

许多语音控制产品并不需要转录每一句话。当交互以唤醒词开始、随后只跟一小串固定命令时，本地关键词检测（keyword spotting）往往比持续运行云端语音识别更简单、更可控。本文基于一套开源实现，拆解如何用自定义唤醒词加 ONNX 推理搭建离线语音控制，并重点讨论误触发治理与跨运行时部署这两个容易被低估的环节。

两级架构：唤醒与命令分离

这套方案的核心是把「唤醒」和「命令识别」拆成两个阶段。麦克风采集的音频流首先送入唤醒词模型，该模型以较保守的阈值持续运行；一旦命中唤醒词，应用才开启一个短暂的时间窗，把窗口内的音频交给多关键词模型做命令识别，最后映射为具体动作。

以原文给出的例子来说：唤醒词为「Hey device」，命令为「Turn on the light」。这种设计的价值在于，较大的命令识别器不必常驻运行，交互状态机也更容易控制——系统清楚地知道当前处于「等待唤醒」还是「接收命令」阶段。

为什么不用语音识别做唤醒词

Web Speech API 在原型阶段很方便，但它并不是可靠的常驻唤醒词检测器。原文指出，浏览器对 SpeechRecognition 及其 continuous 模式的支持并不一致，部分实现可能中途断开连接，或者实际上把音频发往远程识别服务——这既带来延迟，也破坏了「音频不出设备」的隐私前提。

更稳妥的本地路径是：在用户手势之后申请麦克风权限，用 getUserMedia() 读取音频流，把流转换成模型期望的帧格式，本地运行关键词检测推理，只有检测到唤醒词后才启动 ASR 或展示命令界面。浏览器仍有权限与生命周期的限制，但关键词检测器不再依赖 SpeechRecognition 返回转录文本。

Web Speech API 是浏览器提供的高层语音接口，SpeechRecognition 是其核心对象。它的设计目标是「语音转文本」，而非「常驻关键词检测」，因此存在几个结构性限制：首先，continuous 模式在 Chrome 之外的浏览器中支持度参差不齐，部分实现会在静音数秒后自动结束会话，需要反复重启；其次，多数浏览器将音频发送到云端识别服务（如 Google 的服务器），意味着唤醒词检测的延迟取决于网络往返，且音频离开了设备；第三，API 不暴露原始音频帧或置信度分数，应用无法自定义阈值或做本地分帧处理。这些限制使得它适合一次性听写场景，却不适合需要 7×24 小时低功耗监听的唤醒词场景。改用 getUserMedia() 获取 MediaStream 后，音频数据留在本地，开发者可以自行控制采样率、帧长与推理节奏。

一个模型搞定多条固定命令

当设备只需要处理有限命令时，多关键词模型可以为每个标签输出一个分数，应用再把选中的标签映射为动作。原文给出的命令集包括 next、previous、stop、open menu、close menu，对应代码用一个 actions 对象做分发：

const actions = {
  next: () => nextPage(),
  previous: () => previousPage(),
  stop: () => stopPlayback(),
  "open menu": () => openMenu(),
  "close menu": () => closeMenu(),
};

function handleKeyword(label) {
  actions[label]?.();
}

这种做法的边界需要说清楚：它适用于词表事先已知的场景，不能替代开放式语音识别。像「把客厅灯调到 37%」这类包含任意参数的说法，仍然需要 ASR 加意图解析，因为其中的词汇和数值都不是固定的。

多关键词模型（multi-keyword model）与单唤醒词模型的区别在于输出层：后者通常只输出一个「目标词 vs 非目标词」的分数，前者则为每个关键词标签各输出一个独立分数（常见做法是 sigmoid 多标签输出，而非 softmax 单标签互斥）。这意味着同一帧音频理论上可以同时激活多个标签，应用需要配合阈值与冷却逻辑来消歧。训练时，每个关键词都需要正样本，同时所有非目标音频（包括其他关键词的样本）都作为负样本，模型因此学会在标签之间做区分。词表大小会影响模型容量与误触发率：标签越多，混淆风险越高，通常建议将命令数量控制在十余条以内，并对发音相近的词做额外难负样本挖掘。

误触发治理：R0 与 R1 两轮训练

让模型认出目标短语只是问题的一半，真实设备还必须学会拒绝：日常对话、音乐与电视声、风扇与机械噪声、发音相近的短语、麦克风或外壳引入的噪声。

原文把这套流程拆得很清楚：第一版模型可视为 R0；测试后收集那些被错误触发的音频片段，这些「难负样本」（hard negatives）进入下一轮训练，得到 R1。R1 是一个训练过程，而不是运行时必须再跑一个模型——目标是在保持目标短语召回率的同时，教会模型拒绝那些容易混淆的声音。这一点常被误解为「要部署两个模型」，实际上运行时仍然只有一个。

难负样本（hard negatives）是机器学习中「难例挖掘」思路在关键词检测上的应用。普通负样本是随机收集的背景音频，模型很容易将它们判为负类；难负样本则是模型当前误判为正类的片段——例如电视里出现相似音节、用户咳嗽、关门声等。将这些片段加入训练集重新训练，相当于专门针对模型的决策边界做局部修正，通常能在不大幅牺牲召回率的前提下显著降低误触发率。实际操作中，R0 模型部署到测试设备后，应开启「误触发录音」日志，把每次超过阈值的片段保存下来，人工听审后剔除真正的目标词，其余作为 R1 的训练负样本。这个过程可以迭代多轮（R2、R3），每轮都针对上一轮暴露的新混淆源。

本地推理与隐私收益

本地关键词检测适合这样一类产品：要求低延迟、可离线运行、命令行为可预期、降低云与网络依赖、并对麦克风隐私有更强控制。需要注意，模型文件只是系统的一部分，运行时还需要音频采集、分帧、特征提取、阈值处理、冷却逻辑和应用回调。原文特别提醒：应当验证完整流水线，而不是只测试模型文件能否加载。

ONNX 与 TFLite 部署要点

ONNX 适合桌面、Python、Android 以及支持 ONNX Runtime 的浏览器运行时；TFLite 或 TFLite Micro 则常见于资源受限的嵌入式设备。把模型迁移到另一个运行时之前，需要逐项核对：采样率、PCM 格式、帧长与帧移、Mel 特征配置、输入张量形状、输出标签顺序、量化设置、检测阈值。

原文的一个关键提醒是：即使模型文件完全没变，只要预处理发生变化，召回率也可能下降。这解释了为什么很多「模型没问题但效果变差」的案例，根因其实在特征提取环节。

Mel 特征（梅尔频谱）是关键词检测模型最常见的输入表示。它模拟人耳对频率的非线性感知：将线性频谱通过一组三角形滤波器组映射到梅尔刻度，再取对数。关键参数包括采样率（常见 16 kHz）、帧长（如 25 ms）、帧移（如 10 ms）、Mel 滤波器数量（如 40 或 64）、频率上下限以及是否做归一化。这些参数必须与训练时完全一致，否则同一段音频在部署端提取出的特征分布会偏移，模型看到的输入与训练分布不匹配，召回率随之下降。跨运行时迁移时，尤其要检查 TFLite 的 Microfrontend 或自定义算子是否与 Python 端的 librosa/torchaudio 实现对齐，包括窗函数类型（Hann 还是 Hamming）和是否补零。

实测清单：别只优化召回率

原文给出的测试清单值得直接拿来用：用多位说话人测试唤醒词；测试不同距离与语速；播放普通对话与背景音频；统计每小时误触发次数；把召回率与误触发率分开测量；为下一轮训练补充难负样本；测试冷却与重复触发行为；确认每条识别命令都映射到预期的安全动作。

其中最容易被忽视的一条是：不要只优化召回率。一个触发过于频繁的模型，即便很少漏掉目标短语，在产品层面也不可用。误触发是语音控制产品体验的真正杀手。

开源实现与延伸阅读

开源项目 onnx-wakeword 提供了在本地应用中运行 ONNX 唤醒词与关键词检测模型的推理代码和示例，适合在集成到更大产品之前先验证推理路径。当然，最终结果仍应使用真实麦克风、目标操作系统与硬件进行测试。原文还提供了更长的架构指南以及一段德语语音控制演示视频作为参考。