Quoi de neuf au sujet de la résolution d’entité dans MindMeld ?

Introduction

La résolution d’entités (ER, Entity resolution) est le processus de désambiguïsation d’une entité. Il consiste à mapper une mention textuelle vers le nom réel le plus approprié présent dans une base de connaissances de référence (KB, knowledge base). Il permet, par exemple, de résoudre `madrid fc` en `Real Madrid Club de Fútbol`, le premier élément étant une des paraphrases du second élément. La résolution d’entités est souvent désignée par d’autres termes, tels que « correspondance d’entités », « liaison référentielle d’entités », « liaison d’enregistrements » ou « déduplication d’enregistrements ». La résolution d’entités est disponible dans le cadre du Pipeline NLP de MindMeld et permet de désambiguïser toutes les entités identifiées dans les données entrées par un utilisateur, en les mettant en correspondance avec une base de connaissances préremplie. Reportez-vous à la documentation officielle pour découvrir comment créer une base de connaissances pour un résolveur d’entités et l’utiliser durant la création d’une application MindMeld. Jusqu’à récemment, MindMeld proposait deux possibilités pour la résolution d’entités : une basée sur le moteur de recherche et d’analyse de texte intégral Elasticsearch, et une autre basé sur un algorithme simple de correspondance exacte comme option de remplacement. Avec la diversification croissante des applications de MindMeld, il est possible que ces options ne soient pas toujours envisageables. Afin d’offrir une prise en charge étendue, MindMeld propose désormais deux options additionnelles : une basée sur TF-IDF, et une autre reposant sur des représentations de modèles neuronaux pré-entraînés (BERT, GloVe, fastText etc.). Il est important de noter que ces nouvelles options ne présentent aucune dépendance avec Elasticsearch (et ses services). Avant de les examiner plus en détail, nous allons résumer brièvement comment une base de connaissances d’entités est structurée dans MindMeld. L’exemple suivant s’appuie sur le plan Food Ordering avec la base de connaissances créée pour désambiguïser des noms de produits alimentaires :   Comme on peut l’observer, le champ `cname` (nom canonique) et le champ `whitelist` fournissent des exemples d’usages courants pour chaque produit alimentaire, tandis que le champ `id` répertorie un enregistrement unique reconnu officiellement dans la base de connaissances. Ces trois champs constituent principalement un objet d’entité dans la base de connaissances. Le texte figurant dans le champ `cname` est généralement utilisé dans des réponses conversationnelles, alors que les termes figurant dans le champ `whitelist`, ainsi que le nom canonique, servent d’alias lors de la désambiguïsation. Les meilleurs résultats d’un résolveur d’entités sont souvent obtenus lorsque le champ `whitelist` est rempli de manière exhaustive (ex., en incluant les termes alternatifs, les erreurs d’orthographe, les formes abrégées, etc.). Ce type de sélection peut se révéler fastidieux dans certaines applications, mais il s’agit d’un processus inévitable lors du traitement d’entités dans un domaine hautement spécialisé.

En savoir plus sur les résolveurs nouvellement ajoutés

Dans les résolveurs n’utilisant pas la correspondance exacte, la première étape consiste à obtenir une représentation vectorielle du texte d’entrée à désambiguïser, ainsi que pour toutes les entrées de la base de connaissances (champs cnames et whitelists) utilisés comme alias pour la désambiguïsation. Les alias sont ensuite évalués et classés au moyen d’une sorte de mise en correspondance de vecteurs de similarités (ex., similarité cosinus). Avec les nouvelles options de résolution d’entités, le résolveur basé sur TF-IDF sélectionne différentes caractéristiques n-grammes (c’est-à-dire, des caractéristiques textuelles de surface) avant de calculer des similarités cosinus sur les vecteurs creux. De leur côté, les résolveurs basés sur un embeddeur pré-entraîné assurent la mise en correspondance au moyen de similarités cosinus sur des représentations vectorielles denses de texte. Le recours à des embeddeurs pré-entraînés pour la résolution d’entités présente certains avantages par rapport aux autres approches. Ils offrent par exemple une compréhension sémantique du texte sans nécessiter le remplissage exhaustif de listes blanches (ex., `performances inférieures aux attentes` équivaut à `performances insuffisantes`) et permettent une transition facile vers la mise en correspondance d’entités multilingues (ex., déduire que `tercio` en espagnol est identique à `troisième` en français). Cependant, les embeddeurs pré-entraînés sont désavantagés par des écarts entre le pré-entraînement et l’inférence, tels que des différences de longueur des textes d’entrée. De plus, les délais d’inférence des modèles basés sur des embeddeurs peuvent être supérieurs à ceux des autres résolveurs en raison des calculs vectoriels denses sous-jacents. Cependant, lorsqu’ils sont ajustés de façon appropriée, les modèles basés sur des embeddeurs peuvent surpasser les autres résolveurs basés principalement sur des caractéristiques textuelles de surface. L’analyse ci-dessous compare des résolveurs basés sur un embeddeur pré-entraîné à des résolveurs d’entités Elasticsearch et TF-IDF. Les ensembles de données sélectionnés pour cette comparaison impliquent des mises en correspondance de caractéristiques textuelles de surface ainsi que des mises en correspondance sémantiques.

Performances de différents résolveurs

