En la lección anterior tratamos el LLM como una caja negra que recibe texto y devuelve texto. En esta lección vamos a abrir esa caja lo justo para que puedas trabajar con ella de forma eficaz. No necesitas dominar el cálculo matricial que ocurre dentro de un transformer, igual que no necesitas conocer los árboles B+ para usar PostgreSQL; pero sí necesitas entender tokens (porque determinan límites y costes de cada llamada), embeddings (porque son la base de la búsqueda semántica que usará DocuBot), la idea de atención (porque explica por qué el modelo maneja bien el contexto) y el hecho de que todo se reduce a predecir el siguiente token (porque explica tanto las capacidades como los fallos del modelo). Esta visión práctica te permitirá razonar sobre el comportamiento del modelo en lugar de tratarlo como magia.

1. La idea central: predecir el siguiente token
2. Tokenización: cómo ve el texto un LLM
3. Embeddings: representar el significado con números
4. La arquitectura transformer y el mecanismo de atención
5. De la predicción a la respuesta: muestreo, temperature y top_p
6. Cómo se entrena un LLM: pre-entrenamiento, fine-tuning y RLHF

Aunque parezca sorprendente, todo lo que hace un LLM se reduce a una única operación repetida muchas veces:

Dado un texto de entrada, calcular qué fragmento de texto (token) es más probable que venga a continuación.

Cuando le preguntas a DocuBot "¿Qué es Nubelia?", el modelo no busca la respuesta en una base de datos ni ejecuta un razonamiento simbólico. Genera la respuesta token a token: predice el primer token de la respuesta, lo añade al texto, predice el siguiente teniendo en cuenta todo lo anterior, y así sucesivamente hasta que predice un token especial de "fin".

En pseudocódigo:

Fíjate en dos consecuencias directas de este diseño, que reaparecerán durante todo el curso:

• El modelo siempre genera algo. No hay un mecanismo interno de "no lo sé"; si el texto más probable a continuación de una pregunta es una respuesta con apariencia de cierta, eso es lo que produce, sea verdad o no. Aquí está la semilla de las alucinaciones que analizaremos en la lección 01-04.
• El texto de entrada lo es todo. La única forma de influir en la predicción es cambiar lo que el modelo recibe. Por eso el prompting (módulo 2) y la gestión del contexto (módulos 3 y 4) son tan importantes.

Que un mecanismo tan simple produzca traducciones, código funcional o razonamientos se debe a la escala: para predecir bien el siguiente token de cualquier texto, el modelo se ve obligado a aprender gramática, hechos, estilos y patrones de razonamiento presentes en sus datos de entrenamiento.

Hemos dicho "token" varias veces. Definámoslo bien, porque es el concepto más práctico de toda la lección.

Un LLM no procesa caracteres ni palabras: procesa tokens, fragmentos de texto de longitud variable que salen de trocear la entrada con un diccionario fijo (el vocabulario, típicamente de 50.000 a 200.000 tokens). El proceso de trocear el texto se llama tokenización, y lo realiza un componente determinista llamado tokenizador antes de que el texto llegue a la red neuronal.

• Las palabras frecuentes suelen ser un único token: " the", " de", " project".
• Las palabras raras o largas se parten en varios: "Nubelia" podría tokenizarse como ["Nub", "elia"].
• Los espacios y signos de puntuación forman parte de los tokens (a menudo el espacio inicial va pegado a la palabra).
• El código también se tokeniza: def, paréntesis, indentación... todo consume tokens.

Un ejemplo ilustrativo (los cortes exactos dependen de cada tokenizador):

Como regla mental rápida para estimar: en inglés, 1 token ≈ 4 caracteres ≈ 0,75 palabras. En español la proporción suele ser algo peor (más tokens por palabra), porque los vocabularios de la mayoría de modelos se construyeron con predominio de texto en inglés.

Un ejemplo clásico: si un modelo falla al contar las letras "r" de una palabra, no es porque "no sepa contar"; es porque nunca ve las letras individuales — ve uno o dos tokens opacos que representan la palabra completa.

Para DocuBot esto tiene una consecuencia directa que retomaremos en el módulo 4: la documentación de Nubelia ocupa muchísimos más tokens de los que caben en una llamada, así que no podremos "pasarle toda la wiki" al modelo; habrá que seleccionar los fragmentos relevantes para cada pregunta.

Una red neuronal solo opera con números, así que el primer paso tras tokenizar es convertir cada token en un vector: una lista de cientos o miles de números decimales. Ese vector es el embedding del token.

