El Viaje de una Pregunta en un LLM: De tu prompt al token final

Escribes una pregunta en ChatGPT:

“Explícame por qué el cielo es azul”

Y, unos segundos después, aparece una respuesta clara, fluida y aparentemente instantánea.

Pero entre tu mensaje y ese texto final pasan muchas cosas. No hay una “mente” pensando como humano: hay una pipeline de procesamiento, contexto, cálculo probabilístico y generación token a token.

Este es el viaje completo de una pregunta en un sistema tipo ChatGPT.

Escena 1: La interfaz captura tu mensaje

Todo empieza en el cliente: navegador, app móvil o integración vía API.

El sistema normalmente envía algo más que tu última frase:

• Tu mensaje actual
• Parte del historial de conversación
• Instrucciones del sistema
• Metadatos de sesión
• A veces herramientas disponibles o documentos recuperados

Es decir: el modelo casi nunca recibe “solo una pregunta”. Recibe un paquete de contexto.

Modelo mental:

[System prompt]
[Historial resumido o reciente]
[Mensaje del usuario]
[Contexto adicional]

Escena 2: Orquestación antes del modelo

Antes de llegar al LLM, suele haber una capa de backend que prepara la request.

Allí pueden ocurrir tareas como:

1. Autenticación del usuario
2. Validación de límites de uso
3. Moderación básica del input
4. Recuperación de memoria conversacional
5. Búsqueda de contexto externo (RAG)
6. Selección del modelo a usar

En productos reales, esta capa importa tanto como el modelo. Muchas veces la calidad percibida depende más de la orquestación que del LLM en sí.

Escena 3: Tokenización, el texto deja de ser texto

El modelo no trabaja directamente con palabras humanas. Primero convierte el texto en tokens.

Un token puede ser:

• una palabra completa
• parte de una palabra
• un signo de puntuación
• un espacio o fragmento frecuente

Por ejemplo, una frase como:

El cielo es azul

puede dividirse en unidades internas que el modelo sí sabe procesar.

Esto importa porque:

• el costo suele medirse por tokens
• la ventana de contexto se mide en tokens
• la generación también ocurre token por token

No hay magia aquí: primero se transforma lenguaje en piezas numéricas manejables.

Escena 4: Embeddings internos y representación numérica

Una vez tokenizado, cada token se transforma en un vector numérico interno.

Ese paso permite que el modelo opere matemáticamente sobre el texto. Ya no está viendo "azul" como una palabra, sino como una representación en un espacio de alta dimensión.

Aquí conviene separar dos ideas:

• Embeddings de retrieval: se usan en búsqueda semántica o RAG
• Embeddings internos del modelo: se usan para procesar el prompt durante la inferencia

Ambos convierten texto en números, pero no cumplen exactamente el mismo rol.

Escena 5: El Transformer procesa todo el contexto

Aquí entra el corazón del sistema: la arquitectura Transformer.

El modelo toma todos los tokens del contexto y calcula relaciones entre ellos mediante mecanismos de atención.

La idea simplificada es esta:

• cuando aparece “azul”, el modelo puede relacionarlo con “cielo”
• cuando aparece “por qué”, reconoce una intención explicativa
• cuando ve historial previo, ajusta tono, continuidad y contexto

No “entiende” como una persona. Calcula qué partes del contexto son más relevantes para predecir lo siguiente.

Una intuición útil:

Prompt completo
   ↓
Tokens
   ↓
Capas del transformer
   ↓
Distribución de probabilidad del siguiente token

Escena 6: El modelo no genera una respuesta, genera el siguiente token

Este es el punto más importante para entender un LLM.

El modelo no escribe una respuesta entera de una vez. Hace algo mucho más mecánico:

1. mira el contexto completo
2. predice cuál es el siguiente token más probable
3. agrega ese token al contexto
4. repite el proceso

Así, una respuesta larga nace como una cadena de pequeñas decisiones sucesivas.

Ejemplo simplificado:

Pregunta: "¿Por qué el cielo es azul?"

El modelo podría generar:
"Porque" → "la" → "atmósfera" → "dispersa" → "más" ...

Cada paso depende de todos los anteriores.

Escena 7: Decodificación y control de estilo

La elección del siguiente token no siempre es “el más probable y listo”.

Existen parámetros y reglas que afectan el comportamiento:

• temperature: más alta, más variación; más baja, más estabilidad
• top-k / top-p: limitan el espacio de opciones
• instrucciones de sistema
• formato exigido, por ejemplo JSON

Por eso el mismo prompt puede producir respuestas distintas según configuración.

Un modelo de soporte técnico probablemente use menor temperatura. Uno creativo para brainstorming tolera más variación.

Escena 8: Herramientas, memoria y RAG si la arquitectura lo requiere

