Vision Language Models dans Omeka

VLM

Historiquement les réseaux de neurones convolutionnels CNNs étaient privilégiés pour le deep learning appliqué aux tâches de computer vision, mais à l’instar des modèles de NLP pour les corpus textuels, les modèles d’IA dédiés à l’analyse d’images ont aussi amorcé une transition vers des architectures inspirées des Transformers, notamment avec l’émergence du Vision Transformer ViT (qui convertit des portions d'images en séquences de tokens) et ses nombreuses variantes (Swin Transformer, DeiT, etc.). Avec ces architectures permettant aux modèles de capturer des caractéristiques complexes et les relations spatiales dans les données visuelles, les modèles SOTA de vision pré-entraînés sur de grands corpus d’images offrent un haut niveau de performance et de précision pour des opérations de classification d’image, de segmentation, détection ou localisation d’objects.

Par extension, les Vision Language models (VLMs ) ont émergé, qui, combinant modèles de vision et modèles de langage, se positionnent à l’intersection de la computer vision et du NLP par leur multimodalité native et leur capacité à traiter texte, image fixe et animée. Selon la manière dont ils ont été pré-entraînés et/ou fine-tunés, ces VLMs peuvent être utilisés dans de multiples contextes et pour des tâches diverses, allant de la computer vision classique à l'interaction conversationnelle avec des contenus multimédias via des chatbots (image-to-text), en passant par de la génération d’images à partir d’instructions dans des systèmes combinés avec des modèles de diffusion (text-to-image), de l’extraction de données structurées ou encore de la transcription type OCR et HTR sur de larges quantités de documents même de qualité moyenne.

Comment fonctionne un VLM ? En règle générale, les VLMs combinent un LLM pré-entraîné avec un encodeur d’image associé. Le vision encoder génère des embeddings d’image qui sont ensuite projetés dans l’espace des embeddings de texte par un petit module complémentaire - un projecteur- , afin d’aligner les deux représentations vectorielles dans un espace commun. Il existe évidemment de nombreux vision encoders — c’est-à-dire des modèles capables de produire des embeddings visuels — , eux-mêmes pré-entraînés sur des paires image-texte pour capturer les correspondances sémantiques entre texte et image. Parmi les plus utilisés, on trouve notamment CLIP d'OpenAI, BLIP, ou DINOv2.

Source : https://arxiv.org/pdf/2501.02189

La stratégie suivie par les principaux fournisseurs privés de LLMs consistant à proposer des modèles de plus en plus puissants et multitâches, les principaux LLMs du marché sont donc dorénavant par nature multimodaux, mais à l’instar des modèles génératifs purement textuels, il existe un grand nombre d’autres VLMs open weights, facilement déployables localement et sans coût d’usage, car de taille beaucoup plus réduite, et disponibles sur HuggingFace. Parmi ceux-ci, on peut par exemple citer la famille des modèles SmolVLM proposant des variantes avec très peu de paramètres donc très portables (même sur smartphone), OlmoOCR pour la conversion de pdf en image et la transcription du texte, InternVL dont la version 3 introduit des capacités de raisonnement, ou encore Kimi-VL un des premiers modèles de vision et de raisonnement... Et de fait ces dernières années, les nouvelles possibilités offertes par les VLMs en termes d’approche méthodologique et d’outillage pour le traitement et l’analyse de corpus iconographiques a complètement relancé le champ des humanités numériques, en témoignent les recherches menées par le consortium PictorIA en France ou le Distant Viewing Lab aux USA.

Exemples d'utilisation de VLM sur des contenus numériques

La plupart des modèles déposés sur HuggingFace étant en général accompagnés d'espaces de démonstration, on peut facilement les tester sans aucune installation préalable.

Génération de description textuelle avec Qwen2.5-VL-7B-Instruct

HuggingFace space : https://huggingface.co/spaces/prithivMLmods/Qwen2.5-VL-7B-Instruct

Détection d'objets avec Florence-2

HuggingFace space : https://huggingface.co/spaces/gokaygokay/Florence-2

Segmentation avec Florence-2

HuggingFace space : https://huggingface.co/spaces/gokaygokay/Florence-2

QA et raisonnement avec Kimi-VL-A3B-Thinking

HuggingFace space : https://huggingface.co/spaces/moonshotai/Kimi-VL-A3B-Thinking

IA et Omeka

Les collections numériques patrimoniales et scientifiques mises en ligne via des bibliothèques numériques déployées sous Omeka (version Classic ou S) apparaissent comme des candidates idéales pour l’intégration de pipelines basés sur des modèles de vision, l’implémentation de fonctionnalités additionnelles étant favorisée par les caractéristiques open source et modulaire du framework Omeka.

Comme évoqué plus haut, les cas d’usage appliqués à des collections documentaires numérisées sont nombreux : OCR ou HTR à la volée lors de l’import de documents, classification d’images, enrichissement automatisé de la description ou de l’indexation de médias, ajout de moteur de recherche sémantique combinant embeddings de textes et d’images, clusterisation et recherche de similarités entre sets d’images de collections diverses… En théorie, il suffirait donc de développer et installer un plugin/module embarquant l'implémentation d'un VLM (ou d'un vision encoder selon son cas d'usage) dans Omeka afin d’augmenter, au choix, la production de métadonnées descriptives, la performance du moteur de recherche de contenus, la visualisation de données etc…, bref d'accroître notablement les possibilités d’exploitation et de recherche dans les contenus iconographiques. En réalité il est même étonnant qu’aucun module basé sur un VLM n’ait encore vu le jour dans la communauté Omeka (à ma connaissance du moins), alors même que les applications basées sur la conversion des images en embeddings se multiplient dans la recherche académique en humanités numériques (je pense par exemple aux applications Panoptic ou Aikon), témoignant de la plus-value de ces approches basées sur l’IA, et donc de la pertinence de les injecter dans un outil comme Omeka.

La raison principale tient probablement à l’architecture technique d’Omeka basé sur le socle PHP/MySQL : en effet, le PHP, langage serveur historique des applications web, couplé à la base de données relationnelle classique MySQL pour le stockage des données ne forment pas vraiment un contexte technique naturellement adapté pour la data science en général et l’IA en particulier, domaines où l’écosystème est massivement dominé par Python et, dans une moindre mesure, par JavaScript. Ainsi par exemple, il n’existe que très peu de bibliothèques php capables de réaliser une inférence locale sur des modèles de type Transformers, et les quelques solutions existantes se limitent à des clients d’interrogation de serveurs openai-like, c’est-à dire à du requêtage d’API Rest exposées pour l’inférence par des providers tels qu’OpenAI, Google, Mistral, Anthropic, DeepSeek, Openrouter…). L’hypothèse de l'inférence locale - avec un modèle hébergé localement - nécessiterait donc la mise en place d’une instance serveur dédiée additionnelle, exposée en HTTP via une API Rest locale (avec par exemple une solution de type Ollama, llama.cpp, Docker Hugging Face, etc.). Parallèlement, bien qu'il soit possible de stocker des vecteurs dans MySQL (sous des formats Blob ou JSON, ou avec le plugin expérimental mysql_vss), les performances en recherche sémantique sont rapidement limitées pour des corpus important et/ou des embeddings de grande dimension par rapport à celles des bases de données vectorielles spécialisées (Faiss, chroma, Qdrant, Milvus, LanceDB…), pour lesquelles par ailleurs les clients PHP sont quasiment inexistants.