Les résultats suivants présentent les performances moyennes de différents résolveurs d’entités en matière de correspondance de chaînes de texte courtes dans le cadre d’une expérimentation avec différents ensembles de données sélectionnés en interne. Le meilleur score de récupération est indiqué ici en tant que mesure de l’exactitude :   Les variantes BERT pré-entraînées sont disponibles dans le cadre des transformateurs de phrases Huggingface, et le graphique présente les scores des 5 meilleures variantes uniquement. Les performances des modèles à plongement lexical pré-entraînés, tels que fastText, sont généralement inférieures à celles des modèles basés sur des embeddeurs BERT ou des résolveurs basés sur TF-IDF. La faiblesse de ces performances peut être attribuée au décalage de domaine et à l’absence d’ajustement. Une analyse plus approfondie utilisant différentes configurations des meilleures variantes BERT (‘distilbert-base-nli-stsb-mean-tokens’) produit les résultats suivants :   Les résultats montrent que des scores de similarité alternatifs tels que BERTScore ne sont pas compétitifs. De plus, l’utilisation de similarités cosinus pour concaténer différentes couches du modèle BERT génère des gains de performances correspondant aux performances d’Elasticsearch. Il s’agit d’un constat intuitif, car différentes couches du modèle BERT peuvent capturer des informations complémentaires. Même après avoir quantifié la réduction des exigences en mémoire et de la complexité temporelle du modèle BERT, la dégradation des performances s’élève à 2 à 3 % seulement. Par ailleurs, lorsqu’il est évalué avec des données bruitées de manière aléatoire contenant des fautes d’orthographe dans le texte d’entrée, le résolveur basé sur TF-IDF offre des performances supérieures aux autres. Ce résultat peut être dû à l’ensemble diversifié de caractéristiques n-grammes capturées par ce résolveur. (Pour cette expérimentation, les textes en liste blanche sont réutilisés en tant qu’instances de test, et les fautes d’orthographe sont induites dans celles-ci. De ce fait, avec un bruit de 0 %, une exactitude de 100 % est observée car toutes les entités de test sont également présentes dans les listes blanches.)   Enfin, le dernier graphique illustre les différences de complexités temporelles d’inférence entre les différents résolveurs :   (De gauche à droite : résolveurs BERT, TF-IDF et Elasticsearch offrant les plus hauts niveaux d’exactitude) Délai d’inférence par entité mesuré avec des bases de connaissances de différentes tailles. L’axe X présente la taille de la base de connaissances, tandis que l’axe Y correspond au délai par entité en millisecondes. Les zones en jaune illustrent le délai d’inférence requis pour l’encodage du texte d’entrée, tandis que les zones en vert représentent le délai d’inférence nécessaire aux calculs de similarité. Les complexités temporelles de TF-IDF et Elasticsearch sont assez comparables, alors que la meilleure variante BERT, même quantifiée, est 20 fois plus lente. Ce délai est 10 fois plus long seulement lorsque les 4 meilleures couches ne sont pas concaténées, mais une diminution de l’exactitude est alors observée.

Sélection et configuration d’un résolveur d’entités

Les configurations de résolveur d’entités MindMeld fournissent différents paramètres configurables selon le résolveur utilisé. L’extrait de code suivant, lorsqu’il est intégré au module `config.py` d’une application, utilise un modèle BERT pré-entraîné de votre choix de Huggingface : ENTITY_RESOLVER_CONFIG = {     ’model_type’: ’resolver’,     ’model_settings’: {         ’resolver_type’: ’sbert_cosine_similarity’,         ’pretrained_name_or_abspath’: ’distilbert-base-nli-stsb-mean-tokens’,         …     } } Vous pouvez utiliser d’autres modèles d’embeddeurs en modifiant le paramètre `embedder_type` : ENTITY_RESOLVER_CONFIG = {     ’model_type’: ’resolver’,     ’model_settings’: {         ’resolver_type’: ’embedder_cosine_similarity’,         ’embedder_type’: ’glove’,        …     } } Vous pouvez également spécifier des configurations d’environnement d’exécution telles que `batch_size` lorsque vous utilisez un modèle d’embeddeur, ainsi que des configurations spécifiques au modèle d’embeddeur. Pour charger un résolveur basé sur TF-IDF, vous pouvez procéder comme suit : ENTITY_RESOLVER_CONFIG = {     ’model_type’: ’resolver’,     ’model_settings’: {         ’resolver_type’: ’tfidf_cosine_similarity’,         …     } } Pour chaque objet d’entité dans la base de connaissances, des représentations vectorielles continues spéciales, qui correspondent au pool moyen/maximum des représentations vectorielles continues de tous les alias, sont également calculées et utilisées à des fins de résolution si elles sont configurées. Ces représentations vectorielles continues améliorent souvent l’exactitude des résolveurs avec une augmentation seulement minime des coûts de calcul. Pour consulter des informations détaillées, ainsi que toutes les configurations possibles, reportez-vous à la section « Configurations » de la documentation officielle.

Conclusions et développements futurs

De manière générale, il est conseillé d’utiliser le résolveur basé sur Elasticsearch, sauf si un scénario particulier l’interdit. En remplacement, utilisez des résolveurs basés sur un modèle d’embeddeur lorsqu’une correspondance plus sémantique est requise, ou un résolveur basé sur TF-IDF si une telle exigence ne s’applique pas. Le module de résolution d’entités de MindMeld ne fournit pas encore d’API pour évaluer le résolveur le plus adapté à votre application. Suivez-nous, car nous prévoyons d’ajouter cette capacité, ainsi que des méthodes pour ajuster les résolveurs basés sur un modèle d’embeddeur.   Inscrivez-vous à Webex Accédez à notre page d’accueil ou contactez-nous directement si vous avez besoin d’aide. Cliquez ici pour en savoir plus sur les offres de Webex et créer un compte gratuit.