Automatisation en temps réel

Dans ce tutoriel pratique, nous allons créer une application de triage automatisée simple qui utilise Communications Mining pour catégoriser les e-mails entrants en temps réel. Nous allons créer un workflow de bout en bout qui peut être utilisé comme point de départ de votre propre automatisation Communications Mining, et examiner en détail comment utiliser l'API Stream en temps réel.

Prérequis

Principes de base de Communications Mining

Avant de commencer ce tutoriel, assurez-vous de bien connaître les concepts et la terminologie de Communications Mining, ainsi que les bases de l'API de Communications Mining.

Accès à Communications Mining

Vous avez besoin des autorisations suivantes pour suivre le tutoriel. Vous pouvez vérifier vos autorisations actuelles sur votre page Gérer le compte (Manage Account).

Projet	DESCRIPTION	PERMISSIONS
reinfer-sandbox	Contient l'ensemble de données reinfer-sandbox/integration-tutorial pré-labellisé utilisé dans ce tutoriel.	« Afficher les sources », « Afficher les libellés »
Votre projet de développement	Lors de votre intégration, vous devriez avoir reçu l’accès à un projet que vous pouvez utiliser comme environnement de développement.	« Administrateur des flux », « Utiliser des flux », « Afficher les sources », « Afficher les libellés »

Veuillez contacter l'assistance si vous ne savez pas quel projet vous pouvez utiliser pour le développement, ou si vous avez besoin des autorisations « Afficher les sources » et « Afficher les libellés » dans reinfer-sandbox.

Données du tutoriel

Dans ce tutoriel, nous utiliserons des données pré-labellisées. Afin de faire une copie de l'ensemble de données reinfer-sandbox/integration-tutorial pré-labellisé, créez un nouvel ensemble de données dans votre projet de développement à l'aide de l'option Copier une taxonomie existante. Vous pouvez trouver des instructions sur la façon de procéder ici.

Étant donné que votre nouvel ensemble de données contient des données labellisées, le modèle commencera à s'entraîner immédiatement. Vous pouvez suivre le statut d'entraînement du modèle dans la barre d'état de l'ensemble de données. Une fois que cela est fait, les métriques de performances pour chaque libellé apparaîtront sur la page Validation et une nouvelle version du modèle apparaîtra sur la page Modèles.

Figure 1.. Page de validation affichant les performances du libellé

Figure 2. Page Modèles (Models) affichant la nouvelle version du modèle.

Concevoir votre application

Maintenant que vous connaissez les prérequis, commençons à construire notre workflow de bout en bout. Dans cette section, nous discuterons de la conception d'une application de triage automatisé simple et de son intégration avec Communications Mining. Dans les sections suivantes, nous aborderons l' API Stream qui pilotera notre automatisation. Enfin, nous allons construire notre application basée sur la conception ici et la tester à l’aide de données pré-labellisées.

Présentation du cas d'utilisation

Nous ciblerons un cas d'utilisation typique de l'assistance par e-mail comme point de départ de notre conception :

• Une boîte aux lettres d'assistance Outlook reçoit quotidiennement un grand nombre d'e-mails de clients.
• Une équipe de tri transforme chaque e-mail en ticket d'assistance. Cela nécessite de remplir les champs du ticket avec les informations de l'e-mail (par exemple, un ID client). Chaque ticket est ensuite ajouté à la file d'attente de workflow appropriée.
• Les tickets dans les files d'attente du workflow sont traités en continu par une équipe d'assistance à la clientèle.
  Graphique 3. Un cas d'utilisation simple de l'assistance par e-mail
  

  

  
  

Il existe deux opportunités d’automatisation ici : l’étape de triage et l’étape de traitement. Ce didacticiel montrera comment automatiser l'étape de triage en utilisant Communications Mining pour extraire les champs requis de l'e-mail, puis en affectant l'e-mail à une file d'attente de workflow.

Remarque : bien que l'étape de traitement ne soit pas mentionnée dans ce didacticiel, elle repose sur les données collectées lors de l'étape de triage. Vous avez donc la possibilité de l'ajouter après avoir créé l'exemple d'application de triage.

Conception de bout en bout

Jetons un œil au diagramme ci-dessous, qui illustre la conception de bout en bout que nous allons construire :

Figure 4. Conception d'automatisation de bout en bout.

