O Profeta do Facebook é adequado para fazer boas previsões em um projeto do mundo real?

Testamos o Prophet em um projeto real, em três aspectos principais: engenharia de recursos, interpretabilidade e uso na produção e manutenção, e aqui estão nossas conclusões:

Recentemente, um artigo apontou que o Facebook Prophet estava tendo um desempenho ruim em alguns casos extremos. De fato, esse pacote é tão popular que tende a ser considerado como a ferramenta ideal para todos os casos de uso de previsão. Isso deu início a um debate na comunidade e até mesmo seu criador reagiu.
Há muita literatura sobre como fazer uma única previsão com o Prophet. Mas há uma falta de feedback empírico sobre como ele se comporta na produção, quando você precisa fornecer previsões diariamente. Testamos e comprovamos essa ferramenta por 6 meses em um projeto comercial real. Aqui estão algumas conclusões.

Usamos o Prophet para prever a chegada de chamadas nos call centers de uma das maiores empresas de telecomunicações da Europa, a fim de otimizar a qualidade do atendimento ao cliente.

Aplicamos a estrutura GLADS para elaborar nossa abordagem data :

Uma restrição importante foi a necessidade de interpretar os resultados. Na verdade, nossas previsões são consumidas por planejadores humanos cujo objetivo é manter um SLA (X% das chamadas devem ser atendidas em um determinado período) e, ao mesmo tempo, minimizar os custos. Seu trabalho consiste em três missões:

Os principais drivers de chamada diferem de acordo com as SKUs. Por exemplo, os drivers de assistência comercial incluem:

Nossas séries temporais têm fortes sazonalidades e seguem os ciclos econômicos. Elas não são estacionárias. Nesse caso, o Prophet é uma escolha apropriada. Optamos por testá-lo, bem como outros algoritmos de ML frequentemente usados para essa tarefa.

O Prophet tem muitas vantagens inegáveis que são especialmente úteis para um projeto de previsão orientado para os negócios e que justificam plenamente sua popularidade.

Uma delas é a facilidade de uso. São necessárias apenas algumas linhas de código e quase nenhuma engenharia de recursos para ter uma boa linha de base. Para saber mais sobre como ele funciona e como usá-lo, leia este tópico do Twitter de seu criador, bem como esta excelente postagem de blog (com código).

Os recursos de tempo, como tendência e sazonalidade são criados nativamente - sem as médias móveis, defasagens e outros recursos complicados exigidos pelos modelos baseados em árvore de aprendizado de máquina (ML).

No entanto, pode ser um grande incômodo fazer o ajuste fino se vários eventos perturbarem o sinal.

Uma grande vantagem em relação aos modelos autorregressivos (por exemplo, ARIMA) é que o Prophet não exige séries temporais estacionárias: um componente de tendência é gerado nativamente.

Por esses motivos, o Prophet funciona muito bem para previsões de médio prazo (nós o testamos no horizonte M+5), embora o intervalo de confiança seja bastante grande.

A tendência pode ser estimada corretamente sem qualquer data externo (como o número de clientes). Isso é muito poderoso, pois quando você prevê a chegada de chamadas, não sabe quantos clientes terá em 5 meses, portanto, não pode usar esse recurso.
Por exemplo, este gráfico mostra o número de clientes de Internet de fibra ótica (FIO) ao longo do tempo (um mercado em crescimento para nossa empresa de telecomunicações), em comparação com o componente de tendência aprendido pelo Prophet sobre volumes de chamadas. Há uma forte correlação (coeficiente de Pearson: 0,988) entre o volume de chamadas e o número de clientes. Portanto, o modelo aprende bem a tendência, e somente a partir da própria série temporal.

Identificamos algumas dicas e truques para tornar a tendência um benefício real em sua previsão baseada em Profeta.

Um dos pontos fortes do Prophet também é um ponto fraco para a estabilidade dos resultados e do desempenho: O componente de tendência tende a explicar a grande maioria da previsão - cerca de 90% em nosso estudo de caso. Portanto, se a tendência não for bem estimada, o desempenho cairá drasticamente e você poderá perder mais de 20 pontos de MAPE ao fazer uma previsão acima ou abaixo do esperado ao longo do tempo. Você tem vários parâmetros para ajudar o Prophet a ajustar a tendência, incluindo o `changepoint_prior_scale` e o `changepoint_range`

