Modelo de lenguaje visual

Conceptualmente, el diseño se basa en un LLM estándar (una variante perfeccionada de Llama ^{[ 17 ]} llamada Vicuna), con componentes añadidos para admitir las entradas de imagen.

LLaVA toma prestados los módulos de tokenización y transformación (incluidos sus pesos ) de Vicuna y los utiliza para procesar el texto que lo acompaña. Recordemos que en una aplicación anterior (no VLM) de Vicuna, el tokenizador convierte el texto en una secuencia de tokens, que se transfieren al módulo de transformación, el cual a su vez produce una secuencia de tokens de respuesta. Estos se convierten posteriormente de nuevo a texto mediante el tokenizador.

A esto, LLaVA añade dos componentes para admitir entradas de imágenes:

• Codificador de visión: Este se basa en un modelo CLIP comercial, entrenado por separado (específicamente, la variante ViT-L/14) de OpenAI. El codificador de visión convierte la imagen en una matriz de vectores de incrustación de características (más información a continuación), que codifican información útil sobre la imagen. Esta información puede ser utilizada directamente por el LLM, ya que este está diseñado para recibir tokens con diferentes dimensiones. Además, al ser un LLM comercial, Vicuna no fue entrenado para reconocer y responder a dicha información.
• Proyección (también conocida como puente ) : Este módulo conecta el codificador de visión con el LLM. Es decir, es una matriz simple de parámetros entrenables que convierte las dimensiones de las salidas del codificador de visión y que también puede entrenarse (véase más abajo) para que sea útil para el LLM. Sus salidas se denominan tokens de imagen .

Los tokens de imagen se anteponen a los tokens de texto y el LLM los procesa exactamente como tokens de texto ordinarios, lo que produce la respuesta final.

Se utilizó una modificación sencilla del codificador de visión CLIP ViT-L/14 para obtener vectores codificados más eficaces. Dado que este módulo es un transformador de visión , una aplicación directa habría utilizado el token de clase en la salida de su última capa transformadora (véase la clase del transformador de visión ) como una única salida vectorial. Sin embargo, LLaVA 1.0 utiliza los tokens de cuadrícula (no de clase) en la salida de la capa anterior (penúltima) para generar múltiples salidas vectoriales. Los tokens de cuadrícula corresponden a parches espaciales en estas imágenes de entrada y, por lo tanto, capturan información de mayor granularidad.

Se requirió entrenamiento para alinear los módulos de modo que pudieran combinarse en un solo modelo . En la terminología VLM, este paso se denomina ajuste de instrucciones. LLaVA 1.0 logró esto en dos etapas. La etapa 1 se centró en la alineación preliminar de la capa de proyección. Solo se entrenaron los pesos de ese módulo, mientras que los de los demás módulos permanecieron congelados. El conjunto de datos era un subconjunto del conjunto de datos CC3M ^{[ 18 ]} de pares imagen-leyenda. Este conjunto de datos era pequeño (595.000 pares) y limitado en su alcance, ya que contenía solo pares imagen-leyenda simples. La etapa 2 se centró en un entrenamiento más elaborado tanto de la capa de proyección como del LLM. El codificador de visión permaneció congelado. Para esta etapa se produjo un conjunto de datos de entrenamiento enriquecido (LLaVA-Instruct-158K ^{[ 19 ]} ) de pares de imágenes y texto, aprovechando un LLM de solo texto ( GPT-4 ) para convertir los subtítulos simples de los pares de imágenes y subtítulos (del conjunto de datos COCO ^{[ 11 ]} ) en indicaciones elaboradas al estilo de una conversación.

Las versiones posteriores de LLaVA introdujeron varias mejoras con respecto a LLaVA 1.0. Algunas mejoras conceptuales notables incluyen la sustitución en LLaVA 1.5 ^{[ 20 ]} del módulo de proyección simple por un MLP más elaborado . LLaVA-NeXT ^{[ 21 ]} añadió soporte para múltiples relaciones de aspecto de imagen, más allá de los 224x224 de LLaVA 1.0.

