Unidad 4 - Fundamentos de Machine Learning

Introducción al Business Analytics · Semana 10 · 06278-ECO

Autor/a

PhD. Eduard F. Martínez-González

1 Cómo estudiar esta semana

Este documento es la versión escrita del podcast de la semana — y esta vez viene con dos videos

  1. 🎧 Escucha el episodio — el enlace está en Intu.
  2. 🎬 Mira los dos videos de métricas que están embebidos más abajo: cómo se construye la matriz de confusión y cómo se calculan MAE y RMSE. No son opcionales: son la mitad del material de esta semana y la herramienta central de la clase.
  3. 📖 Lee este documento — organiza los conceptos, resume los videos y trae tres herramientas interactivas para ponerte a prueba.
  4. Presenta el quiz en Intu antes de la clase (cubre el podcast y los videos).

El plan del episodio: hasta la semana 6 usaste los datos para describir el pasado: KPIs, tablas, gráficos. Esta semana el curso cambia de pregunta: ya no ¿qué pasó? sino ¿qué va a pasar? Veremos qué significa que una máquina “aprenda”, por qué la única prueba que cuenta es con datos que el modelo nunca vio, cómo saber si un modelo de verdad aporta (el baseline), y las trampas que hacen que un modelo se vea brillante en el computador y fracase en el mundo real: el sobreajuste y el data leakage. Al final, los dos videos te dan el instrumento de medición: las métricas. En clase las usarás para juzgar modelos ya entrenados — y en las semanas 11 y 12 construirás los tuyos.

2 Glosario de la semana

Los términos que vas a escuchar en el episodio y en los videos. Vuelve aquí cada vez que uno se te escape.

Machine Learning 🧠 Enseñarle a un programa a partir de ejemplos (filas de datos), no de reglas escritas a mano. El objetivo no es repetir lo que vio: es generalizar — acertar en casos nuevos.

Target (variable objetivo) 🎯 Lo que quieres predecir. Si es una categoría (“Aprobado”/“Rechazado”) el problema es de clasificación; si es un número (la nota final, el precio) es de regresión.

Features (predictoras) 🧩 Las variables con las que el modelo intenta adivinar el target: ingreso, edad, historial… Elegirlas bien es más importante que el algoritmo de moda.

Train / Test 📚 La partición sagrada: con el ~80% el modelo estudia (train) y con el ~20% restante presenta el examen (test). El test se toca una sola vez, al final.

Baseline 📏 El modelo más tonto posible: predecir siempre la clase mayoritaria o siempre el promedio. Es la vara mínima — si tu modelo no le gana, no aporta nada.

Sobreajuste y subajuste 🎭 Sobreajuste: memorizar el ruido de train y fallar en test. Subajuste: un modelo tan simple que falla hasta en train. La firma del sobreajuste es la brecha entre ambos errores.

Validación cruzada 🔄 En vez de un solo examen, k exámenes rotando qué parte de los datos se reserva. Sirve para comparar modelos y elegir hiperparámetros sin gastar el test.

Data leakage 🚰 Información del test — o del futuro — que se “fuga” al entrenamiento. El modelo se ve genial en el examen… porque vio las respuestas. La métrica queda inflada y la decisión, contaminada.

Matriz de confusión 🧮 La tabla 2×2 que resume un clasificador: qué predijo el modelo contra qué ocurrió de verdad. De ella salen accuracy, precisión y recall. La construyes en el video 1.

MAE y RMSE 📐 Las métricas de regresión: cuánto se equivoca el modelo, en promedio, en las unidades del target. El RMSE castiga más los errores grandes. Los calculas en el video 2.

3 El estudiante que se sabía el parcial de memoria

El episodio arranca con dos estudiantes preparando el mismo parcial.

El primero consiguió los parciales de los últimos cinco semestres con sus soluciones y se los aprendió de memoria, cifra por cifra. En los simulacros — que salen de esos mismos parciales viejos — saca 5.0 clavado. El segundo estudió los conceptos: resolvió ejercicios, se equivocó, entendió por qué se equivocaba. En los simulacros saca 4.2.

