Alexa & Co.: Wofür Sprachassistenten wirklich taugen

Sprachassistenten wie Amazon Echo taugen nur bedingt für das angedachte Shopping-Szenario. Wir erläutern, wofür die digitalen Assistenzen wirklich gut sind.

Laut einer Befragung von 300 Benutzern der Amazon Sprachassistenten (Amazon Echo und Echo Dot sowie Tap) durch den US-Marktanalyst Field Agent sind die Nutzer der Alexa zwar Neuem gegenüber aufgeschlossen und probieren auch verschiedene Funktionen aus, das eigentlich durch Amazon angedachte Szenario „einfach shoppen“ wird im Grunde jedoch nicht angenommen. Mittlerweile glaubt selbst Amazon CEO Jeff Besos nicht mehr an das Szenario.

Wenn also „Shopping“ kein Szenario ist, was können digitale Sprachassistenten dann?

Warum sollten wir uns mit dem Thema der automatisierten Kommunikation im Sinne von Chatbots oder Sprachassistenten weiter beschäftigen? Können wir die Automatisierung denn wirklich nur für das Einkaufen nutzen?

Betrachtet man die diversen Einsatzmöglichkeiten der automatisierten Kommunikation, so stellt „Shopping“ durch den Einsatz von Engagement-Bots in der Tat nur einen (kleinen) Teilbereich der Anwendungsgebiete dar. Die Automatisierung der Kundenkommunikation und Sprachassistenten kann jedoch weitaus mehr als das reine Suchen und Verkaufen von Produkten.

Ein derzeit heiß diskutiertes Thema, in welchem die nächsten Hoffnungen der Assistenten-Anbieter liegen, ist die Home-Automation. Geht es nach den Vorstellungen der Hard- und Softwarehersteller, dann ist dieses Szenario das große neue Ding. Die Steuerung eines Hauses oder einer Wohnung durch einen Sprachassistenten. So kann man bereits heute per Alexa Sprachsteuerung oder auch Google Home diverse im Haus verbaute Geräte und Funktionen steuern. Ob Licht, Heizung oder Fenster – alles soll möglich werden. Angesichts der aktuell jedoch noch nicht flächendeckend verbreiteten Technologie sowie der doch noch erheblichen Sicherheitsmängel wird es wohl noch ein wenig länger brauchen, bis sich dieser Trend in jedem Haushalt durchsetzt.

Ein aus meiner Sicht sehr gutes Einsatzgebiet für automatisierte Kommunikation ist der Einsatz eines Customer-Care-Bots. Dieser Einsatz bietet für Unternehmen die Möglichkeit, einen Kundendienst 24 Stunden 7 Tage die Woche anzubieten. Dabei kann die Automatisierung der Kommunikation von Terminbuchungen, Reservierungen bis hin zur kompletten Selbstverwaltung eines Kunden getrieben werden. Ob diese Kommunikation per Sprache oder Texteingabe erfolgen soll, ist insofern wichtig, als dass man sich bei einer Sprachnutzung neben der Erkennung der Absicht eines Nutzers (des Intents) auch noch mit Sprach-Analyse an sich beschäftigen muss.

Um zu erproben, wie realistisch die Erstellung eines eigenen Customer-Care Bots ist, haben wir das einmal prototypisch durchgeführt.

Setup eines ersten Customer–Care Chatbots

Um einen eigenen Bot aufzusetzen, ist es im ersten Schritt notwendig, sich ein paar Gedanken zu machen, welche Fragen der Bot denn eigentlich beantworten können soll. In der Regel ist der schnellste Weg, sich den Posteingang des Helpdesks oder der Kundenbetreuung anzuschauen. Nehmen wir einfach die E-Mails der vergangenen 3 Monate und clustern die Fragen der Kunden. Schnell werden wir feststellen, dass sich einige Fragen dahingehend häufen, dass die gleichen Themen adressiert oder angefragt werden.

Reichen die vorhandenen Daten nicht aus, so macht es durchaus Sinn, die Telefon-Hotline eine gewisse Zeit zu protokollieren, um zusätzliche Themen oder Themencluster zu erkennen. Mit den so gewonnenen Fragen fangen wir an und ordnen die richtigen Antworten dazu. Ist das erfolgt, haben wir im Grunde schon den „fachlichen“ Teil des Chatbots erledigt. Wir haben die Intents, also die grundlegenden Absichten, erkannt, und auch schon beantwortet.