Encontrar o valor correto de changepoint_prior_scale é essencial, pois esse parâmetro define a flexibilidade da tendência. Quanto maior ele for, mais flexível será a tendência. Nossa estratégia é fazer uma busca em grade desse parâmetro com os seguintes valores (em uma escala logarítmica): [0.001, 0.01, 0.1, 0.5]. Ter valores relativamente pequenos geralmente leva a uma melhor generalização.

Próximo ponto de atenção: por padrão, o Prophet leva em consideração apenasos primeiros 80% do histórico para aproximar a tendência, especificando 25 pontos de alteração em potencial. Descobrimos que aumentar esse valor de 80% alterando o parâmetro changepoint_range estava melhorando o desempenho. De fato, isso também levará em conta os últimos data, que são mais importantes para explicar o nível de chamadas em nosso caso. Por exemplo, neste gráfico, você pode ver que 2021 data é importante porque tem uma tendência decrescente. Optamos por levar em conta todo o conjunto de treinamento, exceto os últimos 7 dias, em vez de 80%.

Outro aspecto a ser considerado é a sensibilidade aos valores discrepantes. A documentação oficial recomenda removê-los: "O Prophet é capaz de lidar com os valores discrepantes no histórico, mas apenas ajustando-os com alterações de tendência".

Os componentes de sazonalidade, como diários e anuais, são estimados com séries de Fourier. Como nossas séries temporais têm fortes ciclos comerciais sazonais, descobrimos que o Prophet funciona muito bem.

Mas quando nos aprofundamos um pouco mais, descobrimos que a modelagem da sazonalidade semanal é limitada. Nossa série temporal apresentava valores muito baixos aos sábados em comparação com o restante da semana (e nenhum valor aos domingos). Gastamos muito tempo e tivemos muitos problemas para tentar melhorar nossas previsões nesse dia específico da semana.

Finalmente, tivemos que usar uma solução alternativa: empilhar dois modelos, incluindo o nosso modelo do Prophet e um modelo estatístico que calcula as previsões com base no peso médio dos dias da semana nas últimas seis semanas. E isso apesar de termos tentado alterar todos os parâmetros da sazonalidade semanal do Prophet.

Nosso entendimento: Em uma sazonalidade de 7 dias (6 em nosso caso, sem domingos), aumentar a ordem de Fourier não é tão útil, porque o intervalo entre 0 e 2pi é dividido em apenas alguns segmentos (6 ou 7). E uma ordem de Fourier baixa significa que não é possível ajustar valores extremos e mudanças rápidas na sazonalidade, como os sábados no exemplo acima.

Alguns outros truques para ajustar as sazonalidades:

Para eventos e extra-regressores , o Prophet também pode ser útil.

Você pode adicionar regressores adicionais, contínuos ou categóricos, fornecendo outra série temporal (valores e datas) ao modelo com o método add_regressor. Os eventos são gerenciados como regressores categóricos (o valor é 0 - o evento não está ocorrendo naquele dia ou hora - ou 1 - o evento está ocorrendo).

Adicionar novos eventos é fácil: você só precisa fornecer ao Prophet um dataframe que contenha as datas e os nomes dos eventos.
Funcionou muito bem com feriados, férias e outros eventos. E tende a dar melhores resultados do que os modelos baseados em árvore.

Além disso, o Prophet está usando o Python holidays para permitir que você use apenas a identificação do país (EUA ou FRA) para adicionar feriados relacionados como um recurso.

Como em muitos outros algoritmos de previsão de séries temporais, muitas vezes é difícil saber se um evento recorrente já está incluído na sazonalidade do profeta ou se precisa ser sinalizado manualmente para ajudar o algoritmo. Um exemplo simples é o período de Natal e Ano Novo: mesmo período, praticamente o mesmo efeito, todos os anos. Um exemplo complicado são os feriados de primavera na França. Na França, por volta de abril, há duas semanas de férias escolares com datas variáveis de ano para ano e divididas por área geográfica (nem toda a França sai de férias ao mesmo tempo).

