¿Es Facebook Prophet adecuado para hacer buenas predicciones en un proyecto del mundo real?

Hemos probado Prophet en un proyecto real, en 3 aspectos principales: ingeniería de características, interpretabilidad y uso en producción y mantenimiento, y aquí están nuestras conclusiones:

Hace poco, un artículo señalaba que Facebook Prophet no funcionaba bien en algunos casos extremos. De hecho, este paquete es tan popular que tiende a considerarse LA herramienta a la que acudir para cualquier caso de uso de previsión. Esto suscitó un debate en la comunidad e incluso su creador reaccionó.
Existe mucha literatura sobre cómo hacer una previsión única con Prophet. Pero falta información empírica sobre cómo se comporta en producción, cuando es necesario realizar previsiones a diario. Hemos probado esta herramienta durante 6 meses en un proyecto empresarial real. He aquí algunas conclusiones.

Utilizamos Prophet para prever la llegada de llamadas en los centros de atención telefónica de una de las mayores empresas de telecomunicaciones de Europa, con el fin de optimizar la calidad del servicio al cliente.

Aplicamos el marco GLADS para elaborar nuestro enfoque data :

Una limitación importante era la necesidad de interpretar los resultados. En efecto, nuestras predicciones son consumidas por planificadores humanos cuyo objetivo es mantener un SLA (X% de las llamadas deben ser atendidas en un periodo determinado) minimizando los costes. Su trabajo consta de 3 misiones:

Los controladores de llamadas principales difieren en función de las SKU. Por ejemplo, los controladores de asistencia comercial incluyen:

Nuestras series temporales presentan fuertes estacionalidades y siguen los ciclos económicos. No son estacionarias. En este caso, Prophet es una opción adecuada. Decidimos probarlo, así como otros algoritmos de ML utilizados frecuentemente para esta tarea.

Prophet tiene muchas ventajas innegables que son especialmente útiles para un proyecto de previsión orientado a la empresa, y que justifican plenamente su popularidad.

Una de ellas es su facilidad de uso. Sólo se necesitan unas pocas líneas de código y casi nada de ingeniería de funciones para tener una buena línea de base. Para saber más sobre cómo funciona y cómo utilizarlo, lee este hilo de Twitter de su creador, así como esta excelente entrada de blog (con código).

Las características temporales, como la tendencia y la estacionalidad , se crean de forma nativa, sin las medias móviles, los retardos y otras características complicadas que requieren los modelos basados en árboles de aprendizaje automático (ML).

Sin embargo, puede ser bastante complicado afinar si varios eventos perturban la señal.

Una gran ventaja frente a los modelos autorregresivos (por ejemplo, ARIMA) es que Prophet no requiere series temporales estacionarias: se genera un componente de tendencia de forma nativa.

Por estas razones, Prophet funciona bastante bien para predicciones a medio plazo (lo probamos en el horizonte M+5), aunque el intervalo de confianza es bastante amplio.

La tendencia puede estimarse correctamente sin ningún data externo (como el número de clientes). Esto es bastante potente, porque cuando se predice la llegada de llamadas, no se sabe cuántos clientes habrá dentro de 5 meses, por lo que no se puede utilizar esta función.
Por ejemplo, este gráfico muestra el número de clientes de Internet de fibra óptica (FIO) a lo largo del tiempo (un mercado en crecimiento para nuestras telecomunicaciones Compañia), comparado con el componente de tendencia aprendido por Prophet sobre los volúmenes de llamadas. Existe una fuerte correlación (coeficiente de Pearson: 0,988) entre el volumen de llamadas y el número de clientes. Así pues, el modelo aprende bien la tendencia, y sólo a partir de la propia serie temporal.

Hemos identificado algunos consejos y trucos para convertir la tendencia en una ventaja real en sus previsiones basadas en Prophet.

Uno de los puntos fuertes de Prophet es también un punto débil para la estabilidad de los resultados y el rendimiento: El componente de tendencia tiende a explicar la gran mayoría de la predicción, alrededor del 90% en nuestro caso de estudio. Por lo tanto, si la tendencia no está bien estimada, el rendimiento se reducirá drásticamente y se pueden perder más de 20 puntos de MAPE por exceso o defecto de predicción a lo largo del tiempo. Dispone de varios parámetros para ayudar a Prophet a ajustar la tendencia, incluidos `changepoint_prior_scale` y `changepoint_range`.

