De las RNN a los Transformers: qué cambió en las arquitecturas de lenguaje y qué no fue un progreso lineal

La arquitectura importa, pero no explica todo

Una arquitectura determina cómo se representa y procesa la información: qué elementos pueden influirse entre sí, en qué orden se realizan los cálculos y qué partes del contexto están disponibles al producir una salida. En tareas de lenguaje, estas decisiones tienen consecuencias prácticas. Por ejemplo, un sistema de traducción debe relacionar palabras de la entrada con palabras de la salida y producir una secuencia que resulte coherente.

Pero una arquitectura no es una explicación completa de las capacidades de un sistema. También cuentan el objetivo de entrenamiento, los datos disponibles, el cómputo y el modo en que el modelo se adapta a una tarea. Por eso, describir la historia como una cadena en la que cada diseño «supera» y elimina al anterior induce a error. A menudo, lo que cambia es el equilibrio entre ventajas y costes, y las técnicas se mantienen útiles en contextos distintos.

La traducción automática permite examinar esos cambios porque obliga a resolver varios problemas a la vez: estimar qué expresiones de una lengua corresponden a las de otra y producir una oración de destino. El modelado del lenguaje ofrece otro caso de estudio: aprender a asignar probabilidades a secuencias y, en el caso autorregresivo, predecir qué token puede venir a continuación. Estos ejemplos permiten comparar decisiones de diseño sin confundir la arquitectura con la tarea.

Antes de las redes recurrentes: traducción estadística

Antes de los modelos neuronales de traducción que se describen en los trabajos de esta historia, una línea de investigación aplicaba métodos estadísticos al problema. El artículo de Peter F. Brown y sus colaboradores sobre métodos estadísticos para traducción automática documenta ese enfoque temprano. En lugar de tratar la traducción como una lista fija de reglas lingüísticas escritas a mano, estos métodos estimaban relaciones probabilísticas a partir de datos y buscaban una salida adecuada según esas estimaciones.

La diferencia respecto de una red neuronal no consiste simplemente en que un enfoque use números y el otro no: ambos hacen cálculos. La diferencia relevante está en cómo se representan las relaciones y se organizan los componentes que intervienen en la tarea. En un sistema estadístico, el problema se formula mediante modelos de probabilidad y procedimientos para escoger una traducción. En los sistemas neuronales encoder-decoder, en cambio, una red aprende representaciones internas de la secuencia de entrada y las utiliza para generar la secuencia de salida.

Este punto de partida sirve como referencia, no como relato exhaustivo de toda la traducción estadística. Un artículo fundacional permite describir una contribución concreta, pero no basta para reconstruir todas las variantes, sistemas operativos o decisiones técnicas que existieron en el campo. El cambio hacia métodos neuronales tampoco implica que desaparecieran de inmediato los métodos anteriores ni que una arquitectura, por sí sola, garantizara una traducción mejor en cualquier conjunto de datos.

Encoder-decoder recurrente: codificar y generar paso a paso

El trabajo de Sutskever, Vinyals y Le estudió una arquitectura neuronal encoder-decoder basada en redes LSTM para traducción inglés-francés. El encoder procesa la secuencia de entrada y el decoder produce la secuencia de salida. En la formulación descrita en el artículo, la entrada queda representada por un vector de longitud fija que el decoder utiliza para generar la traducción.

Este diseño hacía posible aprender una transformación entre secuencias sin diseñar manualmente una correspondencia para cada palabra. El encoder y el decoder podían aprender representaciones útiles a partir de ejemplos de traducción. Sin embargo, el vector fijo también concentraba la información de toda la oración de entrada en una representación de tamaño limitado. La dificultad potencial aumenta cuando la secuencia es larga o contiene información que el decoder necesita recuperar con precisión: el modelo debe conservar en esa representación lo necesario para producir la salida.

La recurrencia introduce otro compromiso. El estado que procesa una posición depende del estado anterior, por lo que el recorrido de una secuencia avanza paso a paso. Esta estructura ofrece una manera natural de manejar entradas de longitud variable y de mantener un estado que resume lo procesado hasta el momento. A la vez, limita cuánto puede calcularse en paralelo a lo largo de la secuencia, porque cada paso necesita el resultado del anterior. No es una deficiencia abstracta: afecta a la organización del cómputo y al coste de entrenar con secuencias.

Conviene separar lo que mostró el trabajo de una conclusión más amplia. El artículo evaluó una arquitectura concreta para traducción inglés-francés; no prueba que todas las redes recurrentes compriman la información del mismo modo ni que el vector fijo sea siempre insuficiente. La limitación es una motivación para estudiar mecanismos que permitan consultar la entrada de forma más directa, no una demostración de que la recurrencia carezca de utilidad.