Lo fascinante de los embeddings es que no son códigos arbitrarios: capturan significado. Durante el entrenamiento, el modelo aprende a colocar en posiciones cercanas del espacio vectorial los tokens (y, por extensión, las frases) que aparecen en contextos similares. El resultado es una especie de "mapa del significado":

La "cercanía" se mide con operaciones geométricas sencillas (como la similitud coseno, el ángulo entre dos vectores). Y el concepto escala más allá de tokens sueltos: existen modelos especializados que producen el embedding de una frase o un documento completo, de modo que "¿cómo reinicio el servicio de informes?" y "reinicio del módulo de reporting" acaban con vectores muy próximos aunque no compartan casi ninguna palabra.

¿Ves hacia dónde apunta esto para DocuBot? Si podemos convertir cada fragmento de la documentación de Nubelia en un vector, y también la pregunta del usuario, entonces encontrar la documentación relevante se convierte en buscar los vectores más cercanos. Esa es la búsqueda semántica, la pieza central de RAG, y la desarrollaremos en la lección 04-01. Por ahora, quédate con la idea: embedding = significado convertido en coordenadas.

Dentro del propio LLM, los embeddings de los tokens de entrada son el punto de partida: la primera capa de la red los toma y, capa a capa, los va refinando con la información de su contexto. Lo que hace ese refinamiento es, precisamente, la atención.

Como vimos en la lección anterior, la arquitectura transformer (2017) es el hito que hizo posibles los LLMs. Su innovación central es el mecanismo de atención (attention). Veámoslo conceptualmente, sin matemáticas.

El problema que resuelve: el significado de una palabra depende de su contexto, y ese contexto puede estar lejos. Observa:

"El equipo de soporte revisó el banco de pruebas antes del despliegue." "Se sentó en el banco del parque a leer la documentación."

Para representar bien "banco", el modelo necesita mirar otras palabras de la frase — y decidir cuáles importan. Eso es exactamente la atención: un mecanismo por el cual cada token calcula cuánta importancia debe dar a cada uno de los demás tokens del contexto, y actualiza su representación (su embedding) mezclando información de los tokens relevantes.

Una analogía útil para desarrolladores: la atención funciona como una consulta ponderada. Cada token lanza una "query" al resto de tokens ("¿quién de vosotros es relevante para mí?"), cada token responde con qué ofrece, y el resultado es una media ponderada donde los tokens relevantes pesan más.

Sobre esta idea, la arquitectura completa se organiza así:

• Un transformer apila decenas de capas, cada una con múltiples "cabezas" de atención en paralelo (cada cabeza aprende a fijarse en tipos distintos de relaciones: sintaxis, correferencias, patrones de código...), alternadas con pequeñas redes neuronales que transforman cada posición.
• Capa tras capa, la representación de cada token se enriquece con más y más contexto: de "qué token soy" a "qué significo exactamente en esta frase, este párrafo y este documento".
• A la salida de la última capa, la representación del último token se usa para calcular la probabilidad de cada posible token siguiente — y volvemos a la idea central de la lección.

Dos ventajas del transformer que explican su éxito frente a las redes recurrentes anteriores:

1. Paralelismo: la atención procesa todos los tokens a la vez (no uno tras otro), lo que permite entrenar con volúmenes de datos gigantescos.
2. Alcance: cualquier token puede atender directamente a cualquier otro, por lejos que esté, así que las dependencias a larga distancia no se "diluyen".

Los famosos parámetros de un modelo (cuando se habla de modelos "de miles de millones de parámetros") son justamente los números aprendidos que gobiernan estas capas: los pesos de la atención y de las transformaciones. Más parámetros suele significar más capacidad de capturar patrones — y más coste de ejecución.

Con esto tienes el nivel de detalle adecuado: suficiente para razonar sobre el modelo, sin perderte en la mecánica interna.

El modelo produce una distribución de probabilidad sobre el siguiente token. Pero ¿cuál se elige? Aquí entra el muestreo (sampling), y con él los dos parámetros que verás en todas las APIs de LLMs: temperature y top_p.

La opción más obvia sería elegir siempre el token más probable (muestreo greedy). Funciona, pero produce texto repetitivo y predecible, y ante preguntas creativas da siempre la misma salida. Por eso, en la práctica se elige el token al azar, ponderado por su probabilidad — y los parámetros de muestreo controlan cuánto azar.

