Contexto
Un modelo de demanda puede acertar durante periodos tranquilos y fallar precisamente cuando el responsable necesita reforzar recursos. Si esos periodos dominan el histórico, el error medio puede mejorar aunque la predicción en los picos siga siendo inútil.
La carga depende de demanda y capacidad disponible. La misma afluencia puede resultar manejable con todos los puestos abiertos y crítica con parte de ellos fuera de servicio. Los cambios de horario, personal o infraestructura deben describirse con la información que se conocía al emitir la previsión.
Tampoco conviene borrar todos los extremos como si fueran errores. Un registro duplicado exige una corrección; un episodio real poco frecuente exige evaluación. Excluir ambos de la misma manera produciría un histórico cómodo que no representa la operación.
Ejemplo didáctico · situación inventada
Un aviso correcto que llega cuando ya no se puede reforzar
Un centro de atención registra pocas desviaciones durante la jornada habitual. Cuando cierra otro centro cercano, recibe una oleada de solicitudes. El modelo detecta el pico al empezar la cola, pero el refuerzo necesita prepararse con antelación.
Qué decisión cambia. La prueba debe medir cuánto antes se anticipa el pico y si el aviso permite actuar. Acertar el máximo después de que llegue la demanda no cumple esa función. Se conserva el episodio completo para evaluar el siguiente candidato, sin repartir sus registros entre entrenamiento y prueba.
Qué comprobar antes de empezar
- Definición de saturación, capacidad disponible y fuentes con las que se reconoce cada episodio.
- Número de episodios y jornadas distintos, además del número de registros.
- Horizonte mínimo que necesita la persona responsable para actuar.
- Coste de una falsa alarma y coste de no anticipar un pico.
- Demoras, ausencias o cambios de cobertura de las fuentes durante los momentos difíciles.
Método de trabajo
Fijar la prueba antes de ver al ganador
Identifica las jornadas y condiciones de carga con el equipo operativo. Reserva periodos completos; evita repartir momentos del mismo episodio entre entrenamiento y prueba. Si la etiqueta del episodio se obtiene al final de la jornada, puede servir para analizar resultados, pero no para alimentar una predicción anterior. Documenta la separación y cualquier periodo excluido.
Medir el pico con la unidad correcta
Informa del error por horizonte, del retraso en detectar el aumento y de cuánto se infraestima la demanda máxima. Cuenta falsas alarmas por unidad de tiempo operativa y picos omitidos sobre episodios observados. Compara las predicciones emparejadas sobre las mismas jornadas. Para estimar incertidumbre, respeta la dependencia entre registros, por ejemplo mediante remuestreo de bloques cuya longitud tenga justificación.
Diagnosticar por qué empeora
Comprueba primero si faltan ejemplos, si una fuente llega tarde o si la relación entre demanda y capacidad ha cambiado. Añadir variables de contexto, ajustar el muestreo o corregir la fuente son respuestas diferentes. La especialización por regímenes requiere patrones repetidos fuera de muestra; crear un modelo por cada pico no resuelve la escasez de episodios.
Ensayar la degradación del sistema
Reproduce una entrada retrasada, la caída de un contador y un aumento de peticiones. Registra qué predicciones dejan de emitirse o pierden calidad. Mide por separado la latencia de respuesta y el error del pronóstico. Una cola informática saturada puede convertir una previsión correcta en una respuesta demasiado tardía para actuar.
Aceptar una mejora sin esconder regresiones
Exige rendimiento suficiente en episodios críticos y en el resto del servicio. Acercar ambas métricas empeorando los periodos tranquilos no es una mejora. Entrega el desglose por jornada, tamaño de muestra y casos fuera de cobertura. Si solo existe un episodio extremo, puede estudiarse como prueba de estrés; no acredita estabilidad ante episodios futuros.
Señales para detener la prueba
- Se redefine qué cuenta como saturación después de observar los resultados.
- La aparente mejora depende de muchas filas del mismo incidente y no se repite en otro periodo.
- El aviso llega después del momento en que todavía era posible intervenir.
- Se eliminan eventos válidos difíciles o se presentan fuentes imputadas como observaciones reales.
Fuentes
- scikit-learn — límites de la validación aleatoria y separación temporal — Las observaciones relacionadas requieren un diseño de evaluación que conserve su dependencia.
- Sagawa et al. — robustez ante cambios entre grupos — Investiga la generalización del peor grupo y la importancia de regularizar; no demuestra que especializar sea siempre mejor.
Para seguir con esta decisión
- ¿Cómo validar mantenimiento predictivo cuando hay pocas averías?
- ¿Cómo saber si el intervalo de una predicción es fiable?
- ¿Por qué predecir demanda no basta para asignar recursos?
Servicio de Machine learning y modelos predictivos: alcance y entregables
Publicado por Ordantis el .