Saltar al contenido

lección 7

Viernes: predecir los próximos turnos y que se fíen del número

Predecir la demanda de los tramos futuros, traducirla a operadores por turno, montar las figuras y escribir el one-pager con el error honesto.

⏱ 55 min

## Viernes, 10:00. Que sirva y que se entienda

Ya tienes un modelo honesto y sabes por cuántos servicios se equivoca de verdad. Hoy hay que convertir eso en dos cosas: una entrega que Rebeca pueda usar el lunes para cuadrar los turnos, y un mensaje que Casilda entienda en cinco segundos y que la deje fiarse del número. No es el día de más código, pero es el que decide si todo el trabajo de la semana sirve para algo o se queda en un notebook que nadie abre. Un modelo que no se usa es un modelo que no existe.

Lo primero es predecir de verdad. Rebeca te pasó un fichero con los tramos futuros: los 14 días siguientes al histórico, por zona y hora, sin demanda —porque aún no han pasado—. El modelo necesita, para cada tramo, las mismas pistas con las que aprendió: los lags, las medias móviles, el calendario. El calendario es fácil, sale de la fecha del tramo. Y aquí cobras el premio de haber respetado el horizonte: como ninguna pista mira a menos de 14 días, las de los próximos 14 días ya existen hoy en el histórico. No hay que inventar la "demanda de hace una hora" de un martes que aún no ha llegado, ni encadenar predicciones. Se fabrican con el mismo bloque de siempre, pegando los tramos futuros al final de la serie.

Para predecir el futuro hay que fabricarle al modelo las mismas pistas con las que aprendió: los lags salen de la demanda de hace 14 días o más, que ya conoces; el calendario, de la fecha del tramo. El modelo que predice es el evaluado por tiempo, el honesto.

## De servicios a operadores por turno

La predicción, en servicios, no le sirve a Rebeca tal cual: ella piensa en operadores y grúas. Traducir es sencillo y es lo que convierte tu número en una decisión. Si sabes que un operador puede atender del orden de un número de servicios por hora, dividir la demanda prevista entre esa capacidad te da cuántos operadores hacen falta en ese tramo. Y aquí es donde el error honesto gana su sueldo: como sabes que a 14 días te equivocas de media en ~2,5 servicios por hora, puedes añadir un margen de seguridad en las zonas y tramos donde más se mueve la demanda, para no quedarte corto. Con el 0,97 falso, ese margen habría sido demasiado ajustado, y el primer martes de ola de frío la central se habría quedado sin grúas.

## Las figuras que se entienden en cinco segundos

Casilda no quiere ver tu código ni una tabla de métricas: quiere tres o cuatro imágenes limpias que cuenten la historia. La estrella es la comparación de los dos splits —al azar contra por tiempo—, porque enseña de un vistazo por qué el 0,97 engañaba y por qué el 2,5 es el bueno, con la referencia de hace 14 días al lado. Después, un predicho contra real sobre el tramo de prueba temporal, para que se vea dónde acierta el modelo (el nivel de la demanda) y dónde no (el detalle de cada hora). Y la demanda media por hora del día, el patrón que Rebeca ya intuía, para dar contexto. Nada de jerga, ejes claros, y una cifra grande: el error en servicios con el que se puede dimensionar.

Consejo de senior: cuando presentes a alguien que decide presupuestos y plantilla, la peor cifra que puedes dar es la que no se cumple. Casilda prefiere oír "me equivoco de media en 2,5 servicios por hora" y poder fiarse, que oír "0,97" y descubrir en la primera ola de frío que era mentira. La honestidad no es una virtud moral abstracta aquí: es lo que hace que tu modelo se siga usando después del primer susto. Un número en el que no se puede confiar se deja de usar, y entonces da igual lo bueno que fuera.

## El one-pager y el cierre del repositorio

El último entregable es el README del repositorio: el one-pager que resume qué hace el proyecto, cómo se ejecuta y —lo más importante— el hallazgo honesto de la semana. Tres hallazgos y una recomendación. Que se puede predecir la demanda a 14 días con un error medio de ~2,5 servicios por hora, la mitad que repitiendo lo de hace dos semanas. Que el patrón que Rebeca intuía es real y el modelo lo usa vía la hora del día y el nivel reciente. Que el R² bueno del principio era trampa, y el error honesto, más alto, es el que se cumple. Y la recomendación: dimensionar los turnos con el error del split temporal, con un pequeño margen donde el error es mayor. Con eso, el repositorio queda cerrado: los cinco ficheros de src/, las consultas de sql/, el requirements.txt y el README. Un proyecto de forecasting completo, que puedes subir a tu GitHub.

El repositorio lleno al cerrar la semana. Lo que parecían ejercicios sueltos era este proyecto montándose pieza a pieza. Un proyecto de forecasting completo y reproducible, listo para tu portfolio.

En la demo, Casilda te pregunta directa: ¿me puedo fiar del número para poner la gente del martes? Le explicas que el 0,91 era un espejismo, que al partir la serie al azar el modelo se copiaba del futuro, y que el número real, probándolo con dos semanas que no había visto, es un error de ~2,5 servicios por hora: la mitad que repitiendo lo de hace dos semanas, pero lejos del 0,97 que parecía. Rebeca murmura que ya tenía los turnos cuadrados con el 0,91. Y Casilda cierra el caso con la frase que resume por qué este trabajo valía la pena: menos mal que lo habéis visto antes de poner a nadie, prefiero un número honesto a uno bonito que me explote en el arcén. Buen trabajo.

Hoy usas periodos_a_predecir.csv (los 14 días de tramos futuros por zona y hora), serie_horaria.csv y calendario_festivos.csv, y les fabricas las features a 14 días con el bloque de siempre. Todo en la carpeta datos/. (Los ficheros periodos_features.csv y periodos_predichos.csv son de una versión anterior con pistas de hace una hora, imposibles de conocer a 14 días: no los uses.)

volver a la visión del caso y descargar los datasets

Regístrate para guardar tu progreso.