Omitir las capas de visión funciona, hasta que le pides que lea texto

Pregunta a un modelo de visión-lingüística que cuente los coches en una foto de un aparcamiento, y ejecutará la misma cantidad de cómputo que cuando le pides que transcriba un recibo borroso. Mismo codificador, mismo número de capas, mismos milisegundos y dólares gastados, ya sea que la tarea sea "cuántos" o "qué dice esto". Eso debería preocuparte un poco, porque son obviamente trabajos diferentes. Contar coches necesita un esquema espacial aproximado. Leer un recibo necesita detalle fino en caracteres diminutos. Nadie diseñó estos modelos para tratar ambas tareas de forma idéntica. Es simplemente lo que ocurre cuando construyes un codificador de visión único y lo ejecutas sobre todo.

Un nuevo artículo de Tarun Tomar plantea una pregunta directa: si un modelo de visión-lingüística ya funciona, ¿puedes hacerlo más barato omitiendo parte de su procesamiento interno de visión, sin volver a entrenar nada? Y en caso afirmativo, ¿ayuda omitir partes diferentes dependiendo de si la pregunta trata sobre texto, conteo, objetos, colores o relaciones espaciales? La respuesta es sí y también, de una manera importante, no. El artículo encuentra ganancias reales y transferibles mediante la poda inteligente, y luego descubre que su idea más tentadora (personalizar el atajo por tarea) colapsa exactamente en el caso que más importa a los lectores de OpenOCR: la lectura de texto.

Pasaporte 8 — por Ken_Mayer vía flickr, BY 2.0.

Lo que realmente hay dentro de los "ojos" de un modelo de visión y lenguaje

Un modelo de visión y lenguaje (VLM) toma una imagen y un texto de entrada y produce una respuesta en texto. Antes de que ocurra cualquier razonamiento lingüístico, la imagen pasa por un codificador de visión: una pila de bloques de transformador, cada uno refinando un poco más la representación visual. El bloque 1 podría detectar bordes y texturas. El bloque 12 podría representar algo más cercano a "esta es la suma total de un recibo en la región inferior derecha". Para cuando la imagen llega al modelo de lenguaje, ha pasado por cada bloque de la pila, en orden, sin importar cuál fuera la pregunta.

Ese es el planteamiento que este artículo aborda. La idea es omitir por completo un número fijo de bloques, llamémoslo K, durante la inferencia. Sin ajuste fino, sin reentrenamiento, simplemente decidir "esta vez no vamos a ejecutar los bloques 4, 9, 15 y 21" y ver qué le sucede a la precisión. Si la precisión apenas disminuye mientras que el cómputo se reduce de manera significativa, has encontrado eficiencia gratuita. Haz esto en una familia de modelos y habrás encontrado algo que podría generalizarse.

El primer intento obvio es clasificar los bloques según lo importantes que parezcan individualmente (eliminar uno, medir el daño, repetir para cada bloque) y luego eliminar los K bloques que parezcan menos importantes por sí mismos. El artículo llama a esto clasificación independiente, y es la línea base natural a la que cualquiera recurriría primero. Otro instinto natural es simplemente eliminar una secuencia contigua de bloques, bajo la teoría de que las capas intermedias son redundantes. Ambos son baratos de calcular. Ambos, resulta, dejan una precisión real sobre la mesa.

Criando mejores rutas en lugar de solo clasificar bloques

El problema con la clasificación independiente es el mismo al que te enfrentarías al evaluar jugadores de baloncesto uno por uno y luego elegir tu "mejor quinteto" sin verificar nunca si funcionan bien juntos. Los bloques interactúan. Eliminar el bloque 9 podría ser inofensivo si el bloque 10 sigue ahí para compensarlo, pero dañino una vez que el bloque 15 también ha desaparecido. La importancia no es aditiva, por lo que puntuar los bloques de forma aislada y combinar las mejores selecciones pasa por alto interacciones que solo aparecen cuando se prueban combinaciones directamente.