La atención: consultar la entrada sin abandonar la recurrencia

Bahdanau, Cho y Bengio plantearon un mecanismo de atención para aprender conjuntamente a alinear y traducir. La motivación era reducir el cuello de botella de representar toda la oración fuente mediante un único vector fijo. En vez de obligar al decoder a depender únicamente de ese resumen, el mecanismo le permite buscar partes relevantes de la entrada al predecir cada palabra de destino.

En términos intuitivos, el decoder puede asignar distinta importancia a distintos elementos de la oración fuente según el paso de generación. Si necesita producir una palabra concreta, puede apoyarse más en una parte pertinente de la entrada que en el resto. Esto ofrece una representación más flexible del vínculo entre entrada y salida y hace explícita una operación relacionada con el alineamiento, que la traducción necesita resolver de algún modo.

La atención de este trabajo no equivale todavía al Transformer. Se incorpora a una arquitectura que conserva componentes recurrentes: el procesamiento de la secuencia y la generación siguen organizados paso a paso. El cambio importante es que el decoder obtiene acceso selectivo a la información de la entrada, en lugar de recibirla solo a través de un resumen único. Por ello, la atención mejora una dimensión del problema —el acceso a la entrada— sin eliminar la dependencia secuencial propia de las redes recurrentes.

Esta diferencia ayuda a evitar una simplificación frecuente: «atención» no nombra una arquitectura única ni implica automáticamente paralelización total. Puede designar un mecanismo integrado en modelos que mantienen recurrencia. Para entender qué cambió en cada diseño hay que preguntar dónde se aplica, qué representaciones consulta y qué operaciones siguen dependiendo de pasos anteriores.

El Transformer: autoatención y otro equilibrio de cómputo

El Transformer propone construir el procesamiento de secuencias mediante mecanismos de atención, sin recurrencia. Su artículo original estudió el diseño en tareas de traducción automática y presentó encoder y decoder con capas de autoatención y redes de alimentación hacia delante. La autoatención permite que las representaciones de una secuencia incorporen información de otras posiciones de esa misma secuencia; en el decoder, el acceso se restringe para que la predicción no use tokens futuros.

Eliminar la recurrencia cambia la organización del cálculo. Durante el entrenamiento, las representaciones de distintas posiciones de una capa pueden calcularse en paralelo, en lugar de esperar a completar el paso recurrente anterior. Esa posibilidad fue una de las ventajas de paralelización atribuidas al diseño original. No significa que toda operación del sistema ocurra simultáneamente: las capas siguen construyéndose en orden, y la generación autorregresiva de una salida continúa necesitando producir un token antes de poder condicionar el siguiente.

El cambio también introduce costes. En la autoatención, cada posición puede relacionarse con muchas otras posiciones. Por tanto, al crecer la longitud de la secuencia, aumenta el trabajo de calcular y almacenar esas relaciones. La arquitectura no elimina el coste computacional; redistribuye dónde se incurre en él. El artículo original compara coste, número de operaciones secuenciales y complejidad de rutas entre posiciones, además de medir resultados en tareas de traducción. Esas comparaciones respaldan ventajas bajo las condiciones evaluadas, no una regla universal para toda tarea o tamaño de secuencia.

También es importante no convertir la historia en una transición instantánea. El Transformer mostró una alternativa capaz de aprovechar paralelización durante el entrenamiento, pero las redes recurrentes y otras técnicas no dejan de ser posibles por ello. Una elección arquitectónica depende de la tarea, la longitud del contexto, los recursos, el objetivo y el sistema de entrenamiento. La historia describe un cambio importante en el equilibrio entre acceso al contexto y ejecución secuencial, no la desaparición automática de todas las opciones previas.

Modelos autorregresivos de tipo GPT: objetivo y arquitectura

La línea de GPT muestra por qué es necesario distinguir la arquitectura del objetivo de entrenamiento. El trabajo de OpenAI sobre preentrenamiento generativo describe un proceso en dos etapas: primero, preentrenamiento generativo sobre texto no etiquetado; después, ajuste discriminativo para tareas de comprensión del lenguaje. En el objetivo generativo autorregresivo, el modelo aprende a predecir el siguiente token condicionado en el contexto anterior. La generación aplica esa misma dependencia de forma sucesiva: cada token nuevo se incorpora al contexto para producir el siguiente.

En la familia de modelos de tipo GPT, el diseño se centra en el componente decoder y en la predicción autorregresiva, en lugar de construir necesariamente un encoder y un decoder separados para una traducción. Esto hace que una misma interfaz de modelado —continuar una secuencia— pueda emplearse como punto de partida para tareas de lenguaje. Pero de ahí no se desprende que la arquitectura, sin más, produzca capacidades generales. El resultado también depende del texto de preentrenamiento, del tamaño y procedimiento de entrenamiento, y de cómo se formule y evalúe la tarea posterior.