¿A quién le va mejor el día del parcial, con preguntas que ninguno ha visto? Exacto. El primero colapsa: su 5.0 era una ilusión, porque medirse en preguntas que ya conoces no mide que sepas — mide que memorizaste. El segundo saca su 4.2 tranquilo, porque su nota de simulacro sí medía comprensión.

Un modelo de Machine Learning puede ser cualquiera de los dos estudiantes

Y aquí está el problema de negocio: por fuera son idénticos. Ambos presentan métricas espectaculares en los datos con los que se construyeron. La diferencia solo aparece cuando llegan datos nuevos — y en una empresa, “datos nuevos” significa clientes reales, créditos reales, plata real.

Todo lo de esta semana — train/test, baseline, validación cruzada, leakage — es una sola pregunta repetida con distintos instrumentos: ¿este modelo entendió o memorizó? Tu trabajo como analista es averiguarlo antes de que la empresa le confíe una decisión.

¿Y por qué te importa? Porque los modelos ya están decidiendo: el banco que aprueba o niega un crédito en segundos, la universidad que dispara alertas tempranas de deserción, la tienda que pronostica cuánto inventario pedir. En la semana 5 llamaste a esto analítica predictiva. Esta semana le abres el capó.

Conexión con la semana 5 — y con tu proyecto final

¿Recuerdas la traducción de preguntas de negocio a tareas analíticas? ¿Este cliente incumplirá? → clasificación. ¿Cuánto venderá esta tienda? → regresión (predicción). ¿Qué grupos de clientes tengo? → segmentación. Las dos primeras son aprendizaje supervisado — hay una respuesta correcta en los datos históricos con la cual entrenar y calificar — y son el tema de las semanas 10 a 12. La segmentación no tiene “respuesta correcta” y por eso se evalúa distinto: eso es la semana 13. Tu pregunta del proyecto final cae en una de estas casillas, así que lo de hoy es, literalmente, el manual de evaluación de tu Entrega 3.

4 Aprender, para una máquina

Programar, como lo has hecho hasta ahora, es escribir reglas: si el ingreso es mayor a 4 millones y no tiene mora, apruebe. Machine Learning invierte el flujo: no le das las reglas — le das ejemplos resueltos (miles de solicitudes históricas con su desenlace) y el algoritmo encuentra los patrones solo.

Para eso el dataset se divide en dos papeles:

  • El target 🎯: la columna que quieres predecir. En los ejemplos de esta semana: la decisión de crédito (Aprobado/Rechazado) y la nota final de un estudiante (0 a 5).
  • Las features 🧩: las columnas con las que se predice. Ingreso, deuda, antigüedad laboral; parciales, tareas, asistencia.

Y del tipo de target sale el tipo de problema — la misma tabla de la semana 5, ahora con apellido técnico:

La pregunta de negocio Target Tipo de problema Métrica (hoy la aprendes)
¿Este solicitante incumplirá el crédito? Categoría Clasificación Matriz de confusión
¿Qué nota sacará este estudiante? Número Regresión MAE / RMSE
¿Cuánto venderá la tienda en mayo? Número Regresión MAE / RMSE
¿Este correo es spam? Categoría Clasificación Matriz de confusión
Advertencia

“Aprender” no es entender — es ajustar

El algoritmo no sabe qué es un crédito ni le importa. Solo ajusta parámetros para que sus predicciones se parezcan a los ejemplos que le diste. Por eso puede “aprender” cosas absurdas si los datos las contienen: patrones espurios, errores de digitación, ruido. Y por eso la evaluación honesta — todo lo que sigue — no es un trámite: es la única forma de saber si aprendió algo útil.

5 El pipeline: de la pregunta al reporte

Todo proyecto de ML serio recorre los mismos pasos, en el mismo orden. Este es el mapa de las próximas cuatro semanas del curso:

1
Pregunta y target. Traducir la pregunta de negocio a una variable concreta que predecir. Sin target claro no hay proyecto.
2
Features. Elegir y preparar las variables predictoras (aquí reaparece toda tu semana 6: limpieza y EDA).
3
Partir train/test. Separar el examen antes de estudiar. Típicamente 80/20 y al azar — con una excepción que veremos abajo.
4
Entrenar y ajustar. El algoritmo aprende con train; la validación cruzada compara versiones e hiperparámetros. (Semanas 11 y 12.)
5
Evaluar en test, contra un baseline. Una sola vez, con la métrica correcta, y comparando contra la regla tonta. (Esta semana.)
6
Reportar. Métrica en test + comparación con baseline + limitaciones y riesgos. Lo que un gerente necesita para decidir.

Fíjate en el orden de la clase: esta semana entras al pipeline por el final — aprenderás a ejecutar los pasos 5 y 6 sobre modelos que ya vienen entrenados. Es deliberado: primero juez, después ingeniero. Cuando la próxima semana entrenes tu primer árbol, ya sabrás calificarlo.

6 El examen: entrenamiento vs. prueba

La regla más importante de todo Machine Learning cabe en una línea:

Nunca evalúes un modelo con los datos que usó para aprender.

El modelo ya vio esas filas. Medir ahí es tomarle el examen con las mismas preguntas del simulacro: la nota sale inflada y no mide generalización. Por eso, antes de entrenar nada, se aparta un pedazo de los datos — el conjunto de prueba (test) — que el modelo no toca durante el aprendizaje. Ese pedazo simula el futuro: los clientes que aún no llegan, las solicitudes del próximo trimestre.

La receta estándar: mezclar las filas al azar y partir 80% train / 20% test. Dos detalles que en la práctica separan a los profesionales:

  1. El test se usa una sola vez, al final. Si lo consultas veinte veces mientras ajustas el modelo, deja de ser un examen y se convierte en otro simulacro — ya “aprendiste” de él. Para iterar está la validación cruzada (abajo).
  2. Con datos temporales, el azar se prohíbe. Si quieres predecir las ventas de mayo, entrena con enero-abril y prueba con mayo. Partir al azar mezclaría pasado y futuro: el modelo “vería” datos posteriores a los que intenta predecir — una fuga de información de manual.

7 Sobreajuste y subajuste

Volvamos a los dos estudiantes. En términos de modelos:

  • Subajuste (underfitting): el modelo es demasiado simple para el patrón real. Le va mal en train y en test — el estudiante que no estudió.
  • Sobreajuste (overfitting): el modelo es tan flexible que además del patrón se aprendió el ruido de train. Brilla en train, colapsa en test — el memorizador.

Entre los dos hay un punto dulce, y encontrarlo es el oficio. Muévele a la complejidad y mira qué pasa con los dos errores:

🎛️ El dial de la complejidad
Complejidad del modelo 1
Error en train
Error en test
Brecha (test − train)

Las curvas son ilustrativas — la forma es la típica de casi cualquier problema; los números exactos cambian en cada caso. La lección del dial: el error de train siempre baja al agregar complejidad, así que nunca es evidencia de calidad. La curva que decide es la de test — y por eso el examen es sagrado.

8 El baseline: la regla tonta que hay que vencer

Te presentan un modelo: “accuracy del 98%”. ¿Aplaudes? Todavía no. Falta la pregunta clave: ¿98% comparado con qué?

El baseline es el modelo que no piensa

  • En clasificación: predecir siempre la clase mayoritaria. Si el 55% de los créditos históricos fueron aprobados, la regla “apruebe a todo el mundo” acierta el 55% — sin mirar un solo dato del solicitante.
  • En regresión: predecir siempre el promedio. Si la nota media histórica es 3.3, la regla “todos sacan 3.3” ya logra un MAE sorprendentemente decente.

