Pratique de la technologie du moteur de processus SOP multi-tours du robot de service client Dewu

1. Contexte commercial

Au début de l'auto-développement du robot de service client Dewu, la solution FAQ traditionnelle à une question, une réponse était grossière dans les scénarios commerciaux réels, il devenait de plus en plus difficile de répondre aux besoins des utilisateurs. besoins de consultation et il n'y avait aucune différence. Les solutions de processus standardisées guident avec précision les utilisateurs pour résoudre les problèmes, mais un grand nombre d'utilisateurs s'appuient toujours sur le service client manuel pour résoudre les problèmes. Les premiers moteurs SOP multi-tours reposaient principalement sur des plates-formes tierces. La vitesse de réponse des tiers était relativement lente, les services fournis n'étaient pas personnalisables et l'efficacité de la configuration des processus était également relativement faible. Avec le développement rapide des affaires, il est absolument nécessaire d'améliorer la capacité du robot à résoudre des scénarios complexes, de réduire le coût du service client manuel et de fournir un backend de configuration de processus SOP visuel multi-tours flexible. Cela a lancé le multi-développement auto-développé. -moteur de processus SOP rond de kilométrage.

2. Introduction aux multi-roues

Après avoir compris le contexte commercial, de nombreuses personnes ne savent peut-être pas grand-chose sur les multi-roues dans les scénarios de service client. Ici, en combinaison avec un véritable dialogue homme-machine, nous présenterons comment les robots résolvent les problèmes des utilisateurs. basé sur plusieurs roues.

Comme le montre ce qui précède, le processus de consultation des utilisateurs se déroule étape par étape selon le processus de questions et réponses. Il n'y a pas d'intervention manuelle du service client pendant cette période. En plusieurs cycles de conversations, le service client. le robot a résolu le problème de l'utilisateur. Alors il peut y avoir une question ici, comment le robot sait-il quoi demander et quoi répondre ? En fait, il ne s'agit ni de reconnaissance sémantique ni de reconnaissance algorithmique. Il existe une page de construction visuelle correspondante en arrière-plan de configuration pour configurer plusieurs séries de processus.

3. Recherche préliminaire

Après avoir clarifié les exigences, quel type de capacités techniques faut-il utiliser pour construire le processus SOP multi-tours du robot ? Le choix principal était-il de le mettre en œuvre de 0 à 1 ou sur la base d'un framework open source ? problème rencontré à l’époque. C'est bien sûr le mieux de l'implémenter de 0 à 1, et c'est aussi l'occasion pour de nombreux étudiants techniques de se mettre au défi. Cependant, le principal problème rencontré à cette époque était que la construction du processus impliquait le canevas Canvas et l'édition graphique. si vous n'avez pas de connaissances professionnelles, ce sera relativement difficile. C'était relativement important, et couplé au développement rapide de l'entreprise à cette époque, il y avait un besoin urgent de pouvoir personnaliser plusieurs cycles d'auto-développement. produits, j'ai donc choisi un framework open source pour l'implémenter. Dans l'étude des frameworks open source, nous avons également fait référence à la mise en œuvre de nombreuses configurations de processus, comme suit :

• Styles de nœuds personnalisés dans les scénarios métiers
• vue-flowchart-editor : un framework d'édition d'organigrammes basé sur vue qui fournit plusieurs styles de nœuds et des capacités de configuration de données simples. Les nœuds personnalisés nécessitent un développement secondaire basé sur le code source ;
• Activité : Il s'agit d'un ensemble complet de moteurs de processus qui intègrent des modèles front-end, back-end et de données. S'il est utilisé, non seulement le front-end nécessite un développement secondaire, mais également le back-end. Le coût de déploiement des services correspondants ou de leur reconception et de leur développement est relativement élevé, et la pile technologique front-end utilisée par Activity est relativement ancienne. et difficile à intégrer dans notre système existant, il n'est donc pas adapté au scénario commercial actuel ;
• Flowable : un moteur de processus métier. S'il est utilisé, le backend doit déployer un ensemble complet de. services de moteur de processus. Le frontend coopère principalement avec des modifications et le coût est relativement élevé. Il n'est pas adapté au scénario commercial actuel ;
• X6 : Il s'agit d'un moteur d'édition de graphiques sous AntV. des composants interactifs prêts à l'emploi et des capacités de personnalisation de nœuds faciles à utiliser, facilitant la création rapide d'applications graphiques telles que des organigrammes.

