El pronosticar es una actividad que hacemos constantemente en nuestra vida cotidiana, es una actividad que ha fascinado y fascina a millones de personas, como la popularidad de horóscopos y videntes deja claro, no es extraño entonces que su uso se extienda a los negocios.  La necesidad de tener una aproximación a futuro puede ser muy importante para una empresa, tanto para saber qué cantidad de inventario comprar, cuantos empleados contratar, el valor de cierto producto a determinado tiempo o muchas otras actividades.

Afortunadamente existen herramientas que nos facilitan esta tarea, algunas tan básicas como promediar nuestras observaciones o tan complejas como las muy utilizadas redes neuronales. Dichas herramientas, por muy poderosas que puedan llegar a ser, no son magia y no podrán predecir un patrón que no existe, hay que tener esto en cuenta al elegir qué queremos pronosticar y qué modelo usaremos. Habrá ocasiones que un modelo muy simple tenga un mejor rendimiento que el más complejo, justo por la razón anterior.

En este artículo usaremos Microsoft Azure Machine Learning Studio. Este servicio es una herramienta intuitiva para crear modelos Machine Learning sin necesidad de lidiar con mucho código gracias a que muchas de las trasformaciones y algoritmos usuales se pueden usar a través de una interfaz drag and drop.

El experimento se basa en modelos de series temporales (time series) que se mencionaran más adelante. Si están interesados en aprender más acerca de los conocimientos y herramientas fundamentales de Forecast el excelente libro “Forecasting: Principles and Practice” de Rob J. Hyndman y George Athanasopouloses es una buena introducción.

Necesitaremos una cuenta de Azure, se puede crear una cuenta gratuita desde este link: https://azure.microsoft.com/es-es/free/

Accedamos al Portal Azure con nuestra cuenta, el panel de la izquierda contiene la opción Create a resource, la seleccionamos y se mostrará la siguiente pantalla.

Buscaremos el recurso llamado Machine Learning Studio Workspace.

Listo, esto es lo que estábamos buscando. Vamos a crear este servicio y entremos a él en cuanto este listo para usar.

Una vez dentro de nuestro Workspace seleccionemos la opción NEW en la esquina inferior izquierda. Posteriormente buscaremos el experimento Forecasting Model for Microsoft Dynamics 365 Business Central.

Una vez dentro de nuestro Workspace seleccionemos la opcion NEW en la esquina inferior izquierda. Posteriormente buscaremos el experimento Forecasting Model for Microsoft Dynamics 365 Business Central.

Seleccionemos la opción Open in Studio para configurar el experimento, la opción View in Gallery proporciona una descripción pequeña de su uso, así como instrucciones para usar este experimento como web service o desde Dynamics 365 Business Central.

Como se puede observar el experimento tiene dos nodos donde recibe datos y dos nodos de resultados. Así como un nodo con la etiqueta GENERATE FORECAST es aquí donde se realizan las acciones principales del experimento. Si están familiarizados con el lenguaje R, este nodo permite investigar y modificar el código.

Primeramente, nuestros datos deben estar estructurados de manera que el script los pueda procesar.  Dicho modelo requiere que existan tres columnas llamadas: GranularityAtribute, TransactionQty y DateKey.

GranularityAtribute. Nos referiremos como GA de ahora en adelante, es usado para diferenciar los objetos sobre los que haremos el Forecast. Cada instancia única en GA será ajustada un modelo independiente.

DateKey. Denotado como DK, es una representación ordinal de las fechas de nuestras transacciones. En otras palabras, DK es una serie de números enteros donde cada número representa el mismo intervalo de tiempo. La siguiente tabla ejemplifica una posible implementación:

Fecha de TransacciónSept/2001Oct/2001Nov/2001Enero/2002Feb/2002Mar/2002
DateKey91011131415

Tabla 1. La elección de DateKey es arbitraria, se podría reemplazar por otros enteros (por ej. se puede remplazar estos datos con: 123,124,125,…). Nótese que ante la falta de datos del mes de diciembre se omitió el entero correspondiente a él.

TransactionQty. Denotado como TQ, es el valor de las transacciones en esa unidad de tiempo(DK). Es el valor principal sobre el cual se realizará el Forecast.

Una vez que los datos están listos, necesitamos elegir los parámetros adecuados para nuestro modelo. Dichos parámetros son horizon, seasonality, forecast_start_datekey, time_series_model, confidence_level, test_set_size_percent, missing_value_substitution.

Forecast_start_datekey. Parámetro opcional, indica el valor de DK sobre el cual se inicia la predicción. Debe de ser mayor que el valor máximo de DK. En caso de no ser proporcionado, tomara el valor máximo de DK más uno.

Horizon. Parámetro obligatorio, el número de unidades de DK que deseamos predecir iniciando con Forecast_start_datekey.

Missing_value_substitution. Parámetro opcional, indica el valor con el que TQ será sustituido en caso de que no tenga valor numérico. Si hay huecos en la serie de DK (cómo en la imagen 1) los valores de TQ en ellos serán especificados por este parámetro. En caso de no ser proporcionado, tomara el valor de 0.

Este parámetro acepta valores numéricos, así como las siguientes cadenas de texto: MEAN, PREVIOUS, INTERPOLATE LINEAR e INTERPOLATE POLYNOMIAL.

Confidence_level.  Parámetro opcional, probabilidad de que el valor real este delimitado por sigma (varianza, output del script) y el valor obtenido al predecir. En caso de no ser suministrado, se le asigna un valor de 95. Con un valor de 95, una predicción de 100 y un sigma de 20, el modelo calcula 95% de probabilidad que el valor real se encuentre entre 80 y 120.

