Multi-Keyword-Wake-Word: Ein Modell, 10 Befehle
Die meisten Wake-Word-Engines bauen auf einer einzigen Annahme auf: Ein Modell erkennt ein Wort. openWakeWord, der Standard in Home Assistant, funktioniert genau so. Aber eine echte Sprachsteuerung hört selten bei einer Phrase auf. Du weckst das Gerät mit „Hey Lampe", und dann willst du „heller", „dunkler", „aus" sagen – und wenn jedes davon ein eigenes Modell braucht, wird deine Integration schnell kompliziert.
Warum „ein Wort pro Modell" ein Problem ist
Angenommen, dein Produkt hat ein Wake-Word und drei Befehle. Mit dem Ein-Wort-pro-Modell-Ansatz laufen dann vier Modelle parallel:
- Speicher: vier Modelle × ~100 KB = ~400 KB, bevor du überhaupt etwas anderes hinzufügst.
- CPU: vier Modelle, die auf jedem Audio-Frame inferieren.
- Komplexität: vier Callbacks, vier Schwellwerte, vier Stellen, an denen Fehlauslösungen zu debuggen sind.
Bei zehn Befehlen wird das unübersichtlich. Die saubere Alternative ist ein einzelnes Modell, das mehrere Schlüsselwörter gleichzeitig erkennt.
Wie ein Modell mehrere Wörter erkennt
Der Trick ist ein gemeinsames Backbone. Statt vier getrennter Netze trainierst du einen Feature-Extraktor, der eine kleine Zahl pro-Wort-Klassifikatoren speist. Der teure Teil – rohes Audio in akustische Merkmale zu verwandeln – läuft einmal, und nur die günstigen Klassifikatorköpfe unterscheiden sich pro Wort.
Das Ergebnis:
| Schlüsselwörter in einem Modell | Modellgröße | Inferenz |
|---|---|---|
| 1 Wort | ~128 KB | < 5 ms |
| 3 Wörter | ~135 KB | < 5 ms |
| 10 Wörter | ~167 KB | < 5 ms |
Neun weitere Keywords kosten ~40 KB und praktisch keine Latenz, weil das Backbone geteilt wird. Das ist der Unterschied zwischen „einem Wake-Word" und „einer kleinen Sprachsteuerung".
Ein konkretes Beispiel
Trainiere ein Modell auf vier Keywords – ein Wake-Word plus drei Befehle – und der Callback wird zu einem einfachen Switch:
engine.start(lambda word, prob, info: handle(word))
def handle(word):
if word == "hey_lampe": return listen() # auf Befehle warten
if word == "heller": return set_brightness(+1)
if word == "dunkler": return set_brightness(-1)
if word == "aus": return power_off()
Das Modell ist weiterhin Standard-ONNX und läuft damit überall, wo dein Ein-Wort-Modell lief – Android, Linux, ESP32, Web – über dieselbe Open-Source-Engine onnx-wakeword.
Wann Multi-Keyword besser ist als „Wake-Word + ASR"
Die Alternative zu einem Multi-Keyword-Modell ist, ein Wake-Word mit einem vollständigen Spracherkennungssystem (ASR) zu kombinieren, um die Befehle zu verstehen. Für einen festen Befehlssatz ist das übertrieben:
| Multi-Keyword-Modell | Wake-Word + ASR | |
|---|---|---|
| Modellgröße | ~135–167 KB | 100–200 MB |
| Latenz | < 5 ms | 100–500 ms |
| Offline auf dem Gerät | Ja, überall | Meist größeres Gerät oder Cloud nötig |
| Genauigkeit bei festen Phrasen | Hoch | Hoch, aber übertrieben |
Wenn deine Befehle eine bekannte, feste Liste sind – der übliche Fall bei Lampen, Ventilatoren, Spielzeug und Haushaltsgeräten – ist ein Multi-Keyword-Modell deutlich leichter. ASR lohnt sich erst, wenn der Nutzer alles sagen kann.
Der Haken: Die meisten Tools bieten es nicht an
openWakeWord ist ein-Wort-pro-Modell und nur englisch. Picovoice kann Multi-Keyword, aber unter Lizenz pro Gerät. DIY-Toolkits können es – wenn du die Daten und die Zeit hast. Wenn du mehrere Schlüsselwörter in einem Modell, in einer nicht-englischen Sprache, ohne Lizenzdeal brauchst, ist genau das die Lücke, für die ein Multi-Keyword-Generator da ist.
Multi-Keyword-Modell trainieren →