Désambiguïsation d'entité à l'aide du moteur de recherche

Maysam

Arrière-plan

La désambiguïsation d’entité ou la résolution de jetons mal orthographiés/ambigus a toujours été un sujet intéressant avec ses propres défis. Avec la montée en puissance des assistants numériques tels que Microsoft Cortana, Google Home, Amazon Alexa, etc. la précision globale de l’appareil est devenue importante. La qualité de la communication avec un appareil contient la capacité de comprendre l’intention de l’humain, de distinguer les entités correctes avec leur forme orthographique correcte et enfin de répondre à la demande de l’humain avec une réponse appropriée. De même, avec les défis liés aux résultats de la reconnaissance optique de caractères (OCR), les meilleurs résultats de reconnaissance ne peuvent être obtenus que si l’image source est de bonne qualité.

Défis et objectifs

Un défi commun lors du mappage d’un nom d’entité à partir d’un document (électronique ou numérisé), d’une phrase écrite ou transcrite à sa forme canonique dans un système d’enregistrement, consiste à gérer les variations d’orthographe, les fautes d’orthographe, les erreurs dues à la transcription OCR de un scan de mauvaise qualité, ou des différences dans la forme de l’entité entre une transcription du discours à la forme canonique. Ces variations nécessitent une correspondance de sous-jeton, une rupture de mot ou une collation de jetons sib pour augmenter la probabilité de correspondance lors de la recherche de la forme canonique la plus pertinente de l’entité.

Le fait d’avoir des entités mal orthographiées signifie que nous ne pourrons peut-être pas répondre à la demande vocale initiale. Par conséquent, soit nous devons résoudre les entités mal orthographiées dans leur forme correcte, avant d’essayer d’interroger une source de données, soit nous devons préparer la source de données cible pour répondre aux requêtes avec des entités mal orthographiées avec un taux de précision plus élevé.

Solution

Ce document propose une méthodologie pour lever l’ambiguïté des entités mal orthographiées en comparant les performances de récupération de recherche avec différents analyseurs de recherche personnalisés dans un moteur de recherche. Par conséquent, même si la requête fournie contient des entités mal orthographiées, le moteur de recherche peut répondre à la requête avec une précision et un rappel plus élevés que les paramètres par défaut. Cette méthode peut être appliquée à n’importe quel service de moteur de recherche capable d’ajouter des analyseurs de recherche personnalisés.

Dans ce document, nous expérimentons un scénario de synthèse vocale. Des approches similaires peuvent être appliquées à l’OCR et à tout système d’extraction d’entités machine. La solution implémentée peut être trouvée dans le référentiel EntityDisambiguation.

Approfondissement de l’architecture

Dans cette section, nous discuterons de la motivation derrière la solution proposée. Considérez un scénario de synthèse vocale dans lequel un utilisateur interagit avec un appareil et demande à passer un appel téléphonique. La figure ci-dessous indique l’architecture globale depuis le discours de l’utilisateur jusqu’à la recherche de la source de données et la réponse à la demande de l’utilisateur.

Utilisateur  : Hey appareil, appelez « JchnHeng »

Appareil  : Désolé, je ne trouve pas « JOhnHuneng »

Le discours est converti en texte, puis il sera envoyé à un service de compréhension du langage naturel tel que LUIS. Nous supposons que notre modèle LUIS (Language Understanding Intelligent Service) est bien entraîné et nous nous attendons à ce qu’il puisse identifier l’intention et extraire les entités. Il peut identifier que « l’appel JchnHeng » est une intention « d’appel » avec un score de précision de 0,88. Il peut également identifier que « JchnHeng » partie de cette requête est un « personName ». Cependant, lorsque nous interrogeons le moteur de recherche pour « JchnHeng », il est possible de ne pas récupérer cet enregistrement à partir de la source de données car ce qui existe dans l’index de recherche est « JOhnHuneng » et non « JchnHeng ».

« query » : « appeler jean hang »,

« intention » : « Appeler »,

« score » : 0.8851808

« intentions » : [

« intent » : « Call »,

« score » : 0.8851808

« intent » : « None »,

« score » : 0.07000262

],

« entités » : [

« entity » : « jean heng »,

« type » : « builtin.personName »,

« startIndex » : 5,

« endIndex » : 13

]

Exemple de réponse de LUIS. L’intention peut être identifiée avec un niveau de confiance élevé (0,88) et l’entité est un nom de personne. Cependant, comme le nom est mal orthographié, lorsque nous interrogeons notre source de données (moteur de recherche), le nom est introuvable.

Méthodologie

