Intégration d'Elasticsearch

Communications Mining propose un riche ensemble d'outils d'analyse intégrés. Cependant, il est parfois nécessaire de joindre les prédictions de Communications Mining avec des données qui ne peuvent pas être téléchargées dans le cadre des commentaires de Communications Mining. Dans ces cas, une solution courante consiste à indexer les prédictions de Communications Mining et toutes les données supplémentaires dans Elasticsearch et à utiliser un outil comme Kibana pour générer des analyses. Ce tutoriel explique comment importer des données Communications Mining dans Elasticsearch et les visualiser dans Kibana.

Les données utilisées dans les exemples de ce tutoriel sont des e-mails factices générés à partir du domaine de l’assurance.

Stockage des données dans Elasticsearch

Tout d'abord, définissons les données que nous voulons importer dans Elasticsearch. L'API Communications Mining fournit le texte de commentaire, les métadonnées de commentaire, les libellés prédits et les champs généraux prédits dans un objet JSON imbriqué. Vous trouverez ci-dessous un exemple de commentaire brut fourni par l'API Communications Mining. (Notez que vous pouvez voir différents champs de métadonnées selon la façon dont vos données ont été ingérées dans Communications Mining. Vous pouvez en savoir plus sur les champs d'objet de commentaire ici.)

{
  "comment": {
    "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
    "timestamp": "2021-03-29T08:36:25.607Z",
    "messages": [
      {
        "body": {
          "text": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL"
        },
        "subject": {
          "text": "Change of address - Policy SFG48807871"
        },
        "from": "[e-mail]",
        "to": ["[e-mail]"],
        "sent_at": "2021-03-29T08:36:25.607Z"
      }
    ]
    // (... more properties ...)
  },
  "labels": [
    {
      "name": ["Admin"],
      "probability": 0.9995054006576538
    },
    {
      "name": ["Admin", "Change of address"],
      "probability": 0.9995054006576538
    }
  ],
  "entities": [
    {
      "name": "address-line-1",
      "formatted_value": "19 Essex Gardens",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 63,
        "char_end": 79,
        "utf16_byte_start": 126,
        "utf16_byte_end": 158
      }
    },
    {
      "name": "post-code",
      "formatted_value": "SW17 2UL",
      "span": {
        "content_part": "body",
        "message_index": 0,
        "char_start": 81,
        "char_end": 89,
        "utf16_byte_start": 162,
        "utf16_byte_end": 178
      }
    },
    {
      "name": "policy-number",
      "formatted_value": "SFG48807871",
      "span": {
        "content_part": "subject",
        "message_index": 0,
        "char_start": 27,
        "char_end": 38,
        "utf16_byte_start": 54,
        "utf16_byte_end": 76
      }
    }
  ]
}

Le schéma des commentaires bruts renvoyés par l'API Communications Mining n'est pas pratique pour le filtrage et la requête de ces données dans Elasticsearch. Vous devez donc modifier le schéma avant d'ingérer les données dans Elasticsearch. Vous trouverez ci-dessous un exemple de schéma aplati que vous pouvez utiliser. Vous devez ajouter tous les champs nécessaires à votre cas d'utilisation.

{
  "id": "c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "uid": "49ba2c56a945386c.c7a1c529-3f57-4be6-9102-c9f892b81ae51",
  "timestamp": "2021-03-29T08:36:25.607Z",
  "subject": "Change of address - Policy SFG48807871",
  "body": "The policyholder has changed their address to the new address: 19 Essex Gardens, SW17 2UL",
  // (... more fields ...)
  "labels": ["Admin", "Admin > Change of address"],
  "entities": {
    "policy_number": ["SFG48807871"],
    "address-line-1": ["19 Essex Gardens"],
    "post-code": ["SW17 2UL"]
  }
}

Notez qu'un commentaire peut avoir zéro, un ou plusieurs libellés. Par conséquent, le champ labels doit être un tableau. De plus, si un ou plusieurs types de champs généraux ont été configurés pour l'ensemble de données, un commentaire contiendra zéro, un ou plusieurs champs généraux de chaque type de champ général. Les noms de libellés hiérarchiques dans la réponse API brute sont eux-mêmes des tableaux (["Admin", "Change of address"]). Ils doivent être convertis en chaînes ("Admin > Change of address").

Récupérer des données

Pour récupérer les données, nous vous recommandons d'utiliser l' . (Voir ici pour un aperçu de toutes les méthodes de téléchargement de données disponibles.) Lors de la création d'un flux, vous devez définir des seuils pour chaque libellé afin que les libellés avec des scores de confiance inférieurs au seuil soient rejetés. C'est le plus simple à partir de l'interface utilisateur de Communications Mining en accédant à la page « Flux » d'un ensemble de données. Après avoir utilisé les scores de confiance pour déterminer si un libellé s'applique, vous pouvez ensuite importer uniquement les noms de libellés dans Elasticsearch. (Consultez la section Libellés pour l'analyse des libellés pour analyser le moment auquel nous recommandons de supprimer ou de conserver les scores de confiance des libellés.)

Les champs généraux n’ont pas de scores de confiance, aucune gestion spéciale n’est donc requise.

Remarque :

Gestion du changement de modèle

Lors de la création d'un flux, vous spécifiez une version de modèle. Cette version de modèle est utilisée pour fournir des prédictions lors de la récupération de commentaires à partir du flux. Même si les utilisateurs continuent d'entraîner de nouvelles versions de modèle sur la plate-forme, votre flux utilisera la version de modèle que vous avez spécifiée, vous fournissant des résultats déterminiques.

Pour effectuer une mise à niveau vers une nouvelle version de modèle, vous devez créer un nouveau flux qui utilise cette version de modèle, puis mettre à jour votre code pour utiliser le nouveau flux. (Pour cette raison, nous vous recommandons de rendre le nom du flux configurable dans votre code.) Pour vous assurer que les analyses à l'aide de prédictions restent cohérentes, vous devez réingérer les prédictions pour les données historiques à l'aide de la version de modèle mise à jour. Pour ce faire, ajoutez le Stream à l’horodatage avant votre commentaire le plus ancien et en réingérant les données dès le début.

Visualisation des données dans Kibana

Une fois que vous avez indexé les données dans Elasticsearch, vous pouvez commencer à créer des visualisations. Cette section fournit des exemples simples pour un certain nombre d'outils de visualisation courants dans Kibana.

Minuterie

Vous pouvez utiliser l'expression suivante pour produire un graphique des 5 libellés les plus courants au fil du temps. Notez que cela affiche à la fois les libellés de catégorie et de sous-catégorie de niveau supérieur.

.es(index=example-data,split=labels:5,timefield=@timestamp)
    .label("$1", "^.* > labels:(.+) > .*")

Figure 1.. Les 5 premiers libellés d'un ensemble de données tracés sur une certaine durée.

Graphique à barres

Ce graphique à barres affiche les 20 premières adresses e-mail d'expéditeurs dans le jeu de données. Les adresses e-mail de l’expéditeur et du destinataire font partie des métadonnées de commentaire dans les ensembles de données basés sur les e-mails.

Figure 2. Top 20 des adresses e-mail d'expéditeurs.

Graphique à secteurs

Ce graphique à secteurs affiche les libellés de sous-catégorie sous le libellé de niveau supérieur « Claim ». Les catégories de libellés sont définies par l’utilisateur qui entraîne le modèle.

Figure 3. Sous-catégories du libellé Revendication (Claim).