La previsión estadística es una ciencia contra intuitiva. Esto ya se dijo en el pasado, pero vamos a enfatizar este punto nuevamente.

Con frecuencia, recibimos personas que solicitan soporte porque acaban de cargar algunos datos en Lokad y los pronósticos que obtienen son planos. En otras palabras, los valores pronosticados son constantes para todos los pasos futuros. Por ejemplo, valores de ventas constantes para los próximos 6 meses, si estamos considerando pronósticos de ventas mensuales a 6 meses de anticipación.

Sin embargo, está perfectamente claro que no hay posibilidad de que las ventas comerciales sean perfectamente planas durante los próximos 6 meses, entonces ¿por qué Lokad sigue produciendo resultados tan insignificantes?

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

El problema es que necesitamos un modelo de pronóstico bueno; y la regla cardinal de la previsión estadística es que cuanto más complejo sea el modelo, más datos se necesitan para que el modelo sea confiable. Los modelos que producen pronósticos distintos para cada paso futuro son definitivamente más complejos que los que producen el mismo valor para todos los pasos futuros.

Por otro lado, también podemos decir que esos modelos más complejos también son menos confiables en conjuntos de datos limitados, lo que significa que es muy probable que su uso disminuya la precisión de pronóstico en ciertas situaciones.

Volviendo a la situación en la que las personas se quejan de los pronósticos planos, lo que suele suceder es simplemente que los datos que se acaban de cargar son muy cortos (como solo 3 meses de historial mensual) o muy dispersos (como un comercio electrónico con solo unas pocas ventas por cada producto). En esas situaciones, Lokad frecuentemente opta por pronósticos planos.

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


Comentarios de los lectores (6)

Hola Johan, la representación eficiente de las series de tiempo en bases de datos relacionales es un asunto bastante complicado. En resumen, depende mucho de la longitud de las series de tiempo que estés considerando. Luego, dudo que exista algo cercano a un “estándar de la industria” en esta área. Nuevamente, para el código fuente en sí, todo depende mucho de la longitud y el número de series de tiempo que se estén considerando. Espero que esto ayude. Hace 7 años | Joannes Vermorel


Estamos trabajando en un proyecto de series de tiempo con una definición y observaciones típicas de series de tiempo. ¿Puedes ayudarnos con lo siguiente?

  1. ¿Tienes una estructura estándar de la industria para la definición de series de tiempo y la observación asociada desde una perspectiva de diseño de base de datos?
  2. ¿Cuál sería la mejor práctica en cuanto al código que representa una serie de tiempo, por ejemplo, [Nivel 1].[Nivel 2].[Número de secuencia].[Versión]? Cualquier orientación y ayuda será apreciada. Hace 7 años | Johan Strydom

Hola Izi, eso 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 precisión los datos que tu objetivo está enviando a Lokad. Luego, también necesitarías conocer con precisión el tipo de correlaciones que estamos analizando. Los desplazamientos simples de series de tiempo no son “naturales” en los datos comerciales reales. Por último, te costaría 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 clásicos bien conocidos. Este tema obviamente es un poco delicado para nosotros, pero intentaré publicar un resumen no demasiado detallado más adelante. Además, hay que tener en cuenta que todavía está en rápida evolución. Hace 9 años | Joannes Vermorel


Entonces, si subo datos incorrectos, cuidadosamente diseñados para correlacionar con un proveedor / socio que sé que utiliza su 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 utilizan (por ejemplo, ARIMA, ANN, etc.). Hace 9 años | Izi


Hola Stephen, Buen punto. El problema principal aquí es que el usuario podría querer no solo las previsiones en sí, sino también la justificación detrás de ellas o, al menos, un comentario. En el futuro, probablemente intentaremos mejorar las aplicaciones cliente de Lokad con pautas automatizadas que “comenten” las previsiones entregadas por Lokad. Hace 9 años | Joannes Vermorel


Hola Joannes, ¿Crees que esta es una retroalimentación útil del usuario en términos de describir lo que el usuario espera? Potencialmente, podrías restringir al usuario para que solo pueda realizar una tarea de pronóstico durante unos meses, digamos 3, y si es más que eso, se le daría una advertencia sobre el efecto en la precisión del pronóstico. Supongo que también podría depender de la disponibilidad de los datos históricos, por lo que tal vez haya alguna forma de correlacionar los dos, no estoy seguro. Además, creo que desde el punto de vista de los usuarios, aunque podría ser más correcto devolverles un pronóstico 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. Hace 9 años | Stephen