Grâce à la connexion en direct entre le serveur Exchange et Communications Mining, Communications Mining peut servir de source de données pour votre application. De cette façon, une connexion distincte entre votre application et le serveur Exchange n'est pas nécessaire. Votre application interrogera en continu Communications Mining à la recherche de nouveaux e-mails et les recevra avec leurs libellés et entités prévus. (Nous supposons qu'aucun utilisateur ne travaille directement dans la boîte de réception de la boîte aux lettres en même temps que votre application est en cours d'exécution ; sinon, vous devrez tenir compte des conflits entre les utilisateurs de votre application et de votre boîte aux lettres).

Votre application interrogera Communications Mining et, pour chaque e-mail, vérifiera si les libellés et les entités requis sont présents dans la réponse de l'API. Si oui, un ticket sera créé dans la file d'attente de workflow appropriée. Sinon, une deuxième requête API sera envoyée à Communications Mining pour marquer l'e-mail comme une exception « Pas de prédiction ». De même, il devrait exister un moyen pour les utilisateurs traitant les tickets de signaler les tickets mal classés afin que les e-mails correspondants puissent être marqués dans Communications Mining comme une exception de « prédiction erronée ». (Les deux types d'exceptions seront ensuite examinés et labellisés par le responsable du modèle afin d'améliorer les performances du modèle).

Certaines parties de la conception (affichées dans le diagramme avec un contour en pointillés) seront hors de portée pour ce tutoriel. Dans un scénario réel, ces étapes ne doivent bien sûr pas être ignorées :

• Nous utiliserons les données existantes dans la plate-forme au lieu de configurer une connexion EWS active.
• Les données sont pré-labellisées, nous n'aurons donc pas besoin de former un modèle.
• Nous ne concevrons pas de boucle de rétroaction pour les exceptions de « prédiction erronée » car la conception dépend des capacités du système où les tickets sont traités.

Ingestion de données

L'option recommandée pour obtenir des données d'e-mail dans Communications Mining consiste à utiliser le connecteur EWS Communications Mining, mais d'autres options sont également disponibles. Puisque nous utilisons des données qui se trouvent déjà dans la plate-forme, la configuration de l'ingestion de données ne fait pas partie de ce tutoriel. Pour en savoir plus sur toutes les options d'ingestion de données disponibles, cliquez ici.

Logique métier

Nous aimerions automatiser ce processus :

Une équipe de tri transforme chaque e-mail en ticket d'assistance. Cela nécessite de remplir les champs du ticket avec les informations de l'e-mail (par exemple, un ID client). Chaque ticket est ensuite ajouté à la file d'attente de workflow appropriée.

Pour les besoins de ce tutoriel, supposons que nos files d'attente de workflow sont « Renewal », « Cancellation », « Admin » et « Urgent ». Les e-mails concernant les tâches de renouvellement, d'annulation et d'administration (par ex. les changements d'adresse) sont censés être placés dans les files d'attente respectives, tandis que tous les e-mails urgents doivent être mis dans la file d'attente « Urgent », quel que soit le sujet.

Supposons également que chaque e-mail puisse contenir un ID client (soit dans l'objet, soit dans le corps de l'e-mail). L'ID client doit être extrait afin qu'il puisse être utilisé lors de la création d'un ticket à partir de l'e-mail. Mais comme les clients oublient parfois d'inclure l'ID de client, nous voulons rendre ce champ facultatif afin qu'un ticket puisse être créé même si aucun ID de client n'est présent.

Figure 5. Commentaire révisé avec le libellé « Annulation » attribué et l'entité « ID client » extraite

