El almuerzo gratuito escondido en tu codificador de visión: lo que SigLIP-HD hace bien

Un corredor pasa junto a un cartel a mitad de la carrera. El cartel dice "HOKA TIME TO FLY", anunciando la marca de zapatillas de running. Si alimentas esa foto a un modelo de visión-lingüístico de última generación y le preguntas qué dice el cartel, te devuelve: "HOOKA TIME TO FLY". No es un error tipográfico en la imagen. Es un error inventado por el modelo, porque a la resolución que estaba analizando, las letras se desenfocaron lo suficiente como para convertir un nombre de marca real en una palabra que no existe.

Ese es el modo de fallo que un nuevo artículo llamado SigLIP-HD está diseñado para corregir, y la solución es casi sospechosamente simple. No requiere imágenes más grandes. No necesita más potencia de cómputo en tiempo de inferencia. No introduce una nueva arquitectura. Solo es una forma diferente de entrenar el mismo codificador visual que ya está dentro de una gran parte de los modelos multimodales actuales. Los autores, de la Universidad de Hong Kong y el Shanghai AI Lab, obtienen mejoras significativas en OCR y comprensión de documentos con SigLIP 2 (un codificador de imágenes ampliamente utilizado) sin pedirle que analice ni un solo píxel adicional en tiempo de inferencia.

El instinto que todos tenemos, y por qué es más caro de lo que parece

Cuando un LLM multimodal (MLLM, un modelo que recibe imágenes y texto y genera texto como salida, como GPT-4V o LLaVA) malinterpreta texto pequeño, la solución obvia es proporcionarle una imagen más grande. Más píxeles de entrada, más tokens visuales de grano fino de salida y mayores probabilidades de capturar cada carácter. Esta es exactamente la dirección que ha tomado el campo: los sistemas tempranos como LLaVA redimensionaban todo a una imagen fija de 336×336, mientras que los más recientes como Qwen2.5-VL o InternVL intentan preservar la resolución nativa, a veces dividiendo un documento en una cuadrícula de mosaicos y ejecutando el codificador visual en cada mosaico por separado.

Funciona, pero no es gratis. Dividir una imagen en mosaicos implica múltiples pasadas hacia adelante a través del codificador para una sola entrada. Más mosaicos significan más tokens visuales fluyendo hacia el modelo de lenguaje, lo cual se encarece rápidamente ya que el costo del transformer escala con la longitud de la secuencia. Por ello, los sistemas agregan muestreadores o trucos de "pixel-unshuffle" para comprimir esos tokens nuevamente, lo que añade superficie de ingeniería y modos de fallo propios. Cada paso hacia arriba en resolución es un paso hacia arriba en latencia y costo, el tipo de problema que aparece como tiempos de espera agotados en producción mucho antes de que alguien actualice una cifra en un benchmark.

Los autores plantean una pregunta más aguda antes de comprometerse con ninguna de estas soluciones: ¿realmente hemos sacado todo el provecho de la resolución que ya estamos utilizando? Su ilustración es muy acertada. Tomemos una infografía alta, algo así como un póster deportivo cargado de estadísticas, con una altura nativa de 1722 píxeles. Reduzcámosla a una resolución "media" estándar de 512 píxeles. El texto se vuelve borroso. Un humano, entrecerrando los ojos ante la versión más pequeña, aún puede leer la mayor parte. Somos buenos reconstruyendo texto degradado a partir del contexto y formas de letras aproximadas. ¿Está un modelo visual realizando la misma reconstrucción, o simplemente... no está mirando lo suficiente lo que ya tiene? Si la respuesta es esta última, no necesitas una imagen más grande. Necesitas enseñar al modelo a extraer más información de la que ya está pagando.

Enseñar a una imagen barata a ver como una cara

El método se llama supervisión de fino a grueso, y una vez que ves el diagrama, te toma unos treinta segundos entenderlo. Comienza con un codificador SigLIP 2 preentrenado y congelado. "Congelado" significa que sus pesos están bloqueados y no se tocan durante este paso. Aliméntalo con la misma imagen a dos escalas: una versión base barata de 512×512 píxeles y una versión ampliada más cara de 1024×1024. Ambas pasadas producen una cuadrícula de vectores de características (piensa en estos como el resumen interno del modelo de lo que hay en cada pequeña porción de la imagen). La pasada de alta resolución obviamente captura más detalles finos, texto más pequeño, bordes más definidos, pero produce una cuadrícula más grande, una que no coincide con la forma de la versión barata.

