Desglose paso a paso del recorrido de los tokens a través del modelo, desde la entrada en texto hasta la generación del siguiente token.
En el contexto de los grandes modelos de lenguaje (LLM) como GPT-2, el término inferencia se refiere al proceso de utilizar un modelo ya entrenado para generar una predicción o respuesta a partir de una entrada de datos. Para los arquitectos de software, comprender este flujo es de importancia estratégica, ya que define cómo una aplicación interactuará con el modelo para producir resultados en tiempo real.
Para los arquitectos, este proceso secuencial y dependiente del estado tiene implicaciones directas en el diseño de sistemas, influyendo en las decisiones sobre estrategias de procesamiento por lotes (batching), la optimización de la latencia para aplicaciones en tiempo real y la gestión de los recursos computacionales necesarios para cada paso de la generación token por token.
Este proceso es fundamentalmente distinto al entrenamiento, que es la fase de aprendizaje computacionalmente intensiva donde el modelo ajusta sus parámetros internos a partir de un vasto corpus de datos. A diferencia de las redes neuronales clásicas, donde las entradas pueden procesarse en paralelo de forma independiente, el procesamiento en un Transformer es inherentemente secuencial y contextual: el significado de cada elemento depende de su relación con todos los demás elementos de la secuencia.
Este informe desglosará cada etapa del flujo de inferencia, comenzando por la preparación de la entrada para su procesamiento por el modelo.
Antes de que un modelo Transformer pueda procesar texto, el lenguaje humano debe ser traducido a una representación matemática estructurada. Esta fase de preparación de la entrada es fundamental, ya que convierte una secuencia de caracteres en un formato numérico de alta dimensión que encapsula tanto el significado semántico de las palabras como su orden dentro de la secuencia.
Este proceso se divide en dos pasos principales: la tokenización y la construcción de un embedding inicial.
El primer paso es la tokenización, donde el texto de entrada se descompone en unidades más pequeñas llamadas tokens. A cada token único en el vocabulario del modelo se le asigna un identificador numérico (ID de token). Este proceso convierte una cadena de texto en una secuencia de números enteros que el modelo puede interpretar.
Por ejemplo, al procesar el siguiente texto:
Hola mundo Esta es una prueba de tokenizacion real.
El tokenizador lo convierte en un tensor de identificadores numéricos, como se muestra a continuación:
tensor([[ 39, 5708, 27943, 78, 198, 22362, 64, 1658, 555, 64, 778, 518, 7012, 390, 11241, 528, 49443, 1103, 13, 198]])torch.Size([1, 20])Esto indica que el texto original ha sido descompuesto en una secuencia de 20 tokens, cada uno representado por un ID único.
Cada ID de token debe ser convertido en un vector denso y significativo. Este embedding inicial se construye sumando dos componentes vectoriales distintos, ambos con una dimensionalidad de 768 en el caso de GPT-2.
Cada ID de token se utiliza como un índice para consultar una gran tabla de embeddings pre-entrenada. Esta tabla asigna a cada token un vector fijo de 768 dimensiones que representa su significado semántico. Este vector fue aprendido durante la fase de entrenamiento del modelo y permanece inalterado durante la inferencia. Por ejemplo, el token para "Hola" siempre corresponderá al mismo vector de 768 valores.
Para que el modelo comprenda el orden de las palabras, se genera un segundo vector de 768 dimensiones. Este vector se obtiene de una tabla de embeddings de posición separada. A diferencia del embedding de token, este vector no depende del contenido de la palabra, sino únicamente de su posición en la secuencia de entrada (por ejemplo, la primera palabra, la segunda, y así sucesivamente).
Los dos vectores —el embedding de token y el embedding de posición— se suman elemento a elemento para crear el embedding inicial de cada token. La lógica subyacente es que tanto el significado de una palabra (qué es) como su ubicación en la frase (dónde está) son cruciales para determinar el contexto completo.
Este vector combinado, que integra información semántica y posicional, sirve como la entrada inicial para el proceso de contextualización que ocurre dentro de los bloques Transformer.
El resultado de esta operación es un tensor final con la siguiente forma:
torch.Size([1, 20, 768])Esto representa un lote (1), con 20 tokens, donde cada token es ahora un vector de 768 dimensiones. Un ejemplo del primer embedding de la secuencia podría verse así (mostrando solo los primeros 10 de 768 valores):
tensor([-0.2077, -0.1556, -0.1638, 0.0468, -0.0956, -0.3012,
0.1546, 0.1558, -0.3139, -0.0316, ...])
Estos embeddings iniciales, que ya contienen información semántica y posicional, están ahora listos para ser procesados por el núcleo del modelo: los bloques Transformer.
El bloque Transformer es la unidad de procesamiento fundamental y repetitiva del modelo. Su propósito es refinar iterativamente los embeddings de entrada. Dentro de cada bloque, cada token puede "mirar" a todos los demás tokens de la secuencia para reinterpretar y enriquecer su propia representación vectorial con información contextual completa.
Cada bloque se compone de dos subcapas principales: un mecanismo de auto-atención y una red de proyección feed-forward.
La auto-atención es el mecanismo que permite al modelo ponderar dinámicamente la importancia de las diferentes palabras en la secuencia de entrada al procesar una palabra específica. Este proceso permite que la información fluya entre los tokens, contextualizándolos.
El embedding de entrada de cada token se proyecta en tres vectores distintos: Query, Key y Value. Esto se logra multiplicando el vector de embedding por tres matrices de pesos (W_Q, W_K, W_V) que fueron aprendidas durante el entrenamiento.
| Elemento | Descripción | Origen |
|---|---|---|
| X | Embedding inicial (token + posición) para cada token. | Calculado en la etapa de preparación. |
| W_Q | Matriz de pesos para generar el vector Query. | Aprendida en entrenamiento (valor fijo). |
| W_K | Matriz de pesos para generar el vector Key. | Aprendida en entrenamiento (valor fijo). |
| W_V | Matriz de pesos para generar el vector Value. | Aprendida en entrenamiento (valor fijo). |
Conceptualmente, estos vectores representan:
A continuación, el modelo calcula una puntuación de atención entre cada par de tokens usando sus vectores Query y Key. Esta puntuación determina cuánto "interés" debe prestar un token a otro. La fórmula es la siguiente:
attention_scores = softmax(Q · Kᵀ / √dₖ)
El resultado es una matriz de puntuaciones (de 20 × 20 en nuestro ejemplo), donde cada fila representa un token observador y cada columna representa el token al que se le presta atención. Es importante notar que el vector V (Value) no se utiliza en este cálculo; esta fase solo determina los pesos de la atención.
Finalmente, la matriz de pesos de atención se aplica a los vectores de Valor (V). Para cada token, se calcula un nuevo embedding mediante una suma ponderada de los vectores V de todos los tokens de la secuencia, donde los pesos son las puntuaciones de atención calculadas.
nuevo_embedding[i] = Σ_j ( attention_scores[i, j] × V[j] )
Ejemplo ilustrativo: Consideremos la frase "Hoy martes llueve" y calculemos el nuevo embedding para el token "hoy".
Vectores V simplificados (4 dimensiones):
Pesos de atención calculados para "hoy":
Cálculo del nuevo embedding contextualizado:
El vector resultante para "hoy" es una nueva representación sintetizada. Si bien el alto peso de atención (0.7) hace que el vector de "martes" sea el contribuyente dominante, el embedding final es una mezcla compuesta, sutilmente influenciada por todos los tokens en proporción a su relevancia calculada. Este es el fundamento matemático de la comprensión contextual en los Transformers.
Después del mecanismo de atención, se aplican dos operaciones cruciales para la estabilidad numérica y la eficacia del modelo.
El embedding original (X) se suma elemento a elemento al nuevo embedding contextualizado (Embedding_Score) generado por la atención:
Embedding_Residual = X + Embedding_Score
Esta operación, conocida como conexión residual o skip connection, es estratégicamente vital. Asegura que la información original del token no se pierda durante la transformación, preservando su significado base mientras se le añade el nuevo contexto.
El vector resultante de la suma residual se normaliza. La normalización de capa (LayerNorm) reescala las activaciones para que tengan una media cercana a 0 y una varianza cercana a 1.
Fórmula general:
LayerNorm(x) = (x - media) / sqrt(varianza + ε)
Ejemplo de cálculo para un vector x = [2.0, 0.5, 1.5, 3.0]:
Esta operación estabiliza el flujo de datos a través de la red, evitando que los valores de las activaciones crezcan o disminuyan descontroladamente en capas sucesivas.
La segunda subcapa principal del bloque Transformer es una red feed-forward (FFN). A diferencia del mecanismo de atención, que procesa las relaciones entre tokens, la FFN procesa cada embedding de token de forma aislada a través de una transformación no lineal.
La expansión hacia un espacio de mayor dimensionalidad puede entenderse como la creación de un "espacio de trabajo computacional". En este espacio expandido, el modelo tiene más libertad expresiva para desenredar y aislar características complejas y abstractas del vector de entrada, características que podrían no ser linealmente separables en la dimensión original.
La activación ReLU actúa entonces como un filtro, preservando solo las características más destacadas antes de que la capa de contracción proyecte esta representación refinada de nuevo al espacio original de 768 dimensiones. Este proceso se ejecuta en tres pasos:
h1 = x_norm · W1 + b1
ReLU(x) = max(0, x)
output_ffn = h1_relu · W2 + b2
De manera análoga a la subcapa de atención, la salida de la FFN también pasa por una conexión residual y una capa de normalización final. Este proceso consolida la transformación del embedding dentro de un bloque Transformer completo.
A continuación se resume la evolución del vector a través de estas etapas (ejemplo en 4D):
[ 0.277, -1.386, -0.277, 1.386 ]
[ 1.01164, 0.2867, -0.361, 0.50358 ]
[ 1.28864, -1.0993, -0.638, 1.88958 ]
[ 0.894, -1.41, -0.97, 1.48 ]
Este bloque completo se apila múltiples veces. Cada capa refina progresivamente la comprensión del modelo sobre las complejas interacciones semánticas y sintácticas de la secuencia.
La arquitectura de GPT-2 consiste en apilar múltiples bloques Transformer, uno tras otro. Esta arquitectura apilada es análoga a una pipeline de procesamiento de señales multietapa con bucles de retroalimentación, donde la salida de cada bloque —una señal parcialmente refinada— se alimenta a la siguiente para una mayor corrección y estabilización, permitiendo el desarrollo progresivo de características semánticas complejas.
Este procesamiento iterativo permite un refinamiento profundo de la representación semántica de cada token, pasando de correlaciones simples a inferencias de alto nivel. Un modelo como GPT puede tener hasta 96 de estas capas. (verificar)
Para ilustrar cómo evoluciona la "comprensión" del modelo a través de las capas, consideremos la frase:
Hoy martes llueve, asi que...
"hoy" con "martes" como fecha actual y "llueve" como un evento climático presente.
"hoy" se reinterpreta como un "día lluvioso" que puede afectar una acción; "llueve" se asocia con un impacto en la movilidad.
"lluvia" y "paraguas" coexisten en contextos causales, el modelo ha ajustado sus pesos de tal manera que sus respectivos vectores de embedding ahora exhiben una alta similitud matemática. En esta capa, el mecanismo de atención aprovecha esta similitud aprendida para enriquecer el embedding de "llueve" con estas asociaciones probabilísticas.
"llueve" ahora encapsula su rol como la condición causal prioritaria que debe determinar el siguiente token.
La función de la última capa de Transformer es diferente. Una vez que los embeddings han sido completamente refinados, el embedding final del último token de la secuencia de entrada se proyecta hacia el vocabulario completo del modelo. Esta proyección genera una distribución de probabilidad sobre todos los tokens posibles, indicando cuál es el más probable para continuar la secuencia.
Para la frase: "Hoy martes llueve, asi que...", el modelo podría generar las siguientes probabilidades:
| Token | Probabilidad |
|---|---|
| paraguas | 0.64 |
| llevar | 0.18 |
| sacar | 0.05 |
| abrigo | 0.03 |
| coche | 0.01 |
El modelo selecciona el token con la probabilidad más alta, en este caso "paraguas", como la continuación más lógica y lo genera como salida.
El proceso de inferencia de GPT-2 es una secuencia orquestada de transformaciones matemáticas: desde la tokenización inicial del texto, la creación de embeddings que capturan significado y posición, el procesamiento iterativo a través de múltiples bloques de Transformer —donde los mecanismos de atención y las redes feed-forward refinan el contexto—, hasta la proyección final que genera una distribución de probabilidad para el siguiente token.
Es crucial reflexionar sobre la naturaleza de este "entendimiento". El proceso descrito es puramente computacional. El modelo de IA no "piensa" ni posee una lógica humana abstracta. Su habilidad para generar texto coherente y contextualizado se deriva de la asociación de patrones numéricos, específicamente la similitud entre embeddings, que ha aprendido a partir de una cantidad masiva de datos durante el entrenamiento.
La relación entre "lluvia" y "paraguas" no es un concepto lógico para el modelo, sino una fuerte correlación matemática entre sus vectores. Por lo tanto, el resultado de la inferencia es siempre una predicción probabilística, no una verdad absoluta, y requiere un análisis crítico por parte del usuario.
Para el arquitecto de software, esta distinción es primordial: el sistema que se está integrando no es un motor de razonamiento, sino un sofisticado aparato de coincidencia de patrones de alta dimensionalidad. Sus resultados deben ser tratados como hipótesis probabilísticas, no como verdades definitivas, y la responsabilidad de la validación crítica recae enteramente en el sistema de implementación y sus operadores humanos.