Cette section présente un aperçu de la méthodologie proposée pour améliorer la récupération de la recherche pour les entités mal orthographiées, à savoir personName. Différents analyseurs de recherche bénéficient de différents tokenizers et filtres de jetons. Un tokenizer divise le texte continu en une séquence de tokens, par exemple en divisant une phrase en mots, et un filtre de token est utilisé pour filtrer ou modifier les tokens générés par un tokenizer. Par conséquent, différents analyseurs de recherche peuvent se comporter différemment et leurs performances peuvent varier en fonction des noms de personnes mal orthographiés. Notre approche consiste à mesurer les performances du moteur de recherche dans la récupération du nom de la personne mal orthographié lorsque le moteur de recherche utilise des analyseurs spécifiques ou multi-recherches. Nous commençons par créer un index de recherche à l’aide de différents analyseurs de recherche. Ensuite, nous ingérerons le nom de la personne dans l’index de recherche créé.

Analyse du schéma d’index de recherche

Dans cette section, nous allons créer un schéma de recherche pour notre index de recherche. Nous avons commencé par identifier plusieurs analyseurs de recherche. Ensuite, nous identifierons les champs de l’index de recherche nécessaires à cette expérience.

Analyseurs

Un analyseur est un composant du moteur de recherche en texte intégral chargé de traiter le texte dans les chaînes de requête et les documents indexés. Différents analyseurs manipulent le texte de diverses manières selon le scénario. Par défaut, la recherche Azure utilise Standard Lucene pour l’analyse des enregistrements/documents ainsi que pour l’analyse d’une requête. Nous allons créer plusieurs analyseurs de recherche personnalisés qui, selon nous, pourraient être les meilleurs candidats pour l’expérience.

Dans la section suivante, nous allons exécuter nos expériences en envoyant une requête à l’index de recherche pour toutes les combinaisons des analyseurs de recherche créés afin de vérifier quel analyseur peut améliorer la récupération du nom. La plupart des analyseurs personnalisés bénéficient du pliage de la casse pour résoudre des termes similaires qui ont un pliage de la casse différent. De plus, ils utilisent le pliage ASCI pour convertir les caractères Unicode numériques, alphabétiques et symboliques en représentation ASCII de ce jeton. L’API REST Analyze peut être utilisée pour vérifier comment chaque analyseur analyse le texte. Dans ce document, nous avons choisi « Nom de la personne » comme entité expérimentée et nous créons des analyseurs de recherche dans la section suivante.

Dans notre expérience, nous avons utilisé les analyseurs de recherche suivants : Phonetic, Edge-N-Gram, Microsoft, Letter, CamelCase, URL-Email et default Analyzer (Standard Lucene).

Champs d’index de recherche

Maintenant que nous avons créé nos analyseurs de recherche, nous allons créer notre index de recherche. Nous allons ajouter plusieurs champs, chacun d’eux correspondant à un analyseur de recherche. Le tableau suivant représente les champs ajoutés à l’index de recherche.

Domaine

Analyseur

phonétique

analyseur-phonétique

edge_n_gram

analyseur edge-n-gram

microsoft

Fr.microsoft

lettre

analyseur de lettres

ngramme

ngram-analyseur

affaire de chameau

analyseur-de-motifs-de-chameau

provenant

analyseur-de-racines

url_email

analyseur-url-email

standard_lucene

standard.lucene

Ingestion de données

Nous avons utilisé l’ensemble de données des résultats de recherche des candidats aux élections de mi-mandat et intégré 400 noms dans l’index de recherche. Pour chaque enregistrement, un nom a été ajouté à chaque champ. Cependant, pour chaque champ, nous avons spécifié un analyseur différent. Le JSON (Java Script Object Notation) indiqué ci-dessous est le résultat d’une recherche dans l’index de recherche avec la requête  : « Jean Heng ». Les données ingérées dans l’index de recherche seront utilisées dans la section suivante pour vérifier la précision de la récupération de la recherche et le rappel pour différents analyseurs.

score » : 4.589165,

« stndard_lucene » : « Jean Heng »,

« phonétique » : « Jean Heng »,

« edge_n_gram » : « Jean Heng »,

« lettre » : « Jean Heng »,

« ngram » : « Jean Heng »,

« camelcase » : « Jean Heng »,

« steming » : « Jean Heng »,

« url_email » : « Jean Heng »,

« text_microsoft » : « Jean Heng »

Expérience

Dans la section précédente, nous avons créé un index de recherche avec 400 noms dans l’index. Dans cette section, nous allons effectuer des expériences pour mesurer le ou les analyseurs les plus performants pour le champ de nom. Nous pouvons, espérons-le, améliorer la recherche, même pour les noms mal orthographiés tels que « JOhnHuneng » nous devrions être en mesure de récupérer « JchnHeng » du moteur de recherche.

