Capítulo 6: ¿Cómo aprende una máquina?¶

"El machine learning es el campo de estudio que da a las computadoras la capacidad de aprender sin ser programadas explícitamente." — Arthur Samuel, 1959

Objetivos del capítulo¶

Al terminar este capítulo serás capaz de:

Explicar la diferencia fundamental entre programación clásica y machine learning.
Definir qué es un modelo sin misticismo: una función con parámetros ajustables.
Distinguir los paradigmas de aprendizaje: supervisado, no supervisado, por refuerzo y auto-supervisado.
Describir e implementar el ciclo de entrenamiento completo: predicción → pérdida → gradiente → actualización.
Entrenar desde cero una regresión lineal con NumPy y ver la pérdida bajar época a época.
Diagnosticar overfitting y underfitting y saber qué hacer en cada caso.
Diferenciar parámetros de hiperparámetros y experimentar con el learning rate.
Entender la diferencia entre entrenamiento e inferencia y por qué define tu carrera como AI Engineer.
Conectar todo con los LLMs: qué significa realmente que GPT o Claude "aprendieron".

Nota

Este capítulo es el puente entre los fundamentos (Módulo 01) y el Machine Learning en serio (Módulo 02). Aquí no buscamos dominar cada técnica, sino construir el mapa mental completo sobre el que colgaremos todo lo demás. Si entiendes bien este capítulo, el resto del curso será cuesta abajo.

Índice¶

La idea central: dos formas de programar
1.1 Programación clásica: reglas + datos → respuestas
1.2 Machine learning: datos + respuestas → reglas
1.3 Ejemplo narrado: detectar spam a mano
1.4 ¿Cuándo usar ML y cuándo NO?
¿Qué es un modelo? Desmitificación total
2.1 Un modelo = una función con perillas
2.2 Analogías: la receta y el ecualizador
2.3 ¿Qué significa "un modelo de 70B de parámetros"?
Los paradigmas de aprendizaje
3.1 Aprendizaje supervisado
3.2 Aprendizaje no supervisado
3.3 Aprendizaje por refuerzo
3.4 Aprendizaje auto-supervisado: el paradigma que cambió todo
3.5 Tabla comparativa de paradigmas
El ciclo de entrenamiento paso a paso
4.1 El diagrama del ciclo
4.2 La función de pérdida: el GPS del aprendizaje
4.3 MSE calculado a mano
4.4 Implementación completa: regresión lineal con NumPy
4.5 Leyendo el entrenamiento: la pérdida época a época
Generalización: el objetivo real
5.1 Memorizar no es aprender
5.2 Overfitting y underfitting
5.3 Train / Validation / Test
5.4 La curva de aprendizaje
Hiperparámetros vs. parámetros
6.1 La diferencia clave
6.2 El learning rate: experimento en código
6.3 Otros hiperparámetros importantes
Entrenamiento vs. inferencia
7.1 Dos fases, dos mundos
7.2 Qué significa esto para tu carrera
7.3 Fine-tuning: el punto intermedio
¿Y los LLMs? Conectando todo
Caso empresarial: predecir cancelaciones de clientes
Buenas prácticas
Malas prácticas
Errores comunes
Preguntas frecuentes (FAQ)
Resumen del capítulo
Bibliografía y recursos

1. La idea central: dos formas de programar¶

1.1 Programación clásica: reglas + datos → respuestas¶

Durante 70 años, programar ha significado una cosa: un humano escribe reglas explícitas que la computadora ejecuta sobre unos datos para producir respuestas.

Qué es: el programador analiza el problema, deduce la lógica y la codifica en instrucciones (if, for, funciones...).
Para qué sirve: para problemas donde las reglas son conocibles, estables y enumerables: calcular una nómina, validar un formulario, ordenar una lista.
Por qué funciona: porque la lógica del problema cabe en la cabeza de un humano y se puede expresar sin ambigüedad.
Su limitación fatal: hay problemas donde las reglas no se pueden escribir. ¿Qué reglas exactas distinguen la foto de un gato de la de un perro? ¿Qué reglas exactas definen el sarcasmo en un tuit? Nadie las conoce. Ni siquiera tú, que reconoces gatos sin esfuerzo, puedes escribir el algoritmo que usa tu cerebro.

1.2 Machine learning: datos + respuestas → reglas¶

El machine learning invierte la ecuación. En lugar de que el humano escriba las reglas, el humano aporta ejemplos con sus respuestas correctas y un algoritmo de aprendizaje descubre las reglas (los patrones) por sí mismo.

flowchart LR
    subgraph Clasica["‍ Programación clásica"]
        direction LR
        R[Reglas escritas<br/>por humanos] --> P1[Programa]
        D1[Datos] --> P1
        P1 --> A1[Respuestas]
    end

    subgraph ML["Machine Learning"]
        direction LR
        D2[Datos] --> P2[Algoritmo de<br/>aprendizaje]
        A2[Respuestas<br/>correctas] --> P2
        P2 --> R2[Reglas aprendidas<br/>= MODELO]
    end

    Clasica -.->|"inversión del paradigma"|ML

Fíjate bien en el diagrama: en ML, la salida del proceso de entrenamiento son las reglas (materializadas en un modelo). Luego ese modelo se usa como un programa clásico: le das datos nuevos y produce respuestas. Esa segunda fase se llama inferencia y la veremos en profundidad en la sección 7.

Nota

Esta formulación ("datos + respuestas → reglas") la popularizó François Chollet, creador de Keras, en su libro Deep Learning with Python. Es probablemente la definición de ML más útil que existe en una sola frase.

1.3 Ejemplo narrado: detectar spam a mano¶

Imagina que en 2004 te contratan para filtrar spam en un servidor de correo. No existe ML accesible, así que haces lo que haría cualquier programador: escribir reglas.

# ==========================================================
# DETECTOR DE SPAM CON REGLAS ESCRITAS A MANO (enfoque clásico)
# ==========================================================

# Lista negra de palabras que "sabemos" que aparecen en spam
PALABRAS_SPAM = [
    "gratis", "oferta", "urgente", "premio", "lotería",
    "viagra", "dinero fácil", "haz clic", "100% garantizado",
    "sin compromiso", "millones", "herencia", "príncipe",
]

# Dominios de remitentes sospechosos
DOMINIOS_SOSPECHOSOS = ["ofertas-increibles.biz", "premios-ya.info"]


def es_spam(remitente: str, asunto: str, cuerpo: str) -> bool:
    """Devuelve True si el correo parece spam según nuestras reglas."""
    texto = (asunto + " " + cuerpo).lower()   # Normalizamos a minúsculas

    # Regla 1: el dominio del remitente está en la lista negra
    dominio = remitente.split("@")[-1]
    if dominio in DOMINIOS_SOSPECHOSOS:
        return True

    # Regla 2: contamos cuántas palabras prohibidas aparecen
    coincidencias = sum(1 for palabra in PALABRAS_SPAM if palabra in texto)
    if coincidencias >= 3:                    # ¿Por qué 3? Umbral arbitrario...
        return True

    # Regla 3: demasiadas mayúsculas en el asunto ("GANA DINERO YA")
    if asunto.isupper() and len(asunto) > 10:
        return True

    # Regla 4: demasiados signos de exclamación
    if cuerpo.count("!") > 5:
        return True

    return False  # Si ninguna regla salta, lo damos por legítimo


# Probamos el detector
print(es_spam("x@premios-ya.info", "GANASTE LA LOTERÍA", "Haz clic!!!"))  # True
print(es_spam("jefa@miempresa.com", "Reunión mañana", "A las 10h."))      # False

Funciona... durante dos semanas. Entonces empiezan los problemas:

Los spammers se adaptan: escriben "v1agra", "gr@tis", "L0TERÍA". Tus reglas de texto exacto quedan ciegas.
Falsos positivos: tu compañera de marketing envía "Oferta especial para clientes: descuento garantizado" y el filtro se lo come. Ahora Marketing te odia.
Explosión de mantenimiento: cada semana añades 20 reglas nuevas y ajustas umbrales. A los seis meses tienes 4.000 reglas que interactúan de formas que nadie entiende. Tocar una rompe otras tres.
Umbrales arbitrarios: ¿por qué 3 coincidencias y no 2? ¿Por qué 5 exclamaciones y no 4? Nadie lo sabe; alguien los eligió un martes por la tarde.
No escala a otros idiomas: tus reglas están en español. ¿Spam en inglés, ruso o chino? Vuelta a empezar.

El enfoque de machine learning es radicalmente distinto: recopilas 100.000 correos que usuarios reales marcaron como spam o no spam (¡las respuestas!), se los das a un algoritmo, y este descubre solo qué combinaciones de palabras, remitentes, estructuras y frecuencias delatan al spam. Cuando los spammers cambian de táctica, no reescribes reglas: reentrenas con ejemplos nuevos. Así funcionan Gmail y Outlook desde hace dos décadas: el botón "Marcar como spam" que pulsas cada día es, literalmente, etiquetado de datos para reentrenar el modelo.

Para que veas el contraste en código, así de distinto se ve el mismo problema con ML (usando scikit-learn, que dominaremos en el Módulo 02 — hoy solo léelo como pseudocódigo):

# ==========================================================
# DETECTOR DE SPAM CON MACHINE LEARNING (esbozo conceptual)
# ==========================================================
from sklearn.feature_extraction.text import CountVectorizer
from sklearn.naive_bayes import MultinomialNB

# Los DATOS: correos reales... y sus RESPUESTAS (etiquetas humanas)
correos = ["GANA DINERO YA haz clic", "Reunión mañana a las 10",
           "Oferta gratis premio lotería", "Te adjunto el informe Q3", ...]
etiquetas = [1, 0, 1, 0, ...]        # 1 = spam, 0 = legítimo

# Convertimos texto a números (Capítulo 5: representación de datos)
vectorizador = CountVectorizer()
X = vectorizador.fit_transform(correos)   # Cada correo → vector de frecuencias

# El algoritmo DESCUBRE las reglas a partir de los ejemplos
modelo = MultinomialNB()
modelo.fit(X, etiquetas)             # ← aquí ocurre TODO el aprendizaje

# Inferencia sobre un correo nuevo: ni un solo "if" escrito a mano
nuevo = vectorizador.transform(["Premio urgente: dinero gr@tis"])
print(modelo.predict(nuevo))         # → [1] (spam)

Cero listas negras, cero umbrales arbitrarios, cero reglas frágiles. Las "reglas" existen, pero viven dentro de los parámetros del modelo, aprendidas de los datos — y se actualizan reentrenando, no reprogramando. Nota también qué NO ha desaparecido: alguien tuvo que etiquetar los correos y representarlos numéricamente. En ML el esfuerzo humano no se elimina; se desplaza de escribir reglas a curar datos.

Consejo profesional

La pregunta clave para decidir entre reglas y ML es: "¿Puede un experto humano escribir las reglas de forma completa y estable?" Si sí (validar un DNI, calcular un IVA), usa reglas: son baratas, deterministas y auditables. Si no (reconocer imágenes, entender lenguaje, predecir comportamiento), necesitas ML.

