Datos de entrenamiento: el combustible del aprendizaje

Hemos visto la arquitectura del transformer: una máquina diseñada para procesar secuencias y predecir el siguiente token. Pero una máquina, por sí sola, no sabe nada. Necesita aprender a partir de ejemplos. Y para aprender, necesita datos. Muchos datos.

En este capítulo veremos cómo se construye el conjunto de datos que alimenta a un modelo de lenguaje: de dónde viene el texto, cómo se limpia, cómo se prepara para el entrenamiento, y cuánto se necesita realmente. Como dice el viejo adagio en IA: “los datos son el combustible; el modelo es el motor”. Un motor potente con combustible sucio no va a funcionar bien.

La escala real: ¿cuánto texto necesita un modelo?

La respuesta corta es: mucho. Mucho más de lo que cualquier humano podría leer en varias vidas.

Para un modelo pequeño (digamos, 100 millones de parámetros, similar a GPT-2 pequeño), se necesitan cientos de millones de tokens (unas cuantas decenas de gigabytes de texto). Para un modelo grande (como GPT-3, con 175 mil millones de parámetros), se necesitan cientos de miles de millones de tokens — varios terabytes de texto.

¿De dónde sale todo ese texto? Las fuentes típicas incluyen:

• Rastreos web: Common Crawl es la columna vertebral de casi todos los modelos — una organización que ha estado descargando y almacenando páginas web mensualmente desde 2008. Masivo, pero también muy ruidoso (spam, código HTML, textos duplicados).
• Wikipedia: unos 6 millones de artículos en inglés, bien estructurados, con lenguaje relativamente formal. Pequeña comparada con Common Crawl, pero de alta calidad.
• Libros digitalizados: Project Gutenberg, Google Books, y otros — texto narrativo y expositivo de calidad.
• Papers académicos: arXiv, PubMed, etc. — texto científico y técnico.
• Código fuente: GitHub y otros repositorios — esencial para modelos que generan código.
• Noticias, foros, redes sociales: Reddit, Hacker News, etc. — lenguaje conversacional y actual.

La mezcla importa: la proporción de cada fuente influye en el comportamiento del modelo. Un modelo entrenado con demasiados foros puede volverse coloquial y poco formal; uno con demasiada Wikipedia puede ser rígido y enciclopédico. El equipo de The Pile (EleutherAI) publicó documentación abierta detallando exactamente qué fuentes mezclaron y por qué — un buen ejemplo de transparencia poco común en este espacio.

¿Cuánto es suficiente? La regla Chinchilla

Durante los primeros años de los transformers, la tendencia era clara: modelos cada vez más grandes, entrenados con conjuntos de datos que no crecían al mismo ritmo. Se pensaba que el tamaño del modelo era el factor más importante para el rendimiento.

Pero en 2022, investigadores de DeepMind publicaron “Training Compute-Optimal Large Language Models” (el paper de Chinchilla), que cambió esta visión. Entrenaron más de 400 modelos de distintos tamaños y volúmenes de datos, y encontraron una relación empírica: por cada parámetro del modelo, se necesitan aproximadamente 20 tokens de entrenamiento para el uso óptimo de un presupuesto fijo de cómputo.

La gran lección: no es óptimo tener un modelo gigante entrenado con pocos datos — es mejor tener un modelo más pequeño entrenado con más datos. De hecho, Chinchilla (70B parámetros, entrenado con 1.4 billones de tokens) superó a GPT-3 (175B parámetros, entrenado con solo ~300 mil millones de tokens) en la mayoría de benchmarks, a pesar de tener menos de la mitad de parámetros — porque GPT-3 estaba, en retrospectiva, significativamente sub-entrenado para su tamaño.

Aplicado a nuestro modelo pequeño: 8 bloques, ancho 256 ≈ 9 millones de parámetros → la regla de 20 tokens pide ~180 millones de tokens. El entrenamiento por defecto usa 20,000 pasos × 32 ventanas de 512 tokens ≈ 330 millones de tokens, o ~37 por parámetro — casi el doble de la recomendación de Chinchilla. Entrenar más allá del punto Chinchilla está bien: esa cifra describe el mejor uso de un presupuesto fijo; un modelo pequeño sigue mejorando más allá de ese punto, solo que más lentamente.

