Basket Analysis usando análise preditiva – Apriori

Uma das razões principais para a criação do HANA Brasil era a oportunidade de falar sobre Análise Preditiva (principalmente mas não somente no ecossistema SAP). Nossa intenção não é ser superficial neste assunto, por isso neste post você será inundado de informações práticas de como criar uma aplicação em HANA usando Análise Preditiva em carrinho de compras através da biblioteca PAL.

Espere um tutorial fim a fim falando de conceitos, modelagens, front end e back end. Não espere passo a passo de detalhes como a criação de artefatos no HANA.

Demo – Basket Analysis usando HANA PAL

A aplicação que mostraremos foi demonstrada no SAP Inside Track São Paulo 2014 como parte da palestra de Machine Learning por Bruno @Lucattelli e @FabioPagoti (quem escreve este post). Você pode conferir a palestra na íntegra abaixo. A demonstração da aplicação abordada neste post começa a partir do minuto 34:55.

Outro vídeo de demonstração da aplicação pode ser visto abaixo (não há audio).

Basket Analysis

Basket analysis é um exemplo de aplicação de Affinity analysis para fins de retail. O propósito dela é descobrir se há relação na venda entre produtos num carrinho de compras. Mas com qual finalidade?

Veja um exemplo: Suponha que você tenha um mercado. É razoável se pensar que a venda de pão está associado a venda de manteiga. Também é razoável pensar que a venda de manteiga está associada a venda de ovos, e que a venda de ovos por sua vez está associada a venda de açúcar. Mas será que estas relações são verdadeiras? Será que elas não acontecem por mero acaso? Será que a venda de amaciante também pode estar de alguma forma associada com a venda de repelentes? Qual destas relações é mais verdadeira ou todas tem o mesmo “peso”? Será que quando o meu estoque de ovos acabar eu também deveria encomendar mais manteiga? Será que fazendo uma promoção dos ovos eu acabo vendendo mais açúcar, no qual minha margem é maior? Será que se eu aproximar as gôndolas de farinha e ovos a venda de ambos não acabam crescendo?

São todas ótimas perguntas. Respondê-las para todas as combinações de produtos que um mercado trabalha certamente não é uma boa tarefa a se delegar para um grupo de humanos. A menos que eles tenham o auxílio de algum bom sistema de análise preditiva, por mais competentes que eles sejam esta análise levaria muito tempo.

A Basket Analysis usa simplesmente a relação das vendas de um estabelecimento para construir em termos numéricos o grau de associação entre os diferentes produtos em um carrinho de compras.

Modelando um simples cenário no SAP Predictive Analysis

Vamos usar o SAP Predictive Analysis para entender um pouco como será o processo de descobrimento das associações entre produtos. Você pode baixar gratuitamente uma versão trial do SAP Predictive Analysis válida por 30 dias.

Dataset

Temos o seguinte dataset:

Apenas com estas 2 colunas é possível realizar uma basket analysis. Temos o ID de uma transação, que podemos entender como uma compra no supermercado, e o ID do produto ou material, que representa o que está sendo comprado. Para fins didáticos, o nome do material é único na base inteira. No caso do SAP seria razoável usar o MATNR (código do material) para este fim.

Pré-Processamento

É importante notar também que não deve haver registros duplicados no dataset. Logo, caso a base seja extraída do SAP isso deve ser tratado visto que uma venda pode ter 2 ou mais itens com o mesmo material no caso do módulo de SD na tabela VBAP.

SAP Predictive Analysis

Tendo o dataset pronto podemos realizar o processo de descobrimento localmente, visto que o dataset é pequeno. Usaremos o SAP Predictive Analysis com o R instalado e devidamente configurado para rodar um algoritmo de associação na nossa base.

O primeiro passo é criar um nova análise importando um dataset.

Criando uma nova análise no SAP Predictive Analysis

Criando uma nova análise no SAP Predictive Analysis

Nosso simples dataset está num formato .csv. Poderíamos fazer alguns ajustes no formatação de colunas se fosse necessário.

Importando o dataset em formato .csv

Importando o dataset em formato .csv