Aquí es donde entra el método principal del artículo: una búsqueda evolutiva sobre qué conjunto específico de K bloques omitir. En lugar de puntuar los bloques individualmente, prueba combinaciones completas (rutas completas a través del codificador visual) directamente contra un conjunto retenido de 876 ejemplos, y evoluciona hacia mejores opciones. Comienza con una población de rutas candidatas, conserva las que obtienen buenas puntuaciones, las muta y las recombinas, y repite el proceso. Es la misma lógica que utilizan los criadores para mejorar un cultivo: no decides de antemano qué gen individual es más importante, seleccionas en función de resultados del mundo real y dejas que sobrevivan las buenas combinaciones.

Un detalle es importante aquí: la búsqueda es "equilibrada por fuente", lo que significa que el conjunto retenido contra el cual evalúa mezcla deliberadamente diferentes tipos de tareas (OCR, conteo, reconocimiento de objetos, atributos, relaciones espaciales) en proporciones equilibradas, en lugar de permitir que una categoría domine. Esto está diseñado para evitar que la búsqueda encuentre una ruta que sea excelente, por ejemplo, en conteo y mediocre en todo lo demás simplemente porque los ejemplos de conteo estaban sobrerrepresentados.

El artículo pone a prueba esto en dos modelos, Qwen2.5-VL-3B-Instruct y SmolVLM2-2.2B-Instruct, ambos VLMs abiertos de tamaño medio, y los compara con la clasificación independiente, la eliminación contigua y la selección aleatoria de bloques con presupuestos coincidentes (mismo número de bloques omitidos, diferente elección de cuáles).

El resultado que debería hacer que la gente replantee el poda ingenua

El número destacado: en SmolVLM2, la ruta compartida de cuatro bloques del búsqueda evolutiva (un conjunto fijo de cuatro bloques a omitir, utilizado para cada pregunta independientemente de la tarea) supera a la construcción de clasificación independiente por 4,91 puntos porcentuales. Esa es una brecha significativa para un cambio que no cuesta nada en el momento de la inferencia más allá de decidir qué cuatro bloques dejar fuera. Y dado que este patrón aparece en ambas arquitecturas probadas, es una señal bastante buena de que la búsqueda combinatoria (verificar rutas completas juntas en lugar de puntuar bloques uno por uno) es una forma genuinamente mejor de construir estos atajos que el enfoque inicial obvio.

Si el artículo se detuviera allí, la conclusión sería simple: buscar buenas combinaciones de bloques supera a clasificarlos individualmente, y eso vale la pena saberlo si estás intentando reducir el costo de inferencia en un VLM sin volver a entrenarlo.

Donde la idea de la especialización resulta tentadora, y luego se rompe

La siguiente pregunta que plantea el artículo es más ambiciosa: ¿qué pasaría si no usas una ruta fija para cada pregunta, sino que en su lugar eliges una ruta diferente de K bloques dependiendo del tipo de pregunta? Si sabes (o puedes adivinar) que una pregunta trata sobre OCR, conteo o razonamiento espacial, quizás los bloques ideales para omitir sean diferentes para cada uno. Esto requiere una etiqueta de capacidad, alguna señal que indique al sistema en qué categoría de tarea encaja la pregunta actual.

En Qwen2.5-VL, esto da frutos, a primera vista. La política específica de capacidad de seis bloques supera a la ruta compartida y única para todos en 2.17 puntos en general, y casi toda la ganancia proviene de una sola categoría: una mejora de 7.10 puntos en OCR específicamente. Este es un resultado real, y si se mantuviera en todas partes, sería genuinamente útil: usa una ruta genérica por defecto, cambia a una ruta especializada para OCR cuando sabes que estás leyendo texto y obtén un aumento significativo de precisión sin costo adicional.

Excepto que no se mantiene. Cuando el artículo verifica la ruta específica de OCR de SmolVLM2 contra IIIT5K, un benchmark estándar de texto en escena (fotos de texto en la naturaleza: escaparates, señales de tráfico, etiquetas de productos), esa ruta especializada se queda atrás de la ruta compartida simple por 13.6 puntos. No es un error de redondeo. Un atajo especializado que parecía una victoria en el conjunto retenido propio de la búsqueda resultó perjudicar activamente el rendimiento en una prueba de OCR separada y sellada.

