Primera parte

• El flujo de trabajo de ML
• Calidad de datos y preprocesamiento
• Feature engineering
• División train/test y validación cruzada

Segunda parte

• Sobreajuste y sesgo-varianza
• Métricas de evaluación
• Selección de modelos
• Reproducibilidad en ML

Recolección de datos

• Encuestas, registros administrativos, sensores, APIs, web scraping, etc
• La calidad de los datos determina la calidad del modelo
• “Basura entra, basura sale” (garbage in, garbage out)

Preprocesamiento

• Valores faltantes: imputar, eliminar o marcar
• Convertir variables categóricas a numéricas con one-hot encoding o label encoding
• Escalar variables numéricas (normalizar)
• Detectar outliers y decidir qué hacer con ellos
• Feature engineering, crear nuevas variables a partir de las existentes

Problemas comunes en datos reales:

• Valores faltantes, ¿aleatorios o sistemáticos?
  • MCAR: completamente al azar
  • MAR: dependen de otras variables observadas
  • MNAR: dependen de la variable misma (más difícil)
• Errores de medición: datos mal cargados o unidades inconsistentes
• Duplicados que sesgan el modelo
• Desbalance de clases (mucho más de una categoría que de otra)
• Data leakage: información del futuro que se filtra al entrenamiento

• Feature engineering, crear nuevas variables a partir de las existentes
• Puede mejorar mucho el rendimiento de un modelo simple
• Ejemplos comunes:
  • Transformaciones: log(ingreso), raíz cuadrada, bins
  • Interacciones entre variables (edad × educación)
  • Agregaciones, como el promedio de compras de los últimos 3 meses
  • Variables temporales: día de la semana, mes, año
  • Variables de texto (largo, cantidad de palabras)
• El conocimiento del dominio es clave: ¿qué variables tienen sentido para el problema?

• Queremos saber si el modelo funciona con datos nuevos, no solo con los datos que ya vio
• Si evaluamos el modelo con los mismos datos que usamos para entrenarlo, no sabemos si realmente aprendió
• Por eso dividimos:
  • Entrenamiento (~70-80%): el modelo aprende de estos datos
  • Prueba (~20-30%): evaluamos el rendimiento con datos que el modelo nunca vio
• Regla de oro: nunca mirar los datos de prueba hasta el final

• La forma más simple de evaluar un modelo
• Dividimos los datos aleatoriamente en dos conjuntos
• El modelo solo ve los datos de entrenamiento durante el ajuste
• Evaluamos con los datos de prueba al final
• Problemas potenciales:
  • Con pocos datos, una sola división puede no ser representativa
  • El resultado depende de qué observaciones cayeron en cada conjunto
• Para datasets pequeños, necesitamos algo más: validación cruzada

• Dividimos los datos en K partes (folds) de tamaño similar
• Entrenamos K veces, cada vez usando K-1 folds para entrenamiento y 1 fold para validación
• Repetimos K veces, rotando el fold de validación
• Promediamos los resultados de las K iteraciones
• Cada observación es usada para validación exactamente una vez
• Más confiable que una sola división, especialmente con pocos datos
• K = 5 o K = 10 son los valores más comunes

• Pregunta frecuente sin respuesta universal
• Depende de varios factores:
  • Complejidad del problema: número de variables y tipo de relaciones
  • Cantidad de ruido en los datos (con datos limpios bastan menos)
  • Complejidad del modelo, ya que los más complejos piden más datos
  • Número de clases: más clases = más datos por clase
• Reglas prácticas (muy aproximadas):
  • Para clasificación, al menos 50-100 por clase minoritaria
  • Deep learning: miles o millones de ejemplos

• Sobreajuste (overfitting): el modelo funciona muy bien con los datos de entrenamiento pero mal con datos nuevos
• El modelo ha memorizado el conjunto de entrenamiento, incluyendo su ruido y particularidades
• No ha aprendido los patrones subyacentes
• Señales de sobreajuste:
  • Rendimiento excelente en entrenamiento
  • Rendimiento pobre en test
  • La brecha crece con la complejidad del modelo
• Piénsenlo así: memorizar las respuestas del examen vs. entender la materia
• El estudiante que memoriza fracasa cuando las preguntas se reformulan

Subajuste

• Modelo demasiado simple
• Alto sesgo, baja varianza
• Malo en entrenamiento Y en test
• No captó el patrón
• Solución: modelo más complejo

Buen ajuste

• Complejidad adecuada
• Sesgo y varianza equilibrados
• Bueno en ambos conjuntos
• Captura el patrón verdadero
• Esto es lo que buscamos

Sobreajuste

• Modelo demasiado complejo
• Bajo sesgo, alta varianza
• Excelente en entrenamiento, malo en test
• Memorizó el ruido
• Solución: regularización

• El sesgo (bias) es el error por suposiciones simplificadoras: un modelo con alto sesgo “no presta atención” a los datos
• La varianza, en cambio, es el error por sensibilidad excesiva al entrenamiento: cambia mucho con cada muestra
• No se pueden minimizar ambos al mismo tiempo, ya que al reducir uno el otro tiende a aumentar
• El objetivo es encontrar el punto medio donde el error total es mínimo
• En la práctica:
  • Los modelos simples (regresión lineal) tienden a alto sesgo y baja varianza
  • Los modelos complejos (redes neuronales profundas) muestran bajo sesgo y alta varianza
  • La regularización controla la varianza sin aumentar mucho el sesgo (la veremos en detalle en el Día 2, con regresión)