Al igual que LLaVA, Flamingo comienza con un modelo de lenguaje natural (LLM) y un codificador de visión diseñados de forma independiente, para el análisis de texto y la incrustación de imágenes, respectivamente. Ambos se entrenan previamente para sus propósitos específicos, independientemente de su utilidad final como componentes de Flamingo. Además, como componentes, sus pesos permanecen fijos durante el entrenamiento conjunto (véase más abajo).

Flamingo utiliza Chinchilla de DeepMind como su arquitectura base LLM. Para el codificador de visión, optaron por un diseño sin transformador ( NFNet-F6 basado en ResNet ^{[ 22 ]} ). Lo entrenaron utilizando una pérdida contrastiva al estilo CLIP en pares de imagen-leyenda de ALIGN ^{[ 23 ]} y un conjunto de datos especialmente seleccionado llamado LTIP (Long Text & Image Pairs).

El codificador de visión toma imágenes individuales como entrada (más información en los vídeos a continuación) y produce una cuadrícula bidimensional de vectores de características.

El componente perceptor-remuestreador ^{[ 24 ]} juega un papel clave en el soporte para video y número variable de imágenes en la entrada Flamingo.

Varias imágenes consecutivas (una o más) se introducen una a una en el codificador de visión, generando una cuadrícula tridimensional de vectores de características. Los vídeos se convierten en una secuencia de imágenes mediante un muestreo a una velocidad de 1 fotograma por segundo . La cuadrícula resultante se transforma en una matriz larga y de tamaño variable de vectores de características.

El remuestreador-perceptor convierte esto en una matriz corta de tokens de longitud fija . Utiliza un diseño basado en la atención cruzada entre un número fijo de vectores de consulta artificiales y predeterminados (cuyos valores se determinan mediante entrenamiento) y pares (clave, valor) derivados de la matriz de vectores de características.

Cabe señalar que, en este contexto, se asume que las imágenes consecutivas son contiguas, sin texto intermedio. El caso general se analizará más adelante.

Se trata de varios bloques (véase la figura superior) que desempeñan una función paralela a la del módulo de proyección de LLaVA, sirviendo de interfaz entre los módulos de visión y procesamiento de texto. Sin embargo, su diseño está más estrechamente ligado al modelo de lenguaje.

En concreto, Flamingo inserta estos bloques de atención cruzada y densos entre bloques transformadores seleccionados del modelo de lenguaje. Estos bloques se asemejan a los bloques decodificadores de las arquitecturas transformadoras codificador-decodificador. Es decir, sus consultas se obtienen del bloque transformador de autoatención heredado anterior del modelo de lenguaje principal. Sus claves y valores se derivan de los vectores de características de visión. Sus salidas se envían al siguiente bloque del modelo de lenguaje principal. También incluyen conexiones de salto.

Una modificación importante en los bloques añadidos, en comparación con los bloques de transformadores codificador-decodificador, es la inclusión de una compuerta tanh . Estos pequeños módulos multiplican sus entradas y están controlados por un peso escalar entrenable en el intervalo (-1, 1), específico para cada bloque. Estos pesos modulan el impacto del bloque de atención cruzada densa en el proceso de generación de texto. Se inicializan a cero al comienzo del entrenamiento, cuando los pesos de los demás módulos del bloque aún no están entrenados y son aleatorios. A medida que avanza el entrenamiento, sus valores aumentan gradualmente. Estas compuertas desempeñan un papel crucial para garantizar la estabilidad del entrenamiento.

Para admitir secuencias de imágenes y texto intercaladas, Flamingo introdujo una adaptación sencilla que, sin duda, mejora el rendimiento en el aprendizaje contextual (con pocos ejemplos). Concretamente, dividen el flujo de entrada en fragmentos, cada uno de los cuales contiene una única entrada visual (imagen, secuencia contigua de imágenes o vídeo). Al aplicar la atención cruzada entre texto y características visuales, los tokens de texto solo pueden prestar atención a la entrada visual dentro de su fragmento. Las demás entradas visuales se enmascaran.