1.4 ¿Cuándo usar ML y cuándo NO?¶

Criterio	Usa programación clásica	Usa machine learning
Las reglas son conocidas y estables	Sí (nómina, impuestos, validaciones)	Innecesario y contraproducente
El patrón es demasiado complejo para expresarlo	Imposible	Sí (visión, lenguaje, voz)
El entorno cambia constantemente	Mantenimiento infernal	Sí: se reentrena con datos nuevos
Necesitas explicar cada decisión al 100% (regulación estricta)	Sí	Con cuidado (interpretabilidad limitada)
Tienes pocos o ningún dato histórico	Sí	No: sin datos no hay aprendizaje
El coste de un error es catastrófico y no tolerable	Preferible	Solo con supervisión humana
Necesitas personalización a escala (millones de usuarios)	Inviable	Sí (recomendadores)

Advertencia

El error número uno de las empresas que se inician en IA es usar ML para problemas que se resuelven con tres if. El ML tiene costes ocultos enormes: datos, entrenamiento, monitorización, deriva del modelo. La solución más simple que funcione es siempre la correcta.

Ejercicio rápido 1: Clasifica estos problemas como "reglas" o "ML": (a) convertir grados Celsius a Fahrenheit, (b) detectar si una radiografía muestra neumonía, (c) calcular el descuento del 10% para mayores de 65 años, (d) predecir qué película te gustará ver esta noche.

Ver solución

- **(a) Reglas.** La fórmula es exacta y conocida: `F = C × 9/5 + 32`. Usar ML aquí sería absurdo. - **(b) ML.** Nadie puede escribir reglas píxel a píxel que definan una neumonía. Se aprende de miles de radiografías etiquetadas por radiólogos. - **(c) Reglas.** Un `if edad >= 65: precio *= 0.9`. Determinista, auditable, trivial. - **(d) ML.** Depende de patrones de gusto complejos e individuales que nadie puede enumerar; es el clásico sistema de recomendación (Netflix, YouTube).

2. ¿Qué es un modelo? Desmitificación total¶

2.1 Un modelo = una función con perillas¶

Olvida todo halo de misterio. Cuando en IA decimos "modelo", nos referimos a algo muy concreto:

Un modelo es una función matemática con parámetros ajustables. Entra un dato, sale una predicción. Los parámetros determinan cómo se transforma la entrada en la salida.

El modelo más simple del mundo es la recta que ya conoces del colegio:

y = w · x + b

x es la entrada (por ejemplo, el diámetro de una pizza en cm).
y es la salida o predicción (por ejemplo, su precio en euros).
w (weight, peso) y b (bias, sesgo) son los parámetros: los números ajustables.

Con w = 0.8 y b = 2, el modelo predice que una pizza de 30 cm cuesta 0.8 × 30 + 2 = 26 €. Con otros valores de w y b, predice otra cosa. "Entrenar" no es más que encontrar los valores de w y b que hacen que las predicciones se parezcan lo máximo posible a la realidad. Eso es todo. Todo lo demás — redes neuronales, transformers, GPT — son versiones de esta misma idea con muchísimas más perillas y funciones más retorcidas.

Qué es: una función parametrizada f(x; θ) donde θ (theta) es el conjunto de todos los parámetros.
Para qué sirve: para aproximar una relación desconocida entre entradas y salidas.
Cómo funciona por dentro: aplica operaciones matemáticas (multiplicaciones, sumas, funciones no lineales) usando los valores actuales de sus parámetros.
Ventaja: si la familia de funciones es lo bastante flexible, puede aproximar casi cualquier relación (las redes neuronales son aproximadores universales).
Limitación: un modelo solo es tan bueno como los datos con los que se ajustó; y más parámetros no siempre es mejor (lo veremos con el overfitting).

2.2 Analogías: la receta y el ecualizador¶

La receta con cantidades ajustables. Imagina una receta de bizcocho donde la estructura está fija (mezclar, hornear, enfriar) pero las cantidades son perillas: gramos de azúcar, de harina, minutos de horno, temperatura. Horneas un bizcocho, lo pruebas (¿demasiado seco? ¿poco dulce?), ajustas las cantidades y vuelves a hornear. Tras muchas iteraciones, llegas a la receta perfecta. Eso es entrenar un modelo:

La estructura de la receta = la arquitectura del modelo (la eliges tú antes de empezar).
Las cantidades = los parámetros (se ajustan probando).
Probar el bizcocho = evaluar la función de pérdida.
"Está seco, más mantequilla" = el gradiente: te dice en qué dirección ajustar cada cantidad.

El ecualizador de música. Una mesa de mezclas tiene decenas de deslizadores (graves, medios, agudos, reverb...). El sonido de entrada es el mismo; la posición de los deslizadores determina el sonido de salida. Un técnico de sonido "entrena" la mesa moviendo deslizadores hasta que el resultado suena bien. Un modelo de 70.000 millones de parámetros es una mesa de mezclas con 70.000 millones de deslizadores, ajustados no por un humano sino por un algoritmo (descenso de gradiente) que escucha el error y mueve cada deslizador una pizca en la dirección que lo reduce.

2.3 ¿Qué significa "un modelo de 70B de parámetros"?¶

Cuando lees que Llama 3 tiene 70B (70 billions = 70.000 millones) de parámetros, significa literalmente que la función tiene 70.000 millones de números ajustables almacenados en matrices gigantes.

Modelo (ejemplos)	Nº de parámetros	Equivalencia intuitiva
Nuestra regresión de pizza	2 (`w` y `b`)	Una receta con 2 cantidades
Regresión con 20 variables	21	Un ecualizador doméstico
Red neuronal pequeña (MNIST)	~100.000	La mesa de mezclas de un estudio
ResNet-50 (visión)	~25 millones	Todos los deslizadores de todos los estudios de una ciudad
GPT-2 (2019)	1.500 millones	—
Llama 3 70B (2024)	70.000 millones	~9 parámetros por cada humano del planeta
Modelos frontera (2025-2026)	Cientos de miles de millones a billones	—

Cosas importantes que se derivan de esto:

Memoria: cada parámetro es un número (típicamente 2 bytes en fp16/bf16). Un modelo de 70B ocupa ~140 GB solo en pesos. Por eso no cabe en tu portátil sin trucos (cuantización, que veremos en módulos posteriores).
Los parámetros no se programan, se aprenden: nadie escribió esos 70.000 millones de números; emergieron del entrenamiento.
Los "pesos" (weights) son los parámetros: cuando alguien dice "descargar los pesos de un modelo" (open weights), habla de descargar ese archivo gigante de números. La arquitectura sin los pesos es una receta sin cantidades: inútil.
Más parámetros = más capacidad de representar patrones complejos, pero también más coste, más datos necesarios y más riesgo de memorizar en lugar de generalizar.

Nota

En español a veces se traduce billion como "billón", pero un billion inglés son mil millones (10⁹), no un billón español (10¹²). "70B" = 70 mil millones. Este falso amigo causa errores constantes en prensa.

Anatomía de un modelo en código. Para que nada quede abstracto, esto es un "modelo" reducido a su esqueleto en Python — cualquier modelo, de la recta al transformer, encaja en esta plantilla:

class Modelo:
    def __init__(self):
        # LOS PARÁMETROS: el "estado aprendible". Aquí 2; en un LLM, 70e9.
        self.w = 0.0
        self.b = 0.0

    def predecir(self, x):
        # LA FUNCIÓN: cómo se combinan entrada y parámetros para dar salida.
        # Aquí una recta; en una red, capas de multiplicaciones y no-linealidades.
        return self.w * x + self.b

    def entrenar(self, X, y):
        # EL AJUSTE: mover los parámetros para reducir el error (sección 4).
        ...

Tres piezas, siempre las mismas: estado aprendible (parámetros), función de predicción (arquitectura) y procedimiento de ajuste (entrenamiento). Cuando en el Módulo 03 veas model.forward() y model.parameters() en PyTorch, reconocerás exactamente esta anatomía.

Y una precisión que evita confusiones futuras: arquitectura ≠ modelo entrenado. La arquitectura es la forma de la función (la plantilla de la clase de arriba); el modelo entrenado es la arquitectura más los valores concretos de sus parámetros tras el aprendizaje. Dos entrenamientos de la misma arquitectura con datos distintos producen dos modelos distintos — igual que dos panaderos con la misma receta base y ajustes diferentes producen panes diferentes.

Ejercicio rápido 2: Si un modelo tiene 8B de parámetros y cada parámetro se guarda en fp16 (2 bytes), ¿cuánta memoria ocupan sus pesos aproximadamente? ¿Cabría en una GPU de consumo con 12 GB de VRAM?

Ver solución

8.000.000.000 parámetros × 2 bytes = 16.000.000.000 bytes ≈ **16 GB**. No cabría en 12 GB de VRAM tal cual. Opciones: cuantizarlo a 8 bits (~8 GB, sí cabe) o a 4 bits (~4 GB, cabe holgadamente con espacio para la inferencia). Este cálculo mental (parámetros × bytes por parámetro) es el primer reflejo de todo AI Engineer al evaluar si un modelo cabe en su hardware.

3. Los paradigmas de aprendizaje¶

No todo aprendizaje automático funciona igual. Según qué información de supervisión tiene el algoritmo durante el entrenamiento, distinguimos grandes familias. Dominar esta taxonomía te permite, ante cualquier problema real, saber inmediatamente qué tipo de solución buscar.

3.1 Aprendizaje supervisado¶

Qué es. El paradigma más común y el que produce más valor empresarial hoy. El algoritmo aprende de ejemplos etiquetados: cada dato de entrenamiento viene con su respuesta correcta (la etiqueta o label). Es como estudiar con un solucionario: haces el ejercicio, miras la solución, corriges tu método.

Cómo funciona. Se le muestran pares (entrada, salida correcta). El modelo predice, se mide cuánto se equivocó respecto a la etiqueta, y se ajustan los parámetros para reducir ese error. Repetir millones de veces.

Las dos grandes tareas:

	Regresión	Clasificación
Qué predice	Un número continuo	Una categoría discreta
Ejemplos de salida	247.500 € · 3,7 días · 18,2 ºC	spam/no-spam · gato/perro/pájaro · cancela/no cancela
Ejemplos empresariales	Precio de una vivienda, demanda de un producto, tiempo de entrega	Fraude en transacciones, churn de clientes, diagnóstico por imagen
Métrica típica	MSE, MAE, RMSE	Accuracy, precisión, recall, F1, AUC
Pregunta que responde	"¿Cuánto?"	"¿Cuál/de qué tipo?"

Ejemplos empresariales reales:

Precio de vivienda (regresión): entradas = m², ubicación, habitaciones, año; etiqueta = precio de venta real. Idealista y Zillow lo usan para sus estimadores automáticos.
Churn / cancelación (clasificación): entradas = uso del producto, tickets de soporte, antigüedad; etiqueta = ¿canceló en los siguientes 30 días? (lo desarrollamos entero en el caso empresarial).
Fraude (clasificación): entradas = importe, hora, país, historial; etiqueta = ¿fue reportada como fraudulenta? Visa y Mastercard evalúan cada transacción en milisegundos con modelos así.