Por qué ocurre esto es la parte importante. La ruta específica de capacidad fue optimizada contra un conjunto limitado de ejemplos etiquetados como OCR del conjunto de selección. Aprendió a omitir bloques que resultaron ser innecesarios para esa porción particular de ejemplos de lectura de texto, no bloques que son innecesarios para leer texto en general. El texto en escena de IIIT5K (señalización curva, fuentes extrañas, fondos desordenados) aparentemente necesita algo del procesamiento visual exacto que la ruta especializada decidió descartar. La ruta se sobreajustó a una definición estrecha de "OCR" en lugar de encontrar algo que generalice a través de lo que realmente parece el OCR en la vida real.

Por qué importa para quien construye o elige OCR

Si estás construyendo una tubería de procesamiento de documentos, o evaluando en qué motor de OCR o columna vertebral de VLM confiar, este artículo es una útil advertencia sobre un tipo específico de truco de eficiencia, no una razón para desconfiar del OCR basado en VLM en general.

La buena noticia: omitir bloques mediante una búsqueda combinatoria adecuada, no poda ad hoc, es una forma legítima de reducir el costo de inferencia en un modelo de visión-lenguaje sin volver a entrenarlo, y las ganancias se transfirieron entre dos familias de modelos diferentes en este estudio. Si un proveedor te dice que ha encontrado una ruta de inferencia más barata mediante una búsqueda cuidadosa en lugar de conjeturas, eso es plausible y merece ser tomado en serio.

La trampa: cada vez que un proveedor te diga que ha construido una ruta rápida "especializada para tareas" u "optimizada para OCR" a través de un modelo compartido, pregúntale contra qué fue validada. Este artículo muestra que una ruta especializada para OCR puede verse muy bien en el benchmark exacto utilizado para construirla, y luego perder más de 13 puntos en una prueba OCR estándar diferente. Esa brecha es exactamente el tipo de cosa que sería invisible si solo revisaras los números reportados por el propio proveedor. Si estás eligiendo entre motores de OCR, el movimiento práctico es el mismo que implica este artículo: prueba con tus propios documentos, especialmente los del mundo real desordenados (recibos, señalización, escritura a mano, escaneos de bajo contraste), no solo con el benchmark contra el que se ajustó la optimización de un proveedor.

Para quien construye en lugar de comprar: este es un fuerte argumento para mantener una ruta compartida y bien probada como predeterminada y tratar cualquier ruta rápida específica de tarea como un complemento experimental que necesita su propia validación retenida en un conjunto de prueba genuinamente diferente antes de su lanzamiento, no solo una puntuación más alta en el conjunto que utilizaste para encontrarla.

Qué sigue siendo incierto aquí

Se trata de un estudio con modelos pequeños y un alcance limitado, y debe leerse como tal. Ambos modelos evaluados son relativamente compactos (3B y 2.2B de parámetros), por lo que queda por ver si la misma brecha entre las rutas compartidas y las especializadas se manifiesta en VLMs de mayor escala y grado de producción. Solo se probaron dos arquitecturas, lo cual es suficiente para demostrar que el patrón no es una anomalía aislada, pero no basta para declararlo universal.

Existe también un detalle práctico que el artículo no resuelve por completo: utilizar una ruta específica para una capacidad requiere conocer la etiqueta de dicha capacidad en tiempo de inferencia, lo que significa que algo (un clasificador, una pista proporcionada por el usuario, un modelo router) debe etiquetar correctamente cada pregunta entrante como OCR, conteo, espacial, etc., antes de seleccionar una ruta. Si esa clasificación es incorrecta, no solo se pierde el beneficio de la especialización, sino que podría estar enrutando activamente una pregunta de OCR a través de una ruta optimizada para el conteo.

La limitación más importante, sin embargo, es aquella que el artículo reconoce con honestidad en su propia formulación: la búsqueda combinatoria mejora de manera fiable cómo se construye una ruta, pero las etiquetas de capacidad no definen de manera fiable una ruta que generalice. Esta es una afirmación más estrecha y útil que "la poda específica por tarea funciona", y es la que conviene recordar la próxima vez que alguien presente un modelo que ha sido optimizado especialmente para la lectura de texto. Pregúntele qué hace con texto que no se parece al texto en el que fue optimizado.