Mesurer les performances de récupération

Pour mesurer la précision de la recherche, nous devons savoir comment le moteur de recherche peut récupérer un résultat de recherche si un nom mal orthographié est transmis comme requête ; il est important pour nous que le résultat obtenu soit exact. Le tableau suivant contient les mesures de la matrice de confusion dont nous aurons besoin pour calculer les performances de recherche.

TP

VraiPositif

Étant donné qu’un nom mal orthographié est recherché,

un nom est trouvé et correspond au nom attendu.

PF

Faux positif

Étant donné qu’un nom mal orthographié est recherché,

un nom est trouvé, mais il ne correspond pas au nom attendu.

TN

Vrai négatif

Étant donné qu’un nom inexistant est recherché, aucun nom n’est trouvé.

FN

Faux négatif

Étant donné qu’un nom mal orthographié est recherché, aucun nom n’est trouvé.

Avec TP, FP, TN et FN définis, nous pouvons calculer à la fois le rappel et la précision à l’aide des formules suivantes  :

Formules de précision (en haut) et de rappel (en bas)

Étant donné que la précision et le rappel sont des facteurs cruciaux de la recherche, nous utiliserons le score F1 qui prend en compte à la fois les mesures de précision et de rappel. Le score F1 est la signification harmonique de la précision et du rappel, où un score F1 atteint sa meilleure valeur à 1 (précision et rappel parfaits) et la pire à 0. La formule suivante est la façon dont nous calculons le score F1.

Formule de score F1

Noms mal orthographiés et noms attendus

attendu}. Les 400 premiers tuples correspondaient à ceux qui existaient dans notre index de recherche. Les 50 derniers tuples n’existent pas dans notre index de recherche et seront utilisés pour avoir un impact sur les mesures TN (vraiment négatives) du test.

Générer des noms mal orthographiés

La méthode la plus précise pour générer des noms mal orthographiés consiste à utiliser les données de télémétrie19 du système avec lequel vous travaillez. Par exemple, trouvez ce qui n’a pas été correctement orthographié dans les journaux et capturez-les pour les utiliser pour l’expérience. Si vous n’avez pas accès aux données de télémétrie pour créer des noms mal orthographiés, vous pouvez utiliser l’API de synthèse vocale Azure. L’algorithme suivant illustre un organigramme sur la façon de générer un ensemble de données de noms mal orthographiés et attendus à partir d’un corpus de noms à l’aide de l’API Speech to Text.

Commencer

liste vide misspelled_nams

liste vide de expect_names

noms noms_corpus

Bien que davantage de données soient nécessaires pour l’expérience, ne

API vocale d’appel fournissant un nom à partir des noms

Si la réponse de l’API est égale au nom correct

Continuer

Autre

Insérer un nom mal orthographié dans misspelled_nams

Insérez le nom correct dans expect_names

Finir

Enfin, nous allons créer un ensemble de données de noms, comme dans le tableau ci-dessous, où les 400 premiers enregistrements de la colonne des noms attendus sont ingérés dans Azure Search (comme indiqué dans la section précédente).

#

Nom attendu

Nom mal orthographié

1

Tobye Schimpke

tobeshimpok

2

SidneyMcElree

Sidney Mc. Elrée

400

Kimmie Fridlington

Kim Fridlington

401

PAS TROUVÉ

Netta Niezen

450

PAS TROUVÉ

Aluin Donnett

Sélection de fonctionnalité