Encontrar el valor correcto de changepoint_prior_scale es esencial, porque este parámetro establece la flexibilidad de la tendencia. Cuanto más alto sea, más flexible será la tendencia. Nuestra estrategia consiste en buscar en la cuadrícula este parámetro con estos valores (en escala logarítmica) [0.001, 0.01, 0.1, 0.5]. Si los valores son relativamente pequeños, la generalización será mejor.

Siguiente punto de atención: por defecto, Prophet sólo tiene en cuentael primer 80% del historial para aproximar la tendencia especificando 25 puntos de cambio potenciales. Hemos comprobado que aumentar este valor del 80% cambiando el parámetro changepoint_range mejoraba el rendimiento. De hecho, esto también tendrá en cuenta los últimos data, que son más importantes para explicar el nivel de llamadas en nuestro caso. Por ejemplo, en este gráfico se puede ver que 2021 data es importante porque tiene una tendencia decreciente. Hemos optado por tener en cuenta todo el conjunto de entrenamiento excepto los últimos 7 días en lugar del 80%.

Otra cosa a tener en cuenta es la sensibilidad a los valores atípicos. La documentación oficial recomienda eliminarlos: "Prophet es capaz de manejar los valores atípicos en el historial, pero sólo ajustándolos con cambios de tendencia".

Los componentes de estacionalidad, como el diario y el anual, se estiman con series de Fourier. Como nuestras series temporales tienen fuertes ciclos económicos estacionales, comprobamos que Prophet funciona bastante bien.

Pero cuando profundizamos un poco, descubrimos que la modelización de la estacionalidad semanal es limitada. Nuestra serie temporal tenía sábados muy bajos en comparación con el resto de la semana (y ningún valor los domingos). Pasamos mucho tiempo y tuvimos muchos problemas intentando mejorar nuestras predicciones sobre este día concreto de la semana.

Al final tuvimos que recurrir a una solución alternativa: apilar dos modelos, incluido nuestro modelo de Prophet y un modelo estadístico que calcula las predicciones basándose en el peso medio de los días de la semana en las últimas 6 semanas. Y ello a pesar de haber intentado cambiar todos los parámetros de la estacionalidad semanal de Prophet.

A nuestro entender: En una estacionalidad de 7 días-periodo (6 en nuestro caso sin domingos), Aumentar el orden de Fourier no es tan útil, porque el intervalo entre 0 y 2pi sólo se divide en unos pocos segmentos (6 ó 7). Y un orden de Fourier bajo significa que no puede ajustarse a valores extremos y cambios rápidos de estacionalidad, como los sábados en el ejemplo anterior.

Algunos otros trucos para afinar las estacionalidades:

Para eventos y extra-regresores también Profeta puede ser útil.

Puede añadir regresores adicionales, ya sean continuos o categóricos, proporcionando otra serie temporal (valores y fechas) al modelo con el método add_regressor. Los eventos se manejan como regresores categóricos (el valor es 0 - el evento no está ocurriendo en ese día u hora - o 1 - el evento está ocurriendo).

Añadir nuevos eventos es fácil: basta con proporcionar a Prophet un marco de datos que contenga las fechas y los nombres de los eventos.
Funciona bastante bien con días festivos, vacaciones y otros eventos. Y suele dar mejores resultados que los modelos basados en árboles.

Además de eso, Prophet está utilizando el programa Python días festivos para permitirte utilizar sólo el id del país (USA o FRA) para añadir días festivos relacionados como una característica.

Como ocurre con muchos otros algoritmos de predicción de series temporales, a menudo es difícil saber si un acontecimiento recurrente ya está incluido en la estacionalidad de prophet o si hay que marcarlo manualmente para ayudar al algoritmo. Un ejemplo sencillo es el periodo de Navidad y Año Nuevo: el mismo periodo, aproximadamente el mismo efecto, todos los años. Un ejemplo complicado son las vacaciones francesas de primavera. En Francia, en torno al mes de abril, hay dos semanas de vacaciones escolares con fechas variables de un año a otro y divididas por zonas geográficas (no toda Francia se va de vacaciones al mismo tiempo).

