Módulo final del Curso de Transformers. En el módulo 11 vimos las arquitecturas que hacen a los modelos modernos eficientes. Ahora subimos la cámara y miramos el bosque completo. Recorrimos el camino entero: de convertir texto en números (módulo 1) a MoE y KV cache (módulos 10-11). Queda cerrar con las preguntas que un ingeniero se hace fuera del modelo: ¿cuánto conviene crecer? ¿qué NO puede hacer esto por diseño? ¿hacia dónde va? Este módulo no enseña una pieza nueva del Transformer — enseña a mirarlo como pieza de un producto.

La tesis del módulo

Un Transformer entrenado no es un producto: es un componente con leyes de escalado, límites duros y una dirección de evolución. Saber cuánto escalarlo, qué no esperar de él y hacia dónde va el campo es lo que separa a quien usa un LLM de quien construye con él.

Cuánto crecer: las scaling laws

Durante años, mejorar un modelo fue una carrera de tamaño: más parámetros, mejor. Pero, ¿cuánto de cada cosa? Las scaling laws (leyes de escalado) son las relaciones —medidas empíricamente— entre el tamaño del modelo, la cantidad de datos de entrenamiento y el cómputo invertido, y qué tanto mejora el resultado. No son magia: son curvas que dicen cuánto rinde cada dólar de cómputo.

El hallazgo que cambió el campo fue Chinchilla (DeepMind, 2022): mostró que los modelos grandes de la época estaban sub-entrenados — tenían demasiados parámetros para tan pocos datos. La conclusión, hoy conocida como relación óptima de Chinchilla: para un presupuesto de cómputo dado, conviene balancear parámetros y datos (a grandes rasgos, escalarlos juntos), no inflar solo el tamaño del modelo.

  presupuesto de cómputo fijo, ¿cómo repartirlo?

  ┌───────────────┬───────────────┐
  │  demasiados   │  balanceado   │
  │  parámetros   │  (Chinchilla) │
  │  pocos datos  │  params+datos │
  ├───────────────┼───────────────┤
  │ sub-entrenado │ óptimo para   │
  │ desperdicia   │ ese cómputo   │
  └───────────────┴───────────────┘

La consecuencia práctica: los modelos modernos son más chicos de lo que serían con la vieja mentalidad, pero entrenados con muchísimos más datos. Un modelo de 7B bien entrenado hoy supera a monstruos de hace unos años. Escalar bien no es “más grande”: es la proporción correcta.

Los límites reales: lo que un LLM NO puede hacer

Un Transformer es asombroso y, al mismo tiempo, tiene fronteras duras que no se arreglan con un prompt más ingenioso. Conocerlas es parte del oficio:

Límite	Qué es	Por qué ocurre
Alucinaciones	Inventa datos con total seguridad	Predice el token probable, no la verdad
Knowledge cutoff	No sabe nada posterior a su entrenamiento	Sus pesos se congelaron en una fecha
Ventana de contexto	No puede leer más de N tokens	Costo cuadrático y KV cache (módulo 10)
Costo / latencia	Cada token cuesta cómputo y tiempo	Miles de millones de operaciones por token
Sin estado	No recuerda entre conversaciones	Solo “ve” lo que está en su contexto actual

Dos merecen un párrafo. Las alucinaciones no son un bug que se parcha: son consecuencia directa de cómo funciona el modelo — predice el token más plausible, y lo plausible no siempre es lo verdadero. Un modelo puede inventar una cita, un dato o una función que no existe con la misma fluidez con la que dice algo cierto. Por eso los sistemas serios verifican, citan fuentes (RAG) o restringen el dominio.

El knowledge cutoff (fecha de corte del conocimiento) es la fecha hasta la cual el modelo vio datos en su entrenamiento: no sabe nada de lo que pasó después, porque sus pesos se congelaron ahí. Preguntarle por eventos recientes es pedirle que adivine. La solución no es reentrenar cada semana, sino darle la información fresca en el contexto — y eso nos lleva al futuro.

Cuidado: estos límites no son fallas de un modelo malo; son propiedades de la tecnología. Un modelo mejor alucina menos y tiene más contexto, pero no elimina el problema. Construir producto es diseñar alrededor de estos límites, no esperar que desaparezcan.

