O QCon São Paulo é um dos maiores eventos de tecnologia do Brasil e um dos poucos voltado para um público mais sênior. Nele encontram-se as melhores empresas do país trazendo seus cases, assim como palestrantes internacionais de instituições de renome/extrema importância. Na edição deste ano, tive a oportunidade de participar do terceiro dia de evento, na trilha dedicada à Data Science.
Foi notável como a Data Science está sendo usada em diversas áreas no Brasil, e como cada vez mais a tomada de decisões baseada em dados faz parte da estratégia das empresas. Uma organização com um trabalho voltado a dados, exige uma grande mudança de cultura e um entendimento das informações, e a Data Science vem apoiando muito isso.
Não só foram abordados casos de uso, mas também levantados pontos importantes, como enfoque na Engenharia de Dados – que trata de como preparar seus dados para análises e treinamento de modelos de inteligência artificial -, assim como a questão da ética e modelos de aplicação, levantando uma questão importante sobre limpeza das informações e como criar modelos que respeitem a igualdade e sejam livres de preconceito, seja ele qualquer um.
Na minha palestra, intitulada: “Analisador de dados Automatizado utilizando Machine Learning”, mostrei como usamos análises de dados e Machine Learning para monitorar nossos sistemas distribuídos gerando impacto financeiro direto. Segue o resumo detalhado:
A Wavy possui negócios e produtos com operadoras de telefonia móvel no Brasil e demais países da América Latina. Os clientes são tarifados de forma recorrente pelas assinaturas desses produtos. Em média, geramos em torno de 150 milhões de transações de tentativas de tarifação por dia. Todo esse ecossistema é composto de uma gama de sistemas distribuídos de alto desempenho que funcionam 24h por dia.
Utilizamos a ferramenta Apache Spark para empregar algoritmos de Machine Learning, gerando modelos capazes de fazer a análise dos dados automaticamente, dessa forma, conseguindo identificar se temos algum problema em nossos serviços e notificando os times responsáveis. Nessa abordagem, empregamos com sucesso modelos de regressão linear com árvores de decisão, para conseguir prever os valores de números de transações com sucesso, erros e dessa forma, poder determinar se os valores de nossas séries temporais estavam funcionando de acordo com o esperado.
Entrando em detalhes sobre o caso de uso, convém mostrar qual o tipo de problema essa solução se propõe a resolver. Na Wavy, nós temos diversos produtos e serviços, dentre eles, vamos tratar aqui de produtos de assinatura junto às operadoras de telefonia móvel, tais como, entrega de conteúdo rico no celular, acesso a aplicações móveis, jogos e etc.
Nossas plataformas tratam as assinaturas de nossos produtos a criação e cancelamento delas, e também o seu controle do ciclo de renovação, que em termos práticos, significa a cobrança do cliente em sua operadora de telefonia celular. Essas plataformas funcionam de forma distribuída, ou seja, em diversos computadores diferentes, inclusive em localidades distintas e tem como principais requisitos: alto desempenho e disponibilidade. Há um grau de criticidade grande envolvido na manutenção operacional das plataformas, pois em caso de indisponibilidade de alguma parte, podemos ficar sem cobrar os usuários, afetando diretamente o faturamento da área como um todo.
Dado esse cenário, temos dois desafios:
- Saber se a plataforma está funcionando corretamente; e
- Identificar problemas com os produtos e operadora de forma automatizada.
Antes da solução que apresentamos aqui, as análises eram efetuadas manualmente sobre um conjunto de dados consolidados, provenientes do funcionamento da plataforma de tarifação,
veja a Tabela 1 abaixo:
.
Tabela 1. Dados de tentativas de tarifação consolidados para análise
Temos um identificador da operadora (carrier_weigth), a faixa de horários da análise, por exemplo das 0h até as 20h (date_time), algumas informações da operação, como: tempo de resposta da operadora (avg response time), requisições de cobranças com sucesso (succ. charges), número de tentativa de cobrança onde o usuário não possuía crédito suficiente (no credit), erros retornados pela plataforma ou pela operadora (general errors) e o número total de tentativas de cobranças (total attempts).
A análise era realizada comparando-se os dados do dia atual, com os dados dos dias anteriores na média, como mostrado na tabela acima, e não tínhamos um método formal para fazer essa análise. Caso o analista julgasse que os dados eram de alguma forma discrepantes, então iniciavam-se as investigações por problemas na plataforma.
Nossos objetivos com o projeto foram:
- Determinar se a plataforma distribuída estava funcionando adequadamente baseado somente em análise de dados
- Criar uma forma de analisar esses dados automaticamente de forma sistematizada
Em nossa abordagem, preparamos os dados da Tabela 1 para alimentar algoritmos de Machine Learning para experimentar sua capacidade de prever um determinado número contínuo, em nosso caso, queremos prever o número de sucessos de tarifação e o número esperado de tentativas de tarifação dado uma operadora, hora do dia e assim por diante.
Aprendizado Supervisionado é a categoria de problemas de Machine Learning, quando sabemos o que queremos prever, temos os chamados dados rotulados nas nossas amostras. Dentro desse tipo de aprendizado, quando queremos trabalhar para prever números contínuos, em geral, trabalhamos com regressões lineares. Baseado nisso, testamos algumas implementações de algoritmos regressores que o Apache Spark já disponibiliza. Fizemos os testes mudando alguns regularizadores. O resultado do desempenho dos algoritmos pode ser observado na Tabela 2 abaixo:
Tabela 2. Desempenho dos algoritmos regressores do Apache Spark
Na Tabela 2 temos as medidas de erro e acurácia dos algoritmos. O critério de avaliação para medir o erro foi a RMSE (Root Mean Square Error), já conhecido para medir desempenho dos algoritmos regressores. A acurácia reflete a capacidade do algoritmo de prever o valor para o número de sucessos, no nosso caso, consideramos uma variação de +/- 15% para considerar que o algoritmo acertou o valor esperado. Todo código da experimentação prática para chegar a esses resultados podem ser replicados através do spark-notebook disponível nesse repositório.
De acordo com os resultados apresentados na Tabela 2, o modelo de árvore de decisão com regressão linear (Decision Tree Model), foi o modelo com o menor erro e também com a maior capacidade de prever os valores, ou seja, acurácia.
Com 93% de acurácia, decidimos colocar o modelo em produção para fazer as análises automaticamente. O modelo serializado com Apache Spark dá bastante flexibilidade de trabalho, os modelos foram treinados em linguagem Scala, entretanto, para usá-lo , podemos escolher entre as linguagens suportadas pelo Apache Spark: Scala, Java, Python e para alguns casos até mesmo R.
Nós batizamos o projeto inicialmente de Watcher-AI. A implantação ocorreu em duas fases distintas. A primeira de treinamento do modelo. A segunda de implantação do modelo onde expomos como um pequeno micro serviço.
Com essa interface de previsões exposta, fizemos então que de hora em hora, os dados fossem coletados de nossas bases de produção e comparamos o valor corrente de tentativas de tarifação, número de sucessos, número de erros e tempos de resposta previstos pelo nosso modelo. Os detalhes da solução arquitetural podem ser observados na Figura 1.
Figura 1. Arquitetura da solução Watcher-AI
Os dados são coletados de nossas bases, treinamos os modelos no Apache Spark. Os modelos são expostos via uma API chamada de Nostradamus, o Watcher-AI por sua vez funciona a cada hora obtendo os dados atuais dos indicadores das plataformas e caso necessário envia mensagens de notificação usando diferentes tipos de canais de comunicação.
Caso o Watcher-AI detecte um valor muito discrepante entre o esperado e o medido, em geral maior que um limiar definido (exemplo: erro maior que 15%), o sistema envia uma série de notificações informando o problema e dando alguns dados adicionais para auxiliar nas investigações.
O sistema foi integrado com uma série de diferentes canais de comunicação, como ferramenta de chat interna da empresa, como o Slack, envio de notificações por push e até envio de mensagens via SMS. Dependendo do problema detectado diferentes times, são acionados e notificados via o canal mais adequado, por exemplo, problema com a operadora, notificamos o time de suporte, problema com a plataforma, número baixo de tentativas, notificamos o time de desenvolvimento e assim por diante.
E como são essas mensagens de notificação do Watcher-AI? As pessoas tem curiosidade de saber. Essas mensagens são programadas, não temos inteligência artificial envolvida.
Nas mensagens colocamos informações sobre o problema, valores medidos e esperados, erro calculado de forma a auxiliar na análise e diagnóstico do problema. Na Figura 2 mostramos o conteúdo de uma mensagem de exemplo, em cada canal de comunicação a mensagem vai se apresenta em formatos distintos, porém o conteúdo se mantém.
Figura 2. Exemplo de conteúdo de uma mensagem de notificação do sistema
Com os resultados práticos desse trabalho, conseguimos treinar um modelo capaz de prever nosso principais indicadores das plataformas. Esse modelo está sendo utilizado em produção no momento com alto impacto financeiro. Uma série de problemas foram descobertos, o sistema agora avisa quando algum número não está na faixa esperada e temos muito mais agilidade na detecção do problema, assim como na atuação para correção do problema. Em quase 3 anos de funcionamento, estimamos uma economia em custos por volta de 2 milhões de dólares.
Caso queira saber mais detalhes e acessar os slides que apresentei no QConSP 2018, basta clicar aqui.
Dica: tem uma talk também disponível onde apresento alguns pontos da solução:
Have Fun!
#GoMovile
#GoWavy