Pour résumer, intégrer de l'IA via un VLM dans Omeka reste possible mais au prix de fortes contraintes techniques, soit en externalisant le modèle et le stockage vectoriel (posant ainsi des problèmes dépendances, voire de coûts) soit en installant et administrant des services complémentaires en local (souvent avec Docker) pour ces deux aspects, ce qui dépasse de loin la logique simple d'un module "clé-en-main" (“plug-and-play” pour reprendre les éléments de langage du moment ;)) et en tout cas limite pour l’instant l’usage démocratisé de telles approches dans la communauté Omeka.

Quelles solutions ?

De manière concrète et synthétique, voici un petit résumé des principales options envisageables avec Omeka (résumé non exhaustif, il manque par exemple les possibilités d'inférence maintenant offertes par le nouveau standard WebGPU des navigateurs et les environnements d'exécution optimisés pour le web) :

• Externalisation du VLM et de la base vectorielle chez des fournisseurs propriétaires (cloud) : un module PHP peut alors tout à fait interroger les API REST/GraphQL exposées par les services pour effectuer classification, recherche sémantique, génération de métadonnées, etc.

  • Points forts : rapidité de l’inférence, performance des gros modèles, pas de charge d’administration d’outil ou de service.
  • Points faibles : dépendance à des services externes, coûts de type pay-as-you-go, risques de fuite de données (notamment pour les contenus ayant vocation à rester en accès privé), nécessité de synchroniser les contenus entre la base MySQL d'Omeka et la base vectorielle externe.

