Modelos preditivos em dados: detecção de fraude

Olá!! Boas-vindas ao curso de Modelos preditivos em dados: detecção de fraude da Alura. Eu sou a Sthefanie Monica e te acompanharei durante todo o seu percurso.

Sthefanie é uma mulher jovem, branca, de olhos castanhos e cabelos castanhos claros na altura dos ombros. Usa óculos de grau, headphones e veste uma camiseta preta com a palavra "Caelum;" estampada ao centro em amarelo. Está sentada em uma cadeira gamer preta dentro de uma sala de estúdio com placas de isolamento acústico na parede e alguns quadros de filmes pendurados. Um deles, do "Star Wars: the Mandalorian".

Neste curso aprenderemos como produzir uma pipeline de machine learning desde o início. Então, faremos a aquisição de dados, traremos esses dados e trabalharemos com eles a partir de uma análise inicial, entendendo quais são os requisitos e tratamentos necessários para que esses dados sejam inseridos no nosso modelo de machine learning.

Após passar pelos tratamentos prévios, com os dados já nos modelos, nós faremos a avaliação dos modelos através de métricas. Esses modelos serão avaliados individualmente e, depois, comparados entre si. É a partir dessa comparação entre modelos que escolheremos o melhor.

Para conseguir aproveitar realmente o curso, é importante que você tenha um conhecimento básico em machine learning. Mas, por que estamos fazendo todo esse projeto de detecção de fraude?

Vamos supor a seguinte situação: eu e você trabalhamos em uma startup, então, somos colegas, e o nosso chefe pediu que produzíssemos um projeto para compor um portfólio da empresa. Nós precisamos de novos clientes, porque ainda somos uma statup em construção. Esses clientes podem ser bancos ou financeiros.

Diante desse contexto, um problema bastante recorrente é o de fraude e nós precisamos resolvê-lo. Além disso, será bastante interessante ter um projeto como esse no nosso portfólio. Portanto, nosso objetivo é criar um projeto de detecção de fraudes e adicioná-lo ao portfólio da nossa startup.

Então, vamos aprender um pouco mais sobre detecção de fraude!!

Então, o caso que resolveremos é de uma startup que deseja montar um portfólio. Nós somos as pessoas cientistas de dados dessa startup e desejamos captar mais clientes para que ela tenha bastante sucesso.

A startup trabalha com diversos projetos em ciência de dados e busca diversificar seus clientes, inclusive, trazer soluções sobre projetos que passam por situações de fraude, por exemplo, agregar bancos ou comércios que enfrentam essas falhas.

Os pontos de falha ou fraude têm acontecido por muito tempo e diminuído com as técnicas de machine learning que aplicamos e visam reconhecer os padrões de compra de cada cliente, saber como ele faz suas transações, suas passagens de dinheiro de cliente para cliente ou como ele trabalha, por exemplo, se pagará as contas no começo do mês ou no final.

Portanto, vamos identificando pequenos padrões e, a partir disso, as fraudes. Significa que conseguimos treinar os modelos para dizerem se é fraude ou não. Para que esse tipo de análise seja feita, as empresas contam com um vasto banco de dados com nome, cartão de crédito e documentos pessoais. Chamamos esses dados de dados sensíveis, que obviamente não podem ser divulgados, porque são pessoais. Caso sejam vazados, a empresa terá grandes problemas.

Por serem restritos, nós não conseguimos trabalhar com os dados que estão nos bancos, instituições financeiras ou nas empresas que os recebem. Como fazer um trabalho de detecção de fraude sem esses dados?

Existem algumas tabelas com determinada transação e colunas x1, x2, x3, mas não alcançamos a mesma performance que teríamos com o nome da pessoa, ou sabendo que ela fez uma transação de determinado valor, dia e horário. Então, isso dificulta o nosso trabalho e impede que o nosso modelo seja preciso, pois não sabemos ao que equivale o x1, x2 e x3 e não conseguimos predizer.

Porém, há outros meios de acesso a uma tabela ou banco de dados que seja interessante para trabalhar com a detecção de fraudes. Como cientistas de dados dessa startup, faremos uma pipeline desse processo de detecção de fraudes do começo ao fim, assim agregaremos novos clientes e revolveremos esse problema que os afeta.

Nós trabalharemos com o Storytelling de um banco que conta com um sistema de cadastro dos clientes e aconteceram alguns casos de fraude. Nosso objetivo é diminuir essas fraudes, mas não sabemos ainda o que está acontecendo. Esse será nosso ponto de partida.

Antes de começarmos a analisar os códigos de fato, precisamos escolher uma IDE. Nela construiremos todas as nossas análises que ficarão disponíveis para os clientes, nosso chefe ou para colocarmos no nosso portfólio. Para isso, utilizaremos uma IDE ON-LINE, que permite acessos e alterações simultâneas.

Nós optaremos então pela IDE Colab ou Google Colaboratory. O Google Colab é on-line, o que permite compartilharmos o nosso trabalho com outras pessoas, que acompanharão a nossa evolução no projeto, por exemplo, os nossos colegas de startup e o nosso chefe.

Outra vantagem de usarmos o Google Colab é que ele roda o Jupyter, porém, não é necessário instalar o Anaconda no nosso computador, que tem um processo de instalação um pouco mais burocrático e longo. Já teremos tudo instalado dentro do Colab on-line, por isso será bem mais fácil manipulá-lo.

Temos ainda outra vantagem, talvez a melhor delas, que é rodar tudo em nuvem. Então, o Colab não processará tudo no nosso computador, deixando-o livre para outras atividades que eventualmente precisarmos fazer, tanto da startup quanto atividades pessoais. Portanto, todo processamento fica na nuvem, o que é muito positivo.