• Una tabla que muestra todos los resultados posibles de las predicciones
• Cuatro cantidades clave:
  • Verdaderos Positivos (VP): correctamente predicho como positivo
  • Verdaderos Negativos (VN): correctamente predicho como negativo
  • Falsos Positivos (FP): predicho como positivo, pero era negativo (Error Tipo I)
  • Falsos Negativos (FN): predicho como negativo, pero era positivo (Error Tipo II)
• Todas las métricas de clasificación se derivan de estos cuatro números

Precisión = VP / (VP + FP)

• De todo lo que el modelo marcó como “sí”, ¿qué parte era “sí” de verdad?
• Mide la confianza en la alarma: alta precisión, pocas falsas alarmas
• Importa cuando un falso positivo cuesta caro (spam, moderación de contenido)

Recall = VP / (VP + FN)

• De todo lo que era “sí” de verdad, ¿qué parte encontró el modelo?
• Mide la cobertura: alto recall, no se nos escapa casi nada
• Importa cuando un falso negativo cuesta caro (enfermedades, seguridad)

¿Qué modelo usar?

• No existe un modelo “mejor” para todos los problemas
• Depende de:
  • Cantidad de datos disponibles
  • Interpretabilidad requerida
  • Tiempo de entrenamiento aceptable
  • Tipo de relaciones en los datos

Principio de parsimonia:

• Empezar con modelos simples (regresión, árboles)
• Aumentar complejidad solo si es necesario
• Un modelo simple que funciona bien es mejor que uno complejo que funciona igual

En R:

• renv para gestionar dependencias y versiones de paquetes
• targets: pipelines reproducibles
• Quarto, código y documentación juntos
• Git para control de versiones

En general:

• Docker: contenedores con ambiente completo
• MLflow para tracking de experimentos
• DVC, versionado de datos

• tidymodels es un conjunto de paquetes de R para modelado de datos
• Sigue la filosofía del tidyverse: código legible, consistente y modular
• Paquetes principales:
  • rsample divide los datos (train/test, validación cruzada)
  • parsnip para especificar modelos con una interfaz unificada
  • yardstick: métricas de evaluación
  • workflows combina preprocesamiento y modelo
  • recipes para preprocesar los datos
• Ventaja: misma sintaxis para todos los modelos, ya sea regresión logística, random forest o redes neuronales

• initial_split() separa los datos en entrenamiento y prueba. Con prop = 0.75 dejamos 75% para entrenar
• strata = mantiene la misma proporción de clases en ambos conjuntos, algo importante cuando una categoría es poco frecuente
• training() y testing() extraen cada parte del objeto que devuelve initial_split()
• vfold_cv() arma los K folds de validación cruzada, siempre a partir del conjunto de entrenamiento
• set.seed() antes de dividir: sin eso, cada ejecución da una división distinta y los resultados no son reproducibles

Todo modelo se define con tres verbos:

• El tipo de modelo: logistic_reg(), decision_tree(), rand_forest(), linear_reg(), etc.
• set_engine(): qué paquete de R hace el cálculo por detrás (glm, rpart, ranger)
• set_mode(): "classification" o "regression"

Después:

• fit() ajusta el modelo con los datos de entrenamiento
• La fórmula y ~ . significa “predecir y con todas las demás variables”
• La ventaja: cambiar de modelo es cambiar dos líneas, no reescribir el análisis

# Regresión logística
modelo_log <- logistic_reg() |>
  set_engine("glm") |>
  set_mode("classification")

# Árbol de decisión: mismo patrón,
# solo cambian el tipo y el motor
modelo_arbol <- decision_tree() |>
  set_engine("rpart") |>
  set_mode("classification")

# Ajustar con los datos de entrenamiento
ajuste <- modelo_log |>
  fit(crecimiento_alto ~ .,
      data = datos_train)

Especificar el modelo y ajustarlo son pasos separados: podemos definir varios modelos y recién después decidir cuáles ajustar. La lista de modelos está en https://www.tidymodels.org/find/parsnip/

• augment() agrega las predicciones (clase y probabilidades) al conjunto de prueba en una sola línea
• conf_mat() arma la matriz de confusión que vimos antes
• metric_set() junta varias métricas. En los labs usamos precision, recall y roc_auc en lugar de accuracy
• roc_auc es el área bajo la curva ROC: mide qué tan bien separa el modelo las dos clases (0,5 = azar, 1 = perfecto)
• event_level = "second" le indica cuál es la clase positiva, porque R ordena los niveles alfabéticamente y deja "si" en segundo lugar
• Para la versión con validación cruzada: fit_resamples() entrena sobre los folds y collect_metrics() promedia los resultados

# Predicciones sobre el test set
pred_test <- ajuste |> augment(datos_test)

conf_mat(pred_test,
         truth    = crecimiento_alto,
         estimate = .pred_class)

# La misma evaluación, pero con
# validación cruzada sobre los folds
fit_resamples(modelo_log,
  crecimiento_alto ~ .,
  resamples = folds,
  metrics = metric_set(precision, recall, roc_auc),
  control = control_resamples(
    event_level = "second")
) |>
  collect_metrics()

Hoy pasamos la fórmula directamente a fit(). Mañana la vamos a reemplazar por recipe() + workflow(), pero el esqueleto sigue siendo este

Conceptos fundamentales:

• El flujo de trabajo de ML tiene 5 pasos: recoger, preprocesar, dividir, entrenar, evaluar
• La calidad de los datos determina la calidad del modelo
• El feature engineering puede mejorar mucho un modelo simple
• Dividimos los datos en entrenamiento y prueba para evaluar generalización
• La validación cruzada es más confiable que una sola división

Problemas y soluciones:

• El sobreajuste ocurre cuando el modelo memoriza en lugar de aprender
• La accuracy no es suficiente: necesitamos precisión y recall
• La reproducibilidad es necesaria para verificar y colaborar