Wake Word Detection

Wake word detection (also called keyword spotting or hotword detection) is the small, always-running model that listens to a live microphone feed for one specific phrase, such as “Hey Siri,” “OK Google,” or “Alexa,” and does nothing else until it hears one. The moment it fires, it hands control to the rest of the voice stack: full ASR, a language model, and a text-to-speech reply. Everything before that handoff has to run on-device, continuously, on a power and compute budget measured in milliwatts, because the alternative, streaming every second of ambient audio to a server, is both a privacy non-starter and a battery drain no phone or smart speaker could survive.

This is what makes wake word detection a genuinely distinct engineering problem from speech recognition, not a smaller version of it. A full ASR model is invoked once, briefly, after a human has already signaled intent to speak. A wake word model runs forever, on every frame of audio a microphone ever captures, and has to decide, thousands of times a minute, whether the last second of sound contained a specific short phrase or not.

The Pipeline: From Raw Audio to a Trigger

A wake word system is a tight, three-stage loop running continuously on-device:

graph LR
    A[Raw audio stream] --> B[Feature extraction]
    B --> C[Keyword spotting model]
    C --> D{Score > threshold?}
    D -->|No| A
    D -->|Yes| E[Wake full pipeline]

    classDef default fill:#ffffff,stroke:#4338CA,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef data    fill:#EEF0F7,stroke:#0D9488,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef process fill:#F7F8FC,stroke:#6366F1,stroke-width:2px,color:#0F172A,rx:8px,ry:8px;
    classDef output  fill:#4338CA,stroke:#4338CA,stroke-width:2px,color:#ffffff,rx:8px,ry:8px;

    class A data;
    class B,C process;
    class D process;
    class E output;

1. Feature extraction converts a rolling window of raw waveform (typically 1-1.5 seconds, updated every 10-20ms) into a compact representation, usually log-Mel filterbank energies or MFCCs, the same front end used in most ASR systems.
2. The keyword spotting model scores that window: how much does it look like the target phrase? Early systems used Hidden Markov Models; production systems since the mid-2010s use small convolutional or recurrent neural networks, and newer ones use compact attention-based or streaming transformer architectures.
3. A threshold decision turns the continuous score into a binary fire/don’t-fire signal. Cross that threshold and the device wakes the rest of the pipeline; stay under it and the frame is discarded, often without ever leaving RAM.

# Scenario: an always-on smart speaker listening for "Hey Nova" on a microcontroller
import numpy as np
from kws_runtime import FeatureExtractor, TinyKWSModel  # illustrative, not a real package

extractor = FeatureExtractor(sample_rate=16000, window_ms=1000, hop_ms=20)
model = TinyKWSModel.load("hey_nova_int8.tflite")  # quantized, <200KB
THRESHOLD = 0.85

def on_audio_frame(pcm_chunk: np.ndarray):
    features = extractor.push(pcm_chunk)          # log-Mel filterbank features
    if features is None:
        return                                     # not enough audio buffered yet
    score = model.predict(features)                 # runs in <5ms on-device
    if score > THRESHOLD:
        trigger_full_pipeline()                      # wake ASR + LLM + TTS

Architecture Approaches Compared

The two-stage pattern deserves its own mention because it is what nearly every shipping commercial device actually runs. The on-device model is deliberately loose (it would rather over-trigger than miss a real wake word), and a second, much larger model in the cloud double-checks the audio a moment later; if the cloud model disagrees, the device silently goes back to sleep without the user noticing anything happened.

# Scenario: cloud-side verification stage after an on-device trigger fires
def verify_wake_word(audio_clip: bytes) -> bool:
    # audio_clip is the ~1.5s buffer captured around the on-device trigger
    result = cloud_verifier_model.transcribe_and_score(audio_clip)
    return result.keyword == "hey nova" and result.confidence > 0.97

if on_device_trigger_fired:
    if verify_wake_word(captured_audio):
        start_conversation()
    else:
        go_back_to_sleep()  # false alarm, filtered before the user ever notices

The Threshold Trade-off: False Accepts vs. False Rejects

Every wake word model outputs a continuous confidence score, and the single threshold applied to that score is the one dial that determines the entire user experience. Set it too low and the device fires on TV commercials, similar-sounding words, or background chatter (a false accept, measured as false accepts per hour of ambient audio). Set it too high and the device ignores its own name when a real user says it in a noisy kitchen (a false reject, measured as a false reject rate against genuine attempts). These two error types move in opposite directions as the threshold shifts, and there is no setting that minimizes both at once.

Training Data and the Negative Sampling Problem

A wake word model’s hardest job isn’t recognizing the target phrase, it’s correctly rejecting everything else. Training data typically includes:

• Positive examples: hundreds to thousands of recordings of the phrase, spoken by diverse speakers, accents, and distances from the microphone, often augmented with reverberation and background noise to simulate real rooms.
• Hard negatives: phrases that sound acoustically close to the target (“Hey Nova” vs. “OK Nova,” or vs. a TV ad that happens to contain a similar cadence), which matter far more for reducing false accepts than random negative audio does.
• General negative audio: music, television, conversation, kitchen noise, pulled from massive unlabeled corpora, since the model spends 99.9% of its runtime listening to audio that isn’t the wake word at all.

Because collecting enough real recordings of a brand-new wake phrase is slow and expensive, most production pipelines now lean on text-to-speech data augmentation, synthesizing thousands of speaker- and accent-varied renditions of a new phrase (an approach documented in the “data-efficient” wake word literature), which is also what makes it practical for products to ship custom, user-chosen wake words rather than a single fixed one.

What’s New (2025-2026)

• Personalized and multiple wake words: rather than one fixed phrase burned into firmware, several vendors now support user-defined wake words trained from a handful of the user’s own recordings plus TTS-augmented data, and devices increasingly listen for several valid triggers at once rather than a single hardcoded phrase.
• Speaker-adaptive triggering: some assistants now combine wake word detection with lightweight speaker verification in the same pass, so the device can distinguish “my kid saying the wake word” from “a stranger’s voice on TV saying it,” cutting false accepts without raising the base threshold.
• Streaming transformer and attention-based spotting: production systems are moving from pure CNN/RNN spotting toward compact streaming-attention architectures that hold accuracy at even smaller memory footprints, following the trend documented in 2025-2026 small-footprint keyword spotting surveys.
• Convergence with audio-native models: as more of the downstream pipeline moves to single end-to-end speech-to-speech networks, some experimental systems fold the wake word decision into the front end of that same network rather than keeping it a fully separate model, though the tiny always-on trigger remains dominant for battery-powered devices for now.

Wake Word Detection vs. Continuous ASR vs. Push-to-Talk

Wake word detection exists precisely to make hands-free voice interaction possible without the privacy and power cost of continuous ASR, and without the friction of push-to-talk, which is why it remains the entry point for essentially every consumer voice assistant, from phones to smart speakers to the half-duplex agents built on top of them.