Recherche d’images hybride à grande échelle : SigLIP, SPLADE, YOLOv8 et Gemini Captions

La correspondance des mots-clés sur les balises ne suffit pas pour gérer les images. Les équipes qui créent des catalogues de e-commerce, des outils de gestion de contenu ou des bibliothèques d’actifs numériques souhaitent un système de recherche capable de comprendre ce que montre une image, son style et son ton émotionnel, et non seulement les mots saisis dans un champ de balise. La conception présentée ci-dessous décrit un système hybride de recherche d’images qui récupère des informations dans un répertoire comptant environ un million d’images en utilisant à la fois du contenu visuel et des requêtes textuelles, construit principalement à partir de services d’IA existants afin de limiter les efforts de développement.

L’architecture combine plusieurs composants spécialisés. Ceux-ci sont présentés ci-dessous dans l’ordre du flux des données : les embeddings, l’analyse d’images, la génération de descriptions, le traitement des requêtes et les opérations.

Deux modèles d’embeddings

Le système repose sur deux pipelines d’embeddings distincts, chacun capturant un aspect différent du contenu.

Les images utilisent SigLIP. Après avoir évalué également CLIP et ImageBind, SigLIP s’est avéré supérieur. Il s’agit d’un modèle contrastif image-text entraîné avec une perte sigmoïde, et les résultats rapportés indiquent une précision top-1 sur ImageNet en mode zero-shot d’environ 76 %, soit quelques points de plus que les modèles CLIP comparables. Il consomme également moins de ressources informatiques, d’environ 40 % de moins selon la comparaison citée ici, et il généralise à de nouveaux domaines sans nécessiter de retouche fine. Chaque image devient un vecteur dense dans un espace où les points proches se ressemblent.

Le texte utilise SPLADE v2. SPLADE génère des vecteurs sparses liés directement à un vocabulaire, ce qui offre trois avantages :

• La sortie sparsa reste interprétable, car chaque dimension correspond à un terme réel.
• Il étend automatiquement les requêtes sur le plan lexical, atténuant les incohérences de vocabulaire qui entravent la récupération d’informations (« sofa » versus « couch »).

Puisque les dimensions sont des termes, il est possible de remonter aux mots exacts qui en sont la cause, ce qui facilite l’explication des résultats.

Comprendre chaque image

Les pixels bruts sont transformés en couches d’informations exploitables au cours d’un processus en plusieurs étapes.

Détection d’objets avec YOLOv8. YOLO analyse l’ensemble de l’image en une seule passe du réseau, ce qui le rend bien plus rapide que les détecteurs à deux étapes tels que Faster R-CNN. Dans cette configuration, la version optimisée nécessite en moyenne environ 50 ms par image, ce qui permet un agrégement efficace. Il atteint un score mAP de 53,9 % sur COCO pour 80 classes courantes, et le modèle s’adapte facilement à un cluster de GPU.

Des classes génériques aux entités nommées. La détection produit des étiquettes telles que personne, voiture et bâtiment. Les recherches avancées nécessitent des identités spécifiques, c’est pourquoi un service d’entités web les convertit :

Example Transformation:

YOLO: "person" (coordinates: [120, 45, 220, 320])
Web Extraction: "Elon Musk" (confidence: 0.96)

YOLO: "building" (coordinates: [50, 100, 400, 600])
Web Extraction: "Eiffel Tower" (confidence: 0.92)

Cette plateforme reconnaît plus de cinq millions d’entités appartenant à des catégories telles que les personnalités publiques, les lieux emblématiques, les produits et marques, ainsi que les événements. Cette étape relie la détection visuelle à la compréhension du sens. Une recherche concernant un chanteur en particulier fonctionne alors, au lieu d’une requête générique pour une personne.

Étiquettes issues d’une API de vision. Les concepts généraux, les activités et les thèmes proviennent de la détection d’étiquettes, qui a permis, lors des tests, de reconnaître plus de 10 000 concepts distincts dans l’ensemble des données. Cela aide pour trois choses : les activités telles que la randonnée ou la cuisine, les scènes comme la plage ou la forêt, ainsi que des objets trop spécifiques pour les catégories de YOLO, comme un cappuccino que YOLO ne désigne que par « tasse ».

Recherche sécurisée. Le contenu est marqué selon cinq critères : contenu pour adultes, violence, aspects médicaux, contenus falsifiés (mèmes et images modifiées) et contenu suggestif. Chaque critère est associé à un score de fiabilité, ce qui permet d’adapter le filtrage en fonction des politiques de l’organisation. L’automatisation de cette étape a remplacé une grande partie des vérifications manuelles.

Gemini pour les métadonnées et les descriptions

Gemini génère des métadonnées structurées. Une conception minutieuse des instructions a permis d’élaborer un modèle capable d’extraire de manière fiable 25 attributs, chacun accompagné d’un score de fiabilité allant de 0 à 1, tels que le niveau de sensibilité ou l’émotion exprimée :

System: You are an expert image analyzer. Extract the following attributes from the image, with a confidence score (0-1):

1. sensitivity (none, low, medium, high)
2. emotion (neutral, joy, sadness, surprise, etc.)
3. emotion_triggered (yes/no)
4. text_overlay (yes/no)
5. has_frames (yes/no)
6. has_religious_symbols (yes/no)
7. has_scattered_objects (yes/no)
8. style (photographic, illustrated, cartoon, abstract, etc.)
9. has_crowd (yes/no)
...
[full list of 25 attributes]