Afin de pouvoir catégoriser les e-mails dans les quatre files d'attente de workflow, le modèle a été entraîné pour prédire les libellés « Renewal », « Annulation », « Admin » et « Urgent ». Pour extraire l'ID client, une entité « ID client » a été configurée. (Communications Mining est livré avec de nombreux types d'entités pré-construits ; d'autres types d'entités peuvent être ajoutés en fonction des besoins de votre intégration spécifique. Vous pouvez voir une liste des entités actuellement disponibles ici, et en savoir plus sur la demande de nouveaux types d'entités ici.

Nous pouvons maintenant fournir un mappage entre le ou les libellés prévus reçus de Communications Mining et la file d'attente du workflow dans laquelle l'e-mail doit être dirigé :

IF number of labels == 0 THEN put email into "Uncategorised" queue
IF one of labels is "Urgent" THEN put email into "Urgent" queue
ELSE
    IF number of labels == 1 THEN put email into the respective queue
    ELSE put email into "Uncategorised" queue

Nous avons fait quelques choix pour les besoins du tutoriel :

• En plus des quatre files d'attente de workflow existantes, il existe une file d'attente spéciale « Non catégorisée ». Si le modèle n'est pas en mesure de fournir de prédiction, nous y plaçons l'e-mail pour qu'il soit traité manuellement. Alternativement, nous aurions pu choisir une file d'attente existante qui devrait traiter tous les e-mails non catégorisés, par exemple "Admin".
• Si un e-mail a plus d'un libellé dans l'ensemble de ["Renewal", "Cancellation", "Admin"], cela signifie qu'il contient plusieurs requêtes. Nous choisissons de mettre ces e-mails dans la file d'attente « Non catégorisé », peut-être parce que nous ne prévoyons pas en recevoir beaucoup. Alternativement, nous aurions pu créer une file d'attente de « Requêtes complexes ».

Dans un scénario réel, vous devez baser ces décisions sur les exigences spécifiques de votre cas d'utilisation.

Entraînement du modèle

Pour interroger un modèle pour des prédictions, vous devez bien sûr disposer d'un modèle entraîné. Un modèle est entraîné en labellisant certaines des données que vous avez ingérées. Étant donné que plusieurs heures de labellisation sont nécessaires pour produire un modèle qui fonctionne bien, nous utiliserons des données pré-labellisées dans ce tutoriel afin que vous n'ayez pas besoin d'entraîner votre propre modèle.

Dans un scénario réel, un entraîneur de modèle doit avoir une bonne connaissance du domaine des données. Par exemple, l'utilisateur d'une boîte aux lettres d'assistance serait un bon entraîneur de modèle pour labelliser les données provenant de cette boîte aux lettres. L’entraînement doit être effectué avec soin afin de produire un modèle qui fonctionne bien et qui n’est pas biaisé. À cette fin, Communications Mining fournit des ressources de formation et propose des sessions de formation pratiques.

Gestion des exceptions

Même un modèle performant fournira parfois des résultats incorrects, soit en échouant à prédire un libellé, soit en prédisant le mauvais libellé. L'une des meilleures façons d'améliorer le modèle est de labelliser les e-mails sur lesquels le modèle n'est pas performant. C'est pourquoi nous voulons avoir une boucle de rétroaction pour ces e-mails :

Pour chaque e-mail, votre application vérifie si les libellés et les entités requis sont présents. Si oui, il crée un ticket dans la file d'attente de workflow appropriée. Sinon, une deuxième requête API est envoyée à Communications Mining pour marquer l'e-mail comme une exception « Pas de prédiction ». De même, il devrait exister un moyen pour les utilisateurs traitant les tickets de signaler les tickets mal classés afin que les e-mails correspondants puissent être marqués dans Communications Mining comme une exception de « prédiction erronée ».

Notre conception affiche des boucles de rétroaction pour les deux types d'exceptions.

Systèmes en aval

Notre conception affiche les files d'attente de workflow de manière abstraite. En réalité, vous pouvez transférer les e-mails directement vers une plate-forme CRM, utiliser un courtier de messages tel que Cafka, ou même simplement déplacer les e-mails du dossier de la boîte de réception vers un sous-dossier. Pour les besoins de ce tutoriel, nous allons simuler les files d'attente, mais vous êtes encouragé à développer votre intégration de test de bout en bout.

Comprendre l'API de flux

Afin de récupérer les e-mails entrants avec des libellés prédits et des entités extraites, nous utiliserons l'API de flux (Stream API). L' API de flux (Stream API) vous permet de définir un flux de commentaires basé sur un jeu de données, une version de modèle épinglée et des filtres de commentaires facultatifs, et de les parcourir de manière avec état.

Chaque résultat de la réponse au flux contiendra un commentaire, une liste de libellés prédits et une liste d'entités. Cela est passé en tant que structure JSON comme indiqué ci-dessous :

{
"comment": {...},
"entities": [...],
"labels": [...],
    ...
}

La section suivante explique comment interpréter correctement les libellés prédits dans chaque réponse de flux.

Scores de seuils de confiance

Score de confiance

Le point de terminaison Stream renverra les libellés prédits avec un score de confiance (un nombre entre 0 et 1). Par exemple, l'extrait ci-dessous concerne les prédictions de "Cancellation" et "Admin" avec des confiances d'environ 0,84 et 0,02 respectivement :

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Afin d'interpréter correctement un tel résultat, vous devez déterminer le score de confiance minimum à partir duquel vous traiterez la prédiction comme indiquant « oui, l'étiquette s'applique ». Nous appelons ce numéro le seuil du score de confiance.

Précision et rappel

Pour comprendre les seuils de confiance, vous devez connaître les termes précision et rappel. Vous pouvez trouver une explication de ces conditions sur nos pages d'assistance. En bref, une précision élevée est associée à un faible taux de faux positifs (c'est-à-dire vos résultats ont plus de chances d'être exacts), et un rappel élevé est associé à un faible taux de faux négatifs vous êtes moins susceptible de manquer des résultats pertinents).

Seuil de confiance

Le seuil de confiance d'un libellé correspond à un compromis précision-vs-rappel spécifique. À moins que votre modèle ne fonctionne parfaitement, avoir une haute précision nuira à un certain rappel, et, inversement, avoir un rappel élevé nuira à une certaine précision. Ces compromis sont visualisés sous la forme d'une courbe de rappel de précision pour chaque libellé sur la page Validation.

Figure 6. Courge de précision-rappel d'un libellé

À l'aide du curseur interactif, vous pouvez rapidement trouver le seuil souhaité : déplacez le curseur vers la droite pour optimiser la précision, ou vers la gauche pour optimiser le rappel, jusqu'à ce que vous trouviez la précision et le rappel qui correspondent aux besoins de votre application. La valeur de seuil affichée sera votre seuil souhaité. Si vous voulez en savoir plus sur la fonctionnalité de page de validation, veuillez consulter les pages d'assistance.

Remarque :

Si vous parcourez la page Validation, vous remarquerez peut-être que les formes des courbes de rappel de précision sont différentes pour chaque libellé. Cela vous donne un indice sur la façon dont nous allons sélectionner les seuils : nous choisirons un seuil individuel pour chaque libellé. Ceci est particulièrement important dans les applications d'automatisation où les meilleures performances doivent être garantie.

Exemples de seuils

Pour notre exemple d'application, nous choisirons un compromis précision-vs-rappel pour nos libellés « Renouvellement », « Annulation » et « Administrateur » (Admin), et optimiserons le rappel du libellé « Urgent » (pour que nous soyons moins susceptibles de manquez des e-mails urgents). (Notez qu'en raison des améliorations continues des performances ML sous-jacentes, au moment où vous suivez ce tutoriel, les valeurs de précision et de rappel au seuil choisi peuvent être légèrement différentes de ce qui est indiqué ici.)