• Gestion locale externe du modèle et des embeddings : déploiement et administration d'instances locales (par exemple via Docker), le module PHP interrogeant ces services exposés en API HTTP.

  • Points forts : maîtrise des processus d’inférence, liberté de choix des modèles et de l’architecture.

  • Points faibles : charge d'administration supplémentaire, besoin éventuel de serveur GPU selon les modèles utilisés, compétences techniques nécessaires en interne, nécessité de synchroniser la base MySQL Omeka avec la base vectorielle.

• Externalisation complète du traitement sur une plateforme tierce spécialisée : par exemple en utilisant Nomic Atlas (gestion d’embeddings, visualisation, enrichissement), avec des scripts périodiques d’export et de réimport de métadonnées enrichies dans Omeka. (une plateforme comme FiftyOne peut aussi être utilisée en complément pour explorer ou annoter les corpus.)

  • Points forts : qualité des embeddings et des visualisations proposées, peu de développement interne requis en dehors des scripts d’export-import.

  • Points faibles : dépendance à un service tiers, offre freemium limitée et pouvant évoluer, nécessité de développer une intégration spécifique des visualisations dans Omeka, mise à jour régulière à prévoir en fonction de l’évolution des contenus dans Omeka S

• Développement local d'une plateforme type "Nomic-like" auto-hébergée : mise en place d’une solution interne exposant ses propres APIs pour une intégration plus fluide dans Omeka, par iframe ou appel d'API backend.

  • Points forts : pleine maîtrise des traitements (choix des embeddings, du VLM, de la librairie de visualisation), personnalisation complète de l’intégration.

  • Points faibles : besoins en compétences internes (backend, infrastructure), nécessité d’un serveur supplémentaire à administrer, synchronisation des contenus à prévoir

En illustration de ce billet, une application "Nomic-like" est déployée sur HuggingFace, qui permet de moissonner des contenus et leurs médias (par collections) à partir d'instances Omeka S, de convertir les métadonnées et images en embeddings, les clusteriser, les visualiser en scatter plot, et d'effectuer des recherches en langage naturel. La conversion en embeddings n'est pas optimisée et l'application est loin du niveau de Nomic mais permet tout de même d'expérimenter ce genre de workflow.

Lien vers l'application : https://huggingface.co/spaces/Geraldine/omeka-s-computer-vision

Les quelques collections existantes ont été moissonnées à partir de la bibliothèque numérique Hum@zur d'Université Côte d'Azur.

• Intégration artisanale, limite bricolage (hybride) : en développant un module Omeka qui appelle en PHP des exécutables externes produits à partir de scripts Python (par exemple avec pyinstaller), ou en utilisant des solutions légères comme llamafiles pour exécuter localement des modèles en CLI, soit encore des services ultra-légers exposant des APIs locales HTTP (par exemple avec Ollama ou llamafiles).

  • Points forts : intégration complète au sein d’Omeka, respect de la philosophie modulaire et open source du framework.

  • Points faibles : complexité de développement, besoin de gérer les compatibilités multi-plateformes pour les exécutables, maintenance supplémentaire.