Cabe señalar que los tokens de texto siguen estando influenciados indirectamente por todas las entradas de vídeo, a través de la autoatención intratextual.

Durante el entrenamiento, las estructuras básicas de lenguaje y texto permanecen fijas (como se indicó anteriormente). El entrenamiento utilizó tres conjuntos de datos: el conjunto de datos LTIP mencionado anteriormente, un conjunto de datos seleccionado de pares de vídeo y texto (denominado VTP) y un conjunto de datos masivo de secuencias de texto e imagen intercaladas, derivado de documentos HTML (MultiModal MassiveWeb - M3W).

Una diferencia clave con respecto a LLaVA 1.0 y Flamingo es que el codificador de visión admite resoluciones de imagen arbitrarias , sin necesidad de redimensionar la imagen a una forma fija. El número de tokens codificados es variable y depende de la forma de la imagen.

Los vídeos se muestrean a 2 fotogramas por segundo para generar una secuencia de imágenes, cada una de las cuales se codifica por separado. Esto también contribuye a la longitud variable del array de tokens.

Una MLP alinea la dimensión de incrustación del ViT con la del modelo de lenguaje. También contribuye a reducir la dimensionalidad de la codificación de imágenes mediante la fusión de parches adyacentes de 2x2 incrustaciones vectoriales (véase ViT ). La codificación de vídeo también se beneficia de una convolución 3D que opera en la dimensión temporal.

La codificación posicional estándar no es adecuada para datos de visión, especialmente cuando estos se codifican en incrustaciones de tokens de longitud variable. En concreto, su representación unidimensional pierde la disposición espacial de las imágenes y la continuidad temporal del vídeo.

Qwen2-VL utiliza una variante multidimensional para datos de visión, que denomina codificación posicional rotacional multimodal (M-RoPE). Con esta implementación, a cada token se le asigna una tripleta de índices ( i , x , y ), definida de la siguiente manera: para las imágenes, x e y representan las coordenadas espaciales del token en la imagen. i es constante para todos los tokens de la imagen e iguala el número de secuencia de la imagen dentro del flujo de entrada unificado al modelo. La codificación posicional M-RoPE se construye intercalando codificaciones RoPE unidimensionales separadas para los tres índices. ^{[ 27 ]}

La codificación posicional de vídeo utiliza tripletes similares, con la diferencia de que i no es constante y progresa con cada imagen en la secuencia de vídeo. De este modo, codifica la ubicación temporal.

Qwen2-VL se entrena mediante un proceso de tres etapas que integra progresivamente la comprensión visual y lingüística. En la Etapa 1, se entrena el codificador de visión, manteniendo los demás módulos congelados. En la Etapa 2, se desbloquea toda la arquitectura, y en la Etapa 3, se congela el codificador de visión mientras se ajusta el modelo de lenguaje. El conjunto de datos de entrenamiento incluye una amplia gama de modalidades, que suman finalmente 1,4 billones de tokens (incluidos los tokens de visión codificados). La pérdida de entrenamiento se calcula sobre los tokens de texto en la salida del modelo de lenguaje.

Una funcionalidad clave que permite la codificación posicional multimodal es la contextualización visual; es decir, la capacidad de razonar sobre objetos específicos dentro de una imagen. La preservación de la ubicación espacial de los elementos de la imagen por parte de M-RoPE es esencial para ello.

Para facilitar la contextualización, gran parte de los datos de entrenamiento incluyen información sobre objetos en imágenes, como subtítulos y coordenadas de cuadros delimitadores . La preparación del conjunto de datos de entrenamiento implica formatear estos datos en una estructura estándar, que incluye tokens especiales como object_ref_start, object_ref_end, box_start, y box_end.