Seit Siri zur Standardfunktion von iOS geworden ist, haben Sprachbefehle und Konversationsschnittstellen eine Art Renaissance erlebt und endlich die Schwelle von technischen Spielereien oder Science Fiction zur tatsächlichen Nutzbarkeit überschritten. Anfangs waren sie kaum mehr als Sprachkommandos, aber schon bald wurden sie vollständig konversationsfähig - d.h. sie konnten natürliche Sprache anstelle von Sprachbefehlen verstehen und Folgefragen stellen.
Schließlich entwickelten sie so etwas wie eine Persönlichkeit, die sie menschlicher erscheinen ließ. Dies geschah zunächst durch das Hinzufügen von selbstbewusst klingenden Antworten, die sich oft auf Asimovs philosophische Arbeit über KI oder Turings Arbeit zur Unterscheidung einer KI von einer echten Person bezogen.
Konversationsschnittstellen sind schon seit Jahrzehnten ein Forschungsgebiet, das bis in die Mitte der 60er Jahre mit textbasierten Schnittstellen und Chatbots zurückreicht. Ein Beispiel für frühe Konversationsschnittstellen ist STUDENT, das 1964 entwickelt wurde, acht Jahre nachdem John McCarthy den Begriff Künstliche Intelligenz geprägt hatte. Ein weiteres Beispiel ist ELIZA, das eine Konversation simulierte, indem es ein Mustervergleichs- und Substitutionsverfahren anwandte. Es verfügte weder über einen eigentlichen Rahmen für die Kontextualisierung von Ereignissen noch über eine Datenbank mit realem Wissen. Ein Skript, das er ausführte, diente als einfache Form der Psychotherapie, indem er dem Benutzer bestimmte Fragen stellte, um ihn dazu zu bringen, sich zu "öffnen", wobei er sich oft auf den vorherigen Satz bezog, den der Benutzer erwähnt hatte. Dies war einer der ersten Bots, die es mit dem Turing-Test aufnehmen konnten.
Die Arbeit an der Verarbeitung natürlicher Sprache und KI wurde im Laufe der Jahrzehnte fortgesetzt. Einer der wichtigsten Meilensteine für die heutigen Konversationsschnittstellen war IBMs Watson, der in natürlicher Sprache gestellte Fragen beantworten kann. Er gewann 2011 das berühmte Spiel Jeopardy.
Die erste Konversationsschnittstelle, die eine breite Akzeptanz fand, war natürlich Apples Siri, die ursprünglich als App für iOS im Februar 2010 entwickelt und nur zwei Monate später von Apple übernommen wurde. Sie verwendet eine Spracherkennungs-Engine, die von Nuance Communications bereitgestellt wird. (Nebenbei bemerkt wurde dieselbe Text-to-Speech-Technologie von einem Kollegen von mir verwendet, als ich für die niederländischen Eisenbahnen arbeitete, und er stellte sie schließlich bei Strangeloop 2012 vor).
Microsoft folgte 2013 mit Cortana, einer persönlichen digitalen Assistentin, die nach der synthetischen Intelligenz in den Halo-Spielen benannt ist. Er wurde 2015 in Windows 10 integriert, nachdem es Microsoft nicht gelungen war, auf dem mobilen Markt Fuß zu fassen. Wenig später führte Amazon Alexa ein, die das Konzept von Siri als persönliche Sprachassistentin aufgriff und zu einer ständigen Haushaltshilfe machte, die ständig auf einen Aktivierungsbefehl wartet.
Schließlich zog Google 2016 mit Google Assistant nach, als Nachfolger oder Ersatz für sein Google Now Angebot. Er basierte (höchstwahrscheinlich) auf der Assistant-App von Speaktoit, die übernommen wurde, kurz bevor Google seinen Assistant und sein Google Home-Angebot einführte.
Speaktoit öffnete 2014 seine Engine zur Verarbeitung natürlicher Sprache für Drittentwickler unter dem Namen API.AI. Die Engine war agnostisch, d.h. sie konnte für die Erstellung von Konversationsschnittstellen für eine Vielzahl von Diensten und Chat-Anwendungen verwendet werden. Im Jahr 2017, etwa ein Jahr nach der Übernahme durch Google, wurde API.AI in Dialogflow umbenannt und das Marketing auf die Entwicklung von Aktionen für den Google Assistant ausgerichtet.
Wir haben in letzter Zeit mit Dialogflow zusammengearbeitet, um unsere Kunden bei der Integration dieser neuen Form der Benutzerinteraktion zu unterstützen. Der größte Teil dieses Beitrags wird sich auf die Erstellung von Dialogschnittstellen mit Dialogflow konzentrieren, aber es gibt auch einige konkurrierende Alternativen, auf die wir später in diesem Beitrag kurz eingehen werden.
Dialogflow
Dialogflow ist das Produkt von Google, mit dem Sie konversationelle, natürlichsprachliche Interaktionen erstellen können. In Kombination mit der Text-to-Speech-Technologie von Google ermöglicht es sowohl sprach- als auch textgesteuerte Schnittstellen. Es kann von einer Vielzahl von Produkten aus bedient werden, von Slack- oder Messenger-Bots bis hin zu Google Home-Smart-Lautsprechern und -Displays, und Sie können sogar Ihren eigenen Assistenten erstellen, indem Sie z.B. einen Raspberry Pi oder Ihre eigenen Apps damit verwenden.
Obwohl sich Dialogflow jetzt hauptsächlich auf den Google Assistant konzentriert, unterstützt es auch Cortana und Alexa, so dass Entwickler ihre Schnittstelle für alle wichtigen Sprachassistenten-Plattformen erstellen können.
Schnittstellen mit Dialogflow erstellen
Am besten folgen Sie der offiziellen Dokumentation und den Tutorials, aber in diesem Abschnitt werden wir versuchen, Ihnen aus der Vogelperspektive zu zeigen, wie Sie mit Dialogflow eine Konversationsschnittstelle - auch als Agent bekannt - erstellen können.
Intentionen
Die Basiseinheit einer Konversationsschnittstelle in Dialogflow wird als Intent bezeichnet. Kurz gesagt ist ein Intent eine Einheit einer Konversation, die durch eine bestimmte Phrase ausgelöst wird, die der Benutzer eingibt. Dabei kann es sich um einen Befehl ("Schalten Sie das Licht im Wohnzimmer ein", "Rufen Sie meine Mutter an", "Spielen Sie Despacito"), eine Frage ("Welche Termine habe ich heute?", "Was ist die Lichtgeschwindigkeit?", "Was ist das erste Gesetz der Robotik?") oder eine Antwort auf eine vom Agenten gestellte Frage ("Blau", "Ja", "Nächsten Samstag") handeln.
Für einen Intent müssen eine Reihe von Trainingsphrasen programmiert werden, d.h. eine Reihe von Wörtern, Phrasen oder Sätzen, die als Auslöser für den Intent dienen, und ein Trainingsset, mit dem der Agent trainiert wird. Der Clou dabei ist, dass der Dialogflow-Agent, wenn Sie ihn mit nur einer Handvoll Trainingsphrasen programmieren, so intelligent wird, dass er Variationen der Phrasen erkennt, um den Intent auszulösen. Der Standard-Willkommens-Intent, der verwendet wird, um ein Gespräch mit dem Bot zu beginnen, ist mit Phrasen wie "hi", "hallo" und "Grüße" programmiert, wird aber auch ausgelöst, wenn Sie "yo" sagen.
Wenn Sie einen Intent programmieren, um eine bestimmte Benutzereingabe zu erhalten - d.h. das, was der Benutzer wünscht oder bereitstellt - verfügt Dialogflow über eine intelligente Methode, diese Eingabe zu erkennen und zu extrahieren. Bei einem Satz wie "Bitte spielen Sie Despacito" löst der gesamte Satz den Intent aus, aber Dialogflow muss das Schlüsselwort - Despacito - extrahieren, damit das Fulfillment den richtigen Song zum Abspielen abrufen kann.
Entitäten
Dieses Schlüsselwort wird in Dialogflow als Entität bezeichnet. Standardmäßig gibt es eine Reihe von eingebauten Entitäten, die so genannten Systementitäten. Dies sind z.B. Zahlen, Daten, Zeiträume, Orte, Genres, Flugnummern, usw. Wenn Sie die Trainingssätze für Ihre Absicht definieren, beginnt Dialogflow automatisch mit der Markierung von Systementitäten, die es bereits kennt. Wenn die Entität nicht automatisch erkannt wird, können Sie auf sie doppelklicken und Dialogflow anweisen, diese Phrase als eine der eingebauten Systementitäten zu interpretieren.
Die Erkennung von Entitäten ist etwas unscharf. Manchmal ist es magisch genug, dass es "Nächsten Sonntag" als (z.B.) 21. Oktober erkennt, aber manchmal scheint es einfach nicht zu funktionieren. Wenn Sie mehr Trainingsphrasen mit nicht erkannten Entitäten hinzufügen und Dialogflow mitteilen, wie diese zu interpretieren sind, hilft das nicht nur kurzfristig bei Ihrem speziellen Agenten, sondern auch langfristig, denn jeder Intent, jede Entität und jede Konversation, die Sie und Ihre Nutzer mit dem Agenten führen, tragen zum Trainingssatz bei, den die Google-Ingenieure zur Verbesserung ihrer Software verwenden können.
Zusätzlich zu den Systementitäten können Sie benutzerdefinierte Entitäten für Argumente definieren, die nicht von den Systementitäten abgedeckt werden, die so genannten Entwicklerentitäten. Beispiele sind z.B. Kleidergrößen, Lebensmittel, Automarken, usw. Standardmäßig haben Entwickler-Entitäten eine strikte Übereinstimmung - d.h. sie entsprechen nur dem Schlüsselwort selbst oder den Synonymen, die Sie explizit definieren. Über ein Kontrollkästchen können Sie Dialogflow jedoch anweisen, die Entitäten automatisch zu erweitern - das in der Dokumentation genannte Beispiel ist das von Lebensmitteln. Geben Sie dem Agenten Wörter wie "Brot", "Butter" und "Milch" ein, und er wird "Gemüse" als passende Entität hinzufügen.
Schließlich können Sie sitzungsspezifische Entitäten erstellen, die nur für die Dauer der aktuellen Konversation gültig sind. Das angegebene Beispiel sind zeitabhängige Buchungsoptionen, obwohl diese wahrscheinlich auch durch Systementitäten für Datum und Uhrzeit behandelt werden könnten.
Kontexte
Standardmäßig "hört" ein Dialogflow-Agent auf alle Intents gleichzeitig und ruft den Intent auf, der den Eingaben des Benutzers am ehesten entspricht. Dies kann jedoch schnell dazu führen, dass der falsche Intent ausgelöst wird, insbesondere wenn der Agent in verschiedenen Phasen des Gesprächs ähnlich klingende Eingaben erwartet (z.B. wenn er nach einem Datum fragt).
Um dieses Problem zu lösen, können Intents mit Kontexten konfiguriert werden, die in Form von Input- und Output-Kontexten vorliegen. Ein Ausgangskontext ist wie ein Flag, das gesetzt wird, wenn ein Intent ausgelöst wurde, ähnlich wie ein aktueller Status. Bei der Definition eines Ausgangskontextes kann der Entwickler ein Ablaufdatum festlegen, das angibt, nach wie vielen Gesprächsschritten der Kontext nicht mehr gültig ist. Ein Beispiel: Sie setzen einen Kontext "Hören auf die Eingabe des Abreisedatums", nachdem ein Intent die Frage "Wann möchten Sie abreisen?" beantwortet hat.
Als Nächstes kann der Handler für einen generischen "Datumsempfang"-Intent sehen, welcher Kontext aktiv ist - Abfahrtsdatum oder Ankunftsdatum. Dies wird dann als Eingabekontext bezeichnet.
Wenn Sie in der Dialogflow-Benutzeroberfläche einen Intent mit einem Eingabekontext konfigurieren, hört der Agent erst dann auf diesen bestimmten Intent, wenn der Eingabekontext auf aktiv gesetzt ist. Das heißt, dass er nicht einmal auf Datumseingaben achtet, bevor nicht einer der beiden Datumseingabekontexte aktiv ist. Dies ist der primäre Ansatz für die Behandlung verschiedener Phasen in einem Gespräch.
Erfüllung
Wenn Sie eine Absicht erstellen, gibt es zwei Optionen für die Bearbeitung: Entweder der Agent antwortet, optional mit den Eingaben des Benutzers, oder Sie implementieren eine vollständig benutzerdefinierte Erfüllung über einen Web-Hook.
Wenn Sie einen Web-Hook konfigurieren, ruft Dialogflow den von Ihnen konfigurierten Web-Hook mit einer HTTP POST-Anfrage auf, die einen JSON-Body enthält. Dieses JSON-Dokument enthält Informationen über die Eingabe, die Kontexte und (zur Erleichterung des Entwicklers) alle extrahierten Entitäten, die auf ein gemeinsames Format normalisiert sind (z.B. ein ISO-Datum für den 21. Oktober, wenn der Benutzer "Nächsten Sonntag" gesagt hat).
Der Webhook ruft das Dokument ab und gibt einen weiteren JSON-Body zurück, der Dialogflow mitteilt, wie es reagieren soll, welche Ausgabekontexte gesetzt werden sollen, welche auswählbaren Optionen dem Benutzer angezeigt werden sollen usw.
Es gibt zwei wichtige Bibliotheken, die die Implementierung von Dialog-Webhooks erleichtern: die Dialogflow Fulfillment-Bibliothek für NodeJS und die Actions on Google-Bibliothek für NodeJS, die der Dialogflow Fulfillment-Bibliothek sehr ähnlich ist, aber zusätzlich Funktionen für Firebase Functions, das Google Actions SDK und Smart Home-Funktionen bietet.
Webhooks sind ideale Anwendungsfälle, um in Lambdas eingesetzt zu werden. Google hebt Firebase Functions hervor, aber diese können genauso gut in Google Cloud Functions, AWS Lambda, Azure Cloud Functions usw. eingesetzt werden. Natürlich kann es auch als normale Anwendung eingesetzt werden. Ein Lambda wird dennoch empfohlen. Bei jedem Aufruf des Webhooks werden alle wichtigen Zustände (falls vorhanden) an die Funktion übergeben, so dass der Hook keinen Zustand behalten muss. Schließlich ermöglichen Lambdas eine nahezu unbegrenzte horizontale Skalierung, so dass Ihr Agent zwischen einer und Millionen von Konversationen gleichzeitig verarbeiten kann.
Apropos Preise: Es gibt zwei Kosten, die Sie im Auge behalten sollten: die Dialogflow-Preise, bei denen die Kosten pro Anfrage, pro 15 Sekunden Audio und pro Minute verarbeiteten Telefonats berechnet werden. Beachten Sie, dass einige dieser Funktionen noch als Beta-Version gekennzeichnet sind. Wenn Sie Ihren eigenen Webhook implementieren, müssen Sie außerdem die Kosten für die Ausführung der Firebase-Funktion oder des Lambdas im Auge behalten. Verschiedene Lambda-Anbieter haben unterschiedliche Preise, vergleichen Sie also die Anbieter je nach Ihren Anforderungen. Außerdem können verschiedene Implementierungen oder Implementierungssprachen unterschiedliche Leistungsmerkmale und damit auch unterschiedliche Lambda-Preise haben.
Persönliche Erfahrungen
Ich habe in den letzten Tagen selbst an einigen Proof of Concepts gearbeitet, um ein Gefühl für konversationelle Schnittstellen zu bekommen. Der Anfang war etwas holprig. Ich bin über Actions bei Google eingestiegen. Wenn Sie diesem Tutorial folgen, gelangen Sie von der Actions-Konsole von Google zur Dialogflow-Konsole und zu Firebase Functions, d.h. zu mindestens drei verschiedenen Diensten, von denen jeder seine eigene Sprache hat, und es ist anfangs etwas einschüchternd, sich damit zurechtzufinden. Wenn Sie in diese Technologie einsteigen möchten, ist es meiner Meinung nach einfacher, die Dialogflow-Dokumentation zu lesen, auch weil dort die wichtigsten Konzepte nach und nach vorgestellt werden.
Die Dialogflow-Benutzeroberfläche sowie der Ablauf zur Erstellung eines Agenten könnten noch etwas überarbeitet werden, um ein reibungsloseres Erlebnis zu ermöglichen. Ich fand es etwas lästig, zwischen Dialogflow für die Verwaltung von Intents, Training Phrases und Entities und zurück zum NodeJS-Webhook zu wechseln, um Antworten zu verarbeiten. Außerdem habe ich nicht herausgefunden, wie ich Dialogflow dazu bringen kann, die Antworten anzuführen. Das heißt, die Antworten und Folgefragen, die der Agent gestellt hat, kamen alle vom Webhook und nicht von der etwas benutzerfreundlicheren Dialogflow-Oberfläche.
Ich glaube, dass die Entwicklung von Konversationsschnittstellen und die spätere Bereitstellung in mehreren Sprachen ein großer Aufwand für mehrere Disziplinen ist. Es wäre ideal, wenn der Text- und Sprachteil, d.h. Fragen, Antworten, Entitäten, Folgefragen, Trainingsphrasen usw. in der Benutzeroberfläche behandelt werden könnten, während die softwarebasierte Handhabung im Code erfolgt. Im Moment ist es eine Mischung aus beidem, die sich wahrscheinlich nicht leicht skalieren lässt.
Oder machen Sie es zu einer vollständigen Entwicklererfahrung, bei der Intentionen, Kontexte, Trainingsphrasen usw. alle im Code behandelt werden.
Die meisten Tutorials und Dokumentationen beziehen sich auf die NodeJS-Schnittstelle, aber Google bietet auch eine Reihe von Dialogflow-Bibliotheken in anderen Programmiersprachen an. Diese scheinen jedoch alle Teil der Google Cloud Client Libraries zu sein, so dass sie möglicherweise etwas unscharf oder schwer zu verwenden sind. Die Node-Bibliotheken sollten für die meisten Anwendungsfälle ausreichen. Falls nicht, sollte es kein allzu großes Problem sein, eine eigene API zu erstellen oder eine von den Cloud Client Libraries abzuzweigen, denn die Webhook rest/json API ist gut dokumentiert und nicht allzu kompliziert.
Ich habe bisher nur Zeit mit Dialogflow und Actions on Google verbracht, aber neben Google gibt es noch eine Reihe anderer großer Anbieter auf dem Markt, von denen jeder für sich bewertet werden sollte.
Alternativen
Es gibt mindestens zwei weitere große Anbieter von Sprachassistenten: Amazon und Microsoft. Die Erstellung eines Cortana-Skills, wie Microsoft ihn nennt, ist eine größere Programmieraufgabe als bei Dialogflow, wo der Entwickler das Bot Framework verwenden kann, um einen Sprachbot in C# oder Javascript zu entwickeln.
Interessanter scheint Amazon Lex zu sein, ein Dienst zur Erstellung von Konversationsschnittstellen, der auf der gleichen Technologie basiert wie Alexa. Einer der Anwendungsfälle, die sie auf ihrer Landing Page hervorheben, ähnelt dem, an dem Google arbeitet, nämlich Call Center Bots. Ich konnte mir Lex noch nicht im Detail ansehen und weiß daher noch nicht, wie die Erfahrungen der Entwickler oder Kunden sind, aber auch Lex könnte ein wichtiger Akteur auf diesem neuen Markt sein.
Die nahe Zukunft
Google Assistant und Dialogflow sind nur der Anfang von Googles Plänen in Bezug auf die Verarbeitung natürlicher Sprache und konversationelle Schnittstellen. Bisher haben wir uns von Sprachbefehlen - mit denen z.B. Siri begonnen hat - zu Konversationsschnittstellen entwickelt. Diese sind natürlicher und ermöglichen eine größere Bandbreite an Funktionen (z.B. Flugbuchungen oder Essensbestellungen), aber sie fühlen sich immer noch so an, als würden Sie mit einem Roboter hin und her sprechen.
Die nächsten Schritte befinden sich bereits in der Beta-Phase und werden zum Beispiel von Google vorgeführt. Eine Technologie, an der sie arbeiten, ist die
Zweitens: Beachten Sie die Verwendung des Wortes Contact Center anstelle von Call Center - wir leben in einem Zeitalter, in dem sich die Menschen nicht nur über ein Call Center, sondern auch über Direct Messaging, Twitter, Textnachrichten usw. an Unternehmen wenden. Mit diesem Tool kann ein Unternehmen einen Agenten einsetzen, der denselben Kundensupport über mehrere Kanäle hinweg leisten kann. Es könnte (aber das ist nur eine Hypothese) sogar die Notwendigkeit beseitigen, dass ein Mensch direkt mit dem Kunden spricht. Stattdessen kann der menschliche Agent seine Arbeit in reinem Text erledigen, während der virtuelle Agent dem Benutzer in Sprache antwortet. Dies wäre wahrscheinlich eine zu große Verzögerung, da die sprachliche Kommunikation in Echtzeit erfolgen muss.
Eine weitere Technologie, an der Google arbeitet, ist der Versuch, die Interaktionen mit einem Gesprächsagenten menschlicher klingen zu lassen. Auf der Google I/O 2018 präsentierte Google Google Duplex, was wie eine fortgeschrittene Version seiner Konversationsschnittstelle aussieht, gemischt mit der nächsten Generation von Text-to-Speech-Engines, die dem gesprochenen Computertext kleine Details hinzufügt, um ihn menschlicher klingen zu lassen, und die Sprache-zu-Text-Verbindung in die andere Richtung verbessert, so dass sie in der Lage ist, umgangssprachliche Sprache von niedriger Qualität (Telefon) besser zu verstehen, anstatt der eher befehls- und eingabeähnlichen Struktur von heute.
[embed]https://www.youtube.com/watch?v=bd1mEm2Fy08[/embed]
Die Kombination von Dialogflow, Contact Center AI und Duplex hat ein enormes Potenzial, innerhalb des nächsten Jahres oder so die Contact Center auf der ganzen Welt zu verändern. Kombiniert mit Googles Übersetzungsdienst wird die internationale Konsolidierung des Kundensupports Realität werden. Microsoft und andere Unternehmen haben Echtzeit-Sprachübersetzungsmaschinen vorgestellt, die es Menschen, die nicht dieselbe Sprache sprechen, ermöglichen, ein Gespräch zu führen. Dies auf den Kundensupport anzuwenden, wird für viele Unternehmen ein großer Schritt sein.
Sind Sie daran interessiert, Ihren eigenen Assistenten zu entwickeln? Xebia bietet einen (kostenlosen!) Google Assistant for Your Business-Workshop zu einem Termin und an einem Ort Ihrer Wahl an. Der Workshop dauert etwa zwei Stunden, und wenn Sie teilnehmen, haben Sie automatisch die Chance, einen kostenlosen Google Home Smart Speaker zu gewinnen.
Wenn Sie mehr darüber erfahren möchten, wie Xebia Ihnen bei der Entwicklung Ihrer Assistenten oder Contact Center-Agenten helfen kann, nehmen Sie Kontakt mit uns auf!
Verfasst von
Freek Wielstra
Unsere Ideen
Weitere Blogs
Contact