Dewu Kundenservice-Roboter-Multi-Round-SOP-Prozess-Engine-Technologie-Praxis

1. Geschäftshintergrund

In den frühen Tagen der Selbstentwicklung des Dewu-Kundendienstroboters war die traditionelle FAQ-Lösung mit einer Frage und einer Antwort grobkörniger und wurde immer schwieriger zu lösen Um den Beratungsbedarf der Benutzer zu erfüllen, gibt es keine differenzierte Prozesslösung, die Benutzer bei der Lösung von Problemen genau anleitet. Frühe Multi-Runden-SOP-Engines stützten sich hauptsächlich auf Plattformen von Drittanbietern. Die Reaktionsgeschwindigkeit der Drittanbieter war relativ langsam, die bereitgestellten Dienste waren nicht anpassbar und die Effizienz der Prozesskonfiguration war relativ gering. Angesichts der rasanten Geschäftsentwicklung ist es sehr wichtig, die Fähigkeit des Roboters zur Lösung komplexer Szenarien zu verbessern, die Kosten für den manuellen Kundenservice zu senken und ein flexibles visuelles Multi-Runden-SOP-Prozesskonfigurations-Backend bereitzustellen. Damit wurde das selbst entwickelte Multi gestartet -runde SOP-Prozess-Engine.

2. Multi-Wheel-Einführung

Nachdem wir den geschäftlichen Hintergrund verstanden haben, wissen viele Menschen möglicherweise nicht viel über Multi-Wheel in Kundendienstszenarien Tatsächlicher Mensch-Maschine-Dialog: So löst der Roboter Benutzerprobleme auf der Grundlage mehrerer Runden.

Wie aus dem oben Gesagten hervorgeht, wird der Benutzerberatungsprozess Schritt für Schritt entsprechend dem Frage- und Antwortprozess abgeschlossen Da keine manuellen Kundendiensteingriffe erforderlich sind, hat der Kundendienst-Bot das Problem des Benutzers gelöst. Dann stellt sich hier möglicherweise die Frage: Woher weiß der Roboter, was er fragen und was er antworten soll? Tatsächlich handelt es sich weder um eine semantische noch um eine Algorithmuserkennung. Im Konfigurationshintergrund gibt es eine entsprechende visuelle Konstruktionsseite, um mehrere Prozessrunden zu konfigurieren.

3. Vorläufige Forschung

Welche technischen Fähigkeiten sollten zum Aufbau des mehrstufigen SOP-Prozesses verwendet werden? 1 oder basierend auf einem Open-Source-Framework? Zu erkennen, dass es damals das Hauptproblem war. Es ist natürlich am besten, es von 0 auf 1 zu implementieren, und es ist auch eine Gelegenheit für viele Technikstudenten, sich selbst herauszufordern. Das Hauptproblem bestand jedoch darin, dass der Prozess die Bearbeitung von Canvas und Grafiken umfasste Wenn Sie nicht über professionelles Hintergrundwissen verfügen, wird es relativ schwierig sein. Es war relativ groß und in Verbindung mit der schnellen Entwicklung des Unternehmens zu dieser Zeit bestand ein dringender Bedarf an der Fähigkeit, mehrere Runden selbst zu entwickeln Daher habe ich mich für ein Open-Source-Framework entschieden, um es zu implementieren. Bei der Untersuchung von Open-Source-Frameworks haben wir auch auf die Implementierung vieler Prozesskonfigurationen verwiesen, wie folgt:

• Implementieren Sie den Aufbau eines Flussdiagramms, können jedoch die benutzerdefinierten Knotenstile in Geschäftsszenarien nicht erfüllen Benutzerdefinierte Knoten erfordern eine sekundäre Entwicklung basierend auf dem Quellcode Es muss nur die Front-End-Seite neu entwickelt werden, aber auch die Back-End-Seite muss entsprechende Dienste bereitstellen oder neu gestalten und entwickeln. Die Kosten sind relativ hoch, und der von Activity verwendete Front-End-Technologie-Stack ist relativ hoch relativ alt. Unser bestehendes System ist schwer zu integrieren und eignet sich daher nicht für das aktuelle Geschäftsszenario Es handelt sich um einen vollständigen Satz von Prozess-Engine-Diensten, der hauptsächlich mit Modifikationen zusammenarbeitet, und die Kosten sind im aktuellen Geschäftsszenario nicht geeignet Bildbearbeitungs-Engine unter AntV, die eine Reihe sofort einsatzbereiter interaktiver Komponenten und benutzerfreundliche Knotenanpassungsfunktionen bereitstellt, die die schnelle Erstellung von Flussdiagrammen und anderen Diagrammanwendungen erleichtern.
• Jedes Framework hat seine eigenen Vor- und Nachteile. Schließlich haben wir uns für die Bildbearbeitungs-Engine antv-x6 für die Sekundärentwicklung entschieden. Die Hauptgründe sind wie folgt:
• #🎜🎜 #
Ants Open-Source-Datenprodukt, die Community ist relativ aktiv;
• hat nichts mit dem Technologie-Stack zu tun und hat eine gute Skalierbarkeit;
• unterstützt benutzerdefinierte Knoten und kann individuell angepasst werden.

