Warum openWakeWord je nach Wake Word unterschiedlich erkennt
Zwei eigene Wake Words werden mit demselben Rezept trainiert. Das erste reagiert zuverlässig, das zweite erreicht kaum den Schwellwert. Mehr synthetische Beispiele oder zusätzliche Trainingsschritte lösen das Problem nicht immer.
Was die offizielle Architektur macht
Die openWakeWord-Dokumentation beschreibt drei Stufen:
- Mel-Spektrogramm mit festen Parametern;
- gemeinsamer, von einem Google-Modell abgeleiteter Speech-Embedding-Backbone;
- ein kleiner Klassifikator für das jeweilige Wake Word.
Diese Architektur ist nicht einfach „veraltet“. Sie ist eine bewusste Transfer-Learning-Entscheidung: Das vortrainierte Embedding senkt Daten- und Trainingsaufwand erheblich. Der Nachteil ist, dass das Training eines eigenen Wortes den eingefrorenen Merkmalsraum nicht verändern kann.
Warum Wörter unterschiedlich schwer sind
Ein längerer, akustisch markanter Ausdruck kann im festen Embedding-Raum weit von Alltagssprache liegen. Ein kurzes oder häufiges Wort kann sich dagegen mit normaler Sprache, Aussprachevarianten oder ähnlich klingenden Begriffen überlappen. Derselbe Klassifikator trennt diese Fälle nicht gleich gut.
Das ist eine technische Folgerung aus der veröffentlichten Architektur, kein Beweis dafür, dass Frozen Embeddings grundsätzlich schlecht funktionieren. Die mitgelieferten englischen Modelle zeigen, dass der Ansatz mit passender Phrase, Datenbasis und Parametern sehr gut funktionieren kann.
Der Maintainer bestätigt wortabhängige Parameter
In der offiziellen Diskussion #171 erklärt der Maintainer, dass die vortrainierten Modelle unterschiedliche Parameter verwenden. Es gebe keinen Parametersatz, der für alle Wake Words gut funktioniert; Einstellungen für ein Wort könnten ein anderes sogar verschlechtern. Trainingsmetriken korrelieren außerdem nicht immer sauber mit dem späteren Verhalten.
Issue #110 dokumentiert einen automatischen Trainingslauf mit ungefähr 25,7 Prozent Recall. Eine andere Trainingsroute funktionierte beim selben Nutzer besser. Das ist kein allgemeiner Benchmark, zeigt aber, warum eine erfolgreich erzeugte Modelldatei noch kein produktionsreifes Modell beweist.
Was man zuerst prüfen sollte
- 16-kHz-Mono-PCM, Framing und Pufferung;
- Rohscores vor Änderung des Schwellwerts;
- ein fester Testsatz mit unbekannten Sprechern;
- ähnlich klingende Wörter und echte Fehlaktivierungen;
- das endgültige Mikrofon, Abstände und Raumgeräusche.
| Problem | Versuch | Risiko |
|---|---|---|
| Niedriger Recall | Negative Weight reduzieren, positive Stimmen erweitern | Mehr Fehlaktivierungen |
| Viele Fehlaktivierungen | Hard Negatives hinzufügen, Negative Weight erhöhen | Recall kann sinken |
| Nur eine Aussprache funktioniert | Sprecher und reale Aufnahmen ergänzen | Überanpassung vermeiden |
| Ein Wort bleibt schwierig | Längere, markantere Phrase wählen | Produktname kann sich ändern |
Alternative: das kompakte Modell für Sprache und Zielwort trainieren
2026 haben wir für Voicute eine eigene Trainingspipeline aufgebaut. Statt nur einen Klassifikator über einem unveränderten Universal-Embedding anzupassen, wird das kompakte Modell für die angeforderte Sprache und Phrase trainiert. Sprachspezifische TTS-Stimmen, verschiedene Sprecher, akustische Augmentation und optional reale Aufnahmen sollen Unterschiede zwischen Wörtern und Sprachen reduzieren.
Aktuell unterstützt die Trainingsoberfläche Chinesisch, Englisch, Japanisch, Französisch und Deutsch. „Stabiler mehrsprachig“ ist keine Garantie für identische Recall-Werte in jedem Raum. Es bedeutet, dass die vollständige kompakte Repräsentation an Sprache und Zielwort angepasst werden kann und dadurch kontrollierbarer ist.
Der Export erfolgt als ONNX beziehungsweise TFLite. Heruntergeladene Modelle laufen lokal ohne Voicute-AccessKey. Ein Demo-Modell lässt sich vorab in der Konsole mit dem eigenen Mikrofon testen und herunterladen.