Calculadora y gráfica: ¿dónde caen los modelos reales respecto a Chinchilla?

La línea es tokens = 20 × parámetros. Los puntos no se inventan: GPT-3, Chinchilla y Llama 3 70B usan cifras publicadas; el punto pequeño es el ejemplo de este capítulo. Es aritmética, no entrenamiento.

Nota importante que la gráfica va a revelar: no todos los modelos reales siguen la regla al pie de la letra, y por buenas razones. La regla de Chinchilla optimiza el costo de entrenamiento — pero si vas a servir el modelo a millones de usuarios, el costo de inferencia también importa, y ahí a veces conviene entrenar de más.

El caso de Llama 3: Meta entrenó su modelo de 70B parámetros con 15 billones de tokens — casi 11 veces más que el punto Chinchilla-óptimo para ese tamaño (1.4T). Según el propio blog de Meta, el rendimiento del modelo siguió mejorando de forma log-lineal incluso mucho más allá del punto que Chinchilla marcaría como “óptimo”. La razón: un modelo más pequeño, entrenado por más tiempo, resulta más eficiente y barato de servir después — un costo de entrenamiento más alto una sola vez, a cambio de un costo de inferencia menor multiplicado por cada consulta futura. Esta es exactamente la tensión que ya vimos en el trilema de la inferencia de Parte III: no existe una configuración que optimice entrenamiento e inferencia a la vez — hay que elegir conscientemente cuál priorizar según el caso de uso.

Limpiando los datos

Un dataset “prolijo” suele tener etiquetas HTML, codificaciones rotas, párrafos repetidos, menús de navegación, y texto sin sentido. Limpiar (data curation) involucra:

• Extraer el texto limpio: eliminar etiquetas HTML y quedarse solo con el contenido textual.
• Normalizar: unificar codificaciones, manejar espacios, convertir comillas curvas a rectas.
• Filtrar por calidad: eliminar páginas con muy poco texto, alta proporción de caracteres repetidos, o lenguaje ofensivo.
• Eliminar duplicados: a nivel de documento y también de párrafo.

Ejemplo de limpieza:

Antes:

<story>
  <p>El gato pequeño encontró una pelota roja.</p>
  <p>COMPRA YA COMPRA YA COMPRA YA</p>
  <p>El gato pequeño encontró una pelota roja.</p>
</story>

Después:

El gato pequeño encontró una pelota roja.

Se eliminó el marcado HTML, el spam, y el párrafo duplicado. En un proceso de limpieza típico, se retiene aproximadamente el 60% de los bytes originales — el 40% restante es basura que no aporta nada, y que incluso podría perjudicar el aprendizaje.

Deduplicación: calidad venciendo a cantidad

Si el modelo ve la misma frase cientos de veces, memoriza esa frase específica en vez de aprender un patrón general — y durante la generación, tenderá a repetirla (el famoso “parroteo”). El paper “Deduplicating Training Data Makes Language Models Better” (2022) demostró que eliminar duplicados mejora el modelo con menos datos — entrenar con 100GB de datos únicos supera a entrenar con 200GB donde la mitad está duplicada.

La deduplicación ocurre a varios niveles: a nivel de documento (la misma página en varias URLs), a nivel de párrafo o línea, y a veces a nivel de n-grama (fragmentos demasiado comunes). Un método frecuente usa hashing aproximado (como MinHash) para encontrar duplicados que no son idénticos byte por byte, pero sí muy similares.

La mezcla de datos: el arte del equilibrio

No todos los textos son iguales. Un modelo entrenado exclusivamente con libros generaría texto formal y académico; uno entrenado con Reddit sería coloquial y lleno de jerga. El truco está en la mezcla (data mix): seleccionar proporciones de cada dominio para que el modelo sea versátil.

Ejemplo ilustrativo de una mezcla típica:

Esta mezcla no es fija — cada equipo la ajusta según sus objetivos (un modelo especializado en código, como CodeLlama, usa una proporción mucho mayor de código fuente). Un detalle importante: la mezcla se aplica durante el muestreo de los datos, no simplemente concatenando archivos — si un dominio es más pequeño (como Wikipedia), se le da más peso en el muestreo para que el modelo vea suficientes ejemplos de él.