Eu já criei um Google Colaboratory e adicionei alguns comentários, um deles em relação ao nosso banco de dados. Primeiro, não temos dados públicos sobre detecção de fraude, porque os bancos não divulgam dados dos clientes. Além disso, existe outra situação que são as bases de dados compostas de X1, X2 e assim por diante.

Precisamos superar esses problemas, principalmente porque ainda estamos criando o nosso portfólio e queremos mostrar que conseguimos extrair informações relevantes para as empresas. Uma solução é usarmos o simulador PaySim que oferece dados sintéticos exatamente para a detecção de fraude.

É basicamente o tipo de dado que teríamos acesso, apenas um pouco reduzido. Em alguns bancos, acessaríamos o número do documento, CNPJ, e outros, no PaySim esses dados não aparecem, mas temos o suficiente para a detecção de fraude: o nome dos clientes, quanto transferiram de dinheiro, para quem e outros detalhes desse gênero.

O PaySim é um banco de dados muito extenso, por isso não conseguiremos utilizá-lo dentro do Google Colaboratory gratuito. Então, utilizaremos uma fração de dados do PaySim que é o Fraud Detection Example, um exemplo da fração de dados. Nós encontraremos esse exemplo de dados no Kaggle. O link já está no nosso Colaboratory com o nome "Fraud Detection Example", basta selecioná-lo e seremos redirecionados ao Kaggle.

No Kaggle, encontraremos informações sobre o Dataset, o contexto do PaySim e o conteúdo com todas as descrições das colunas, isto é, o que cada coluna significa. Um pouco mais abaixo, é possível visualizar a nossa tabela, que é o nosso dataset, conseguimos inclusive rolá-la tanto para baixo, quanto para os lados, o que nos permite verificar as variáveis das colunas.

Na aba de colunas, "Column", conseguimos visualizar também algumas estatísticas sobre cada uma das colunas. Por exemplo, na coluna "Nome do origem" ou "nameOrig", temos 101613 (cento e um mil, seiscentos e treze) nomes únicos.

Provavelmente, esses são os valores totais do dataset, logo, concluímos que o dataset tem mais de cem mil dados. Esse número representa apenas uma parcela do PaySim, entretanto, é uma quantidade grande de dados. Agora retornaremos ao Google Colaboratory, pois já traduzimos o que cada coluna representa.

Saber o que cada uma das colunas é, faz ou representa facilita a nossa análise, já que saberemos o que está acontecendo de uma para outra, inclusive porque podem existir dependências entre elas. Nós temos onze colunas no total.

A primeira que encontraremos no dataset é a step, que mapeia uma unidade de tempo no mundo real. Cada step é uma unidade de tempo de hora. Nós teremos 744 (setecentos e quarenta e quatro) steps totalizando um mês do nosso mundo. É uma simulação de trinta dias que, mesmo sendo pequena, nos fornece bons resultados.

Depois temos os tipos, type, que correspondem à caixa de entrada, saída, débito, pagamento e transferência. Neles encontramos não só os clientes convencionais, mas também os com perfil de comerciante, porque a caixa de entrada e de saída não é usada normalmente por pessoa física, mas, sim, jurídica.

Em seguida, aparece o amount que seria o valor da transação em moeda local. No nosso caso, usaremos o real, já que estamos no Brasil. Depois, temos o nameOrig ou "nome de origem", que é o cliente que iniciou a transação. Também temos o oldbalanceOrg ou "balanço antigo", que seria o saldo inicial antes da transação, o newbalanceOrig, o novo saldo após a transação desse mesmo cliente.

Para o cliente que recebeu, temos exatamente os mesmos dados, o dado do nome, nameDest, que se refere, portanto, ao cliente que é o destinatário da transação, o balanço de antes, odlbalanceDest, que se refere ao destinatário do saldo inicial antes da transação e o saldo depois que recebeu a transação, newbalanceDest.

Também temos dois tipos de fraude, o isFraud e o isFlaguedFraud. O primeiro está relacionado às fraudes de fato, isto é, às transações que são classificadas como fraudulentas. Essas transações são feitas por agentes e nós conseguimos identificar por dados específicos, usando alguns sistemas, que são fraudes.

Por exemplo, verificamos que a pessoa x passou valor y de dinheiro em determinado horário diferente do habitual, enfim, se algo diferente aconteceu, já classificamos como fraude. Já o isFlaguedFraud funciona como um alerta vermelho, quando há alguma tentativa de transferir mais de duzentos mil reais de uma conta para outra. Se isso acontecer, é sinal de que precisamos tomar uma atitude urgentemente.

Nós analisaremos as onze colunas no decorrer das aulas e já notamos a existência de uma coluna que varia da outra. Por exemplo, o amount que é a transação em moeda local, causará uma variação no nosso balanço de origem e o balanço novo. Então, temos essas variações e precisamos compreender realmente o que cada uma das colunas significa para entendermos as relações entre as próprias colunas.

Para colocarmos o nosso dataset no Colaboratory e iniciarmos as nossas análises, na lateral esquerda, temos um ícone de arquivos. Vamos selecioná-lo e ele abrirá uma área vazia, onde apertaremos com o botão direito do mouse. Em seguida, selecionaremos a opção "Upload".

Agora, acessaremos a pasta onde está baixado o dataset que foi disponibilizado. Vamos selecioná-lo e apertar "Abrir". Como são mais de cem mil dados, o carregamento demorará um pouco, mas depois que ele for carregado, estará tudo pronto para começarmos as nossas análises. Faremos isso nas próximas aulas!!