Avoir 9 champs différents, chacun d’entre eux utilisant des analyseurs différents sans tenir compte du vide ensemble, nous aurons 511 combinaisons de champs sur lesquels interroger dans notre expérience. Nous avons également   400 documents dans notre moteur de recherche. Pour couvrir tous les scénarios possibles, nous devons effectuer 400 × 511 = 204 400 appels vers la recherche Azure. Nous pouvons également utiliser l’une des techniques d’élimination des caractéristiques[5]pour accélérer le temps d’exécution des expériences. Par exemple, nous pouvons exécuter notre expérience en plusieurs phases. Dans chaque phase, nous supprimerons les champs où leur score F1 est nettement inférieur à celui des autres domaines. Au fur et à mesure que nous exécutons notre expérience, nous supprimerons d’autres sous-ensembles de l’ensemble de champs. En utilisant un sur-ensemble de tous les champs avec 511 sous-ensembles, ou toute technique d’élimination de caractéristiques, nous aurons une liste de caractéristiques avec chaque élément contenant des champs (par exemple, caractéristiques =[“ngram”, “phonetic, ngram”, ….”phonetic, ngram, stemming” … ]

Calcul des scores F1

Disposant d’un ensemble de données « missplled_names », « expected_names » (créé dans la section 4.2.1) et d’une liste de fonctionnalités (créée dans la section précédente), nous pouvons maintenant calculer le score F1 pour chacune de ces fonctionnalités. Pour chaque fonctionnalité de la liste des fonctionnalités et pour chaque « nom_mal orthographié » dans notre ensemble de données, nous allons procéder comme suit  :

    « queryType » : « complet »,

    « search » : « NOM MAL orthographié »,

    « searchFields » : « FEATURE/S »

  1. Prenez la réponse la mieux classée et comparez-la au nom attendu correspondant
  2. Marquez le résultat en fonction des éléments suivants  :
    • TP : Certains noms ont été trouvés et correspondent au nom attendu
    • PF : Certains noms ont été trouvés, mais ils ne correspondent pas au nom attendu
    • TN :Aucun nom trouvé et aucun nom attendu
    • FN : aucun nom n’a été trouvé mais nous devions en trouver
  3. À l’aide de la formule décrite dans la section précédente, calculez la précision, le rappel et la F1 pour chaque caractéristique

Enfin, pour chaque fonctionnalité, nous aurons un résultat semblable à ce qui est illustré dans le schéma suivant composé de différentes mesures pour la combinaison de différents analyseurs de recherche.

« fn » : 26,

« tp » : 365,

« tn » : 18,

« fp » : 11,

« fields » : « camelcase-url_email-text_microsoft »,

« précision » : 0.6206896551724138,

« rappel » : 0.9335038363171355,

« f1 » : 0.7456165238608637

Sélectionnez les meilleurs analyseurs

Après avoir exécuté les expériences mentionnées dans la section précédente, nous avons sélectionné la ou les fonctionnalités avec le score F1 le plus élevé. S’il existe plusieurs fonctionnalités avec un score similaire, nous pouvons augmenter le nombre de données de test pour les noms mal orthographiés et les noms attendus. Ensuite, nous pouvons ajouter ces enregistrements supplémentaires dans notre recherche Azure et relancer le test. Nous pouvons également réduire nos fonctionnalités à l’aide d’une méthode d’élimination des fonctionnalités.

« url_email »74, alors que si nous nous appuyons sur l’analyseur par défaut (stanadard_lucene), le score F1 est égal à0,69. Par conséquent, si nous spécifions les analyseurs de recherche dans la requête de recherche, nous aurons environ 5 % d’amélioration dans la récupération des noms à partir du moteur de recherche. La figure 17 illustre le score F1 pour 50 caractéristiques sur les 511 testées, le score F1 étant supérieur à celui de l’analyseur par défaut dans l’ordre croissant.

Analyseurs avec F1 supérieur à la valeur par défaut (standard_lucene)

Résumé

Dans ce document, nous avons expliqué comment lever l’ambiguïté des entités mal orthographiées à l’aide d’AzureSearch. Nous avons discuté de la façon dont nous pouvons utiliser Microsoft LUIS pour lever l’ambiguïté des entités des intentions, et comment nous pouvons améliorer la récupération d’entités en expérimentant avec différents analyseurs de recherche. Ensuite, nous avons créé un index de recherche à l’aide de neuf analyseurs de recherche et avons ingéré un ensemble de données de noms de personnes dans cet index. Nous avons ensuite exécuté l’expérience en envoyant des noms de personnes mal orthographiés à l’index de recherche et, sur la base des performances de récupération, nous avons sélectionné les analyseurs de recherche les plus performants. En expérimentant avec différents analyseurs de recherche, nous avons pu spécifier les analyseurs de recherche avec la meilleure précision et le meilleur rappel.

Par conséquent, nous pourrions améliorer le score F1 de la récupération de recherche de 5 %.

Cette expérience a été exécutée pour les noms de personnes. Pour tout autre champ (par exemple, adresse, ville, pays, etc.), une expérience similaire doit être exécutée pour s’assurer que les analyseurs les plus performants sont sélectionnés et seront utilisés. De plus, nous pouvons exécuter cette expérience en conjonction avec un service de vérification orthographique tel que la vérification orthographique Bing pour tenter de résoudre les entités mal orthographiées avant même d’appeler le service de recherche.

L’équipe

Je tiens à exprimer mes remerciements particuliers à l’équipe incroyable qui m’a aidé à travers les expériences, les mises en œuvre de cette méthode.

Ressources:

[1] https://docs.microsoft.com/en-us/azure/search/index-add-custom-analyzers

[2] https://www.luis.ai/

[3] Pouvoirs, David MW (2011)

Tags: