Previsão do tempo de Natal-RN utilizando LSTM — Parte 3/3

Modelo, discussões e projetos futuros

Dando seguimento ao projeto, nesse artigo irei apresentar o modelo final, apresentar os resultados, debate-los e fazer apontamentos para projetos futuros.

Artigos anteriores:

• Parte 1 — Entendendo o contexto e o desafio;
• Parte 2 — Coleta e tratamentos dos dados.

O que queremos prever?

Como foi dito no artigo anterior, nós queremos prever os valores da coluna temperature_air_dry_bulb, que diz respeito a temperatura do ar do bulbo seco em graus (ºC) no horário em que ocorreu a medição.

Além disso, queremos prever os valores das próximas 12 horas utilizando os dados das 32 horas anteriores.

Testes

Para encontrar o melhor modelo, alternou-se os valores das seguintes configurações:

• Epochs: 100, 300 e 500, nesse último não teve testes finalizados.
• Batch size: 32, 64 e 128.
• Camadas LSTM: 2 a 5 camadas, nesse último não teve testes finalizados.
• Camadas Dropout: 3 a 6 camadas, nesse último não teve testes finalizados. Além disse utilizou-se os valores 0.2 e 0.3.
• Dense: testou-se previsões de 3, 6, 9 e 12 horas.

Problemas enfrentados

Vários problemas ocorreram durante o decorrer desse projeto. Inicialmente a questão era poder computacional, rodar os scripts de treinamento na minha máquina demorava muito tempo até em alguns modelos de LSTM pouco complexos, por isso optou-se por usar o Google Colab.

Após isso, o principal problema enfrentado foi a conexão de internet, pois se a internet caísse e demorasse alguns minutos para voltar, já era o suficiente para o kernel do Colab ser reiniciado e todas as horas de treinamento serem perdidas.

Esse problema com a internet impediu, por exemplo, de testar os modelos com os parâmetros que tornavam o treinamento mais demorado. Os treinamentos com 500 épocas eram os melhores candidatos para o melhor modelo, sendo que nunca foram finalizados pois demoravam várias horas ou até dias e a internet sempre caia em algum momento, impedindo assim de realizar as previsões.

Arquitetura

Irei explicar brevemente os componentes usados na arquitetura final do modelo desse projeto:

• Bidirectional: para garantir que as informações da parte anterior da sequência estejam disponíveis para a parte posterior e vice-versa.
• LSTM (4x): o valor 32 no parâmetro units representa o conjunto de dados históricos na janela de 32 horas. O parâmetro return_sequences especifica que cada saída da unidade será usada como entrada da próxima camada.
• Dropout (5x): serve para regularizar os efeitos e evitar que a rede se adapte ao conjunto de treinamento.
• Dense: com 12 neurônios de previsão, onde cada um representa uma hora no futuro.

Você pode ver melhor como ficou a organização da arquitetura na imagem a seguir:

Arquitetura do melhor modelo até o momento.

Resultados

O modelo descrito anteriormente foi o que apresentou o melhor resultado:

Resultado final do treinamento do modelo.

Uma acurácia de 0.6844, muito longe do desejado e indo até pior do que alguns resultados no trabalho anterior que utilizou modelos não propícios a dados seriais. Podemos ver isso mais claramente nos valores previstos:

Valores previstos e reais para os 12 dias futuros.

Trabalhos futuros

Para os trabalhos futuros, eu gostaria de conseguir realizar os treinamentos que não consegui finalizar, como também testar com novas configurações.

Gostaria também de ter usado mais dados, além de usar dados de outras estações e não apenas de Natal-RN.

Seria interessante testar outros modelos, como Hidden Markov Model (HMM) ou Recurrent Neural Network (RNN). Combinar modelos talvez fosse uma abordagem interessante, visto que podemos também usar imagens de satélites para prever o tempo.

Código

• Modelos: https://github.com/alvarofpp/imd1104-weather-forecasting

Esse artigo foi escrito para a disciplina de Aprendizado Profundo do curso de Bacharelado em Tecnologia da Informação (BTI) da Universidade Federal do Rio Grande do Norte (UFRN), possuindo Ivanovitch Silva como professor.