SaMer supprime 93% des tokens visuels de ColPali sans perte de rappel

Un papier passé sur Hugging Face Papers s'attaque à un goulot d'étranglement très concret des systèmes de recherche vision-langue de nouvelle génération : le coût de stockage et de scoring des index à interaction tardive comme ColPali ou ColQwen2, qui gardent des centaines à un millier d'embeddings par image pour comparer chaque token de requête à chaque patch visuel via MaxSim.

La méthode proposée s'appelle SaMer. Plutôt que d'élaguer les tokens visuels ou de les regrouper uniquement par similarité de features, elle les fusionne en K centroïdes en utilisant les annotations d'objets comme *prior* d'assignation pendant l'entraînement, pour éviter que des tokens issus d'instances différentes du même objet ne s'effondrent dans le même représentant. Fait notable, ces annotations ne servent qu'à l'entraînement : à l'inférence, SaMer n'a besoin ni de bounding boxes ni de détecteur, et seule la couche de projection partagée est adaptée, les backbones vision et langue restant gelés.

Les chiffres sont ceux que revendiquent les auteurs. Avec K=64, SaMer retire plus de 93 % des tokens visuels et réduit le stockage image de ColPali d'un facteur 16,09. Sur Flickr30K, le R@1 monte de 77,0 à 82,4 pour ColPali et de 73,6 à 79,3 pour ColQwen2. Sur MSCOCO, en cross-dataset, il passe de 47,4 à 51,6 sur ColPali. Sur ImageCoDe, qui teste la discrimination entre images visuellement proches, R@1 passe de 5,4 à 5,9. Les baselines comparées (H-Pool, HPC, SAP) sont battues au même budget de 64 tokens.

La caveat honnête vient du papier lui-même. Sur DocVQA, où la recherche repose sur des tokens OCR et la mise en page plutôt que sur des objets, SaMer n'est pas conçu pour briller : son R@1 (45,7) reste sous ColPali non compressé (51,0). L'adaptation n'a été menée que sur Flickr30K-Entities, en trois époques, ce qui laisse la généralisation à des domaines très spécialisés à démontrer. Et ce que le papier ne chiffre pas, c'est le gain de latence de scoring à index de production, seulement la compression de l'index côté stockage.

Ce qui rend le résultat intéressant à surveiller, c'est que le code est publié sur github.com/dmis-lab/SaMer et se branche sur des retrievers multi-vecteurs existants. Pour une équipe qui pousse un RAG multimodal en prod sur du contenu naturel, l'ordre de grandeur du gain justifie un essai rapide, avec un A/B test soigneux dès que le domaine s'éloigne des images naturelles.