Uma vez que tenhamos o dataset importado, podemos iniciar um processo de descoberta de informação nos dados. É verdade que poderíamos fazer algum tipo de análise prévia num outro software como o excel, mas o SAP Predictive Analysis facilita bastante este trabalho também. Na imagem abaixo podemos ver que no nosso dataset não há nenhuma compra com mais de 3 itens. Também podemos ver que a Manteiga é o produto mais presente nas compras (não necessariamente o mais comprado visto que o nosso dataset não contempla a quantidade do material que foi adquirido). Por exemplo, a Farinha pode estar presente apenas em duas transações mas em apenas uma delas o cliente pode ter comprado 30 sacos de farinha. Logo a quantidade de produtos refere-se a aparições ou presenças nas transações.

Primeiras análises em cima do dataset

Primeiras análises em cima do dataset

Vamos para a aba “Predict” onde podemos fazer uma modelagem para predição. No caso, como nosso dataset já foi pré-processado antes de ser importado no SAP Predictive Analysis, simplesmente executaremos o algoritmo Apriori (baseado em R) diretamente após a leitura do dataset.

Modelando a predição usando o algoritmo Apriori em R

Modelando a predição usando o algoritmo Apriori em R

Fazemos então a parametrização do algoritmo. No caso identificamos qual a coluna de item e qual a coluna de transação. O Apriori é um algoritmo de associação que precisa apenas destas duas informações para ser executado.

Também alteramos o valor mínimo de confiança para 20% que mais regras sejam geradas. O padrão de suporte de 10% foi mantido. Nenhuma parametrização avançada foi feita.

Configuração do algoritmo Apriori em R

Configuração do algoritmo Apriori em R

O SAP Predictive Analysis aceitou nossa configuração e indica que nosso modelo de predição pode ser executado.

Verificação da configuração realizada com sucesso

Verificação da configuração realizada com sucesso

Uma vez executada a nossa análise (que foi praticamente instantânea pelo fato do nosso dataset ser muito pequeno) podemos visualizar os resultados.

Execução do algoritmo realizada com sucesso

Execução do algoritmo realizada com sucesso

Apriori

Vamos pausar um pouco a modelagem para falar do algoritmo usado. O Apriori cria regras de associação entre os produtos (caso elas sejam mais representativas que a nossa parametrização mínima). Para cada regra, o algoritmo calcula 3 valores: suporte, confiança e a sustentação (lift).

Vale a pena destacar o significado de cada uma destas colunas geradas.

Rule (regra)

Esta coluna define uma associação entre diferentes conjuntos de produtos. Por exemplo:

  • {} => {Arroz} significa que independente dos outros produtos, o arroz aparece nas compras (o quanto isso é verdade é dito em outras colunas)
  • {Arroz} => {Feijão} significa que quando se compra Arroz, também se compra feijão. Novamente, o quanto isso é verdade é dito nas outras colunas.
  • {Arroz & Feijão} => {Ovo} significa que quando se compra Arroz E Feijão, também se compra Ovo (esta regra não foi gerada na análise)
  • {Arroz} => {Feijão & Ovo} significa que quando se compra Arroz, também se compra Feijão E Ovo (esta regra não foi gerada na análise)

Support (suporte)

Esta coluna informa a representatividade de um produto no conjunto geral das vendas. Exemplos:

  • {} => {Arroz} tem suporte ~ 29%. Nas 17 transações do nosso dataset, 5 possuem Arroz. Logo, 5 / 17 = ~29,41%
  • {Arroz} => {Feijão} tem suporte de ~18%. Se você contar no dataset, apenas 3 transações possuem Arroz e Feijão (IDs 12, 13 e 17). Logo, 3 / 17 = ~17,64
  • {Feijão} => {Arroz} também tem suporte de ~18% e não é mera coincidência. Estamos falando das mesmas vendas. Logo o cálculo do suporte é associativo.

Confidence (confiança)

Se algum cientista de dados afirmasse para você (que é dono do mercado): “Quando se vende Manteiga, também se vende Ovo”, você poderia ficar receoso e perguntar: “Você tem certeza? Daria sua vida por isso?”. A confiança diz se você poderia dar sua vida por este tipo de afirmação. A confiança informa a representatividade de um produto no conjunto de vendas que ele mesmo aparece.

{Manteiga} => {Ovo} tem confiança ~ 33% ao passo que {Ovo} => {Manteiga} tem confiança ~ 67% – O que isso significa? Já chegaremos lá… mas já afirmo que vamos precisar do suporte para para calcular a confiança

  • Confiança de {Manteiga} => {Ovo}
    • {} => {Manteiga} tem suporte ~35% (ela aparece em 6 das 17 transações)
    • {Manteiga} => {Ovo} tem suporte ~11% (somente 2 das 17 vendas possuem Manteiga E Ovo)
    • Fazemos então 11% / 35% – ou se preferir (2/17)/(6/17) – e temos 33% como resultado

Isso significa que 33% das vezes que Manteiga é vendida, também se vende Ovo. Isso é muito ou pouco? Quem tem que dizer isso é você como dono do supermercado. Agora, não se esqueça que você deve avaliar se a venda de Manteiga é representativa verificando o suporte. Logo, 35% das compras do mercado inteiro tem Manteiga (suporte) e 33% destas vendas que tem Manteiga, também tem Ovo.

Note que regras cujo lado esquerdo é vazio possuem suporte = confiança, o que é lógico pensando que 100% das vezes que manteiga é vendida manteiga é vendida :-P

Note também que para o cálculo da confiança usamos o suporte do produto no lado esquerdo da regra (Manteiga). Logo, se formos calcular a confiança da regra oposta {Ovo} => {Manteiga} talvez tenhamos um resultado diferente pois o suporte do Ovo pode ser outro.

  • Confiança de {Ovo} => {Manteiga}
    • {} => {Ovo} tem suporte ~18% (ela aparece em somente 3 das 17 transações) – note que esta regra nem aparece no resultado do algoritmo visto que configuramos o Apriori para retirar todas as regras com confiança menor que 20%
    • {Ovo} => {Manteiga} tem suporte ~11% (somente 2 das 17 vendas possuem Ovo E Manteiga) – o que já era sabido do exemplo anterior – suporte é associativo!
    • Fazemos então 11% / 18% – ou se preferir (2/17)/(3/17) – e temos ~66% como resultado.

Concluímos então que esta última regra é mais “verdade”. Quando se vende ovo, vende-se manteiga em 66% dos casos. Mas vale lembrar que o suporte da venda de Ovos é mais baixo. Somente 18% das vendas tem Ovo.

Na verdade a principal conclusão disso tudo é que suporte e confiança caminham lado a lado.

Lift (sustentação)

Apesar de caminhar lado a lado, suporte e confiança podem não ser suficientes. Imagine que o seu mercado tenha um produto que está sempre sendo vendido (como tem acontecido com água, ventiladores e extintores em São Paulo). Como ele quase sempre é vendido, você pode imaginar que o suporte dele é grande. Também é de se supor que a maioria das regras que este produto mega vendido está a direita na regra, a confiança é grande. Nestes casos você conta também com a sustentação (lift). Ele te dirá se uma regra é mero acaso ou não.

Outra forma de se pensar no lift é a seguinte: Será que o produto mega-vendido é vendido menos quando outro produto está presente nas compras? Imagine que {Refrigerante} => {Água} tem suporte de 40% e confiança de 80%. Isso pode soar interessante num primeiro momento porque você pode considerar que ambos valores são grandes. E se na verdade Água é vendida em 95% dos casos de qualquer maneira? Isso pode ser um indício que na verdade o refrigerante diminui a venda de Água. Se a margem da Água for maior que a do refrigerante talvez isso represente muito dinheiro para você.

O lift também é um ratio representado logo por um um número que poder ser maior que 1.

  • Sustentação de {Arroz} => {Feijão}
    • Confiança de {Arroz} => {Feijão} = 60% – das 5 vendas no todo que tem Arroz, 3 também tem Feijão (3 / 5)
    • Suporte de {Arroz} => 29% – 5 das 17 vendas tem Arroz
    • Fazemos então 60% / 29% e temos 2.04. Logo Arroz e Feijão são comprados mais juntos do que Arroz isoladamente.
  • Sustentação de {Feijão} => {Arroz} deu o mesmo resultado neste exemplo pois ao suporte do Feijão é o mesmo
    • Confiança de {Feijão} => {Arroz} = 60% – das 5 vendas no todo que tem Feijão, 3 também tem Arroz (3 / 5)
    • Suporte de {Feijão} => 29% – 5 das 17 vendas tem Feijão
    • Fazemos então 60% / 29% e temos 2.04. Logo Feijão e Arroz são comprados mais juntos do que Feijão isoladamente.