El baseline es la vara mínima: un modelo solo aporta lo que le gana al baseline. Y en un negocio la vara real suele ser más alta: la regla que la empresa ya usa (el comité de crédito, el pronóstico del vendedor experimentado).

El ejemplo clásico de por qué esto importa: detección de fraude. En 1.000 transacciones hay 20 fraudes (el 2%). Un “modelo” que responde “no es fraude” a todo alcanza 98% de accuracy — y no detecta ni un solo fraude. Espectacular en el papel, inservible en la vida. Guarda esta alarma para el video 1: cuando las clases están desbalanceadas, la accuracy se infla sola, y hay que mirar la matriz completa.

9 Validación cruzada: no un examen, sino cinco

Queda un problema práctico. El test se usa una sola vez, pero mientras construyes el modelo necesitas comparar decenas de versiones: ¿árbol profundo o superficial? ¿estas features o aquellas? Si comparas contra el test cada vez, lo gastas. Y si comparas con un único pedacito de train, puedes tener suerte (o mala suerte) con ese pedacito.

La solución es elegante — la validación cruzada (k-fold cross-validation): divide el train en k bloques (típicamente 5), entrena k veces rotando cuál bloque hace de examen, y promedia las k notas.

Ronda 1
Ronda 2
Ronda 3
Ronda 4
Ronda 5
entrena    examina — cada bloque del train hace de examen exactamente una vez; la nota final es el promedio de las 5 rondas.

Con ese promedio eliges tu mejor versión del modelo — profundidad del árbol, conjunto de features, algoritmo — y solo entonces, con la decisión tomada, presentas el examen final en el test. En las semanas 11 y 12 esto dejará de ser un dibujo: la usarás para elegir los hiperparámetros de tus árboles.

10 Data leakage: el enemigo silencioso

La palabra suena exótica; el error es cotidiano. Data leakage (fuga de datos) es cualquier camino por el que información del test — o del futuro — se cuela al entrenamiento. El resultado siempre es el mismo: métricas infladas en el laboratorio, decepción en producción. Es el error #1 de los proyectos de ML principiantes, y también de varios profesionales.

Las tres fugas más comunes:

  1. Preprocesar con toda la base. Imputar valores faltantes con el promedio global, o estandarizar variables con la media y desviación de todos los datos, antes de partir train/test. Suena inocente, pero ese promedio ya contiene información del test. La regla profesional: todo lo que se aprende de los datos (medias, escalas, imputaciones) se aprende solo con train y luego se aplica, congelado, al test.
  2. Variables del futuro. Para predecir si un crédito caerá en mora, incluir la variable “número de cuotas atrasadas al cierre” — una columna que solo existe después del desenlace. El modelo saca métricas de fantasía porque, literalmente, le diste la respuesta disfrazada de feature.
  3. Gastar el test. Probar 30 modelos y quedarse con el que dio mejor métrica en el test. Tras 30 consultas, el test dejó de ser un examen: elegiste al ganador por sus respuestas al examen, y su nota ya no predice nada.

¿Quedó claro? Demuéstralo — seis situaciones, tú decides:

🚰 ¿Hay leakage aquí?
1. Imputas los ingresos faltantes con el promedio calculado sobre toda la base y después partes train/test.
🚨 Hay fuga. Ese promedio ya "vio" las filas del test. Lo correcto: calcular el promedio solo con train y usarlo para imputar ambos conjuntos.
2. Calculas la media del ingreso solo con train y usas esa misma media para imputar los faltantes de train y de test.
Sin fuga. Es exactamente el protocolo correcto: lo aprendido (la media) salió solo de train; al test únicamente se le aplica.
3. Para predecir si un crédito caerá en mora, incluyes como feature el número de cuotas atrasadas al cierre del crédito.
🚨 Hay fuga — del futuro. Esa columna solo se conoce después del desenlace que intentas predecir. En producción no existirá al momento de decidir. Es la respuesta disfrazada de pregunta.
4. Antes de partir train/test, eliminas las filas duplicadas exactas de la base.
Sin fuga — de hecho, lo contrario. Si una fila repetida cae con una copia en train y otra en test, el modelo "verá" el examen. Deduplicar antes de partir previene esa fuga.
5. Estandarizas todas las variables (restar la media, dividir por la desviación) usando media y desviación de toda la base, y luego partes.
🚨 Hay fuga. Mismo pecado del caso 1 con otro disfraz: media y desviación se aprenden de los datos, así que deben salir solo de train.
6. Entrenas 30 modelos distintos y te quedas con el que sacó la mejor métrica en el test.
🚨 Hay fuga — la más elegante. Elegiste al ganador por sus respuestas al examen: el test ya participó del entrenamiento (del tuyo). Para comparar 30 modelos está la validación cruzada; el test se visita una sola vez.

