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 “?”.

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.

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.

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.
- A l’aide du modèle de segmentation lectau1_8 [↩]
- Voir Kraken/ketos.py [↩]
- 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. [↩]
- Voir Issue kraken/#242 [↩]
- Daniel Stoekl supervise le développement de la plateforme eScriptorium dans le cadre du projet SCRIPTA [↩]
- Avec les données issues du projet TIME US, le lot comptabilisait 502 pages. [↩]
- 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 [↩]
- Source : https://github.com/mittagessen/kraken/blob/ffb35d101166e35fad7930d468138e216e48991a/kraken/lib/default_specs.py#L21) [↩]
- 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”. [↩]