Mientras más pequeño sea Confidence_level se le pide menos precisión así que sigma aumenta su valor, análogamente en el caso opuesto.

Seasonality. Parámetro opcional, indica la temporada o frecuencia de los datos con los que trabajamos. Al no ser suministrado, tomara valor de 1. Si cada DK representa un mes, Seasonality debe de ser 12, en caso de trimestres, sería 4.

Existe un detalle importante aquí, el script hace uso de objetos de tipo ts (time series) y asumirá que el primer valor de DK es también el primer valor de la temporada. Adelante se muestra un ejemplo de cómo funciona tomando los datos de la tabla 1:

Time Series con Seasonality de 12
EneroFebr.MarzoAbrilMayoJunioJulioAgostoSept.Oct.Nov.Dic.
20019101112131415
2002

Tabla 2. Ya que el script recibe sólo el valor de DK, no tiene manera de saber que 9 representa septiembre de 2001 y lo asigna erróneamente al primer valor del primer año, llevando a un modelo que quizá no sea óptimo. Obsérvese también la existencia del valor 12 aunque este no fue suministrado originalmente. El script llenó los huecos y el TQ de 12 tiene el valor especificado en el parámetro missing_value_substitution.

Para evitar este problema podríamos asegurarnos que los datos que suministramos sean siempre los iniciales de una temporada. Alternativamente si los datos iniciales son importantes, basta con hacer un pequeño cambio al script R que se muestra en las siguientes imágenes:

m n

En ambas imágenes se añadió “start = 9” a las correspondientes líneas de código. El valor es 9 ya que el primer valor de nuestro ejemplo es septiembre y así este será asignado a la novena posición del primer periodo. Si Seasonality fuera 3 y nuestros datos iniciaran en el segundo tercio añadiríamos “start=2”.

Test_set_size_percent. Parámetro opcional, determina el porcentaje de los datos que serán utilizados para calcular el error del modelo elegido. En caso de no ser suministrado tendrá valor de 20. Con un valor de 20, el script separará el ultimo 20% de los datos (test set) y entrenará el modelo deseado sobre el 80% restante (training set). Posteriormente usará el 20% para calcular el error, así teniendo una métrica adecuada para comparar modelos.

Time_series_model. Parámetro opcional, modelo time series que se desea usar. En caso de no recibir un valor tomara valor DEFAULT usando el modelo TBATS. El parámetro acepta los siguientes valores:

ARIMA (Autoregressive integrated moving average) Útil con datos estacionarios, es decir datos sin tendencia o temporalidad.

ETS (Error, Trend and Seasonality). Útil en datos que tengan una clara tendencia o temporalidad. Usa pesos que decaen exponencialmente con respecto al tiempo, mientras más pase el tiempo menos pesan los datos sobre el pronóstico.

STL (Seasonal and Trend decomposition using Loess). Método basado en descomponer datos en sus componentes de tendencia y temporalidad. Permite que estos tengan cambios con respecto al tiempo. La función usada es stlf() del paquete Forecast de R, esta descompone los datos y pronostica usando ETS.

TBATS (Trigonometric seasonality, Box-Cox transformation, ARMA errors, Trend and Seasonal components). Útil con datos que muestren temporalidades complejas.

ETS+ARIMA. Promedio de los valores obtenidos en ambos modelos

ETS+STL. Promedio de los valores obtenidos en ambos modelos

DEFAULT. Valor por default, el modelo usado es TBATS.

ALL. Compara el error de todos los modelos y usa aquel con valor menor.

Hemos entendido los parámetros y los datos que el script espera, ahora es importante entender que se va a hacer con ellos. Una descripción a groso modo de los procesos que realiza el script es:

  • Separa los datos suministrados con respecto a su GA.
  • Ordena y completa la serie de DK, reemplaza valores faltantes de TQ con lo establecido en los parámetros.
  • Separa los datos en un training set y test set según los parámetros suministrados, posteriormente compara los resultados obtenidos con el training set al test set y calcula el error del modelo. Si el parámetro Time_series_model tiene valor ALL, compara los valores de error y elige el modelo con menor valor.
  • Realiza el Forecast con todos los datos conforme a los parámetros dados y despliega los resultados obtenidos en dos tablas.

f8

Salida 1. Despliega las h predicciones pedidas, con h siendo el valor horizon de los parametros. El valor sigma establece un rango donde el modelo espera que el TQ real se encuentre. Mientras menor sea sigma, más preciso es el modelo.   

f9Salida 2. Indica el modelo usado así como su porcentaje de error para cada valor de GA dado. El error calculado es MAPE (Mean Absolute Percentage Error), siempre positivo y un valor menor indica un mejor modelo. Si la columna ErrorPercentage regresa un valor de -1 el modelo no se pudo ajustar a los parametros o datos dados.

Habiendo leído esto estamos listos para usar nuestros propios datos ya sea desplegando el experimento como web service y consumiéndolo desde Dynamics 365 Business Central, alguna otra aplicación o subiendo nuestros datos directamente al Workspace.

Referencias

Hyndman, R.J., & Athanasopoulos, G. (2018) Forecasting: principles and practice, 2nd edition, OTexts: Melbourne, Australia. OTexts.com/fpp2. Consultado 13/05/2019.

R Forecast Package: https://cran.r-project.org/web/packages/forecast/forecast.pdf

Forecasting Model for Microsoft Dynamics 365 Business Central: https://gallery.azure.ai/Experiment/4e9fdd573d01444c87819491e948e931

De Livera, A.M., Hyndman, R.J., & Snyder, R. D. (2011), Forecasting time series with complex seasonal patterns using exponential smoothing”. Consultado 13/05/2019. https://robjhyndman.com/papers/ComplexSeasonality.pdf