Ressources numériques en sciences humaines et sociales OpenEdition Nos plateformes OpenEdition Books OpenEdition Journals Hypothèses Calenda Bibliothèques OpenEdition Freemium Suivez-nous

Création de modèles de transcription pour le projet LECTAUREP #2

Dans le précédent billet, nous vous expliquions quelles avaient été nos premières pistes pour la création de modèles de transcription applicables aux données du projet LECTAUREP. En essayant d’entraîner un modèle pour chaque famille d’écriture identifiée, nous nous retrouvions à devoir effectuer beaucoup de saisie pour des modèles finalement peu efficaces. Lorsque nous fusionnions toutes ces données, nous obtenions des performances similaires mais qui nous laissaient entrevoir la possibilité d’une plus grande robustesse face à des écritures nouvelles. Au lieu de silos de données assignées à tel ou tel modèle, nous pouvions envisager un pot commun pour tous les documents du projet et gagner ainsi un temps précieux.

Le présent billet vise à rendre compte de la stratégie mise en place afin d’élaborer un modèle générique pour les pages des répertoires de notaires.

Des données variées et imparfaites

Un premier lot de données de vérité de terrain a été constitué par les équipes du Département du Minutier Central des Archives nationales à partir de plusieurs extraits de répertoires. En plus des données mentionnées dans le billet précédent, ce lot rassemblait des pages issues des notaires Rigault, Legay, Boissel et Cahouet. Il était composé d’un total de 480 fichiers XML, correspondant chacun à une page de répertoire. Chaque page avait été pré-segmentée automatiquement1, reprise manuellement (parfois entièrement) puis transcrite par différent(e)s annotateurs et annotatrices.

Notons : comme pour une partie des données testées précédemment, aucune de ces transcriptions n’avait été relue en totalité. Cette vérité de terrain comportait donc non seulement des erreurs de transcription, mais également des omissions non résolues, généralement marquées par une suite de “X” ou de “?”.

Exemple de notation d'omission
Exemple d’omission : au lieu de “rue des Remises”, la transcription propose “rue des xxxx”.

Notre objectif général était de tester si l’augmentation du corpus de vérité de terrain, opérée grâce à la mise en commun de transcriptions associées à des types d’écritures différents, permettait de gagner quelques points d’exactitude (accuracy) de manière à atteindre un score d’au moins 80%. Ce modèle aurait ensuite été affiné (finetuné) pour permettre de réaliser une première transcription que les annotateurs et annotatrices auraient ensuite seulement à corriger. Même si l’usage est de viser une vérité de terrain la plus correcte possible, ici nous jugions que le rapport entre gain de performance et temps investi pour la correction ne justifiait pas que l’on relise chacune des 480 pages pour débusquer les erreurs et que cela pouvait venir dans un deuxième temps. Pour cette raison, on peut considérer que la qualification d’un tel lot en “vérité de terrain” constitue une erreur. Cependant, lorsque l’on mène un projet de cette envergure, avoir suffisamment de temps ou de personnes chargées d’annoter n’est pas évident. Laisser ce lot de données en l’état permettrait de prendre en compte cette réalité dans la chaîne de production de la vérité de terrain.

Optimisation du temps de calcul

Étant donné la quantité de données rassemblées, nous avons d’abord dû optimiser le temps de calcul afin de pouvoir effectuer différentes expériences dans des temps raisonnables.

Nous avons ainsi configuré Kraken, notamment en ce qui concerne le réglage des threads, aussi appelé fils d’exécution des CPUs. Ce paramètre a un impact important sur la vitesse des entraînements car il spécifie avec quel moyen (et donc à quelle vitesse) la machine charge en mémoire les données pour ensuite réaliser ses calculs à l’aide des GPUs.

Sur des machines de type laptop comme ceux qui équipent une partie des membres de l’équipe ALMAnaCH, on trouve des processeurs Intel Core i7 ou i9, comportant entre 4 et 8 cœurs, soit respectivement 8 ou 16 threads. Le serveur Traces6 possède, lui, 2 processeurs à 16 cœurs, soit un total de 64 threads. Pour l’entraînement de modèles de transcription, Kraken est paramétré par défaut pour n’utiliser qu’un seul thread2. Conserver ce paramétrage par défaut sur une machine possédant 2 GPUs RTX 6000, 125 Go de RAM et 64 CPUs, c’est vraiment ne pas donner les moyens aux GPUs de se rendre utile : on passerait beaucoup plus de temps à charger les données qu’à effectuer les calculs .

