跳到正文
DEV Community· voicute·· 2 小時前AI 評分46

Voicute 如何把產品名稱轉成離線喚醒詞:需要測試甚麼

I Turned a Product Name into an Offline Wake Word — What I Had to Test

AI 導讀

Voicute 可把產品名稱訓練成離線關鍵詞模型,經真實語音測試後匯出 ONNX 或 TFLite,在目標產品本地執行。網上測試只能作初步篩選,不能保證正式產品表現;上線前仍須量度召回率、每小時誤觸發次數、延遲、記憶體及耗電量。

正文

Most smart products already have a name. The hard part is making the device hear that name reliably without sending every conversation to the cloud.

This is the product question behind a custom wake word: can a device recognize one short phrase locally, then start the next interaction?

The product name and the wake word are different things

A brand name is designed for people. A wake word is designed for a detector. The same phrase can be a good brand name and a poor wake word if it is too short, too common, or easily confused with normal conversation.

For an example product, imagine a small robot called “Taro”. The desired flow is:

“Hey Taro”       → wake the robot
“Move forward”   → start a fixed action
“Stop”           → stop the motor

The wake phrase and the fixed commands are not the same product requirement.

KWS or ASR?

If the product needs to understand arbitrary sentences, names, numbers, or parameters, it needs speech recognition and intent handling. But if it only needs one wake phrase or a small list of commands, keyword spotting is a more focused option.

Requirement First option
Wake an assistant Single-keyword KWS
Detect 2–10 fixed commands Multi-keyword KWS
Understand open speech ASR plus intent parsing
Verify the speaker Speaker verification

KWS does not try to transcribe everything. It asks a narrower question: “did one of the target phrases occur?” That makes a small, local model possible.

What I would test before choosing the name

I would not approve a wake word from the spelling alone. I would test:

  1. Several speakers saying the phrase naturally.
  2. Different speaking speeds and distances.
  3. The target microphone and enclosure.
  4. Background conversation, music, fans, and household noise.
  5. Similar-sounding phrases that should not trigger the product.

The browser is a useful first filter. It can tell us whether a phrase is worth taking to a device. It cannot prove that the same result will hold after the microphone, enclosure, distance, and noise environment change.

The delivery path

The practical flow is:

Product name
    ↓
Train a custom keyword model
    ↓
Test with real voices
    ↓
Export ONNX or TFLite
    ↓
Run locally on the target product

For a product team, the useful deliverable is not only a model file. The team also needs the audio input assumptions, feature extraction path, threshold behavior, cooldown logic, and a way to connect a detection callback to a safe product action.

Where a small custom model fits

For my experiments, I wanted a model that could run offline and fit several possible targets: Python, Web, Android, and embedded hardware. A standard ONNX or TFLite artifact makes that transition easier than a platform-locked runtime.

Voicute is one way to start this process without building the training pipeline first: enter the product name, train a Basic model, test it with real voices, and decide whether the result is good enough to download. Real-voice enhancement can help when the target users have a specific accent or speaking style.

The honest boundary is important: online testing is a screening step, not a production guarantee. The final product still needs measurements for recall, false triggers per hour, latency, memory and power.

A minimal local integration example

The runtime should expose a simple event to the application layer:

def on_keyword(word, probability, info):
    if word == "hey_taro":
        robot.start_interaction()
    elif word == "stop":
        robot.stop()

The application should also implement cooldowns and safe failure behavior. A detector should not repeatedly start an action because the same phrase remains in the audio buffer.

What I would ship with the project

  • The ONNX or TFLite model;
  • A reproducible inference example;
  • The supported sample rate and audio format;
  • Threshold and cooldown defaults;
  • A test checklist for the final microphone and enclosure;
  • Clear limitations instead of a universal accuracy claim.

The open-source runtime and examples are available in onnx-wakeword. If you want to test your own product name, use the Voicute online training page.

Disclosure: Voicute is my project. I am sharing the engineering process and its limitations, not claiming that one wake-word model is best for every language or device.

來源:DEV Community · dev.to