Figure 7. Précision et rappel du libellé administrateur

Figure 8. Précision et rappel du libellé d'annulation

Figure 9. Précision et rappel du libellé de renouvellement

Graphique 10. Précision et rappel du libellé d'urgence

Nous utiliserons les valeurs de seuil suivantes pour le reste du tutoriel.

Admin: 0.898 (corresponds to 100% precision at 100% recall)
Cancellation: 0.619 (corresponds to 100% precision at 100% recall)
Renewal: 0.702 (corresponds to 100% precision at 100% recall)
Urgent: 0.179 (corresponds to 83% precision at 100% recall)

Nous pouvons maintenant appliquer les seuils à notre exemple. Le libellé « Annulation » s’applique depuis le 0.8374786376953125 > 0.619. Le libellé « Administrateur » ne s’applique pas depuis le 0.0164003014564514 < 0.898.

"labels": [
{
"name": ["Cancellation"],
"probability": 0.8374786376953125
},
{
"name": ["Admin"],
"probability": 0.0164003014564514
}
]

Pour faciliter ce processus, l'API Streams vous permet de spécifier vos seuils de libellé dans la configuration du flux. Si spécifié, seuls les libellés dont la valeur est supérieure à son seuil sont renvoyés.

Dans un scénario réel, les performances de rappel de précision de la cible seront déterminées par la combinaison des exigences de l'entreprise et des performances du modèle historique. Par exemple, si une étiquette a historiquement atteint une précision de 85 % avec un rappel de 55 %, vous pouvez décider d'investir plus de temps pour l'entraîner jusqu'à une précision de 90 % avec un rappel de 55 %. Vous épinglerez ensuite la nouvelle version du modèle, choisirez de nouveaux seuils et mettrez à jour la configuration de votre application.

Créer votre application

Après avoir finalisé notre conception, nous sommes prêts à commencer à construire notre application.