Chaque framework a ses propres avantages et inconvénients. Enfin, nous avons choisi le moteur d'édition de graphiques antv-x6 pour le développement secondaire. Les principales raisons sont les suivantes :

• Les produits de données open source d'Ant ont une communauté relativement active ; Suivre la technologie Indépendant de la pile et très évolutif ;
• prend en charge les nœuds personnalisés et est hautement personnalisable ;
• Les composants de l'outil sont relativement complets et peuvent être utilisés directement
• 4. la prochaine étape est la mise en œuvre technique spécifique. Le moteur de processus SOP à plusieurs tours nécessite non seulement la conception et la mise en œuvre du front-end, mais ne peut pas non plus se passer de la conception et de la mise en œuvre du back-end. La conception globale de l'architecture est présentée dans la figure ci-dessous :

.

4.1 Couche de configuration frontale

La couche de configuration frontale comprend principalement plusieurs tours. Il existe quatre modules fonctionnels de construction de processus visuels SOP, de gestion en ligne et hors ligne, de gestion de versions et de gestion d'interface.

• Construction visuelle de SOP multi-tours : incluant les opérations de glisser-déposer et la configuration des données de chaque nœud métier, et générant une configuration complète du processus grâce à l'association de différents nœuds métier
• Gestion en ligne et hors ligne : le multi-tours construit ; Le processus SOP rond doit être des opérations en ligne et hors ligne. Lorsque des problèmes surviennent dans le processus SOP multi-tours en ligne, vous devez vous déconnecter à temps.
• Gestion des versions : lorsque le processus SOP multi-tours configuré vient d'être publié, les compétences de réponse ; ou les fonctions des nœuds de processus sont relativement basiques. , il est nécessaire d'améliorer continuellement les capacités du processus grâce aux données de processus des utilisateurs en ligne. Chaque changement nécessite une version mise à niveau pour garantir une version en ligne stable tout en optimisant continuellement plusieurs cycles de processus SOP ;
Gestion des interfaces : processus Chaque nœud métier impliqué dépend de services dans différents domaines métiers, tels que les commandes reposant sur des interfaces de transaction, la logistique reposant sur des interfaces de chaîne d'approvisionnement, etc. Ces fonctions impliquées dans la configuration des processus métier doivent être implémentées via la configuration de l'interface.

4.2 Couche de service backend

La partie essentielle de la couche de service backend est le module du moteur d'exécution de processus. Dans les scénarios d'application réels, le processus le plus approprié sera adapté en fonction des problèmes saisis par l'utilisateur pour résoudre les problèmes de l'utilisateur. Lors de l'exécution du processus correspondant, le moteur d'exécution créera d'abord le contexte du processus. Ici, les informations contextuelles seront chargées à partir du cache Redis. En fonction de l'état d'exécution du processus enregistré dans le contexte, elles seront déterminées à partir de. quel nœud démarrer l'exécution. Après l'exécution, le contexte sera les mises à jour des informations. Lorsque l'exécution du processus se termine, le contexte est détruit.

4.3 Couche d'application

La couche d'application concerne principalement les scénarios d'utilisation spécifiques du processus SOP à plusieurs tours. Actuellement, elle comprend principalement les deux scénarios d'utilisation du robot de service client Dewu et du SOP assisté par agent.

5. Défis techniques

5.1 Modélisation des données

Résoudre le problème de l'association entre les nœuds grâce à la modélisation des données.

Dans le processus de visualisation du processus SOP à plusieurs tours, la création et la connexion des nœuds du canevas sont les plus compliquées. Certaines scènes à plusieurs tours ont plus de 100 nœuds et la relation entre les nœuds est très importante dans le canevas. Il existe actuellement 4 types de nœuds personnalisés par l'entreprise, comme suit :

