Was ist ein KWS-Modell? Offline-Sprachsteuerung mit ONNX

Sprachsteuerung braucht nicht immer Spracherkennung, eine Cloud-API oder ein großes Sprachmodell.

Wenn ein Gerät nur auf eine kurze, vorher festgelegte Liste von Ausdrücken reagieren soll – etwa „Licht an“, „Licht aus“, „Weiter“ oder „Foto aufnehmen“ –, reicht es oft zu erkennen, ob eines dieser Schlüsselwörter gesprochen wurde. Genau dafür ist Keyword Spotting (KWS) gedacht.

KWS ist ein spezialisiertes Audioklassifikationsverfahren. Es analysiert kurze Audiofenster und schätzt, ob ein trainiertes Schlüsselwort darin vorkommt. Es transkribiert nicht alles Gesagte und versteht keine offenen Fragen.

Wake Words sind verbreitet, aber nicht der einzige Einsatz

Häufig wird KWS für Wake Words eingesetzt. Ein kleiner Detektor wartet lokal auf eine Phrase wie „Hallo Gerät“. Erkennt er sie, kann das Produkt eine größere Spracherkennung oder einen Sprachassistenten starten.

KWS kann auch direkt Geräte steuern. Ein Lichtschalter könnte „Licht an“ und „Licht aus“ erkennen, eine Präsentationsfernbedienung „nächste Folie“ und „zurück“. Ein einfaches Gerät braucht dann keine anschließende Unterhaltung.

Bei einem festen Vokabular mit wenigen Befehlen – je nach Modell, Ähnlichkeit der Ausdrücke und Hardware auch mit etwa zehn oder mehr – lässt sich jeder erkannte Ausdruck direkt einer Aktion zuordnen. Eine allgemeingültige Obergrenze gibt es nicht. Entscheidend sind die konkreten Befehle und die gemessenen Fehlaktivierungen.

KWS und ASR beantworten unterschiedliche Fragen

Automatic Speech Recognition (ASR) wandelt Sprache in Text um. Das ist sinnvoll, wenn Menschen viele verschiedene Formulierungen verwenden und die Anwendung den gesprochenen Text benötigt.

KWS stellt eine engere Frage: Wurde einer dieser vorher festgelegten Ausdrücke gesprochen? Weil das Modell eine kleinere Aufgabe löst, kann es kompakt und lokal auf Geräten laufen, bei denen Speicher, Rechenleistung, Netzwerkzugang oder Datenschutz eine Rolle spielen.

Ein kleines KWS-Modell ist kein verkleinerter Chatbot. Es erkennt nur die trainierten Ausdrücke und muss unter den vorgesehenen Bedingungen getestet werden.

Was bedeutet lokale ONNX-Inferenz?

ONNX ist ein portables Format für Machine-Learning-Modelle. Eine passende Laufzeitumgebung kann das Modell auf einem unterstützten Gerät laden, sodass die Erkennung lokal statt über einen Sprachdienst erfolgt.

Mikrofon
  → Audio vorbereiten und kurze Frames bilden
  → die vom Modell erwarteten Audiomerkmale extrahieren
  → ONNX-Inferenz ausführen
  → Scores glätten und Erkennungsregeln anwenden
  → Keyword-Ereignis auslösen
  → Aktion in App oder Gerät ausführen

Nach der Installation von Modell und Laufzeit kann die Erkennung ohne Internetverbindung funktionieren. Das verringert die Abhängigkeit vom Netzwerk und kann dafür sorgen, dass das Mikrofon-Audio auf dem Gerät bleibt. Lokale Inferenz garantiert jedoch weder Datenschutz noch niedrigen Energieverbrauch von selbst: Mikrofonrechte, Audioaufnahme, Laufzeit und Leistungsaufnahme müssen passend umgesetzt werden.

ONNX bedeutet auch nicht, dass jedes Modell unverändert auf jedem Chip läuft. Das Zielgerät braucht eine kompatible ONNX-Laufzeit sowie ausreichend Speicher und Rechenleistung. Mikrocontroller benötigen unter Umständen ein anderes Exportformat oder eine optimierte Laufzeit, zum Beispiel TensorFlow Lite Micro. Deshalb sollte die komplette Pipeline auf der Zielhardware geprüft werden.

Die Modelldatei allein ist noch kein Detektor

Ein Modell gibt üblicherweise Scores für Audioframes zurück. Die Anwendung entscheidet, wann daraus ein Befehl wird. Nur einen einzelnen Score-Schwellenwert zu prüfen kann zu verpassten Befehlen, Wiederholungen oder Fehlaktivierungen führen.

Ein robuster Detektor kann mehrere aufeinanderfolgende Frames verlangen, nach einer Erkennung eine kurze Sperrzeit verwenden und Schwellenwerte anhand normaler Sprache und Hintergrundgeräusche prüfen. Ähnlich klingende Befehle sind schwieriger zu unterscheiden. Kurze Ausdrücke mit deutlich unterschiedlichen Lauten sind oft eine bessere Wahl.

Teste mit dem Mikrofon, den Stimmen, Abständen, Raumgeräuschen und Akzenten des späteren Produkts. Miss sowohl übersehene Befehle als auch Fehlaktivierungen. Ein gutes Ergebnis mit synthetischen Beispielen muss sich in einem echten Gehäuse oder lauten Raum nicht wiederholen.

Wann passt ein kleines KWS-Modell?

KWS ist eine Option, wenn die Befehlsliste kurz und im Voraus bekannt ist, jeder Ausdruck eine eindeutige Aktion auslöst und Offline-Betrieb oder lokale Audioverarbeitung wichtig sind.

ASR passt besser, wenn Nutzer Text diktieren, Befehle frei formulieren oder unbekannte Dinge sagen können müssen. Eine Kombination ist ebenfalls üblich: KWS wartet auf das Wake Word, danach übernimmt ASR für freie Sprache.

Ein praktischer Weg zum Prototyp

Notiere zuerst alle Befehle und die jeweilige Aktion. Wähle akustisch unterscheidbare Ausdrücke und eine Laufzeitumgebung für die Zielplattform. Verbinde Erkennungsereignisse mit App-Aktionen und teste Fehlaktivierungen ebenso sorgfältig wie erfolgreiche Erkennungen.

Für ein eigenes Vokabular kann ein KWS-Modell für die gewünschten Ausdrücke trainiert und beispielsweise als ONNX exportiert werden. Die Open-Source-Laufzeit onnx-wakeword bietet Inferenzintegrationen für mehrere Plattformen. Mit Voicute lassen sich eigene Keyword-Modelle erstellen.

Hinweis: Ich bin der Entwickler von Voicute und Maintainer von onnx-wakeword.