Embora a sazonalidade anual seja baixa durante esse período, o efeito de um evento de "feriado de primavera" é positivo nas previsões de volumes de chamadas. E o modelo tem melhor desempenho com esse evento. Portanto, o efeito desse evento é inconsistente com outros feriados e com a sazonalidade que observamos, mas há um efeito sobre o treinamento e as previsões do modelo que melhora o desempenho... Devemos adicioná-lo ou não?
Observamos problemas semelhantes com vários feriados públicos que mudam todos os anos e, às vezes, tivemos de usar o Prophet com um modelo estatístico para ajustar melhor os efeitos dos feriados. No entanto, não temos nenhuma solução consistente para oferecer.

Como o Prophet é um modelo aproximadamente linear na forma como lida com recursos e eventos adicionais, o cruzamento de recursos não é automático. Isso significa que o Prophet não pode inferir que uma combinação de valores de diferentes recursos levará a um impacto exponencialmente maior ou menor na previsão, enquanto isso é algo que os algoritmos baseados em árvores e a aprendizagem profunda podem inferir muito bem.

Exemplo: digamos que você tenha um impacto em sua série temporal no Dia Útil + 1 após um feriado(HBD+1). Então, fornecer ao Prophet um evento "HBD+1" permitirá que ele se ajuste melhor a esse efeito. Mas aqui, o impacto depende muito do fato de o dia HBD+1 ser uma segunda-feira, um sábado etc. E não é linear nem multiplicativo. Portanto, você terá que adicionar todos os recursos "HBD+1_monday", "HBD+1_tuesday",...

Ao cruzar os recursos, o número deles cresce exponencialmente e , sevocê adicionar muitos desses recursos ,isso lhe custará tempo para computá-los, uma perda de interpretabilidade e, provavelmente, uma queda no desempenho.

Uma das principais vantagens do Prophet em relação a outros modelos é sua capacidade de interpretação.

A decomposição nativa da previsão em componentes de tendências, sazonalidades, eventos e extra-regressores é significativa para perfis de baixa tecnologia.

O Prophet é um modelo aditivo: a soma de cada componente é igual à previsão. A importância de cada componente é expressa diretamente na unidade de destino(ao contrário dos valores SHAP). E ele oferece explicabilidade local e global.

Consequentemente, é muito fácil plotar a previsão/impacto de cada componente na previsão. Se você optar por mudar para um modo multiplicativo, em que cada componente é expresso como uma porcentagem da tendência, terá um pouco mais de trabalho a fazer, mas continuará sendo muito fácil plotar.

Infelizmente, todos esses componentes fornecem apenas cerca de 10% da previsão, sendoos 90%restantes previstos na tendência... o que é quase inexplicável. Sua tarefa será tentar explicar a tendência usando regressores externos que não podem ser usados como recursos para o Prophet, como crescimento da base de clientes, taxas de contato e mudanças no comportamento dos clientes em nosso estudo de caso. Para isso, você precisa ter os valores reais associados a cada um desses recursos: portanto, só é possível analisar sua tendência quando você olha para as previsões feitas no passado.

O Prophet tem um bom desempenho muito rápido, em comparação com o tempo de desenvolvimento. Em outras palavras, ele oferece uma boa linha de base rapidamente, já que não é necessário criar recursos de tempo.

O Prophet possibilita a previsão de séries temporais com quase nenhuma engenharia de recursos e um bom nível de desempenho, em tempo recorde.

O treinamento é rápido: leva menos de 1 minuto por modelo, com validação cruzada, em um conjunto de dados com aproximadamente 3 anos de data em um macbook Air com chip M1 e 8 GB de memória.

Na produção, à medida que o novo data chega, você precisa reajustar o modelo. Uma forma de acelerar o treinamento é iniciar o ajuste a quente, usando os parâmetros do modelo anterior. Você também pode usar esse recurso para acelerar o processo de validação cruzada. Consulte a seção "Atualização de modelos ajustados" na documentação para saber mais.

