2026 Ecole nationale des Chartes hackathon: OpenStemmata for ERC LostMa project
Le projet LostMA (The Lost Manuscripts of Medieval Europe, ERC 2024–2028) vise à étudier la transmission des textes médiévaux à partir de leurs stemmata, c’est-à-dire les arbres généalogiques des manuscrits. Dans ce cadre, le projet OpenStemmata constitue une base de données ouverte rassemblant des stemmata publiés et leurs transcriptions formelles.
Le projet du Hackathon, « Trouver les arbres cachés », a pour objectif de concevoir une chaîne de traitement automatisée permettant d’extraire ces stemmata directement à partir de publications savantes numérisées.
Le pipeline attendu comprend trois étapes principales :
- Identification : former un modèle pour détecter et extraire les stemmata dans les publications numérisées de différentes époques (du XIXe siècle à aujourd'hui)
- Transcription : concevoir une solution pour convertir automatiquement l'image d'un stemma en un format de représentation graphique standard (GraphML, DOT, liste d'adjacence JSON, etc.)
- Acquisition de métadonnées : extraire les métadonnées des témoins (emplacement, datation, etc.) à partir du texte de la publication et les lier de manière cohérente aux témoins identifiés sur le stemma, puis les rassembler dans un fichier de métadonnées dans un certain format de balisage
L’enjeu du projet est de rendre possible l’analyse à grande échelle des traditions manuscrites et de contribuer à l’enrichissement collaboratif de la base OpenStemmata.
Pour la tâche 1 de détection de stemma à partir de pages issues de documents pdf au format image, nous avions à disposition un jeu de données annoté. Celui-ci a été produit par l'équipe du projet OpenStemata. Il comprend deux dossiers correspondant à la provenance des stemmas :
- « OpenStemmata + HandbookOfStemmatology »
- « Persee »
Chaque dossier comprend deux sous-dossiers contenant la vérité terrain, à savoir les images des stemmata dans l’un et le résultat de l’annotation dans Label Studio dans l’autre, au format YOLO. Les fichiers txt de ce second dossier « labels » contiennent une ligne par stemma. Cette ligne comporte les informations concernant la position du stemma sur l’image de la page. Ainsi, les pages images ne comportant pas de stemma se verraient associer un fichier label .txt vide.
Nous avons porté une attention particulière à la présence d’arbres pouvant prêter à confusion et laisser penser qu’il s’agit de stemmata, alors qu’il peut s’agir par exemple d’arbres généalogiques. Typiquement, ces arbres ont un fichier label vide associé. Le dossier « Persee » en comporte une bonne partie. Le dossier « OpenStemmata + HandbookOfStemmatology » n’en comporte pas. Par la suite, nous avons désigné ce cas particulier de « faux positifs » par « non_stemma_trees ».
| Dossier | Total | Multiples | Faux-positifs |
|---|---|---|---|
| OpenStemmata + Handbook | 115 | 16 | 0 |
| Persee | 177 | 15 | 71 |
En plus de ce jeu de données annoté disponible sur GitHub, les porteurs du projet nous ont fourni des données supplémentaire sur une clef USB. Le dossier fourni se divise cette fois en trois dossiers, « handbook », « openstemmata » et « persee ». Les sous-dossiers « handbook » et « openstemmata » contiennent chacun un fichier yaml, indiquant des pages contenant des « faux positifs ».
La première stratégie proposée (dès le tutorat de décembre 2025) et finalement non retenue consistait à détecter ce qui pouvait s'apparenter à un stemma sans chercher précisément à savoir si c'est effectivement un stemma ou alors un faux positif (arbre généalogique, phylogénétique...). Ensuite, nous aurions pu entraîner un classifieur afin de répartir les résultats obtenus selon leur degré de complexité (deux catégories auraient pu suffire: facile de vérifier si c'est un stemma, difficile de vérifier si c'en est effectivement un).
De rapides tests montrèrent la déroutante efficacité des grands modèles de langage (même avec un prompt très simple). Ceci nous a poussé à directement fournir à YOLOv11 nano les données sans opérer cette distinction selon le degré de complexité. Dans tous les cas, nous aurions utilisé un grand modèle de langage pour les données catégorisées difficiles. Nous avons préféré utiliser directement des LLM / VLM afin de ne pas passer trop de temps sur un classifieur dont l'utilisation n'aurait au final était que sommaire (quoique moins gourmande en capacité de calcul).
Afin d'assurer de meilleurs résultats, une augmentation des données d'entrainement a été faite.
Nos ordinateurs nous ont poussé à nous limiter au modèle nano de YOLOv11. Des essais ont été faits sur des modèles de taille plus grosse. Ils sont trop gourmands pour nos petits ordinateurs personnels.
Pour l'entraînement du modèle YOLOv11 nano, nous disposions d'un tout petit peu plus de données que celles initialement présentes sur le GitHub HackathonStemmata. À ces dernières, s'ajoutent :
false_positive_imagescontenant des faux positifs (pouvant être confondus avec un stemma pour un oeil non expert),persee_sans_interetcontenant de simples pages textes dénuées de stemmata ou de faux positifs,sans_interet_imagescontenant de même des pages dénués de stemmata ou faux positifs provenant du Handbook.
Les faux positifs ont été acquis depuis des fichiers .yaml fournis. Pour acquérir des pages dites sans intérêt, il convenant de parcourir les fichiers .pdf repertoriés dans les .yaml en vérifiant que l'on n'était ni sur une page contenant un stemma (true_positive) ni sur une page contenant un faux positif (false_positive).
Il n'est nullement assuré que ce qui marche sur Stackoverflow marchera pour nous (environnements non similaires ou configurations pouvant différer). Par exemple, pour une raison structurelle, il avait été décidé de ne pas séparer les données en dossiers différents selon leur provenance (sans_interet_images, false_positive_images...) mais de tout mettre dans un seul et même dossier en gardant la provenance en mémoire dans un fichier csv (selon une nomenclature quelque peu différente). Ceci peut contrarier YOLO... Ce dernier est habitué à recueillir dans son data.yaml une structuration en dossiers (e.g. train: images/train, val: images/val, test: images/test). Nous espérions pouvoir fournir une liste de fichiers à la place des dossiers. Ceci est apparemment possible (selon Stackoverflow) mais a provoqué chez nous des encodec errors ainsi que des erreurs internes à YOLO.
Il ne faut pas faire confiance trop rapidemment aux documentations (qui parfois n'existent pas totalement, en particulier si le projet / la librairie est récent(e)).
Même sur des modèles nano, demander trop d'epoch peut conduire à un crash system (peut-être dû à un memory overflow). Ceci est gênant, en particulier après 4h de calculs.
En développant en parallèle, même en suivant la même ligne directrice et des contraintes similaires, il peut être peu aisé de connecter des codes entre eux (pour rationaliser le code par exemple et imbriquer différentes tâches entre elles, chacune réalisée par une personne différente).
Les données peuvent vite s'accumuler (jeudi soir, l'un des étudiants du projet avait près de 40'000 fichiers ayant été générés lors du HACKATHON; noter qu'aucun projet sur lequel l'étudiant a travaillé en local ne contenait plus de 500 éléments).
Les résultats sont relativement concluants (sous-crop du stemma, oubliant une maigre partie) quoiqu'acceptables. On retrouve également quelques confusions entre véritable stemma et faux positif. Nous n'avons pas su identifier de méthode low tech pour différencer faux positif de vrais positifs. Il semble que la prise en compte du contexte de la figure s'apparentant à un stemma soit primordiale. Seuls des LLM / VLM peuvent nous fournir cette prise en compte du contexte.
Pour le modèle entraîné sur les données initiales enrichies simplement de faux positifs (false_positive_images), nous obtenons ceci.
Il est possible d'augmenter le nombre d'epoch (fixé ici à 30).
Cette premiere tache a été l'occasion pour la majorité des membres du groupe de découvrir YOLO par la pratique.
Force est de constater qu'il faut s'incliner devant la puissance des LLM. Le modèle YOLO ne discrimine pas suffisamment les faux positifs des véritables stemmata.
Il y a 271 dossiers correspondant à un stemma. Parmi ces 271 dossiers, 254 contiennent un unique fichier avec une extension « .png » ainsi qu'un unique fichier avec une extension « .gv ». Pour rappel, le premier des deux fichiers correspond au stemma tel qu'il apparaît dans le document original, que l'on peut nommer « stemma_source ». Le second fichier correspond à l'encodage du même stemma conformément aux guidelines proposées par le projet OpenStemmata. On pourrait le désigner par « stemma_target ».
Les statistiques qui suivent n’ont été réalisées qu’au sein des 254 dossiers mentionnés ci-dessus.
| Statistique | Valeur |
|---|---|
| Nombre total de stemmata | 254 |
| Minimum | 2 |
| Maximum | 59 |
| Moyenne | 16.67 |
| Médiane | 15.0 |
| Écart-type | 9.78 |
| 1er quartile (Q1) | 10.0 |
| 3e quartile (Q3) | 21.0 |
| Total | 'no' | 'yes' | '?' | 'yes?' |
|---|---|---|---|---|
| 254 | 158 | 94 | 1 | 1 |
| Total | 'no' | 'yes' | '?' |
|---|---|---|---|
| 254 | 238 | 14 | 2 |
91 stemmata présentent dans leur encodage au format « .gv » au moins un nœud sans label.
| Nœuds sans label | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 10 | 11 | 13 | 16 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Stemmata | 163 | 36 | 17 | 6 | 3 | 6 | 6 | 4 | 5 | 2 | 3 | 1 | 2 |
243 stemmata présentent dans leur encodage au format « .gv » au moins une incertitude (incertitude de lien et/ou incertitude de nœud).
Après réflexion, nous avons décidé de séparer la tâche 2 de transcription des stemmata en deux étapes. Le but de la première étape serait d’obtenir des transcriptions des stemmata au format .gv fidèles aux stemmas png d’origine. La seconde étape viserait à produire des encodages .gv conforment aux guidelines du projet OpenStemmata.
@Marie
L’exploration des données a été compliquée par la présence de plusieurs stemmata dans un même article, dont certains n’étaient pas pertinents pour l’analyse ou étaient purement illustratifs. Les informations sur les témoins étaient parfois clairement indiquées près du stemma, mais souvent éparpillées dans le texte ou les notes de bas de page, ce qui rendait leur repérage plus difficile.
- Site internet du projet OpenStemmata
- Jeu de données élargi de détection fourni
- Jeu de données pour la transcription et l'alimentation de métadonnées
- Guidelines d'OpenStemmata
- Edotor : éditeur libre pour encoder les graphes
Organisé par : Chahan Vidal-Gorène
Avec le soutien de l'ERC LostMa, la junior-entreprise CartaData, l'ANR, la chaire de professeur junior de l'École nationale des chartes-PSL, le département de la recherche, la direction des études et les services logistiques.