Hacia dónde va: multimodalidad y agentes

El Transformer que estudiamos procesa texto. Pero la arquitectura no tiene nada de intrínsecamente textual: si puedes convertir algo en una secuencia de vectores, el Transformer puede procesarlo. De ahí salen las dos grandes direcciones del campo.

Multimodalidad. Imágenes, audio y video se trocean en “tokens” (parches de imagen, fragmentos de audio) y entran al mismo mecanismo de atención que el texto. Así nacen los modelos que ven y escuchan, no solo leen. Es exactamente el puente que exploramos en el curso de generación de imágenes, módulo multimodal: el mismo Transformer, otras entradas. La frontera entre “modelo de lenguaje” y “modelo de todo” se está borrando.

Agentes. Un LLM solo predice texto. Pero si le das herramientas (buscar en la web, ejecutar código, llamar APIs) y un bucle que le deje actuar sobre los resultados, deja de ser un autocompletado y se vuelve un sistema que resuelve tareas de varios pasos. Aquí se resuelven de golpe varios límites de arriba: el knowledge cutoff (busca lo nuevo), las alucinaciones (verifica con herramientas), la falta de estado (memoria externa). Es el salto del modelo al producto, y es justo lo que arma el curso de LangGraph.

El mapa completo del curso

  bloque básico        bloque interm.       bloque avanzado
  la arquitectura      el entrenamiento     inferencia/prod
  ┌──────────────┐     ┌──────────────┐     ┌──────────────┐
  │ tokens y     │     │ del GPT al   │     │ decodificar  │
  │ embeddings   │     │ pretraining  │     │ KV cache y   │
  │ atención     │ ──► │ fine-tuning  │ ──► │ FlashAttn    │
  │ multi-head   │     │ RLHF y       │     │ MoE y GQA    │
  │ arquitectura │     │ alineamiento │     │ el producto  │
  └──────────────┘     └──────────────┘     └──────────────┘

La progresión completa: entiendes cómo se arma un Transformer, cómo aprende a base de datos y alineamiento, y cómo se pone a generar texto de forma eficiente en el mundo real — con la lucidez de saber qué puede y qué no puede hacer. Ese era el contrato del módulo 1: no usar la caja negra, sino abrirla. Está cumplido.

Errores comunes

Creer que más parámetros siempre es mejor. Chinchilla mostró lo contrario: sin datos suficientes, escalar el tamaño desperdicia cómputo. La proporción manda.
Tratar las alucinaciones como un bug parchable. Son consecuencia de predecir lo plausible. Se mitigan con verificación y RAG, no se eliminan con un prompt.
Olvidar el knowledge cutoff. El modelo no sabe nada posterior a su entrenamiento; para lo fresco, dáselo en el contexto o dale herramientas.
Confundir el modelo con el producto. Un LLM es un componente. El producto son las herramientas, la memoria, las verificaciones y el bucle que lo rodean.
Esperar que el modelo recuerde solo. No tiene estado entre sesiones; lo que no está en su contexto, no existe para él. La memoria se diseña por fuera.

La frase para llevarse

“El Transformer es un motor extraordinario con límites conocidos: predice lo plausible, se congela en una fecha y no recuerda nada por sí solo. El producto no es el motor — es todo lo que construyes alrededor para que ese motor sea útil y honesto.”

Qué viene: fin del curso

Doce módulos: de “una red neuronal solo come números” al modelo convertido en producto, con multimodalidad y agentes en el horizonte. Abrimos la caja negra pieza por pieza —tokens, atención, arquitectura, entrenamiento, alineamiento, decodificación, eficiencia— y ya no queda misterio, solo ingeniería.

Si completaste la serie con tu cuenta de la academia, el certificado es tuyo. El glosario de Transformers queda como referencia permanente para cuando un término se te escape. Y desde aquí los caminos naturales son dos: hacia lo multimodal (cómo ven los LLM) y hacia los agentes (LangGraph) — porque entender el Transformer por dentro era, todo este tiempo, el permiso para construir en serio sobre él.

Transformers — Módulo 12: del modelo al producto — escalado, límites y hacia dónde va