Response format: JSON object with attributes as keys and values as described above.

Les résultats combinés de la détection, des entités, des attributs et des métadonnées alimentent ensuite un deuxième prompt Gemini qui rédige une description complète. La conception du prompt est très importante ici, car les descriptions doivent être :

1. Riches en mots-clés, ce qui facilite la recherche de texte.
2. Consistantes dans leur structure, afin qu’elles puissent être analysées de manière fiable.
3. Significatives dans leur contexte, en montrant pourquoi les entités détectées sont importantes.
4. Conscientes des attributs tels que l’émotion et le style.
5. Rédigées en tenant compte des termes de recherche probables.

Le modèle ressemble à ceci :

Generate a comprehensive, search-optimized description for this image based on the following data:

[Entity data from object detection and recognition]
[Label data from Vision API]
[Structured metadata from previous Gemini analysis]

Your description should:
1. Begin with the most significant entities and their actions/relationships
2. Include key visual attributes (colors, style, composition)
3. Mention emotional tone and aesthetic qualities
4. Incorporate likely search terms
5. Be 3-5 sentences in length

Tenez d’abord compte des données brutes de détection :

Objects: person (0.98), guitar (0.95), microphone (0.92)
Entities: Taylor Swift (0.97)
Labels: concert, performance, stage, entertainment
Metadata: emotion=joy, has_crowd=yes, style=photographic, dominant_color=purple

Après enrichissement, il devient une phrase pouvant être recherchée :

Taylor Swift performs energetically on stage with an acoustic guitar during a concert, singing into a microphone with passionate expression. The image captures the excitement of a live performance with purple stage lighting creating a vibrant atmosphere. This high-quality photograph conveys feelings of joy and excitement, with Swift's iconic performance style clearly visible. The composition includes partial views of an enthusiastic crowd in the foreground, making this suitable for music, entertainment, and celebrity content.

Ces types de descriptions contiennent beaucoup de contenu pouvant être recherché, conservent leur sens dans le contexte, incluent des attributs visuels et émotionnels, et reflètent ce que les utilisateurs sont susceptibles de taper.

Réponse à une requête

Les requêtes passent par six étapes :

1. Analyse. La classification de l’intention détermine si l’utilisateur souhaite des entités spécifiques, des styles, des émotions ou d’autres attributs.
2. Extraction des entités. Les entités nommées dans la requête sont comparées à la base de données d’entités afin qu’elles reçoivent le poids approprié.
3. Encodage. La requête est encodée à l’aide de SPLADE v2 et SigLIP, de manière similaire à la représentation des images.
4. Recherche vectorielle. L’encodage de la requête permet de récupérer les encodages d’images les plus proches à partir de l’index.

Filtrage des politiques. Des règles spécifiques à la région et au niveau de l’organisation s’appliquent : des seuils de sécurité adaptés à la région de l’utilisateur, une protection de la marque, un filtrage approprié au âge ainsi que des droits d’autorisation.

Réclassement. Plusieurs facteurs ajustent l’ordre de la première sélection :

• Diversité, grâce à un algorithme gourmand qui maintient une distance cosinus minimale entre les images choisies.
• Récence, en donnant plus de poids aux éléments les plus récents via un décrochage temporel : score_boost = base_score * (1 + alpha * exp(-beta * days_old)).
• Popularité, en utilisant un atténuation logarithmique afin que les éléments très fréquemment utilisés ne dominent pas.
• Règles métier pour des ajustements spécifiques au domaine.

Deux problèmes difficiles

Latence. La chaînage de plusieurs piles de services entraîne des retards, et les premières mesures ont montré plus de quatre secondes pour le traitement complet d’une image. Les solutions mises en œuvre ont inclus des appels parallèles asynchrones, le regroupement des tâches pour les pipelines non interactifs, le regroupement des services pour réduire le temps de transmission réseau, ainsi que la segmentation du travail en fonction de la complexité des images. Le temps moyen est passé à 850 ms par image, avec 95 % des images traitées en moins de 1,2 seconde.

Complexité d’intégration. Chaque service dispose de sa propre API, de son propre comportement en cas d’erreur et de son propre profil de performance. Une couche d’abstraction unifiée, dotée d’un traitement cohérent des erreurs, de mécanismes de protection et de solutions de secours par service, de métriques d’état pour chaque dépendance, ainsi qu’une dégradation progressive, ont permis au système de continuer à fonctionner en cas de pannes partielles.

Résultats et prochaines étapes

L’investissement dans des services d’IA gérés s’est avéré payant. Le développement a duré quatre mois, contre une estimation de plus de douze mois pour une solution personnalisée ; la satisfaction concernant les résultats de recherche a augmenté de 40 %, tandis que le marquage et la catégorisation manuels ont diminué de 80 %.

Diverses pistes restent à explorer : la personnalisation en fonction du comportement de l’utilisateur, le perfectionnement interactif des résultats, les requêtes combinant texte et images, des boucles de feedback apprenant à partir des clics, ainsi que l’ajustement fin des modèles d’embedding pour des secteurs spécifiques.