Alices B2B-Fähigkeit: Vom Prototyp bis zum ersten gespeicherten Rubel

Vor nicht allzu langer Zeit fand in St. Petersburg die zweite Konversationskonferenz statt, die der Konversations-KI gewidmet war und bei der ich das Glück hatte, als Redner zu sprechen. Das Thema war die Entwicklung eines Prototyps einer B2B-Fähigkeit für ein großes Unternehmen. In dem Bericht wurde beschrieben, wie sie es geschafft haben, sich mit den relativ langsamen Webdiensten und der geschlossenen Infrastruktur des Unternehmens anzufreunden. Dies wird unter dem Schnitt besprochen.

Wenn Sie plötzlich nicht mehr wissen, was Alice kann, schauen Sie unter den Spoiler: Er beschreibt kurz, was was ist.

Idee

Wie hat alles angefangen? Am 13. März 2018 kündigten sie Beta-Tests der Yandex.Dialogs-Plattform an (Alices Fähigkeiten). Zu dieser Zeit waren viele bereits an dem virtuellen Assistenten interessiert, was bedeutet, dass es eine großartige Gelegenheit war, mit einem ziemlich großen Publikum zu arbeiten. Die Idee eines Chat-Bots hat sich schon lange in meinem Kopf gedreht, daher habe ich beschlossen, dass es interessant wäre, in seiner Freizeit einige Fähigkeiten daraus zu machen. Und wenn er auch bei der Arbeit Vorteile bringen kann, ist das im Allgemeinen hervorragend.

Unser Unternehmen bietet eine umfassende Palette von Dienstleistungen im Bereich des Geschäftstourismus an. Dies bedeutet, dass Sie eine Fähigkeit erwerben können, die dem Benutzer hilft, eine Geschäftsreise zu unternehmen.
Dann war ich im Team für die Entwicklung einer mobilen Anwendung, mit der Sie Flugoptionen und Hotels für Geschäftsreisen finden und die passenden arrangieren können. Einer der Schlüsselindikatoren, für die wir Schwierigkeiten hatten, uns zu erhöhen, war die Anzahl der Downloads. Es kam die Idee auf, dass wenn diese Fähigkeit Benutzer zur Anwendung führt, wir diese Indikatoren verbessern können. Dies war erforderlich, um die Verwendung dieses Projekts zu überprüfen.

Damit eine Fähigkeit für irgendjemanden nützlich ist, muss sie eine bestimmte Aufgabe des Benutzers lösen. Suchen Sie in diesem Fall nach Optionen für eine Geschäftsreise. Das heißt, die Fertigkeit muss Informationen darüber sammeln, wohin sie gehen soll, und die Ergebnisse in einer mobilen Anwendung anzeigen. Auf diese Weise erhält der Benutzer die gewünschten Optionen mithilfe einer interessanten Sprachinteraktion und arbeitet weiterhin in unserer Anwendung, was bedeutet, dass Entwickler die gewünschte Leistungssteigerung erhalten.

Es stellt sich heraus, dass die Fähigkeit ungefähr so ​​funktionieren sollte: Begrüßen Sie den Benutzer; finde ihn beim Namen; Stellen Sie klärende Fragen und erhalten Sie so die notwendigen Reiseparameter: Städte (von wo und wo) und Daten. Als nächstes zeigen Sie die erkannten Parameter. Wenn alles korrekt ist, starten Sie die Suche und geben Sie einen Link zur Anwendung an.

Ressourcen und Einschränkungen

Um seine Aufgabe zu erfüllen, muss der Skill mit unseren internen APIs interagieren und sein Webdienst muss irgendwo veröffentlicht werden. Einerseits konnte es bei der Arbeit eingesetzt werden, aber wie bereits erwähnt, wurde die Entwicklung in der Freizeit durchgeführt, weshalb ich nicht auf speziell zugewiesene Unternehmensressourcen angewiesen sein wollte. Sie mussten also die standardmäßig verfügbaren Funktionen nutzen.

