vEADette: une ébauche d’application d’audit et d’indexation des instruments de recherche pour les archivistes

Dans ce très court article, je vous présente un projet que j’ai réalisé en deux semaines, il y a une paire de mois : l’application vEADette, dédiée à l’audit et l’indexation d’instrument de recherche en XML/EAD. Bien que je ne sois pas particulièrement fier de ce projet — inabouti car fait dans un temps imparti –, je trouve que ce défi que je me suis lancé a malgré tout quelques mérites : il propose des éléments de réponse techniques relatifs au besoin d’indexation des IR (avec des bases de données vectorielles; de la sortie structurée via LLM mais aussi des « simples » Regex). Il nourrit également des aspects plus stratégiques avec une partie « audit » (Archifiltre aura été une source d’inspiration !)

NB: La partie « front-end » (la partie visuelle) a été « vibe-codée », mais la logique derrière (le « back-end ») a été faite à la main.

vEADette est une ébauche d’application d’indexation automatique et d’audit des instruments de recherche en XML/EAD. Automatique car l’analyse et l’extraction sémantique emploie un LLM pour l’analyse de corpus d’instruments de recherche; et contrôlée car la génération des données repose sur l’emploi du vocabulaire fixé par les thésaurus réglementaires et les notices d’autorité permettant à la fois de se prémunir des hallucinations et de s’aligner sur les référentiels.

vEADette est conçu pour établir, à l’échelle d’un service d’archives, un rapport statistique afin de fournir des éléments statistiques sur les pratiques d’indexation et une indexation minimale des instruments de recherche au niveau haut.

Il faut considérer cette application à la fois comme une manière d’expérimenter les méthodes récentes de génération ou sortie structurée par LLM pour les problématiques d’indexation; et de proposer une solution concrète d’indexation automatique de corpus d’instruments de recherche de taille moyenne.

1. Problématique : indexer des instruments de recherche pour le web

L’indexation s’inscrit dans les enjeux de valorisation des fonds et ceux des nouvelles pratiques de recherche. Il est question de valorisation car une bonne indexation permet la « découvrabilité » des fonds d’archives — et donc de leur exposition au public –; et des « nouvelles pratiques de recherches » car la recherche documentaire n’implique plus seulement de fréquenter les instruments de recherche en salles de lecture, mais aussi de préparer sa visite en amont, par la recherche en ligne.

Il faut donc fournir, pour chaque instrument de recherche, des voies d’accès thématiques, géographiques ou bien nominatives (noms d’entreprises, personnes, familles, etc.). L’indexation est cette « condition préalable pour fournir un point d’accès sûr et vérifié à l’information en utilisant des notions clairement définies, représentées par des termes eux-mêmes soigneusement choisis et contrôlés » (Guide de l’indexation pour le web). Concrètement, cette indexation repose sur un ajout ou l’alignement des balises appropriées (origination, controlacess, subject, persname, corpname, famname, etc.) au regard des référentiels réglementaires publiés par le SIAF. Parmi ces référentiels, mentionnons le thésaurus matière, publié notamment sous format .rdf.

J’ai d’ailleurs implémenté ce thésaurus matière sous format de classes Python; mais aussi sous forme de représentations vectorielles pour la recherche sémantique. Voir ce projet annexe :

Aux problématiques d’accès proprement dites, s’ajoutent celles, plus globales, des politiques d’indexation, exigeant une main d’œuvre et du temps pour reprendre les instruments de recherche. Mais cette reprise doit être fait à la lumière des thésaurus, des formes autorisées et la désambiguïsation des termes grâce aux URIs. Si ce que les progrès récents de l’ »intelligence artificielle » (concrètement : les modèles Bert et les LLMs) permettent, à première vue, d’apporter de nouvelles solutions pour indexer ou retoucher de façon industrielles des instruments de recherche, leur utilisation n’en reste pas moins sources de nouveaux problèmes techniques. Pour avoir une vue d’ensemble de ce qui est producteur de ces problèmes techniques (granularité disparate ou nulle des IR; balises mal utilisées), une phase d’audit est indispensable. C’est la raison pour laquelle vEADette a été pensé comme outil d’audit et d’indexation automatique, basé sur une utilisation particulière des LLMs. L’interface se veut simple pour se concentrer sur l’essentiel.

Parmi les outils sources d’inspiration, je mentionne évidemment Archifiltre.

2. Démonstration vidéo

3. Fondements techniques de l’indexation via la sortie structurée par LLM

L’application repose aussi bien sur des algorithmes basiques d’extraction de données (ReGex) que sur des approches plus modernes pour extraire le sens et le contexte des instruments de recherche, à savoir la sortie structurée via LLM.

La sortie structurée consiste ici à contraindre la génération de texte du LLM avec un nombre restreint de choix (ici implémentée en Python avec des classes Pydantic et le résultat d’extractions via Regex) et avec un format (JSON). Grâce à cette méthode, le LLM ne peut répondre: 1) qu’avec des champs imposés (par exemple les matières du thésaurus-matière); 2); faire des choix parmi des portions de texte qui lui auront été soumis. Cette méthode l’empêche le LLM d’halluciner — ce qui n’exclut pas la possibilité qu’il se trompe en catégorisant. Mais couplé aux embeddings, on peut recouper les résultats pour obtenir des valeurs pertinentes.

