Investigadores añaden regiones de interés al token CLS de DINOv2 para la búsqueda de imágenes

Los autores del preprint arXiv:2610.10991 proponen una forma de sacar a DINOv2-reg más partido del que ofrece un único vector [CLS]. A los cinco tokens semánticos del modelo (el [CLS] global y cuatro register tokens) añaden tokens ROI locales. La búsqueda sigue un esquema multi-vector inspirado en ColBERT. En lugar de un solo descriptor por imagen, se obtiene un pequeño conjunto, y no es necesario almacenar los embeddings de todos los patches. El código está publicado en GitHub.

Por qué un solo descriptor se queda corto

El pipeline estándar de búsqueda de imágenes con un vision transformer es sencillo: se procesa la imagen, se toma el [CLS] y se compara por similitud del coseno. Para una búsqueda semántica gruesa («encuentra playas») basta. En tareas fine-grained (especies de animales cercanas, modelos de aparatos, productos parecidos) la cosa se complica. Las diferencias están en los detalles pequeños, y el vector global tiene que empaquetar todo el contenido del encuadre de golpe. Los autores afirman explícitamente que esta compresión perjudica la calidad de la búsqueda.

Otros enfoques abordan el problema con detectores externos, bounding boxes o módulos de saliency. Eso supone componentes de más, errores de más y anotación adicional. Aquí se ha elegido otro camino.

Cómo funciona el método

La base del método es DINOv2-reg, la variante de DINOv2 con register tokens. Según los autores, durante el entrenamiento estos tokens empiezan a codificar por sí solos objetos y sus partes. Cada uno de los cinco tokens semánticos ([CLS] y cuatro register) actúa como una «pista» (cue). Para cada pista se busca un «compañero» (buddy): el patch token que mejor se corresponde con la región espacial que esa pista describe. Alrededor del compañero se toma una ventana de N×N patches, que se agrega en un token ROI local.

Un detalle importante: las regiones de interés se encuentran de forma automática, únicamente emparejando los tokens semánticos con sus representaciones espaciales. No hay cajas externas ni módulos de detección de relevancia.

Después entra en juego la idea de ColBERT. La consulta y el documento se representan como conjuntos de vectores, y la similitud se calcula mediante una alineación token a token (late interaction). Así se conserva una comparación fina, pero el índice no se infla hasta cientos de embeddings de patches por imagen.

• Backbone: DINOv2-reg, cinco tokens semánticos ([CLS] + 4 register).
• Para cada «pista» se construye su propio token ROI a partir de una región de N×N patches.
• No hacen falta detectores, bounding boxes ni módulos de saliency.
• Búsqueda: multi-vector con alineación token a token, como en ColBERT.
• El código es abierto; el repositorio figura en el abstract.

Qué mostraron los experimentos

Los autores formulan tres conclusiones. Primera: los register tokens sí almacenan detalles finos útiles y complementan al [CLS]. Segunda: los tokens ROI obtenidos mediante pooling automático mejoran además la distinción entre clases cercanas. Tercera: la búsqueda multi-vector con pocos tokens supera a la variante base de un solo vector sobre DINOv2-reg y sigue siendo aceptable para la búsqueda a gran escala.

Conviene señalar de entrada una limitación. El abstract no incluye métricas concretas: ni la mejora en Recall@K, ni mAP, ni los nombres de los benchmarks. La magnitud del efecto solo puede valorarse con el texto completo y las tablas del artículo. La afirmación sobre una escala «tractable» también requiere comprobarse con el volumen de datos propio.

Dónde se puede aplicar

El método interesa en la práctica a quienes construyen búsqueda visual sobre catálogos: e-commerce, colecciones de museos, archivos biológicos y médicos. En esos casos, las diferencias pequeñas separan el resultado buscado de uno casi correcto. La ventaja del enfoque es que se monta sobre un DINOv2-reg ya listo: no es obligatorio reentrenar el backbone desde cero, basta con añadir la etapa de extracción de tokens.

El coste se conoce de antemano: en lugar de un vector por imagen habrá que almacenar varios. Si se construye un token ROI para cada una de las cinco pistas, salen del orden de diez vectores (estimación a partir de la descripción del método; la cifra exacta depende de la configuración). El índice crecerá, y la base de datos vectorial debe admitir consultas multi-vector con scoring tipo MaxSim. Antes de implantarlo conviene ejecutar el repositorio con el propio dataset y comparar la mejora de precisión con el aumento del coste de almacenamiento y de la latencia.