Zum Beispiel ein Testserver. Entwickler haben genügend Rechte, um eine Webanwendung darauf bereitzustellen, diese ist jedoch nur im internen Netzwerk des Unternehmens verfügbar, da der Server nicht hervorsteht. Gleichzeitig hat er Zugang zum Internet, so dass dieser genutzt werden kann.

Der Skill-Webdienst muss von außen zugänglich sein (damit Alice wissen konnte, wohin er Anfragen senden soll), also musste er auf einem externen Hosting platziert werden.

Damit die Fähigkeit ihre Aufgabe erfüllen kann, benötigen Sie einen Unternehmenswebservice, der nach Profilen und Städten suchen kann und von außen zugänglich ist. Die API für mobile Anwendungen ist dafür geeignet, obwohl sie ihre eigenen Nuancen hat. Sie bestehen darin, dass Sie nur für einen bestimmten Benutzer eine Verbindung zur API herstellen können, was bedeutet, dass der Bereich der für die Suche verfügbaren Profile begrenzt ist. Und das Unangenehmste: Die Ergebnisse einer über die API gestarteten Suche werden nur diesem Benutzer zur Verfügung gestellt. Trotzdem verfügt es über die notwendige Funktionalität, was bedeutet, dass Sie damit arbeiten können.

Die Fähigkeit zum externen Hosting interagiert also mit der API. Es ist natürlich ziemlich schnell, aber manchmal hat die Antwort laut Testergebnissen keine Zeit, um in den erforderlichen 1500 ms anzukommen (dies ist die Anforderung der Yandex.Dialogs-Plattform). Und um die Ergebnisse weiterhin an den richtigen Benutzer zu senden, müssen Sie in seinem Namen einen Suchdienst ausführen, der nur im internen Netzwerk verfügbar ist. Die API hilft dabei leider nicht weiter, was bedeutet, dass Sie die Anforderung von der Fertigkeit direkt an die interne Infrastruktur übertragen müssen.
Wir werden diese Probleme lösen, sobald sie verfügbar sind.

Stufen Probleme und Lösungen

Um das beschriebene Szenario allgemein implementieren zu können, muss der Skill zunächst den Status irgendwo speichern: Bühne, Benutzername, Stadt und Datum. Da es nicht viele Informationen gibt, sollten Sie nicht eine ganze Datenbank dafür bereitstellen, zumal es zu viel Aufhebens darum gibt. Sie können den Status im Cache speichern.

Die Wahl fiel auf Redis . Er hat sich in Reaktionstests gut gezeigt, und wir setzen es auch bei der Arbeit eng ein, was bedeutet, dass dieses Projekt bei Erfolg leicht auf das Unternehmen (und den Spoiler - wir haben es verschoben) übertragen werden kann. Als Schlüssel können Sie die Benutzerkennung in der Fertigkeit (in der Anforderung angegeben) verwenden und die Statusdaten im JSON-Format im Wert speichern. Eine kostenlose Version von Redis kann auf Heroku bereitgestellt werden und wird seit einiger Zeit in Yandex.Cloud unterstützt .

Jetzt werden wir die Stufen der Fertigkeit genauer analysieren. Beim ersten Start sieht der Benutzer die übliche Begrüßungsphrase. Als nächstes muss er seinen Namen benennen, nach dem die Fertigkeit nach einem Profil sucht.



Wenn es existiert, sollte sein Name in den Status geschrieben werden, und da der Cache verwendet wird, können die restlichen erforderlichen Informationen über das Profil in ihn eingefügt werden. Wenn der Kunde nun zu der Fertigkeit zurückkehrt, wird ihm eine persönliche Begrüßung angezeigt. Wenn sich dieselbe Person von einem anderen Gerät aus anmeldet und ihren Namen benennt, wird ihr Profil auch im Cache gefunden. Dies bedeutet, dass wir die API nicht erneut durchsuchen müssen, was Zeit bei der Verarbeitung der Anforderung spart.