El preentrenamiento puede aportar parámetros que luego se adaptan a una tarea, pero no debe confundirse con el ajuste mismo ni con la evaluación. «Se entrena para predecir el siguiente token» describe un objetivo; no equivale a afirmar que el modelo comprende cualquier instrucción, dispone de información actualizada o resuelve de forma fiable toda tarea. Para sostener afirmaciones de ese tipo hacen falta resultados sobre el modelo concreto y la tarea concreta.

Así, la relación entre Transformer y GPT no es que sean sinónimos. Transformer nombra una arquitectura basada en atención; GPT remite a una familia de modelos autorregresivos y a un enfoque de preentrenamiento generativo seguido, en el trabajo fundacional citado, de adaptación a tareas. Una arquitectura puede emplearse con objetivos distintos, y un objetivo de entrenamiento no determina por sí solo todos los usos o comportamientos posteriores.

Comparación transversal: qué cambió y qué persistió

La comparación más útil no es una lista de ganadores, sino un conjunto de preguntas. ¿El modelo procesa la secuencia paso a paso o puede calcular representaciones de varias posiciones en paralelo? ¿Cómo recupera información de la entrada cuando genera una salida? ¿Qué objetivo se optimiza? ¿Qué coste aparece al aumentar la longitud de la secuencia? ¿Qué parte del resultado se debe al diseño y cuál a los datos, al cómputo o a la adaptación? Estas preguntas permiten analizar sistemas actuales sin asumir que una innovación aislada explica todo su rendimiento.

En las RNN, el estado recurrente organiza la información y crea una dependencia entre pasos. En la atención recurrente, el decoder puede consultar partes de la entrada, pero la recurrencia sigue presente. El Transformer elimina esa recurrencia y habilita más paralelismo durante el entrenamiento, a cambio de calcular relaciones de atención cuyo coste crece con las posiciones. En un modelo autorregresivo, incluso con Transformer, la generación de una secuencia sigue siendo paso a paso: la arquitectura paraleliza parte del entrenamiento, no la dependencia lógica de cada token generado respecto de los anteriores.

También persiste la necesidad de elegir un objetivo adecuado. Una arquitectura de traducción encoder-decoder y un modelo que predice el siguiente token no se entrenan necesariamente para resolver la misma tarea de la misma manera. Y una traducción estadística y una neuronal no difieren únicamente en rapidez o calidad: organizan de formas distintas las estimaciones y representaciones que conducen a una salida. Las comparaciones de rendimiento deben atender al conjunto de datos, al protocolo y a la métrica usados; no es riguroso extrapolar una medición puntual a todas las aplicaciones.

La siguiente tabla resume compromisos generales. No sustituye la revisión de un artículo o de una implementación: distintas variantes de una familia pueden modificar esos compromisos, y las condiciones de evaluación pueden cambiar el resultado.

Conclusión: la arquitectura es una parte de la explicación

El recorrido desde los métodos estadísticos de traducción hasta los modelos autorregresivos de tipo GPT no es una marcha inevitable hacia una única forma de procesar el lenguaje. El encoder-decoder recurrente aprendió una transformación entre secuencias, pero resumía la entrada en un vector de longitud fija. La atención introdujo acceso selectivo a partes de esa entrada manteniendo la recurrencia. El Transformer eliminó la dependencia recurrente en el procesamiento de las posiciones y favoreció la paralelización del entrenamiento, pero mantuvo costes de atención y la generación token a token. GPT combinó una arquitectura autorregresiva con preentrenamiento generativo y adaptación posterior, sin que el objetivo o la arquitectura, por sí solos, expliquen todas las capacidades observadas.

La historia ayuda a plantear preguntas concretas sobre un modelo actual: qué contexto puede consultar, qué partes del cálculo pueden paralelizarse, cómo se produce la salida y qué objetivo aprendió. No responde automáticamente si el modelo es exacto, seguro o adecuado para un uso particular. Para eso hace falta evidencia del sistema y de la tarea. Separar arquitectura, entrenamiento y evaluación evita tanto el relato simplista de sustituciones como la atribución de capacidades a una sola innovación.

Para continuar el recorrido, conviene relacionar esta explicación con una guía de fundamentos sobre modelos de lenguaje, una comparación de enfoques y un panorama de técnicas de IA. En cada caso, la pregunta clave es la misma: qué evidencia describe el comportamiento del sistema y qué parte es interpretación sobre su diseño.

Continúa explorando

Correcciones y transparencia

Si detectas un dato incorrecto o desactualizado, puedes enviarnos una corrección indicando la página y la fuente que debemos revisar.