- Documents d’API
- CLI
- Guides d'intégration
- Blog
- Comment les machines apprennent à comprendre les mots : guide des intégrations dans NLP
- Apprentissage basé sur des invites avec des Transformers
- Efficient Transformers II : Dilarification des connaissances et ajustements de précision
- Transformateurs efficaces I : mécanismes d'attention
- Modélisation de l'intention hiérarchique non supervisée : obtenir de la valeur sans données d'entraînement
- Corriger le biais de labellisation avec Communications Mining
- Active Learning : de meilleurs modèles d'ML en moins de temps
- Tout est dans les chiffres – Évaluation des performances du modèle avec des métriques
- Pourquoi la validation du modèle est importante
- Comparaison de Communications Mining et de Google AutoML pour les renseignements sur les données conversationnelles
![](https://docs.uipath.com/_next/static/media/grid.05ebd128.png?w=3840&q=100)
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.
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 entités prédites 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": "CPX8460080@broker.com",
"to": ["underwriter@insurer.com"],
"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
}
}
]
}
{
"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": "CPX8460080@broker.com",
"to": ["underwriter@insurer.com"],
"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"]
}
}
{
"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"]
}
}
labels
doit être un tableau. De plus, si un ou plusieurs types d'entités ont été configurés pour l'ensemble de données, un commentaire contiendra zéro, une ou plusieurs entités de chaque type d'entité. 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"
).
Pour récupérer les données, nous vous recommandons d'utiliser l' API de flux (Stream API). (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 les seuils de chaque libellé afin que les libellés avec des scores de confiance inférieurs au seuil soient ignorés. C'est le plus facile à faire à partir de l'interface utilisateur de Communications Mining en accédant à la page Flux (Streams) 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 les analyses ( Labels for Analytics ) pour savoir quand nous recommandons de supprimer ou de conserver les scores de confiance des libellés.)
Les entités n’ont pas de scores de confiance, aucune gestion spéciale n’est donc requise.
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 mettre à 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 la cohérence des analyses à l'aide de prédictions, vous devez réingérer les prédictions pour les données historiques à l'aide de la version de modèle mise à jour. Vous pouvez le faire en réinitialisant le flux à l'horodatage avant votre commentaire le plus ancien et en réingérant les données depuis le début.
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:(.+) > .*")
.es(index=example-data,split=labels:5,timefield=@timestamp)
.label("$1", "^.* > labels:(.+) > .*")
Graphique à barres
Graphique à secteurs