Épingler votre modèle

Accédez à la page Modèles (Models) et épinglez le modèle en cliquant sur le bouton Enregistrer (Save). Une fois le modèle épinglé, vous pouvez commencer à y accéder via l'API.

Remarque :

Si vous souhaitez suivre cette partie du didacticiel avec un ensemble de données labellisé différent, vous devez vous assurer qu'il est suffisamment labellisé. En particulier, un ensemble de données avec seulement quelques exemples labellisés produira un modèle qui ne renverra pas de prédictions pour la majorité des commentaires.

Graphique 11. Épinglez la version du modèle en cliquant sur le bouton Enregistrer (Save)

Configuration du flux

Dans la plupart des cas, il suffit de spécifier le nom du flux, le nom de l'ensemble de données, la version du modèle, ainsi que les libellés qui vous intéressent. Pour une liste complète des options, consultez la référence de l' API de flux .

Pour chaque libellé, vous devez spécifier un seuil. Consultez la section précédente de ce tutoriel sur la façon de choisir les seuils de libellés.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "stream": {
        "name": "<my-stream-name>",
        "model": {
          "version": <my-model-version>,
          "label_thresholds": [
            {
              "name": [
                "Parent Label",
                "Child Label"
              ],
              "threshold": <my-label-threshold>
            },
            {
              "name": [
                "Label Without Parent"
              ],
              "threshold": <my-label-threshold>
            }
          ]
        }
      }
    }'

Boucle de récupération et d'avance

Vous pouvez maintenant utiliser votre flux pour récupérer les commentaires de Communications Mining. Notez que des tailles de lot très faibles (telles que la récupération par lots de 1 commentaire) auront un impact sur la vitesse à laquelle les commentaires sont récupérés.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/fetch' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "size": <my-stream-batch-size>
    }'

La position initiale du flux est définie sur son heure de création. À des fins de développement, il est souvent utile de récupérer les commentaires qui ont été créés avant le flux. Pour ce faire, vous pouvez définir le flux sur un horodatage spécifique.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/reset' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "to_comment_created_at": "<YYYY-MM-DDTHH:MM:SS>"
    }'

Si vous réexécutez la requête fetch maintenant, elle partira de la même position. Afin de récupérer le prochain lot de commentaires, vous devez reconnaître le lot précédent avec une requête advance . Dans la requête advance , vous devez fournir un sequence_id que vous pouvez trouver dans votre réponse fetch .

La boucle de récupération et d'avance garantit que vous n'ignorerez pas accidentellement les commentaires si votre application échoue lors du traitement. Notez que votre application doit être capable de gérer le fait de voir un commentaire plusieurs fois en cas de traitement réussi d'un commentaire, mais d'échec à l'étape avancée.

curl -X POST 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/advance' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "sequence_id": "<my-sequence-id>"
    }'

Notez que vous devez fournir le nom de l'ensemble de données dans toutes les requêtes d'API utilisant le flux - c'est parce que les flux sont inclus dans les ensembles de données.

Résultats du processus

La réponse contiendra des commentaires ainsi que des libellés et des entités prédits, comme décrit dans les pages Commentaires ( Comments ) et Libellés (Labels) et Entités (Entities). Veuillez consulter ces pages pour comprendre comment analyser la réponse.

Gestion des exceptions

Si votre application permet aux utilisateurs de baliser les éléments qui ont été prédits de manière incorrecte, vous pouvez utiliser le point de terminaison d'exception pour baliser le commentaire correspondant comme une exception dans la plate-forme. Le nom de l'exception sera disponible en tant que filtre dans l'ensemble de données, afin qu'un entraîneur de modèle puisse examiner et étiqueter les exceptions pour améliorer le modèle.

curl -X PUT 'https://<my_api_endpoint>/api/v1/datasets/<my-project>/<my-dataset>/streams/<my-stream-name>/exceptions' \
    -H "Authorization: Bearer $REINFER_TOKEN" \
    -H "Content-Type: application/json" \
    -d '{
      "exceptions": [
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        },
        {
          "metadata": {
            "type": "Wrong Prediction"
          },
          "uid": "<comment-uid>"
        }
      ]
    }'

Terminé !

Félicitations, vous avez terminé le tutoriel d’automatisation de Communications Mining. Bien sûr, votre propre application d'automatisation peut être différente de celle présentée ici. Veuillez contacter l’assistance si vous avez des questions.