Depois disso tudo… fica fácil notar porque este tipo de demanda vem crescendo no mercado. As pessoas no fundo “querem evitar a fadiga” de calcular isso tudo.

Pós-Processamento

Para facilitar a exibição, eu criei uma visualização baseada no resultado do Apriori criando algumas measures e criando uma saída tabular. A etapa de pós processamento envolve capturar a saída do algoritmo e transformá-la em algo que pode ser compreendido mais facilmente.

Exibição do resultado do algoritmo a priori em forma tabular

Exibição do resultado do algoritmo a priori em forma tabular

Além da forma tabular, podemos exibir as regras criadas em forma de nuvem de tags, o que é bem legal. Quando maior a regra maior o Lift, quanto mais vermelho maior a confiança.

Exibição do resultado do algoritmo a priori em forma de nuvem de tags

Exibição do resultado do algoritmo a priori em forma de nuvem de tags

Podemos ainda parar o mouse numa das regras e ver seus detalhes.

Detalhamento da regra em tooltip

Detalhamento da regra em tooltip

Além destes gráficos, quando um algoritmo é executado em R no SAP Predictive Analysis, a própria saída do R é exibida. Aqui está na íntegra:

Podemos finalizar então o processo de modelagem. Já sabemos como deve ser nosso dataset, o algoritmo a ser usado e seus parâmetros.

Vale lembrar que este post é didático. Esta etapa no mundo real envolveria fazer inúmeras etapas de pre-processamento e várias tentativas de predição usando algoritmos diferentes, com parâmetros diferentes e até uma grande combinação de algoritmos. O SAP Predictive Analysis ajuda neste processo de modelagem pois permite criar diferentes modelos e compará-los usando gráficos, boards, relatórios e infográficos.

Deployment

O SAP Predictive Analysis é legal mas até então tínhamos um pequeno dataset e uma execução local na máquina de um cientista de dados. O SAP Predictive Analysis é capaz de se conectar com o HANA também permitindo que tanto o dataset quando a execução dos algoritmos sejam feita no HANA, mas ainda sim o processo faria parte da etapa de modelagem, Uma importante tarefa do processo de data science é o deployment da modelagem. Ou seja, transformar o que foi projetado em algum produto/aplicação. Algo que não precise da supervisão/interação de alguém para que funcione (ou que pelo menos seja mínima e bem menos trabalhosa do que o trabalho que fizemos no SAP Predictive Analysis). Ainda, esta aplicação deveria suportar uma massa de dados bem maior que o nosso pequeno dataset.

Finalmente chegamos no HANA! Ele pode nos ajudar com isso tudo. Abordaremos a criação da aplicação demonstrada no vídeo no começo deste post. A aplicação foi desenvolvida num HANA standalone, hospedado no Cloudshare com SP06.