Darauf folgt der technische Teil – der im Grunde genauso einfach ist. Damit die Nutzer mit der „Automatik“ kommunizieren können, ist eine Eingabe-Interface nötig. Sprich, wir brauchen etwas, damit der Nutzer seine Frage auch stellen und an das Unternehmen senden kann. Ebenso muss die Antwort an den fragenden Menschen wieder zurück übermittelt werden können. Da es jetzt sein kann, dass unterschiedliche Nutzer auch über unterschiedliche Kanäle mit dem Unternehmen kommunizieren wollen, wäre es sinnvoll, verschiedene Wege anzubieten, jedoch ohne unsere Fragen und Antworten immer kopieren zu müssen. Wir brauchen demnach eine Art Hub, Gateway oder Verteiler bzw. Kanalisierung.

Wie bereits schon an anderer Stelle geschrieben, entspricht das Arbeitsprinzip der Chatbots im Grunde einer Auswertung der Anfrage auf Keywordbasis bzw. einer semantischen Analyse der Eingabe mit dem Ziel, die Absicht, den Intent, des Nutzers zu erkennen. Diese Logik können wir jetzt selber programmieren, was etwas Kenntnis in Sprachwissenschaft oder Natural Language Processing und Co voraussetzt, oder wir nutzen eine der offen verfügbaren Plattformen.

Ich habe mich für api.ai als NLP (Natural Language Processor) und Eingabe- sowie Ausgabeschnittstelle entschieden. Über api.ai ist es relativ einfach, Intents zu formulieren. Das sind die im ersten Schritt fachlich zusammengetragenen Fragen bzw. die dahinterliegenden Absichten. Gleichzeitig bietet die Plattform zahlreiche Integrationen in unterschiedliche Kanäle wie Google Assistent, den Messenger #Slack, Facebook Messenger oder ein eigenes Web-Interface an. Darüber hinaus können wir an api.ai ein sogenanntes „Fulfilment“ über einen Webhook definieren. Der Webhook kann genutzt werden, um einen unternehmensinternen Microservice anzusprechen, welcher auf den Intent reagieren kann.

Um das ganze etwas plastischer zu beschreiben, habe ich mir einen nahezu echten, wenngleich leider auch komplizierten, Anwendungsfall überlegt und prototypisch implementiert. Folgende Situation eines Nutzers ist dafür die Ausgangslage: „Es ist Sonntag, Anfang März, die Steuererklärung ist zu erstellen und ich vermisse die letzten beiden Rechnungen des Unternehmens. Die Webseite hat keinen eigenen Customer-Care Bereich, in den ich mich einloggen könnte, die telefonische Erreichbarkeit ist am Wochenende gleich null.“

Was also tun?

Chatbot-Systematik als Grundlage für Sprachassistenten

Ich starten meinen Google-Sprachassistenten und frage ihn nach meinen letzten Rechnungen des Unternehmens. Google erkennt, dass ich einen Skill innerhalb des Sprachassistenten benötige und startet automatisch den Skill des Unternehmens und damit den Chatbot. Ab jetzt werden alle meine Eingaben in den Google-Sprachassistenten direkt an den Skill des Unternehmens weitergeleitet. Ich frage also nach meinen letzten Rechnungen. Problem an der Stelle ist, dass der Skill nicht weiß, wer ich bin und ob ich berechtigt bin, irgendwelche Rechnungen zu erhalten. Also fragt mich der Chatbot / Skill nach meinen persönlichen Daten, die zur Authentifizierung nötig sind. Welche Parameter dies sind, wurde vorher konfiguriert. Und jetzt kam die Stelle, an der ich die Komplexität etwas unterschätzt hatte: Das Einsammeln meiner persönlichen Daten ist per Intent-Steuerung über api.ai noch relativ einfach abbildbar, die Logik des NLP-Prozessors sieht vor, so lange nach den richtigen (vordefinierten) Variablen und Parametern zu fragen, bis alle „eingesammelt“ sind.

Nur woher weiß api.ai, ob die Daten richtig sind?

Eine Anbindung an das Unternehmen ist zwingend nötig, da nur das Unternehmen prüfen kann, ob die über den Sprachassistenten eingegebenen Kundendaten korrekt sind. Sicherlich, man könnte diese Daten auch für alle Kunden im Gateway, also api.ai, hinterlegen, nur ist der Pflegeaufwand bei Änderungen oder neuen Kunden nicht realisierbar. Datenschutz und Sicherheit mal außen vor gelassen.

Folglich muss ein Webservice erstellt und api.ai so konfiguriert werden, dass die gesammelten Daten des Kunden an diesen Webservice weitergeleitet werden. Dieser prüft dann gegen interne Systeme, ob die eingegebenen Daten valide sind. Nach Prüfung der Identität muss das von dem Webservice ermittelte Ergebnis wieder an den Nutzer übertragen werden, auch wieder durch das Gateway hindurch.

