Forecast planos

Joannes Vermorel

Forecast estadístico es una ciencia contraintuitiva. Esto ya se dijo en el pasado, pero vamos a enfatizar nuevamente este punto.

Frecuentemente, recibimos solicitudes de soporte porque acaban de subir algunos datos a Lokad, y los forecast que obtienen son planos. En otras palabras, los valores forecastados son constantes para todos los periodos siguientes. Ej: valores de ventas constantes para los próximos 6 meses, si estamos considerando forecast mensual a 6 meses.

Sin embargo, es perfectamente claro que no hay manera de que las ventas del negocio sean perfectamente planas durante los próximos 6 meses, entonces, ¿por qué Lokad sigue produciendo resultados tan sin sentido?

Bueno, sabemos con certeza que el negocio va a cambiar (al menos un poco) durante los próximos seis meses. No hay duda de ello. Sin embargo, el problema es: ¿cómo podemos producir un forecast lo más cercano posible a esos cambios futuros? Si tomamos el camino estadístico, entonces necesitamos un modelo estadístico para los forecast.

El problema es que necesitamos un modelo de forecast bueno; y la regla cardinal del forecast estadístico es que cuanto más complejo es el modelo, más datos se necesitan para que el modelo sea confiable. Los modelos que producen forecast distintos para cada periodo siguiente son definitivamente más complejos que aquellos que producen el mismo valor para todos los periodos siguientes.

A la inversa, también podemos decir que esos modelos más complejos también son menos confiables en conjuntos de datos limitados, lo que significa que usarlos es muy probable que disminuya la precisión de forecast general en ciertas situaciones.

Volviendo a la situación en la que las personas se quejan de forecast planos, lo que usualmente ocurre es simplemente que los datos que acaban de subirse son ya sea muy cortos (como solo 3 meses de historial mensual) o muy escasos (como un ecommerce con solo unas pocas ventas por cada producto). En esas situaciones, Lokad frecuentemente opta por forecast planos.

No es un error, es una característica de mejora de la precisión.

Comentarios de lectores (6)

Hola Johan, la representación eficiente de series de tiempo en bases de datos relacionales es un asunto bastante complicado. En resumen, depende mucho de la duración de las series de tiempo que estés considerando. Entonces, dudo que exista algo cercano a un “Industry Standard” en esta área. Por otro lado, para el código fuente en sí, todo depende mucho de la duración y el número de series de tiempo que se están considerando. Espero que ayude. Joannes Vermorel (hace 7 años)

Estamos trabajando en un Proyecto de Series de Tiempo con una definición típica de series de tiempo y observaciones. ¿Podrías ayudar con lo siguiente:

1. ¿Tienes una estructura de Industry Standard para la definición de Time Series y la observación asociada desde la perspectiva del diseño de bases de datos.
2. ¿Cuál sería la mejor práctica en cuanto al código que representa una serie de tiempo, por ejemplo, [Level 1].[Level 2].[Sequence Number].[Version]. Cualquier orientación y ayuda será apreciada. Johan Strydom (hace 7 años)

Hola Izi, es un pensamiento interesante :-) He estado pensando en este tipo de “ataque” desde el principio, aunque no se anuncia ampliamente en nuestro sitio web. Básicamente, para hacer eso necesitarías conocer con mucha precisión los datos que tu objetivo está enviando a Lokad. Luego, también necesitas saber con gran precisión el tipo de correlaciones que estamos analizando. Los simples desplazamientos de series de tiempo no son “naturales” en los datos reales de negocio. Finalmente, te costaría algo de dinero, ya que no confiamos en los datos de usuarios que no pagan. En cuanto a nuestras técnicas, utilizamos una mezcla compleja de muchos modelos, que incluye a los clásicos bien conocidos. Este tema es obviamente un poco sensible para nosotros, pero intentaré publicar más adelante una visión general no demasiado detallada. Además, cabe señalar que aún se encuentra en rápida evolución. Joannes Vermorel (hace 9 años)

Entonces, si subo datos incorrectos, cuidadosamente elaborados para correlacionarse con un proveedor / socio que sé que utiliza tu producto, ¿puedo arruinar sus resultados? Eso es interesante, ¡y parece bastante fácil de hacer también! De lo contrario, sería bueno saber más sobre las técnicas que usas (ej: ARIMA, ANN, etc.). hace 9 años

Hola Stephen, Buena observación. El problema subyacente es que el usuario podría querer no solo los forecast en sí, sino también la justificación detrás de ellos o, al menos, un comentario. En el futuro, probablemente intentaremos mejorar las aplicaciones de cliente de Lokad con directrices automatizadas, que “comenten” los forecast entregados por Lokad. Joannes Vermorel (hace 9 años)

Hola Joannes, ¿Crees que este es un comentario útil del usuario en términos de describir lo que él espera? Potencialmente, podrías restringir al usuario para que solo se le permita realizar una tarea de forecast durante unos pocos meses, digamos 3, y si es más que esto, se le daría una advertencia sobre el efecto en la precisión de forecast. Supongo que también podría depender de la disponibilidad de los datos históricos, así que tal vez habría alguna manera de correlacionar ambos, no estoy seguro. Además, creo que desde el punto de vista de los usuarios, aunque podría ser más correcto devolverles un forecast plano, potencialmente podrían ser notificados de alguna manera sobre este caso y/o se les podría dar la opción de aceptarlo o aceptar un resultado más ingenuo? Stephen (hace 9 años)