lección 5
Jueves A: el split al azar deja ver el futuro
Se te cae el 0,91: partir las horas al azar entrena con el futuro para predecir el pasado. Demostrar la fuga y ver qué datos no se parten al azar.
⏱ 55 min
## Jueves, 10:05. La pregunta de Severino
Ayer le mandaste a Severino un mensaje eufórico: R² de 0,91, error de menos de un servicio por hora a dos semanas vista, casi tienes el número para Rebeca. Él no te lo celebró. Te respondió que no mandaras nada todavía y que esta mañana lo mirabais juntos. Y lo primero que te pregunta, antes de abrir ningún gráfico, es esto: «Tus features miran todas a 14 días o más, bien. Pero si repartes las horas al azar entre entrenamiento y prueba, ¿qué puede acabar en el entrenamiento que sea del futuro de una fila de prueba?». Te quedas pensando. Y entonces lo ves.
Si una fila de prueba es el martes a las 10, al barajar el martes a las 9 puede haber caído perfectamente en el entrenamiento, con su demanda real como respuesta. Y sus pistas son casi las mismas que las de las 10: el mismo día, el mismo mes, casi la misma hora y casi las mismas medias de hace 14 días. Es decir: el modelo ha aprendido con una hora que está pegadita, en el tiempo, a la hora que tiene que predecir. Ha visto lo de alrededor. Peor aún: la hora de prueba del martes a las 10 tiene vecinas suyas —las 9, las 11, el lunes a las 10— repartidas por el entrenamiento, y todas se parecen muchísimo entre sí porque la demanda cambia poco de una hora a la siguiente. El modelo no está prediciendo el futuro desde el pasado: está rellenando un hueco rodeado de datos casi idénticos que ya conoce.
## Por qué esto es trampa, y no un modelo mejor
La clave es entender que esto NO es que el modelo sea bueno. Es que la evaluación le está regalando la respuesta. En la vida real, cuando la central use el modelo para cuadrar el turno del martes que viene, tú solo tendrás el pasado: sabrás lo que entró hasta hoy, pero no lo que entrará el martes a las 9, ni a las 11, ni ninguna hora futura. El modelo tendrá que predecir el martes a las 10 sin tener a mano sus horas vecinas, porque todavía no han pasado. El split al azar le da, en la prueba, un lujo que nunca tendrá en producción: ver lo de alrededor. Por eso el 0,91 es un espejismo. No mide lo que el modelo sabe hacer; mide lo fácil que es rellenar huecos cuando te rodean de pistas.
Esto es un pariente cercano de un error que ya conoces de otros trabajos: dejar que el modelo vea, al evaluar, información que en el momento de predecir no tendría. Pero el mecanismo aquí es distinto y conviene no confundirlo. No hay ninguna columna tramposa: todas tus features son legítimas, se calculan con datos de hace 14 días o más, lo arreglaste ayer con el shift. La serie entera está bien construida. La fuga no está en los datos: está en el MÉTODO con el que partes la serie para evaluar. Es una trampa de evaluación, no de features. Y por eso no se arregla cambiando ninguna columna: se arregla cambiando cómo se parte.
Consejo de senior: la regla para saber si una evaluación es honesta es ponerse en el momento de la predicción y preguntar "¿qué sabría yo de verdad en este instante?". Si para predecir el martes a las 10 tu evaluación le ha dejado al modelo ver el martes a las 9 (que en producción aún no habría pasado), la evaluación miente, por muy bueno que salga el número. En una serie, lo único que sabes de verdad en el momento de predecir es el pasado. Así que el test tiene que ser, siempre, el futuro.
## Qué se puede partir al azar y qué no
Aquí está la lección que te llevas, y que vale para toda tu carrera. No todos los problemas tienen esta trampa. Cuando las filas son independientes —un cliente, una parcela, un socio—, repartirlas al azar entre entrenamiento y prueba es correcto y es lo que hay que hacer: no hay un "antes" ni un "después" entre un socio y otro, así que ninguna fila puede filtrar información a otra. Fue lo correcto en tus tres encargos anteriores. Pero cuando las filas forman una serie en el tiempo, barajar mezcla pasado y futuro, y entonces la partición honesta es por tiempo: entrenar con los primeros meses y probar con los últimos, respetando el orden. El criterio no es el modelo ni el tema: es si las filas tienen un orden temporal que importa.
Para terminar de ver el patrón que el modelo está aprovechando, vas a mirar también la demanda media por hora del día con una consulta SQL. Verás los picos: las puntas de la mañana y de la tarde se repiten día tras día, y por eso una hora se parece tanto a sus vecinas y a la misma hora de otros días. Esa regularidad es la que hace tan predecible la serie —y la que, con el split al azar, el modelo explota de más—. Entenderla te prepara para mañana, cuando reevalúes el modelo como se debe.
Los ejercicios de Python reconstruyen la tabla a 14 días con el bloque de siempre. Para la consulta SQL del patrón horario, DuckDB lee serie_modelo.csv como la tabla serie_modelo; de ella solo usas n_servicios y hora, para mirar la demanda (sus columnas de lags de 1h no se usan para predecir a 14 días).
volver a la visión del caso y descargar los datasets## comentarios
Reporta erratas, ayuda a otros o comparte tu opinión. Sé constructivo.
Inicia sesión para comentar y responder.
cargando comentarios...
Regístrate para guardar tu progreso.