Cuándo usarlo: cuando tienes (o puedes conseguir) datos históricos con la respuesta correcta y quieres predecir esa misma respuesta para casos nuevos.

Cuándo NO usarlo: - No tienes etiquetas y conseguirlas es carísimo o imposible. - Las etiquetas históricas están sesgadas (p. ej., un modelo de contratación entrenado con decisiones humanas discriminatorias aprenderá esa discriminación). - La relación entre pasado y futuro se rompe (cambios de régimen: una pandemia invalida tu modelo de demanda de 2019).

Advertencia

La calidad del supervisado depende al 100% de la calidad de las etiquetas. "Garbage in, garbage out" no es un eslogan: es la primera ley del ML. Un dataset con 15% de etiquetas mal puestas producirá un modelo que como mucho acierta el 85% de lo aprendible.

3.2 Aprendizaje no supervisado¶

Qué es. Aquí no hay etiquetas: solo datos crudos. El algoritmo debe descubrir estructura oculta por sí mismo. Es como si te dieran 10.000 canciones sin género ni artista y te pidieran organizarlas en grupos que "tengan sentido".

Cómo funciona. El algoritmo busca regularidades: puntos que están cerca entre sí, direcciones en las que los datos varían más, densidades anómalas. No hay "respuesta correcta" contra la que corregirse; hay criterios matemáticos de estructura (compacidad de grupos, varianza explicada, densidad).

Las tres tareas estrella:

Clustering (agrupamiento): dividir los datos en grupos naturales. Algoritmo icónico: K-Means. Ejemplo: segmentación de clientes. Un e-commerce agrupa a sus clientes por comportamiento y descubre, sin decírselo nadie, que existen "cazadores de ofertas", "compradores premium recurrentes" y "compradores navideños". Marketing diseña una campaña distinta para cada segmento.
Reducción de dimensionalidad: comprimir datos de cientos de variables a 2-3 dimensiones conservando lo esencial. Algoritmos: PCA, t-SNE, UMAP. Ejemplo: visualizar en un plano 2D una tabla de clientes con 200 columnas para ver los grupos; o comprimir features antes de entrenar otro modelo.
Detección de anomalías: encontrar puntos que no encajan con el patrón general. Ejemplo: detectar servidores con métricas raras antes de que caigan, transacciones atípicas, sensores industriales que empiezan a fallar.

Cuándo usarlo: - Fase exploratoria: "¿qué estructura tienen mis datos?" - No existen etiquetas y no vale la pena crearlas. - Quieres detectar lo raro sin definir de antemano qué es raro.

Cuándo NO usarlo: - Si tienes una pregunta concreta con etiquetas disponibles, el supervisado casi siempre rendirá más. - Cuando necesitas resultados con interpretación garantizada: los clusters que encuentra K-Means son matemáticos, no de negocio; puede agrupar por algo irrelevante (p. ej., por la zona horaria del registro y no por comportamiento de compra). Validar los clusters con expertos de negocio es obligatorio. - Evaluar es difícil: sin etiquetas no hay accuracy; medir si los grupos son "buenos" es en parte subjetivo.

3.3 Aprendizaje por refuerzo¶

Qué es. Un paradigma completamente distinto: no hay dataset fijo. Un agente interactúa con un entorno, ejecuta acciones, y recibe recompensas (positivas o negativas). Su objetivo: aprender una política (estrategia de acción) que maximice la recompensa acumulada a largo plazo. Es aprender como aprende un cachorro: prueba, error, premio.

Los cuatro elementos:

Agente: el que aprende y decide (el programa).
Entorno: el mundo con el que interactúa (un juego, un robot en una fábrica, un simulador).
Acción: lo que el agente puede hacer en cada momento (mover una pieza, acelerar, girar).
Recompensa: la señal numérica que dice qué tan bien va (+1 por ganar la partida, −1 por chocar, +0.1 por avanzar).

Cómo funciona (intuición): al principio el agente actúa al azar. Cuando una secuencia de acciones acaba en recompensa, esas acciones se refuerzan (se vuelven más probables en situaciones parecidas). Cuando acaba en castigo, se debilitan. La dificultad central es la asignación de crédito: si ganas una partida de ajedrez en el movimiento 40, ¿qué movimientos de los 40 merecen el mérito? Y el dilema exploración vs. explotación: ¿repito lo que ya sé que funciona o pruebo algo nuevo que podría ser mejor?

Ejemplos reales: - Juegos: AlphaGo (venció al campeón mundial de Go en 2016 jugando millones de partidas contra sí mismo), agentes de StarCraft II y Dota 2. - Robótica: manos robóticas que aprenden a manipular objetos, robots cuadrúpedos que aprenden a caminar en terreno irregular (entrenados primero en simulación). - Optimización de sistemas: Google redujo ~40% el gasto de refrigeración de sus centros de datos con RL; gestión de carteras, control de semáforos, enfriamiento industrial.

Su papel moderno: RLHF en los LLMs. El refuerzo vive hoy su momento estelar dentro de los LLMs mediante RLHF (Reinforcement Learning from Human Feedback). Intuición en tres pasos:

El LLM base genera varias respuestas a una misma pregunta.
Humanos ordenan esas respuestas de mejor a peor (más útil, más veraz, menos dañina). Con esas comparaciones se entrena un modelo de recompensa que aprende a puntuar respuestas como lo haría un humano.
El LLM se afina con RL usando ese modelo de recompensa como "profesor": las respuestas bien puntuadas se refuerzan, las malas se penalizan.

El resultado: un modelo que no solo predice texto plausible, sino que responde de forma útil, honesta e inofensiva. RLHF (y variantes como DPO o el RL sobre razonamiento) es gran parte de la diferencia entre un modelo base "en bruto" y un asistente como Claude o ChatGPT.

Cuándo usarlo: decisiones secuenciales donde cada acción afecta al futuro, existe una recompensa medible y puedes permitirte (o simular) millones de intentos.

Cuándo NO usarlo: - No puedes simular el entorno y equivocarse en el mundo real es caro o peligroso (no entrenas un coche autónomo por prueba y error en una autopista real). - La recompensa es difícil de definir: una recompensa mal diseñada produce reward hacking — el agente encuentra trampas para maximizar el número sin lograr el objetivo (el famoso agente de carreras de barcos que giraba en círculos recogiendo turbos en vez de terminar la carrera). - Un problema supervisado disfrazado: si tienes ejemplos etiquetados de la decisión correcta, el supervisado es órdenes de magnitud más simple y estable.

3.4 Aprendizaje auto-supervisado: el paradigma que cambió todo¶

Qué es. Una idea engañosamente simple que desencadenó la era de los LLMs: generar las etiquetas automáticamente a partir de los propios datos, sin humanos etiquetando nada.

El truco con texto: toma cualquier frase de Internet y ocúltale la última palabra.

Entrada:  "El gato se subió al ___"
Etiqueta: "tejado"    ← ¡la etiqueta estaba en el propio texto!

Cada frase de cada libro, artículo y página web se convierte gratis en millones de ejercicios de "predice la siguiente palabra" con su solución incluida. De golpe, el cuello de botella del supervisado (etiquetar es caro) desaparece: todo Internet se vuelve dataset etiquetado.

Por qué cambió todo. Para predecir bien la siguiente palabra en cualquier contexto, el modelo se ve forzado a aprender gramática, hechos del mundo, razonamiento, estilos, idiomas... No porque nadie se lo pidiera, sino porque es la única forma de reducir el error de predicción a esa escala. Así se preentrenan GPT, Claude, Llama, Gemini: billones de palabras, una única tarea aparentemente tonta, capacidades emergentes asombrosas. En visión ocurre lo análogo prediciendo trozos ocultos de imágenes.

Nota

Técnicamente el auto-supervisado es supervisado en su mecánica (hay entrada y etiqueta, se usa la misma maquinaria de pérdida y gradiente); lo revolucionario es de dónde salen las etiquetas: de los datos mismos, a coste cero y escala planetaria. Profundizaremos en el Módulo 04.

3.5 Tabla comparativa de paradigmas¶

	Supervisado	No supervisado	Por refuerzo	Auto-supervisado
Señal de aprendizaje	Etiquetas humanas	Ninguna (estructura interna)	Recompensas del entorno	Etiquetas extraídas de los propios datos
Pregunta típica	"¿Qué valor/clase corresponde a X?"	"¿Qué estructura hay en estos datos?"	"¿Qué acción tomar en cada situación?"	"¿Qué parte falta en este dato?"
Datos necesarios	Pares (entrada, etiqueta)	Solo entradas	Entorno interactivo (real o simulado)	Datos crudos masivos
Coste de datos	Alto (etiquetar cuesta)	Bajo	Alto (simulación/interacción)	Bajísimo por ejemplo, volumen gigante
Ejemplos estrella	Fraude, churn, diagnóstico, precios	Segmentación, anomalías, compresión	AlphaGo, robótica, RLHF	Preentrenamiento de GPT/Claude/Llama
Evaluación	Directa (comparar con etiqueta)	Difícil, en parte subjetiva	Recompensa acumulada	Pérdida de predicción + benchmarks
Riesgo característico	Heredar sesgos de las etiquetas	Clusters sin sentido de negocio	Reward hacking	Absorber sesgos y errores de Internet
Peso en la industria hoy	Dominante en ML "clásico" empresarial	Complementario, exploratorio	Nicho + crucial en LLMs (RLHF)	La base de toda la IA generativa

Ejercicio rápido 3: Una aseguradora quiere: (a) predecir el coste esperado de los siniestros de un nuevo cliente, (b) descubrir tipologías de conductores entre sus asegurados, (c) que un sistema aprenda a ajustar precios dinámicamente maximizando beneficio a largo plazo en un mercado simulado. ¿Qué paradigma corresponde a cada una?

Ver solución

- **(a) Supervisado (regresión):** hay histórico de clientes con su coste real de siniestros (etiqueta numérica). - **(b) No supervisado (clustering):** no hay etiquetas de "tipo de conductor"; se busca estructura oculta en los datos de conducción. - **(c) Refuerzo:** decisiones secuenciales (precios) en un entorno (mercado simulado) con recompensa (beneficio acumulado). Nota la palabra clave "simulado": sin simulador, RL sería muy arriesgado aquí.

4. El ciclo de entrenamiento paso a paso¶

Llegamos al corazón del capítulo. Ya sabes qué es un modelo (función con perillas) y qué paradigmas existen. Ahora: ¿cómo se ajustan exactamente las perillas? El proceso es un bucle sorprendentemente simple que se repite desde la regresión de 2 parámetros hasta el LLM de 2 billones.

4.1 El diagrama del ciclo¶

flowchart TD
    A[1. Datos de entrenamiento<br/>pares entrada → salida correcta] --> B[2. Inicialización aleatoria<br/>los parámetros empiezan siendo ruido]
    B --> C[3. Predicción forward pass<br/>el modelo calcula ŷ con sus parámetros actuales]
    C --> D[4. Función de pérdida<br/>¿cuánto se alejan las predicciones ŷ de la realidad y?]
    D --> E[5. Gradiente backward pass<br/>¿en qué dirección mover cada parámetro para reducir la pérdida?]
    E --> F[6. Actualización de pesos<br/>parámetro ← parámetro − lr × gradiente]
    F --> G{¿Pérdida suficientemente<br/>baja o épocas agotadas?}
    G -- "No: otra época"--> C
    G -- "Sí"--> H[Modelo entrenado<br/>parámetros congelados → inferencia]