Les premiers entraînements réalisés permettaient ainsi de passer de près de 4 heures pour 30 époques3 d’apprentissage, à environ 2h30. C’était mieux mais toujours lent ; depuis, les modalités de chargement des images par Kraken ont été revues dans le code source, de manière à effectuer plusieurs chargements en parallèle4.

Des résultats décevants

Les entraînements sont lancés en ligne de commande et non depuis eScriptorium, ce qui pour le moment permet de mieux surveiller ce qu’il se passe durant l’entraînement tout en pouvant intervenir sur les paramètres par défaut. Les premiers résultats obtenus se sont avérés décevants :  en ayant quasiment doublé le lot d’entraînement, au lieu des 80% espérés, ou des 70% acquis avec les modèles à une seule main, nous plafonnions à 67 % d’exactitude au bout de 23 époques.  Nous en avions initialement tiré deux conclusions :

– l’augmentation de la taille du lot de données ne compensait pas l’augmentation de la variation dans les images ;

–  et/ou il restait trop d’erreurs dans la vérité de terrain.

Il fallait donc d’abord relire les transcriptions, ou bien en produire de nouvelles, puis retenter l’expérience.

Avec ce premier modèle générique à 67%, nous avons tout de même tenté une campagne d’affinage avec les données du notaire Riant, en ajoutant 50 pages qui avaient été laissées de côté. Cette fois encore, le modèle obtenu peinait à dépasser les 75% d’exactitude.

Un problème d’architecture

Nous en étions restés là de nos expérimentations lorsqu’une discussion avec les membres de l’équipe SCRIPTA nous a donné de nouvelles pistes. S’étonnant que nous ne parvenions pas à dépasser la barrière des 80% avec la quantité de données rassemblée, Daniel Stoekl5  nous a encouragé à modifier quelques paramètres supplémentaires, notamment le learning rate (ou vitesse d’apprentissage) et l’architecture des réseaux de neurones employée (exprimée en spécifications VGSL).

L’architecture correspond à l’enchaînement de couches de neurones, c’est-à-dire à l’enchaînement des transformations appliquées aux données afin d’en tirer la sortie souhaitée. La vitesse d’apprentissage correspond à l’amplitude de l’espace de probabilité exploré par le modèle à chaque itération. En somme, c’est comme, marchant dans le noir et cherchant une sortie, choisir de faire des grands pas autour de soi pour arriver plus vite vers une porte, ou bien faire de petits pas qui nous amènent plus lentement mais plus sûrement vers la bonne porte.

Entre-temps nous avions ajouté de nouvelles données6 à notre lot d’entraînement. Pour comparer l’impact de ces paramètres sur la réussite de l’apprentissage, nous avons réalisé un entraînement sans ces paramètres. Comme précédemment, celui-ci restait bloqué autour de 73% d’exactitude après 19 époques.

Courbe montrant en miroir l'évolution du CER et celle du taux d'exactitude pour un entraînement avec les paramètres par défaut de Kraken. Le CER reste au-dessus de 26%.
Performance du modèle entraîné avec les paramètres par défaut, exprimée en CER et en exactitude. Le CER reste au-dessus de 25%.

En revanche, les résultats étaient bien meilleurs en ajoutant à la commande d’entraînement les deux éléments suivants7 :

-s ‘[1,120,0,1 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 S1(1×0)1,3 Lbx200 Do0.1,2 Lbx200 Do.1,2 Lbx200 Do]’
r 0.0001

