Historical HTR Pipeline : Apprendre à un modèle à lire une écriture qu'il n'a jamais vue

Les manuscrits espagnols du début de l'époque moderne — lettres, actes notariés, journaux de bord des XVIe et XVIIe siècles — dorment dans les archives, en grande partie non lus, parce que les transcrire à la main prend une éternité et que la plupart des OCR ont été conçus pour du texte imprimé, pas pour l'écriture d'un scribe vieille de quatre cents ans.

C'est une tentative de construire un pipeline capable de vraiment les lire : trouver le texte sur la page, déterminer l'ordre dans lequel il est censé être lu, et le transcrire, en une seule passe à travers un modèle vision-langage plutôt qu'une chaîne d'outils séparés se passant le relais l'un à l'autre.

L'écriture historique casse la plupart des hypothèses sur lesquelles l'OCR moderne est construit. Les formes des lettres varient d'un scribe à l'autre. Les abréviations et les ligatures étaient courantes et n'ont jamais été standardisées. L'orthographe non plus n'était pas standardisée, des siècles avant qu'une quelconque Real Academia Española n'existe pour la fixer.

Les pages sont souvent délavées ou endommagées par l'eau, et fréquemment disposées en deux colonnes avec des notes marginales qui n'ont leur place nulle part dans l'ordre de lecture principal. Se tromper sur la mise en page, et même un reconnaisseur de caractères parfait produit du non-sens, parce qu'il lit une note de marge au milieu d'une phrase.

La plupart des systèmes HTR traitent cela comme deux tâches agrafées ensemble : un modèle de mise en page trouve les régions de texte et l'ordre de lecture, puis un reconnaisseur séparé, souvent quelque chose comme TrOCR ou un modèle de type CRNN, transforme chaque ligne en texte. Les erreurs de la première étape s'accumulent silencieusement dans la seconde, et un modèle vision-langage comme Qwen3-VL n'apparaît généralement qu'à la fin, comme une passe de nettoyage sur ce que le reconnaisseur a raté.

L'approche que je teste met Qwen3-VL dans la boucle dès le départ : détection de la mise en page, récupération de l'ordre de lecture, et transcription en une seule passe, plutôt qu'une correction superficielle après coup. Un modèle qui comprend déjà où se situe une note marginale par rapport au texte principal devrait avoir moins à corriger en aval.

Celui-ci est encore en cours. Ce qui existe aujourd'hui, c'est l'échafaudage du pipeline en PyTorch et Transformers, plus un chemin d'inférence fonctionnel pour une seule page à travers Qwen3-VL. Ce qui n'existe pas encore, c'est un jeu de test isolé avec des transcriptions de référence pour mesurer le taux d'erreur de caractères. Je n'ai donc aucun chiffre de précision à rapporter, et je préfère le dire clairement plutôt que d'en publier un qu'aucune évaluation ne soutient.

Pour donner une idée de l'objectif : une étude de 2022 sur des manuscrits latins médiévaux (arXiv:2201.07661) a réduit le taux d'erreur de caractères d'environ 6 % de base à environ 3 % en affinant sur deux pages de référence par document. C'est la fourchette que je vise. Si ce pipeline s'en approche reste, pour l'instant, non mesuré.

L'ordre de lecture est la question ouverte qui compte le plus en ce moment, avant la précision des caractères. Un modèle peut avoir chaque lettre d'une ligne juste et quand même produire une transcription inutile s'il assemble ces lignes dans le mauvais ordre.

Réussir cela, de façon cohérente, sur des pages avec notes marginales, insertions, et l'occasionnelle demi-page écrite de travers, c'est l'objet de la prochaine étape de ce projet.