Why openWakeWord Recall Varies by Wake Word—and How to Fix “Word Picking”

You train two custom phrases with the same openWakeWord recipe. One reaches a useful score quickly; the other rarely activates, even after generating more samples. This phrase-dependent behavior is real. Understanding the frozen embedding architecture explains why adding more data or more steps does not always solve it.

What the openWakeWord architecture actually does

The official project describes three stages:

1. A fixed-parameter mel-spectrogram preprocessor.
2. A shared Google-derived feature extractor that turns audio into general-purpose speech embeddings.
3. A small phrase classifier trained on top of the frozen feature extractor.

This design has important advantages. The expensive backbone is shared across wake words, fully synthetic positive data can work, and adding another phrase has a small runtime cost. But custom training cannot change the representation produced by the frozen backbone; it can only learn a decision boundary on top of it.

Why that can produce “word picking”

Consider two phrases. In the frozen embedding space, phrase A may form a compact cluster far from ordinary speech and similar-sounding words. Phrase B may overlap with common speech, split across pronunciations, or sit near a phonetic neighbour. The same small classifier and the same loss settings will not separate both cases equally well.

This is a technical inference from the published architecture and observed phrase-dependent training—not a claim that a frozen embedding always fails. openWakeWord's supplied English models demonstrate that the approach can work well when the phrase, data, negatives and parameters fit each other.

The maintainer confirms that parameters vary by phrase

In an openWakeWord discussion about pretrained models exceeding 90% performance, the maintainer explained that the models used a range of parameters because there was no single set that worked well across wake words. Parameters that helped one phrase could make another phrase worse. The maintainer also noted that training metrics do not always correlate cleanly with real-world performance.

A separate public issue shows the other end of the range: an automatic training run for “alice” reported about 25.7% recall, while a different training path worked better for the same contributor. One issue is not a universal benchmark, but it demonstrates why a successful notebook execution is not proof of a deployable model.

How to tell whether your phrase is being “picked against”

• The audio pipeline is correct, yet intended speech consistently peaks below threshold.
• Increasing steps or positive sample count produces little improvement.
• A different wake phrase trained with the same setup works substantially better.
• Recall improves only after a large threshold reduction, causing many false activations.
• The model works for one pronunciation or TTS voice but not for real speakers.

Before blaming the embedding, complete the audio and inference checklist. Wrong sample format, frame buffering or VAD logic can imitate low recall.

Fix 1: choose a more separable phrase

A two- or three-syllable phrase with a distinctive sound pattern is usually easier than a very short, common word. Avoid words that appear frequently in normal conversation and phrases that differ from common speech by only one sound. Adding a prefix such as “Hey” can create a longer acoustic signature, although it does not guarantee success.

Fix 2: tune the positive/negative trade-off per phrase

The maintainer recommends reducing negative-weight scale when recall is too low, and increasing generated positive samples. If false activations are the problem, increase negative weight and add adversarial negative generations. Change one variable at a time and evaluate on a fixed holdout set.

Fix 3: train against the phrases that fool the model

Collect false activations from actual use and convert them into hard negatives. Also synthesize phonetic neighbours, partial phrases and common sentences containing similar sound sequences. Random background data reduces generic false positives; targeted negatives teach the exact boundary that the current model is missing.

Fix 4: use real-device validation

Do not choose parameters from training recall alone. Build a fixed evaluation set with unseen speakers, the final microphone, several distances and realistic background sound. Report false rejects and false activations together. A parameter change is useful only if it improves the operating point your product needs.

An alternative: learn the target representation instead of freezing it

When phrase-by-phrase tuning becomes the main cost, another approach is to train the compact keyword model for the target task instead of keeping a universal speech embedding frozen.

In 2026, we rebuilt Voicute around a self-developed training pipeline that trains the compact model for the requested language and phrase. It combines language-specific TTS voices, speaker diversity, acoustic augmentation and an optional real-recording enhancement path. The current training service supports Chinese, English, Japanese, French and German.

“More stable across languages” does not mean every phrase, microphone and room receives an identical recall score. It means the training pipeline can adapt the complete compact model to the target language and phrase instead of changing only a classifier above a fixed representation. That makes multilingual behavior and phrase-to-phrase variation more controllable.

Models are exported as standard ONNX/TFLite artifacts for local validation. ONNX targets Python, desktop, Android and Web runtimes; ESP32-S3 uses the INT8 TFLite Micro path. Downloaded models run locally without a Voicute runtime AccessKey.

Primary sources

• openWakeWord architecture and training documentation
• Maintainer discussion: different wake words require different parameters
• Public example of a low-recall automatic training run
• openWakeWord synthetic-data guidance