In the Code: Der Kampf um die Sprach­schnitt­stelle

Ist die Sprachschnittstelle ein Hype der Tech-Giganten? Eine andere Frage sollte im Vordergrund stehen, so Michael Wechner von Netcetera und zeigt konkret warum.
 
Es tobt ein Krieg zwischen den Tech Giganten um die Vorherrschaft bei der Sprachschnittstelle. Die Gewinner können damit noch mehr Daten sammeln, noch besser das Verhalten der Benutzer verstehen. Doch was nützt dem Benutzer eine Sprachschnittstelle?
 
Der Dichter Carl Sandburg schrieb 1936 "Sometime they'll give a war and nobody will come" ("Stell Dir vor, es ist Krieg, und keiner geht hin"). Ist die Sprachschnittstelle nur ein Hype, der getrieben wird vom Überlebenskampf der Tech Giganten? Um die Frage nach dem Nutzen zu beantworten, hilft es zu fragen "wieso sprechen Menschen überhaupt"?
 
Sprache ist eine Form der Kommunikation, mit der man Informationen austauscht. Das Teilen von Informationen hilft zu überleben. MRI-Scans des menschlichen Gehirns zeigen, dass beim Sex, Essen und Austausch von Informationen, das gleiche Belohnungssystem im Gehirn aktiv ist. Sprachen haben sich evolutiv entwickelt, da sie helfen zu überleben.
 
Die Erkenntnis daraus: Wir sollten keine Sprachschnittstellen implementieren nur der Sprache willen, sondern uns fragen "was hilft uns zu überleben?". Der Einsatz von Sprache wird automatisch folgen. In den folgenden Abschnitten geben wir einige Beispiele, die diese Erkenntnis illustrieren.
 
Sprachinterface versus Button
Angenommen wir kommen mit dem Flugzeug von einer Geschäftsreise zurück und möchten möglichst schnell vom Flughafen nach Hause. Wir wissen jedoch nicht, wann der nächste Zug fährt, beziehungsweise ob wir uns auf dem Weg zum Flughafenbahnhof beeilen müssen. Hätten wir einen menschlichen Assistenten, der den Zugfahrplan auswendig kennt, würden wir ihn fragen wann der nächste Zug nach Hause fährt. Der Assistent würde antworten "es fährt ein Zug in 13 Minuten, das können wir noch schaffen, aber wir müssen uns ein bisschen sputen", oder "jetzt ist gerade ein Zug gefahren, der Nächste fährt erst in 40 Minuten. Wir können uns ruhig Zeit lassen beim Aussteigen". Viele mobile Fahrplan-Apps haben mittlerweile einen "Take me Home" Button. Das heisst, die App weiss wo wir wohnen und dank der Geo-Location erhalten wir per Knopfdruck einen Vorschlag für die Abfahrt der nächsten Züge. Sitzen wir noch wartend im Flugzeug, ziehen wir wohl den "Take me Home" Button gegenüber dem Sprachinterface vor. Es ist effizient und unsere Sitznachbarn erfahren nicht wo wir Zuhause sind. Befinden wir uns aber bereits auf dem Weg zum Flughafenbahnhof mit Gepäck in beiden Händen, wären wir froh um ein Sprachinterface.
 
Was bringt es im Laden?
Amazon arbeitet mit "Amazon Go" seit einiger Zeit daran den offline Einkaufsprozess zu digitalisieren. Es liegt nahe, dass Amazon diesen Prozess einsetzen wird bei der Lebensmittelhandelskette Whole Foods, welche Amazon im Sommer 2017 laut 'Forbes' für 13.7 Milliarden Dollar übernommen hat.
 
Der offline "End to End Shopping Process" wird in Zukunft möglicherweise durchgehend digital sein. Ein Kunde erstellt Zuhause oder unterwegs seine Einkaufsliste sprachbasiert auf dem Mobile. Beim Betreten der Filiale ordnet sich die Einkaufsliste gemäss dem Ladenlayout. Augmented Reality auf dem Mobile hilft dem Kunden seine Artikel zu finden und Produkt-Zusatzinformationen zu erhalten. Die Mobile App wird automatisch synchronisiert, wenn ein Produkt in den physischen Einkaufswagen gelegt wird und der Kunde muss nicht mehr an einer Kasse anstehen, sondern kann bequem via Mobile App beim Verlassen des Ladens bezahlen.
 
Das Sprachinterface ist bei diesem Prozess nur ein Puzzleteil. Beim Erfassen der Einkaufsliste ist es sinnvoll, da das sprachbasierte Erfassen von Artikeln sehr effizient ist.
 
