一盏灯需要听懂多少话？多关键词模型就够了

很多语音界面根本不需要把任意一句话转成文字。一盏灯、一台机器人、一个家电、一台自助终端或者一个媒体控制器，可能只需要一小套词汇：开灯、关灯、下一首、上一首、停止。

对这类产品来说，多关键词模型比完整的云端语音识别（ASR）流水线更合适。它回答的是一个被限定死的问题：当前这段音频窗口里，有没有出现某个已知指令？如果有，是哪一个？

这套系统的工程形态包括模型元数据、本地推理、指令回调和上线前的测试。核心判断只有一句：关键词识别（KWS）不是通用语音识别。KWS 检测的是已知短语或一小撮已知短语，ASR 产出的是开放式语音的转写文本。

一个典型的两级语音控制器是这样串起来的：常驻唤醒词，进入短指令窗口，交给多关键词模型，输出指令标签，最后触发安全的应用程序动作。唤醒词和指令词表是两件独立的事。把指令列表固定下来，应用行为更容易测试，系统也能保持本地运行。

一个模型，多个指令标签

多关键词模型对外暴露一个固定的输出顺序。比如元数据里写明模型类型为 multi_keyword，关键词数组是“开灯”“关灯”“下一首”“停止”，模型文件为 commands.onnx，并给出 mel_time 98、n_mels 32、cons_frames 2 这些参数。

关键词数组本身就是接口的一部分，它的顺序必须和模型输出严格对齐：输出第 0 位对应开灯，第 1 位对应关灯，第 2 位对应下一首，第 3 位对应停止。应用应该把识别出的标签映射成动作，而不是把业务逻辑塞进模型里。

回调边界可以写得很简单：识别到“开灯”就调用开灯，识别到“关灯”就关灯，识别到“下一首”就切歌，识别到“停止”就停播。真实产品里还要加冷却时间，并让重复事件保持安全。语音检测不应直接绕过授权或确认，去执行删数据、开门、下单这类破坏性动作。

本地推理流水线不止一个模型文件

一个能工作的检测器，链路是：麦克风采集，得到单声道 PCM 音频，做采样率转换和分帧，提取对数梅尔特征，跑 ONNX 或 TFLite 推理，再做阈值和连续帧判断，最后触发指令回调。

运行时的预处理必须和训练、导出时的配置一致。同一个模型，在一个演示里看着正常，一旦目标应用改了采样率、帧形状、梅尔设置或输入归一化，召回率就可能掉下去。

开源仓库 onnx-wakeword 里放了本地推理示例。同一套模型概念，可以以 ONNX 形式交付到桌面、Web、安卓和 Python 集成中，也可以以 TFLite 或 TFLite Micro 形式交付到资源受限的嵌入式目标上。ONNX 和 TFLite 是部署选择，用哪个运行时取决于目标平台。

“模型可移植”不等于每个音频设备或板子表现一致。最终的麦克风、外壳、操作系统和功耗预算，都需要单独测试。

把指令当成一组来测

每条指令只测一句成功语料远远不够。对每条指令，至少要收集这些样本：

• 多个说话人的正样本；
• 不同距离、语速和音量；
• 发音相近的短语；
• 普通对话和静音；
• 电视、音乐、风扇和设备自身播放的声音；
• 产品实际要用的麦克风和外壳。

至少要测两个指标：召回率，即检测到的目标语句数除以目标语句总数；每小时误接受次数，即非目标激活次数除以负样本音频的小时数。还要检查指令之间的混淆。一个模型可能对“下一首”召回不错，却在同一环境里把“下一首”错认成“停止”。

如果基线模型被某种反复出现的声音触发，就把这些误触发片段留作后续训练的困难负样本：基线模型，扫描有代表性的负样本音频，收集误触发片段，带困难负样本重训，再做留出集评估。不要把每个片段都拿去当训练数据，要留一份独立的留出集，这样第二次评估测的还是泛化能力。

先验证，再集成

固定指令产品的实际工作流是：先定义唤醒词和指令词表，为目标语言生成一个基础模型，在下载前用真实人声测试这些短语，然后下载 ONNX 或 TFLite 产物及其元数据，集成匹配的本地运行时，最后在目标设备上测召回率、误接受、延迟、内存和功耗。

Voicute 支持中文、英文、西班牙语、日语、德语、法语和印地语的自定义关键词。在线测试只是筛选步骤，不是对每个麦克风或外壳的生产保证。

对于指令词表小而固定的产品，一个多关键词模型比每条指令一个检测器、或者一整套 ASR 服务更干净。模型负责识别词表，应用负责动作策略，最终设备测试决定能不能出货。开源推理示例在 voicute/onnx-wakeword，也可以在自己的固定指令词表上生成并测试。

需要说明的是，本文作者是 Voicute 的创建者。模型生成服务是商业服务，本地推理示例是开源的。结果取决于语言、说话人、麦克风、环境和运行时配置。