¿Cómo mitigar el overfitting al forecast de demanda?

Joannes Vermorel

Nuestro video sobre overfitting recibió su parte de atención desde que se publicó hace 5 años, es decir, hace medio siglo para una startup como Lokad. Años más tarde, hemos progresado mucho pero overfitting sigue siendo un asunto difícil.

En resumen, el overfitting representa el riesgo de que tu modelo de forecast sea preciso solo al predecir el pasado, y no al predecir el futuro. Un buen modelo de forecast debería ser bueno para predecir los datos que no tienes.

Un concepto erróneo común es que no existe otra manera de evaluar un modelo, excepto comprobando su rendimiento contra los datos históricos. Es cierto, los datos históricos deben aprovecharse; sin embargo, si hay una lección a recordar de la teoría de Vapnik-Chervonenkis, es que no todos los modelos nacen iguales: algunos modelos conllevan mucho más riesgo estructural — un concepto parte de la teoría — que otros. Toda una clase de modelos puede ser considerada como segura o no segura desde una perspectiva puramente teórica, lo que se traduce en mejoras muy reales en accuracy.

Las cuestiones del overfitting no pueden evitarse por completo, pero pueden mitigarse de todos modos.

Existen varias formas de mitigar el overfitting. Primero, la única regla que nunca debes romper es: un modelo de forecast nunca debe evaluarse contra los datos que se utilizaron para entrenar el modelo en primer lugar. Muchos conjuntos de herramientas ajustan modelos sobre toda la historia para luego estimar el fit general. Pues bien, como sugiere el nombre, tal proceso te da el fit pero nada más. En particular, el fit no debe interpretarse como ningún tipo de precisión esperada, no lo es. El fit es típicamente mucho menor que la precisión real.

Segundo, una forma sencilla de mitigar el overfitting es realizar extensos back-testing. En la práctica, esto significa que tu proceso necesita dividir el conjunto de datos de entrada en docenas — si no cientos — de umbrales de fecha incrementales, y reentrenar todos los modelos de forecast y reevaluarlos cada vez. El back-testing requiere mucha potencia de procesamiento. Poder asignar la enorme potencia de procesamiento que se necesita para realizar back-testing extenso fue de hecho una de las razones principales por las que Lokad migró hacia computación en la nube en primer lugar.

En tercer lugar, incluso el back-testing más extenso vale poco si tus series de tiempo son escasas en primer lugar, es decir, si las series de tiempo representan artículos con bajos volúmenes de ventas. De hecho, dado que la mayoría de los puntos de datos de las series de tiempo son cero, el proceso de back-testing aprende muy poco al iterar sobre ceros. Desafortunadamente para el comercio, aproximadamente el 90% de los artículos vendidos o atendidos tienen un historial de demanda que se considera escaso desde un punto de vista estadístico. Para abordar este problema, el rendimiento del modelo debería evaluarse con una perspectiva de múltiples series de tiempo. No es el rendimiento del modelo sobre una única serie de tiempo lo que importa, sino su rendimiento sobre clusters bien definidos de series de tiempo. Entonces, cada uno se convierte en un equilibrio entre la precisión empírica local vs la global a la hora de seleccionar el mejor modelo.

¿Alguna pregunta? No dudes en publicarlas como comentarios.

Comentarios de los lectores (2)

Shaun, El backtesting es una herramienta muy fundamental en estadística. Se ha utilizado durante décadas en prácticamente todos los dominios: finanzas, meteorología, transportes, energía, … El backtesting no requiere “confianza”, es prácticamente la única metodología sólida que conocemos al evaluar la precisión de un proceso predictivo, y existe una montaña de literatura sobre el tema. Para una introducción suave, realmente deberías empezar a leer “Elements of statistical learning” Joannes Vermorel (hace 4 años)

Joannes, Esto es extremadamente interesante. Sin embargo, me estremezco al pensar en cómo se lo explicaré a los clientes. Entonces, si entiendo bien, se puede realizar backtesting en Lokad, sin embargo, si el back testing — que al leerlo es una forma de machine learning — ¿no supone un desafío significativo a la hora de explicar lo que se hizo? Si se convierte en un algoritmo avanzado, ¿no se debe básicamente confiar en que funciona? Obviamente, esto es uno de los focos principales en Lokad, así que todos ustedes allí han reflexionado mucho sobre ello. Sin embargo, creo que existe una audiencia corporativa limitada que comprende los detalles específicos de cómo funciona. ¿Entonces, Lokad se basa en los resultados de investigaciones que Lokad ha realizado en compañías anteriores, mostrando el beneficio neto de este back testing? Shaun Snapp (hace 4 años)