Aunque la estacionalidad anual es baja durante este periodo, el efecto de un evento de "vacaciones de primavera" es positivo en las predicciones de volúmenes de llamadas. Y el modelo funciona mejor con este acontecimiento. Así pues, el efecto de este evento es incoherente con otros días festivos y con la estacionalidad que observamos, pero tiene un efecto en el entrenamiento del modelo y en las predicciones que mejora el rendimiento... ¿Deberíamos añadirlo o no?
Observamos problemas similares con varios días festivos que se desplazan cada año, y a veces tuvimos que apilar Prophet con un modelo estadístico para ajustar mejor los efectos de los días festivos. Sin embargo, no tenemos ninguna solución coherente que ofrecer.

Como Prophet es un modelo aproximadamente lineal en la forma en que maneja las características adicionales y los eventos, el cruce de características no es automático. Esto significa que Prophet no puede inferir que una combinación de valores de diferentes características tendrá un impacto exponencialmente mayor o menor en la predicción, mientras que es algo que los algoritmos basados en árboles y Deep Learning pueden inferir muy bien.

Ejemplo: digamos que tiene un impacto en su serie temporal en el Día Hábil + 1 después de un festivo(HBD+1). Entonces, dotar a Prophet de un evento "HBD+1" le permitirá ajustarse mejor a este efecto. Pero en este caso, el impacto depende en gran medida de si el día HBD+1 es un lunes, un sábado, etc. Y no es lineal ni multiplicativo. De ahí que tenga que añadir todas las funciones "HBD+1_monday", "HBD+1_tuesday",...

Al cruzar características, su número crece exponencialmente y le va a costar tanto tiempo calcularlas como una pérdida de interpretabilidad y, probablemente, un descenso del rendimiento siañade demasiadas de estas características.

Una de las principales ventajas de Prophet sobre otros modelos es su interpretabilidad.

La descomposición nativa de la previsión en componentes de tendencia, estacionalidad, eventos y extra-regresores es significativa para perfiles de baja tecnología.

Prophet es un modelo aditivo: la suma de cada componente es igual a la predicción. La importancia de cada componente se expresa directamente en la unidad objetivo(a diferencia de los valores SHAP). Y proporciona una explicabilidad tanto local como global.

Por consiguiente, es realmente fácil trazar la predicción / el impacto de cada componente en la previsión. Si opta por un modo multiplicativo, en el que cada componente se expresa como porcentaje de la tendencia, tendrá que trabajar un poco más, pero el gráfico seguirá siendo muy sencillo.

Lamentablemente, todos estos componentes sólo proporcionan alrededor del 10% de la predicción, el 90%restante se predice en la tendencia... que es casi inexplicable. Su trabajo consistirá en intentar explicar la tendencia utilizando regresores externos que no puede utilizar como características para Prophet, como el crecimiento de la base de clientes, las tasas de contacto y los cambios en los comportamientos de los clientes para nuestro caso de estudio. Para ello, es necesario disponer de los valores reales asociados a cada una de estas características: de ahí que sólo sea posible analizar la tendencia si nos remontamos a las predicciones realizadas en el pasado.

Profeta tiene muy rápidamente un buen rendimiento, en comparación con el tiempo de desarrollo. En otras palabras, Servicios una buena línea de base rápidamente, ya que no tiene que elaborar características de tiempo.

Prophet permite predecir series temporales sin apenas ingeniería de características y con un buen nivel de rendimiento, en un tiempo récord.

Se entrena rápido: tarda menos de 1 minuto por modelo, con validación cruzada, en un conjunto de datos con ~3 años de data en un macbook Air con chip M1 y 8 Go de memoria.

En la producción, a medida que llega la nueva data , es necesario volver a ajustar el modelo. Una forma de acelerar el entrenamiento es iniciar en caliente el ajuste, utilizando los parámetros del modelo anterior. También puede utilizar esta función para acelerar el proceso de validación cruzada. Para más información, consulta la sección "Actualización de modelos ajustados" de la documentación.

