Un exemple d’exploitation des données produites grâce à la reconnaissance d’écriture manuscrite : la reconnaissance d’entités nommées

De la création des données à leur exploitation

Grâce à l’instance eScriptorium mise en place sur le serveur Traces6 et la création de modèles de reconnaissance d’écriture manuscrite (REM), il est maintenant possible d’automatiser la transcription automatique des documents du projet LECTAUREP à grande échelle. On peut exporter les données produites depuis eScriptorium dans trois formats différents : du texte brut, XML PAGE, et XML ALTO. Ce contenu textuel peut ensuite faire l’objet de premières recherches plein texte, de corrections automatiques, ou encore servir à la création d’une nouvelle couche d’annotations. Celles-ci permettraient de repérer et d’organiser plus finement les informations essentielles.

En décidant de traiter le texte obtenu par la REM, on entre dans l’étape de post-traitement. Celle-ci est importante et nécessite des prises de décisions : que faire du bruit généré par la REM ? Faut-il nécessairement le corriger ? Souhaitons-nous livrer le texte en l’état, ou du texte enrichi ? Autant de questions qui impacteront l’expérience de l’exploitation de ces documents.

La reconnaissance d’entités nommées

Une des tâches les plus communes du traitement automatique des langues (TAL) dans le champ de l’extraction d’informations est la reconnaissance d’entités nommées (REN). Ce processus propose de repérer automatiquement dans un texte les noms propres, les localisations, les informations de date, etc. Ce faisant, un nouvel accès au texte est créé, basé non plus sur la lecture directe mais sur une lecture ciblée. L’important ici est de souligner que cette tâche est bien documentée et réalisable à l’aide de la plupart des librairies de TAL.

La REN peut s’appuyer sur plusieurs méthodes. Dans le domaine de l’apprentissage machine (machine learning), il existe des approches supervisées et non supervisées. Dans le premier cas, on cherche à entraîner un modèle reconnaissant des structures similaires grâce à une phase d’apprentissage effectuée à partir de données annotées manuellement. Dans le second cas, on laisse le programme détecter automatiquement des structures et les classifier. L’apprentissage profond (deep learning) possède également aujourd’hui une part importante dans la REN.1

Ces architectures permettent de détecter une entité et de lui attribuer un label. Notons que ces deux tâches sont distinctes : il est possible de détecter une entité mais de mal l’identifier (catégoriser une somme monétaire comme une date, par exemple), et la première est la condition de la deuxième. Sans détection, impossible de donner un label. 

On retrouve enfin des approches par systèmes de règles, où on cherche par exemple à faire correspondre les mots analysés à des référentiels extérieurs afin de générer des étiquettes, ou à retrouver des structures morpho-syntaxiques spécifiques. 

La REN doit également faire face aux limitations techniques des modèles génériques de reconnaissance qui sont mis à disposition. Si l’on prend l’exemple de la chaîne de traitement la plus complète en langue française de la librairie de TAL spaCy, on observe qu’avec les “réglages d’usine”, on ne peut détecter que les types d’entités suivants2 :

  • LOC – Localisation
  • ORG – Organisation
  • PER – Personne
  • MISC – Miscellaneous3

Quatre types d’entités donc, dont une difficilement exploitable en tant que telle (MISC), contre dix-huit pour la chaîne de traitement en langue anglaise. En plus des entités déjà présentes pour le modèle français, on retrouve par exemple les entités de date, de quantité, de temps, monétaires, etc.

L’entraînement d’un modèle de REN permet de répondre à des besoins spécifiques de détection.4  On peut alors déterminer les entités que l’on souhaite récupérer tout en choisissant leur étiquette. Il serait alors possible d’envisager d’entraîner un modèle de REN pour détecter par exemple les mentions d’œuvres d’art et littéraires dans un roman.

La REN et LECTAUREP

Dans les documents du projet LECTAUREP, nous cherchons à appliquer un traitement de REN au texte de la colonne centrale.5 Regardons de plus près un exemple tiré d’une ligne issue de la colonne centrale d’une page datée du mois de février 1901 dans un registre de notaire.

Extrait d'un enregistrement de la colonne centrale d'un registre de notaire datant du mois de février 1901
Dans cet extrait, on lit “Gauthier (par Marie Alexandrine) à Paris, rue St Ferdinand 2, à ses père et mère”

Il serait intéressant de récupérer automatiquement, dans les données de cette colonne, les noms propres et les localisations, par exemple.

Observons dans un premier temps une extraction réalisée avec spaCy à partir d’une transcription manuelle de la page6 :

Visualisation avec la librairie python displaCy de la reconnaissance d'entités nommées. [Gauthier, PER] (par [Marie Alexandrine, PER]) à [Paris, LOC], [rue St Ferdinand 2, LOC], à ses père et mère

