Skip to content

English · Español

00 — Motivación: multimodalidad como paradigma separado

🇪🇸 Multimodalidad (multimodal) no es "concatenar tokens de imagen y de texto y entrenar un transformer encima". El problema central es que cada modalidad vive en un espacio de representación distinto (la modality gap), y forzarlas al mismo espacio cuesta datos, parámetros y diseño cuidadoso. Esta sección explica por qué.

Este fichero responde: ¿por qué el modelado multimodal es un paradigma distinto, y no solo "tokens con pasos extra"?

La visión ingenua (y por qué está equivocada)

Una primera lectura de los papers de CLIP (CLIP) o Flamingo sugiere: "tokenizamos imágenes en patch-tokens, audio en frame-tokens, texto en tokens BPE, los volcamos todos en un transformer, entrenamos predicción de siguiente-token. Listo."

La visión ingenua es mecánicamente correcta (de hecho puedes hacer esto — Chameleon y Gemini 1.5 esencialmente lo hacen, ver theory/03-fusion-strategies.md) pero prácticamente se pierde el problema central de ingeniería:

Diferentes modalidades tienen estructura estadística, densidad de información y escala muy distintas. Meterlas en el mismo modelo sin pensar en estos desajustes produce un modelo que ignora una modalidad.

Concretamente:

  • Densidad de información. Una imagen 224×224, patchificada ingenuamente a 16×16, son 196 tokens. Una frase inglesa hablada a 16 kHz durante 5 s son 5 × 100 = 500 frames mel antes del downsampling. El caption de texto "un gato se sienta en una alfombra" son 8 tokens BPE. Tres órdenes de magnitud de variación en tokens-por-significado entre modalidades para el mismo contenido semántico.
  • Estructura estadística. El texto es discreto, baja entropía a nivel de token (la mayoría de tokens son altamente predecibles desde contexto previo), y obedece frecuencia zipfiana. Los patches de imagen son de valor continuo (o cuantizados a un codebook de 8k en algunos esquemas), alta entropía a nivel de patch, y estructurados espacial-visualmente (patches adyacentes están correlacionados). Los frames de audio son continuos, periódicos en estructura espectral, y tienen un prior fuerte de suavidad temporal. Una sola arquitectura de modelo no puede ingenuamente ser óptima para las tres.
  • Escala de pretraining (pretraining). Los LLMs de texto entrenan sobre ~10 T tokens. CLIP entrenó sobre 400 M pares imagen-texto (≈ 80 B "tokens" si cuentas patch+texto). Whisper entrenó sobre 680 k horas de audio (≈ 24 B frames de audio). Los datos difieren en órdenes de magnitud — y las etiquetas (texto-imagen pareados vs. audio transcrito) son mucho más difíciles de obtener que el texto crudo.

El modality gap

Un fenómeno específico, medible. El entrenamiento contrastivo estilo CLIP aprende a mapear pares (imagen, texto) al mismo espacio de embedding. Tras el entrenamiento, si miras los embeddings de todas las imágenes vs. todos los textos, encuentras dos clusters disjuntos.

Específicamente:

  • La distancia coseno entre el centroide de todos los embeddings de imagen y el centroide de todos los embeddings de texto es ~0.5 (de un máximo de 2 para direcciones opuestas).
  • Un clasificador lineal entrenado sobre la unión de (embedding de imagen, embedding de texto) → "¿es esto imagen o texto?" alcanza > 99% de precisión.

Este es el modality gap (Liang et al. 2022, "Mind the Gap"). Es sorprendente porque la pérdida contrastiva empuja explícitamente a imagen y texto pareados juntos — y aun así las modalidades acaban en conos separados de la esfera unidad.

Por qué ocurre: la inicialización. El encoder de imagen y el encoder de texto se inicializan independientemente, con arquitecturas diferentes (ViT para imagen, transformer para texto). Sus outputs iniciales aterrizan en regiones diferentes de \(\mathbb{R}^d\). La pérdida contrastiva atrae los puntos pareados juntos, pero la señal de gradiente no es lo suficientemente fuerte como para borrar el gap globalmente — hay una barrera de energía entre "encoger el gap globalmente" (que requeriría reestructurar todo el espacio de representación) y "hacer que este par específico esté lo suficientemente cerca como para ser top-1" (un fix local).

Por qué importa en la práctica:

  • La clasificación zero-shot ("¿cuál de estos 1000 textos de etiqueta-de-clase está más cerca de esta imagen?") funciona porque dentro de cada modalidad, las distancias coseno siguen siendo informativas — la imagen está más cerca del texto-de-clase correcto que de uno aleatorio. Pero los scores absolutos no son comparables entre modalidades.
  • El retrieval imagen-a-imagen y texto-a-texto dentro del mismo modelo a menudo supera al imagen-a-texto. El modelo está implícitamente haciendo dos sistemas separados de retrieval que casualmente están ligeramente alineados.
  • Arquitecturas de fusion que cubren el gap explícitamente (el MLP proyector de LLaVA, la gated cross-attention de Flamingo) a menudo superan al contrastivo puro en tareas downstream — pueden usar los mismos parámetros a través de modalidades, en vez de atornillar dos encoders juntos.

Dos paradigmas: multimodal contrastivo vs autoregresivo

Hay dos grandes familias de modelos multimodal. La distinción es qué pérdida minimizan.

Multimodal contrastivo (CLIP, SigLIP, ALIGN, BLIP-1)

  • Arquitectura: dos encoders (imagen, texto). Sin decoder. Opcionalmente una cabeza de proyección por modalidad.
  • Pérdida: contrastiva — atraer embeddings (imagen, texto) pareados juntos; alejar los no-pareados. Concretamente: InfoNCE simétrico (theory/01-vision-transformers.md §"CLIP loss").
  • Salida: un embedding por modalidad. Para hacer cualquier cosa downstream (clasificar, retrieval, caption), necesitas una cabeza separada.
  • Fuerza: inferencia rápida, excelente para retrieval y clasificación zero-shot, sin coste de generación.
  • Debilidad: no puede generar texto describiendo una imagen. No puede responder preguntas sobre una imagen. El modelo "sabe" la relación imagen-texto implícitamente, pero no puede articularla.
  • Cómputo: CLIP-L sobre 400 M pares, 32 V100s, ~12 días. Totalmente data-scaling-bound.

Multimodal autoregresivo (Flamingo, LLaVA, GPT-4V, Gemini, Chameleon)

  • Arquitectura: un LLM base (transformer decoder) + un encoder de imagen + un mecanismo de fusion que inyecta información de imagen en el stream residual del LLM. Opcionalmente un decoder de imagen para generación de imagen.
  • Pérdida: next-token cross-entropy estándar sobre texto, con tokens de imagen (o features de imagen proyectadas) prepended/intercalados en el contexto.
  • Salida: texto generado, condicionado por la entrada de imagen.
  • Fuerza: puede hacer cualquier cosa que puedas describir en texto. Captioning, VQA, OCR, lectura de gráficos, diálogo multi-turn de visión-lenguaje.
  • Debilidad: la generación es cara; aplica el cuello de botella autoregresivo. El encoder de imagen está a menudo congelado durante el entrenamiento de fusion (LLaVA), lo que significa que la representación de imagen es lo que un modelo contrastivo ya produjo.
  • Cómputo: LLaVA-1.5 entrenado sobre ≤ 1 M pares de instrucción en ≤ 1 GPU-día para el proyector + LoRA. Barato si reutilizas un encoder + LLM pre-entrenados.

Híbrido (Chameleon, Gemini, GPT-4o)

Discretiza imágenes en tokens estilo VQ-VAE, mételos en el mismo vocabulario que el texto, entrena predicción de siguiente-token a través del stream unificado de tokens. Esto unifica los dos paradigmas — misma pérdida, misma arquitectura a través de modalidades — pero requiere cómputo extremadamente grande (el pretraining de Gemini 1.5 está en el orden de \(10^{25}\) FLOPs). El escalado de datos de entrenamiento para modelos unificados es theory/03-fusion-strategies.md §"unified token fusion".

En qué se convierte el tutor de gramática (Fase 32) con visión

La Fase 32 es el agente capstone: leer una frase en inglés, proponer correcciones de conjugación. Con X2, la extensión natural es:

Tutor multimodal de gramática. El usuario sube:

  • Una foto de una página de libro de texto con una frase, O
  • Un clip de audio de 5 segundos de alguien diciendo una frase,

y el tutor (a) extrae la frase (OCR vía visión o ASR vía Whisper), (b) parsea las formas verbales, © marca errores y propone correcciones (el pipeline existente de la Fase 32).

Este es el caso de uso para el que X2 prepara. No construimos este capstone en X2 (eso pertenecería a una hipotética "X4 — Capstone multimodal"), pero los labs verifican cada componente:

  • Lab 00 (ViT) — verifica que puedes clasificar tiempo verbal desde un ícono visual. Un pequeño paso hacia OCR.
  • Lab 01 (estilo CLIP) — verifica la alineación imagen ↔ texto sobre el dominio de gramática. El mecanismo de retrieval que un tutor usaría para matchear una frase fotografiada contra sus plantillas de gramática conocidas.
  • Lab 02 (Whisper) — verifica que puedes transcribir audio hablado de formas verbales a texto. El frontend ASR del camino de audio.

Cuándo usar multimodalidad (y cuándo no)

Multimodal añade dos costes: complejidad de ingeniería (mantienes dos pipelines de pretraining, dos evaluadores, a menudo dos equipos) y latencia de inferencia (los encoders de imagen son típicamente 50–500 ms en CPU, los encoders de audio 1–5 s para 30 s de audio).

Usa multimodal cuando:

  • La información es genuinamente no-textual (una foto de un hueso roto, una grabación de un golpeteo de motor, una nube de puntos 3-D de una línea de fab). Cualquier cosa que puedas OCRear o ASRear a texto se maneja mejor por pipeline OCR/ASR → LLM de texto.
  • El grounding cross-modal es parte de la respuesta (visual question answering, diálogo condicionado a imagen).
  • Necesitas interacción en tiempo real con una escena física (robótica, asistentes de realidad aumentada).

Usa solo-texto cuando:

  • La entrada era originalmente texto (PDFs, código, transcripciones). Convierte y no re-introduzcas modalidad.
  • La latencia o el coste importan más que el % marginal ganado por imágenes.
  • No tienes datos de entrenamiento multimodal y tu tarea es lo suficientemente nicho como para que CLIP / LLaVA pre-entrenados no transfieran.

Qué viene a continuación

Lee theory/01-vision-transformers.md para el lado visual, theory/02-audio-models.md para el lado de audio. Luego 03-fusion-strategies.md y 04-llava-and-vision-language.md cubren cómo las dos modalidades se cosen a un único modelo.