11 Los videos: métricas con lápiz y papel

Hasta aquí, el juicio (“¿generaliza o memoriza?”) ha sido cualitativo. Falta el instrumento de medición: ¿cómo se califica, exactamente, una predicción? Eso es lo que construyen los dos videos de esta semana — uno para clasificación, otro para regresión. En el diseño original del curso venían al final de las semanas 11 y 12; los adelantamos para que llegues a los modelos ya sabiendo calificarlos. En la clase de esta semana los usarás sin descanso.

11.1 Video 1 — La matriz de confusión (clasificación)

El video construye, celda por celda, la tabla que resume cualquier clasificador. Usa como ejemplo un modelo que decide créditos — no importa todavía cómo decide (eso llega la próxima semana); importa cómo se califica lo que decidió. Al final el profesor propone un ejercicio de conteo: páusalo y resuélvelo — en clase harás exactamente esa operación sobre datos reales.

El resumen para tener a la mano. Comparas cada predicción con la realidad; hay cuatro resultados posibles (con “Aprobado” como clase positiva):

Predicho: Aprobado Predicho: Rechazado
Real: Aprobado Verdadero Positivo (TP) Falso Negativo (FN)
Real: Rechazado Falso Positivo (FP) Verdadero Negativo (TN)

Regla de memoria: la primera palabra (Verdadero/Falso) dice si el modelo acertó. La segunda (Positivo/Negativo) dice qué predijo el modelo. Un Falso Positivo es “predijo positivo… y falló”.

De esa tabla salen las tres métricas del curso:

Accuracy — ¿qué fracción del total clasificó bien? \[\text{Accuracy} = \frac{TP + TN}{TP + TN + FP + FN}\] Trampa conocida: con clases desbalanceadas se infla (el “modelo” que responde siempre lo mismo ya saca la accuracy de la clase mayoritaria — el detector de fraude del 98%).

Precisión — de los que el modelo marcó como positivos, ¿cuántos lo eran? \[\text{Precisión} = \frac{TP}{TP + FP}\] En crédito: de los que aprobó, ¿qué fracción pagó de verdad? Cada FP aquí es plata perdida.

Recall — de los positivos reales, ¿cuántos detectó el modelo? \[\text{Recall} = \frac{TP}{TP + FN}\] En crédito: de los buenos clientes que llegaron, ¿qué fracción aprobó? Cada FN aquí es un buen cliente rechazado.

¿Cuál importa más? Depende de cuál error cuesta más — y esa es una decisión de negocio, no del algoritmo:

Situación El error caro Conviene vigilar
Aprobar créditos (el impago es caro) FP: aprobar a quien no pagará Precisión alta
Detectar fraude FN: dejar pasar un fraude Recall alto
Diagnóstico médico FN: no detectar un caso real Recall alto
Retener clientes FN: no ver al que se va Recall alto

Ahora hazlo tú. Diez decisiones de un modelo de crédito — clasifica cada una en su celda:

🧮 Arma la matriz — clase positiva: Aprobado
Caso 1 de 10
Predicho:
Aprobado
Predicho:
Rechazado
Real:
Aprobado
Real:
Rechazado
¿En qué celda cae este caso? Haz clic en la celda.

