• Michel

Seleção Automática no RapidMiner (Automatic Features Selection)

O RapidMiner vem evoluindo ano após ano, sendo que neste artigo abordamos duas das mais recentes implementações que abreviam drasticamente o trabalho do Cientista de Dados, AutoModel e Automatic Feature Selection.



O RapidMiner é uma plataforma baseada em fluxo de trabalho que tenta dar a você a maior parte da flexibilidade e capacidade de programação sem precisar saber programar (codificar). Seu estilo de fluxo de trabalho é fácil de usar, arrastando e soltando ícones (drag and drop) que representam as etapas da análise. O que cada ícone faz é controlado por caixas de diálogo em vez de ter que lembrar de comandos. Certamente é preciso de muito mais tempo para aprender a programar do que para aprender uma interface de usuário de fluxo de trabalho.

O Cientista de Dados é um profissional multidisciplinar, com conhecimentos em ciência da computação, matemática, estatística e, principalmente, conhecimentos do negócio onde está inserido e nem sempre é possível e necessário dominar também linguagens de programação como Python ou R.

Por outro lado o RM não é uma plataforma de alto custo, sendo ideal para implementar os processos de Machine Learning para empresas que não desejam investir grandes recursos logo de saída.

Neste artigo usamos uma base de dados comercial em que queremos prever os valores de vendas de lojas no futuro a partir dos dados colhidos em anos anteriores.

Nossos objetivos são:

•Desenvolver um projeto do início ao final e fornecer um conjunto de previsões usando um modelo de bom desempenho.

•Explorar as funções AutoModel e Automatic Feature Selection.

•Criar várias visualizações e usar estatísticas para escolher o melhor modelo de desempenho.

Para entender este artigo você deve conhecer os fundamentos do aprendizado de máquina.

Aos que não conhecem nada do RapidMiner recomendo dar uma olhada em https://www.3dimensoes.com.br/blog/categories/rapidminer

Se você quiser um tutorial completo de como o aplicar o RapidMiner vá para https://www.youtube.com/watch?v=54CRc33WtaE


Tela típica do RapidMiner

Os dados