O Prophet precisa de pelo menos dois anos de data para calcular a sazonalidade anual, mas recomendamos ter pelo menos três anos de histórico data para obter bons desempenhos.

Alcançamos um desempenho de ~15% MAPE após algumas iterações. No entanto, o ajuste fino dos resultados foi bastante desafiador e foi difícil superar esse teto. Tivemos que desenvolver algumas correções personalizadas na saída para obter um MAPE de aproximadamente 10%.

Em nosso projeto, o Prophet e o XGboost têm métricas de desempenho semelhantes nos horizontes M+1 e M+2. No entanto, os desempenhos em M+3 e M+4 tendem a se degradar mais no Prophet em comparação com o XGboost. Isso ocorre porque a tendência não foi estimada corretamente. Embora isso não afete as previsões de curto prazo, as previsões de longo prazo são muito afetadas pela direção da tendência, pois ela continua crescendo ou diminuindo ao longo do tempo, o que leva a previsões acima ou abaixo do esperado. Usar outra abordagem para previsões de longo prazo é provavelmente mais seguro.

É interessante notar que , às vezes, adicionar mais histórico data pode ser contraproducente e levar a uma queda na precisão da previsão. O Prophet não permite dar mais peso às observações mais recentes, portanto, mais data pode levar a uma diminuição da precisão da previsão.
Nesse caso, a dica seria realizar experimentos com vários comprimentos do histórico data e selecionar aquele que produz os melhores resultados.

Apesar de algumas vantagens inegáveis, o Prophet não é um modelo plug-and-play. É necessário algum tempo para ajustá-lo e aumentar o desempenho. Alguns pontos fracos tornam difícil confiar em sua estabilidade na produção.
Para avaliar a frequência com que precisaríamos treinar novamente o modelo, comparamos duas estratégias. Geramos previsões em meses diferentes e medimos os resultados:

O retreinamento do modelo a cada mês apresentou melhores resultados. Em conclusão, apesar da validação cruzada temporal, os hiperparâmetros não eram estáveis ao longo do tempo. Para o XGboost, não é necessário fazer esse retreinamento com frequência. No entanto, esses resultados devem ser tratados com cautela, pois os volumes foram afetados pela crise da COVID na época em que fizemos esse benchmark. Mais uma vez, nossa intuição para explicar o resultado foi que a tendência é difícil de estimar corretamente.

Uma das desvantagens desse modelo univariado é que você precisa de um modelo por SKU, em comparação com as abordagens baseadas em árvore, em que é possível usar o mesmo modelo para muitos produtos.

Normalmente, isso leva a melhores desempenhos, como Pierre-Yves Mousset apontou em seu projeto. Entretanto, ter muitos modelos pode ser um desafio de engenharia e um pesadelo para a manutenção.

A facilidade de uso do Profeta o tornou um modelo de linha de base muito bom quando sua série temporal se divide facilmente em componentes temporais simples. Entretanto, se o sinal for ruidoso, o ajuste fino do desempenho do modelo pode ser um incômodo.

Graças à divisão nativa da previsão em componentes de tempo, as decisões do modelo são fáceis de interpretar. No entanto, ele não é suficientemente preciso para ser usado para medir o impacto de um evento externo, pois nunca se sabe se o efeito do evento já foi levado em conta nos componentes de tempo nativos.

Se sua série temporal seguir alguns ciclos de negócios, você poderá obter um desempenho bastante decente rapidamente, sem engenharia intensiva de recursos. Entretanto, o componente de tendência nem sempre é bem estimado, o que pode gerar desvios significativos no desempenho. Por esse motivo, esse modelo pode exigir monitoramento cuidadoso e intervenções humanas frequentes.

Se você quiser oferecer alguma explicabilidade e criar um modelo decente de forma fácil e rápida, o Prophet é uma opção a ser considerada. No entanto, se você se preocupa com a estabilidade e a precisão da previsão, considere usar outro tipo de algoritmo, como modelos baseados em árvores, Orbit ou DeepAR.