En el software tradicional, una persona escribe las reglas: if monto > 1000: revisar(). En machine learning (ML) las reglas no se escriben; se ajustan a partir de ejemplos. Ese cambio tiene consecuencias de ingeniería concretas: el comportamiento del sistema depende de los datos, de cómo se midió el error y de si alguien comprobó que funciona con casos que nunca vio.
Esta lección fija el vocabulario mínimo que usa el resto del curso: datos, , , loss, y , y una idea intuitiva de qué son una red neuronal y un . Usamos Adapta como caso de estudio porque separa de forma visible cada una de estas piezas.
Aprender a partir de ejemplos
Un modelo es una función con parámetros ajustables: y = f(x; θ). x es la entrada, y la salida y θ (theta) son los parámetros o pesos, a veces millones o miles de millones de números.
- Features (características): lo que el modelo recibe. En un clasificador de tickets, el texto del ticket.
- Label (etiqueta): la respuesta correcta que queremos que aprenda. Por ejemplo,
billing. - Dataset: muchos pares
(x, y).
Cuando cada ejemplo trae su etiqueta hablamos de aprendizaje supervisado, que es el caso de esta lección. Un se preentrena de forma parecida, pero sin etiquetas escritas a mano: la "etiqueta" de cada posición es simplemente el siguiente del texto.
Entrenamiento: loss y descenso por gradiente
Entrenar es buscar valores de θ que hagan que f(x; θ) se acerque a y en los datos. Para eso hacen falta dos cosas.
Una loss (función de pérdida): un número que mide cuán mal lo hizo el modelo. En clasificación y en modelos de lenguaje se usa la cross-entropy: si el modelo asignó probabilidad p a la respuesta correcta, la pérdida de ese ejemplo es −log p. Si p = 0.9, la pérdida es ≈ 0.105; si p = 0.1, es ≈ 2.3. Equivocarse con confianza cuesta mucho.
Un método para bajarla: el descenso por gradiente. El gradiente ∇L indica en qué dirección crece la pérdida si movemos cada parámetro; damos un paso pequeño en la dirección contraria.
repetir durante N epochs:
para cada batch de ejemplos:
L = loss(f(x; θ), y) # forward pass
g = gradiente de L en θ # backward pass
θ = θ - learning_rate * g # un paso cuesta abajo
El learning rate fija el tamaño del paso; un batch es el grupo de ejemplos que se procesa junto; una epoch es una pasada completa por el dataset. En la práctica se usan variantes como Adam o AdamW, pero la idea es la misma.
Entrenar no es servir
Hay dos fases con perfiles de costo muy distintos:
| Entrenamiento | Inferencia | |
|---|---|---|
| Qué hace | ajusta θ |
usa θ fijo para responder |
| Frecuencia | ocasional, por lotes | continua, por request |
| Hardware | GPU casi siempre | a veces basta CPU |
| Falla típica | memoria agotada, no converge | latencia, respuesta incorrecta |
La inferencia tiene su propia lección: Servir modelos.
Generalizar: splits y overfitting
Que el modelo acierte en los datos con los que entrenó no demuestra nada: podría haberlos memorizado. Lo que interesa es la generalización, es decir, que acierte con datos nuevos de la misma distribución. Por eso se separa el dataset:
- Train: con estos datos se ajustan los parámetros.
- Validation: sirven para elegir hiperparámetros y decidir cuándo parar.
- Test: se tocan una sola vez, al final, para estimar el rendimiento real.
Si usas el conjunto de test para tomar decisiones repetidas, deja de ser un test: terminas ajustando el sistema a ese conjunto.
El overfitting aparece cuando la loss de train sigue bajando mientras la de validación sube: el modelo aprende detalles del conjunto de entrenamiento que no se transfieren. El underfitting es lo contrario: el modelo ni siquiera aprende bien los datos de train.
loss
|\
| \ ___ validación
| \______/
| \
| \______ train
+------------------ epochs
^ aquí conviene parar
Las métricas y los se tratan a fondo en Evaluar modelos.
Para CTOs
La decisión que impone este tema es quién custodia los datos de evaluación. Si el mismo equipo que entrena elige, mira y reutiliza el conjunto de prueba, los resultados se inflan sin que nadie mienta. Conviene exigir:
- un held-out versionado que no se use para entrenar ni para ajustar;
- un baseline (el modelo sin cambios) medido sobre ese mismo conjunto;
- un criterio de aprobación escrito antes de entrenar, no después de ver los números.
Redes neuronales y transformers
Una red neuronal es una composición de capas. Cada capa multiplica su entrada por una matriz de pesos, suma un sesgo y aplica una función no lineal. Apiladas, estas capas pueden aproximar funciones muy complejas, y el descenso por gradiente ajusta todas las matrices a la vez.
Un transformer es la arquitectura de red detrás de los LLM actuales. Su pieza central es la atención: para cada token, el modelo calcula cuánto debe "mirar" a cada uno de los tokens anteriores y combina su información. Esto permite relacionar palabras lejanas dentro del contexto. Un LLM es un transformer entrenado para predecir el siguiente token; generar texto es repetir esa predicción una y otra vez.
Pretraining y fine-tuning
- Pretraining: entrenar un modelo desde cero sobre un corpus enorme. Requiere clústeres de GPU y que pocas organizaciones tienen. El resultado es un modelo base.
- : continuar el entrenamiento de un modelo base con un dataset pequeño y específico para cambiar su comportamiento (formato, tono, clasificación).
Casi ningún equipo de producto hace pretraining. Las opciones realistas son usar el modelo tal cual con buenos , darle conocimiento en tiempo de consulta (Embeddings y RAG) o ajustar su comportamiento con técnicas eficientes (Fine-tuning, LoRA y QLoRA).
Para llevar
- Un modelo es una función con parámetros ajustados a partir de datos; su comportamiento depende de esos datos tanto como del código.
- Entrenar es minimizar una loss con descenso por gradiente; servir es usar los parámetros ya fijos. Tienen hardware, costos y fallas distintos.
- Solo el rendimiento sobre datos no vistos dice algo sobre generalización; train, validation y test tienen funciones distintas.
- Un LLM es un transformer entrenado para predecir el siguiente token; optimiza plausibilidad, no veracidad.
- Casi nadie hace pretraining: se elige entre prompting, RAG y fine-tuning sobre un modelo base.
Comprueba lo aprendido
¿Por qué no basta con medir la loss sobre los datos de entrenamiento?
Porque un modelo puede memorizar esos ejemplos y obtener una loss baja sin generalizar. Solo la loss sobre datos que no participaron en el entrenamiento estima cómo se comportará con entradas nuevas.
Si la loss de train baja y la de validación sube, ¿qué está pasando y qué haces?
Es overfitting: el modelo aprende particularidades del conjunto de entrenamiento. Lo habitual es parar antes, conseguir más datos o más variados, o reducir la capacidad del modelo o del ajuste.
¿Qué ventaja tiene que Adapta entrene en un contenedor `worker` separado del `app`?
El entrenamiento es largo, usa la GPU y puede fallar por falta de memoria; aislarlo evita que degrade o bloquee las requests que el app está sirviendo, y permite que el servicio siga funcionando en un host sin GPU.