11.2 Video 2 — MAE y RMSE (regresión)

En regresión no hay “acierto”: el modelo predijo 3.6 y la nota real fue 3.8. ¿Un error de 0.2 es mucho o poco? El video calcula las dos métricas estándar con un ejemplo paso a paso — míralo con calculadora a la mano y replica las cuentas.

El resumen. Para cada fila del test, el error es \(y_i - \hat{y}_i\) (real menos predicho). Las dos formas de promediarlo:

MAE — Error Absoluto Medio \[\text{MAE} = \frac{1}{n} \sum_{i=1}^{n} |y_i - \hat{y}_i|\] “En promedio, el modelo se equivoca por X unidades” — en las mismas unidades del target (puntos de nota, pesos, unidades vendidas). Fácil de comunicar a un gerente.

RMSE — Raíz del Error Cuadrático Medio \[\text{RMSE} = \sqrt{\frac{1}{n} \sum_{i=1}^{n} (y_i - \hat{y}_i)^2}\] Eleva cada error al cuadrado antes de promediar: los errores grandes pesan mucho más. Por eso siempre \(\text{RMSE} \geq \text{MAE}\), y por eso es la métrica preferida cuando equivocarse feo es especialmente caro.

Míralo en miniatura — cinco predicciones de nota, errores: 0.2, −0.4, 0.1, −0.1 y 1.2 (una embarrada grande):

\[\text{MAE} = \frac{0.2 + 0.4 + 0.1 + 0.1 + 1.2}{5} = 0.40\]

\[\text{RMSE} = \sqrt{\frac{0.04 + 0.16 + 0.01 + 0.01 + 1.44}{5}} = \sqrt{0.332} \approx 0.58\]

El RMSE quedó muy por encima del MAE por culpa de un solo error grande: esa distancia entre las dos métricas es una pista de que el modelo tiene fallas graves ocasionales, aunque “en promedio” se vea decente.

Situación Preferir
Los errores grandes son igual de malos que los pequeños MAE
Los errores grandes son especialmente costosos RMSE
Comunicar a una audiencia no técnica MAE
Detectar modelos con embarradas ocasionales Comparar ambos
Advertencia

Y siempre, siempre, contra el baseline

El baseline de regresión es predecir el promedio (calculado en train) para todo el mundo. Calcula el MAE y el RMSE de esa regla tonta antes de emocionarte con tu modelo: si el modelo no la mejora, no aprendió nada útil. Lo comprobarás en carne propia en el taller de esta semana.

12 ¿Y esto cómo se ve en tu semestre?

  • En la clase de esta semana: recibirás las predicciones de modelos ya entrenados — uno que decide créditos, otro que pronostica notas — y harás el trabajo del analista: matriz de confusión, precisión, recall, MAE, RMSE, comparación contra el baseline y veredicto de negocio. Sin entrenar nada todavía: primero juez.
  • Semanas 11 y 12: construirás tus propios modelos (árboles de clasificación y de regresión, y sus ensambles) y los calificarás con exactamente estas métricas. La validación cruzada dejará de ser un dibujo.
  • Semana 13: segmentación — el caso sin target, con sus propias métricas (codo, silueta).
  • Tu proyecto final: la Entrega 3 debe reportar la métrica correcta para tu tipo de pregunta, medida en test y comparada contra un baseline. Un jurado de esta materia siempre pregunta lo mismo: “¿y eso comparado con qué?” — desde hoy tienes la respuesta.

13 Para pensar 🤔

  1. Una farmacéutica usa un modelo para detectar reacciones adversas graves a un medicamento. ¿Qué prefiere: precisión alta o recall alto? ¿Quién paga el costo de cada tipo de error?
  2. Tu modelo de fraude saca 99.5% de accuracy y el fraude ocurre en el 0.5% de las transacciones. ¿Motivo de celebración o de sospecha? ¿Qué mirarías inmediatamente después?
  3. Un compañero te dice: “mi modelo da error cero en los datos de entrenamiento — es perfecto”. ¿Qué le respondes, en una frase, usando lo del dial de complejidad?