Le résultat est satisfaisant : les noms de personnes ont bien été détectés, les localisations également. La segmentation des entités est également efficace : “Marie Alexandrine” a été reconnue comme une seule et même personne, et l’adresse – type de voie, nom de la voie et numéro – a correctement été extraite si l’on met de côté le nom de la ville. L’adresse complète peut facilement être reconstituée par concaténation, ou par l’entraînement d’un modèle sachant identifier ce format. Gardons cependant en mémoire que la structure de cette unité sémantique est simple et les termes non ambigus. Plus on ajoute de difficultés, plus on risque d’avoir des erreurs : des entités mal définies et/ou mal catégorisées.

Dans un deuxième temps, observons une extraction réalisée à partir d’une transcription  bruitée. Par bruit, on entend l’ensemble des erreurs de transcription ayant un impact sur l’intégrité des mots : des caractères absents ou en trop, des espaces mal placés, etc. Un modèle de REM générique entraîné à partir des documents de LECTAUREP nous a permis d’obtenir cette prédiction :

Visualisation avec la librairie python displaCy de la reconnaissance d'entités nommées sur une transcription automatique. [Gauther, LOC] (par [Marie Cexandinte, PER]) à [Paris, LOC], [rue St Ferdinandt, LOC], à sespère et [mère, PER]

La REM livre ici une transcription compréhensible et proche du texte original.7  L’extraction des entités sur ce texte bruité est globalement satisfaisante : sur les quatre entités reconnues à partir de la transcription manuelle, on en retrouve trois correctement identifiées dans la transcription automatique. Cependant, remarquons que “Gauthier” en début de ligne, devient “Gauther” et est maintenant labellisé comme une localisation.

Des stratégies à établir

Le bruit généré par la REM, lorsqu’il demeure en quantité acceptable,8 pourrait finalement n’être considéré que comme une gêne mineure, d’autant plus qu’il n’empêche pas la recherche plein texte dans le cadre d’un moteur de recherches floues. Bien que cette solution ait l’avantage de proposer de la souplesse à l’utilisateur.ice, l’enrichissement des données textuelles par des annotations permet une nouvelle approche du texte. Grâce à la REN on peut par exemple mettre en place une recherche à facettes. Réussir à récupérer tous les noms propres permettrait alors de choisir ces entités comme point d’accès au texte. 

En conclusion, la finalité d’un projet et les données sur lesquelles il est élaboré sont déterminants pour la mise en place d’une stratégie d’identification et d’annotation des entités nommées. Dans le cas du projet LECTAUREP, par exemple, on n’a pas besoin d’utiliser des outils de TAL pour toutes les colonnes : le nombre de valeurs possibles étant limités dans les colonnes “nature et espèce des actes”, on peut se contenter de mettre en place un script basé sur des règles pour comparer la prédiction de la transcription avec une liste des entrées acceptées. Lorsqu’une procuration est enregistrée par un notaire, seul le mot “procuration” est indiqué : pas besoin du TAL pour interpréter le sens de cette indication. En revanche, nous avons besoin de reconstituer le sens des informations contenues dans la colonne centrale afin de trier ce qui relève de telle ou telle catégorie d’information. 

La nature du texte à analyser n’est pas le seul facteur à prendre en compte : il est aussi nécessaire d’observer la quantité de bruit dans les données transcrites automatiquement, et d’en estimer l’impact sur l’analyse du texte. 

Enfin, s’agissant d’une couche d’analyse, la REN doit faire l’objet d’une réflexion scientifique visant à modéliser les informations contenues dans les documents et la manière dont il convient de les catégoriser. Parmi les questions à aborder : quels types d’entités souhaite-t-on collecter ? Dans quel(s) but(s) ? Avec quel niveau de granularité ? Peut-on/Doit-on normaliser et/ou désambiguïser les entités identifiées ?

Des questions se posent également sur l’après. Récupérer automatiquement des entités spécifiques avec un haut taux de réussite est une victoire, mais il est nécessaire de réfléchir à comment les stocker pour préparer leur exploitation.

  1. Pour un guide plus détaillé des différentes approches existantes concernant la REN, voir https://nanonets.com/blog/named-entity-recognition-2020-guide/ []
  2. Ses spécificités sont accessibles ici, dans la rubrique Label Scheme, à la ligne NER []
  3. Ce type d’entité indique de manière générale que le mot détecté en tant que MISC est une entité nommée, sans en déterminer la catégorie. Une entité nommée en devenir, en somme. []
  4. Voir par exemple, la documentation pour entraîner un modèle de REN à partir du modèle de langue française CamemBERT, sur huggingface. []
  5. La colonne centrale, rappelons le, concerne les “noms, prénoms et domiciles des parties – indications, situations et prix des biens” []
  6. La visualisation des entités nommées est réalisée à l’aide de la librairie python displaCy. Voir https://spacy.io/usage/visualizers []
  7. Entre la transcription manuelle et la transcription automatique, le taux d’erreur au niveau du caractère (CER pour character error rate) est de 20% et la distance de Levenshtein est de 16. Au niveau du mot, le taux d’erreur (WER pour word error rate) s’élève à 60%. Ces mesures ont été effectuées grâce à la librairie Python KaMI, utilisée ici pour comparer deux chaînes de caractères. []
  8. Avec un CER au-delà de 80%, on estime que le texte est illisible et inexploitable par un humain. []

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.