• temperature (típicamente entre 0 y 1, a veces hasta 2): reescala la distribución de probabilidades.
  • Cerca de 0: acentúa las diferencias — los tokens probables se vuelven casi seguros. Salidas más deterministas, conservadoras y repetibles.
  • Cerca de 1: respeta la distribución original — más variedad y "creatividad", pero también más riesgo de desvíos.
• top_p (muestreo nucleus): en lugar de considerar todos los tokens, considera solo el conjunto más pequeño de tokens cuya probabilidad acumulada alcanza p (por ejemplo, 0.9), y muestrea solo entre ellos. Es un recorte de la "cola" de tokens improbables.

Guía práctica inicial (la afinaremos cuando integremos la API en el módulo 3):

Un aviso importante que retomaremos en 01-04: ni siquiera con temperature = 0 la salida está garantizada al 100% idéntica entre llamadas. Trata los LLMs como componentes no deterministas por diseño.

Última pieza del puzle: ¿cómo llega el modelo a predecir tan bien? El entrenamiento de un LLM moderno tiene tres fases principales. No vas a entrenar un modelo en este curso, pero conocer las fases explica comportamientos que verás a diario.

El modelo se entrena con cantidades enormes de texto (webs, libros, código público...) en una tarea única: predecir el siguiente token. Billones de tokens, semanas o meses de cómputo en miles de GPUs. De aquí sale el conocimiento general del modelo: idiomas, hechos, estilos, lenguajes de programación.

Dos consecuencias prácticas:

• El conocimiento del modelo queda congelado en la fecha de sus datos (el knowledge cutoff, que analizaremos en 01-04).
• El modelo solo sabe lo que estaba en esos datos. La wiki interna de Nubelia, obviamente, no estaba.

El resultado de esta fase (el modelo base) es un completador de texto muy potente, pero no un asistente: si le escribes una pregunta, puede perfectamente continuarla con más preguntas parecidas, porque eso es un texto estadísticamente plausible.

Para convertir el completador en asistente, se reentrena el modelo con un dataset mucho más pequeño y cuidado de ejemplos de conversaciones: instrucción del usuario → respuesta deseada. El modelo aprende el formato de comportarse como asistente: responder a lo que se pregunta, seguir instrucciones, mantener un diálogo.

Por último, se afina la calidad y el estilo de las respuestas: personas evalúan y comparan respuestas del modelo ("esta es mejor que esta otra"), con esas preferencias se entrena un modelo de recompensa, y el LLM se ajusta mediante aprendizaje por refuerzo para producir respuestas mejor valoradas: más útiles, más seguras, mejor explicadas.

Una consecuencia sutil de RLHF que conviene conocer: al optimizar para respuestas que "gustan", los modelos desarrollan cierta tendencia a sonar seguros y complacientes, incluso cuando no deberían. Otra pieza más del rompecabezas de las alucinaciones que armaremos en la lección 01-04.

• Confundir palabras con tokens. Los límites y precios de los modelos se expresan en tokens. Si estimas "este documento tiene 2.000 palabras, caben de sobra", puedes llevarte una sorpresa: en español pueden ser fácilmente 3.000–4.000 tokens. Usa siempre el tokenizador (o el contador de tokens) del modelo concreto para estimar.
• Creer que el modelo "consulta" información al responder. Un LLM puro no busca en ninguna base de datos en tiempo de respuesta: genera a partir de sus parámetros y del texto que le has pasado. Si necesitas datos actuales o privados, tendrás que ponérselos tú en el contexto (módulos 3 y 4).
• Atribuir a "falta de inteligencia" errores que son de tokenización. Contar letras, invertir cadenas u operar con números muy largos son tareas donde la representación en tokens juega en contra del modelo. Para esas tareas, usa código, no un LLM.
• Subir la temperature para "mejorar" respuestas factuales. Es al revés: para tareas tipo DocuBot (respuestas basadas en documentación) quieres temperature baja. La temperature alta es para tareas donde la variedad aporta valor.
• Esperar determinismo absoluto. Diseña tu aplicación asumiendo que dos llamadas idénticas pueden devolver textos distintos. Valida las salidas en lugar de compararlas con una cadena exacta (esto será clave al testear, en el módulo 6).
• Consejo: cuando el comportamiento de un modelo te desconcierte, repasa mentalmente el pipeline de esta lección — ¿qué tokens está viendo? ¿qué había en su contexto? ¿qué texto sería estadísticamente plausible a continuación? — y la mayoría de "misterios" se disuelven.