Chaque nœud a ses propres attributs commerciaux. Ici, l'activité de chaque nœud est principalement combinée à travers l'idée de. ​​modélisation des données. Les attributs et les attributs de relation sont abstraits. L'idée est la suivante :

Les types de données d'origine fournis par Les champs d'attributs d'origine peuvent être étendus et les attributs de données fournis par X6 peuvent bien répondre aux besoins de. données commerciales personnalisées. Après avoir analysé les quatre types de nœuds métier, chaque nœud métier peut résumer un modèle de données commun. Les significations de ses principaux champs sont les suivantes :

nodeName : le nom du nœud
• nodeType : le type du nœud. Il existe quatre types de nœuds : les nœuds de remplissage, les nœuds de saut, les nœuds de réponse et les nœuds de jugement
• fromNodeId : l'ID du nœud source
• nextNodeId : l'ID du nœud de pointage
• fromEdgeIdList : la liste des ID de bord source
• nextEdgeIdList : la liste des identifiants de bord de pointage
• bizData : différentes informations sur les attributs métier des nœuds métier

Ici, bizData est utilisé comme modèle de données général des nœuds métier pour stocker les données d'attribut de différents nœuds métier. Par exemple, les nœuds de remplissage d'emplacements ont des affaires. des attributs tels que slot et anorma, et les nœuds de réponse ont des attributs métier tels que contentSort et content. En faisant abstraction du modèle de données des nœuds métier, les relations entre les différents nœuds peuvent être exprimées, comme le montre la figure ci-dessous :

• Le nœud de jugement peut être associé au nœud de remplissage de slot et au nœud de saut via l'attribut nextEdgeIdList ;
• Le nœud de jugement peut être associé au nœud de réponse manuelle via l'attribut fromNodeId
• Le nœud de réponse manuelle peut être associé à ; le nœud de réponse de sauvegarde via nextNodeId ;
• Le nœud de réponse de sauvegarde Vous pouvez créer un lien vers le nœud de réponse manuelle via fromEdgeIdList.

Une fois que les différentes relations de nœuds sont exprimées via des attributs sémantiques, les nœuds et les bords sont connectés sur la base de la méthode addNode/addEdge fournie par X6. De cette manière, quel que soit le nombre de nœuds dans le canevas, les relations entre les nœuds. sont très clairs.

5.2 RXJS

Résoudre le problème de la direction du flux de données de différents modules fonctionnels grâce à l'abonnement aux événements RXJS et au flux de données unidirectionnel

Dans l'arrière-plan de la construction de visualisation SOP multi-tours, il existe trois zones fonctionnelles différentes : barre d'outils, canevas zone et zone de configuration des données. Le fonctionnement de chaque zone impliquera des modifications des données des nœuds. S'il n'y a pas de flux de données clair, cela entraînera des modifications chaotiques des données et un risque de confusion potentielle des données lors de la sauvegarde. Ici, nous adoptons le modèle de conception de l'abonnement aux événements RXJS et du flux de données unidirectionnel. L'implémentation spécifique est illustrée dans la figure ci-dessous :

• L'opération de nœud dans la barre d'opération déclenchera des événements, tels que la suppression de l'opération de nœud. ;
• Sélectionnez les éléments requis dans la zone de canevas. Le nœud supprimé déclenche l'événement de suppression des données du nœud ;
• La zone de configuration du formulaire de données reçoit les données de l'événement de suppression des données du nœud, supprime les données du nœud correspondant et les synchronise avec le cache mémoire des données.
• Lorsque le processus est finalement soumis, les données en mémoire sont transférées vers la base de données du serveur.

L'ensemble du processus s'écoule des données du nœud pour former les données, puis pour mettre les données en cache. La direction entière du flux est unidirectionnelle. Quel que soit le module déclenché, la direction finale du flux est le cache de la mémoire des données.

Pour le flux de données, il existe actuellement de nombreux frameworks open source disponibles, tels que redux, vuex, dva, etc. Pourquoi RXJS est-il utilisé ici ? Principalement parce que RXJS est relativement léger et n'a rien à voir avec la pile technologique, il offre donc une meilleure évolutivité ultérieure.

5.3 Orchestration des processus