Entonces, los autores reducen la resolución de la cuadrícula de características de alta resolución con una simple interpolación bilineal hasta que tenga la misma forma que la cuadrícula de resolución base, y luego simplemente promedian las dos, parche por parche. Ese resultado promedio es la característica "maestra": algo que ha visto genuinamente el detalle fino de la pasada cara, pero que está empaquetado en la misma forma que la salida barata.

Ahora viene el paso de entrenamiento real. Toma una segunda copia del mismo codificador preentrenado. Esta es entrenable, no congelada, y solo se le muestra la imagen barata de 512×512. Ajusta finamente para que las características que produce de esa única imagen barata coincidan con la característica maestra, parche por parche, usando una pérdida L1 simple (en resumen: minimiza la diferencia absoluta entre las dos cuadrículas de características). Sin etiquetas de texto, sin subtítulos sintéticos, nada anotado a mano. La "supervisión" aquí es el modelo enseñándose a sí mismo usando nada más que imágenes crudas en diferentes tamaños.

Después del entrenamiento, descartas por completo la configuración maestra multi-escala cara. Lo que queda es un único codificador que toma exactamente la misma entrada de 512×512, produce exactamente el mismo número de tokens y se integra en un MLLM como un intercambio de punto de control, pero ahora codifica, en sus pesos, cierta noción de cómo se habría visto la versión de mayor detalle de esa imagen. Misma entrada, mismo costo, mejor salida. Ese es todo el truco: destilación no de un modelo maestro separado y más grande (la configuración habitual en la destilación de conocimiento), sino del mismo modelo mirando más píxeles de la misma imagen.

También es barato de producir. Los autores lo entrenaron con 4.5 millones de imágenes durante 90,000 pasos, y toda la ejecución tomó 34 horas en 32 GPUs A100. Compara eso con el preentrenamiento de un codificador visual desde cero, que el papel señala puede consumir "millones de horas de GPU" y conjuntos de datos con mil millones de imágenes. Este es un paso de pulido ligero añadido a un codificador existente, no un nuevo modelo construido desde cero.

París - Mapa del Metro 1973 — por roger4336 vía flickr, BY-SA 2.0.

Lo que realmente reveló el ajuste de escalas y pérdidas

Antes de llegar a la receta final, los autores realizaron una serie de estudios piloto que valen la pena analizar, porque las respuestas son más interesantes que el simple "más grande es mejor".

Al probar entradas de una sola escala frente a múltiples escalas para la señal del modelo maestro, descubrieron que combinar una vista base de 512² con una vista ampliada de 1024² mejoraba el rendimiento en 10 de los 12 conjuntos de evaluación en comparación con usar cualquiera de las dos por separado. Sin embargo, añadir una tercera escala (1536²) o una cuarta (2048²) dejaba de aportar beneficios en la mayoría de los casos y, a veces, empeoraba los resultados. De hecho, una única vista de alta resolución, sin una vista base complementaria, rendía peor que la combinación. El modelo parece necesitar la vista global y gruesa junto con la vista local y detallada, no simplemente más detalles finos apilados.

También probaron cómo procesar una imagen de alta resolución cuando el codificador solo había sido entrenado con un tamaño fijo más pequeño. La solución intuitiva, tomada de tareas de predicción densa como la segmentación, consiste en deslizar ventanas superpuestas a través de la imagen para que ningún elemento importante quede incómodamente en el límite de un mosaico. Aquí, esto tuvo el efecto contrario: las ventanas no superpuestas resultaron vencedoras. Su mejor hipótesis es que las regiones superpuestas reciben un tratamiento inconsistente (algunos parches se "cuentan dos veces" de forma efectiva) o que los embeddings posicionales entran en conflicto cuando el mismo contenido aparece en más de una ventana. En cualquier caso, un poco de sabiduría previa de otro ámbito de la visión por computadora no fue transferible.

Y cuando se trató de combinar las características de múltiples escalas, la opción más simple ganó nuevamente: la interpolación bilineal para alinear las formas, seguida de un promedio simple sin ponderación, superó tanto a la concatenación por canales como al submuestreo mediante pixel-unshuffle. Incluso intentaron inclinar el promedio hacia las características de alta resolución específicamente para conjuntos de evaluación intensivos en detalles, como el VQA de documentos, bajo la teoría de que más detalles finos deberían ayudar más donde los detalles finos importan más. No fue así. Un promedio directo de 1:1 se mantuvo como el mejor en todo momento.

