Seitdem intelligente persönliche Sprachassistenten wie Siri (2012) oder Smart Speaker wie Amazon Echo (2014) für die breite Masse erschienen sind, hat sich viel in dem Bereich getan. Viele der großen Unternehmen wie Apple, Microsoft, Google und Amazon investieren nicht nur viel in dem Bereich sondern entwickeln auch alle ihre eigene Sprachassistenten.
Was jedoch alle kommerziellen Sprachassistenten gemein haben ist, dass sie nicht auf Privatsphäre ausgelegt sind und hauptsächlich cloudbasiert arbeiten. Wenn es um Datenschutz, Privatsphäre oder Offlinetauglichkeit geht sind diese Geräte also ungeeignet.
Seit einigen Jahren gibt es jedoch ernstzunehmendere Open-Source Lösungen, die den Fokus auf den Punkt Privatsphäre legen. Diese sogennanten Maker-Lösungen werden i.d.R. auf eigener Hardware wie z.B. einem Raspberry Pi installiert und bieten neben Privatsphäre und Datenschutzkonformität außerdem oft noch eine höhere Konfigurierbarkeit und Offlinetauglichkeit.
Snips, ein französisches Unternehmen, welches seit seiner Gründung im Jahr 2013, in den Bereichen Künstliche Intelligenz und Mensch-Computer Interaktion geforscht hat, veröffentlichte 2017 erstmals eine Spracherkennungsplattform bei der Privatsphäre schon beim Entwurf eine Hauptrolle gespielt hat (private-by-design). Die Privatsphäre wird hierbei dadurch gewährleistet, dass alle Berechnung offline durchgeführt werden und somit keine datenschutzkritischen Anfragen nach außen notwendig sind.
Dadruch war es zum ersten Mal möglich einen eigenen erstzunehmenden Sprachassistenten mithilfe eines Raspberry Pi zu erstellen, der datenschutzkonform und offlinetauglich ist.
Snips wurde 2019 von Sonos gekauft wodurch der Support für die öffentliche Plattform eingestellt worden ist. Mit Jasper, Mycroft, Rhasspy und Alice gibt es jedoch weitere ähnliche Lösungen.
Auch wenn der Support für Snips eingestellt ist, sind einige Softwarekomponenten von Snips übrig geblieben, die z.B. immer noch in Rhasspy und Alice Verwendung finden.
Ein Sprachassistent ist aus mehreren Softwarekomponenten zusammengesetzt. Die Softwarekomponenten, die einen Sprachassistenten ausmachen sind folgende:
Vor jeder Bedienung muss der Sprachassistent erst einmal mittels “Wake Word” (auch als hotword bekannt) aktiviert werden. Sobald das Wort erkannt wurde, wartet der Assistent für eine bestimmte Zeit auf Anweisungen.
Bekannte Beispiel für Wake-words sind “Okay Google” für den Google Assistant und “Hey Siri”.
Es gibt u.a. folgende Wake-word-engines:
Nach der Aktivierung durch die Wake-word-engine nimmt der Sprachassistent das Gesagte für eine bestimmte Zeit (ASR timeout) auf und wandelt es in Text um. Dabei gibt es mehrere Teilergebnisse und ein finales Endergebnis. Dafür ist Automatic-Speech-Recognition (ASR) bzw. Speech-to-Text (STT) verantwortlich.
Die Spracherkennung basiert auf Machine Learning Modellen. Es können entweder vorgefertigte Modelle genutzt werden (pre-trained models), die mit einer Liste von gebräuchlichen Wörtern trainiert sind oder selbst trainierte Modelle, die man mit den Befehlen trainiert, die man vom Nutzer erwartet. Letzteres verbessertet die Texterkennung, vermindert jedoch zur gleichen Zeit die Flexibilität des Systems.
Hierfür gibt es u.a. folgende Engines:
Nachdem das Gesprochene durch das Speech-to-Text System in Text umgewandelt worden ist, muss als nächstes erkannt werden welchen der verfügbaren Aufgaben (Intents) der Nutzer mit seiner Anweisung beabsichtigt. Die NLU gibt außerdem an wie wahrscheinlich der gefundene Intent ist (max 1.0). Neben der Erkennung des Intents wird außerdem die im Befehl enthaltenen Variablen (Slots), wie z.B. Zahlen, Zustände, Orte und Objekte erkannt.
Diese Komponente nennt man Intent recognition oder Natural Language Understanding (NLU).
Nehmen wir an die ASR hat folgende Eingabesatz in Text umgewandelt:
Wie wird das Wetter um 9 Uhr in Paris?
Eine gut-trainierte NLU erzeugt daraus beispielsweise folgenden strukturierten Datensatz:
{
"intent": {
"intentName": "searchWeatherForecast",
"probability": 0.95
},
"slots": [
{
"value": "paris",
"entity": "locality",
"slotName": "forecast_locality"
},
{
"value": {
"kind": "InstantTime",
"value": "2018-02-08 20:00:00 +00:00"
},
"entity": "snips/datetime",
"slotName": "forecast_start_datetime"
}
]
}
NLUs werden mithilfe verschiedener Ansätze realisiert. Die meisten davon verwenden eine KI (bspw. Neuronales Netzwerk) um Intent und Slots zu erkennen. Eine große Anzahl an verschiedenen Slots kann den Arbeitsaufwand beim Trainieren erhöhen. NLUs unterscheiden sich je nach Ansatz in Ihrer Flexibilität, Trainingsdauer, Erkennungsdauer und idealen Anzahl an Sätzen. Eine gute Übersicht findet man auf der Dokumentation von Rhasspy von der wir folgende Tabelle entnommen haben:
| NLU | Ideale Anzahl an Sätzen | Trainingsdauer | Erkennungsdauer | Flexibilität | Lizenz | Alice | Rhasspy |
|---|---|---|---|---|---|---|---|
| Snips | 1K-100K | moderat | sehr schnell | erfasst unbekannte Wörter/Einheiten | Apache 2 Lizenz | ✗ | ✗ |
| Fsticuffs | 1M+ | sehr schnell | sehr schnell | ignoriert unbekannte Wörter | – | ✗ | |
| Fuzzywuzzy | 100-1K | schnell | sehr schnell | erlaubt fuzzy string matching | GPL 2.0 Lizenz | ✗ | |
| RasaNLU | 1K-100K | sehr langsam | moderat | erfasst unbekannte Wörter | Apache 2 Lizenz | ✗ | |
| Mycroft Adapt | 100-1K | moderat | schnell | ignoriert unbekannte Wörter | – | ✗ | |
| Flair | 1K-100K | sehr langsam | moderat | erfasst unbekannte Wörter | – | ✗ |
Nachdem der Intent erkannt ist, kommt Intenthandling ins Spiel. Hier wird der eigentliche Befehl ausgeführt und dem Nutzer bei Bedarf geantwortet.
Bei Bedarf antwortet der Assistent dem Nutzer mit einem vom Intenthandler bestimmten Text. Dafür ist eine Text-to-Speech (TTS) Engine nötig.
Folgende Text-to-Speech-Engines stehen zur Auswahl:
Der Dialog Manager verwaltet eine Sitzung, die durch ein erkanntes Wakeword oder einem manuellen startSession initiiert wird und koordiniert ASR, NLU und TTS bis ein Intent durchgeführt oder abgebrochen ist. Wenn nachdem der Intent erkannt worden ist weitere Eingaben des Nutzers erforderlich sind, kann die Sitzung verlängert werden. Es kann nur eine Sitzung zu einer Zeit geben. Wenn zeitgleich weitere Sitzungen erstellt werden, landen diese erst einmal in einer Warteschlange.
Der vorgestellte Techstack enthält nur die wesentlichen Komponenten eines Sprachassistenten.
Die Technologie für die Kommunikation zwischen den Komponenten fehlt jedoch zum Beispiel. Rhasspy und Alice verwenden dafür das von Snips entwickelte Hermes Protokoll in Kombination mit einem MQTT Broker. Hier wird überwiegend Mosquitto von Eclipse eingesetzt. MQTT setzt nicht auf das etablierte Client/Server-Modellen sondern verwendet das Publish/Subscribe-Modell. Bei MQTT gibt es einen Broker, der es erlaubt für ein bestimmtes Topic eine Nachricht zu publishen oder ein bestimmtes Topic zu subscriben um alle Nachrichten zu erhalten, die zu diesem Topic veröffentlicht werden.
Für den Bereich SmartHome ist außerdem das ZigBee-Protokoll wichtig, welches mit auch mit MQTT angesprochen werden kann mithilfe von ZigBee2MQTT.
Für mehr Informationen zu dem Thema bitte Weitere Technologie anschauen.
Um den Sprachassistenten mit Funktionalität zu erweitern, müssen weitere Intents erzeugt werden. Diese müssen wiederum implementiert werden (Intent handling). Je nachdem welches Framework dafür verwendet wird gibt es unterschiedliche Möglichkeiten. Rhasspy unterstützt Hermes kompatible Services wie zum Beispiel Home Assistant und Hass.io. Der Skillstore von Alice unterstützt auch verschiedene Services mithilfe von Skills.
Makerlösungen bieten aber auch eigene Entwicklungsmöglichkeiten. Unter Rhasspy kann das Intenthandling mit Python oder Nodered umgesetzt werden.
Im Gegensatz zu Rhasspy entwickelt man mit Alice nicht unbedingt Individuallösungen. Alice hat ein eigenes Skillsystem mit einem offiziellen Store, vergleichbar mit Alexa Skills und Google Actions. Dadurch kann man bei Bedarf mit Python eigene Skills erstellen und diese im Store veröffentlichen aber auch auf eine Vielzahl von der Community entwickelten Skills zurückgreifen ohne jeglichen Programmieraufwand.
Mit Scenarios, welches eine integrierte Node Red-Instanz ist, kann man theoretisch auch Intent handling betreiben indem man auf den erkannten Intent per MQTT Topic hört. Man müsste jedoch erst einmal einen Skill ohne jegliche Funktionalität erzeugen um neue Intents erstellen zu können. Scenarios ist daher nicht zum Intent Handling ausgelegt sondern ist vielmehr zum Personalisieren vorhandener Skills gedacht.