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 Communications Mining. Dans ces cas, une solution courante consiste à indexer les prédictions Communications Mining et toute donnée supplémentaire 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

First, let's define the data that we want to import into Elasticsearch. Communications Mining™ API provides the comment text, comment metadata, predicted labels and predicted general fields in a nested JSON object. The following is an example of a raw comment provided by the Communications Mining API.

Note: You may notice different metadata fields depending on how your data was ingested into Communications Mining. To learn more about comment object fields, check Comments.

{
  "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
      }
    }
  ]
}

The schema of the raw comments returned by the Communications Mining API is inconvenient for filtering and querying this data in Elasticsearch, so you should change the schema before ingesting the data into Elasticsearch. The following is an example flattened schema you can use. You should add all fields that you need for your use-case.

{
  "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

In order to fetch the data, we recommend using the . For an overview of all available data download methods, check Downloading data. When creating a Stream, you should set the thresholds for each label so that labels with confidence scores below the threshold are discarded. This is easiest to do from the Communications Mining™ UI by going to the "Streams" page of a dataset. Having used the confidence scores to determine whether a label applies, you can then import just the label names into Elasticsearch. For a discussion on when we recommend dropping or keeping label confidence scores, check Labels for Analytics.

Les champs généraux n’ont pas de scores de confiance, donc aucune gestion spéciale n’est 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 garantir que les analyses utilisant des prédictions restent cohérentes, vous devez réingérer les prédictions pour les données historiques à l’aide de la version mise à jour du modèle. Vous pouvez le faire en ajoutant le flux vers 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

This bar chart shows the top 20 sender email addresses in the dataset. Sender and recipient email addresses are part of comment metadata in email-based datasets.

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).