Los números reales y un par de errores de lectura corregidos

Al integrarse en la tubería de entrenamiento estándar de LLaVA con un LLM Vicuna de 7 mil millones de parámetros, utilizando los datos de ajuste de instrucciones más intensivos en OCR de LLaVA-NeXT, SigLIP-HD elevó DocVQA (un benchmark para leer texto en documentos escaneados) de 56.0 a 59.6, ChartQA (lectura de datos en gráficos y diagramas) de 61.6 a 65.2 y HRBench (un benchmark diseñado específicamente en torno a detalles visuales finos) de 43.5 a 48.3, todo frente a la línea base SigLIP 2, con un costo de inferencia idéntico. Promediado en todos los benchmarks probados, esa configuración de entrenamiento pasó de 62.8 a 64.4.

Las mejoras no fueron específicas de un solo LLM. Si se cambia por un Llama-3.2-3B más pequeño, ChartQA salta de 45.2 a 49.8; si se utiliza Qwen2.5-7B, DocVQA pasa de 62.5 a 64.2. Y no es solo una historia de SigLIP 2: al añadirse al codificador OpenAI CLIP mucho más antiguo de 2021, el mismo truco de autodescansado impulsó DocVQA de 22.4 a 33.2. Lo que sea que esté haciendo este método, no está atado a las peculiaridades de un codificador específico.

Dos resultados destacan como algo más que ruido en el ranking. Primero, el método se acumula con el enfoque de "usar simplemente la resolución nativa" (mosaico AnyRes) en lugar de competir con él. Aplicado sobre AnyRes, SigLIP-HD aún impulsó ChartQA otros 3.5 puntos. Segundo, y aquí es donde la afirmación del resumen del artículo aparece en la práctica: los ejemplos cualitativos del artículo incluyen la lectura errónea exacta de HOKA/HOOKA del inicio de este artículo, además de una foto de una pizarra donde el modelo de línea base lee un nombre manuscrito como "Brian Owens" y la versión ajustada obtiene correctamente "Bryan Owens". Pequeño, específico, el tipo de error que realmente aparece cuando se apunta una cámara a escritura a mano o un banner borroso en la vida real en lugar de una página escaneada limpia.

Por qué importa si estás construyendo o comprando un pipeline de OCR

La lección principal no se trata realmente de SigLIP en específico. Se trata de que la "resolución" y el "presupuesto de tokens", los números que los proveedores citan al describir un motor de OCR o de IA documental, no te dicen todo sobre cuánta información de la imagen está extrayendo realmente el modelo. Dos codificadores pueden tomar una imagen idéntica de 512×512, producir un número idéntico de tokens, costar lo mismo en tiempo de inferencia y, aun así, diferir en varios puntos en los benchmarks de documentos y gráficos simplemente debido a cómo se realizó el entrenamiento. Si estás evaluando motores solo por especificaciones de resolución y conteos de tokens, estás omitiendo una variable que importa tanto como las demás.

Prácticamente, esto también es una buena noticia para cualquiera que esté desplegando OCR a gran volumen en lugar de solo probarlo en un laboratorio. Los pipelines de mosaico de alta resolución son una forma legítima de capturar texto pequeño, pero multiplican las pasadas hacia adelante y los conteos de tokens, lo que a su vez multiplica la latencia y el costo por documento, un número real cuando se procesan miles de páginas al día. Una única pasada de ajuste fino autosupervisado de 34 horas que mejora la precisión sin afectar el costo de servicio es el tipo de cambio que es fácil de justificar y, notablemente, fácil de deshacer si no ayuda, ya que se trata de un cambio de checkpoint en lugar de una reestructuración arquitectónica.

La advertencia honesta, que los autores declaran claramente en lugar de ocultarla: esto no hace obsoleta la alta resolución nativa. Algunos detalles realmente se destruyen una vez que se reduce la resolución de una imagen; ninguna cantidad de entrenamiento inteligente recupera los píxeles que fueron promediados antes de que el modelo los viera. Lo que esto te ofrece es exprimir más precisión del presupuesto de resolución al que ya te has comprometido, lo cual, para los equipos que no pueden permitirse pasar cada documento por un costoso pipeline de múltiples mosaicos, podría ser la palanca más útil para tirar primero.