SELECCIÓN
Una mejora agregada no bastó
El challenger redujo WAPE 11,94 %, pero alcanzó 14,77 % de sesgo absoluto y solo mejoró 10 de 20 productos.
CASO DE ESTUDIO · RELEASE 1.0.1
Retail Demand Forecasting & Monitoring recorre un sistema de forecasting completo: contrato temporal, baseline, challenger, intervalos, holdout final, persistencia, API y monitoreo. El resultado final no habilitó el modelo para decisiones operacionales, y esa conclusión se conserva como parte central del proyecto. La release 1.0.1 mejora la entrega y las pruebas sin modificar el resultado congelado de la evaluación.
01 · RETO
La fuente contiene facturas históricas de un retailer británico sin tienda física. El objetivo se definió como unidades positivas facturadas por SKU y día: un proxy observable, no demanda irrestricta.
No hay información confiable de inventario, quiebres de stock, promociones, cumplimiento ni ventas perdidas. El problema exigía ordenar el tiempo correctamente, mantener el holdout fuera del ajuste y evitar que una mejora promedio escondiera sesgo o deterioro por SKU.

02 · PROCESO
El proyecto separa desarrollo, confirmación, calibración de intervalos y holdout. Cada fase conserva manifiestos y hashes para que repetir el software no signifique reabrir evidencia usada para decidir.
Fuente, cohortes, panel diario y reglas temporales documentadas.
Seasonal naive de siete días evaluado en folds rolling-origin.
Error, sesgo, consistencia y amplitud por SKU deciden el champion.
Calibración por horizonte sin usar resultados del holdout final.
La ventana final se evalúa una vez mediante contrato y recibo.
API, persistencia y dashboard reconstruyen la evidencia histórica.
SELECCIÓN
El challenger redujo WAPE 11,94 %, pero alcanzó 14,77 % de sesgo absoluto y solo mejoró 10 de 20 productos.
CHAMPION
Seasonal naive permaneció como champion porque el candidato no cumplió todas las reglas predefinidas.
INTEGRIDAD
Panel, cohorte, evidencia previa y árbol de código se verifican antes de abrir la evaluación final.
PRODUCTO
FastAPI, PostgreSQL/JSON y un dashboard permiten revisar pronósticos, outcomes y alertas ya sellados.
03 · RESULTADOS
| Métrica | Resultado | Lectura predeclarada |
|---|---|---|
| WAPE | 1,1565 | Error agregado alto; bajo el umbral de alerta provisional de 2,00 |
| MAE | 85,1881 | Unidades por fila SKU-día |
| Sesgo normalizado | +0,0593 | Dentro del guardrail de ±0,10 |
| Cobertura empírica | 77,02 % | Falla el mínimo de 85 % y el objetivo nominal de 90 % |
| Ancho medio | 192,3692 | Debe leerse junto con la cobertura insuficiente |
| Winkler score | 1.105,4818 | Penaliza simultáneamente amplitud y fallos de cobertura |
DECISIÓN PUBLICADA
degraded_with_published_alerts · no-go operacionalSe emitieron 52 alertas en los niveles global, horizonte y SKU. El resultado demuestra el proceso de evaluación y monitoreo, no la calidad necesaria para automatizar compras.
04 · INGENIERÍA
TEMPORALIDAD
Veinte folds no solapados y una ventana final de 84 días separan aprendizaje y evaluación.
PERSISTENCIA
Repositorios intercambiables conservan inserciones atómicas, reconciliación e idempotencia.
CALIDAD
La release revisada pasa 107 pruebas, lint, builds y smoke tests del stack PostgreSQL.
ENTREGA
Docker Compose expone solo la API en localhost y carga un snapshot histórico de solo lectura.
05 · LÍMITES
EVIDENCIA PÚBLICA
El repositorio conserva los contratos, informes, figuras, pruebas y artefactos necesarios para seguir la decisión desde los datos hasta las alertas finales.