Wir sind überzeugt, dass Sprachschnittstellen in Zukunft als Eingabekanal neben Touch und Text eine immer wichtigere Rolle einnehmen werden. Die aktuelle Entwicklung von Speech-to-Text, Plattformen zur Verarbeitung von natürlicher Sprache beziehungsweise Software mit kognitiven Fähigkeiten, kommt uns dabei entgegen. Ein Grund für diese rasante Entwicklung ist der Umstand, dass Benutzerdaten für viele Firmen eine wichtige Grundlage für ihre bestehenden Geschäftsmodelle sind. Gleichzeitig eröffnen Sprachschnittstellen neue Geschäftsfelder, was die Firmen zum Handeln zwingt, um nicht ins Hintertreffen zu geraten, wenn sich das Benutzerverhalten aufgrund von Sprachschnittstellen ändert.

Bei der Entwicklung der Fahrplan App basierend auf iOS / SirKit stellten wir fest, dass SiriKit gegenwärtig nur eine sehr beschränkte Anzahl Domains unterstützt, beziehungsweise dass das Sprachinterface selbst sehr beschränkt ist. Wir beschlossen deshalb, eine zweite Version der Fahrplan App basierend auf Android zu entwickeln. Unsere Erfahrungen und Ergebnisse beschreiben wir in den folgenden Abschnitten. Wie man im Video sieht, haben wir mit diesem zweiten Prototypen einen grossen Schritt nach vorn gemacht:

Blick hinter die Kulissen

Die 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 Googles Speech API. Die Beantwortung ist 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.

Wie bereits erwähnt, ist Open Transport 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.

Spracherkennung und Text-to-Speech funktionieren zum Teil auch ohne Verbindung zum Internet. Für Anwendungen, welche mit anderen Diensten / Schnittstellen interagieren oder auf aktuellen Informationen beruhen, wird jedoch in der Regel eine Internetverbindung benötigt.

Nächste Schritte

Die Entwicklung von Plattformen wie API.AI schreitet schnell voran und eröffnet viele neue Möglichkeiten, per Sprachinterfaces mit dem User zu interagieren. Auch wenn klassische Eingabemethoden wie Touch und Text wohl nie vollständig durch Sprachinterfaces ersetzt werden, zeigt uns dieser und weitere Prototypen, dass Sprachassistenten in verschiedenen Alltagsbereichen eine spür- und hörbare Bereicherung sein können und den Benutzerkomfort stark erhöhen. Convenience ist aber nicht der einzige Faktor, um die Akzeptanz zu verbessern. Ein weiterer wichtiger Faktor ist die Möglichkeit, dass der Mensch eine natürliche Konversation mit einem Gerät führen kann. Um dies zu erreichen, möchten wir uns in den folgenden Bereichen verbessern:

• Gleichzeitige Verarbeitung von multiplen Domains, beziehungsweise die Fähigkeit, mit Zwischensätzen umzugehen, welche ausserhalb des gegenwärtigen Kontexts sind
• Unterstützung von allen Sprachen und deren Dialekten
• Das Gerät hört immer mit und erkennt auf einfache Weise, wenn es angesprochen wird beziehungsweise einen Beitrag leisten kann
• Erkennung und Unterscheidung von verschiedenen  Personen

Eine natürliche Konversation ist viel mehr als nur die Transkription von Sprache nach Text und dessen Verarbeitung. Wir möchten, dass Menschen in Zukunft völlig natürlich mit ihren Geräten kommunizieren können. Wir sind noch nicht soweit, aber wir sind auf einem sehr guten Weg dorthin.