Apprentissage hybride de la machine : Le mariage du NLP et du RegEx
Introduction
Lors de la conception d'applications NLP réelles, vous êtes souvent confronté à des données limitées (étiquetées), à des exigences de latence, à des restrictions financières, etc. qui vous empêchent d'exploiter tout le potentiel de votre solution.
Une configuration hybride où l'on exploite les connaissances du domaine pour améliorer la précision, l'efficacité, la fiabilité et/ou l'interprétabilité serait parfaite.
Mais il est loin d'être évident de trouver comment concevoir une telle solution hybride.
Passons en revue quelques schémas de conception hybrides courants de la PNL et examinons des exemples de situations dans lesquelles il convient d'opter pour tel ou tel schéma.
(1) RÈGLES VS ML
Le premier modèle que nous examinerons est le cas contradictoire: vous choisissez soit une solution purement fondée sur des règles, soit une solution purement fondée sur la ML.
Examinons quelques exemples dans lesquels ces modèles de conception sont très utiles :
Reconnaissance d'entités nommées (NER): le choix pour ou contre une approche basée sur la ML se résume essentiellement à la façon dont les entités sont contextuelles.
Par exemple, les dates peuvent être structurées d'une manière spécifique (par exemple, "JJ/MM/AAAA"). Si une entité suit ce format, il s'agit d'une date, sinon ce n'en est pas une. Il s'agit donc d'une "entité non contextuelle" : c'est-à-dire qu'un modèle concret fixe détermine s'il s'agit ou non d'une date, indépendamment du contexte.
Il est facile d'extraire ce type d'entités à l'aide de règles simples.
Cependant, supposons que vous ne souhaitiez extraire que les dates de naissance et pas d'autres types de dates. Nous avons affaire à une "entité contextuelle" : les dates de naissance et les autres types de dates se ressemblent exactement ; sans contexte, vous ne pourriez pas faire la distinction entre les deux.
Il est très difficile d'extraire ces entités à l'aide de règles, de sorte qu'une approche purement fondée sur la modélisation linéaire est la plus appropriée.
Classification de textes: dans les cas d'utilisation de la classification de textes, les caractéristiques sous-jacentes qui déterminent la classe à laquelle appartient un texte sont souvent très latentes. Comme les systèmes basés sur des règles n'ont pas tendance à donner de bons résultats dans ces scénarios, un modèle de conception purement basé sur le ML est généralement la voie à suivre. Il en va de même pour les tâches complexes telles que l'extraction de mots-clés, le résumé de texte, etc.
(2) RÈGLES APRÈS/AVANT ML
Le modèle suivant que nous allons examiner est de nature séquentielle: les règles métier agissent soit comme un premier filtre, soit comme une étape de post-traitement pour le modèle ML.
Reprenons quelques exemples :
Filtre passe-haut : supposons que vous souhaitiez extraire les dates de naissance et aucune autre date, vous pourriez alors opter pour une approche ML pure (voir ci-dessus). Cependant, seule une fraction de vos données contient réellement des dates, de sorte que l'exécution de l'inférence sur chaque instance semble être un peu un gâchis.
Nous savons que toute date de naissance est également une date et que les dates suivent un modèle fixe. Ainsi, nous pouvons d'abord vérifier si un texte contient une date à l'aide d'une simple règle de gestion, puis n'exécuter l'inférence que dans les cas où c'est le cas.
Quelques règles simples permettent souvent de réduire considérablement la puissance de traitement utilisée, avec un impact minime, voire inexistant, sur les performances.
Recherche (sémantique): d'une manière très similaire à celle décrite ci-dessus, vous pouvez réduire la quantité de données que vous traitez pour effectuer une recherche sémantique en commençant par filtrer les résultats pour lesquels vous êtes (presque) certain qu'ils ne seront pas pertinents (par exemple, ceux dont le score TF-IDF est (presque) nul). Ce type de configuration est appelé "architecture de récupération et de reclassement".
Selon les données, il est souvent possible d'obtenir une diminution à deux chiffres du temps de latence, avec un impact négligeable sur les performances de recherche.
Liaison d'entités: disons que nous voulons extraire des noms de produits avec des prix de vente et lier les deux entités ensemble (c'est-à-dire déterminer quel prix de vente appartient à quel nom de produit). Nous connaissons nos données et nous supposons simplement qu'un prix de vente correspond au nom de produit le plus proche.
Il s'agit d'une étape de post-traitement ("linking") basée sur des règles qui intervient après l'extraction des prix de vente et des noms de produits basée sur le ML.
(3) RÈGLES ET ML
Ce modèle cherche à combiner les résultats des règles et du ML en tant qu'ensemble.
Voyons à nouveau quelques exemples :
Plus de déterminisme: toutes les erreurs ne sont pas égales. Il y a peut-être des modèles que vous savez corrects et vous voulez que votre solution soit correcte à chaque fois.
Dans ce scénario, vous pouvez disposer d'un système restrictif fondé sur des règles qui garantit que ces situations critiques sont couvertes et, parallèlement, d'un système plus généralisable fondé sur le ML qui vise à couvrir les autres cas (complexes).
Par exemple, vous pouvez disposer d'une liste de noms que vous savez être propres et corrects. Ces noms seront toujours reconnus. Les noms (peu courants) qui ne figurent pas dans cette liste seront pris en compte par le modèle de ML.
Optimisation du rappel/de la précision: puisque vous combinez essentiellement plusieurs prédictions, vous pouvez optimiser le rappel ou la précision en choisissant le "système de vote" (c'est-à-dire la manière dont vous passez de plusieurs prédictions individuelles à une prédiction finale).
(4) RÈGLES INFORMÉES PAR LE ML
Une situation plus particulière pourrait être que votre cas d'utilisation nécessite réellement un système basé sur des règles - que ce soit pour des raisons réglementaires (par exemple, le "droit à l'explication" du GDPR ) ou pour d'autres raisons - mais que ces règles sont très difficiles à déterminer.
Dans ce scénario, vous pourriez utiliser l'apprentissage automatique pour générer des règles optimales (RegEx).
Il existe en fait plusieurs façons d'y parvenir : des modèles Seq2Seq en langage naturel vers RegEx comme SemRegex, des modèles formés sur des données étiquetées comme l'algorithme évolutif RegexGenerator et des modèles comme TransRegex qui utilisent à la fois le langage naturel et des exemples étiquetés.
(5) ML FONDÉ SUR DES RÈGLES
Ce modèle cherche également à combiner règles et ML, mais il le fait en trouvant une représentation appropriée des résultats de RegEx et en intégrant véritablement la connaissance du domaine dans l'architecture du modèle.
Théoriquement, il s'agit d'une solution très propre, mais dans la pratique, nous ne voyons pas l'adoption (généralisée) de telles architectures. Ou du moins pas encore.
Si vous voulez avoir une idée de ce à quoi cela pourrait ressembler, consultez ce document. Mais à l'heure où nous écrivons ces lignes, nous ne recommandons pas un tel modèle de conception.
Conclusion
En conclusion, le NLP hybride a le potentiel d'améliorer considérablement la précision, l'efficacité, la fiabilité et/ou l'interprétabilité de votre solution, en particulier dans le cas de données peu étiquetées. À condition de bien s'y prendre.
Le choix de la bonne configuration est intrinsèquement très spécifique aux données et aux problèmes, mais nous espérons que les exemples ci-dessus vous ont donné une certaine intuition quant à l'approche à adopter.