Die Werkzeugkomponenten sind relativ vollständig und können sofort verwendet werden.

• 4. 🎜🎜#Technologieauswahl klären Danach erfolgt im nächsten Schritt die konkrete technische Umsetzung. Die mehrstufige SOP-Prozess-Engine erfordert nicht nur das Design und die Implementierung des Front-Ends, sondern kann auch nicht ohne das Design und die Implementierung des Back-Ends auskommen. Das gesamte Architekturdesign ist in der folgenden Abbildung dargestellt:
• #🎜 🎜#4.1 Front-End-Konfigurationsschicht
• Die Front-End-Konfigurationsschicht umfasst hauptsächlich vier Funktionsmodule: mehrstufige visuelle SOP-Prozesskonstruktion, Online- und Offline-Management, Versionsmanagement und Schnittstellenmanagement.
• Visuelle Konstruktion von Multi-Runden-SOP: einschließlich Drag-and-Drop-Vorgängen und Datenkonfiguration für jeden Geschäftsknoten sowie Generierung einer vollständigen Prozesskonfiguration durch die Verknüpfung verschiedener Geschäftsknoten.
• Online- und Offline-Verwaltung: die erstellte Multi- Der Runden-SOP-Prozess muss online und offline erfolgen. Wenn im Online-Mehrrunden-Prozess Probleme auftreten, müssen Sie rechtzeitig offline gehen Da die Prozessfunktionen relativ einfach sind, müssen die Prozessfunktionen der Online-Benutzer kontinuierlich verbessert werden, um eine stabile Online-Version sicherzustellen
• Schnittstellenmanagement: Prozess Jeder beteiligte Geschäftsknoten ist auf Dienste in verschiedenen Geschäftsdomänen angewiesen. Beispielsweise müssen Bestellungen auf Transaktionsschnittstellen, Logistik auf Lieferkettenschnittstellen usw. angewiesen sein. Solche Funktionen sind an der Konfiguration von Geschäftsprozessen beteiligt und müssen dies tun durch Schnittstellenkonfiguration umgesetzt werden.
• 4.2 Backend-Serviceschicht

Der Kernteil der Backend-Serviceschicht ist das Prozessausführungs-Engine-Modul. In tatsächlichen Anwendungsszenarien wird der am besten geeignete Prozess entsprechend den vom Benutzer eingegebenen Problemen ausgewählt, um die Probleme des Benutzers zu lösen. Während der Ausführung des übereinstimmenden Prozesses erstellt die Ausführungs-Engine zunächst den Kontext des Prozesses. Dabei werden die Kontextinformationen aus dem Redis-Cache geladen und anhand des im Kontext aufgezeichneten Prozessausführungsstatus ermittelt Welcher Knoten soll die Ausführung starten? Nach der Ausführung lautet der Kontext Informationsaktualisierungen. Wenn die Prozessausführung endet, wird der Kontext zerstört.

4.3 Anwendungsschicht

Die Anwendungsschicht besteht hauptsächlich aus den spezifischen Nutzungsszenarien des mehrstufigen SOP-Prozesses. Derzeit umfasst sie hauptsächlich die beiden Nutzungsszenarien des Dewu-Kundendienstroboters und des agentengestützten SOP.

5. Technische Herausforderungen

5.1 Datenmodellierung

Lösen Sie das Problem der Zuordnung zwischen Knoten durch Datenmodellierung.

Bei der Visualisierung des Multi-Runden-SOP-Prozesses ist die Erstellung und Verbindung von Canvas-Knoten am kompliziertesten. Einige Multi-Runden-Szenen haben mehr als 100 Knoten, und die Beziehung zwischen Knoten ist im Canvas sehr wichtig. Derzeit gibt es vier Arten von geschäftsspezifischen Knoten:







Jeder Knoten hat seine eigenen Geschäftsattribute. Hier wird das Geschäft jedes Knotens hauptsächlich durch die Idee integriert ​​Datenmodellierung. Die Idee ist wie folgt:

