El mismo transformer, tres formas de conectarlo

El transformer de 2017 se diseñó para traducción y tenía dos pilas. Un codificador leía de una vez toda la oración de entrada y construía una representación rica de ella. Un decodificador generaba luego la salida un token a la vez, atendiendo tanto a lo que había producido hasta ese momento como, a través de la atención cruzada, a la representación de la entrada que hizo el codificador. Conservar el codificador, el decodificador o ambos da lugar a tres familias. (Para ver cómo funciona la atención en sí, consulte la explicación sobre autoatención.)

Un modelo de solo codificador usa atención bidireccional: cada token puede atender a todos los demás, a la izquierda y a la derecha. Eso lo hace excelente para construir una representación profunda de una entrada fija, ideal para clasificación, reconocimiento de entidades nombradas, embeddings de recuperación y cualquier tarea en la que se tiene el texto completo y se quiere entenderlo o calificarlo.

Como cada token ve el futuro, un codificador no puede usarse para generar texto de izquierda a derecha: no habría nada que predecir que no haya visto ya. Por eso BERT se preentrena con modelado de lenguaje enmascarado: se ocultan al azar algunos tokens y se le pide al modelo que los complete usando el contexto de ambos lados. Modelos como BERT, RoBERTa y los modelos de embeddings detrás de la mayoría de los sistemas de recuperación viven aquí.

Un modelo de solo decodificador usa atención causal (enmascarada): cada token solo puede atender a los tokens anteriores, nunca a los siguientes. Esa restricción es exactamente lo que hace posible y honesta la generación del siguiente token: en la posición n el modelo de verdad no ve la posición n+1, así que predecirla es una tarea real. Esta es la arquitectura detrás de GPT, Claude, Llama, Gemini y prácticamente todos los modelos modernos de chat y razonamiento.

Resulta que este único objetivo, predecir el siguiente token (vea preentrenamiento), escala asombrosamente bien y abarca la mayoría de las tareas: la clasificación, la traducción y el resumen pueden plantearse como “continúe este texto de forma adecuada”. Esa generalidad es la razón por la que el campo se consolidó alrededor de los modelos de solo decodificador, incluso para trabajos que antes hacía un codificador.

El diseño completo de dos pilas conserva un codificador bidireccional y un decodificador causal unidos por atención cruzada. El codificador entiende por completo la entrada; el decodificador genera una salida condicionada a ella. Esto brilla en la transformación de secuencia a secuencia propiamente dicha, donde la entrada y la salida son objetos distintos (traducción automática, resumen, voz a texto), porque el modelo puede leer libremente toda la fuente mientras sigue generando el destino de forma autorregresiva.

T5 (“Text-to-Text Transfer Transformer”) planteó cada tarea de PLN como texto que entra y texto que sale, lo que hizo que la forma codificador-decodificador encajara limpiamente. La contrapartida es más complejidad y dos regímenes de atención que entrenar; para el chat abierto, una sola pila de decodificador resultó más simple e igual de capaz, por eso los codificadores-decodificadores hoy son más especializados que dominantes.

La regla práctica: si tiene un texto fijo y quiere entenderlo o convertirlo en embeddings (búsqueda, clasificación, similitud), un modelo de solo codificador es barato y sólido. Si quiere generar o conversar de forma abierta, un modelo de solo decodificador es la opción predeterminada y lo que le da cualquier API de frontera. Si su tarea es una transformación limpia de una secuencia en otra y usted controla el entrenamiento, un codificador-decodificador puede ser la opción más eficiente en datos.

En 2026 la mayoría de la gente nunca elige de forma consciente: llama a un modelo de chat de solo decodificador y este se encarga de todo. Pero saber por qué los embeddings vienen de codificadores y la generación de decodificadores explica muchas decisiones de arquitectura que de otro modo parecen misteriosas, incluida la razón por la que un proceso RAG combina un modelo de embeddings codificador con un modelo de generación decodificador.