A origem deste banco de dados é o site de competições em Machine Learning – Kaggle. (https://www.kaggle.com/c/rossmann-store-sales)

Trata-se de uma rede de drogarias em que se deseja fazer uma previsão de vendas.

A previsão de vendas é uma tarefa comum realizada pelas organizações. Isso geralmente envolve processos manuais intensivos usando planilhas que exigem entradas de vários níveis de uma organização.

A Rossmann opera mais de 3.000 drogarias em 7 países europeus. Atualmente, os gerentes das lojas Rossmann têm a tarefa de prever suas vendas diárias com até seis semanas de antecedência. As vendas nas lojas são influenciadas por vários fatores, incluindo promoções, competição, feriados escolares e estaduais, sazonalidade e localidade. Com milhares de gerentes individuais prevendo vendas com base em suas circunstâncias únicas, a precisão dos resultados pode ser bastante variada.

Na competição você deve prever 6 semanas de vendas diárias para 1.115 lojas localizadas em toda a Alemanha. Previsões de vendas confiáveis ​​permitem que os gerentes de loja criem agendas de pessoal eficazes que aumentam a produtividade e a motivação.

Como obtivemos este banco de dados após o término da competição não foi possível avaliar a performance de nosso modelo em comparação com outros competidores, de modo que usamos somente os dados de treinamento para este artigo.


São fornecidos os dados de vendas históricos para 1.115 lojas de Rossmann. A tarefa é prever a coluna “Sales" do conjunto de testes. Um complicador é que algumas lojas no conjunto de dados foram temporariamente fechadas para reforma.

A maioria dos campos é auto-explicativa.

Id - um Id que representa um (Store, Date) dentro do conjunto de testes

Store - um ID único para cada loja

Sales - o volume de vendas para qualquer dia (target: é isso que vamos prever)

Customers - o número de clientes em um determinado dia

Open - um indicador para saber se a loja estava aberta: 0 = fechada, 1 = aberta

SchoolHoliday - indica feriado escolar

StoreType - diferencia entre 4 modelos de lojas diferentes: a, b, c, d

Assortment - descreve um nível de sortimento: a = básico, b = extra, c = estendido

CompetitionDistance - distância em metros até a loja concorrente mais próxima

CompetitionOpenSince [Month / Year] - indica o ano e mês aproximado em que o concorrente mais próximo foi aberto

Promo - indica se uma loja está executando uma promoção nesse dia

Promo2 - Promo2 é uma promoção contínua e consecutiva para algumas lojas: 0 = loja não está participando, 1 = loja está participando

Promo2Since [Year / Week] - indica o ano e a semana em que a loja começou a participar do Promo2


Os dados são divididos em dois subconjuntos:

train.csv - dados históricos, incluindo vendas

store.csv - informações complementares sobre as lojas


Tradicionalmente aplicamos as seguintes etapas em um projeto de Machine Learning.


Coleta, Exploração e Análise dos dados originais

Temos inicialmente os dois arquivos csv que importamos e fazemos uma rápida análise estatística.





Carregando e agrupando os dados

Temos que combinar os dois datasets, agregando às observaçoes as caracteristicas das lojas correspondes. Para isso usamos o operador join através de um subprocesso e salvamos o novo dataset como stores_trai_join, retratado abaixo:


Observamos as estatísticas de stores_train_join.


Veja que mantivemos o número de observações e agregamos as features (attributes) das 1.115 lojas, formando um total de 16 features.


Feature Engineering inicial

Inicialmente precisamos acertar a formatação das datas e vemos que é mais ou menos óbvio que as seguintes novas features poderão ser úteis. Fazemos isto com o operador

Generate Attributes.


1.Formatação das datas (Nominal to Date)

2.Geramos uma feature _year e um _month e concatenamos para obter o atributo _month_year

3.Geramos as features:

avg sales_by_store

avg_cust_by_store

count _store

sum_sales_by_month

avg_sales by_month

4. Juntamos todas as features em “dados_preprocessados”


Geramos mais algumas features de intervalos de tempo referentes aos períodos de existência dos concorrentes e das promoções (promo2)

_months_of_existing_comp

_months_of_existing_promo2


Temos uma nova base de dados dados_preprocessado com 21 features.



Temos um serie Temporal?

Claramente temos uma base de dados que se desenvolve no tempo. O trabalho com series temporais é muito diferente dos problemas mais tradicionais de modelagem preditiva de classificação e regressão.

A primeira coisa a fazer é verificar se os dados configuram uma serie temporal não estacionária.

Series Temporais geralmente se caracterizam por observações vizinhas serem dependentes, e temos interesse em analisar e modelar essa dependência. O objetivo na previsão de séries temporais é usar informações históricas sobre uma determinada variável para fazer previsões sobre o valor da mesma variável no futuro.

Não estamos interessados em (ou talvez nem tenhamos) outros atributos que poderiam potencialmente influenciar a variável target. Em outras palavras, variáveis independentes não são usadas.

Séries temporais são estacionárias se não tiverem efeitos de tendência ou sazonais. As estatísticas calculadas na serie temporal são consistentes ao longo do tempo, como a média ou a variância das observações, o que não acontece com series não estacionárias.

Series temporais são um capítulo à parte em Machine Learning e não abordaremos aqui. Queremos apenas saber se estamos tratando com uma série temporal ou não em nosso problema.

Observando as series abaixo “parece” que a serie da esquerda é estacionária e a da direita é claramente não estacionária.


Existem muitos métodos para verificar se uma série temporal é estacionária ou não estacionária, por exemplo,

Observando os gráficos : você pode verificar visualmente se há tendências ou sazonalidades óbvias.

Testes estatísticos : Você pode dividir sua série temporal em duas (ou mais) partições e comparar a média e a variância de cada grupo. Se diferirem e a diferença for estatisticamente significativa, a série temporal é provavelmente não estacionária.

Nossa série é apresentada no gráfico gerado no RM em que o eixo horizontal representa o tempo mês a mês e o eixo vertical as vendas mensais mensais somadas de todas as lojas.

Visualmente é difícil dizer se estamos lidando com série temporal estacionária ou não. Com certeza existe uma tendência do crescimento médio ao longo do tempo, e uma sazonalidade nos meses de dezembro (meses 11 e 23).

Porém temos uma técnica mais precisa para decidir sobre isto.

Teste de Dickey-Fuller aumentado

Testes estatísticos fazem fortes suposições sobre seus dados. Eles só podem ser usados ​​para informar o grau em que uma hipótese nula pode ser rejeitada ou não ser rejeitada. No entanto, eles podem fornecer uma verificação rápida e evidência confirmatória de que sua série temporal é estacionária ou não estacionária.

O teste Augmented Dickey-Fuller é um tipo de teste estatístico denominado teste de raiz unitária .

A intuição por trás de um teste de raiz unitária é que ele determina com que intensidade uma série temporal é definida por uma tendência.

Há um número de testes de raiz unitária e o Dickey-Fuller Aumentado é um dos mais utilizados. Ele usa um modelo auto-regressivo e otimiza um critério de informação em vários valores de defasagem diferentes.

A hipótese nula do teste é que a série temporal pode ser representada por uma raiz unitária, que não é estacionária (possui alguma estrutura dependente do tempo). A hipótese alternativa (rejeitando a hipótese nula) é que a série temporal é estacionária.

Hipótese Nula (H0) : Se não foi rejeitada, sugere que a série temporal tenha uma raiz unitária, o que significa que é não-estacionária. Tem alguma estrutura dependente do tempo.

Hipótese Alternativa (H1) : A hipótese nula é rejeitada; sugere que a série temporal não possui raiz unitária, o que significa que é estacionária. Não tem estrutura dependente do tempo.

Nós interpretamos esse resultado usando o valor p do teste. Um valor p abaixo de um limiar (como 5% ou 1%) sugere que rejeitemos a hipótese nula (estacionária), caso contrário, um valor p acima do limiar sugere que não rejeitamos a hipótese nula (não estacionária).

p-value > 0,05 : falha ao rejeitar a hipótese nula (H0), os dados têm raiz unitária e são não-estacionários.

p-value <= 0.05 : Rejeita a hipótese nula (H0), os dados não possuem raiz unitária e são estacionários.

Mas no RM não encontramos um operador para realizar este teste. Então apelamos para o python.

Executando o teste o valor da estatística ADF é de -4,735393. Quanto mais negativa essa estatística, é mais provável que devemos rejeitar a hipótese nula.

Podemos ver que nosso valor da estatística de -4 é menor que o valor de-3.670 em 1%. Isto sugere que podemos rejeitar a hipótese nula com nível de significância de menos de 1% (ou seja, uma baixa probabilidade que o resultado é uma casualidade estatística). Rejeitar a hipótese nula significa que o processo não tem nenhuma raiz da unidade e em vez que a série é estacionária ou não tem estrutura dependente do tempo.


Antes de partir para a modelagem temos ainda duas considerações. Primeiro removemos somente os features que não usaremos e depois substituímos os valores faltantes conforme indicado na coluna "Selected Attributes" onde estão listadas as features retiradas.

Note as features retiradas são aquelas que foram substituídas por outras quando criamos novas features acima.



Data Leakage

Mas ainda temos um outro detalhe para atentar.

Note na figura anterior que retiramos dos dados a feature “Customers”, porque claramente se trata do que chamamos de vazamento de dados.

O vazamento de dados (Data Leakage) é um grande problema no aprendizado de máquina ao desenvolver modelos preditivos.

O vazamento de dados ocorre quando as informações que de fato não são disponíveis no momento do treinamento são usadas para criar o modelo. Essa informação adicional pode permitir que o modelo aprenda ou saiba algo que de outra forma não conheceria e, por sua vez, invalidaria o desempenho estimado do modo que está sendo construído. No nosso caso o número de clientes num determinado dia e numa dada loja (Customers) não é conhecido antecipadamente pelo analista, e portanto não pode ser usado na análise. Por outro lado, o número médio de clientes por mês “ave_Cust” é conhecido e pode ser usado.

Um sintoma de que você tem vazamento de dados é se estiver obtendo um desempenho que parece bom demais para ser verdade, geralmente indicado por uma alta correlação entre a variável target e uma das variáveis independentes.


Treinamento

Vimos que podemos tratar os dados como uma serie estacionária, o que significa usar os algoritmos convencionais de Machine Learning.

Salientamos que o ADF é um teste complexo e de fato estamos apenas mostrando o que fazer com seu resultado e não como ele funciona. Na prática seria uma boa ideia explorar melhor o resultado do teste de estacionaridade pois de fato vemos uma certa tendência na curva, ou seja, talvez devêssemos considerar algum componente de não-estacionaridade em nosso modelo. Para simplificar vamos simplesmente desprezar esta possibilidade.

1ª parte - Treinamento com todas as features

Agora passamos a fase de treinamento, mas primeiro vamos separar um conjunto de teste que ficará intacto e reservado para validação do modelo no final (30% dos dados escolhidos aleatoriamente). Na primeira parte da análise usaremos todas as features e na 2ª parte usaremos apenas as features selecionadas pelo Automated Feature Engineering.


Vamos usar uma função recentemente incorporada ao RM chamada Auto Model.

O RapidMiner Auto Model acelera o trabalho que os cientistas de dados tem ao criar modelos de aprendizado de máquina.

Ao contrário das abordagens de aprendizado de máquina automatizadas existentes, o Auto Model não é uma “caixa preta” que impede que os cientistas de dados compreendam como o modelo funciona. O Auto Model gera um processo do RM nos bastidores, para que os cientistas de dados possam ajustar e testar os modelos antes de colocá-los em produção.

Para mais informações sobre como começar a usar o RapidMiner Auto Model, visite: https://www.3dimensoes.com.br/blog/previs%C3%A3o-de-vendas-em-supermercados-usando-rapidminer

Performance dos modelos

Abaixo os resultados utilizando vários modelos usando as métricas RMSE e R^2.


Agora podemos ver a performance de cada modelo no set de treinamento, bem como o tempo de processamento.

Note que este resultado embute a operação de cross-validation no set de treinamento.

As melhores performances foram dos algoritmo Gradient Boosted Trees e Deep Learning.

A importância de cada feature é correspondente ao seu peso. Vemos que oa feature mais importante é “average(Sales)” ( a soma mensal das vendas por loja) seguida por “DayOfWeek”.

Podemos também verificar que existem baixas correlações entre as variáveis.


Os parâmetros ótimos do modelo Gradient Boosted Trees fornecidos pelo AutoModel estão a seguir.



Os parâmetros ótimos do modelo Deep Learning fornecidos pelo AutoModel são:


Stacking

Como último passo aplicamos o operador stacking que combina os melhores modelos. Usamos os dois melhores modelos – Deep Learning e Gradient Boosted Trees, sendo que o algoritmo Generalized Linear Model faz a melhor escolha a cada observação.


O modelo gerado pelo stacking é então aplicado ao set de Teste



Resultados

Obtemos um RMSE de 2449 e R^2 de 0.829.


O gráfico de Sales x Prediction(sales) parece razoável, porém constatamos com distorções em casos em que Sales = 0, que seria perfeitamente contornável, por exemplo eliminando estes casos da base de dados e nos pontos azuis e vermelhos que representam 2ªf e domingo.


2ª parte - Automated Feature Engineering

Feature Engineering é uma técnica para extrair o máximo potencial dos dados para modelos preditivos. Suas principais formas de aplicação são a redução do número de features através da avaliação do peso de cada uma e daquelas que apresentam apenas ruído, e, a geração de novas features através da combinação de features existentes.

Feature Engineering é uma técnica mas também é uma arte. É considerada a mais importante etapa no aprendizado de máquina podendo fazer a diferença entre um modelo bom e um modelo ruim.

Automated Feature Engineering é um tema quente atualmente, algoritmos Deep Learning fazem este trabalho automaticamente, porém requer-se considerável capacidade de processamento e ainda poucas empresas começaram a trabalhar nisso.

Vamos agora proceder a análise das features usando o Automatic Feature Selection.

Essa função é um processo totalmente automático de seleção das melhores features e ainda pode gerar novas features. Em nosso exemplo não usaremos a geração de novas features.

Escolhemos o algoritmo Gradient Boosted Trees para esta análise sendo que o RM aplica um processo de otimização evolucionário para encontrar os melhores conjuntos de features. Cada conjunto de features busca otimizar a relação complexidade versus erro do modelo.

As figuras a seguir mostram o resultado seleção de features. Cada ponto representa um diferente subconjunto das features originais e podem incluir algumas features recém-criadas no caso de geração de novas features.

Os melhores conjuntos de features são os que aparecem no canto inferior esquerdo com baixa complexidade e taxas de erro baixa. Note que geralmente não é possível minimizar a complexidade sem aumentar a taxa de erro.

Nas figuras abaixo, vemos que somente usando a feature a DayOfWeek , temos uma complexidade de 1 e atingimos uma taxa de erro acima de 3%. Note que esta taxa de erro é a taxa de erro no set de treinamento. O erro no set de teste será maior do que isso e é mostrado nas abas de Performance e Visão geral do modelo.



Usando as 3 features abaixo diminuímos o erro para 2,15% às custas de um aumento na complexidade.


Já com 4 features conseguimos o menor erro.


O resultado com o uso de todas as features é igual ao do resultado com apenas 4 features.

Aplicamos agora somente o Gradient Boosted Trees ao set de Teste, e obtemos resultados semelhantes aos dos modelos usando todas as features como pode ser visto nas figuras seguintes.




3 Dimensões

Inteligência Artificial nas Empresas

Al. das Papoulas, 147 - Santana de Parnaíba - Alphaville, SP 06539-180 - (11) 4153 6004  - (11) 9 9795 9765

michel@3dimensoes.com.br