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

Publication d’un modèle de transcription et de la vérité de terrain !

Afin de rendre visible le travail colossale d’annotation réalisé par les équipes des Archives nationales, les transcriptions susceptibles de servir de données d’entraînement sont désormais publiées au sein du projet HTR-United, dans 3 répertoires Github distincts. Leur publication permet désormais à d’autres utilisateurs et utilisatrices de l’HTR de les réemployer pour leur propres expérimentations.

Il s’agit des répertoires suivants :

LECTAUREP Repertoires : qui contient les pages de répertoires, transcrites et validées (de nombreuses nouvelles pages sont en cours de relecture).

LECTAUREP Bronod : qui contient les minutes rédigées par Maître Bronod, dont le format diffère du corpus de répertoires car elles datent de 1742.

LECTAUREP Mariages et Divorces : qui contient les registres des Mariages et Divorces, pour le début du XXe siècle principalement.

Illustration des 3 types de documents issus de chaque corpus
Illustration des 3 types de documents issus de chaque corpus (de gauche à droite : Bronod, Repertoires, Mariage et Divorce)

Un modèle générique v1

Un nouveau modèle générique intitulé lectaurep_base a été entraîné à partir de ces données. Il est publié sur deux plateformes :

– sur Zenodo, ce qui le rend interrogeable depuis Kraken et permet de lui attribuer un DOI : https://zenodo.org/record/6542744

– sur Github afin de correctement documenter ses conditions de création : https://github.com/lectaurep/lectaurep_base_model

Les deux espaces de publication sont synchronisés et ont l’avantage de permettre de versionner les dépôts. Cela signifie que lorsque de nouvelles données seront publiées, nous pourrons entraîner un nouveau modèle et le publier dans les mêmes répertoires comme des v2, 3, etc.

Il est toujours possible d’accéder aux autres modèles entraînés au cours du projet LECTAUREP, notamment Generic_lectaurep_26, en se rendant ici : https://gitlab.inria.fr/dh-projects/kraken-models.

9,8% de CER

Le modèle générique produit encore beaucoup d’erreurs car son CER (Character Error Rate) reste au-dessus de 5%. Ce taux d’erreur augmente sur des données hors-domaine, c’est-à-dire des variations d’écritures inconnues pour le modèle.

Si on l’applique à un poème autographe d’Apollinaire par exemple, il fait 5 erreurs sur le titre :

Lettres à lire Lettres lue
L l
ont ais
b l
Aperçu de la transcription produite par lectaurep_base, comparé à la transcription attendue (manual) et à celle produite par generic_lectaurep_26
Aperçu de la transcription produite par lectaurep_base sur une écriture inconnue, comparée à la transcription attendue (manual) et à celle produite par generic_lectaurep_26

Le modèle lit donc “le Pais Miraleau” au lieu de “Le Pont Mirabeau”. Il est toutefois intéressant de noter deux choses :

– sur ce même segment, le modèle lectaurep_base fait moins d’erreurs que le modèle generic_lectaurep_26 (même si une partie d’entre elles sont identiques)

– les erreurs propres à lectaurep_base ont plus de sens que celles de generic_lectaurep_26 : si on regarde le tracé des lettres, on comprend l’origine de ces inversions.

L’ajout de nouvelles données d’entraînement pourra peut-être permettre d’abaisser le taux d’erreur théorique, mais cela permettra surtout d’augmenter la robustesse face à des écritures inconnues. Par ailleurs, le but d’un tel modèle n’est pas forcément d’être utilisé comme tel, mais plus de servir de base (comme son nom l’indique) pour affiner de nouveaux modèles de transcription, spécialisés sur une période ou une famille d’écritures.

Publication avec Kraken

Le dépôt Zenodo à été généré à partir de l’utilitaire de publication proposé par Kraken. Il me paraît intéressant d’expliquer ici la marche suivie.

Après avoir installé Kraken (dans un environnement virtuel), la commande “ketos publish” permet de lancer l’utilitaire de publication. La commande complète la plus basique ressemble à ceci :

ketos publish -a $ACCESS_TOKEN chemin/vers/le/model.mlmodel

Cette commande déclenche l’utilitaire en mode interactif. L’utilisateur ou l’utilisatrice est alors amené(e) à renseigner, entre autres, le nom des auteurs et autrices du modèle, leur affiliation, la licence associée au modèle, ainsi qu’une description plus ou moins longue.

La valeur ACCESS_TOKEN doit être obtenue prélablement à partir de Zenodo. Pour cela, il faut créer un compte Zenodo et s’y connecter, puis aller sur Paramètres, puis Applications (ou cliquer ici). C’est depuis cette page que l’on peut créer un jeton d’authentification (access token) qu’il faut prendre soin de copier avant qu’il ne devienne invisible. Le jeton est une (longue) liste de caractères, par exemple “xTjfTjffMh3Ch0CSfwT1tpC”. Avec une telle valeur, la commande ressemble donc à ceci :

ketos publish -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel

Comme il peut sembler risqué d’utiliser la ligne de commande pour fournir les métadonnées qui seront ensuite publiées avec le modèle, il est possible d’utiliser un fichier JSON reprenant la structure suivante :

{"authors": [{"name": "", "affiliation": ""}], "summary": "", "description": "", "accuracy": 00.00, "license": "", "script": [], "name": "", "graphemes": []}

C’est l’option “-i” qui permet de passer le fichier de métadonnées à Ketos. Le mode interactif ne se déclenche pas si on utilise cette option. Admettons que le fichier soit nommé “metadata.json”, la commande ressemblerait à ceci :

ketos publish -i chemin/vers/metadata.json -a xTjfTjffMh3Ch0CSfwT1tpC chemin/vers/le/model.mlmodel

Lorsque la publication vers Zenodo est terminée, Kraken affiche l’identifiant du nouveau dépôt. Il est alors possible d’éditer les métadonnées depuis Zenodo de manière à corriger des erreurs, mieux structurer la description longue, ou encore ajouter d’autres contributeurs et contributrices.

En publiant à l’aide de Kraken, le modèle est automatiquement associé à la communauté “OCR/HTR model repository“. Cela lui donne plus de visibilité, ce qui n’est pas un luxe dans l’océan de dépôts qu’est Zenodo !

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