Als nächstes werden die Auslöseparameter empfangen. Als Benutzer von Sprachkenntnissen möchte ich Städte und Daten so benennen, wie ich möchte, z. B. „Peter“ und „in einer Woche“. Die Fertigkeit muss in der Lage sein, solche Ausdrücke zu erkennen, um den vollständigen Namen der Stadt in die API zu übertragen und am gewünschten Tag eine Suche durchzuführen. Jetzt erhält der Skill-Webdienst diese Informationen sofort direkt in der Anfrage:



Ein solches Feature erschien jedoch um Oktober 2018 und die Fertigkeit wurde etwas früher entwickelt, sodass Dialogflow ausgewählt wurde, um die natürliche Sprache zu verstehen. Es verfügt über ein ausgezeichnetes Markup-System, und von Zeit zu Zeit können Sie es trainieren, um anzuzeigen, was der Benutzer in einem bestimmten Satz gemeint hat.

Der Client benennt die Stadt und das Datum auf seine eigene Weise, der Skill gibt seine Wörter an Dialogflow weiter und sendet den erkannten Städtenamen an die API, von wo er die erforderliche Kennung erhält. Die Kette ist lang und daher wahrscheinlich nicht die erforderlichen 1500 ms zu erfüllen.

Die offensichtliche Lösung ist das Zwischenspeichern. Und als Schlüssel können Sie genau angeben, was der Benutzer gesagt hat, und im Wertspeicher die Stadtkennung aus unserem System speichern. Dann kann es im Cache mehrere Einträge für eine Stadt geben, zum Beispiel für die Wörter "Peter" und "St. Petersburg". Dies ist jedoch nicht kritisch, wenn der Wert nicht zu viele Informationen anzeigt. In jedem Fall können Sie mit diesem Ansatz den Cache mit beliebten Städten füllen, die von anderen Benutzern angefordert wurden, oder ihn im Voraus „aufwärmen“. Auf diese Weise können Sie Dialogflow und die API in Zukunft weniger häufig verwenden, was wiederum Zeit spart.

Der interessanteste Schritt ist das Starten der Suche. Es gibt alle notwendigen Parameter, aber damit die Ergebnisse an die richtige Person gelangen, müssen Sie den internen Suchdienst irgendwie "abrufen". Darüber hinaus dauert die Suche selbst ziemlich lange, und langfristige Vorgänge werden am besten nicht im selben Webdienst, sondern in einer separaten Anwendung ausgeführt.

Es ist Zeit, den verfügbaren Server des Unternehmens zu nutzen. Darauf können Sie eine Anwendung bereitstellen, die Informationen von außen "aufnimmt" und langfristige Aufgaben ausführt, einschließlich des Startens einer Suche.

Eine solche Anwendung könnte durchaus ein Hintergrunddienst sein.

Aus dem Namen geht hervor, dass dies eine Anwendung ohne Benutzeroberfläche ist, die ihre Arbeit zusammen mit dem Starten des Servers beginnen und die geplanten Aktionen oder Aktionen für einen bestimmten Befehl (eine Nachricht) ausführen sollte. Normalerweise organisieren wir einen solchen Dienst im Topshelf- Framework und er kann Befehle beispielsweise von einer Nachrichtenwarteschlange empfangen, die auf dem AMQP- Protokoll basiert.

Kurz gesagt, die Warteschlange funktioniert ungefähr so: Es gibt einen Broker, in dem Absender Nachrichten eines bestimmten Typs hinzufügen. Und es gibt Leser, die sich mit dem Broker verbinden und die notwendigen Informationen erhalten.
Eine ausführlichere Beschreibung finden Sie beispielsweise in diesem Artikel .

Im Internet wurde eine gute Cloud-Lösung gefunden, die eine Nachrichtenwarteschlange als Service bereitstellt - CloudAMQP . Er hat einen kostenlosen Tarif, der aber stabil funktioniert. Ein weiteres Argument für seine Wahl ist, dass dieser Service auf der Basis von RabbitMQ funktioniert, das wir auch bei der Arbeit stark nutzen.