Recorramos cada paso con calma:

Datos. Sin ejemplos no hay nada que aprender. En supervisado, cada ejemplo es un par (x, y): entrada y respuesta correcta.
Inicialización aleatoria. Los parámetros arrancan con valores aleatorios pequeños. El modelo recién nacido es un generador de disparates: predice basura. Es normal y necesario (inicializar todo a cero rompe el aprendizaje en redes neuronales por simetría).
Predicción (forward pass). Pasamos las entradas por el modelo con sus parámetros actuales y obtenemos predicciones ŷ ("y sombrero" = "y estimada").
Función de pérdida (loss). Un número que resume cuánto de mal lo está haciendo el modelo. Pérdida grande = predicciones lejos de la realidad. Es la brújula de todo el proceso.
Gradiente (backward pass). Del Capítulo 3 sabes que el gradiente de la pérdida respecto a cada parámetro nos dice cómo cambia la pérdida si movemos ese parámetro un poquito. Es la flecha que apunta cuesta arriba; nosotros iremos en sentido contrario.
Actualización. Cada parámetro da un pasito en la dirección que reduce la pérdida: θ ← θ − lr · ∇θ. El tamaño del paso lo controla el learning rate (lr).
Repetir. Una pasada completa por todos los datos de entrenamiento se llama época (epoch). Se repiten decenas, cientos o miles de épocas hasta que la pérdida deja de bajar (o se agota el presupuesto).

Nota

Este bucle es universal. Cambia la arquitectura (recta → red → transformer), cambia la pérdida (MSE → entropía cruzada), cambia la escala (2 parámetros → 70B), pero el ciclo predicción→pérdida→gradiente→actualización es idéntico. Cuando en el Módulo 04 veas cómo se entrena un LLM, reconocerás exactamente este diagrama.

4.2 La función de pérdida: el GPS del aprendizaje¶

Qué es: una función que compara predicciones con valores reales y devuelve un solo número ≥ 0: cuanto más alto, peor va el modelo. Pérdida 0 = predicciones perfectas (casi nunca alcanzable ni deseable, como veremos).
Para qué sirve: convierte la pregunta vaga "¿qué tal va mi modelo?" en un número optimizable. Sin pérdida no hay gradiente; sin gradiente no hay aprendizaje.
Por qué importa elegirla bien: el modelo optimizará exactamente lo que la pérdida mida — ni más ni menos. Si tu pérdida no captura lo que le importa al negocio, tendrás un modelo excelente en lo irrelevante.
Ejemplos según tarea:

Tarea	Pérdida típica	Intuición
Regresión	MSE (error cuadrático medio)	Media de los errores al cuadrado: penaliza mucho los errores grandes
Regresión con outliers	MAE (error absoluto medio)	Media de errores absolutos: más robusta a valores extremos
Clasificación binaria	Entropía cruzada binaria	Castiga fuerte estar seguro y equivocado
Clasificación multiclase	Entropía cruzada categórica	Ídem con varias clases
LLM (siguiente token)	Entropía cruzada sobre el vocabulario	"¿Cuánta probabilidad le diste al token correcto?"

4.3 MSE calculado a mano¶

El MSE (Mean Squared Error) es la pérdida canónica de regresión:

MSE = (1/n) · Σ (yᵢ − ŷᵢ)²

En palabras: para cada ejemplo, resta la predicción del valor real, eleva al cuadrado (así los errores no se cancelan entre sí y los errores grandes pesan mucho más), y promedia.

Ejemplo numérico a mano. Nuestro modelo de pizzas con w = 0.5, b = 4 predice sobre 3 pizzas:

Pizza	Diámetro x (cm)	Precio real y (€)	Predicción ŷ = 0.5x + 4	Error (y − ŷ)	Error²
1	20	12	0.5·20 + 4 = 14	12 − 14 = −2	4
2	30	23	0.5·30 + 4 = 19	23 − 19 = +4	16
3	40	30	0.5·40 + 4 = 24	30 − 24 = +6	36

MSE = (4 + 16 + 36) / 3 = 56 / 3 ≈ 18.67

Observa tres cosas:

Los errores −2 y +4 no se cancelan gracias al cuadrado (sin él, −2+4+6 = 8 daría una imagen falsamente optimista).
El error de 6 € aporta 36 al total: 9 veces más que el error de 2 €. El MSE odia los errores grandes.
El modelo actual infravalora sistemáticamente las pizzas grandes (errores positivos crecientes): la pendiente w = 0.5 es demasiado baja. El gradiente detectará esto y empujará w hacia arriba. Eso es exactamente lo que vamos a ver en código.

4.4 Implementación completa: regresión lineal con NumPy¶

Vamos a entrenar, desde cero y sin librerías de ML, un modelo que predice el precio de una pizza según su diámetro. Solo Python + NumPy (Capítulo 4) + gradiente descendente (Capítulo 3). Este código es la semilla conceptual de todo lo que verás después.

Las derivadas que usaremos (calculadas con la regla de la cadena sobre el MSE):

∂MSE/∂w = (-2/n) · Σ xᵢ · (yᵢ − ŷᵢ)      ← cuánto culpar a la pendiente
∂MSE/∂b = (-2/n) · Σ (yᵢ − ŷᵢ)           ← cuánto culpar al sesgo

# =====================================================================
# REGRESIÓN LINEAL DESDE CERO: precio de pizza según diámetro
# El ciclo completo: predicción → pérdida → gradiente → actualización
# =====================================================================
import numpy as np

# ---------------------------------------------------------------------
# PASO 1: LOS DATOS (nuestra "experiencia" del mundo)
# ---------------------------------------------------------------------
# Diámetros de pizzas observadas (cm) — las ENTRADAS x
X = np.array([15.0, 20.0, 25.0, 30.0, 35.0, 40.0])

# Precios reales de esas pizzas (€) — las ETIQUETAS y
# Relación subyacente aproximada: precio ≈ 0.75 · diámetro + 1.5 (+ ruido real)
y = np.array([12.5, 16.0, 20.5, 24.0, 27.0, 31.5])

n = len(X)                      # Número de ejemplos de entrenamiento: 6

# ---------------------------------------------------------------------
# PASO 2: INICIALIZACIÓN ALEATORIA (el modelo nace ignorante)
# ---------------------------------------------------------------------
rng = np.random.default_rng(seed=42)  # Semilla fija => resultados reproducibles
w = rng.normal(0, 0.1)          # Pendiente inicial: número aleatorio pequeño
b = 0.0                         # Sesgo inicial: cero (aquí es seguro; en redes no)

# ---------------------------------------------------------------------
# HIPERPARÁMETROS (decisiones NUESTRAS, no del modelo — sección 6)
# ---------------------------------------------------------------------
lr = 0.001                      # Learning rate: tamaño del paso de cada ajuste
epochs = 200                    # Épocas: pasadas completas por los datos

# ---------------------------------------------------------------------
# PASO 3-6: EL BUCLE DE ENTRENAMIENTO
# ---------------------------------------------------------------------
for epoch in range(epochs):

    # --- 3. PREDICCIÓN (forward pass) ---
    # Con los parámetros ACTUALES, el modelo opina sobre cada pizza.
    # Vectorizado: NumPy calcula las 6 predicciones de una sola vez.
    y_pred = w * X + b

    # --- 4. PÉRDIDA (¿cuánto nos equivocamos?) ---
    error = y - y_pred                    # Vector de errores, uno por pizza
    mse = np.mean(error ** 2)             # MSE: promedio de errores al cuadrado

    # --- 5. GRADIENTE (¿hacia dónde ajustar cada perilla?) ---
    # Derivadas parciales del MSE respecto a w y b (regla de la cadena):
    grad_w = (-2 / n) * np.sum(X * error) # Culpa de la pendiente en el error
    grad_b = (-2 / n) * np.sum(error)     # Culpa del sesgo en el error

    # --- 6. ACTUALIZACIÓN (un pasito cuesta abajo) ---
    # Restamos porque el gradiente apunta hacia donde la pérdida CRECE
    # y nosotros queremos que DECREZCA.
    w = w - lr * grad_w
    b = b - lr * grad_b

    # --- Registro del progreso cada 25 épocas ---
    if epoch % 25 == 0 or epoch == epochs - 1:
        print(f"Época {epoch:3d} | MSE = {mse:8.3f} | w = {w:.4f} | b = {b:.4f}")

# ---------------------------------------------------------------------
# EL MODELO YA ESTÁ ENTRENADO: los parámetros quedan CONGELADOS
# ---------------------------------------------------------------------
print(f"\nModelo final: precio = {w:.3f} · diámetro + {b:.3f}")

# INFERENCIA: usar el modelo con datos que NUNCA vio
pizza_nueva = 28.0                        # Una pizza de 28 cm
prediccion = w * pizza_nueva + b          # Solo un forward pass: sin gradientes
print(f"Predicción para pizza de {pizza_nueva:.0f} cm: {prediccion:.2f} €")

Salida (aprox.):

Época   0 | MSE =  495.061 | w = 0.6216 | b = 0.0209
Época  25 | MSE =    1.616 | w = 0.7838 | b = 0.0724
Época  50 | MSE =    1.594 | w = 0.7830 | b = 0.0954
Época  75 | MSE =    1.573 | w = 0.7823 | b = 0.1183
Época 100 | MSE =    1.552 | w = 0.7815 | b = 0.1409
Época 125 | MSE =    1.532 | w = 0.7808 | b = 0.1634
Época 150 | MSE =    1.512 | w = 0.7800 | b = 0.1856
Época 175 | MSE =    1.493 | w = 0.7793 | b = 0.2077
Época 199 | MSE =    1.475 | w = 0.7786 | b = 0.2287

Modelo final: precio = 0.779 · diámetro + 0.229
Predicción para pizza de 28 cm: 22.03 €

4.5 Leyendo el entrenamiento: la pérdida época a época¶

Analicemos qué acaba de pasar, porque cada línea de esa salida cuenta una historia:

Época 0, MSE ≈ 495: el modelo recién inicializado es terrible (recuerda: parámetros aleatorios). Predice precios absurdos y la pérdida lo refleja.
Caída brutal al principio (495 → 1.6 en 25 épocas): cuando estás muy equivocado, los gradientes son grandes y cada paso corrige mucho. Es la fase de "aprendizaje rápido" — típica de todo entrenamiento sano.
Meseta con mejora lenta (1.6 → 1.47): cerca del mínimo, los gradientes se encogen y cada época aporta poco. w ya está clavado (~0.78, muy cerca del 0.75 real); b avanza despacio hacia su valor ideal (~1.5) porque su gradiente es más pequeño (el diámetro multiplica a w, amplificando su gradiente; a b no lo amplifica nada). Con más épocas o mejor lr, llegaría.
La pérdida nunca llega a 0: los datos tienen ruido (precios reales no siguen una recta perfecta). Un MSE residual es sano; perseguir el 0 absoluto es perseguir memorizar el ruido (overfitting, siguiente sección).
La inferencia final no usa gradientes: una vez congelados w y b, predecir es una multiplicación y una suma. Baratísimo. Esta asimetría (entrenar caro, inferir barato) reaparecerá a lo grande en la sección 7.