Résoudre le problème de la création de processus multi-tours complexes grâce à la technologie d'orchestration des processus

Au premier semestre, il existe près de 200 multi-tours en ligne, et certains processus complexes contiennent plus de 100 nœuds .Pour plus de 100 Si le processus complexe des nœuds est configuré nœud par nœud, l'efficacité de la configuration sera extrêmement faible. Alors, comment pouvons-nous créer rapidement des processus complexes ? La technologie d’orchestration des processus est utilisée ici.

L'orchestration des processus fait référence à l'organisation des processus métier en faisant glisser et en déposant des composants commerciaux visuels, puis le moteur de processus exécute le processus. Son protocole standardisé est le protocole BPMN, qui contient les significations et les spécifications d'utilisation de diverses icônes et composants dans l'orchestration des processus. Dans les scénarios d'application réels, nous n'avons pas entièrement utilisé le protocole BPMN, mais avons suivi le protocole BPMN et créé des composants personnalisés. Pour les processus complexes, nous les organisons à travers différents sous-processus. L'idée est la suivante :

Voici un exemple du processus en plusieurs tours d'annulation de commandes. Le processus se décompose comme suit :

.

Vous pouvez clairement le voir sur l'image ci-dessus. Le processus d'annulation de commande à plusieurs tours comprend trois sous-processus : un sous-processus pour déterminer l'identité de l'utilisateur, un sous-processus pour déterminer les demandes des utilisateurs et un sous-processus pour annuler les commandes. de ces sous-processus est un processus indépendant et complet. De cette manière, grâce à l’agencement de trois sous-processus, un processus complexe à plusieurs tours d’annulation de commande peut être construit.

Les trois points ci-dessus sont les principaux défis techniques rencontrés dans le processus d'auto-recherche. En fait, le processus présente de nombreuses difficultés, telles que la façon de restituer des centaines de nœuds en quelques secondes, une logique complexe (copie, découpe), comment organiser les nœuds de jugement complexes, comment développer et réduire les nœuds de jugement complexes en un seul clic, etc., ne seront pas développés ici un par un.

6. Résultats commerciaux

L'auto-recherche du service client sur plusieurs séries de moteurs de processus SOP a complètement remplacé les services tiers. Elle permet non seulement d'économiser au moins des centaines de milliers de coûts de services externalisés chaque année, mais permet également d'obtenir de bons résultats. Personnalisation flexible pour accompagner rapidement le développement commercial. Depuis son lancement, il a principalement couvert deux scénarios commerciaux : les robots de service client Dewu et les robots assistés par agents. Parmi eux, les robots Dewu ont des centaines de processus SOP à plusieurs tours, et les robots assistés par agents ont des dizaines de processus SOP à plusieurs tours. ce qui s'est considérablement amélioré. Améliorez le taux de résolution du service client et réduisez les coûts de main-d'œuvre de transfert. Après la mise en ligne, en prenant comme exemple les données d'un mois de cette année, le taux de solution du robot du service client s'est considérablement amélioré. Le taux de solution SOP a augmenté de plus de 15 % par rapport au taux de solution FAQ. Le numéro est 2 fois le numéro de réception de la FAQ. Cela permet d'économiser considérablement les coûts de main-d'œuvre.

7. Résumé

Le moteur de processus SOP multi-tours du robot de service client prend environ un mois entre l'établissement du projet et sa sortie. Le processus à partir de zéro est le résultat des efforts conjoints de tous les investisseurs. À l'heure actuelle, en plus de servir les deux scénarios ci-dessus, le moteur de processus multi-tours explore également des scénarios d'utilisation dans les activités d'ordre de travail et d'inspection qualité. Il continue également d'enrichir les scénarios d'assistance aux agents pour fournir des processus de service standardisés pour les utilisateurs de première ligne. service client et améliorer le taux de résolution du service client de première ligne. En termes de fonctionnalités, nous continuerons d'améliorer les capacités du moteur de processus, de prendre en charge l'utilisation d'un plus grand nombre de scénarios commerciaux et d'améliorer continuellement les capacités du moteur de processus pour devenir une référence dans l'industrie.

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!