Cómo se fabrica un modelo de lenguaje
Cuando pensamos en modelos como ChatGPT o Claude, solemos imaginar una arquitectura neuronal brillante, un algoritmo ingenioso ideado por genios. Es la historia cómoda: la inteligencia artificial como un problema de ingeniería matemática elegante.
La realidad, como suele pasar, es más terrenal.
Un amigo me habló de esta conferencia que había visto circular en X, y eso me llevó a buscar la fuente oficial: la charla que Yann Dubois dio en Stanford (CS229) sobre cómo se construyen los modelos de lenguaje grandes (LLM, por sus siglas en inglés). La escuché con atención y, después, preparé un documento de referencia y estudio que me ayudara a entenderla mejor - parte de mi intento continuo por seguir aprendiendo de este mundo que avanza más rápido de lo que uno puede leer. La charla se publicó en agosto de 2024 y hoy supera los 1,8 millones de visualizaciones.[1] Este artículo es, en buena medida, un resumen de lo que Dubois explica en esa conferencia, traducido a un lenguaje más accesible para quienes usamos estas herramientas sin construirlas.
Dubois empieza con una observación que conviene subrayar. Según él, hay cinco componentes que importan cuando se construye un LLM: arquitectura, algoritmo de entrenamiento, datos, evaluación y sistemas. Y añade que la academia se obsesiona con los dos primeros, mientras que la industria - la gente que realmente entrega modelos al mundo - gana con los tres últimos.
Esa inversión de prioridades cambia la historia. Lo que hace funcionar a un LLM, explica Dubois, no es un descubrimiento arquitectónico secreto; son los datos, la evaluación y los sistemas. La arquitectura Transformer lleva años siendo pública. La ventaja competitiva suele decidirse en lo demás.
Con ese marco, Dubois divide el proceso en tres fases.
1. Preentrenamiento: modelar internet
Aquí nace lo que el autor llama el “modelo base” - piensa en GPT-3 antes de que fuera ChatGPT. Se toma una red neuronal Transformer y se le enseña una sola tarea, repetida billones de veces: predecir el siguiente fragmento de texto.
Para lograrlo se procesa una cantidad absurda de datos. Dubois usa como referencia la escala de Llama 3 - más de 15 billones de tokens -, una magnitud coherente con la documentación pública posterior de Llama 3.1.[2] Una de las fuentes centrales es Common Crawl, que publica rastreos mensuales gigantes de la web.[3] Pero internet es sucio. Una página al azar de Common Crawl, dice Dubois, es casi siempre inutilizable: HTML roto, encabezados de foros repetidos mil veces, frases cortadas a la mitad.
Por eso el trabajo real del preentrenamiento, explica él, no está en la arquitectura. Está en la limpieza de datos: extraer el texto útil, filtrar contenido no deseado, eliminar duplicados, aplicar reglas para separar lo bueno de lo basura, entrenar clasificadores que distingan “probablemente útil” de “probablemente ruido”. En los equipos de frontera, una parte sustancial de la ingeniería se dedica solo a esto.
Al final de esta fase el modelo sabe continuar cualquier texto de forma coherente. Lo que todavía no sabe es comportarse como asistente. Dubois da un ejemplo que ilustra el problema: si al modelo base le preguntamos “explícale el alunizaje a un niño de seis años”, probablemente responda con otra pregunta parecida, porque en internet una pregunta suele ir seguida de más preguntas, no de respuestas.
2. Postentrenamiento: convertirlo en un asistente
Aquí se transforma ese modelo base en algo parecido a ChatGPT o Claude. Dubois lo describe en dos pasos.
Fine-tuning supervisado (SFT, del inglés Supervised Fine-Tuning). Se toma el modelo preentrenado y se le muestran ejemplos cuidadosamente construidos de instrucción y respuesta ideal. El hallazgo más contraintuitivo que menciona Dubois es que no hace falta tanta data: unos pocos miles de ejemplos muy bien escogidos pueden pesar más que una cantidad mucho mayor de ejemplos mediocres.[4] El modelo no está aprendiendo conocimiento nuevo desde cero; la mayor parte ya la trae del preentrenamiento. Lo que está aprendiendo es qué tipo de usuario de internet imitar.
Aprendizaje por refuerzo con retroalimentación humana (RLHF, del inglés Reinforcement Learning from Human Feedback). Dubois señala un problema del SFT: clona comportamientos humanos escritos. Si un humano cita una referencia que el modelo nunca vio en el preentrenamiento, el sistema puede internalizar una pauta equivocada: “cuando me preguntan esto, inventa una referencia que suene plausible”. Es decir, alucinaciones por diseño.
El RLHF le da la vuelta al asunto. En vez de clonar respuestas, el modelo genera dos respuestas candidatas, un humano (o un modelo actuando como juez) elige la preferida, y algoritmos como PPO (Proximal Policy Optimization) o DPO (Direct Preference Optimization) ajustan el modelo para que produzca más de lo que la gente prefiere. Esta fue, según Dubois, la gran diferencia entre GPT-3 y ChatGPT.
Hay una consecuencia curiosa de esto. Dubois explica que, después del RLHF, el sistema se parece menos a un modelo de lenguaje puro y más a una política optimizada para generar respuestas preferidas. Por eso la perplexity (una métrica que mide cuánta incertidumbre tiene el modelo sobre la siguiente palabra) se vuelve mucho menos informativa para evaluar asistentes como Claude.
3. Sistemas: que funcione en el mundo real
Si la computación es el cuello de botella - y Dubois insiste en que lo es -, entonces hacer que las unidades de procesamiento gráfico (GPU, por sus siglas en inglés) corran al máximo deja de ser un detalle de infraestructura y pasa a ser una ventaja competitiva. El autor destaca tres palancas de optimización.
Aritmética de baja precisión. En lugar de hacer cálculos en 32 bits, se hacen en 16. Menos bits significa menos datos moviéndose, menos memoria consumida y más velocidad. Para aprendizaje profundo (deep learning), los decimales extra no suelen importar: ya hay tanto ruido en el entrenamiento que pasar de 0.0134 a 0.013 rara vez cambia el resultado.
Fusión de operadores. Cada operación de PyTorch, por defecto, mueve datos entre la memoria general de la GPU y sus núcleos de cálculo. Dos operaciones seguidas implican dos viajes de ida y vuelta. Herramientas como torch.compile pueden fusionar operaciones y recortar ese movimiento de memoria, a menudo con mejoras perceptibles sin reescribir el modelo.[5]
Optimizaciones de inferencia. La inferencia - o, en lenguaje más llano, el momento en que usamos el modelo ya entrenado - es lo que ocurre cada vez que responde a una consulta. Cada pregunta que le hacemos a ChatGPT o Claude pasa por una ronda de inferencia. Dubois subraya algo que muchos olvidamos: en productos masivos, servir el modelo a millones de usuarios puede llegar a costar más que entrenarlo. Por eso técnicas como cuantización (usar números más pequeños al responder), caché de pares clave-valor (KV-caching, reutilizar cálculos ya hechos) y decodificación especulativa son tan importantes como las del entrenamiento. Son la razón, dice él, por la que un modelo más pequeño y bien afinado a veces vence a uno de frontera en producción.
Lo que esto significa para quienes usamos estas herramientas
Hasta aquí he resumido a Dubois. Me permito cerrar con tres observaciones que saco para mi propio uso, como alguien que emplea estas herramientas todos los días sin construirlas.
Primera: el modelo que tenemos enfrente es una destilación de internet filtrado. No es un oráculo. Refleja los sesgos y la calidad de sus datos de entrenamiento. Cuando nos da una respuesta sobre algo de nicho, hay una probabilidad real de que esté adivinando algo que suene convincente en vez de recordar hechos reales.
Segunda: el RLHF introduce una personalidad. Lo que llamamos “tono de Claude” o “estilo de ChatGPT” no es una emergencia espontánea; son preferencias de etiquetadores humanos metidas dentro del modelo. Entender esto ayuda a leer sus respuestas con más criterio - y a escribir mejores instrucciones para sacarle lo que queremos.
Tercera: el cuello de botella no es la inteligencia del modelo; es el costo de inferencia. Las empresas que ganen la próxima década no serán necesariamente las que tengan el modelo más grande; serán las que logren servirlo más barato. Esto tiene implicaciones directas sobre qué herramientas elegimos para nuestras organizaciones.
La IA nos sigue pareciendo magia. Pero cuando uno se asoma al proceso, lo que se ve es ingeniería disciplinada: datos limpios, evaluaciones rigurosas, sistemas optimizados. Eso, lejos de quitarle brillo, nos devuelve algo importante: la responsabilidad de usarla con criterio.
Fuente base
Conferencia: Stanford CS229 | Machine Learning | Building Large Language Models (LLMs)
Ponente: Yann Dubois - yanndubs.github.io
Publicada: 28 de agosto de 2024
Video de YouTube: Ver conferencia
Curso de Stanford Online: stanford.io/ai
Notas sobre cifras y fuentes
[1] Video, fecha y visualizaciones. La fuente base del artículo es la conferencia de Yann Dubois publicada en YouTube el 28 de agosto de 2024. El dato de visualizaciones corresponde a la página del video consultada el 18 de abril de 2026: YouTube.
[2] Escala de preentrenamiento de Llama. En la charla, Dubois usa Llama 3 como referencia para hablar de la escala del preentrenamiento. Como contraste público verificable, la ficha oficial de Llama 3.1 405B publicada por Meta indica que el modelo fue preentrenado con ~15 billones de tokens de datos de fuentes públicas: meta-llama/Llama-3.1-405B-Instruct.
[3] Common Crawl. En la ponencia, Dubois utiliza Common Crawl como ejemplo del volumen de datos web disponible para preentrenamiento. Para no congelar una cifra mensual que puede variar, aquí remito a dos fuentes oficiales: el panel de estadísticas de archivos mensuales de Common Crawl y la entrada del crawl de marzo de 2026, que reporta 1,97 mil millones de páginas web: estadísticas oficiales y March 2026 Crawl Archive Now Available.
[4] LIMA y el tamaño del SFT. La idea de que un conjunto pequeño pero muy bien curado puede pesar más que uno mucho mayor se apoya en LIMA: Less Is More for Alignment. El resumen del paper reporta un modelo afinado con 1.000 prompts y respuestas cuidadosamente curados, sin RLHF: arXiv.
[5] torch.compile y rendimiento. En la conferencia, Dubois lo presenta como ejemplo de mejora fuerte de rendimiento; para contexto actualizado, la documentación oficial de PyTorch explica que torch.compile acelera código con cambios mínimos, pero que el resultado depende del modelo, el hardware y la carga. La página de PyTorch 2.0 reportó 43% de mejora promedio en entrenamiento sobre 163 modelos abiertos en A100, y la guía de optimización explica la lógica de fusión de kernels: PyTorch 2.x, Introduction to torch.compile y Performance Tuning Guide.
Por: Cesar Rosa Polanco - Escrito a partir de una experiencia real, con ayuda de IA para darle forma.