De texto limpio a archivos de entrenamiento

El paso final convierte texto en identificadores de token, separados en conjunto de entrenamiento y validación. Las actualizaciones de pesos usan solo el lado de entrenamiento; la validación se reserva para verificar generalización a texto nunca visto.

data = codificar_documentos_a_array(tokenizador, documentos, dtype=np.uint16)
n_val = max(1, min(int(len(data) * 0.1), 2_000_000))
train_ids, val_ids = data[:-n_val], data[-n_val:]

np.save("cache-tokens/train.npy", train_ids)
np.save("cache-tokens/val.npy", val_ids)

train = np.load("cache-tokens/train.npy", mmap_mode="r")
i = np.random.randint(len(train) - block_size - 1)
x = train[i : i + block_size]              # el contexto
y = train[i + 1 : i + 1 + block_size]      # desplazado por uno = los objetivos

El truco central: desplazar por uno. En cada posición, el siguiente token es la respuesta correcta. Sin etiquetado humano, convertimos texto en millones de problemas de predicción auto-etiquetados — esto es aprendizaje auto-supervisado a escala masiva: el texto mismo contiene las respuestas.

Validación: ¿cómo saber si el modelo está aprendiendo?

Apartamos un pequeño porcentaje de los datos (5-10%) como conjunto de validación, que nunca se usa para actualizar pesos — solo se evalúa periódicamente para medir rendimiento sobre datos que el modelo no ha visto. Si el loss de entrenamiento sigue bajando pero el de validación empieza a subir, el modelo está sobreajustando: memorizó los datos de entrenamiento en vez de aprender patrones generales.

El límite práctico de 2 millones de tokens en el código de arriba existe porque no hace falta una validación gigante — una muestra representativa es suficiente para detectar sobreajuste.

El equilibrio final: modelo, datos, y cómputo

Entrenar un modelo implica decidir cómo invertir un presupuesto limitado entre tamaño del modelo (más grande = más capacidad, pero más lento y costoso), tamaño del dataset (más datos = más ejemplos, pero más costoso de procesar), y duración del entrenamiento (más pasos = mejor ajuste, con rendimientos decrecientes).

La regla de Chinchilla dice: con presupuesto fijo, ~20 tokens por parámetro es lo óptimo — pero eso es óptimo solo para el costo de entrenamiento. Si el modelo va a desplegarse a escala (y el costo de inferencia importa), puede ser mejor entrenar con muchos más datos aunque el modelo sea más pequeño:

Fíjate en la comparación entre las dos filas de 70B parámetros: mismo tamaño de modelo, pero Llama 3 pagó un costo de entrenamiento mucho mayor a cambio de un modelo notablemente más barato y eficiente de servir después — una decisión consciente, no un error de cálculo.

Resumen del capítulo

El entrenamiento de un modelo de lenguaje pasa por varias fases:

• Adquisición: recolectar texto de múltiples fuentes (web, libros, código, etc.).
• Limpieza: eliminar HTML, spam, duplicados, y texto sin sentido.
• Mezcla: equilibrar proporciones de cada dominio para lograr versatilidad.
• Tokenización: convertir el texto limpio en arrays de IDs.
• División: separar en entrenamiento (~90-95%) y validación (~5-10%).
• Auto-supervisión: crear pares (entrada, salida) desplazando la secuencia una posición.

Los datos de entrenamiento son el factor más determinante del comportamiento final del modelo — una arquitectura excelente con datos mediocres produce un modelo mediocre; una arquitectura modesta con datos excelentes produce un modelo sorprendentemente bueno.

En el próximo capítulo veremos cómo aprenden realmente los modelos: el algoritmo de descenso de gradiente, la función de pérdida (cross-entropy), y la retropropagación que convierte datos en pesos útiles.

Si alguna vez trabajas preparando datos para un modelo propio, ten presente la proporción real del esfuerzo: la mayor parte del tiempo se va en limpiar y curar los datos, no en diseñar la arquitectura. Es casi un cliché en machine learning, pero es verdad — los datos son el corazón del aprendizaje; sin ellos, el modelo es solo una carcasa vacía.