14 Checklist de salida

Al terminar el podcast, los videos y esta lectura debes poder explicar:

15 Preguntas de comprensión

1. Un modelo de clasificación se evalúa sobre 50 casos del test y produce: TP = 18, FN = 2, FP = 6, TN = 24. Calcula accuracy, precisión y recall. ¿Qué error comete más: FP o FN? ¿Y si cada FP cuesta el doble que cada FN, el modelo es tan bueno como parece?

Ver respuesta

Accuracy = (18+24)/50 = 84%. Precisión = 18/(18+6) = 75%. Recall = 18/(18+2) = 90%.

Comete el triple de FP (6) que de FN (2): cuando marca “positivo” se equivoca 1 de cada 4 veces. Si el FP es el error caro, el 84% de accuracy es engañoso — el modelo concentra sus errores justo donde más cuestan, y habría que ajustarlo (o rechazarlo) aunque la accuracy “se vea bien”.

2. Tu modelo alcanza accuracy de 99% en entrenamiento y 62% en test. (a) ¿Cómo se llama este cuadro clínico y qué lo delata? (b) Menciona dos acciones razonables para tratarlo.

Ver respuesta
  1. Sobreajuste: la brecha gigante entre train (99%) y test (62%) delata que el modelo memorizó el ruido de entrenamiento en vez de aprender el patrón. La nota de train nunca es evidencia de calidad — siempre mejora con la complejidad.

  2. Entre otras: reducir la complejidad del modelo (menos profundidad, menos parámetros), conseguir más datos de entrenamiento, usar validación cruzada para elegir la versión con mejor desempeño fuera de train. Cualquier par de estas vale.

3. Una cadena de tiendas evalúa dos modelos que pronostican unidades a pedir por semana. El modelo A tiene MAE = 8 y RMSE = 9; el modelo B tiene MAE = 7 y RMSE = 15. Quedarse corto o pasarse por mucho produce pérdidas graves (bodega llena o estantes vacíos). ¿Cuál eliges y por qué?

Ver respuesta

El modelo A. Aunque B gana por MAE (7 < 8), su RMSE dispara la alarma: 15 muy por encima de 7 significa que B comete errores enormes de vez en cuando — exactamente lo que el negocio dice que no tolera. A es apenas peor “en promedio” pero mucho más estable (RMSE 9 ≈ MAE 8). Cuando los errores grandes son los caros, manda el RMSE.

4. Un equipo predice deserción estudiantil. Imputan la asistencia faltante con el promedio de toda la base, parten train/test, entrenan y obtienen métricas excelentes que luego no se repiten en producción. ¿Dónde estuvo la fuga, por qué infló la métrica y cómo se corrige el procedimiento?

Ver respuesta

La imputación usó el promedio de toda la base — que incluye las filas que después serían test. Información del “examen” se coló al entrenamiento: data leakage. La métrica de test quedó inflada porque el test ya no era independiente; en producción, con datos de verdad nuevos, esa ventaja desaparece y el desempeño cae.

Corrección: partir train/test primero; calcular el promedio de asistencia solo con train; usar ese valor congelado para imputar train y test (y el mismo principio para escalas y cualquier parámetro aprendido de los datos).

16 Material adicional

  • 📘 An Introduction to Statistical Learning (ISLR) — capítulos 2 y 5 (evaluación y validación cruzada), el libro gratuito de referencia: statlearning.com
  • 🎓 Google ML Crash Course — módulos de clasificación y regresión con ejercicios interactivos: developers.google.com
  • 🖼️ MLU-Explain — explicaciones visuales e interactivas de train/test, validación cruzada y precisión/recall: mlu-explain.github.io
  • 🎥 StatQuest — repaso alternativo (en inglés, con humor) de la matriz de confusión: youtube.com/@statquest