Il y a plusieurs façon d’extraire la sémantique de données : il y a les modèles Bert qui permettent, pour chaque token (ou mot) de les classifier selon une réserve « d’étiquettes ». Par exemple, cela permet de détecter le sujet ou le verbe d’une phrase; voire, selon le modèle choisi et s’il a été entraîné pour cela, détecter les métiers, les entités nommées. Cette approche qui consiste à « étiqueter » chaque mot, à peu à la façon d’un balisage, requiert une phase d’entraînement qui peut reporter leur mise en application concrète pour répondre à des besoins particuliers — par exemple ceux de l’archiviste. Cette approche n’a pas été choisie ; mais pourra t-être employée ultérieurement pour renforcer le contrôle des données.

L’utilisation d’un LLM (Mistral 8b) que l’on peut employer via des APIs (grosso-modo des services mis à disposition via internet) a été l’option choisie car les modèles mis à disposition sont suffisamment performants pour se passer d’une phase d’entraînement. Ils sont prêts à être utilisés.

Dans vEADette, la sortie structurée est employée pour la détection du producteur de thématiques, des entités géographiques, des institutions.

vEADette repose aussi sur des méthodes plus classiques d’embeddings pour la détection des thématiques et l’attribution des fiches d’autorité au regard du producteur du fonds. Cela consiste à « vectoriser » la sémantique des mots et de calculer entre eux leur proximité. L’ensemble des notices d’autorités des producteurs de France Archives ont été récupérées via SPARQL puis vectorisées. vEADette embarque donc une base de donnée vectorielle pour effectuer des recherches.

4. Améliorations

L’application a été développée en peu de temps; un travail sur le plus long terme permettrait de consolider les processus d’analyse; l’interface utilisateur; et d’établir une indexation fine sur l’ensemble des entités indexables, au regard d’une politique d’indexation choisie. Des fonctionnalités, plus orientées sur la normalisation/alignement des IR sur un modèle générique sont aussi envisagées. L’accent a été mis sur la détection du producteur du fonds, car connaître cette information permet de contraindre plus efficacement et d’affiner l’indexation à un niveau plus fin si on en connaît la nature de l’activité.

Il pourrait être intéressant, côté attribution des URI, de sélectionner des entités avec des autorités provenant de la BnF, Wikidata ou VIAF, en plus de France Archives.

Il pourrait être intéressant de proposer également la génération de fiches EAC à partir de la notice producteur le plus proche.

Enfin, il pourrait être intéressant de se reposer sur des plus petits modèles, spécialisés; et d’employer un contrôle encore plus stricts en contrôlant directement les probabilités de chaque mot généré par un LLM (logits) en lui imposant par exemple des graphes.

L’idée d’intégrer par défaut une base de données vectorielle représentant les autorités de France Archives reste une bonne idée; mais l’APIfication de cette feature pourrait être intéressante afin d’éviter d’avoir une application trop monolithique.

Les pistes d’utiliser les graphes de connaissances et les thésaurus pour conduire la sortie structurée est une piste qu’il me faudrait suivre. S’appuyer sur l’ontologie de Wikidata ou de l’IGN pour mieux saisir le contexte de production des archives décrites dans les IR est aussi à creuser.

Auto-critique

Je me suis lancé dans ce projet sans trop savoir exactement où j’allais — dans le sens où j’ai priorisé des choses qui ne l’étaient pas forcément. Un signe de cela : le projet pèse assez lourd et l’application, compilée, pèse 3 bons Go (ouch…). La faute à une mauvaise gestion des dépendances due aux tâtonnements; aux bases de données vectorielles et surtout d’Electron qui pèse déjà son poids. Mais cela donne des bonnes bases pour une future application. L’erreur aura été de commencer par l’implémentation de la recherche automatique des entités nommées au lieu de commencer par la datavisualisation, qui a mis à plat les différentes catégories de lacunes des instruments de recherche à (ré)indexer.

Si c’était à refaire, je ne passerais pas forcément par Python (Flask) ET Electron. L’idée de faire une application compilée est intéressante, notamment si l’application s’adresse aux archivistes. Mais elle pose de vrais défis UX, difficiles à assumer seul — d’où, d’ailleurs, le recours au vibe-coding pour la partie frond-end, ce qui n’est pas sans poser problème du côté lisibilité du code. Produire des briques de fonctionnalités disjointes, à la manière de CLIs spécialisées et robustes (par exemple réalisées en Golang), pourrait être une piste pertinente, mais cela est inapproprié pour les archivistes. Ce serait alors un outil dédié aux archivistes ayant des bonnes bases en informatique capable d’utiliser un terminal voire modifier du code.

En tout cas la dimension graphique — la destination user-friendly du projet –, de fait, complique largement le développement et ne serait à envisager seulement a posteriori un outil en ligne de commande déjà robuste. Évidemment, pour avoir un livrable très correct aussi bien du côté front que back, un travail en équipe serait idéal !

En tout cas, cela m’a donné la possibilité de me faire la main sur les référentiels, les autorités et les thésaurus !

Bibliographie

, , ,

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *