Conectando audio con lenguaje

Ahora tenemos potentes codificadores de audio (Whisper, wav2vec 2.0) que convierten formas de onda crudas en ricas secuencias de características, y tenemos grandes modelos de lenguaje (LLMs) que razonan sobre texto. La siguiente pregunta obvia: ¿cómo los conectamos para que el LLM pueda razonar sobre lo que escucha?

Este es exactamente el mismo problema que los Modelos Visión-Lenguaje (VLMs) resolvieron para imágenes. La receta es estructuralmente idéntica: tomar un codificador pre-entrenado, proyectar su salida al espacio de embeddings del LLM y ajustar con datos emparejados (audio + texto). Las características del codificador de audio viven en un sistema de coordenadas, los embeddings de tokens del LLM viven en otro, y necesitamos un puente entre ellos. Si has leído el artículo sobre fusión multimodal , los patrones aquí te resultarán muy familiares.

Han surgido tres patrones de arquitectura, paralelos directos a las estrategias de fusión de VLM:

  • Codificador + proyector + LLM congelado: el enfoque más barato de entrenar. El codificador de audio extrae características, un proyector liviano (capa lineal o MLP pequeño) las mapea al espacio de embeddings del LLM, y el LLM en sí se mantiene congelado. Solo se aprenden los pesos del proyector. Esto funciona bien cuando el LLM ya es fuerte y solo necesitamos que «vea» los tokens de audio.
  • Codificador + proyector + LLM ajustado: igual que arriba, pero también actualizamos los pesos del LLM (frecuentemente mediante LoRA o ajuste fino completo). Esto produce mejor calidad porque el LLM adapta sus representaciones internas a la nueva modalidad, pero cuesta más entrenar.
  • Tokens de audio nativos (sin codificador separado): el audio se tokeniza directamente (por ejemplo, mediante un codec neuronal) y se alimenta al LLM como tokens de entrada de primera clase junto con tokens de texto. No hay codificador separado ni paso de proyección. Este es el enfoque más unificado pero requiere datos de entrenamiento masivos porque el modelo debe aprender comprensión de audio desde cero en lugar de heredarla de un codificador pre-entrenado.
💡 La progresión del patrón 1 al patrón 3 intercambia costo de entrenamiento por profundidad de integración. Los enfoques con LLM congelado se pueden entrenar en horas en un solo nodo; los modelos con tokens de audio nativos necesitan miles de millones de tokens y cientos de GPUs. La mayoría de los modelos audio-lenguaje de 2023–2024 usan el patrón 1 o 2.

Qwen-Audio: El primer Audio-LLM

Qwen-Audio (Chu et al., 2023) fue de los primeros modelos en demostrar que un solo modelo audio-lenguaje podía manejar docenas de tareas de audio a la vez: reconocimiento automático de habla (ASR), detección de eventos sonoros, comprensión musical, reconocimiento de emociones y respuesta a preguntas sobre audio, todo dentro de una arquitectura unificada. ¿Cómo funciona?

La arquitectura sigue el patrón 2 de arriba: un codificador Whisper-large-v2 (640M parámetros) extrae características de audio, una capa de proyección las mapea al espacio del LLM, y un LLM Qwen-7B genera texto condicionado tanto en los tokens de audio como en cualquier prompt de texto. El pipeline se ve así:

Forma de onda de audio $\rightarrow$ codificador Whisper $\rightarrow$ pooling temporal (stride 2) $\rightarrow$ proyección lineal $\rightarrow$ espacio de embeddings del LLM $\rightarrow$ decodificador Qwen-7B

El codificador Whisper produce características a 50 Hz (50 vectores de características por segundo de audio). Una capa de pooling con stride 2 reduce esto a la mitad, a 25 Hz, promediando pares de tramas consecutivas, reduciendo la longitud de secuencia antes de que entre al LLM. Luego una proyección lineal mapea cada vector agrupado desde la dimensión oculta de Whisper a la dimensión de embeddings de Qwen-7B:

$$\mathbf{h}_a^i = \mathbf{W}_\text{proj} \cdot \text{Pool}(\mathbf{g}_a^{2i}, \mathbf{g}_a^{2i+1}) + \mathbf{b}_\text{proj}$$

donde $\mathbf{g}_a^j \in \mathbb{R}^{d_\text{whisper}}$ es la $j$-ésima trama del codificador Whisper, $\text{Pool}$ promedia dos tramas consecutivas en una, $\mathbf{W}_\text{proj} \in \mathbb{R}^{d_\text{LLM} \times d_\text{whisper}}$ es la matriz de proyección aprendida, y $\mathbf{h}_a^i \in \mathbb{R}^{d_\text{LLM}}$ es el token resultante que se alimenta al LLM. En los límites: cuando $i = 0$, agrupamos las dos primeras tramas de Whisper; cuando $i$ alcanza el último índice válido, agrupamos las últimas dos tramas. Si el número total de tramas de Whisper es impar, la última trama típicamente se duplica o descarta.

Una innovación clave en Qwen-Audio son las etiquetas jerárquicas durante el pre-entrenamiento. Debido a que el modelo se entrena en más de 30 tareas de audio diferentes simultáneamente, cada muestra de entrenamiento se etiqueta con metadatos que identifican el tipo de tarea, la fuente de datos y el idioma. Esto evita que el modelo confunda una tarea de ASR con una tarea de detección de eventos sonoros durante el entrenamiento multi-tarea y permite que un solo modelo maneje todas sin interferencia.

La versión mejorada Qwen2-Audio (agosto 2024) cambió al codificador Whisper-large-v3, reemplazó las etiquetas jerárquicas rígidas con prompts en lenguaje natural e introdujo dos modos de interacción: chat de voz (el usuario habla y el modelo responde al contenido del habla) y análisis de audio (el usuario proporciona un clip de audio y hace preguntas sobre él mediante texto). Esto hizo al modelo mucho más flexible en la práctica.

💡 El entrenamiento multi-tarea de Qwen-Audio a través de más de 30 tareas es análogo a cómo los primeros VLMs como LLaVA se entrenaron con datos de seguimiento de instrucciones visuales. La lección clave: datos de entrenamiento diversos importan más que la novedad arquitectónica cuando se conecta un codificador pre-entrenado a un LLM.

SeamlessM4T: Traducción multilingual de habla

Mientras Qwen-Audio se enfoca en comprender audio y generar respuestas de texto, SeamlessM4T (Communication et al., 2023) aborda un desafío diferente: traducir entre idiomas y modalidades. Un solo modelo maneja las cuatro direcciones de traducción: habla a texto, habla a habla, texto a habla y texto a texto, en hasta 100 idiomas. Tradicionalmente, cada una de estas direcciones requería un pipeline separado; SeamlessM4T las colapsa en uno.

La arquitectura encadena cuatro componentes:

  • Codificador de habla w2v-BERT 2.0: convierte audio crudo en una secuencia de representaciones de habla. Este codificador combina pre-entrenamiento autosupervisado estilo wav2vec 2.0 con predicción enmascarada estilo BERT, dándole fuerte comprensión de habla multilingual.
  • Decodificador de texto transformer: genera tokens de texto en el idioma objetivo, condicionado en la salida del codificador mediante atención cruzada . Esto maneja las rutas de traducción habla a texto y texto a texto.
  • Decodificador de habla basado en unidades: para salida de habla, un segundo decodificador genera unidades discretas de habla (tokens de audio aprendidos que representan contenido fonético) en lugar de muestras de forma de onda cruda.
  • Vocoder HiFi-GAN: convierte las unidades discretas de habla de vuelta en una forma de onda continua que puede reproducirse como audio. Esta es la etapa final para cualquier ruta que produce salida de habla.

Para una traducción habla a habla (por ejemplo, audio en inglés de entrada, audio en francés de salida), el pipeline completo es: audio $\rightarrow$ w2v-BERT 2.0 $\rightarrow$ decodificador de texto (genera texto en francés) $\rightarrow$ decodificador de unidades de habla (genera unidades de habla en francés) $\rightarrow$ HiFi-GAN (sintetiza forma de onda en francés). El decodificador de texto actúa como cuello de botella semántico: la traducción ocurre en el espacio del texto, y luego el habla se genera a partir del texto traducido.

En diciembre de 2023, el equipo lanzó SeamlessStreaming (Barrault et al., 2023) , que añadió EMMA (Efficient Monotonic Multihead Attention) para habilitar traducción simultánea. En lugar de esperar a que el hablante termine una expresión completa, el modelo comienza a traducir mientras el habla aún está llegando. La idea clave detrás de EMMA es que para traducción, la atención es aproximadamente monótona: la siguiente palabra de salida típicamente atiende a una posición cerca o después de donde la palabra de salida anterior atendió. EMMA explota esto restringiendo cada cabeza de atención a una política monótona aprendida que decide cuándo «leer» más entrada y cuándo «escribir» salida, logrando traducción simultánea con aproximadamente 2 segundos de latencia.

💡 SeamlessM4T demuestra un punto clave sobre los modelos audio-lenguaje: no se limitan a comprender audio. Al encadenar un codificador, un decodificador de traducción, un decodificador de unidades de habla y un vocoder, un solo modelo reemplaza lo que solía ser un pipeline de traducción de múltiples sistemas.

El problema de la proyección de audio

Conectar un codificador de audio a un LLM parece directo en principio, pero hay un desafío central que lo hace más difícil que el problema análogo en visión: el audio tiene una tasa de tokens mucho más alta que el texto.

Pongamos números concretos a esto. El texto se produce a aproximadamente 150 palabras por minuto en habla normal. Con un tokenizador estándar promediando alrededor de 4 tokens por palabra, eso se traduce en aproximadamente 10 tokens por segundo:

$$R_\text{text} = \frac{150 \text{ words/min}}{60 \text{ s/min}} \times 4 \text{ tokens/word} = 10 \text{ tokens/s}$$

Ahora comparémoslo con la salida del codificador de audio. Whisper produce características a 50 Hz, es decir, 50 vectores de características por segundo de audio:

$$R_\text{audio} = 50 \text{ features/s}$$

Eso es un desajuste de 5$\times$ . Sin submuestreo, un clip de audio de 30 segundos se convierte en $50 \times 30 = 1{,}500$ tokens en el contexto del LLM. Un segmento de podcast de 5 minutos sería $50 \times 300 = 15{,}000$ tokens, consumiendo una gran fracción de la ventana de contexto del LLM antes de que el modelo haya comenzado a razonar. Para comparar, la transcripción de texto de ese mismo segmento de 5 minutos sería aproximadamente $10 \times 300 = 3{,}000$ tokens.

En los extremos, el problema es claro. Para audio muy corto (una sola palabra, ~0.5 segundos), obtenemos $50 \times 0.5 = 25$ tokens de audio. Eso es manejable. Pero para una grabación de reunión de 30 minutos, obtenemos $50 \times 1{,}800 = 90{,}000$ tokens. Ningún LLM actual puede atender útilmente sobre 90,000 tokens de audio junto con un prompt de texto.

Tres estrategias principales abordan este desajuste:

  • Pooling temporal / striding: promediar o concatenar tramas consecutivas para reducir la tasa de tramas. Qwen-Audio usa stride 2, reduciendo a la mitad de 50 Hz a 25 Hz. Simple y efectivo, pero la razón de compresión es limitada (típicamente 2–4$\times$). Para un clip de 30 segundos con stride 2: $25 \times 30 = 750$ tokens en lugar de 1,500.
  • Q-Former / pooling de atención: usar un conjunto de vectores de consulta aprendidos que atienden a la secuencia completa de características de audio mediante atención cruzada y la comprimen en un número fijo o mucho menor de tokens. Este es el equivalente de audio del enfoque Q-Former usado en BLIP-2 para visión. La compresión puede ser agresiva (por ejemplo, 100 características de audio $\rightarrow$ 8 tokens de consulta), pero arriesga perder detalle temporal fino.
  • Codecs de tasa de tramas más baja: usar un codec de audio neuronal que opera a una tasa de tramas más baja desde el inicio. Por ejemplo, el codec Mimi (usado por Moshi) opera a 12.5 Hz, así que 30 segundos de audio producen $12.5 \times 30 = 375$ tokens, una reducción de 4$\times$ comparado con las características de Whisper a 50 Hz, sin pooling adicional necesario.

El compromiso general puede expresarse como:

$$N_\text{tokens} = \frac{R_\text{encoder}}{C} \times T$$