En algunos productos, el modelo no responde solo con su conocimiento entrenado.

Puede apoyarse en componentes externos:

• Memoria conversacional: resumen o historial previo
• RAG: búsqueda de documentos relevantes
• Tools: calculadoras, navegadores, bases de datos, APIs
• Function calling: salida estructurada para que otro sistema ejecute acciones

En ese caso, el flujo se parece más a esto:

Usuario pregunta
   ↓
Orquestador prepara contexto
   ↓
LLM decide o recibe contexto externo
   ↓
Se consulta herramienta o documentos
   ↓
Se arma un nuevo prompt enriquecido
   ↓
LLM genera respuesta final

Esto explica por qué dos asistentes que usan “el mismo modelo” pueden comportarse de forma muy distinta: el producto no es solo el LLM, es toda la arquitectura alrededor.

Escena 9: Guardrails, moderación y validaciones

Antes, durante o después de la generación, muchos sistemas aplican controles adicionales:

• detección de contenido riesgoso
• filtrado de datos sensibles
• validación de formato
• límites de longitud
• reglas de seguridad del producto

Si pides salida estructurada, también puede haber validación posterior:

• “esto no es JSON válido”
• “faltan campos requeridos”
• “la herramienta devolvió error”

Es decir, la respuesta final que ves puede ser el resultado de:

1. generación del LLM
2. postprocesamiento
3. validación
4. posible reintento

Escena 10: Streaming, la respuesta aparece en pantalla

Muchos sistemas no esperan a tener todo el texto terminado. Hacen streaming.

Eso significa que envían fragmentos a medida que el modelo genera tokens.

Por eso ves el texto aparecer poco a poco:

"Porque..."
"Porque la atmósfera..."
"Porque la atmósfera dispersa..."

El streaming mejora la percepción de velocidad, incluso cuando el tiempo total de generación no cambia demasiado.

Escena 11: La respuesta se guarda como contexto futuro

Cuando termina la respuesta, el sistema normalmente guarda parte del intercambio:

• mensaje del usuario
• respuesta del asistente
• identificadores de sesión
• herramientas invocadas
• a veces resúmenes de memoria

Eso permite continuidad conversacional.

Pero también introduce límites:

• el contexto no es infinito
• conversaciones largas deben resumirse o truncarse
• si el resumen es malo, la calidad futura cae

Un chatbot útil no depende solo de “recordar”. Depende de recordar bien lo relevante.

El diagrama completo

Usuario escribe pregunta
        ↓
Interfaz envía mensaje al backend
        ↓
Orquestación:
- historial
- system prompt
- moderación
- RAG / tools
        ↓
Tokenización
        ↓
Representación numérica
        ↓
Transformer procesa contexto
        ↓
Predicción del siguiente token
        ↓
Generación token a token
        ↓
Validaciones / guardrails
        ↓
Streaming al cliente
        ↓
Respuesta visible + guardado de contexto

Qué parte suele consumir más tiempo

En una arquitectura real, la latencia total puede venir de varios lugares:

Etapa	Qué puede demorar
Orquestación	cargar historial, auth, rate limiting
RAG	embeddings, búsqueda vectorial, re-rank
Inferencia	ejecución del modelo
Tools	llamadas a APIs o bases externas
Postproceso	validación de formato o reintentos

No toda la demora es “el modelo pensando”. Muchas veces el cuello de botella está alrededor del modelo.

Errores comunes al imaginar cómo funciona

1. Pensar que el modelo “busca en internet” cada vez que responde.
2. Pensar que entiende palabras como un humano, cuando opera sobre tokens y vectores.
3. Creer que redacta una respuesta completa de una sola vez.
4. Asumir que toda respuesta sale solo del entrenamiento, ignorando memoria, RAG o tools.
5. Confundir fluidez con veracidad.

La respuesta puede sonar convincente y aun así ser incorrecta.

Resumen del viaje

Cuando preguntas algo en ChatGPT o en un sistema similar, normalmente ocurre esto:

1. La interfaz captura tu mensaje y arma contexto.
2. Un backend orquesta historial, reglas y posibles fuentes externas.
3. El texto se tokeniza.
4. El modelo transforma esos tokens en representaciones numéricas.
5. El transformer calcula relaciones dentro del contexto.
6. El sistema genera la salida token a token.
7. Se aplican controles, formato y posibles herramientas.
8. La respuesta se transmite en streaming y se guarda para el siguiente turno.

Lo que parece una conversación natural es, en realidad, una cadena de decisiones estadísticas cuidadosamente envueltas en producto, UX y arquitectura.

Y ahí está la clave: un buen asistente no es solo un buen modelo. Es un buen sistema completo alrededor del modelo.