microWakeWord Custom Models: Why False Positives Happen and How to Fix Them

Start with the right expectation

microWakeWord is a strong choice when you want a small model running locally on an ESP32-S3, ESPHome device or Home Assistant Voice setup. The official ecosystem makes it practical to select a supported model and keep wake-word processing on the device. That means low latency and no always-on audio stream to a server. See the Home Assistant wake-word overview and the microWakeWord training framework.

Custom words change the problem. You are no longer choosing a model that has already been tuned and tested. You are building a detector that must separate one short phrase from similar speech, television audio, music, household noise and the exact acoustic path of your device.

Why false positives happen

1. The negative set is too easy. Random background audio may not contain the phrases that actually confuse your word. A model can score well on a clean validation split and still trigger on a similar phrase or television audio.
2. Synthetic positives do not cover the deployment voice. TTS provides useful pronunciation and speaker coverage, but it cannot perfectly represent your accent, distance, microphone response or the way you join the words.
3. The threshold is asked to solve a data problem. Raising the cutoff may reduce false accepts but also remove quiet, distant or accented true wakes. Lowering it improves recall while allowing more confusable speech through.
4. Streaming conditions differ from notebook tests. Frame size, feature step, gain, sample rate, VAD and the ESP32 microphone path all affect the score distribution. A model that looks fine in a file test needs a real-device check.

The practical custom-model recipe

A reliable custom wake word needs three kinds of evidence:

This is the important distinction: real recordings do not need to be endless duplicates. A small set of varied, clean short-phrase recordings is usually more useful than recording the same pronunciation many times. When a specific confusion appears, add that failure as a hard negative and test again.

What to change before changing the cutoff

• Confirm the audio is 16 kHz mono and that the streaming feature path matches training.
• Record the false activation, identify the confusing phrase or sound, and add it to the negative set.
• Test in the target room with the target microphone, distance, speaker volume and background devices.
• Measure both recall and false accepts per hour; a single confidence score is not a product metric.
• Only then tune the probability cutoff and sliding window for the intended latency/false-trigger tradeoff.

Where Voicute fits

Voicute does not replace the strengths of microWakeWord. If your requirement is a tiny preset wake word on an ESP32-S3, microWakeWord can be an excellent fit. Voicute is aimed at the custom-model workflow around the hard part: synthetic positive samples + real hard-negative mining + optional real speaker recordings.

We turn that recipe into a button-driven service: type the phrase, generate and test the synthetic preview, optionally add a small set of real recordings, evaluate the basic model, and export standard ONNX/TFLite artifacts for the target runtime. The goal is not to claim that one engine wins every benchmark; it is to make the custom-data loop visible and repeatable.

FAQ

Should I stop using microWakeWord?

No. Its preset models and low-power on-device path are valuable. Consider an alternative when your main problem is custom-word training, multilingual delivery, cross-platform deployment or the lack of a practical hard-negative workflow.

Do I need 50 recordings?

Usually not. Start with a varied small set, often 5–10 recordings, and add more only when a real pronunciation or environment remains difficult.

Can a higher threshold fix every false positive?

No. It changes the operating point, but it cannot teach the model about a missing confusable phrase. Collect the failure, add it as a hard negative and re-evaluate.