Nach zahlreichen Versuchen hatte ich es dann endlich geschafft, einen funktionierenden und zwingend über https erreichbaren Webservice zu erstellen, der die im JSON-Format übertragene POST-Anfrage des api.ai-Gateways versteht und im korrekt strukturierten JSON-Format antwortet.

Dabei fiel auf, dass das Rendering, also die Ausspielung und Darstellung von Inhalten an den Nutzer, durch den Kanal an sich erfolgt. Sprich, eine Anfrage über #Slack hat das gleiche Format wie eine Anfrage über den Google-Sprachassistenten (beides wird durch das Gateway kanalisiert), die Antwort des Webservices allerdings kann sich unterscheiden. Das Gateway erwartet vom Webservice zwar immer nur Daten, jedoch können diese neben der Text und Text-to-Speech-Angabe weitere kanalspezifische Interaktionsflächen beinhalten. So kann beispielsweise mit übermittelt werden, ob ein Button oder eine Liste mit Optionen im jeweiligen Nutzer-Kanal angezeigt werden soll. Diese Angaben erfolgen ebenfalls in der JSON-Response an api.ai – das Rendering der Buttons, Listen oder Bilder jedoch wird durch den jeweiligen Kanal selbst nativ übernommen.

Zusammengefasst hat das Gateway und die inkludierte NLP folgende Aufgaben:

  • Erfassen der Nutzereingaben (Text oder über den Sprachasssistenten),
  • Erkennen des Intents durch semantische Analyse der Eingabe,
  • Abfragen aller notwendigen Parameter für einen Intent und
  • Das Routen von Anfragen und Antworten zwischen Nutzer und unternehmenseigenen Backend-Systemen, einem Webservice und ggf. angeschlossenen Endnutzer-Kanälen

Was das Gateway nicht kann und auch in einer Alexa nicht per-se vorhanden ist, ist die Bearbeitung logischer Abhängigkeiten. Das Abbilden von Verzweigungen (Wenn-Dann) ist zwar innerhalb der Intent-Konfiguration rudimentär möglich, die Nutzung dynamischer, also erst zur Laufzeit bekannter Werte und Antworten, ist nicht ohne einen Webservice möglich.

Und hier schließt sich der Kreis zur Umfrage der Bitkom

Wenn wir mit Chatbots und Assistenten konfrontiert werden, die überwiegend durch vorgedachte Fragen und Antworten konfiguriert sind, dann stellen wir mit Recht die Sinnhaftigkeit, Zuverlässigkeit und Richtigkeit der Antworten der Bots in Frage. Wenn die Antworten von Chatbots und Assistenten nur im Rahmen der menschlich vorgedachten Parameter und Möglichkeiten bleiben, auch dann ist die Sinnhaftigkeit der Automatismen fraglich.

Wenn jedoch Unternehmen nicht nur einen, sondern möglicherweise zwei Schritte weitergehen, und neben (zwingend notwendigen) Webservices für kundenzentrierte Antworten auch noch künstliche Intelligenz als Unterstützung einsetzen, dann haben Sprachassistenten eine glorreiche Zukunft vor sich. Plattformen wie api.ai bieten eine gute Gateway-Funktion, jedoch nur, um die Backend-Logiken nicht pro User-Kanal entwickeln zu müssen. Künstliche Intelligenz an sich ist jedoch auch nicht das Allheilmittel, denn egal, wie wir es bezeichnen, ob AI, KI oder „Machine Learning“, jedes System wird den Schritten folgen:

  • Grundlagen schaffen (das wären unsere manuell erstellten Frage- und Intent-Cluster)
  • Kommunikationsdaten erfassen (damit ist eine Echt-Kunden-Kommunikation gemeint)
  • Training und Lernen

Gerade der dritte Prunkt, das Training, wird oft entweder unterschätzt oder mit dem AI-Argument erschlagen. Nur leider ist das in der echten Welt nicht sinnvoll. Eine künstliche Intelligenz ist auch nur so gut wie ihr Training. Das bedeutet, für die Erstellung z. Bsp. eines Customer-Care-Bots, ist es zwar wichtig, eine Art Grundlage zu schaffen, um nicht bei jeder Frage mit dem obligatorischen „Ich habe Dich leider nicht verstanden“ zu antworten, nur wirklich gut kann die Intent-Erkennung nur funktionieren, wenn die NLP-Logik lange und mit vielen (echten) Daten trainiert wird.

Gerne unterstützen wir Sie bei der Erschaffung einer Chat-Automatisierung, bei der Erstellung von Intents und deren Parametrisierung sowie bei der Anbindung an Backend-Systeme und Integration in externe Chats oder Messenger – damit Ihr Bot nicht zu denen gehört, die weder Mehrwert noch Sinn stiften.

Alexander Käppler

digital expert
+49 711 2992-0
digital-solutions@diconium.com