Prophet necesita al menos dos años de data para calcular la estacionalidad anual, pero recomendamos disponer de al menos 3 años de data históricos para obtener buenos resultados.

Alcanzamos un rendimiento de ~15% MAPE tras unas cuantas iteraciones. Sin embargo, el ajuste fino de los resultados fue todo un reto y resultó difícil superar este límite. Tuvimos que desarrollar algunas correcciones personalizadas en la salida para lograr un ~10% MAPE.

En nuestro proyecto, Prophet y XGboost tienen métricas de rendimiento similares en los horizontes M+1 y M+2. Sin embargo, el rendimiento en M+3 y M+4 tiende a degradarse más en Prophet que en XGboost. Sin embargo, el rendimiento en M+3 y M+4 tiende a degradarse más en Prophet que en XGboost. Esto se debe a que la tendencia no se estimó correctamente. Aunque no afecta a las predicciones a corto plazo, las predicciones a largo plazo se ven muy afectadas por la dirección de la tendencia, ya que sigue creciendo o disminuyendo con el tiempo, lo que lleva a una predicción por exceso o por defecto. Probablemente sea más seguro utilizar otro enfoque para las previsiones a largo plazo.

Curiosamente, a veces añadir más data históricos puede ser contraproducente y provocar un descenso de la precisión de las previsiones. Prophet no permite dar más peso a las observaciones más recientes, por lo que más data puede conducir a una disminución de la precisión de la previsión.
En este caso, el consejo sería realizar experimentos con varias longitudes de data históricas y seleccionar la que arroje mejores resultados.

A pesar de algunas ventajas innegables, Prophet no es un modelo plug-and-play. Requiere cierto tiempo para ponerlo a punto y aumentar su rendimiento. Algunos puntos débiles hacen difícil confiar en su estabilidad en producción.
Para evaluar la frecuencia con la que tendríamos que volver a entrenar el modelo, comparamos dos estrategias. Generamos previsiones para distintos meses y medimos los resultados:

Reentrenar el modelo cada mes dio mejores resultados. En conclusión, a pesar de la validación cruzada temporal, los hiperparámetros no eran estables a lo largo del tiempo. En el caso de XGboost no es necesario realizar este reentrenamiento con frecuencia. Sin embargo, estos resultados deben tomarse con cautela, ya que los volúmenes se vieron afectados por la crisis de COVID en el momento en que realizamos esta comparativa. También en este caso nuestra intuición para explicar el resultado fue que la tendencia es difícil de estimar correctamente.

Uno de los inconvenientes de este modelo univariante es que se necesita un modelo por SKU, en comparación con los enfoques basados en árboles, en los que se puede utilizar el mismo modelo para muchos productos.

Suele dar lugar a mejores prestaciones, como señaló Pierre-Yves Mousset en su proyecto. Sin embargo, tener muchos modelos puede ser un reto de ingeniería y una pesadilla de mantener.

La facilidad de uso de Prophet lo convierte en un modelo de referencia muy bueno cuando las series temporales se descomponen fácilmente en componentes temporales simples. Sin embargo, si la señal es ruidosa, ajustar el rendimiento del modelo puede resultar complicado.

Gracias al desglose nativo de la previsión en componentes temporales, las decisiones del modelo son fáciles de interpretar. Sin embargo, no es lo bastante preciso para medir el impacto de un acontecimiento externo, porque nunca se sabe si el efecto del acontecimiento ya se ha tenido en cuenta en los componentes temporales nativos.

Si su serie temporal sigue algunos ciclos económicos, puede obtener un rendimiento muy decente rápidamente, sin una ingeniería de características intensiva. Sin embargo, el componente de tendencia no siempre se estima bien, lo que puede generar desviaciones significativas en el rendimiento. Por esta razón, este modelo puede requerir un seguimiento cuidadoso y frecuentes intervenciones humanas.

Si lo que quieres es ofrecer cierta explicabilidad y construir un modelo decente de forma fácil y rápida, Prophet es una opción a tener en cuenta. Sin embargo, si lo que te importa es la estabilidad y la precisión de las previsiones, considera la posibilidad de utilizar otro tipo de algoritmo, como los modelos basados en árboles, Orbit o DeepAR.