El equipo de Nubelia quiere pasar a DocuBot, en cada llamada, un fragmento de documentación de unas 1.200 palabras en español junto con la pregunta del usuario (unas 30 palabras). Usando la regla orientativa de que en español 1 palabra ≈ 1,5 tokens:

1. Estima cuántos tokens de entrada tendrá cada llamada (ignora instrucciones adicionales).
2. Si el modelo elegido tuviera una ventana de contexto de 8.000 tokens, ¿qué porcentaje de la ventana consumiría la entrada?
3. ¿Por qué esta estimación es solo orientativa y qué harías para obtener la cifra real?

Para cada uno de estos tres usos del LLM en Nubelia, indica si usarías una temperature baja (≈0–0.3), media (≈0.5–0.7) o alta (≈0.8–1.0), y justifica:

1. DocuBot respondiendo "¿qué puertos usa el servicio de informes?" a partir de un fragmento de documentación.
2. Generar 10 propuestas variadas de nombre para una nueva funcionalidad de la plataforma.
3. Resumir en un párrafo las notas de una reunión técnica.

Un compañero te pregunta: "¿Por qué dicen que la atención fue la clave de los LLMs? ¿Qué hace exactamente?". Escribe una explicación de 4–6 líneas, sin matemáticas, usando la frase "El banco de pruebas falló" frente a "Se sentó en el banco" como ejemplo.

Solución 1:

1. Documento: 1.200 × 1,5 = 1.800 tokens. Pregunta: 30 × 1,5 = 45 tokens. Total ≈ 1.845 tokens de entrada.
2. 1.845 / 8.000 ≈ 23% de la ventana. Queda margen, pero recuerda que la ventana también debe alojar las instrucciones del sistema, el historial de conversación y la respuesta generada.
3. Es orientativa porque la proporción palabras/tokens depende del tokenizador de cada modelo y del tipo de texto (el texto técnico con nombres propios como "Nubelia" o identificadores de código suele fragmentarse en más tokens). Para la cifra real, tokenizaría el texto con la herramienta o endpoint de conteo de tokens del modelo concreto.

Solución 2:

1. Baja. Es una respuesta factual basada en documentación: queremos precisión y consistencia; la creatividad aquí es un defecto.
2. Alta. El objetivo es variedad: con temperature baja las 10 propuestas se parecerían demasiado entre sí (y entre ejecuciones).
3. Baja o media-baja. Un resumen debe ser fiel al contenido; algo de flexibilidad de redacción es aceptable, pero no queremos que "adorne" o introduzca ideas que no estaban en las notas.

Solución 3 (ejemplo de respuesta):

"Antes de los transformers, los modelos procesaban el texto palabra a palabra y les costaba relacionar palabras lejanas. La atención permite que, al procesar cada palabra, el modelo mire todas las demás palabras del texto y decida cuáles son relevantes para interpretarla. Por ejemplo, 'banco' no significa nada concreto por sí solo: en 'el banco de pruebas falló', la atención da peso a 'pruebas' y 'falló' y el modelo lo interpreta como infraestructura técnica; en 'se sentó en el banco', el peso va a 'sentó' y lo interpreta como mobiliario. Como además esto se calcula para todas las palabras en paralelo, se pudo entrenar con volúmenes de datos enormes — y de esa escala salieron los LLMs."

Ya sabes qué hay dentro de la caja: un LLM tokeniza el texto (y por eso los límites y costes se miden en tokens), representa cada token como un embedding que captura significado (idea que será la base de la búsqueda semántica de DocuBot en el módulo 4), refina esas representaciones con capas de atención que deciden qué partes del contexto importan, y con todo ello predice el siguiente token, una y otra vez, con un grado de azar controlado por temperature y top_p. También conoces las tres fases de entrenamiento — pre-entrenamiento, fine-tuning e RLHF — y sus consecuencias: conocimiento amplio pero congelado en el tiempo, comportamiento de asistente, y cierta tendencia a sonar más seguro de lo que debería.

Con este modelo mental ya puedes evaluar críticamente lo que ofrece el mercado. En la siguiente lección, "Panorama de modelos y proveedores", veremos qué familias de modelos existen, qué criterios usar para compararlos (capacidad, contexto, coste, latencia, modalidades) y cómo decidir entre modelos propietarios vía API y modelos abiertos autoalojados — decisiones que Nubelia tendrá que tomar antes de escribir la primera línea de DocuBot.