Mit dem Roboter im Lift sprechen
Menschen mit Muskelschwund haben eine fortschreitende Muskelschwäche. Gegenwärtige Medikamente können den Verlauf verzögern, aber nicht aufhalten. Man ist bestrebt, die Lebensqualität so lange wie möglich zu erhalten, unter anderem mit einem Roboterarm, der am Rollstuhl befestigt ist und mit einem Joystick gesteuert wird. Der Roboterarm wird zum Beispiel verwendet, um in einem Aufzug das Stockwerk auszuwählen. Ein Aufzug mit Sprachinterface wäre in diesem Fall die einfachste Lösung, aber nicht jeder Aufzug wird in nächster Zeit mit einem Sprachinterface ausgestattet werden.
 
Eine mögliche Zwischenlösung wäre ein Roboterarm mit Sprachinterface und Bilderkennung. Könnte die Person im Aufzug dem Roboterarm die Anweisung geben "bitte in den zweiten Stock", würde der Roboterarm selbstständig nach dem Bedienfeld suchen und den Knopf für den zweiten Stock drücken.
 
Wird die gesprochene Sprache überschätzt?
Die beschriebenen Anwendungsfälle zeigen, dass Sprachschnittstellen manchmal sehr sinnvoll sind, die akustische Sprache jedoch nicht immer die beste Variante ist. Möglicherweise überschätzen wir teilweise die gesprochene Sprache
Grafik: Netcetera.
und merken nicht, dass wir mit anderen Mitteln oft besser und effizienter kommunizieren.
 
Gute Alternativen zeigen sich zum Beispiel in der Fortbewegung. Die Natur hat Beine und Flossen hervorgebracht. Der Mensch jedoch hat Räder, Propeller und Düsen entwickelt, welche abhängig vom Anwendungsgebiet effizienter sind als Beine oder Flossen. Es ist deshalb sinnvoll zuerst das eigentliche Problem zu erkennen und danach die beste Lösung dafür zu suchen.
 
Was Tech-Firmen von Babies lernen können
Zurück zur Frage wieso wir Menschen sprechen. Welche Möglichkeiten hat ein neugeborenes Kind zu kommunizieren? Wenn es Hunger oder Schmerzen hat oder sonst etwas möchte? Wie oft erleben wir schreiende Kinder und den Eltern ist nicht klar wieso es schreit. Welches sind die Alternativen für das Kind zu kommunizieren, abgesehen von Gestik und Gebärden, die nur im Sichtkontakt funktionieren? Lernen wir Menschen aus Mangel an Alternativen zu sprechen?
 
Bis zum Alter von 18 bis 24 Monaten lernen Kleinkinder laut Kleinkinderpädagogen im Schnitt ungefähr 50 Wörter. Ab dann beginnt in der Regel die sogenannte Explosion des Wortschatzes. Das heisst der Wortschatz vergrössert sich stark in relativer kurzer Zeit und die Kinder beginnen ganze Sätze zu bilden. Es gibt mögliche Erklärungen für die Wortschatzexplosion, zum Beispiel die Fast Mapping Theorie oder die Forschungsarbeit des Psychologen Bob McMurray, wirklich einig scheint sich die Fach- und Forschungswelt nicht zu sein. Vielleicht auch, weil das Thema bis zum heutigen Zeitpunkt zu wenig relevant war.
 
Wie Kleinkinder lernen wir gegenwärtig für die Entwicklung von Sprachschnittstellen unsere ersten Wörter und probieren ganze Sätze zu bilden. Der Überlebenskampf der Tech Giganten fördert diese Entwicklung. Ob und wann genau die Explosion passieren wird, ist nach wie vor schwierig abzuschätzen. Aber genau diese Unberechenbarkeit macht das Thema Conversational Interfaces spannend!
 
Hinter den Kulissen: Die Funktionsweise einer sprachbasierten Fahrplan App
Eine sprachbasierte Fahrplan App besteht im Wesentlichen aus vier Komponenten. Die erste Komponente ist die Mobile App selber, die auf dem Smartphone installiert ist und mit welcher der User kommuniziert. Die Mobile App ist zuständig für die Spracherkennung auf User-Seite und die Beantwortung der Benutzeranfragen beziehungsweise die Anzeige der Ergebnisse, in unserem Fall die Fahrplanauskünfte. Die Transkription der Sprache geschieht mittels einer Speech2Text Library, beispielsweise Googles Speech API. Die Beantwortung ist beispielsweise mit Androids TextToSpeech implementiert.
 
