Imagina que acabas de terminar de entrenar un modelo de predicción de abandono de clientes para una startup de logística en Madrid. Has usado Scikit Learn Test Train Split y los resultados son espectaculares: un 98% de precisión en tu conjunto de pruebas. Presentas las métricas al equipo directivo, se autoriza el despliegue y, tres semanas después, el modelo falla estrepitosamente en producción. La empresa pierde diez mil euros en campañas de marketing dirigidas a personas que no iban a irse, mientras que los clientes que sí estaban a punto de marcharse pasan desapercibidos. ¿Qué ha pasado? Que confiaste ciegamente en una función de una línea sin entender la naturaleza de tus datos. He visto esta película docenas de veces: el profesional asume que una división aleatoria es suficiente, ignorando que el azar, sin control, es el camino más rápido hacia el sobreajuste y la decepción empresarial.
El mito de la aleatoriedad pura en Scikit Learn Test Train Split
Muchos ingenieros de datos novatos creen que tirar los dados es la forma más justa de evaluar un modelo. Piensan que al dejar que la máquina elija qué filas van al entrenamiento y cuáles al test, están eliminando el sesgo. No es así. Si trabajas con datos desbalanceados —como sucede en la detección de fraude o en diagnósticos médicos raros—, una división puramente aleatoria puede dejarte con un conjunto de test donde casi no hay ejemplos de la clase positiva.
He auditado proyectos donde el modelo "aprendía" simplemente a decir que "no" a todo, porque en su fragmento de entrenamiento la clase positiva era casi inexistente. El problema radica en no usar el parámetro stratify. Cuando no estratificas, no garantizas que la proporción de las clases se mantenga constante entre ambos bloques. Si en tu base de datos original el 5% de los usuarios son premium, tanto tu entrenamiento como tu evaluación deben reflejar ese 5%. Ignorar esto no solo invalida tus métricas, sino que te da una falsa sensación de seguridad que desaparece en cuanto el modelo toca el mundo real.
La fuga de datos por culpa del orden temporal
Este es el error más costoso que puedes cometer en series temporales. Si estás prediciendo el precio de la vivienda en Bogotá o la bolsa de valores, no puedes mezclar el pasado con el futuro. Scikit Learn Test Train Split tiene, por defecto, el parámetro shuffle activado como True. Esto significa que el modelo podría estar entrenando con datos de diciembre para predecir lo que pasó en enero.
En un escenario real de predicción de ventas, si permites que el modelo vea el futuro para predecir el pasado, estás haciendo trampas sin saberlo. El modelo memoriza patrones que no existen de forma causal. La solución no es otra que desactivar la mezcla aleatoria o, mejor aún, usar divisores específicos para series de tiempo. He visto empresas gastar meses de salarios de ingenieros en modelos que funcionaban increíblemente bien en el laboratorio, pero que eran basura tecnológica porque el entrenamiento contenía información "del futuro" que no estaría disponible en el momento de la ejecución real.
Ignorar el estado de la semilla aleatoria
No fijar el random_state es una receta para el caos en equipo. Trabajas en un modelo, obtienes un resultado decente, se lo pasas a un compañero y, de repente, a él le da algo totalmente distinto. No es magia negra, es simplemente que la partición ha cambiado.
Fijar este número no hace que tu modelo sea mejor, pero lo hace reproducible. Sin reproducibilidad, no hay ciencia, solo hay adivinación. Si no puedes recrear exactamente la misma división de datos, no puedes comparar si un cambio en los hiperparámetros realmente mejoró el rendimiento o si simplemente tuviste suerte con la partición de esa ejecución específica. En entornos profesionales, la falta de una semilla fija impide las auditorías de modelos y genera desconfianza en los departamentos de control de calidad.
El peligro de la optimización excesiva de la semilla
Hay quien lleva esto al extremo opuesto y busca una semilla que, por puro azar, dé mejores resultados en el test. Esto es engañarse a uno mismo. Si pruebas mil semillas diferentes hasta encontrar una que suba tu precisión un 2%, no has mejorado el modelo; has ajustado el modelo a ese conjunto de test específico. Es un error sutil pero letal.
Mezclar el preprocesamiento antes de la división
Este es el error técnico más común que detecto en las entrevistas técnicas. Alguien carga su dataset, calcula la media y la desviación estándar de todas las columnas para normalizar los datos, y solo después aplica la partición.
Es un error grave porque la media del conjunto de test se ha filtrado en el conjunto de entrenamiento. El modelo ya "sabe" algo sobre la distribución de los datos que se supone que son secretos. En un caso real de una empresa aseguradora con la que colaboré, esto infló artificialmente el rendimiento en un 15%. Cuando corrigieron el flujo y calcularon los escaladores solo con los datos de entrenamiento, la realidad golpeó con fuerza: el modelo no era tan bueno como pensaban. La regla de oro es: el conjunto de test debe ser un búnker. Nada de lo que hay allí, ni siquiera una estadística simple como el promedio, debe tocar el entrenamiento.
Comparación directa: el enfoque ingenuo frente al profesional
Para entender el impacto de estos fallos, analicemos cómo se vería un proceso en un entorno de predicción de riesgo crediticio.
El enfoque equivocado: Un analista carga 100.000 registros de préstamos. Aplica una limpieza general de valores nulos usando la mediana de toda la columna. Luego, usa una función estándar para separar los datos sin preocuparse de si hay más impagos en un lado que en otro. Entrena un bosque aleatorio y obtiene un área bajo la curva (AUC) de 0.92. El negocio está encantado y lanza el sistema. A los seis meses, la tasa de morosidad se dispara porque el modelo nunca aprendió realmente a identificar a los clientes de alto riesgo; simplemente aprovechó la fuga de información de las medianas globales y el desbalance de clases para "adivinar" que la mayoría pagaría.
El enfoque profesional: El profesional experimentado primero separa los datos. Reserva un 20% para la evaluación final y no lo mira. Todo el análisis exploratorio y el cálculo de imputaciones (como esa mediana) se realiza exclusivamente sobre el 80% restante. Utiliza una estrategia de estratificación para asegurar que la proporción de clientes morosos sea idéntica en ambos grupos. Además, verifica si hay duplicados o registros altamente correlacionados que puedan estar presentes en ambos conjuntos (fuga por proximidad). El resultado es un AUC de 0.84. Parece peor que el anterior, pero es real. Este modelo sobrevive al despliegue porque fue evaluado con rigor, permitiendo a la empresa provisionar el capital necesario de forma precisa.
La trampa de los conjuntos de datos pequeños
Cuando tienes pocos datos, el riesgo de que una partición aleatoria te juegue una mala pasada se multiplica. Si solo tienes 500 filas, un 20% de test son apenas 100 registros. Basta con que cinco o seis ejemplos atípicos caigan en el test para que tus métricas bailen de un lado a otro cada vez que cambias la semilla.
En estos casos, confiar solo en una división es una negligencia. Tienes que usar validación cruzada. La gente suele ver esto como algo opcional o "para nota", pero cuando los datos escasean, es la única forma de obtener una estimación honesta del error. He visto startups fracasar porque basaron su producto mínimo viable en una métrica obtenida de un conjunto de test de 50 muestras que, por pura coincidencia, eran las más fáciles de clasificar.
Verificación de la realidad sobre el uso de datos
No existe una configuración mágica que funcione para todo. Si esperas que una herramienta automatizada o una línea de código salve un mal diseño experimental, vas a perder dinero y credibilidad. La mayoría de los fallos en modelos de aprendizaje automático no vienen de algoritmos deficientes, sino de una gestión de datos mediocre.
Para tener éxito, tienes que aceptar que el rendimiento que ves en tu ordenador es, casi con total seguridad, una visión optimista. El mundo real es más sucio, más ruidoso y menos previsible que cualquier partición que hagas. La clave no es buscar el porcentaje más alto en tu consola, sino construir un sistema de evaluación que sea tan cruel y exigente con tu modelo que, cuando este finalmente salga a producción, nada de lo que encuentre pueda sorprenderle. Si tu proceso de evaluación es cómodo, tu modelo fallará. Si tu proceso es riguroso y te da noticias que no quieres oír, vas por el buen camino.