Die von X6 bereitgestellten ursprünglichen Datentypen können erweitert werden, und die von X6 bereitgestellten Datenattribute können die Anforderungen von erfüllen maßgeschneiderte Geschäftsdaten. Nach der Analyse der vier Arten von Geschäftsknoten kann jeder Geschäftsknoten ein gemeinsames Datenmodell abstrahieren. Die Bedeutung seiner Hauptfelder ist wie folgt:

nodeName: der Name des Knotens
• nodeType: der Typ des Knotens Es gibt vier Knotentypen: Füllknoten, Sprungknoten, Antwortknoten und Beurteilungsknoten.
• fromNodeId: ID des Quellknotens.
• nextNodeId: ID des zeigenden Knotens.
• fromEdgeIdList: Liste der Quellkanten-IDs.
• nextEdgeIdList: Liste der zeigenden Knoten Edge-IDs
• bizData: verschiedene Geschäftsattributinformationen von Geschäftsknoten
• Hier wird bizData als allgemeines Datenmodell von Geschäftsknoten verwendet, um Attributdaten verschiedener Geschäftsknoten zu speichern. Slot-Filling-Knoten verfügen beispielsweise über Geschäftsattribute wie Slot und Abnorma und Antwortknoten verfügen über Geschäftsattribute wie contentSort und content. Durch die Abstraktion des Datenmodells von Geschäftsknoten können die Beziehungen zwischen verschiedenen Knoten ausgedrückt werden, wie in der folgenden Abbildung dargestellt:
• Der Beurteilungsknoten kann über das Attribut „nextEdgeIdList“ mit dem Slot-Füllungsknoten und dem Sprungknoten verknüpft werden.
• Der Beurteilungsknoten kann über das Attribut „fromNodeId“ mit dem manuellen Antwortknoten verknüpft werden der Backup-Antwortknoten über nextNodeId;
• Der Backup-Antwortknoten Sie können über fromEdgeIdList eine Verknüpfung zum manuellen Antwortknoten herstellen.
• Nachdem verschiedene Knotenbeziehungen durch semantische Attribute ausgedrückt wurden, werden die Knoten und Kanten basierend auf der von X6 bereitgestellten Methode addNode/addEdge verbunden sind sehr klar.

5.2 RXJS

Lösen Sie das Problem der Datenflussrichtung verschiedener Funktionsmodule durch RXJS-Ereignisabonnement und unidirektionalen Datenfluss

Im Hintergrund der mehrrunden SOP-Visualisierungskonstruktion gibt es drei verschiedene Funktionsbereiche: Symbolleiste, Leinwand Der Betrieb jedes Bereichs erfordert Änderungen an den Knotendaten. Wenn kein klarer Datenfluss besteht, führt dies zu chaotischen Datenänderungen und dem Risiko einer möglichen Datenverwechslung beim Speichern. Hier übernehmen wir das Entwurfsmuster des RXJS-Ereignisabonnements und des unidirektionalen Datenflusses. Die spezifische Implementierung ist in der folgenden Abbildung dargestellt:



Der Knotenvorgang in der Betriebsleiste löst Ereignisse aus, z. B. das Löschen des Knotenvorgangs ;
• Wählen Sie im Canvas-Bereich den gewünschten Knoten aus. Der gelöschte Knoten löst das Knotendaten-Löschereignis aus.
• Der Datenformular-Konfigurationsbereich empfängt die Daten des Knotendaten-Löschereignisses, löscht die entsprechenden Knotendaten und synchronisiert sie mit dem Datenspeicher-Cache ;
• Wenn der Vorgang endgültig übermittelt wird, werden die Daten im Speicher in die Serverdatenbank übertragen.
• Der gesamte Prozess verläuft von den Knotendaten über die Formulardaten bis hin zu den Cache-Daten. Die gesamte Flussrichtung ist unabhängig davon, welches Modul ausgelöst wird, die endgültige Flussrichtung ist der Datenspeicher-Cache.

Für den Datenfluss stehen derzeit viele Open-Source-Frameworks wie Redux, Vuex, DVA usw. zur Verfügung. Warum wird hier RXJS verwendet? Hauptsächlich, weil RXJS relativ leichtgewichtig ist und nichts mit dem Technologie-Stack zu tun hat und daher eine bessere spätere Skalierbarkeit aufweist.

5.3 Prozessorchestrierung

Lösen Sie das Problem der komplexen mehrrunden Prozesskonstruktion durch Prozessorchestrierungstechnologie