Consejo profesional

Interiorizar la forma de una curva de pérdida sana (caída rápida → meseta suave) te dará un "oído clínico" para diagnosticar entrenamientos: pérdida que explota → learning rate demasiado alto; pérdida plana desde el inicio → lr demasiado bajo o bug en los datos; pérdida que baja en train pero sube en validación → overfitting. Verás estos patrones cientos de veces en tu carrera.

Ejercicio rápido 4: En el código anterior, ¿qué pasaría si inicializáramos w = 0.75 y b = 1.5 (los valores "verdaderos")? ¿Y si cambiáramos epochs = 200 por epochs = 5?

Ver solución

- **Inicializando en los valores verdaderos:** la pérdida empezaría ya casi en su mínimo (~1.4, el ruido irreducible de los datos) y las actualizaciones serían minúsculas. El entrenamiento "no tendría casi nada que aprender". Esto ilustra por qué el *transfer learning* funciona: partir de pesos ya buenos (preentrenados) ahorra casi todo el entrenamiento. - **Con solo 5 épocas:** el modelo se quedaría a medio camino (MSE aún alto, en plena caída). Es **underfitting por entrenamiento insuficiente**: el modelo podía aprender más pero lo detuvimos antes de tiempo. El número de épocas es un hiperparámetro que hay que ajustar (sección 6).

5. Generalización: el objetivo real¶

5.1 Memorizar no es aprender¶

Aquí llega la idea más importante y menos intuitiva de todo el ML:

El objetivo de entrenar un modelo NO es que acierte en los datos de entrenamiento. Es que acierte en datos que nunca ha visto.

A esa capacidad se la llama generalización. Un modelo que clava el 100% de los ejemplos de entrenamiento pero falla con datos nuevos es inútil: los datos de entrenamiento ya tienen sus respuestas, ¡no necesitamos un modelo para ellos! El valor está siempre en lo nuevo: el cliente que llega mañana, el correo que entra esta tarde, la transacción de dentro de un minuto.

La analogía del estudiante. Dos estudiantes preparan el mismo examen con los mismos 100 problemas resueltos:

Ana memoriza las 100 soluciones, dígito a dígito. En los problemas de práctica saca un 10. En el examen, donde los problemas son parecidos pero distintos, saca un 3: no entendió los métodos, solo grabó respuestas.
Berta entiende los métodos de resolución. En la práctica saca un 8.5 (comete algún despiste). En el examen saca un 8.5 también: lo que aprendió se transfiere a problemas nuevos.

Ana es un modelo con overfitting (sobreajuste). Berta generaliza. Y nota el detalle incómodo: si solo miraras las notas de práctica, elegirías a Ana. Por eso jamás se evalúa un modelo con los datos con los que se entrenó — es como juzgar a un estudiante por un examen cuyas soluciones ya vio.

5.2 Overfitting y underfitting¶

Son los dos modos de fallo fundamentales de todo modelo:

Underfitting (subajuste): el modelo es demasiado simple para capturar el patrón real. Falla en entrenamiento y en datos nuevos. Es el estudiante que ni estudió: mal en la práctica y mal en el examen. Ejemplo: ajustar una recta a datos que forman una curva pronunciada.
Overfitting (sobreajuste): el modelo es demasiado flexible en relación con los datos disponibles, y en lugar de aprender el patrón aprende también el ruido: las peculiaridades accidentales de esos ejemplos concretos. Perfecto en entrenamiento, malo en datos nuevos. Ejemplo: un polinomio de grado 25 que pasa exactamente por los 26 puntos de entrenamiento haciendo eses absurdas entre ellos.