Die eigentliche Analyse der Benutzeranfrage, um den Abfahrts- und Ankunftsort zu bestimmen, zum Beispiel aus dem transkribierten Satz "Wann fährt der nächste Zug von Zürich nach Bern?", wird nicht von der Mobile App durchgeführt, sondern von einer zweiten Komponente, die vollständig in der Cloud betrieben wird. Für diese zweite Komponente verwenden wir zurzeit Googles Plattform API.AI. Es gibt verschiedene andere Plattformen, die eine ähnliche Funktionalität anbieten, wie zum Beispiel Watson von IBM oder LUIS von Microsoft.
 
Innerhalb von API.AI definiert man einen sogenannten Agenten, der die Analyse des transkribierten Textes übernimmt, das heisst die Bestimmung der Entitäten, in unserem Fall der Haltestellen. Der Agent kann so trainiert werden, dass er Entitäten in verschiedensten natürlichen Sätzen identifizieren kann. So wird beispielsweise nicht nur "Von Bern nach Zürich" korrekt erkannt, sondern auch komplexere Sätze wie "Hallo, ich muss um 19 Uhr in Zürich sein. Wann muss ich in Bern auf den Zug?". Der User soll sich nicht gezwungen fühlen, sich dem Gerät anzupassen. Ziel ist eine möglichst natürliche Konversation mit dem Smartphone.
 
Wenn wir den Abfahrts- und Ankunftsort bestimmt haben, sind wir bereit, die entsprechenden Fahrplaninformationen herauszufinden. Dafür verwenden wir Open Transport als weitere Komponente. Da API.AI und Open Transport nicht direkt miteinander kommunizieren können, haben wir eine dritte Komponente als Middle Layer zwischen API.AI und Open Transport eingeführt. Diese dritte Komponente ist eine Java-basierte, von uns selbst entwickelte Web-Applikation, die ebenfalls in der Cloud läuft. Zu Beginn übernahm unsere Webapplikation nur das Mapping zwischen API.AI und Open Transport und generierte die möglichst natürlichen Antworten als Text. Mittlerweile speichert sie die Konversationen und liefert zusätzliche Kontextinformationen.
 
Open Transport ist die vierte Komponente in unserer Architektur, welche die benötigten Routing-Informationen beziehungsweise Fahrplaninformationen liefert. Die Verwendung von Open Transport ist in unserer eigenen Webapplikation austauschbar, so dass wir bei Bedarf jederzeit auf einen alternativen Provider für Fahrplaninformationen umschalten können.

Was die User sagen: Eine neue Schweizer Studie sagt es
Zeix und Netcetera haben gemeinsam eine Benutzer-Studie durchgeführt. Sie stützt sich auf eine sprachbasierte Fahrplan-App, die von Netcetera als Prototyp entwickelt wurde. Die Key Findings sind:
  • Die User wissen oft nicht, was und wie sie fragen sollen. Die Erwartungen an Interfaces mit Spracheingabe variieren zwischen minimal und riesig. Das Frustrationspotenzial ist entsprechend hoch.
  • Komplexere Conversational Interfaces setzen zum Teil hohe kognitive Fähigkeiten in der Verarbeitung der Konversation voraus. Die künstliche Intelligenz ist in vielen Fällen noch nicht ausreichend. Die meisten User würden das Interface nach einer enttäuschenden Erfahrung nicht wieder benutzen. Gut funktionieren sehr einfache Conversational Interfaces, die keine besonderen kognitiven Fähigkeiten im Backend benötigen.
  • Interfaces mit Spracheingabe sind besonders nützlich in Kontexten, in denen man die Hände nicht frei hat. Deshalb sollte die Hürde zum Öffnen des Interfaces möglichst niedrig sein.
Die vollumfängliche Studie ist bei Co-Autor Zeix verfügbar. (Michael Wechner)
 
Links:
Der Browser-Krieg
Does war actually make the technology and science advance faster?
 
(Übrigens: Im Wired Februar 1998 wurde in der Kolumne "Tomorrow Today" die Spracherkennung von Visteon Automotive Systems für 1999 prognostiziert.)
 
Über den Autor:
Michael Wechner, Senior Software Engineer und CI-Experte bei Netcetera, ist der Schöpfer verschiedener Open Source Projekte wie Apache Lenya, Yanel und Yarep, oder die Requirements Engineering Software Yulup. Bevor er in die Welt der Open-Source-Software einstieg, studierte er an der ETH mathematische Physik und führte am Max-Planck-Institut drei Jahre Grundlagenforschung zu Computersimulationen des dendritischen Wachstums durch. Michael war Mitorganisator der ersten Open Source CMS-Konferenz und Mitbegründer von OSCOM.
 
Über "In The Code"
Im Monatsrhythmus erhalten Spezialisten von der Redaktion ausgewählten Schweizer Unternehmen Gelegenheit, ihre Praxis-Erfahrungen zu teilen.