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 próximos días, 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. Pero los lags son el reto del forecasting por features: para predecir el primer tramo futuro, su "demanda de hace una hora" es la última hora conocida del histórico; para el siguiente, puede ser la que acabas de predecir. Se van encadenando a partir de la demanda más reciente conocida. En este caso te damos los tramos futuros ya con sus features fabricadas, para que te centres en lo que importa el viernes: predecir y comunicar.

Para predecir el futuro hay que fabricarle al modelo las mismas pistas con las que aprendió: los lags salen de la demanda más reciente conocida, 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 te equivocas de media en ~1,5 servicios por hora, puedes añadir un pequeño margen de seguridad en las zonas y tramos donde más se mueve la demanda, para no quedarte corto. Con el 0,86 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,93 engañaba y por qué el 0,70 es el bueno. Después, un predicho contra real sobre el tramo de prueba temporal, para que se vea que el modelo honesto sigue bien los picos aunque no clave 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 1,5 servicios por hora" y poder fiarse, que oír "0,86" 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 con un error medio de ~1,5 servicios por hora. Que el patrón que Rebeca intuía es real y el modelo lo usa vía los lags. Que el R² bueno del principio era trampa, y el número honesto, más bajo, 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,93 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 semanas que no había visto, es 0,70, con un error de ~1,5 servicios por hora. Rebeca murmura que ya tenía los turnos cuadrados con el 0,93. 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 tramos futuros por zona y hora) y serie_modelo.csv (la tabla de modelado). Para que te centres en predecir y comunicar, los tramos futuros se te dan con sus features ya fabricadas en periodos_features.csv. Todo en la carpeta datos/.

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

Regístrate para guardar tu progreso.