Im ersten Halbjahr gibt es fast 200 Online-Mehrrunden, und einige komplexe Prozesse enthalten mehr als 100 Knoten . Wenn der komplexe Prozess von Knoten Knoten für Knoten konfiguriert wird, ist die Konfigurationseffizienz extrem gering. Wie können wir also schnell komplexe Prozesse erstellen? Dabei kommt Prozessorchestrierungstechnologie zum Einsatz.

Prozessorchestrierung bezieht sich auf das Anordnen von Geschäftsprozessen durch Ziehen und Ablegen visueller Geschäftskomponenten, und dann führt die Prozess-Engine den Prozess aus. Sein standardisiertes Protokoll ist das BPMN-Protokoll, das die Bedeutungen und Verwendungsspezifikationen verschiedener Symbole und Komponenten in der Prozessorchestrierung enthält. Im tatsächlichen Anwendungsszenario haben wir das BPMN-Protokoll nicht vollständig genutzt, sondern das BPMN-Protokoll befolgt und benutzerdefinierte Komponenten erstellt. Bei komplexen Prozessen gliedern wir diese in verschiedene Teilprozesse:

Hier ist ein Beispiel für den mehrstufigen Prozess der Stornierung von Bestellungen:

Aus dem Bild oben ist deutlich zu erkennen, dass der mehrstufige Auftragsstornierungsprozess drei Unterprozesse umfasst: einen Unterprozess zur Ermittlung der Benutzeridentität, einen Unterprozess zur Ermittlung der Benutzeranforderungen und einen Unterprozess zur Stornierung von Bestellungen. Jeder dieser Teilprozesse ist ein unabhängiger und vollständiger Prozess. Auf diese Weise kann durch die Anordnung von drei Teilprozessen ein komplexer Mehrrundenprozess zur Auftragsstornierung aufgebaut werden.

Die oben genannten drei Punkte sind die wichtigsten technischen Herausforderungen im Prozess der Selbstrecherche. Tatsächlich gibt es immer noch viele Schwierigkeiten im Prozess, z. B. das Rendern von Hunderten von Knoten in Sekunden und komplexe Logik (Kopieren, Schneiden). , wie man komplexe Beurteilungsknoten anordnet, wie man komplexe Beurteilungsknoten mit einem Klick erweitert und reduziert usw., wird hier nicht einzeln erläutert.

6. Geschäftsergebnisse

Die Selbstrecherche mehrerer Runden von SOP-Prozess-Engines hat nicht nur jedes Jahr mindestens Hunderttausende ausgelagerter Servicekosten eingespart, sondern auch gute Ergebnisse erzielt Geschäft. Flexible Anpassung zur schnellen Unterstützung der Geschäftsentwicklung. Seit seiner Einführung deckt es hauptsächlich zwei Geschäftsszenarien ab: Dewu-Kundendienstroboter und agentenunterstützte Roboter. Darunter verfügen Dewu-Roboter über Hunderte von mehrrunden SOP-Prozessen und agentenunterstützte Roboter über Dutzende von mehrrunden SOP-Prozessen. Dies hat die Lösungsrate des Kundendienstes erheblich verbessert und die Transferarbeitskosten gesenkt. Nach der Online-Bereitstellung hat sich die Lösungsrate des Kundendienstroboters am Beispiel eines Monats dieses Jahres deutlich verbessert. Die SOP-Lösungsrate ist im Vergleich zur FAQ-Lösungsrate deutlich gestiegen Die Nummer ist doppelt so hoch wie die FAQ-Empfangsnummer. Dies spart erheblich Arbeitskosten.

7. Zusammenfassung

Die mehrstufige SOP-Prozess-Engine des Kundenservice-Roboters dauert von der Projekterstellung bis zur Veröffentlichung etwa einen Monat. Der Prozess ist das Ergebnis der gemeinsamen Anstrengungen aller Investoren. Derzeit erforscht die Multi-Runden-Prozess-Engine nicht nur die beiden oben genannten Szenarien, sondern auch Einsatzszenarien im Arbeitsauftragsgeschäft und im Qualitätsprüfungsgeschäft. Außerdem erweitert sie weiterhin Szenarien zur Agentenunterstützung, um standardisierte Serviceprozesse für den Frontline-Bereich bereitzustellen Kundenservice und Verbesserung der Lösungsrate an vorderster Front. In Bezug auf die Funktionalität werden wir die Fähigkeiten der Prozess-Engine weiter verbessern, die Verwendung weiterer Geschäftsszenarien unterstützen und die Fähigkeiten der Prozess-Engine kontinuierlich verbessern, um ein Maßstab in der Branche zu werden.

Das obige ist der detaillierte Inhalt vonDewu Kundenservice-Roboter-Multi-Round-SOP-Prozess-Engine-Technologie-Praxis. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!