Vamos criar 2 projetos no HANA.

  • Back end de (contendo tabelas, procedures, serviços XSJS e oData e principalmente a execução Apriori (não mais em R mas usando o Predictive Analysis Library)
  • Front end (feito em SAPUI5) – que será o meio pelo qual o(s) usuário(s) executarão a análise.

A nossa aplicação será capaz de executar o Apriori para uma massa de dados no HANA. Esta massa de dados estará armazenada numa tabela colunar. A tabela pode estar previamente preenchida ou poderemos subir um arquivo .csv para alimentar a tabela. Nesta aplicação ainda permitiremos ajustar os parâmetros do algoritmo Apriori via interface gráfica (UI5) e exibiremos o resultado do algoritmo sem nenhuma etapa de pós-processamento. Ou seja, exibiremos a tabela de regras + suporte + confiança e sustentação para o usuário. Obviamente a nuvem de tags é mais legal, mas requer um trabalho a mais no front end que não é o foco deste post. O importante é que estamos fazendo uma aplicação e mostrando o processo fim a fim.

Arquitetura da aplicação

Uma imagem vale mais que mil palavras. Logo fiz o meu melhor para poder expressar os principais detalhes da aplicação numa forma de arquitetura. É interessante notar e compreender as partes que se interagem.

Basket Analysis - Application Architecture

Arquitetura da aplicação de Basket Analysis

 

Projeto Back end

Para esta aplicação precisamos de três tabelas. Uma com os dados, outra com parâmetros do Apriori e outra para os resultados do mesmo.

As três podem ser criadas num único arquivo usado Core Data Services. Mais ou menos como abaixo.

Expondo dados da aplicação com oData

As três tabelas terão seu conteúdo exibido no front end. Por isso criamos uma serviço oData para expor estes dados. Podemos também definir que o serviço apenas fornece os dados e não irá permitir nenhum tipo de alteração, inserção ou remoção.

Javascript Server-Side – XSJS

O servidor HANA precisará responder algumas requisições do front end. Serão 4 no total:

  • Upload.XSJS – Inserção de dados via arquivo .csv (operação de insert na tabela de dados)
  • Reset.XSJS – Remoção de dados de entrada (operação de delete nas tabela de dados)
  • Options.XSJS – Definição dos  parâmetros do algoritmo (operação de update na tabela de parâmetros do algoritmo)
  • Apriori.XSJS – Chamada de uma procedure do PAL (representada pela chamada da procedure _SYS_AFL)

Os três primeiros serviços XSJS internamente chamam procedures que fazer as operações de Insert, Delete e Update respectivamente. O código das procedures não será inserido abaixo mas você poderá ver na página do projeto.

Upload.XSJS

Reset.XSJS

 Options.XSJS

 Apriori.XSJS

Projeto Front End

Vamos mostrar um pouco dó código SAPUI5 para o projeto de front end. Nossa aplicação usa primordialmente os controles do pacote sap.m e terá 4 views.

  • UserDetails.view – Cadastro de dados do usuário – Um mini cadastro que neste caso não faz diferença nenhuma na execução da aplicação
  • File Input.view – Input de dados via arquivo .CSV. Caso a tabela já esteja preenchida o usuário pode simplesmente pular esta etapa
  • Options.view – Aqui o usuário pode mudar os parâmetros do algoritmo (algo que tipicamente o usuário não faria numa aplicação que usa análise preditiva, mas esta funcionalidade poderia estar presente para um superuser/administrador do sistema para evitar casos como este o mais rápido possível.
  • Result.view – Resultados do algoritmo – num formato tabular assim como foi exibido no SAP Predictive Analysis

Não há motivo para colocar o código completo do front end aqui. Mas colocarei o código das partes que se interagem como é exibido na imagem da arquitetura.

Consumindo oData

Como nosso modelo é fornecido através de oData, usamos a classe sap.ui.model.odata.ODataModel para capturar as informações do modelo.

Controllers

Segue os trechos de códigos dos controllers que fazem chamadas de serviços XSJS. Parte do código foi removido para simplificar um pouco a leitura.

File Input.view – Upload de csv

Já falamos aqui no HANA Brasil de como fazer upload de .csv no servidor a partir de uma aplicação UI. Aqui usamos um outro control chamado sap.ui.unified.FileUploader, mas o conceito é o mesmo.

File Input.controller.js

Options.controller.js

Result.controller.js

Repositório Basket Analysis on SAP HANA no GitHub

O projeto “Basket Analysis on SAP HANA” pode ser encontrado no GitHub. Se você gostaria da versão na qual foi usada durante a criação deste post, sugiro verificar o commit feito antes do SITSP.

Conclusão

É importante que tenhamos mais exemplos de aplicações fim a fim para que possamos entender a complexidade de construção de aplicações voltadas para análise preditiva.

A modelagem da predição é apenas o começo do processo e é fundamental entendermos como as diferentes camadas do front end e back end se interagem.

Entender os detalhes do algoritmo sendo usado é de extrema importância e talvez entender o seu dataset é ainda mais.

Espero que tenha entretido você até aqui. Gostaria muito de ouvir seus comentários e dúvidas aí em baixo. Fique a vontade e deixe seu comentário!

Leave a Reply

Your email address will not be published. Required fields are marked *