Schauen wir uns also die Arbeit des Skills als Ganzes an: Der Skill-Webdienst interagiert mit der API für mobile Anwendungen und dem Dialogflow. Die Ergebnisse von Aufrufen werden in Redis zwischengespeichert, und der Status wird dort gespeichert. Nach Bestätigung der Parameter der Reise sendet der Skill eine Nachricht mit allen erforderlichen Informationen an den Broker. Der Hintergrunddienst auf dem Testserver stellt eine Verbindung zu ihm her. Wenn eine Meldung angezeigt wird, wird die Suche gestartet und die Ergebnisse werden an die mobile Anwendung gesendet.


Wenn der Client es herunterlädt und installiert, findet er sie in seinen Anforderungen:



Damit ist die Arbeit der Fertigkeit abgeschlossen.

Zusammenfassung

Was ist als nächstes passiert? Diese Fähigkeit wurde mehreren Kunden zur Rückmeldung gezeigt, und wir haben Folgendes herausgefunden: Benutzer selbst zögern, zu einer mobilen Anwendung zu wechseln, egal wie cool sie ist. Für einige von ihnen ist es einfacher, unseren Agenten am Telefon anzurufen und ihn zu bitten, nach dem zu suchen, was er benötigt.

Wie die Praxis zeigt, sind Benutzer in diesem speziellen Fall mehr an der Interaktion mit einem Sprachassistenten interessiert. In diesem Fall ersetzt er den Agenten, wodurch er ein wenig Zeit sparen kann, und motiviert Kunden gleichzeitig, die Anwendung herunterzuladen, um weiterhin mit den darin enthaltenen Optionen zu arbeiten.

Es stellt sich heraus, dass es dank der Fähigkeit möglich ist, bestimmte Ressourcen zu sparen und einige Schlüsselindikatoren zu erhöhen, dh die Annahme des Nutzens der Fähigkeit für unser Unternehmen wurde bestätigt.

Ich möchte einige Schlussfolgerungen hervorheben. Offensichtlich: Um mit 1500 ms Schritt zu halten, vermeiden Sie unnötige Anfragen nach Webdiensten, Cache. Sie können verschiedene Cache-Schlüssel für dieselben Informationen verwenden. Dies ist gerechtfertigt, wenn mindestens eine Person in den von einem anderen Benutzer generierten Cache gelangt. Und das Wichtigste: Es ist besser, langwierige Vorgänge in einem separaten Hintergrunddienst auszuführen: Abgesehen von der Tatsache, dass die Fähigkeit dezentralisiert wird, treten weniger Probleme mit Multithreading auf, und bei Bedarf kann es innerhalb des geschlossenen Netzwerks des Unternehmens "bereitgestellt" werden und Nachrichten von außen "abholen".

Anstelle eines Nachworts

Chatbots und Fähigkeiten werden häufig in JavaScript und Python geschrieben (gemessen an der Anzahl der Repositorys auf GitHub für „Chatbot“). Dies liegt auch an der einfachen Veröffentlichung auf dem Server. Dieses Projekt wurde in C # unter .net Core geschrieben. Im Fall des klassischen .net-Frameworks gibt es bestimmte Schwierigkeiten beim Veröffentlichen (es funktioniert hauptsächlich unter Windows usw.), aber mit dem Aufkommen des .net-Kerns hat sich viel geändert. Für jeden oben genannten Dienst oder Framework gibt es Bibliotheken, die diese Technologie vollständig unterstützen. Dank dessen kann die Fähigkeit möglicherweise auf Linux-Servern ausgeführt werden, und noch mehr auf jedem Hosting, das Docker unterstützt. Wenn Sie plötzlich auf einer kreativen Suche sind, empfehle ich, auf dieses Framework zu achten. Es wird eine gute Alternative für die Entwicklung von Chat-Bots.

PS
UPD 08/01/2019: Ab sofort beträgt die Zeitüberschreitung für Fertigkeiten 3 Sekunden .