Des chercheurs enrichissent le jeton CLS de DINOv2 avec des régions d'intérêt pour la recherche d'images

Les auteurs du préprint arXiv:2610.10991 proposent une méthode pour tirer de DINOv2-reg plus que ce que donne un seul vecteur [CLS]. Aux cinq jetons sémantiques du modèle (le [CLS] global et quatre register-tokens), ils ajoutent des jetons ROI locaux. La recherche repose sur un schéma multi-vecteur inspiré de ColBERT. Au lieu d'un seul descripteur par image, on obtient un petit ensemble de descripteurs, sans avoir à stocker les embeddings de tous les patchs. Le code est publié sur GitHub.

Pourquoi un descripteur unique ne suffit pas

Le pipeline standard de recherche d'images avec un vision transformer est simple : on passe l'image dans le modèle, on prend le [CLS] et on compare par similarité cosinus. Pour une recherche sémantique grossière (« trouve des plages »), cela suffit. Pour les tâches fine-grained (espèces animales proches, modèles d'appareils, produits similaires), c'est plus compliqué. Les différences tiennent à de petits détails, alors que le vecteur global doit condenser d'un coup tout le contenu de l'image. Les auteurs écrivent explicitement que cette compression nuit à la qualité de la recherche.

D'autres approches contournent le problème avec des détecteurs externes, des bounding boxes ou des modules de saillance (saliency). Cela ajoute des composants, des sources d'erreur et des besoins d'annotation supplémentaires. Ici, les auteurs ont choisi une autre voie.

Comment fonctionne la méthode

La méthode s'appuie sur DINOv2-reg, la variante de DINOv2 dotée de register-tokens. Selon les auteurs, ces jetons se mettent d'eux-mêmes, au fil de l'entraînement, à encoder des objets et leurs parties. Chacun des cinq jetons sémantiques ([CLS] et quatre register) joue le rôle d'un « indice » (cue). On lui associe un « binôme » (buddy), c'est-à-dire le patch-token qui correspond le mieux à la région spatiale décrite par cet indice. Autour du binôme, on prend une fenêtre de N×N patchs, qui est agrégée en un jeton ROI local.

Détail important : les régions d'intérêt sont trouvées automatiquement, uniquement en mettant en correspondance les jetons sémantiques et leurs représentations spatiales. Il n'y a ni cadres externes ni modules d'extraction de saillance.

Vient ensuite l'idée de ColBERT. La requête et le document sont représentés par des ensembles de vecteurs, et la similarité est calculée par un alignement jeton à jeton (late interaction). La correspondance fine est ainsi préservée, sans que l'index gonfle jusqu'à des centaines d'embeddings de patchs par image.

• Backbone : DINOv2-reg, cinq jetons sémantiques ([CLS] + 4 register).
• Pour chaque « indice », un jeton ROI propre est construit à partir d'une région de N×N patchs.
• Les détecteurs, les bounding boxes et les modules de saillance (saliency) ne sont pas nécessaires.
• Recherche : multi-vecteur avec alignement jeton à jeton, comme dans ColBERT.
• Le code est ouvert ; le dépôt est indiqué dans l'abstract.

Ce que montrent les expériences

Les auteurs tirent trois conclusions. Première : les register-tokens conservent bien de petits détails utiles et complètent le [CLS]. Deuxième : les jetons ROI obtenus par pooling automatique améliorent encore la distinction entre classes proches. Troisième : la recherche multi-vecteur avec un faible nombre de jetons surpasse la base de référence à vecteur unique sur DINOv2-reg, et reste acceptable pour une recherche à grande échelle.

Il faut d'emblée signaler une limite. L'abstract ne donne aucune métrique précise : ni gain en Recall@K, ni mAP, ni noms de benchmarks. On ne peut évaluer l'ampleur de l'effet que dans le texte complet et les tableaux de l'article. L'affirmation d'une échelle « tractable » demande aussi à être vérifiée sur ses propres volumes de données.

Où l'appliquer

La méthode intéresse en pratique ceux qui construisent une recherche visuelle sur des catalogues : e-commerce, collections de musées, archives biologiques et médicales. Dans ces cas, ce sont de petites différences qui séparent le bon résultat d'un résultat presque correct. L'approche a un avantage : elle se greffe sur un DINOv2-reg existant. Réentraîner le backbone from scratch n'est pas obligatoire ; il suffit d'ajouter une étape d'extraction des jetons.

Le prix à payer est connu d'avance : il faudra stocker plusieurs vecteurs par image au lieu d'un seul. Si un jeton ROI est construit pour chacun des cinq indices, cela fait de l'ordre de dix vecteurs (estimation d'après la description de la méthode ; le nombre exact dépend de la configuration). L'index grossira, et la base vectorielle devra prendre en charge les requêtes multi-vecteurs avec un scoring de type MaxSim. Avant tout déploiement, il est judicieux de faire tourner le dépôt sur son propre jeu de données et de comparer le gain de précision à la hausse du coût de stockage et de la latence.