Benutzer, die mit intelligenten Sprachassistenten gesprochen haben, erwarten Informationen von Chat-Bots. Wenn Sie einen Bot für Unternehmen entwickeln, sind die Erwartungen sogar noch höher: Der Kunde möchte, dass der Benutzer dem gewünschten, vorgegebenen Szenario folgt, und der Benutzer möchte, dass der Roboter die gestellten Fragen intelligent und vorzugsweise menschlich beantwortet, bei der Lösung von Problemen hilft und manchmal nur Smalltalk unterstützt.
Wir führen englischsprachige Chat-Bots durch, die über verschiedene Kanäle mit Benutzern kommunizieren - Facebook Messenger, SMS, Amazon Alexa und das Internet. Unsere Bots ersetzen Support-Services, Versicherungsagenten und können einfach chatten. Jede dieser Aufgaben erfordert einen eigenen Entwicklungsansatz.
In diesem Artikel erfahren Sie, aus welchen Modulen unser Service besteht, wie die einzelnen Module hergestellt werden, welchen Ansatz wir gewählt haben und warum. Wir werden unsere Erfahrungen bei der Analyse verschiedener Tools teilen: Wenn generative neuronale Netze nicht die beste Wahl sind, warum verwenden wir anstelle von Doc2vec Word2vec, was ist der Reiz und das Entsetzen von ChatScript und so weiter?
Auf den ersten Blick scheint es, dass die Probleme, die wir lösen, eher trivial sind. Auf dem Gebiet der Verarbeitung natürlicher Sprache gibt es jedoch eine Reihe von Schwierigkeiten, die sowohl mit der technischen Umsetzung als auch mit dem menschlichen Faktor verbunden sind.
- Eine Milliarde Menschen sprechen Englisch, und jeder Muttersprachler verwendet es auf seine Weise: Es gibt verschiedene Dialekte und individuelle Sprachmerkmale.
- Viele Wörter, Phrasen und Ausdrücke sind mehrdeutig: Ein typisches Beispiel ist in diesem Bild.
- Die korrekte Interpretation der Bedeutung von Wörtern erfordert Kontext. Der Bot, der dem Kunden Fragen zur Klärung stellt, sieht jedoch nicht so cool aus wie derjenige, der auf Anfrage des Benutzers zu einem beliebigen Thema wechseln und jede Frage beantworten kann.
- Oft vernachlässigen Menschen in lebendiger Sprache und Korrespondenz entweder die Regeln der Grammatik oder antworten so kurz, dass es fast unmöglich ist, die Satzstruktur wiederherzustellen.
- Manchmal ist es zur Beantwortung der Frage eines Benutzers erforderlich, seine Anfrage mit den FAQ-Texten zu vergleichen. Gleichzeitig müssen Sie sicherstellen, dass der in den FAQ gefundene Text tatsächlich die Antwort ist und nicht nur mehrere Wörter enthält, die der Anfrage entsprechen.
Dies sind nur einige der offensichtlichsten Aspekte, und es gibt Slang, Jargon, Humor, Sarkasmus, Rechtschreib- und Aussprachefehler, Abkürzungen und andere Probleme, die es schwierig machen, in diesem Bereich zu arbeiten.
Um diese Probleme zu lösen, haben wir einen Bot entwickelt, der eine Reihe von Ansätzen verwendet. Der KI-Teil unseres Systems besteht aus einem Dialogmanager, einem Erkennungsdienst und wichtigen komplexen Mikrodiensten, die bestimmte Probleme lösen: Intent Classifier, FAQ-Dienst, Small Talk.
Starten Sie ein Gespräch. Dialogmanager
Die Aufgabe von Dialog Manager im Bot ist eine Softwaresimulation der Kommunikation mit einem Live-Agenten: Sie sollte den Benutzer durch ein Konversationsszenario zu einem nützlichen Ziel führen.
Um dies zu tun, müssen Sie zum einen herausfinden, was der Benutzer möchte (z. B. die Versicherungskosten für Autos berechnen), und zum anderen die erforderlichen Informationen (Adresse und andere Benutzerdaten, Daten zu Fahrern und Autos) herausfinden. Danach sollte der Dienst eine nützliche Antwort geben - füllen Sie das Formular aus und geben Sie dem Kunden das Ergebnis dieser Daten. Gleichzeitig sollten wir den Benutzer nicht fragen, was er bereits angegeben hat.
Mit Dialog Manager können Sie ein solches Szenario erstellen: Beschreiben Sie es programmgesteuert, erstellen Sie es aus kleinen Bausteinen - spezifischen Problemen oder Aktionen, die an einem bestimmten Punkt auftreten sollten. Tatsächlich ist das Szenario ein gerichteter Graph, bei dem jeder Knoten eine Nachricht, eine Frage, eine Aktion ist und die Kante die Reihenfolge und die Bedingungen des Übergangs zwischen diesen Knoten bestimmt, wenn es eine Mehrfachauswahl des Übergangs von einem Knoten zu einem anderen gibt.
Die Haupttypen von Knoten
- Knoten, die warten, bis sie die Warteschlange erreichen und in den Nachrichten angezeigt werden.
- Knoten, die darauf warten, dass der Benutzer eine bestimmte Absicht zeigt (schreiben Sie beispielsweise: „Ich möchte eine Versicherung abschließen“).
- Knoten, die darauf warten, dass Daten vom Benutzer validiert und gespeichert werden.
- Knoten zur Implementierung verschiedener algorithmischer Designs (Schleifen, Verzweigungen usw.).
Wenn der Knoten geschlossen ist, wird die Steuerung nicht mehr auf ihn übertragen, und der Benutzer sieht die bereits gestellte Frage nicht. Wenn wir also eine Tiefensuche in einem solchen Diagramm zum ersten offenen Knoten durchführen, erhalten wir eine Frage, die dem Benutzer zu einem bestimmten Zeitpunkt gestellt werden muss. Bei der Beantwortung der vom Dialog-Manager generierten Fragen schließt der Benutzer nach und nach alle Knoten im Diagramm, und es wird davon ausgegangen, dass er das vorgeschriebene Skript ausgeführt hat. Anschließend geben wir dem Benutzer beispielsweise eine Beschreibung der Versicherungsoptionen, die wir anbieten können.
"Ich habe schon alles gesagt!"
Angenommen, wir fragen den Benutzer nach einem Namen und in einer Nachricht gibt er auch sein Geburtsdatum, seinen Namen, sein Geschlecht, seinen Familienstand, seine Adresse oder ein Foto seines Führerscheins an. Das System extrahiert alle relevanten Daten und schließt die entsprechenden Knoten, dh es werden keine Fragen mehr zum Geburtsdatum und Geschlecht gestellt.
"Übrigens ..."
Dialog Manager bietet auch die Möglichkeit, gleichzeitig zu mehreren Themen zu kommunizieren. Ein Benutzer sagt beispielsweise: "Ich möchte eine Versicherung abschließen." Ohne diesen Dialog zu beenden, fügt er hinzu: „Ich möchte eine Zahlung für eine zuvor angehängte Police leisten.“ In solchen Fällen speichert Dialog Manager den Kontext des ersten Themas und bietet nach Abschluss des zweiten Skripts an, den vorherigen Dialog an der Stelle fortzusetzen, an der er unterbrochen wurde.
Es ist möglich, zu Fragen zurückzukehren, die der Benutzer bereits beantwortet hat. Zu diesem Zweck speichert das System den Schnappschuss des Diagramms beim Empfang jeder Nachricht vom Client.
Welche Möglichkeiten gibt es?
Zusätzlich zu unserem haben wir einen anderen KI-Ansatz für die Implementierung des Dialogmanagers in Betracht gezogen: Die Absicht und die Parameter des Benutzers werden in die Eingabe des neuronalen Netzwerks eingespeist, und das System selbst generiert die entsprechenden Zustände, die nächste Frage, die gestellt werden muss. In der Praxis erfordert diese Methode jedoch die Hinzufügung eines regelbasierten Ansatzes. Vielleicht eignet sich diese Implementierungsoption für triviale Szenarien - zum Beispiel für die Bestellung von Lebensmitteln, bei denen Sie nur drei Parameter benötigen: Was der Benutzer bestellen möchte, wann er die Bestellung erhalten möchte und wohin er sie bringen soll. Bei komplexen Szenarien wie in unserem Fachgebiet ist dies jedoch immer noch nicht erreichbar. Derzeit können maschinelle Lerntechnologien den Benutzer in einem komplexen Szenario nicht qualitativ zum Ziel führen.
Dialog Manager ist in Python, Tornado Framework, geschrieben, da unser KI-Teil ursprünglich als einzelner Dienst geschrieben wurde. Es wurde eine Sprache gewählt, in der all dies realisiert werden kann, ohne Ressourcen für die Kommunikation aufzuwenden.
"Lass uns entscheiden." Anerkennungsdienst
Unser Produkt kann über verschiedene Kanäle kommunizieren, der KI-Teil ist jedoch vollständig kundenunabhängig: Diese Kommunikation erfolgt nur in Form von Proxy-Text. Der Dialogmanager überträgt den Kontext, die Benutzerantwort und die gesammelten Daten an den Erkennungsdienst, der dafür verantwortlich ist, die Absicht des Benutzers zu erkennen und die erforderlichen Daten abzurufen.
Heute besteht der Erkennungsdienst aus zwei logischen Teilen: dem Erkennungsmanager, der die Erkennungspipeline verwaltet, und Extraktoren.
Erkennungsmanager
Der Erkennungsmanager ist für alle grundlegenden Phasen des Erkennens der Bedeutung von Sprache verantwortlich: Tokenisierung, Lemmatisierung usw. Er bestimmt auch die Reihenfolge der Extraktoren (Objekte, die Entitäten und Attribute in Texten erkennen), nach denen eine Nachricht übersprungen wird, und entscheidet, wann die Erkennung und Rückkehr beendet werden soll fertiges Ergebnis. Auf diese Weise können Sie nur die erforderlichen Extraktoren in der am meisten erwarteten Reihenfolge ausführen.
Wenn wir nach dem Namen des Benutzers gefragt haben, ist es logisch, zunächst zu überprüfen, ob der Name in der Antwort enthalten ist. Der Name ist gekommen und es gibt keinen nützlichen Text mehr - was bedeutet, dass die Erkennung in diesem Schritt abgeschlossen werden kann. Einige andere nützliche Einheiten sind hinzugekommen, was bedeutet, dass die Anerkennung fortgesetzt werden muss. Höchstwahrscheinlich hat die Person einige andere personenbezogene Daten hinzugefügt. Dementsprechend müssen Sie den Extraktor für die Verarbeitung personenbezogener Daten ausführen.
Je nach Kontext kann die Startreihenfolge der Extraktoren variieren. Dieser Ansatz ermöglicht es uns, die Belastung des gesamten Dienstes erheblich zu reduzieren.
Extraktoren
Wie oben erwähnt, können Extraktoren bestimmte Entitäten und Attribute in Texten erkennen. Beispielsweise erkennt ein Extraktor Telefonnummern. ein anderer bestimmt, ob eine Person eine Frage positiv oder negativ beantwortet hat; der dritte - erkennt und überprüft die Adresse in der Nachricht; Das vierte sind Daten über das Fahrzeug des Benutzers. Weiterleiten einer Nachricht durch eine Reihe von Extraktoren - Dies ist der Prozess zum Erkennen unserer eingehenden Nachrichten.
Für den optimalen Betrieb eines komplexen Systems müssen Ansätze kombiniert werden. Bei der Arbeit an Extraktoren haben wir uns an dieses Prinzip gehalten. Ich werde einige der Arbeitsprinzipien hervorheben, die wir in Extraktoren verwendet haben.
Verwenden unserer Microservices mit maschinellem Lernen (Extraktoren senden eine Nachricht an diesen Service, ergänzen sie manchmal mit den vorhandenen Informationen und geben das Ergebnis zurück).
- Verwenden von POS-Tagging, syntaktischem Parsen, semantischem Parsen (z. B. Bestimmen der Absicht des Benutzers durch das Verb)
- Verwenden der Volltextsuche (kann verwendet werden, um Marke und Modell der Maschine in Nachrichten zu finden)
- Verwenden von regulären Ausdrücken und Antwortmustern
- Verwendung von APIs von Drittanbietern (z. B. Google Maps API, SmartyStreets usw.)
- Eine wörtliche Suche nach Sätzen (wenn eine Person kurz mit „Ja“ geantwortet hat, macht es keinen Sinn, sie durch ML-Algorithmen zu führen, um nach Absichten zu suchen)
- Wir verwenden auch vorgefertigte Lösungen zur Verarbeitung natürlicher Sprache in Extraktoren.
Welche Möglichkeiten gibt es?
Wir haben uns die Bibliotheken NLTK, Stanford CoreNLP und SpaCy angesehen. NLTK wird in Google SERPs zuerst gelöscht, wenn Sie eine NLP-Überprüfung starten. Es ist sehr cool für Prototyping-Lösungen, hat umfangreiche Funktionen und ist recht einfach. Aber seine Leistung ist schlecht.
Stanford CoreNLP hat ein schwerwiegendes Minus: Es zieht eine virtuelle Java-Maschine mit sehr großen Modulen, integrierten Bibliotheken und verbraucht viele Ressourcen. Darüber hinaus ist die Ausgabe dieser Bibliothek schwer anzupassen.
Aus diesem Grund haben wir uns für SpaCy entschieden, da es über genügend Funktionen verfügt und das optimale Verhältnis von Helligkeit und Geschwindigkeit aufweist. Die SpaCy-Bibliothek läuft Dutzende Male schneller als NLTK und bietet viel bessere Wörterbücher. Es ist jedoch viel einfacher als Stanford CoreNLP.
Im Moment verwenden wir spaCy für die Tokenisierung, Vektorisierung von Nachrichten (unter Verwendung des eingebauten trainierten neuronalen Netzwerks) und die primäre Erkennung von Parametern aus dem Text. Da die Bibliothek nur 5% unseres Erkennungsbedarfs abdeckt, mussten wir viele Funktionen hinzufügen.
"Früher war es ..."
Der Anerkennungsdienst war nicht immer eine zweiteilige Struktur. Die erste Version war die trivialste: Wir wechselten uns mit verschiedenen Extraktoren ab und versuchten zu verstehen, ob der Text Parameter oder Absichten enthielt. Die KI roch dort nicht einmal - es war ein vollständig regelbasierter Ansatz. Die Schwierigkeit bestand darin, dass dieselbe Absicht auf vielfältige Weise zum Ausdruck gebracht werden kann, von denen jede in den Regeln beschrieben werden muss. In diesem Fall muss der Kontext berücksichtigt werden, da dieselbe Benutzerphrase je nach gestellter Frage möglicherweise unterschiedliche Aktionen erfordert. Zum Beispiel aus dem Dialog: "Bist du verheiratet?" - „Bereits zwei Jahre“ können Sie verstehen, dass der Benutzer verheiratet ist (boolesche Bedeutung). Und aus dem Dialog "Wie lange fahren Sie dieses Auto?" - "Bereits zwei Jahre" müssen Sie den Wert "2 Jahre" extrahieren.
Von Anfang an haben wir verstanden, dass die Unterstützung regelbasierter Lösungen viel Aufwand erfordern würde, und wenn die Anzahl der unterstützten Absichten zunimmt, wird die Anzahl der Regeln viel schneller zunehmen als bei einem ML-basierten System. Allerdings aus geschäftlicher Sicht. Wir mussten MVP ausführen, ein regelbasierter Ansatz ermöglichte es uns, dies schnell zu tun. Deshalb haben wir es benutzt und parallel am ML-Modell der Erkennung von Absichten gearbeitet. Sobald es erschien und zufriedenstellende Ergebnisse lieferte, wandten sie sich allmählich vom regelbasierten Ansatz ab.
Für die meisten Fälle der Informationsextraktion haben wir ChatScript verwendet. Diese Technologie bietet eine eigene deklarative Sprache, mit der Sie Vorlagen zum Extrahieren von Daten aus einer natürlichen Sprache schreiben können. Dank WordNet ist diese Lösung unter der Haube sehr leistungsfähig (Sie können beispielsweise eine „Farbe“ in der Erkennungsvorlage angeben, und WordNet erkennt jedes Verengungskonzept, z. B. „Rot“). Wir haben damals keine Analoga gesehen. Aber ChatScript ist sehr schief und fehlerhaft geschrieben, mit seiner Verwendung ist es fast unmöglich, komplexe Logik zu implementieren.
Am Ende wurden die Nachteile aufgewogen, und wir haben ChatScript zugunsten von NLP-Bibliotheken in Python aufgegeben.
In der ersten Version von Recognition Service haben wir die Obergrenze für Flexibilität erreicht. Die Einführung jeder neuen Funktion hat das gesamte System erheblich verlangsamt.
Aus diesem Grund haben wir beschlossen, den Erkennungsdienst vollständig neu zu schreiben und ihn in zwei logische Teile zu unterteilen: kleine, leichte Extraktoren und den Erkennungsmanager, der den Prozess verwaltet.
"Was willst du?". Intent Classifier
Damit der Bot angemessen kommunizieren kann - um die erforderlichen Informationen auf Anfrage bereitzustellen und die Daten des Benutzers aufzuzeichnen - ist es erforderlich, die Absicht (Absicht) des Benutzers anhand des an ihn gesendeten Textes zu bestimmen. Die Liste der Absichten, mit denen wir mit Benutzern interagieren können, ist durch die Geschäftsaufgaben des Kunden begrenzt: Es kann die Absicht sein, die Versicherungsbedingungen herauszufinden, Informationen über sich selbst auszufüllen, eine Antwort auf eine häufig gestellte Frage zu erhalten usw.
Es gibt viele Ansätze zur Klassifizierung von Absichten basierend auf neuronalen Netzen, insbesondere auf wiederkehrenden LSTM / GRU. Sie haben sich in jüngsten Studien bewährt, haben jedoch einen gemeinsamen Nachteil: Für einen ordnungsgemäßen Betrieb ist eine sehr große Probe erforderlich. Bei einer kleinen Datenmenge sind solche neuronalen Netze entweder schwer zu trainieren oder führen zu unbefriedigenden Ergebnissen. Gleiches gilt für das Fast Text-Framework von Facebook (wir haben es überprüft, da es sich um eine hochmoderne Lösung für die Verarbeitung kurzer und mittlerer Phrasen handelt).
Unsere Schulungsbeispiele sind von sehr hoher Qualität: Die Datensätze bestehen aus einem Vollzeit-Team von Linguisten, die Englisch beherrschen und die Besonderheiten des Versicherungsbereichs kennen. Unsere Stichproben sind jedoch relativ klein. Wir haben versucht, sie mit öffentlichen Datensätzen zu verdünnen, aber diese stimmten mit seltenen Ausnahmen nicht mit unseren Angaben überein. Wir haben auch versucht, Freiberufler mit Amazon Mechanical Turk zu gewinnen, aber diese Methode erwies sich auch als nicht funktionsfähig: Die von ihnen gesendeten Daten waren teilweise von schlechter Qualität, die Proben mussten doppelt überprüft werden.
Daher suchten wir nach einer Lösung, die an einer kleinen Stichprobe funktioniert. Die gute Qualität der Datenverarbeitung wurde durch den Random Forest-Klassifikator demonstriert, der auf Daten trainiert wurde, die in die Vektoren unseres Bag-of-Word-Modells konvertiert wurden. Mithilfe der Kreuzvalidierung haben wir die optimalen Parameter ausgewählt. Zu den Vorteilen unseres Modells zählen Geschwindigkeit und Größe sowie die relativ einfache Bereitstellung und Umschulung.
Bei der Arbeit am Intent Classifier wurde deutlich, dass seine Verwendung für einige Aufgaben nicht optimal ist. Angenommen, ein Benutzer möchte den in der Versicherung angegebenen Namen oder die Fahrzeugnummer ändern. Damit der Klassifizierer diese Absicht korrekt bestimmen kann, müssten alle in diesem Fall verwendeten Vorlagenphrasen manuell zum Datensatz hinzugefügt werden. Wir haben einen anderen Weg gefunden: einen kleinen Extraktor für den Erkennungsdienst zu erstellen, der die Absicht anhand von Schlüsselwörtern und NLP-Methoden bestimmt, und Intent Classifier für nicht standardmäßige Phrasen zu verwenden, bei denen die Methode mit Schlüsselwörtern nicht funktioniert.
"Sie fragen immer danach." FAQ
Viele unserer Kunden haben FAQ-Bereiche. Damit der Benutzer solche Antworten direkt vom Chatbot erhalten konnte, musste eine Lösung bereitgestellt werden, die a) die FAQ-Anfrage erkennt; b) würde die relevanteste Antwort in unserer Datenbank finden und herausgeben.
Es gibt eine Reihe von Modellen, die auf dem Stanford SQUAD-Datensatz trainiert wurden. Sie funktionieren gut, wenn der Antworttext aus den FAQ die Wörter aus der Frage des Benutzers enthält. Nehmen wir an, die FAQ sagt: "Frodo sagte, er würde den Ring nach Mordor bringen, obwohl er den Weg dorthin nicht kannte." Wenn der Benutzer fragt: "Wohin wird Frodo den Ring bringen?", Antwortet das System: "An Mordor."
Unser Szenario war in der Regel anders. Zum Beispiel für zwei ähnliche Anfragen: "Kann ich bezahlen?" und "Kann ich online bezahlen?" Der Bot muss anders reagieren: Bieten Sie im ersten Fall einer Person eine Zahlungsmethode an, im zweiten Fall - ja, Sie können online bezahlen, hier ist die Adresse der Seite.
Eine weitere Klasse von Lösungen zur Beurteilung der Ähnlichkeit von Dokumenten konzentriert sich auf lange Antworten - zumindest einige Sätze, darunter Informationen, die für den Benutzer von Interesse sind. Leider funktionieren Fälle mit kurzen Fragen und Antworten („Wie bezahle ich online?“ - „Sie können mit PayPal bezahlen“) sehr instabil.
Eine andere Lösung ist der Doc2vec-Ansatz: Der große Text wird zu einer Vektordarstellung destilliert, die dann mit anderen Dokumenten in derselben Form verglichen wird und der Ähnlichkeitskoeffizient ermittelt wird. Dieser Ansatz musste ebenfalls gestrichen werden: Er konzentriert sich auf lange Texte, aber wir beschäftigen uns hauptsächlich mit Fragen und Antworten aus einem oder zwei Sätzen.
Unsere Entscheidung basierte auf zwei Schritten. Erstens: Mithilfe von Einbettungen haben wir jedes Wort in einem Satz mithilfe des Google Word2vec-Modells in Vektoren übersetzt.
Danach haben wir den Durchschnittsvektor für alle Wörter betrachtet, der einen Satz in Form eines Vektors darstellt. Im zweiten Schritt nahmen wir den Vektor der Frage und fanden in der FAQ-Datenbank, gespeichert in derselben Vektorform, die bis zu einem gewissen Grad nächstgelegene Antwort, in unserem Fall den Kosinus.Zu den Vorteilen gehören eine einfache Implementierung, eine sehr einfache Erweiterbarkeit und eine relativ einfache Interpretierbarkeit. Die Nachteile sind eine schwache Optimierungsmöglichkeit: Dieses Modell ist schwer zu ändern - es funktioniert entweder in den meisten Benutzerfällen gut oder Sie müssen es aufgeben."Und reden?" Smalltalk
Manchmal schreibt der Benutzer etwas völlig irrelevantes, zum Beispiel: "Das Wetter ist heute gut." Dies ist nicht in der Liste der Absichten enthalten, die uns interessieren, aber wir möchten dennoch sinnvoll antworten und die Intelligenz unseres Systems demonstrieren.Für solche Entscheidungen wird eine Kombination der oben beschriebenen Ansätze verwendet: Sie basieren entweder auf sehr einfachen regelbasierten Lösungen oder auf generativen neuronalen Netzen. Wir wollten frühzeitig einen Prototyp bekommen, deshalb haben wir einen öffentlichen Datensatz aus dem Internet genommen und einen Ansatz verwendet, der dem für die FAQ verwendeten sehr ähnlich ist. Zum Beispiel hat ein Benutzer etwas über das Wetter geschrieben - und mithilfe eines Algorithmus, der Vektordarstellungen von zwei Sätzen mit einem bestimmten Kosinusmaß vergleicht, suchen wir im öffentlichen Datensatz nach einem Satz, der dem Wetterthema so nahe wie möglich kommt.Schulung
Jetzt haben wir nicht das Ziel, einen Bot zu erstellen, der für jede von Kunden empfangene Nachricht geschult wird: Erstens ist dies, wie die Erfahrung zeigt, der Weg zum Tod des Bots (denken Sie daran, wie IBM Watson die Basis löschen musste, weil die Diagnose mit einer Matte begann und Microsofts Twitter-Bot hat es geschafft, innerhalb eines Tages zum Rassisten zu werden . Zweitens bemühen wir uns, die Aufgaben der Versicherungsunternehmen so qualitativ wie möglich zu schließen. Ein selbstlernender Bot ist nicht unsere Geschäftsaufgabe. Wir haben eine Reihe von Tools für Linguisten und QS-Befehle geschrieben, mit denen sie Bots manuell neu trainieren können, indem sie Dialoge und Korrespondenz mit Benutzern während der Nachmoderation untersuchen.Trotzdem scheint unser Bot bereits bereit zu sein, den Turing-Test zu bestehen. Einige Benutzer beginnen ein ernstes Gespräch mit ihm und glauben, dass sie mit einem Versicherungsagenten sprechen, und einer drohte sogar dem Chef mit einer Beschwerde, als der Bot ihn missverstand.Pläne
Jetzt arbeiten wir am visuellen Teil: Anzeigen des gesamten Diagramms des Skripts und der Möglichkeit, es über die GUI zu erstellen.Auf der Seite des Erkennungsdienstes führen wir eine sprachliche Analyse ein, um die Bedeutung jedes Wortes in der Nachricht zu erkennen und zu verstehen. Dies verbessert die Genauigkeit der Reaktion und extrahiert zusätzliche Daten. Wenn eine Person beispielsweise eine Autoversicherung ausfüllt und angibt, dass sie ein nicht versichertes Haus hat, kann sich der Bot diese Nachricht merken und an den Betreiber weiterleiten, um den Kunden zu kontaktieren und eine Hausversicherung anzubieten.Ein weiteres Merkmal der Arbeit ist die Rückkopplungsverarbeitung. Nach Abschluss des Dialogs mit dem Bot fragen wir den Benutzer, ob ihm der Service gefallen hat. Wenn die Stimmungsanalyse die Bewertung des Benutzers als positiv erkannt hat, laden wir den Benutzer ein, seine Meinung in sozialen Netzwerken mitzuteilen. Wenn die Analyse zeigt, dass der Benutzer negativ reagiert hat, klärt der Bot, was falsch war, korrigiert die Antwort, sagt: "OK, wir beheben das Problem" und bietet nicht an, die Bewertung im Stream zu teilen.Einer der Schlüssel, um die Kommunikation mit dem Bot so natürlich wie möglich zu gestalten, besteht darin, den Bot modular zu gestalten und das Spektrum der ihm zur Verfügung stehenden Reaktionen zu erweitern. Wir arbeiten daran. Vielleicht war der Benutzer deshalb bereit, unseren Bot aufrichtig für einen Versicherungsagenten zu nehmen. Der nächste Schritt: Stellen Sie sicher, dass die Person versucht, dem Bot zu danken.
. , .