C’est-à-dire en ralentissant les pas d’apprentissage de Kraken (0,0001 au lieu de 0,001) et en revoyant l’enchaînement des couches de transformation (l’architecture par défaut de kraken est la suivante : ‘[1,48,0,1 Cr4,2,32,4,2 Gn32 Cr4,2,64,1,1 Gn32 Mp4,2,4,2 Cr3,3,128,1,1 Gn32 Mp1,2,1,2 S1(1×0)1,3 Lbx256 Do0.5 Lbx256 Do0.5 Lbx256 Do0.5]’8. On passait soudainement à 91% d’exactitude en 26 époques.

Performance de l'entraînement en modifiant les paramètres de Kraken, la courbe du CER passe en-dessous de la barre des 10%.
Performance de l’entraînement en modifiant les paramètres de Kraken, la courbe du CER passe en-dessous des 10% !

Comme on a plus d’images et que le learning rate est plus petit, le modèle a besoin de plus de époques d’entraînement, ce qui ralentit l’ensemble du processus . Pour obtenir notre modèle à 91%, il nous a ainsi fallu compter 16h pour l’apprentissage. Une majeure partie de ce temps reste toutefois dédiée au chargement des images en mémoire et non au calcul.

Cette attente est un moindre mal dans la mesure où non seulement le modèle générique peut être utilisé tel quel pour pré-annoter des manuscrits similaires9 , mais en plus on peut l’utiliser comme base pour affiner de nouveaux modèles qui peuvent très largement dépasser les 95% d’exactitude avec relativement peu de données. Ce fut le cas pour les répertoires du notaire Bronod. Mais nous en parlerons dans un prochain billet !

Finalement, ce billet est l’occasion de rappeler que posséder des connaissances en apprentissage machine reste encore crucial pour profiter à fond des outils de reconnaissance automatique des écritures : la production de la vérité de terrain ne fait pas tout. Cela nous permet aussi d’insister sur l’intérêt de mettre à disposition de la communauté des modèles déjà en partie capables de traiter des données variées. Ce premier modèle générique entraîné dans le cadre du projet LECTAUREP, nommé generic_lectau26, a ainsi été plusieurs fois partagé avec d’autres projets souhaitant travailler sur des écritures françaises des XIXe et XXe siècles.

  1. A l’aide du modèle de segmentation lectau1_8 []
  2. Voir Kraken/ketos.py []
  3. Une époque correspond à une itération sur l’ensemble des données du set d’entraînement, à la fin de laquelle l’état des connaissances du modèle est évalué sur un lot de données qui n’étaient pas contenue dans le set d’entraînement – elles constituent le set de test. []
  4. Voir Issue kraken/#242 []
  5. Daniel Stoekl supervise le développement de la plateforme eScriptorium dans le cadre du projet SCRIPTA []
  6. Avec les données issues du projet TIME US, le lot comptabilisait 502 pages. []
  7. Notez, la commande complète était : ketos train -o generic_lectau -f page -t allxmls.xmllist –device cuda:1 –augment –threads 64 -u NFD -s ‘[1,120,0,1 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,13,32 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 Mp2,2 Cr3,9,64 Do0.1,2 S1(1×0)1,3 Lbx200 Do0.1,2 Lbx200 Do.1,2 Lbx200 Do]’ -r 0.0001 []
  8. Source : https://github.com/mittagessen/kraken/blob/ffb35d101166e35fad7930d468138e216e48991a/kraken/lib/default_specs.py#L21) []
  9. Nous reviendrons dans un autre billet sur les tests réalisés pour confirmer les performances effectives du modèle sur des données “hors domaine”. []

Création de modèles de transcription pour le projet LECTAUREP #1

Quand on se lance dans une campagne de transcription reposant sur la reconnaissance d’écritures manuscrites, on passe généralement par une série de questions qui sont les mêmes d’un projet à l’autre. Parmi ces questions, il y a celle des modèles de transcription et de leur rapport à la variation des écritures. Doit-on entraîner un modèle pour chaque type d’écriture présent dans un corpus de documents ? Au contraire, peut-on se contenter d’entraîner un seul modèle tout terrain (qu’on appellera mixte ou générique) ?

On se pose rarement ces questions si l’on a recours à l’OCR car généralement ces outils ont déjà atteint le stade du tout en un, mais c’est loin d’être le cas pour les textes manuscrits. S’il faut mener une campagne de transcription manuelle pour créer la vérité de terrain nécessaire à l’entraînement des modèles, il est normal de chercher à déterminer en tout premier lieu si une seule suffit, ou s’il faut en fait en mener autant qu’il y a de familles d’écritures. Le problème devient encore plus tentaculaire si la répartition de ces écritures n’est pas prévisible et qu’on commence à se demander comment déterminer et repérer ces variations d’écriture dans les documents : on frissonne à l’idée de devoir dépouiller chaque page du corpus et gérer des dizaines de modèles alors qu’on pensait régler le problème de la transcription en deux claquements de doigts sur un clavier.

Le projet LECTAUREP n’échappe pas à ce cas de figure : avec nos centaines de mains d’écriture dans les répertoires de notaires, dont certaines n’apparaissent que sur très peu de documents, la perspective de créer une vérité de terrain pour chaque main ne manque pas de provoquer des grimaces. Très tôt, nous avons envisagé des solutions pour éviter d’avoir à entraîner plusieurs centaines de modèles différents.

La piste des modèles multiples

Nous ne nous sommes pas directement engagés sur la piste d’un modèle générique. Au contraire, nous avons d’abord imaginé restreindre nos efforts pour ne traiter que quelques notaires lisibles et dont les scribes sont restés constants. L’idée était notamment de simplifier la tâche de transcription manuelle car chaque changement d’écriture requiert un temps d’adaptation et un effort supplémentaire pour la personne chargée de l’annotation.

Une première campagne de transcription avait pris place durant la phase 1 du projet LECTAUREP et s’était concentrée sur 50 pages du notaire Marotte. Nous avons transposé cette transcription dans eScriptorium et annoté 100 pages tirées des répertoires de deux autres notaires : Dufour et Riant. Notons que le texte est beaucoup plus dense dans les pages de Marotte.

En septembre 2020, nous avons évalué l’efficacité des entraînements menés avec ces données à l’aide de Kraken. Le graphique ci-dessous résume l’essentiel des points pris en compte, à savoir :

  • le plus grand score de précision atteint avec les données (Best accuracy), basé sur une évaluation du taux d’erreur par caractère tel que fourni par Kraken à la fin de chaque cycle d’entraînement1 ;
  • le nombre de cycles d’entraînement (epoch) maximum opérés avec ces données avec les réglages par défaut de Kraken ;
  • le nombre de pages et le nombre de caractères contenus dans le set d’entraînement.

graphique entrainements des modèles Marotte Dufour et Riant

Nous nous sommes aperçus, sans surprise, que la densité du texte a un impact sur la quantité de pages qu’il faut transcrire pour obtenir de bons résultats : 49 pages de Marotte contiennent plus de données textuelles que 98 pages de Riant. Avec un tel écart, il faut plus d’itérations (epochs) sur les données Riant pour obtenir un modèle qui reste de toute façon largement en-dessous du modèle Marotte : 69,51 % de précision contre 89,17 %.

Grâce à cette expérience, nous avons conclu que pour passer le cap des 10 % d’erreurs par caractère pour le modèle Marotte, il nous fallait produire plus de données, et que nous étions encore loin du compte pour les modèles Dufour et Riant. En effet, il semblait nécessaire de prévoir de transcrire manuellement 200 pages (ou plus) pour certains notaires avant de parvenir à un modèle à peu près efficace. Cette perspective nous a légèrement échaudé et nous avons décidé de nous intéresser de plus près à la question des modèles mixtes ou génériques, entraînés simultanément sur plusieurs écritures.

Affinage et robustesse

Sans chercher à créer d’emblée un modèle mixte prêt à l’usage, nous avons envisagé d’en acquérir un dont la précision serait au moins supérieur à 80 %, puis d’utiliser nos sets Marotte, Riant et Dufour pour affiner des modèles et finir de gagner les points de précisions restants.

On s'approche du centre de la cible grâce au modèle mixte et on finit de resserrer sur le coeur de cible en affinant sur une écriture particulière

Avec les sets Marotte, Dufour et Riant, nous possédions près de 250 pages de vérité de terrain (pour un total d’environ 42 500 caractères) regroupant au moins 3 types d’écriture. Pour vérifier la faisabilité d’un modèle mixte, et en attendant de constituer un nouveau set de données pour notre modèle générique de base, nous avons décidé de réaliser un entraînement à partir de ces 250 pages.

Graphique montrant la courbe d'apprentissage du premier modèle mixte entraîné

Le graphique ci-dessus représente la courbe d’apprentissage du modèle mixte : en 25 cycles d’apprentissage, le modèle parvient à une précision maximale de 82,89 %. C’est moins que Marotte, mais mieux que Dufour et Riant seuls.

Au-delà du score de précision fourni par Kraken à la fin des cycles d’entraînement, nous nous interrogions sur la capacité du modèle à généraliser son apprentissage à d’autres écritures. La question était alors de savoir si un modèle mixte est plus robuste qu’un modèle unique face à des données légèrement différentes. Derrière la notion de robustesse, nous entendons la capacité d’un modèle à maintenir une transcription correcte malgré l’apparition d’écritures qui n’étaient pas présentes dans le set d’entraînement. Ce sont ces éléments inconnus du modèle que l’on appelle les données hors-domaine.

Illustration du concept de données hors-domaine

Si, appliqué à de nouvelles données, le modèle de transcription maintient une performance élevée malgré la variation des écritures, alors on peut considérer le modèle mixte robuste face à la variation des écritures.

Nous avions désormais deux questions liées : pouvons-nous, pour une écriture donnée, entraîner un modèle plus rapidement et avec moins de données en nous appuyant sur l’affinage d’un modèle mixte ? Le modèle obtenu en bout de course gagne-t-il en plus en robustesse face aux variations imprévues dans le lot traité ?

Le prochain billet s’attachera donc à la description des modalités de création du modèle mixte, mais aussi aux réglages qu’il nous a fallu opérer sur Kraken pour dépasser le plafond des scores à 80 %.

  1. Pour cette expérience, on prend la valeur maximale tout cycle confondu et pas le taux d’exactitude du modèle considéré comme le meilleur. Cf. Surapprentissage []

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. []