donde $R_\text{encoder}$ es la tasa de tramas de salida del codificador (por ejemplo, 50 Hz para Whisper), $C$ es el factor de compresión del pooling o diseño del codec (por ejemplo, $C = 2$ para pooling stride-2, $C = 4$ para la tasa de 12.5 Hz de Mimi relativa a 50 Hz), y $T$ es la duración del audio en segundos. Cuando $C = 1$ (sin compresión), obtenemos el conteo de tramas crudo. A medida que $C$ aumenta, obtenemos menos tokens pero perdemos resolución temporal. El valor correcto de $C$ depende de la tarea: ASR puede tolerar compresión agresiva porque la densidad de información del habla es baja relativa a la tasa de tramas; el análisis musical o la diarización de hablantes pueden necesitar mayor resolución para preservar pistas tímbricas o prosódicas de grano fino.

📌 El problema de la tasa de tokens de audio es la razón principal por la que la mayoría de los modelos audio-lenguaje de 2023–2024 limitan la duración de entrada a 30 segundos. Audio más largo requiere compresión agresiva (perdiendo detalle) o consume la ventana de contexto del LLM (sin dejar espacio para el prompt de texto y la salida). Esta es un área activa de investigación.

Patrones emergentes y tendencias

Los modelos audio-lenguaje están siguiendo la misma trayectoria que los VLMs, aproximadamente dos años por detrás:

  • 2023: aparecieron los primeros audio-LLMs (Qwen-Audio, SALMONN, LTU). Estos son análogos a los primeros VLMs como LLaVA: un codificador pre-entrenado, un proyector simple y un LLM congelado o ligeramente ajustado. Demostraron que el concepto funciona.
  • 2024: recetas de entrenamiento mejoradas y capacidad multi-tarea (Qwen2-Audio, WavLLM). Análogo a LLaVA-1.5 y VLMs posteriores: mejor curación de datos, más tareas, resultados más fuertes. Los modelos comenzaron a manejar tanto habla como audio no verbal (música, sonidos ambientales) en un solo sistema.
  • 2025: modelos omni-modales nativos que manejan audio, texto y visión como modalidades de primera clase en una sola arquitectura (cubierto en el próximo artículo). El enfoque de codificador + proyector da paso a la tokenización unificada de todas las modalidades.

La pregunta arquitectónica clave en la frontera es: codificador + proyector (modular) versus tokens de audio nativos (unificado) ?

El enfoque de codificador es más fácil de entrenar y puede aprovechar años de inversión en modelos de audio pre-entrenados (Whisper, wav2vec 2.0, w2v-BERT). Es modular: puedes reemplazar un codificador mejor sin re-entrenar el LLM. Pero añade un paso de conversión, y el codificador fijo puede descartar información de audio (emoción, prosodia, sonidos de fondo) que al LLM le resultaría útil si pudiera acceder a la señal cruda.

El enfoque nativo es de extremo a extremo: los tokens de audio se tratan idénticamente a los tokens de texto, así que el modelo puede aprender a preservar cualquier información que importe para la tarea (incluyendo matices como emoción, estilo de habla y prosodia que un codificador fijo podría descartar). Pero requiere datos de entrenamiento masivos porque el modelo debe aprender simultáneamente modelado acústico y modelado de lenguaje, en lugar de heredar la comprensión acústica de un codificador pre-entrenado.

El próximo artículo cubre modelos que van más allá de comprender audio: también lo generan , lo manejan nativamente junto con texto y visión, y lo hacen en tiempo real. Estos son los modelos omni-modales (GPT-4o, Gemini, Moshi) que unifican todas las modalidades en un solo flujo de tokens.

Quiz

Pon a prueba tu comprensión de las arquitecturas de modelos audio-lenguaje y los desafíos de conectar codificadores de audio a LLMs.

¿Por qué los modelos audio-lenguaje necesitan una capa de proyección entre el codificador de audio y el LLM?

Si un codificador Whisper produce características a 50 Hz y aplicamos pooling stride-2, ¿cuántos tokens produce un clip de audio de 30 segundos?

¿Qué problema resuelve el mecanismo EMMA de SeamlessStreaming?

¿Cuál es la principal ventaja del enfoque de tokens de audio nativos (sin codificador separado) sobre el enfoque de codificador + proyector?