Visualicémoslo en ASCII con la pérdida a lo largo del entrenamiento:

 Pérdida
   │
 alta ┤\
      │ \
      │  \  ← pérdida de VALIDACIÓN (datos no vistos)
      │   \                                    ___________
      │    \                          ________/
      │     \                 _______/    ↑
      │      \_______________/            │ ¡empieza a SUBIR!
      │              ↑                    │ = OVERFITTING
      │              │ punto óptimo       │ (memoriza ruido)
      │              │ para PARAR         │
      │      ________▼____________________│______________
      │     /`----.____
      │    /           `-----.______
      │   /                         `------.____________
 baja ┤  / ← pérdida de ENTRENAMIENTO (siempre baja y baja...)
      │
      └──┬──────────┬──────────────┬────────────────────┬──→
        inicio   zona sana    punto óptimo         demasiadas
                                                      épocas

  UNDERFITTING          AJUSTE SANO           OVERFITTING
  (izquierda:           (centro: ambas        (derecha: train baja,
  ambas pérdidas        pérdidas bajas        validación sube:
  altas todavía)        y cercanas)           el modelo memoriza)

La firma inconfundible del overfitting: la pérdida de entrenamiento sigue bajando mientras la de validación empieza a subir. Las dos curvas se separan. En ese punto, cada época adicional hace al modelo mejor memorizando y peor generalizando.

Tabla de síntomas y soluciones:

	Underfitting	Overfitting
Error en entrenamiento	Alto	Muy bajo (sospechosamente bajo)
Error en validación	Alto (similar al de train)	Alto (mucho mayor que el de train)
Diagnóstico	El modelo no tiene capacidad (o tiempo) para aprender el patrón	El modelo aprendió el ruido de los datos concretos
Analogía	Estudiante que no estudió	Estudiante que memorizó el solucionario
Soluciones	Modelo más grande/complejo · más features informativas · entrenar más épocas · reducir regularización	Más datos · modelo más simple · regularización (L1/L2, dropout) · early stopping (parar al separarse las curvas) · data augmentation
Riesgo si lo ignoras	Modelo mediocre que deja valor sobre la mesa	Modelo que brilla en el laboratorio y fracasa en producción (el fallo más caro del ML)

Advertencia

El overfitting es traicionero porque se disfraza de éxito: todas tus métricas de entrenamiento son espectaculares. Miles de proyectos de ML han muerto al desplegar un modelo "con 99% de accuracy" que en producción rendía como una moneda al aire. La única vacuna: evaluar SIEMPRE con datos que el modelo jamás tocó.

5.3 Train / Validation / Test¶

Para medir generalización de forma honesta, se parte el dataset en tres bloques antes de entrenar:

Partición	% típico	Para qué se usa	¿El modelo aprende de ella?
Train (entrenamiento)	70-80%	Ajustar los parámetros (el bucle de la sección 4)	Sí
Validation (validación)	10-15%	Elegir hiperparámetros, comparar modelos, decidir cuándo parar	No aprende, pero tú decides mirándola (contamina indirectamente)
Test (prueba)	10-15%	Estimación final y única del rendimiento real	Jamás. Se toca una sola vez, al final de todo

¿Por qué tres y no dos? Sutileza clave: si pruebas 50 configuraciones de hiperparámetros y te quedas con la que mejor va en validación, has "gastado" ese conjunto — elegiste, entre 50 loterías, la que mejor suerte tuvo con esos datos concretos. La validación ya no es una estimación limpia. El test, intacto hasta el final, es tu única medida verdaderamente honesta.

En nuestro ejemplo de pizzas, con scikit-learn (Módulo 02) sería:

from sklearn.model_selection import train_test_split

# Primera partición: separamos el test (15%) y NO lo volvemos a mirar
X_temp, X_test, y_temp, y_test = train_test_split(
    X, y, test_size=0.15, random_state=42)

# Segunda partición: del resto, separamos validación (~15% del total)
X_train, X_val, y_train, y_val = train_test_split(
    X_temp, y_temp, test_size=0.18, random_state=42)

# Entrenamos SOLO con X_train; ajustamos hiperparámetros mirando X_val;
# al final de todo, UNA sola evaluación con X_test.

Advertencia (data leakage)

El pecado capital es que información del test/validación "se filtre" al entrenamiento: normalizar usando estadísticas de todo el dataset antes de partir, duplicados repartidos entre particiones, o partir aleatoriamente datos temporales (¡entrenar con datos de marzo para "predecir" febrero!). El leakage produce métricas infladas que se desploman en producción. Con datos temporales, parte SIEMPRE por fecha: pasado para entrenar, futuro para evaluar.

5.4 La curva de aprendizaje¶

Otra herramienta de diagnóstico: ¿cómo cambia el rendimiento según la cantidad de datos de entrenamiento?

 Error
   │
   │●
   │ ●          ← error de VALIDACIÓN: baja al haber más datos
   │  ●●
   │    ●●●
   │       ●●●●●
   │            ●●●●●●●●●________________  ← se acercan y
   │                    ○○○○○○○○○○¯¯¯¯¯¯¯     se aplanan juntas
   │              ○○○○○○
   │        ○○○○○
   │    ○○○○  ← error de ENTRENAMIENTO: sube un poco con más datos
   │  ○○         (más difícil "contentar" a todos los ejemplos)
   │ ○
   └─┬───────────────────────────────────────→
     pocos datos              muchos datos

Lecturas útiles:

Curvas juntas y altas → underfitting: más datos no ayudarán; necesitas un modelo mejor.
Curvas muy separadas → overfitting: conseguir más datos probablemente ayude (la brecha se cierra con volumen).
Curvas juntas, bajas y planas → has exprimido este enfoque; mejorar exige cambiar de estrategia (mejores features, otra arquitectura).

Consejo profesional

Antes de pedir presupuesto para "más datos" (caros) o "más GPU" (caras), dibuja la curva de aprendizaje con fracciones crecientes de tus datos actuales (10%, 25%, 50%, 100%). En una hora sabrás si el cuello de botella es el volumen de datos o la capacidad del modelo. Es de los análisis con mejor ratio información/esfuerzo que existen.

Ejercicio rápido 5: Tu modelo tiene 99.2% de accuracy en entrenamiento y 71% en validación. (a) ¿Overfitting o underfitting? (b) Nombra tres acciones concretas para mejorarlo. (c) ¿Sería buena idea entrenar más épocas?

Ver solución

- **(a) Overfitting de libro:** brecha enorme (28 puntos) entre train y validación. El modelo memoriza. - **(b)** Conseguir más datos de entrenamiento; simplificar el modelo (menos parámetros/profundidad); añadir regularización (L2, dropout); aplicar early stopping; revisar si hay features "tramposas" que solo funcionan en train. - **(c) No.** Más épocas agrandarían la brecha: la pérdida de train seguiría bajando y la de validación subiendo. De hecho, probablemente haya que entrenar *menos* (parar en el punto óptimo de la curva).

6. Hiperparámetros vs. parámetros¶

6.1 La diferencia clave¶

Dos familias de números gobiernan un modelo, y confundirlas es el error conceptual más común del principiante:

	Parámetros	Hiperparámetros
Qué son	Las perillas internas del modelo (`w`, `b`, los pesos)	Las decisiones de configuración del proceso de entrenamiento
Quién los ajusta	El algoritmo, automáticamente, vía gradiente	Tú (o una búsqueda automática que tú configuras)
Cuándo se fijan	Durante el entrenamiento, cambian en cada paso	Antes de entrenar; fijos durante todo el proceso
Ejemplos	Los 2 números de nuestra pizza; los 70B de Llama	Learning rate, nº de épocas, tamaño del batch, arquitectura, grado del polinomio, fuerza de regularización
Cómo se eligen los buenos	Minimizando la pérdida en train	Comparando resultados en validación
Analogía	Las cantidades de la receta	La temperatura del horno y cuántas veces pruebas la receta

Regla mnemotécnica: los parámetros los aprende la máquina; los hiperparámetros los decide el humano (por eso el "hiper": están por encima del aprendizaje).

6.2 El learning rate: experimento en código¶

El learning rate (lr) es el hiperparámetro más importante de todos: el tamaño del paso en cada actualización. Recuperemos la analogía del Capítulo 3 (bajar una montaña con niebla): el lr es la longitud de tus zancadas.

lr demasiado bajo → zancadas de hormiga: llegarás al valle... en tres años. Entrenamiento eterno, o que se queda a medias con el presupuesto de épocas dado.
lr demasiado alto → zancadas de gigante: saltas de una ladera a la opuesta, cada vez más arriba. La pérdida diverge (crece hasta infinito/NaN).
lr adecuado → convergencia rápida y estable.

Compruébalo tú mismo con nuestro modelo de pizzas:

# =====================================================================
# EXPERIMENTO: el mismo modelo, tres learning rates distintos
# =====================================================================
import numpy as np

X = np.array([15.0, 20.0, 25.0, 30.0, 35.0, 40.0])   # Diámetros (cm)
y = np.array([12.5, 16.0, 20.5, 24.0, 27.0, 31.5])   # Precios (€)
n = len(X)

def entrenar(lr, epochs=100):
    """Entrena la regresión y devuelve el historial de pérdidas."""
    w, b = 0.0, 0.0                      # Misma inicialización para comparar justo
    historial = []
    for _ in range(epochs):
        y_pred = w * X + b               # Forward: predicción
        error = y - y_pred               # Errores por ejemplo
        mse = np.mean(error ** 2)        # Pérdida actual
        historial.append(mse)
        if mse > 1e12:                   # Si diverge, paramos: ya no hay remedio
            break
        grad_w = (-2 / n) * np.sum(X * error)  # Gradiente respecto a w
        grad_b = (-2 / n) * np.sum(error)      # Gradiente respecto a b
        w -= lr * grad_w                 # Paso de actualización
        b -= lr * grad_b
    return historial

# Tres escenarios: tortuga, adecuado y kamikaze
for lr in [0.00001, 0.001, 0.01]:
    h = entrenar(lr)
    print(f"lr = {lr:8.5f} | época 0: {h[0]:12.1f} | "
          f"época 10: {h[min(10, len(h)-1)]:14.1f} | "
          f"final ({len(h)} ép.): {h[-1]:16.1f}")

Salida (aprox.):

lr =  0.00001 | época 0:        495.1 | época 10:          410.9 | final (100 ép.):            114.9
lr =  0.00100 | época 0:        495.1 | época 10:            2.9 | final (100 ép.):              1.6
lr =  0.01000 | época 0:        495.1 | época 10:   3079492526.7 | final (14 ép.): 2745623559343.6

Interpretación:

lr = 0.00001 (tortuga): tras 100 épocas la pérdida solo bajó de 495 a 115. Aprende, pero necesitaría miles de épocas. Coste computacional desperdiciado.
lr = 0.001 (adecuado): en 10 épocas ya está en 2.9. Converge rápido y estable.
lr = 0.01 (kamikaze): en la época 10 la pérdida es de miles de millones y sigue explotando: cada paso sobrepasa el valle y aterriza más arriba en la ladera contraria. Divergencia total. (Cortamos en la época 14 por piedad con los floats.)

Nota

Fíjate en lo fino que es el margen: entre "inutilizable por lento" y "explota" hay solo dos órdenes de magnitud. Por eso en la práctica el lr se busca en escala logarítmica (0.1, 0.01, 0.001, ...) y por eso existen optimizadores adaptativos como Adam que lo ajustan por parámetro sobre la marcha (Módulo 03).

6.3 Otros hiperparámetros importantes¶

Número de épocas: cuántas pasadas completas por los datos. Pocas → underfitting; demasiadas → overfitting. La práctica moderna: poner muchas y usar early stopping (parar automáticamente cuando la validación deja de mejorar).
Tamaño del batch: en datasets grandes no se calcula el gradiente con todos los datos a la vez, sino con lotes (batches) de p. ej. 32 o 64 ejemplos. Batches pequeños → actualizaciones ruidosas pero frecuentes; grandes → estables pero costosas en memoria.
Tamaño/arquitectura del modelo: cuántas capas, cuántas neuronas, grado del polinomio... Controla la capacidad y por tanto el eje underfitting↔overfitting.
Fuerza de regularización: cuánto se penaliza la complejidad del modelo para frenar el overfitting.

Consejo profesional

Ante un presupuesto limitado de experimentación, el orden de prioridad casi siempre es: (1) learning rate, (2) tamaño del modelo, (3) regularización/épocas, (4) el resto. Un lr mal puesto invalida todo lo demás; no pierdas días afinando detalles con un lr roto.

7. Entrenamiento vs. inferencia¶

7.1 Dos fases, dos mundos¶

Todo modelo vive dos vidas radicalmente distintas:

Entrenamiento: la fase de aprendizaje. Se ejecuta el ciclo completo (forward + pérdida + gradientes + actualización) millones de veces. Ocurre pocas veces (una, o periódicamente al reentrenar).
Inferencia: la fase de uso. Los parámetros están congelados; solo se ejecuta el forward pass: entra un dato, sale una predicción. Ocurre millones de veces al día, cada vez que un usuario usa el sistema.

En nuestro código de pizzas ya lo viste: 200 épocas de bucle con gradientes (entrenamiento) frente a una sola línea w * pizza_nueva + b (inferencia).

	Entrenamiento	Inferencia
Qué se computa	Forward + backward (gradientes) + actualización	Solo forward
Frecuencia	Pocas veces (proceso puntual/periódico)	Continua, millones de peticiones
Coste unitario	Enorme (GPT-4: se estima >100 M$ de cómputo)	Pequeño por petición (céntimos o menos)
Coste acumulado	Alto pero acotado	Puede superar al de entrenamiento con volumen
Hardware típico	Clústeres de miles de GPUs/TPUs (H100, B200...) interconectadas	GPUs sueltas, CPUs, móviles, chips específicos de inferencia
Requisito crítico	Throughput masivo, memoria para gradientes y estados del optimizador	Latencia baja (el usuario espera), coste por petición
Quién lo hace (LLMs)	Un puñado de laboratorios (OpenAI, Anthropic, Google, Meta...)	Todo el mundo, vía API o modelos abiertos
Analogía	Los años de carrera de Medicina	Cada consulta del médico ya formado

7.2 Qué significa esto para tu carrera¶

Aquí viene una de las ideas más orientadoras de todo el máster:

Como AI Engineer, en el 95% de tu trabajo NO entrenarás modelos desde cero. Consumirás inferencia de modelos ya entrenados.

¿Por qué?

Economía: preentrenar un LLM competitivo cuesta decenas o cientos de millones de dólares. Ninguna empresa normal lo hace; media docena de laboratorios en el mundo lo hacen por todos.
La analogía eléctrica: las empresas no construyen centrales nucleares, contratan electricidad. Con la IA pasa igual: los modelos frontera se consumen vía API (Anthropic, OpenAI, Google) o se despliegan modelos de pesos abiertos (Llama, Mistral, Qwen) en infraestructura propia.
Dónde está el valor que TÚ aportas: en todo lo que rodea a la inferencia — diseñar prompts y flujos, conectar el modelo con datos de la empresa (RAG), orquestar agentes, evaluar calidad, controlar costes y latencia, desplegar con seguridad. Eso es la AI Engineering, y es exactamente el temario de los módulos siguientes.

Esto NO significa que este capítulo sobre entrenamiento haya sido en vano. Al contrario: entender cómo se entrenó el modelo que consumes te explica por qué se comporta como se comporta — por qué alucina (fue entrenado para producir texto plausible, no verdadero), por qué tiene fecha de corte de conocimiento (sus datos de entrenamiento terminan en una fecha), por qué responde con tanta seguridad (RLHF premió la utilidad percibida), por qué el contexto que le das importa tanto. El mecánico no diseña motores, pero entiende cómo funcionan.

7.3 Fine-tuning: el punto intermedio¶

Entre "entrenar desde cero" (inasumible) y "usar tal cual" (a veces insuficiente) existe un término medio: el fine-tuning (ajuste fino).

Intuición pura (la profundidad llegará en el Módulo 04): tomas un modelo ya preentrenado — que ya "sabe" lenguaje, mundo y razonamiento — y continúas su entrenamiento brevemente con un dataset pequeño y específico de tu dominio (miles de ejemplos, no billones). Es como contratar a un médico ya formado y darle un curso de tres meses en tu especialidad, en lugar de pagarle la carrera entera. Los parámetros parten de valores excelentes (¿recuerdas el ejercicio 4, cuando inicializamos w y b en los valores verdaderos?) y solo se ajustan un poco.

Cuándo tiene sentido: vocabulario/estilo muy específicos (jerga legal, médica), tareas repetitivas de formato fijo, reducir costes destilando a un modelo pequeño.
Cuándo NO: para añadir conocimiento actualizado (para eso está el RAG, casi siempre mejor y más barato), o cuando un buen prompt resuelve el problema (empieza SIEMPRE por ahí).

8. ¿Y los LLMs? Conectando todo¶

Cerremos el círculo. Con todo lo aprendido, ya puedes entender qué es realmente un LLM sin una gota de magia:

Un LLM es una función con cientos de miles de millones de parámetros (sección 2), entrenada de forma auto-supervisada (sección 3.4) para predecir el siguiente token, usando exactamente el ciclo de entrenamiento que implementaste con NumPy (sección 4) — pérdida, gradientes, actualización — repetido billones de veces sobre billones de palabras, y luego afinada con RLHF (sección 3.3) para ser útil y segura. Cuando la usas, haces inferencia (sección 7): un forward pass con los pesos congelados, token a token.

El pipeline completo de creación de un LLM moderno:

flowchart LR
    A["PRETRAINING<br/>(auto-supervisado)<br/>Billones de tokens de texto.<br/>Tarea: predecir el siguiente token.<br/>Meses · miles de GPUs · ~10-100 M$"]
    --> B["FINE-TUNING supervisado (SFT)<br/>Decenas de miles de ejemplos<br/>de conversaciones de calidad.<br/>Aprende el FORMATO asistente"]
    --> C["RLHF / alineamiento<br/>Humanos comparan respuestas →<br/>modelo de recompensa →<br/>refuerzo: útil, honesto, inofensivo"]
    --> D["DESPLIEGUE (inferencia)<br/>Pesos congelados tras una API.<br/>Millones de usuarios ·<br/>aquí trabajas TÚ como AI Engineer"]

Correspondencia pieza a pieza con lo que ya dominas:

Concepto de este capítulo	En nuestra pizza (2 parámetros)	En un LLM (10¹¹ parámetros)
Modelo	`y = w·x + b`	Transformer (Módulo 04)
Entrada	Diámetro en cm	Secuencia de tokens (contexto)
Predicción	Un precio	Distribución de probabilidad sobre ~100k tokens posibles
Etiqueta	Precio real	El token que realmente venía a continuación en el texto
Pérdida	MSE	Entropía cruzada
Optimización	Gradiente descendente a mano	Adam sobre miles de GPUs en paralelo
Épocas	200 pasadas sobre 6 pizzas	~1 pasada sobre billones de tokens
Inferencia	`w * 28 + b`	Generar tu respuesta token a token

Nota

Este cuadro es la razón de ser del capítulo. Un LLM no "piensa" en un sentido mágico ni "busca en una base de datos": ejecuta una función entrenada. Sus virtudes (fluidez, conocimiento amplio, razonamiento aparente) y sus defectos (alucinaciones, corte de conocimiento, sensibilidad al prompt) se derivan directamente de cómo fue entrenado. La profundidad completa — atención, transformers, tokenización, embeddings — llega en el Módulo 04.

9. Caso empresarial: predecir cancelaciones de clientes¶

Caso empresarial

SubTech es una empresa SaaS con 40.000 clientes de suscripción mensual (29-299 €/mes). Cada mes, un 3.5% cancela (churn). Retener a un cliente cuesta ~10 veces menos que captar uno nuevo, así que Dirección pregunta: "¿Podemos saber QUIÉN va a cancelar ANTES de que lo haga, para intervenir a tiempo?" Acompañemos al equipo por el ciclo de vida completo del proyecto, con sus decisiones y sus tropiezos.

Fase 1 — Definir el problema (la fase que todos se saltan). La data scientist, Lucía, obliga al equipo a concretar tres cosas antes de tocar una línea de código:

Formulación ML: clasificación binaria supervisada. Entrada: datos del cliente hoy. Etiqueta: ¿canceló en los siguientes 30 días? (1/0).
Métrica de negocio, no solo de ML: con solo 3.5% de cancelaciones, un modelo tramposo que prediga "nadie cancela" acierta el 96.5%... y es totalmente inútil. Advertencia: el accuracy engaña brutalmente con clases desbalanceadas. Eligen recall (¿qué porcentaje de los que cancelan detectamos?) y precisión (de los que señalamos, ¿cuántos iban a cancelar de verdad?), equilibradas según el coste de cada error: llamar a un cliente que no iba a irse cuesta 5 €; perder uno que sí, 400 €.
Criterio de éxito accionable: "detectar al menos el 60% de las cancelaciones con precisión ≥ 40%, y que Retención pueda contactar a los señalados con 2 semanas de margen". Sin ese margen temporal, la predicción perfecta sería inútil: no daría tiempo a intervenir.

Fase 2 — Datos. El equipo construye el dataset: para cada cliente y cada mes histórico, una fila con features (logins últimos 30 días, tickets de soporte, antigüedad, plan, uso de funcionalidades clave, retrasos de pago...) y la etiqueta (¿canceló en los 30 días siguientes a esa foto?).

Primer tropiezo: la primera versión incluía la feature "fecha de baja programada"... que solo existe cuando el cliente ya pidió la baja. Accuracy del 99.8%. Lucía lo detecta al ver una feature con importancia absurdamente dominante: es data leakage de manual — el modelo "predecía" el pasado usando información del futuro. Fuera esa columna.

Segunda decisión clave: la partición train/validation/test se hace por tiempo (entrenar con 2024, validar con la primera mitad de 2025, test con la segunda), no aleatoria. El modelo se usará para predecir el futuro; debe evaluarse así.

Fase 3 — Entrenar. Empiezan con el modelo más simple posible (regresión logística — la prima clasificadora de nuestra regresión de pizzas) como baseline. Recall 48%, precisión 35%. Luego prueban un gradient boosting (Módulo 02): recall 66%, precisión 44%. La mejora justifica la complejidad extra; una red neuronal mayor no mejora nada (con datos tabulares, es habitual) y se descarta. Consejo profesional: siempre un baseline simple primero; te da un suelo de referencia, detecta problemas de datos pronto, y a veces... basta.

Fase 4 — Evaluar (más allá de la métrica global). Antes de desplegar, análisis por segmentos: ¿funciona igual para clientes nuevos que antiguos? ¿Para el plan barato y el premium? Descubren que con clientes de menos de 3 meses el modelo es casi aleatorio (poca historia = pocas señales). Deciden excluirlos del alcance y documentarlo: es mejor un modelo honesto sobre sus límites que uno que finge cobertura universal. El test final (segunda mitad de 2025, jamás tocado) confirma: recall 63%, precisión 42%. Cumple el criterio de éxito.

Fase 5 — Desplegar. El modelo se ejecuta cada lunes (inferencia batch sobre los 40.000 clientes, coste ridículo: céntimos) y genera una lista priorizada por riesgo que llega al CRM del equipo de Retención con las 3 señales principales de cada cliente ("sin logins en 21 días", "2 tickets sin resolver"). Decisión importante: el modelo no actúa solo — humanos deciden qué hacer con cada caso. Riesgo alto + acción automática mal diseñada = clientes molestos por llamadas inexplicables.

Fase 6 — Monitorizar (donde los proyectos mueren en silencio). Seis meses después, el recall real ha caído del 63% al 51%. ¿Por qué? La empresa lanzó un plan nuevo y cambió el onboarding: el comportamiento de los clientes cambió y el modelo quedó desfasado (model drift: el mundo cambia, los pesos congelados no). Solución: monitorización continua de métricas en producción + reentrenamiento trimestral con datos frescos. Además, un efecto sutil y fascinante: las intervenciones de Retención cambian las etiquetas futuras (clientes que iban a cancelar ya no lo hacen gracias al modelo), así que el propio éxito del sistema contamina sus datos de reentrenamiento. Lo gestionan manteniendo un pequeño grupo de control sin intervención.

Balance final: reducción del churn del 3.5% al 2.8% mensual ≈ 280 clientes/mes retenidos ≈ más de 1 M€/año de ingresos preservados, con un coste total del proyecto (equipo + infraestructura) de ~150 k€. Nótese dónde estuvo el trabajo duro: ~70% en datos y definición del problema, ~10% en entrenar el modelo, ~20% en despliegue y monitorización. Esa proporción es la norma, no la excepción.

Ejercicio rápido 6: En este caso, identifica: (a) el paradigma de aprendizaje, (b) el episodio de data leakage, (c) por qué el accuracy era una métrica trampa, (d) un ejemplo de model drift.

Ver solución

- **(a)** Supervisado, clasificación binaria (cancela/no cancela), con etiquetas extraídas del histórico real. - **(b)** La feature "fecha de baja programada": información que solo existe **después** del evento a predecir. Delatada por una accuracy irreal (99.8%) y una importancia de feature dominante. - **(c)** Con solo 3.5% de positivos, predecir siempre "no cancela" da 96.5% de accuracy siendo inútil. En clases desbalanceadas se usan precisión, recall, F1 o AUC. - **(d)** La caída del recall (63% → 51%) tras el cambio de planes y onboarding: los patrones que el modelo aprendió en 2024-2025 dejaron de describir el comportamiento de 2026.

10. Buenas prácticas¶

Empieza siempre por el baseline más simple. Una regla trivial o un modelo lineal te da el suelo contra el que medir todo lo demás. Si tu red neuronal no supera a la regresión logística, la complejidad no está pagando su coste.
Separa train/validation/test ANTES de mirar los datos en profundidad, y respeta el orden temporal si los datos lo tienen. El test se toca una vez, al final.
Optimiza la métrica del negocio, no la del framework. Define con los stakeholders qué error cuesta más (falso positivo vs. falso negativo) antes de entrenar.
Sospecha de los resultados demasiado buenos. Accuracy del 99% en el primer intento casi siempre significa leakage, etiquetas filtradas o un dataset trivial. Celebra después de auditar.
Registra todos los experimentos (hiperparámetros, datos usados, métricas, semillas). El "yo creo que la versión del martes iba mejor" ha quemado más horas que cualquier bug.
Grafica la pérdida de train Y validación siempre. Una sola curva no diagnostica nada; la separación entre las dos lo diagnostica casi todo.
Busca el learning rate en escala logarítmica antes de afinar cualquier otro hiperparámetro.
Planifica la monitorización desde el día uno. Un modelo desplegado sin métricas en producción es un modelo que se degradará en silencio.
Documenta los límites del modelo (segmentos donde no funciona, supuestos de los datos). El modelo honesto sobre sus límites sobrevive; el que promete todo, explota.
Pregúntate primero si necesitas ML. La mejor solución de ML es a veces tres reglas y un cron job.

11. Malas prácticas¶

Evaluar con los datos de entrenamiento y presentar ese número como rendimiento. Es la mentira estadística más común del ML.
Ajustar hiperparámetros mirando el test. Convierte tu única medida honesta en una tercera partición de validación quemada.
Normalizar/procesar con estadísticas de TODO el dataset antes de partir. Leakage sutil: la media del test se filtra al train.
Perseguir pérdida cero en entrenamiento. Es perseguir la memorización del ruido: overfitting garantizado.
Usar accuracy con clases desbalanceadas (fraude, churn, diagnóstico). El modelo "todo negativo" saca notaza siendo inútil.
Partir aleatoriamente datos temporales. Entrenar con el futuro para predecir el pasado infla todas las métricas.
Cambiar varios hiperparámetros a la vez y sacar conclusiones de qué funcionó. Un cambio por experimento.
Entrenar un modelo gigante con 200 ejemplos. Capacidad sobrada + datos escasos = memorización instantánea.
Desplegar sin grupo de control ni plan de reentrenamiento. El drift es cuestión de cuándo, no de si.
Automatizar acciones sensibles sin humano en el bucle desde el primer día. Primero asistir, luego (quizás) automatizar.

12. Errores comunes¶

Error	Síntoma	Causa	Solución
Learning rate demasiado alto	Pérdida oscila o explota a NaN	Los pasos sobrepasan el mínimo	Reducir lr ×10; probar escala logarítmica
Learning rate demasiado bajo	Pérdida baja lentísimo o parece plana	Pasos minúsculos	Aumentar lr ×10; más épocas no es la solución
Overfitting	Train excelente, validación mala y empeorando	Modelo demasiado flexible para los datos disponibles	Más datos, regularización, early stopping, modelo más simple
Underfitting	Train y validación malos por igual	Modelo demasiado simple o entrenamiento insuficiente	Modelo mayor, mejores features, más épocas
Data leakage	Métricas increíbles en desarrollo, desplome en producción	Información del futuro/etiqueta filtrada a las features	Auditar features "demasiado buenas"; partir por tiempo
Accuracy engañosa	97% de accuracy y el negocio no ve valor	Clases desbalanceadas	Usar precisión/recall/F1/AUC; matriz de confusión
No fijar semillas	Resultados distintos en cada ejecución, imposible comparar	Aleatoriedad no controlada	`seed` fijo en experimentos (y asumir varianza al reportar)
Confundir parámetros e hiperparámetros	"¿Por qué no aprende el modelo el learning rate?"	Confusión conceptual	Repasar sección 6: la máquina aprende parámetros; tú decides hiperparámetros
Olvidar escalar features	El gradiente zigzaguea, converge fatal	Features en rangos muy distintos (2 cm vs. 500.000 €)	Normalizar/estandarizar entradas (Módulo 02)
Modelo desfasado (drift)	Métricas de producción cayendo mes a mes	El mundo cambió; los pesos no	Monitorización + reentrenamiento periódico

13. Preguntas frecuentes (FAQ)¶

1. ¿"Machine learning" e "inteligencia artificial" son lo mismo? No. La IA es el campo general (sistemas que exhiben comportamiento inteligente, incluidos los de reglas). El ML es el subcampo donde ese comportamiento se aprende de datos. Y el deep learning es el sub-subcampo del ML que usa redes neuronales profundas. Todo LLM es deep learning, todo deep learning es ML, todo ML es IA; ninguna flecha va al revés.

2. ¿La máquina "entiende" lo que aprende? Filosóficamente es debate abierto; operativamente, lo que hace es ajustar parámetros para minimizar una pérdida. El modelo captura regularidades estadísticas, a veces tan profundas que su comportamiento es indistinguible de la comprensión para muchos fines prácticos. Como ingeniero, te importa el comportamiento medible: qué acierta, qué falla, y en qué condiciones.

3. ¿Cuántos datos necesito para entrenar un modelo? Depende de la complejidad del patrón y del modelo. Regla orientativa: problemas tabulares simples, de cientos a miles de ejemplos; visión/lenguaje desde cero, millones. Pero el fine-tuning y el transfer learning cambian el juego: partiendo de un modelo preentrenado, cientos de ejemplos pueden bastar. Y con LLMs vía API, a menudo necesitas cero ejemplos de entrenamiento (few-shot en el prompt).

4. ¿Por qué se inicializan los parámetros aleatoriamente y no a cero? En nuestra regresión de 2 parámetros, cero funciona. En redes neuronales, si todas las neuronas de una capa empiezan iguales, reciben gradientes idénticos y aprenden lo mismo para siempre (problema de simetría): la red equivale a una sola neurona repetida. El ruido inicial rompe la simetría y permite que cada neurona se especialice.

5. ¿Un modelo puede seguir aprendiendo después de desplegado? Por defecto no: los pesos quedan congelados y la inferencia no los toca (por eso ChatGPT no "recuerda" entre conversaciones por sus pesos). Actualizar es reentrenar/afinar y redesplegar, de forma controlada. El online learning (aprender en producción de forma continua) existe pero es delicado: un ataque o una racha de datos basura puede corromper el modelo en horas.

6. Si casi nunca entrenaré modelos, ¿por qué aprender cómo se entrenan? Porque el comportamiento de un modelo es la sombra de su entrenamiento. Sin este capítulo no puedes razonar por qué un LLM alucina, por qué el fine-tuning no le añade conocimiento fresco de forma fiable, por qué las métricas de un proveedor pueden ser engañosas, o por qué tu clasificador de producción se degradó. Es la diferencia entre un usuario de IA y un ingeniero de IA.

7. ¿Qué diferencia hay entre "época", "iteración" y "batch"? Un batch es el lote de ejemplos con el que se calcula un gradiente y se hace UNA actualización (una iteración). Una época es una pasada completa por todo el dataset. Con 10.000 ejemplos y batches de 100: una época = 100 iteraciones. En nuestro código de pizzas usamos todo el dataset como un solo batch (los 6 ejemplos), así que época e iteración coincidían.

8. ¿El descenso de gradiente encuentra siempre la mejor solución posible? No garantizado. La "superficie" de pérdida de modelos complejos tiene valles múltiples, mesetas y puntos de silla; el gradiente puede quedarse en un mínimo local. En la práctica, con redes grandes, los mínimos alcanzables suelen ser suficientemente buenos, y trucos como el momentum, Adam o los reinicios ayudan. Para nuestra regresión lineal con MSE sí hay garantía: la superficie es un cuenco perfecto (convexa) con un único mínimo.

9. ¿Qué pasa si mis datos de entrenamiento tienen sesgos? El modelo los aprenderá con entusiasmo: su único objetivo es reproducir los patrones de los datos, sean justos o no. Un histórico de contrataciones sesgado produce un modelo de contratación sesgado, con apariencia de objetividad matemática (lo que lo hace más peligroso). La auditoría de sesgos en datos y predicciones por subgrupos no es opcional en aplicaciones sensibles; lo trataremos en el módulo de ética y despliegue responsable.

10. ¿Por qué el MSE eleva los errores al cuadrado en vez de usar el valor absoluto? Tres razones: (1) evita que errores positivos y negativos se cancelen, (2) penaliza desproporcionadamente los errores grandes (a menudo deseable), y (3) es suave y derivable en todas partes, lo que hace el gradiente limpio y estable. El valor absoluto (MAE) también se usa — es más robusto frente a outliers — pero su derivada es discontinua en cero. Elegir pérdida es elegir qué errores te duelen más: una decisión de ingeniería, no un dogma.

14. Resumen del capítulo¶

La inversión fundamental: la programación clásica codifica reglas a mano (reglas + datos → respuestas); el ML las descubre a partir de ejemplos (datos + respuestas → reglas). Usa ML solo cuando las reglas no se pueden escribir.
Un modelo no es magia: es una función con parámetros ajustables — desde los 2 de nuestra pizza hasta los 70.000 millones de un LLM. Entrenar = encontrar los valores de esos parámetros que minimizan el error.
Cuatro paradigmas: supervisado (con etiquetas: regresión y clasificación, el caballo de batalla empresarial), no supervisado (estructura sin etiquetas: clustering, anomalías), por refuerzo (agente-entorno-recompensa; hoy crucial vía RLHF) y auto-supervisado (etiquetas gratis desde los propios datos: la base de los LLMs).
El ciclo universal de entrenamiento: datos → inicialización aleatoria → predicción → pérdida (MSE en regresión) → gradiente → actualización (θ ← θ − lr·∇) → repetir por épocas. Lo implementaste completo en 40 líneas de NumPy, y es el mismo ciclo que entrena a GPT.
El objetivo real es generalizar, no memorizar: por eso existen train/validation/test, por eso el overfitting (train perfecto, validación mala) es el fallo más caro del ML, y por eso jamás se evalúa con datos de entrenamiento.
Parámetros ≠ hiperparámetros: los primeros los aprende la máquina; los segundos (learning rate, épocas, tamaño) los decides tú, y el learning rate es el más crítico: muy bajo = eterno, muy alto = explosión.
Entrenar es caro y raro; inferir es barato y constante. Tu carrera como AI Engineer vivirá sobre todo en la inferencia: consumir, orquestar, evaluar y desplegar modelos ya entrenados — con el fine-tuning como término medio ocasional.
Un LLM es todo este capítulo a escala: función gigante + auto-supervisión (siguiente token) + el mismo ciclo de gradiente + RLHF + inferencia tras una API. En el Módulo 04 abriremos el capó del transformer.
En proyectos reales (como el churn de SubTech), el modelo es ~10% del trabajo: definición del problema, datos, evaluación honesta, despliegue y monitorización son el otro 90%.

15. Bibliografía y recursos¶

Libros:

Chollet, F. (2021). Deep Learning with Python (2ª ed.). Manning. — Origen de la formulación "datos + respuestas → reglas". Capítulo 1 disponible gratis: https://www.manning.com/books/deep-learning-with-python-second-edition
Géron, A. (2022). Hands-On Machine Learning with Scikit-Learn, Keras & TensorFlow (3ª ed.). O'Reilly. — La referencia práctica que acompañará todo el Módulo 02. https://www.oreilly.com/library/view/hands-on-machine-learning/9781098125967/
Burkov, A. (2019). The Hundred-Page Machine Learning Book. — Todo el ML esencial en 100 páginas, con capítulos abiertos: https://themlbook.com/
Sutton, R. & Barto, A. (2018). Reinforcement Learning: An Introduction (2ª ed.). MIT Press. — La biblia del RL, gratuita online: http://incompleteideas.net/book/the-book.html
Huyen, C. (2022). Designing Machine Learning Systems. O'Reilly. — El ciclo de vida completo en producción (el caso SubTech, sistematizado): https://www.oreilly.com/library/view/designing-machine-learning/9781098107956/

Cursos y vídeos:

Ng, A. Machine Learning Specialization (Coursera/DeepLearning.AI). — El curso introductorio de ML más influyente de la historia: https://www.coursera.org/specializations/machine-learning-introduction
3Blue1Brown. Neural Networks (serie en YouTube). — Gradiente descendente y redes con las mejores visualizaciones que existen: https://www.3blue1brown.com/topics/neural-networks
Karpathy, A. Neural Networks: Zero to Hero. — Construir redes y un GPT desde cero en código, paso a paso: https://karpathy.ai/zero-to-hero.html
Google. Machine Learning Crash Course. — Gratuito, interactivo, con ejercicios: https://developers.google.com/machine-learning/crash-course

Artículos y referencias técnicas:

Samuel, A. L. (1959). "Some Studies in Machine Learning Using the Game of Checkers". IBM Journal of R&D. — Donde nació el término "machine learning": https://ieeexplore.ieee.org/document/5392560
Ouyang, L. et al. (2022). "Training language models to follow instructions with human feedback" (InstructGPT: el paper del RLHF moderno): https://arxiv.org/abs/2203.02155
Bai, Y. et al. (2022). "Constitutional AI: Harmlessness from AI Feedback" (Anthropic): https://arxiv.org/abs/2212.08073
Documentación de NumPy (nuestro caballo de trabajo del capítulo): https://numpy.org/doc/stable/
Documentación de scikit-learn (protagonista del Módulo 02): https://scikit-learn.org/stable/
Sculley, D. et al. (2015). "Hidden Technical Debt in Machine Learning Systems" (por qué el modelo es solo el 10% del sistema): https://papers.nips.cc/paper/2015/hash/86df7dcfd896fcaf2674f757a2463eba-Abstract.html

Próximo paso: Ya tienes el mapa completo de cómo aprende una máquina. En el siguiente capítulo cerraremos los fundamentos con una panorámica del ecosistema: las herramientas, librerías, plataformas y el hardware (CPU vs. GPU vs. TPU) sobre los que se construye todo lo que acabas de aprender. Después, en el Módulo 02, dejaremos de mirar el mapa y empezaremos a caminar el territorio: Machine Learning práctico con scikit-learn.

Anterior	Módulo	Siguiente
Capítulo 5: Datos y representación	01-FUNDAMENTOS	Capítulo 7: Ecosistema, herramientas y hardware