OManual Praticode Data Science

Transaction: HP15615810282991 e-mail: edubastosmail@gmail.com CPF: 052.348.
297-31
Transaction: HP15615810282991 e-mail: edubastosmail@gmail.com CPF: 052.348.297-31
UM RECADO PARA VOCÊ
Obrigado por adquirir este manual.
Este é meu primeiro e-book sobre Data Science, apesar de todo o conteúdo
que já publiquei no meu site.
Quando decidi escrever este e-book procurei entender qual seria a melhor
perspectiva. Deveria ser um livro para iniciantes? Um livro técnico? Um
livro avançado? Quem sabe apenas falar sobre competições?
Mas então eu pensei: se eu tivesse um filho e quisesse garantir que ele
tivesse acesso ao conhecimento que eu aprendi nestes anos de trabalho e
estudo intensos sobre machine learning, sobre o que eu escreveria?
Este livro é o resultado.
Eu espero que com o conhecimento adquirido aqui você possa guiar melhor
os seus projetos e estudos na área de Data Science. O sucesso de cada um
de nós contribui para o fortalecimento da comunidade no Brasil.
A maioria dos casos de competições citados no livro tem algum artigo
escrito no meu site com um resumo da minha abordagem.
1
Boa leitura!
Mario Filho
São Paulo, dezembro de 2019
2
1 DEFINIÇÃO DO PROBLEMA
3
Qual é o problema que queremos resolver?
Quando falamos em problema para resolver, estamos falando de problemas
no sentido abstrato. Nessa hora queremos descobrir casos em que podemos
tentar usar machine learning para criar uma solução.
A maioria dos casos das empresas está relacionado a marketing. Tanto que
uma das aplicações mais comuns de machine learning é a recomendação.
Mas como saber que um sistema de recomendação é o que precisamos
construir?
Imagine que a empresa queira vender mais produtos ou aumentar o valor
médio que cada cliente atual compra.
Precisamos partir desse objetivo mais amplo, abstrato, para poder chegar ao
objetivo técnico de nosso projeto.
O maior erro que você pode cometer
Um erro gigante que eu vejo empresas cometerem é inverter a ordem desse
processo.
Querem começar pelos dados e tentar achar uma solução sem um problema
claro.
É o famoso: “pegue esses dados e veja o que você consegue achar”.
Essa é uma das formas mais garantidas de iniciar um projeto que não vai
chegar a lugar algum.
4
Escolha o problema mais simples
Um outro erro que eu vejo é escolher projetos muito complexos sem ter
uma equipe experiente e uma cultura de dados.
Parece que as empresas ouvem falar sobre machine learning e já querem
resolver o problema mais complicado do negócio.
Se você quer ganhar experiência e criar uma cultura de valorização de Data
Science dentro de sua empresa, comece pelo projeto mais simples.
Como escolher um projeto simples?
Quantas empresas já fizeram projetos parecidos com este?
Se um projeto já foi feito com sucesso em várias empresas, significa que a
complexidade dele é baixa.
Isso é importante para que você não fique perdido nos detalhes e acabe
passando meses sem entregar resultado.
Qual a solução atual desse problema dentro da empresa?
Escolher um problema cuja solução atual seja “fraca” também é
importante.
Imagine que a solução atual de recomendação de produtos seja apenas uma
listagem dos itens mais vendidos na semana passada.
Geralmente, um sistema de recomendação simples que use machine
learning, vai trazer mais vendas ao recomendar produtos personalizados
para cada cliente.
5
Isso vai te ajudar a mostrar que soluções de machine learning podem
agregar valor às diversas áreas de sua empresa e incentivar mais pessoas a
fazer projetos com você, fortalecendo a cultura de dados.
Nosso objetivo não é apenas executar um projeto, mas demonstrar o valor
que existe em usar machine learning para resolver problemas.
Isso é muito importante se você quer sobreviver no mercado.
Qual a dificuldade para obter os dados necessários?
Procure projetos para os quais você já tenha dados armazenados e
razoavelmente consumíveis.
Existem dois momentos em que seus dados estão prontos para análise:
sempre e nunca.
Sempre você pode criar uma solução rápida e entender quais as limitações
dos dados e do problema que você quer resolver.
Nunca os dados estarão da forma ideal para fazer a análise como você
gostaria.
Se for precisar coletar dados, veja qual a possibilidade mais rápida de fazer
essa coleta.
Pode ser que “os dados ideais” precisem ser coletados, mas isso não te
impede de tentar criar uma solução intermediária com dados que você já
tenha.
Em boa parte dos casos você vai descobrir que a solução com dados “não
ideais” já acaba agregando valor.
6
Qual o processo de negócio que podemos afetar?
Nós precisamos entender quais são os processos de negócio que iremos
afetar com nossa solução.
Devemos entender os passos atuais do processo que será afetado por nosso
modelo.
Num caso de vendas de produtos online: qual a jornada do cliente até a
compra? Por onde ele chega ao site?
Pode ser por publicidade online, artigos no blog, newsletter, comercial na
televisão, cupom promocional, loja de aplicativos…
Vamos tomar uma jornada de exemplo:
1. O cliente busca um produto
2. Clica num anúncio online que o leva para o site
3. Lê a página do produto
4. Vê produtos similares
5. Compra ou abandona o site
Devemos melhorar os produtos similares mostrados no passo 4 para ajudar
o cliente a encontrar o que ele quer comprar?
Ou entender quais são os melhores canais para anunciar no passo 2?
Num caso de diagnóstico médico: quais são os passos que o especialista usa
para chegar à conclusão?
Pode ser o seguinte:
7
1. O paciente é examinado no consultório
2. Encaminhado para exames laboratoriais
3. Volta ao médico com os resultados.
Devemos então criar um sistema que sugira os exames que devem ser
pedidos no passo 2? Ou um sistema que ajude o médico a determinar o
diagnóstico no passo 3?
Isso deve ser descoberto nas reuniões iniciais com os especialistas da área
de negócios ou time de produto.
Depois que entendermos como nossa solução vai se encaixar no processo,
fica muito mais fácil entender as etapas restantes do projeto como: quais
dados serão necessários, como esquematizar o problema técnico de
modelagem, as necessidades de infraestrutura em produção.
8
Como iremos afetar esse processo? Qual será o
entregável?
Não basta saber qual processo afetar, mas precisamos entender como nossa
solução será usada na prática.
Se formos criar um sistema de recomendação, como serão usadas essas
previsões? Devemos gerar uma previsão para cada par de cliente e produto?
E se forem muitos produtos e clientes?
Se estivermos selecionando produtos para recomendar numa newsletter
podemos criar um sistema que toda semana compute as previsões e
armazene em um banco de dados.
Nesse caso, o sistema de envio de e-mail simplesmente faz uma busca e
monta o e-mail de para cada cliente.
No caso do diagnóstico médico, pode ser que as previsões precisem ser
geradas no momento em que o especialista enviar as informações.
Nesse caso precisamos ter uma API que receba as informações, rode o
modelo na hora para gerar a previsão e mostre na interface do aplicativo.
Saber as respostas para essas perguntas nos ajudará a entender quais limites
teremos na hora de colocar a solução em produção: como dados disponíveis
e latência do sistema.
9
Como saberemos que a solução está funcionando?
Mais do que melhorar métricas técnicas de machine learning, precisamos
definir quais serão as métricas de negócio/produto que iremos afetar.
É importante escolher dois tipos de métricas:
1. Primária
2. Secundárias
Essas métricas devem ser usadas para definir o sucesso/fracasso do projeto
durante o teste em produção (por exemplo, teste A/B).
Métrica Primária
Essa é a métrica principal do projeto. É aquela que mediremos em todos os
estágios possíveis, principalmente durante o monitoramento em produção.
Alguns exemplos são
1. Número de produtos vendidos por usuário
2. Tempo de solução de tickets de suporte
3. Número de produtos em estoque há mais de 30 dias
4. Valor de compras do cliente no mês
5. Tempo médio de permanência do usuário no site
6. Valor de recompra de produtos
7. Número de novas inscrições
8. Tempo de espera para primeira consulta
9. Número de consultas canceladas
10. Número de diagnósticos corretos
10
Tudo o que faremos no projeto é voltado a melhorar essa métrica. Mas
precisamos tomar cuidado, pois o fato de estarmos tentando afetá-la, a
torna menos confiável.
A “Lei de Goodhart” diz: “Quando uma métrica se torna um alvo, ela deixa
de ser uma boa métrica”
Por isso precisamos de…
Métricas Secundárias
Não adianta melhorar o número de novas vendas se o número de
devoluções de produto dobrar.
Por isso é importante ter várias métricas secundárias que tratem de
monitorar outros passos e processos afetados por nossa solução.
Precisamos lembrar também de entender essas métricas tanto no curto
quanto no longo prazo.
Mesmo que nossa solução seja feita para afetar, por exemplo, a chance de
compra nos próximos 7 dias, é importante monitorar o comportamento dos
clientes afetados durante as próximas semanas.
Nosso objetivo não deve ser otimizar essas métricas diretamente ou
cairemos no mesmo problema da métrica primária.
Devemos monitorar e entender o efeito de nossa solução.
Na maioria dos casos o ideal é que essas métricas se mantenham no mesmo
nível de antes da solução. O mais importante é monitorar a degradação.
11
Se elas melhorarem, considere como um bônus.
Não existem métricas secundárias específicas. Elas são qualquer métrica
que seja importante para o processo e não seja a primária.
Então, além dos exemplos citados na parte da métrica primária, podemos
ter:
1. Lifetime Value
2. Número de consultas de pacientes nos próximos 6 meses
3. Número de devoluções de produto
4. Número de tickets de suporte abertos
12
Em empresas
Se você trabalha numa equipe de dados em uma empresa, é importante
listar quais são as pessoas que vão participar do projeto.
Dentre as informações que você precisará saber estão:
Quais são os pontos de contato (pessoas) para obter os dados
necessários?
Que recursos computacionais vamos usar? Na nuvem ou servidor
próprio?
Em que linguagem de programação precisa ser a solução final?
Quem vai supervisionar o progresso do projeto?
Quais são os gestores que estão “patrocinando” o projeto?
Que equipes vão usar os resultados?
Quais serão as pessoas que vão te ajudar a colocar a solução final em
produção?
Que ferramentas devemos usar para o deploy? (Jenkins, Docker, AWS,
etc)
Como serão definidas as tarefas? Qual a duração da sprint?
Que formato de documentação devemos usar?
Qual o prazo de entrega?
Quais são os cuidados legais a tomar com os dados? Precisam ser
anônimos?
13
Visão Geral sobre Gestão do Projeto
Sprints de duas semanas
Assim como em desenvolvimento de software ágil em geral, é comum ter
projetos de data science com sprints de duas semanas
Cada empresa tem o método próprio de conduzir essas sprints, e não existe
um consenso sobre qual é a melhor maneira de adaptar esse método a
projetos de data science.
É importante entender que durante o passo 3 (modelagem) as tarefas são
mais voltadas a pesquisa do que o desenvolvimento normal de um software.
Por definição elas acabam não sendo muito concretas. Tome cuidado para
não fazer com que a tarefa seja tão limitada que atrapalhe a parte criativa.
Falo mais sobre como acredito ser a melhor maneira de definir tarefas nessa
fase mais à frente.
1-day sprints
Numa entrevista, Andrew Ng comentou que na empresa dele (Landing.AI)
eles conduzem “sprints de um dia”. Como funciona isso?
Durante a manhã eles analisam resultados dos modelos que ficaram
rodando durante a noite. Atividades como: verificar grupos de exemplos
14
onde o modelo está cometendo erros (análise de erro), quais parâmetros e
arquiteturas tiveram os melhores resultados.
No início da tarde, com os resultados do projeto atualizados, a equipe busca
novas ideias, experimentos que devem ser feitos, e definem quais deles
serão executados na próxima iteração.
Após a fase de criação e definição dos próximos experimentos, a equipe
trabalha no desenvolvimento do código para deixá-los executando durante
a noite e poder repetir essa “sprint” no dia seguinte.
Eu acredito que essa seja a melhor maneira de conduzir as partes do projeto
que envolvem majoritariamente experimentação.
É comum você começar a fazer as tarefas de uma sprint mais longa, e os
resultados dos experimentos te apontarem que, o caminho definido no
início da sprint, não é tão promissor.
Usando sprints de um dia não precisamos ficar presos durante duas
semanas a essas ideias, e podemos rapidamente mudar o curso para
explorar caminhos mais interessantes para a solução.
Como definir tarefas
Toda tarefa deve ter um resultado concreto.
Muitas vezes não é possível determinar exatamente quais serão os
experimentos testados durante a sprint, mas é possível saber em que parte
do projeto a equipe trabalhará.
Este resultado pode ser código, um modelo treinado, documentação, uma
apresentação, ou um relatório simples sobre o que foi testado e os
resultados.
15
Por exemplo, se durante essa sprint você for trabalhar na modelagem, eu
recomendo que o “entregável” de sua tarefa seja um diário de pesquisa.
Diário de pesquisa
Uma ideia que implementei com bastante sucesso nas equipes de data
science em que trabalhei foi a criação de um “diário de pesquisa”.
Todos os dias, após terminar os experimentos, você escreve num
documento tudo o que você testou, quais foram os resultados, novas ideias,
como você pensou sobre o problema.
Desta maneira é possível criar uma jornada que, além de documentar o que
foi feito no projeto, ajuda outras pessoas a entender sua linha de raciocínio
e aprender a resolver problemas.
Imagine se pudéssemos ler o diário de desenvolvimento de cada solução de
machine learning que venceu uma competição?
Certamente aprenderíamos muito sobre como machine learning funciona
em casos diferentes, e como uma solução evolui pelo tempo.
Também encontraríamos formas melhores de pensar sobre os problemas, ao
entender como os melhores cientistas de dados pensam.
Por isso, mesmo que você esteja fazendo um projeto sozinho, procure criar
um diário de desenvolvimento.
Duração do projeto
16
Um projeto de Data Science não deve se prolongar por muitos meses.
Por mais que nós façamos testes e validações em dados históricos, tentando
entender o comportamento da solução, só saberemos realmente como ela
vai impactar o negócio ao colocar em produção.
Por isso, eu recomendo que cada passo do processo dure de uma a três
semanas.
O seu trabalho não termina ao colocar o projeto em produção.
Considere cada projeto como uma iteração. Seja da própria solução que
você está construindo ou da evolução do uso de data science na empresa.
Os passos que você aprende aqui devem ser repetidos em projetos novos ou
na tentativa de melhorar a solução desenvolvida em uma iteração anterior.
Com Data Science, mais do que nunca, devemos procurar “falhar
rapidamente”.
O que fazer após encerrar o ciclo dessas etapas?
Apesar de ainda estarmos falando sobre o primeiro passo, é importante se
preparar para o fim do projeto.
Além das verificações técnicas, é importante revisar quais partes foram
difíceis, seja do ponto de vista técnico ou de negócios.
Qual departamento demorou mais para te enviar os dados necessários? Que
parte da infraestrutura de servidores precisou ser modificada? Como foram
resolvidos os problemas encontrados durante o deploy?
17
Isso é importante para garantir o amadurecimento da equipe e da cultura de
dados dentro da empresa, melhorando as chances de sucesso dos próximos
projetos.
18
2 PREPARAÇÃO DOS DADOS
❧
Após escolhermos um problema para resolver, é importante coletar dados
de todas as fontes que possam conter informações relevantes.
Mais do que isso, é importante entender quais são os problemas dos dados e
como eles chegaram até você.
Estes são alguns problemas comuns em projetos de Data Science.
19
Estes dados estarão disponíveis, da mesma forma,
em produção?
É muito comum que os dados que você está vendo na base não sejam iguais
aos que você receberá em produção.
Nos dados históricos nós não temos problemas de latência. Todas as
informações estão disponíveis no mesmo momento em que queremos fazer
a previsão.
Imagine a seguinte situação: você vai fazer um sistema de recomendação
de produtos para clientes e usar informações dos últimos produtos visitados
como features.
Nos dados históricos você tem os logs de acesso do cliente e consegue
determinar exatamente quais foram as páginas acessadas e a ordem em que
isso aconteceu.
Mas quando você for buscar essas informações em produção, elas estarão
prontas da mesma maneira?
Pode ser que o software que acessa os logs e faz a limpeza desses dados
para armazenar no banco de dados só funcione uma vez por hora.
Isso significa que, em produção, na maior parte do tempo, os dados mais
recentes que você terá estarão com uma quantidade incerta de minutos de
atraso.
A solução é construir as suas features e seu modelo adaptando os dados
históricos a essa condição. Você calcularia as features usando apenas dados
20
coletados até a última hora antes da previsão.
Claro que outra alternativa é modernizar a infraestrutura e disponibilizar
esses dados de maneira mais rápida, mas geralmente você não vai ter tempo
de fazer isso durante o projeto.
21
Como os dados foram coletados?
Será que os dados que você está vendo já estavam assim na hora em que
você teria feito a previsão?
Este problema é parecido com o anterior.
Muitas empresas possuem bancos de dados sem registros de modificações.
Ou seja, você só tem acesso ao formato final do registro.
O caso clássico é com dados de perfis de usuários.
Normalmente, o que estamos vendo é a situação atual do perfil, sem saber
exatamente quais foram as mudanças feitas pelo tempo.
Isso aconteceu num problema real que resolvi.
Eu estava tentando prever qual era a probabilidade de um usuário
cadastrado fazer a primeira compra no site.
Quando eu criei a feature “endereço preenchido”, o erro do modelo saltou
para próximo de zero.
Conforme você adquire experiência em machine learning, você sabe que
erro muito próximo de zero (com uma alteração tão pequena), significa que
você fez algo errado.
Avaliando a situação, cheguei à conclusão que, por se tratar de um produto
físico, o cliente que comprava acabava precisando preencher o endereço
para entrega.
22
E o detalhe era: mais de 99% dos usuários não preenchiam o endereço ao se
cadastrar ou antes de fazer uma compra. Preenchiam apenas ao fazer a
compra.
Ou seja, apesar desta informação existir nos dados históricos, ela era
completamente irrelevante no momento em que o modelo faria a previsão
em produção.
Ela não era verdadeiramente capaz de indicar a intenção de compra.
Simplesmente removi as informações de localização do perfil do modelo.
Por isso é importante entender como esses dados chegaram até você.
Além de fazer essa adaptação para o projeto de previsão, a ideia é sugerir
uma mudança na maneira como esses (e outros) dados sejam armazenados
no futuro.
Snapshots
Snapshots são “retratos” de como eram os dados em cada momento.
Existem várias maneiras de implementar este mecanismo em bancos de
dados, mas basicamente a ideia é ter um log de cada mudança que
aconteceu nos registros.
Dessa maneira, podemos acessar os dados exatamente no formato que eles
estavam em um determinado momento do tempo.
23
Como foi criada a amostra de dados? (Selection,
Sampling, Survivorship bias e outros amigos)
Na maioria das empresas, quando acessamos os dados, estamos acessando
amostras que não foram coletadas aleatoriamente.
Isso significa que os dados foram selecionados de uma maneira que pode
ser diferente do que vamos encontrar em produção.
Existem vários exemplos de vieses estatísticos. Mas mais importante do
que saber o nome desses efeitos, é entender como eles acontecem na
prática.
O exemplo clássico de viés vem de uma história da segunda guerra
mundial.
Havia uma equipe tentando entender quais eram as partes mais vulneráveis
dos aviões de combate para que elas pudessem ser reforçadas e o sucesso
neste tipo de batalha aumentasse.
Foram analisados vários aviões e via-se que as asas estavam cheias de
marcas de balas, enquanto a parte da cabine não parecia ser muito atingida.
Apesar de esforços para reforçar as asas, os resultados não melhoravam.
Até que um matemático chamado Abraham Wald (que ficou famoso por
várias contribuições para a estatística) se atentou para o seguinte fato:
Só eram analisados os aviões que retornavam de combate. Os aviões que
caíam no campo de batalha nunca retornavam para a base, ou seja, não
faziam parte da amostra.
24
Sabendo disso ele teve a seguinte ideia: e se reforçarmos as partes que
parecem ser menos atingidas nos aviões que retornam de combate?
Afinal, se um avião é atingido e ainda consegue retornar para a base, essas
áreas não devem ser tão críticas.
Quando começaram a reforçar as partes menos atingidas da amostra de
aviões os resultados positivos começaram a aparecer.
Um outro exemplo bastante usado de “viés de sobrevivência” acontece no
mercado de ações.
Imagine que você tenha dados históricos de 20 anos de todas as empresas
listadas numa bolsa de valores. Antes de revelar o problema, você consegue
identificar algo de errado?
Pare e pense um pouco.
O problema é o seguinte: você tem os dados apenas das empresas que ainda
estão listadas na bolsa. Mas e as empresas que faliram?
Nesse caso, você não possui o mesmo conjunto de empresas que existia em
cada momento do tempo, apenas as empresas que “sobreviveram” aos
últimos 20 anos.
Na minha carreira eu encontrei alguns casos de amostras enviesadas por
seleção.
Num caso em que trabalhei, a tarefa era criar uma solução que pudesse
aprovar novos cadastros automaticamente. A ideia era prever quais
candidatos seriam bem sucedidos na plataforma.
25
Mas aí tínhamos um problema: nós só sabíamos se um candidato foi bem
sucedido se ele foi previamente aprovado pelo sistema atual. E o sistema de
aprovação não era aleatório.
Os candidatos reprovados nunca tiveram a chance de provar se teriam
sucesso ou não.
Nesse caso, sugeri duas alternativas:
1. Permitir que alguns usuários fossem selecionados de forma aleatória
para coletarmos uma amostra representativa da situação real que
queríamos modelar.
2. Criar uma solução com estes dados “incorretos” sabendo que a
performance vista durante o desenvolvimento não seria confiável
como indicador de performance em produção.
É lógico que escolher a primeira opção significaria ter uma queda de
performance nos indicadores de sucesso da empresa, mas isso deve ser
encarado como um custo de coleta de dados.
Na minha experiência, grandes empresas optam pela solução 2.
Principalmente aquelas de capital aberto.
Uma outra área onde esse problema é muito comum é na previsão de
fraudes. Essa fica como um exercício para o leitor: qual é o problema de
dados históricos sobre fraude em transações comerciais?
O mais importante de tudo é você criar um ceticismo saudável em relação a
todas as amostras de dados com que você for trabalhar.
Pare por um momento e se pergunte como essa amostra foi formada e quais
os problemas que ela pode ter.
26
Considere todos os dados “culpados” de ter todo tipo de defeitos até que
você prove que eles não existem.
Mas como você viu acima, defeitos não vão necessariamente te impedir de
criar uma solução. A ideia é você saber quais são eles e como eles devem
afetar seu trabalho.
Dados preconceituosos
Há uma grande preocupação na comunidade de Data Science quanto à
igualdade nas previsões dos modelos.
Como nós estamos usando dados históricos, qualquer preconceito que tenha
sido empregado está implícito nos dados.
Um dos primeiros exemplos disso aconteceu durante o treinamento de um
modelo que procurava capturar associações de significados entre palavras.
No fim, o modelo dava maior probabilidade a um homem de pertencer a
profissões de engenharia e sugeria que mulheres eram mais relacionadas a
tarefas de casa.
Um claro exemplo de um viés preconceituoso.
Esses vieses podem acontecer com vários tipos de características. Então é
importante verificar se o seu modelo vai aprender algum preconceito
contido nos dados históricos.
27
Dados faltando
Existem várias razões para alguns dados não existirem numa amostra.
O mais importante é saber que, normalmente a falta dos dados não é
aleatória. Ou seja, houve algum fenômeno que causou perda de dados de
maneira “determinística.”
Pode ser que o coletor de dados falhou, a rede sobrecarregou e não
conseguiu transmitir as informações.
Existem técnicas, chamadas de imputação dos dados, que substituem os
valores nulos por algum valor válido.
Isso geralmente é definido durante a modelagem.
Neste momento de preparação é importante manter linhas e colunas com
dados faltando e anotar quais são os casos em que isso acontece.
O fato destes valores nulos não serem gerados aleatoriamente significa que
pode haver padrões preditivos baseados nessa informação.
A informação que um sistema de sensores parou de enviar dados pode ser
importante para prever a falha num passo posterior de uma linha de
produção.
Para saber a robustez do seu modelo, verifique como ele reage se uma
coluna tiver uma grande proporção ou todos os valores nulos. Isso pode
acontecer em produção.
28
Valores absurdos
Além da falta de dados, é comum encontrar valores que claramente são
absurdos.
Por exemplo: idades negativas ou usuários com mais de 200 anos. Datas de
compra do produto no ano 3000. Latitude e longitude do endereço no meio
do oceano.
Neste caso você deve entender qual efeito isso terá nos dados. A
informação está comprometida demais para ser usada?
29
Duplicações e pequenas diferenças
Existem duas formas de dados duplicados:
Exatas
Isso acontece quando foram feitos vários registros iguais para uma mesma
entidade dos dados.
Ou temos duas colunas com a mesma informação.
Se a duplicação foi feita por causa de um problema na ingestão dos dados,
basta removermos as linhas em excesso.
Aproximadas
Existem dados que não estão exatamente iguais, mas se referem à mesma
entidade.
Imagine olhar um banco de dados com registros de um cliente:
1. Mario Filho, Documento 1234
2. M. Filho, Documento 123-4
3. Mario, Documento 1234
4. Mario Filho, Documento 1.2.3-4
Isso acontece principalmente em bancos de dados que são preenchidos
diretamente por pessoas, como cadastros.
30
Em alguns casos é possível selecionar algumas colunas mais confiáveis,
como o número de algum documento.
Quando preenchemos o número de nosso documento num cadastro,
geralmente há uma validação do campo que ajuda a impedir esse tipo de
problema.
Raramente alguém conseguirá cadastrar uma pessoa duas vezes, por erro,
com CPFs diferentes. Para isso ela precisaria dar a sorte de errar justamente
os números que ainda validariam o campo.
Claro que isso pode acontecer, mas é raro.
É importante saber quantos registros possuem esse problema. Isso não vai
te impedir de proceder com a modelagem, mas você precisa deixar claro
que pode estar fazendo previsões mais de uma vez para o mesmo caso.
Muitas vezes uma solução criada mesmo com esse tipo de problema já tem
um impacto melhor do que simplesmente não ter solução.
Caso você queira minimizar a incidência deste problema sobre os dados,
existem abordagens simples como calcular a similaridade dos campos do
registro e determinar que acima de um valor eles serão considerados
duplicados.
Existe também a abordagem de criar um modelo de machine learning para
determinar quais casos são duplicados, mas aí você precisará de uma
amostra com os pares de registros e anotações.
O mais importante é saber que o problema existe nos dados e entender
como isso deve afetar o produto final.
31
A regra geral
Como você já deve ter percebido, por mais problemas que você encontre
nos dados, a ideia é seguir em frente.
Os dados nunca estarão exatamente da forma como nós gostaríamos. E
mesmo se estivessem, devemos lembrar que o modelo será usado num
ambiente com novos dados, que certamente não estarão ideais.
O mais importante de tudo é conhecer os problemas de seus dados e saber
como eles podem afetar sua solução.
32
3 MODELAGEM
❧
Agora sim é a hora de pensar em machine learning. Algoritmos, modelos,
ferramentas e métodos.
A ideia desta parte não é te dizer certezas sobre o que funciona na hora de
modelar. Se alguém te prometer isso, esta pessoa está mentindo.
O mais importante é ter uma caixa de ferramentas ampla para que você
possa testar em casos específicos.
Existem alguns métodos que funcionaram melhor na minha experiência,
mas isso não quer dizer que sejam os melhores em qualquer caso.
Aqui eu quero te entregar mais ferramentas.
Teste o máximo de ideias, aplique essas ferramentas aos seus dados e veja
qual é o resultado. Só assim você realmente vai chegar perto da melhor
solução possível para o seu caso.
Vamos começar entendendo quais as abordagens possíveis para resolver o
problema.
33
Tipos de aprendizado
Existem três tipos de algoritmos de aprendizado dentro de machine
learning.
Supervisionado
Este é o mais comum e o que eu vejo agregando mais valor em casos de
empresas.
Nele você precisa ter dados de entrada (geralmente representados por X) e
um ou mais alvos (geralmente conhecido por Y) para cada registro.
Quando você entra em seu e-mail e vê a categoria SPAM, você está vendo
o resultado de um modelo de machine learning supervisionado.
O X neste caso são informações como título do e-mail, remetente, corpo do
e-mail, horário e outros dados que variam em cada provedor.
O Y neste caso é a resposta para a pergunta: este e-mail é spam ou não?
Geralmente usamos o número 1 para representar o caso positivo (spam). E
0 para o negativo (não é spam).
O desenvolvedor deste modelo coletou milhares de e-mails que foram
anotados como spam e outros que não eram spam.
Com isso ele codificou as informações citadas acima de maneira numérica
e treinou o modelo usando um algoritmo.
34
O modelo então foi calibrado para saber relacionar as informações de
entrada (X) com as informações de saída (Y).
Isso significa que sempre que você passar informações no mesmo formato
do seu X original ele vai te dar uma probabilidade deste e-mail ser spam ou
não.
Eu recomendo fortemente que você sempre procure maneiras de usar este
tipo de aprendizado.
Mesmo quando temos poucos dados com as anotações das respostas, ele é
capaz de funcionar melhor do que os outros tipos, já que você está
calibrando o modelo diretamente para o evento que te interessa.
Supervisionado é rei (pelo menos hoje) em machine learning.
Não supervisionado
Este tipo de aprendizado só precisa das informações de entrada (X).
A maneira mais comum de uso é tentar encontrar padrões que possam
agrupar registros semelhantes.
Você encontrará casos de uso com o nome de agrupamento ou clustering.
No caso do SPAM, ele tentaria achar e-mails com títulos, corpo e remetente
similares. Atribuindo-os ao mesmo grupo.
Existem pessoas que recomendam usar este tipo de modelo para resolver
problemas que são mais adequados ao supervisionado: quando você sabe
qual é o alvo que você quer prever, como no caso do spam.
35
Eu evito fazer isso. Apesar destes modelos encontrarem padrões nos dados,
isso não significa que serão padrões úteis para resolver nosso problema.
Uma outra maneira comum de se usar este aprendizado é para reduzir o
tamanho de dados que possuem muitas colunas. Neste caso temos a
redução de dimensionalidade.
Imagine que você tenha registros de todos os sites que uma lista de usuários
acessou enquanto usava seu navegador de internet. Se cada site for uma
coluna e cada usuário, uma linha, teremos uma matriz gigantesca.
Se você tiver mais colunas do que linhas os modelos de machine learning
podem ter dificuldades em encontrar os padrões.
Nesse caso você pode usar um algoritmo para tentar “resumir”, através de
métodos matemáticos, as informações das colunas originais numa
quantidade muito menor.
Na maioria dos casos vale mais a pena treinar um modelo supervisionado
com uma amostra limitada do que o não-supervisionado com uma amostra
grande.
Aprendizado de reforço
O aprendizado mais próximo que temos de como um ser humano aprende é
este.
Nesse caso o modelo é colocado num ambiente (normalmente simulado) e
deve aprender quais ações executar de acordo com as características da
situação.
36
Quando o modelo executa uma sequência de ações corretas, ele recebe uma
recompensa.
Se você já ouviu falar de programas de inteligência artificial que venceram
pessoas em jogos como Damas, Xadrez e Go, já viu uma aplicação deste
aprendizado.
No caso mais famoso atualmente, que é do AlphaGo, parte do sistema foi
treinada através de milhões de simulações de um tabuleiro do jogo onde o
algoritmo disputava a partida contra uma versão dele mesmo.
Nesse caso, o modelo aprendia, de acordo com a situação do tabuleiro,
quais eram os movimentos que ele deveria jogar para vencer.
O caso mais comum do uso deste tipo de aprendizado nas empresas é para
otimizar páginas de venda.
Imagine que você tenha três versões de uma página de seu produto e queira
que a melhor versão seja ajustada dinamicamente.
Na maior parte do tempo o algoritmo vai mostrar a página que faz mais
vendas, mas ele continuará testando as outras páginas para o caso de uma
delas se tornar a melhor.
Apesar de ser muito atraente e promissor, este tipo de aprendizado é
bastante difícil de fazer funcionar na prática. Geralmente ele precisa de
uma amostra muito grande de dados e mesmo assim ainda pode falhar.
37
Definir seu alvo
Procure saber as regras do processo que você está
modelando
O alvo geralmente será uma parte de um processo.
Se nós estamos modelando a probabilidade de um cliente comprar um
produto, existe todo o processo de descoberta do produto até a venda.
Idealmente queremos modelar diretamente o objetivo mais relevante para a
métrica de negócio, mas isso nem sempre é possível.
No caso da modelagem acima, se tentarmos atribuir o alvo como vendas
diretamente, teremos uma quantidade muito pequena de exemplos positivos
(usuários que realmente compraram após a nossa ação).
Por isso precisamos entender quais são os outros passos até o objetivo e
verificarmos a possibilidade de usá-los como alvo.
Continuando na modelagem acima, uma outra possibilidade seria modelar a
chance do usuário clicar no link para a página do produto.
Isto resolve nosso problema de frequência, já que o evento clique é muito
mais comum do que a compra. Mas aí surge outro problema.
O clique é um sinal confiável de compra? Ele é bem correlacionado com a
compra? Geralmente não tanto quanto gostaríamos.
38
Temos dois extremos: um sinal forte, mas pouco frequente, e um sinal
fraco, mas muito frequente. Qual o passo intermediário?
Como outras pessoas resolveram esse problema?
Dificilmente você será a primeira pessoa a tentar resolver um problema
usando machine learning. E mesmo se for, certamente existem problemas
relacionados que podem te ajudar.
Por isso, procure trabalhos acadêmicos, postagens em blogs, vídeos,
soluções de competições, que falem sobre como este mesmo problema ou
um problema similar foi resolvido.
Eu aprendi, por exemplo, que quando estamos lidando com um problema
que envolve texto, podemos buscar casos de aplicação de machine learning
na área de sequenciamento genético.
Apesar de ser uma área diferente, os dados genéticos são coletados como
sequências de caracteres. Textos são, em sua essência, sequências de
caracteres também. Então várias técnicas podem ser reutilizadas.
No nosso caso, após verificar como outras pessoas resolveram o problema
da previsão de compra do produto, descobrimos que existe um alvo
intermediário: o tempo que o usuário passou na página.
Quando queremos comprar alguma coisa, geralmente vamos ler a
descrição, especificações técnicas e opiniões de outros clientes. Enfim,
passaremos mais tempo na página do que se não tivéssemos o interesse de
compra.
39
Prever quanto tempo o usuário vai passar na página do produto
recomendado pode ser o alvo que procurávamos. Mais frequente que a
compra e mais forte indicador de interesse do que o clique.
Toda essa história é justamente para dizer que a melhor forma de você
encontrar qual alvo modelar é basicamente: entender todos os passos do
processo que você está modelando e procurar como as pessoas resolveram
o problema em outros casos.
Se você ler as entrevistas dos maiores vencedores de competições de
machine learning, isso é algo que você vai encontrar em comum: todos
procuram saber quais são os métodos que geralmente são usados para
resolver o problema da competição.
Mistura de alvos
Quando você tem vários alvos com características diferentes, mas
interessantes, como foi mostrado no caso acima, você também pode criar
um alvo sintético com base nas informações dos originais.
Imagine que para cada par de produto e cliente, nos dados históricos,
exista:
1. Indicador de visualização (0 = cliente não viu o produto, 1 = cliente
viu o produto numa lista)
2. Indicador de clique (0 = cliente viu mas não clicou, 1 = cliente clicou)
3. Tempo que o cliente passou na página
4. Indicador de compra (0 = cliente entrou na página mas não comprou, 1
= cliente comprou)
Nosso alvo pode ser uma média ponderada destes eventos.
40
Y = 1 * visualização + 5 * clique + 30 * tempo_na_página + 100 *
compra
Estes número são apenas para demonstração.
Os números otimizados para cada caso devem ser encontrados durante o
desenvolvimento do modelo medindo como o Y criado se relaciona com o
objetivo final.
Pode ser que um modelo treinado usando uma fórmula como esta consiga
capturar melhor a intenção de compra, mas isso não é garantia.
41
Regressão e Classificação
Regressão
Imagine que você esteja prevendo o número de acessos que uma página
terá na semana que vem.
Você está prevendo uma quantidade.
No machine learning isso significa que você fará uma regressão.
Quando você tiver um conjunto de números como alvo, e exista uma forma
de ordená-los, é muito provável que se encaixe numa regressão.
A ordem não precisa ser apenas em uma dimensão. Altura é um valor que
possui uma ordem de maior ou menor.
Mas e se estivermos falando de latitude e longitude? Ou posição de um
objeto em geral? Nesse caso fica muito mais fácil pensarmos no alvo no
contexto de espaço.
De qualquer maneira, estamos falando de quantidades.
Classificação
Imagine que você esteja prevendo qual é o aplicativo mais adequado para
recomendar a um usuário. Neste caso não existe uma ordem natural entre
os aplicativos antes da previsão.
42
Para ter uma ordem nós precisaríamos atrelar alguma quantidade (número
de downloads, tamanho, avaliações positivas, etc).
Neste caso estamos falando de uma classificação. Você quer prever em qual
“caixinha” o seu usuário se encaixará melhor.
Nós podemos ter duas caixinhas, no caso de classificação binária, ou muitas
caixinhas, que chamamos de classificação multiclasse.
No caso dos aplicativos teremos centenas, talvez milhares de opções para
prever, então calculamos a probabilidade do usuário gostar de cada uma
dessas opções.
Já no caso do spam, só precisamos classificar se o e-mail deve ficar na
caixa de spam ou na caixa de entrada.
Ranking
Uma área que tem crescido bastante é o desenvolvimento de algoritmos
para modelar ranking.
Em vez de considerarmos cada opção isoladamente, consideramos todas no
mesmo contexto.
Nem sempre a modelagem direta do ranking bate a modelagem de
classificação simples usando múltiplas classes, mas é uma alternativa
interessante a se considerar.
Muitos alvos com um valor só
43
Existem casos em que queremos fazer uma regressão e temos muitos
exemplos com um valor específico.
Geralmente esse valor é zero.
Quando estamos prevendo potencial de compra, queremos saber a
quantidade de dinheiro que a empresa espera receber durante o
relacionamento com o usuário, caso ele venha a se tornar um cliente.
Como você deve imaginar, a maioria dos usuários, historicamente, não
compra nada. Ou seja, o valor para eles é zero.
Se você tentar modelar este tipo de tarefa com os métodos tradicionais, seu
modelo vai puxar as previsões absurdamente para perto de zero.
Mas existem duas alternativas que eu recomendo.
Modelagem em dois passos
No primeiro passo criaremos um modelo que simplesmente preveja se o
usuário vai comprar alguma coisa. Um problema de classificação binária.
Atribuímos o alvo positivo a todos os usuários que fizeram alguma compra
e o alvo negativo aos outros.
No segundo passo criaremos um modelo que prevê o valor que esperamos
receber do usuário caso o primeiro tenha previsto que ele fará uma compra.
Uma regressão.
Pode parecer confuso no momento, e realmente é um tópico mais complexo
do que nosso escopo aqui, mas é uma abordagem que funciona muito bem
na prática
Usando uma função objetivo própria
44
Na hora de treinar o modelo podemos otimizar algumas funções que são
feitas pensando em casos em que a maioria dos exemplos terá valor zero.
Estas funções estão implementadas em ferramentas como LightGBM e
podem ser úteis para o seu caso específico.
Teste as duas maneiras, levando em consideração outros fatos como a
dificuldade de colocar a solução em produção, e veja qual é a mais
adequada.
45
Previsão de mais de um alvo ao mesmo tempo
Muita gente confunde classificação em múltiplas classes com tarefas
multioutput (numa tradução literal, multisaída).
Nesta modelagem vamos prever vários alvos para um mesmo exemplo,
diferente da classificação multiclasse, onde prevemos apenas um alvo (uma
caixinha) para cada exemplo.
Imagine que você esteja criando um modelo para prever em quais
categorias se encaixa um artigo jornalístico. Ele pode ser sobre futebol ao
mesmo tempo em que fala do Brasil e da Copa do Mundo.
Ou seja, os três alvos estão corretos. Queremos prever que ele faz parte de
todos.
Isso aconteceu numa competição das agências de inteligência do governo
britânico (MI5, MI6, sim, aquelas do James Bond). A tarefa era prever,
usando artigos do jornal The Guardian, quais eram os temas de que eles
tratavam.
Mas também podemos ter tarefas multisaída que sejam de regressão.
Uma outra competição, esta aconteceu no Kaggle, tratava de prever qual a
localização final (latitude, longitude) de uma viagem de táxi na cidade do
Porto em Portugal, dependendo de onde ele estava iniciando a trajetória.
Nesse caso foi necessário usar regressão para prever as quantidades latitude
e longitude.
46
Big Data vs Small Data
Apesar de muito se falar em Big Data, costumo pensar que amostras
grandes são um problema de engenharia, enquanto amostras pequenas são
um problema estatístico.
Big Data
Em termos de modelagem, mais dados tendem apenas a facilitar seu
trabalho. O problema é fazer as computações necessárias gastando pouco
dinheiro e tempo.
A melhor solução que encontrei até agora é selecionar a maior amostra
possível dos dados e rodar os experimentos em um computador com
bastante memória e CPUs (ou GPUs, no caso de redes neurais) na nuvem.
Quando falo de Big Data, me refiro a terabytes de dados. Bilhões de linhas
para processar.
Dezenas ou centenas de milhões de linhas podem ser processadas com certa
facilidade e baixo custo nos recursos de nuvem disponíveis hoje.
Você não precisa usar todos os dados disponíveis para criar um modelo.
Se temos 100 milhões de linhas, podemos pegar 100 mil para treino e 100
mil para validação, treinar o modelo e anotar o resultado.
Depois podemos pegar 200 mil linhas para treino, treinar o modelo, avaliar
nas mesmas 100 mil linhas de validação. Anotar o resultado.
47
É importante manter o mesmo conjunto de dados de validação! Se você
mudar este conjunto de dados a sua comparação entre os resultados de
tamanhos de treino diferentes fica menos confiável.
Como é regra em experimentos, queremos testar apenas uma variável: o
tamanho dos dados de treino.
Se você seguir aumentando o número de linhas de treino, em algum
momento vai notar que a sua métrica de erro muda pouco. Pode ser que
treinar o modelo com 2 milhões de linhas melhore apenas 0.01% da sua
métrica quando comparado ao erro treinando com 1 milhão de linhas.
Isso significa que você não precisa de uma amostra maior que 1 milhão de
registros.
Se ainda assim você quiser usar mais do que 1 milhão de linhas, você deve
obter um resultado melhor treinando modelos sobre amostras diferentes
com o mesmo tamanho e juntando num Ensemble (que explico mais à
frente).
Small Data
Os maiores problemas que já encontrei em termos de modelagem caem
nesta categoria: amostras de dados muito pequenas.
Quantas linhas podem ser consideradas poucas? Depende do nível de
dificuldade da previsão.
Em dados que mudam rapidamente e possuem poucos padrões verdadeiros,
como dados do mercado de ações, você pode ter milhões de linhas e ainda
48
não conseguir uma previsão muito melhor que algo simples como prever
zero para todos os exemplos.
Já em outros casos, como fenômenos físicos, você pode ter algumas
centenas de exemplos e já conseguir um resultado muito bom.
E se existirem muitos registros, mas poucos anotados com o alvo que você
quer?
Active Learning
Esta é uma forma muito inteligente de conseguir anotações quando estas
custam muito caro ou demandam muito tempo.
Imagine que você queira criar um sistema de diagnóstico de doenças
baseado em resultados de exames de imagem. Cada exemplo exige que um
ou mais médicos avaliem e anotem se a doença está presente.
Se tivermos acesso a 10 mil imagens, mas apenas 500 anotadas, não
precisamos anotar todas as 9500 de uma vez para ter um modelo.
Podemos treinar um modelo nessas 500 imagens, fazer a previsão para as
outras 9500 e selecionar as imagens nas quais o modelo esteja com mais
dificuldade.
Vamos supor que nosso orçamento só permita anotar mais 500 imagens.
Podemos selecionar as 400 imagens com previsão mais próxima de 50% e
100 imagens aleatoriamente dentre as que restaram.
Por que 50%? Esses casos são aqueles em que o modelo está mais incerto
se deve classificar como positivo ou negativo. Isso sugere que os exemplos
anotados atuais não informam muito bem sobre esta situação.
49
E por que 100 imagens aleatoriamente? Apesar de querermos selecionar a
maioria de imagens como aqueles casos que são mais difíceis para o
modelo, se focarmos apenas neles podemos enviesar o modelo.
Podem (e provavelmente devem) existir padrões que nem sabemos que são
problemáticos pelo simples fato do modelo não ter sido exposto a eles.
Com a parte aleatória da amostra estamos tentando evitar surpresas com
esses casos.
Poucos exemplos em geral
É difícil dizer qual modelo vai funcionar melhor antes de efetivamente
testar. Ainda assim, modelos lineares tendem a funcionar melhor quando
temos amostras pequenas.
O bom dessas amostras é que se pode testar muita coisa rapidamente, então
teste tipos de modelos diferentes e veja qual funciona melhor em seu caso
específico.
50
Defina uma baseline
Todo projeto de data science deve ser comparado a um valor base.
Chamamos esse valor de baseline.
Sua baseline pode ser, por exemplo, uma estatística simples calculada sobre
seu alvo, ou prever todos os exemplos como zero ou ainda a performance
da solução atual que a empresa esteja usando.
Nossa solução deve ser melhor que a baseline, senão não temos justificativa
para passar por todo o processo de colocar e manter o sistema em produção.
No caso de recomendação, a baseline normalmente é quanto de vendas são
feitas se simplesmente recomendarmos os livros mais vendidos do período
anterior.
Se toda semana eu enviar um e-mail para os clientes recomendando os
livros mais vendidos da semana passada, qual é o meu número de vendas
nesta semana?
É este número que você deve bater quando criar o sistema de
recomendação.
Se eu quiser prever o retorno de uma ação no dia seguinte: qual seria meu
lucro se eu simplesmente comprar essa ação no início do meu período de
validação e vender no final?
O sistema de machine learning precisa dar mais lucro que isso após
computar todos os custos de transação.
51
Lift
Uma forma muito simples de saber quão bom é um modelo, e muito usada
em marketing, é o Lift.
Basicamente consiste em dividir o valor de sua métrica, calculada com a
solução de data science, pelo valor da baseline.
Imagine que, para os 10 mil e-mails enviados com a recomendação dos
produtos mais vendidos na semana passada, eu consegui vender 1000 reais.
Em outra amostra de 10 mil e-mails você enviou recomendações feitas pela
sua solução de machine learning, e vendeu 1500 reais.
Para saber qual foi o “Lift” você simplesmente calcula 1500/1000 = 1,5.
Ou seja, sua solução provocou um aumento de 50% nas vendas.
Sempre estamos procurando um Lift acima de 1.
Se ele estiver igual a 1, significa que sua solução não melhora nada. Se ele
for menor que 1, sua solução é pior do que a atual.
52
Feature Engineering
Para treinar um modelo de machine learning, você precisa de uma
representação numérica das informações sobre o fenômeno que quer
modelar.
Cada variável que calculamos sobre essas informações, e que será colocada
no modelo, chama-se feature.
O nome dessas variáveis de entrada pode mudar de acordo com o campo de
aplicação. Alguns nomes são: covariada, variável de entrada, variável
exógena, variável independente, regressores, fatores, preditores,
características.
Fontes diferentes
Existem duas maneiras muito importantes de pensar na criação de features.
Uma delas é a fonte da informação.
Para ter um bom modelo você precisa ter fontes de informação que sejam
relacionadas ao alvo que quer prever.
Quanto mais fontes de informação diferentes você tiver, melhor.
Para prever vendas, além de usar as características da empresa, você
também pode colocar informações dos produtos, do clima, promoções da
concorrência, indicadores econômicos.
53
Todas essas são fontes diferentes de informações que podem nos ajudar a
prever o valor final de vendas com maior acerto.
Representação das informações
Além de conseguir fontes diferentes, é importante ficar atento à
representação destas informações no modelo.
Eu costumo pensar em modelos como “seres” com pouquíssima
inteligência. Precisamos entregar as informações da forma mais clara
possível ou ele não vai entender direito o que queremos.
Existe uma infinidade de maneiras de representar as informações, mas
todas elas acabam recebendo alguma conversão em formato numérico.
Quando a informação é numérica, geralmente você pode colocá-la em sua
forma original no modelo sem problemas.
No caso de regressão, também podemos aplicar transformações no nosso
alvo para mudar a maneira como o modelo enxerga a relação com as
variáveis de entrada.
Transformações
Existem transformações simples que podemos aplicar em variáveis
numéricas para torná-las mais estáveis, principalmente quando estamos
lidando com modelos que multiplicam valores para chegar à previsão
(redes neurais e modelos lineares).
54
As transformações mais comuns são o logaritmo e a raiz quadrada. Basta
aplicar à variável desejada.
No caso da raiz, podemos ir além da quadrada, e isso pode ser um
parâmetro para otimizarmos. Nesse caso calculamos a variável numérica
elevada à fração 1/n, sendo n a raiz desejada.
Em uma competição para precificar tubos de metal, a melhor solução do
nosso time previa a raiz 17 do alvo.
Scaling
Modelos lineares e redes neurais podem ter dificuldades em achar soluções
para variáveis com distribuições incomuns de valores.
Geralmente é um procedimento padrão fazer algum tipo de scaling ao
treinar estes tipos de modelos.
Scaling basicamente consiste em transformar a sua variável original de
maneira que ela adquira alguma característica, como ter todos os valores
entre um e zero, -1 e 1 ou ter média zero e desvio padrão igual a um.
A forma mais comum de se fazer isso (e que sempre funcionou melhor nos
meus testes) é com a última opção: subtrair a média e dividir pelo desvio
padrão.
Hoje as bibliotecas disponíveis fazem isso de forma muito simples, além de
oferecerem várias outras opções de scaling.
É importante testar e descobrir qual funciona melhor no seu caso.
55
Categorias
Quando temos informações que não são numéricas, como CEP, cor, tipo de
produto, página do site, podemos considerá-las como categorias da
entidade que queremos modelar.
Em geral esse tipo de variável não possui uma ordem natural. Não dá para
dizer que a cor azul é maior que a cor verde sem atribuir alguma
característica numérica.
O mais natural seria substituir cada valor original por um número.
Chamamos isso de transformação ordinal.
O problema é que você acaba criando uma ordem fictícia nos dados, e
alguns modelos podem se atrapalhar tentando capturar isso. Os modelos
mais resistentes a esse tipo de problema são as árvores de decisão.
Uma outra maneira é substituir o valor original pelo número de vezes que
ele aparece nos dados. Se esta informação tiver valor preditivo, isso acaba
ajudando bastante o modelo.
Saber a quantidade de anúncios que existe numa categoria pode ajudar o
modelo a entender que categorias de produtos com mais anúncios tendem a
ter maior chance de ter anúncios duplicados.
Outro caso seria encontrar pessoas com vários cadastros através da
contagem de vezes que o IP do usuário apareceu em todos os registros. O
mesmo IP em contas diferentes é suspeito.
A forma mais comum de se codificar esse tipo de variável chama-se One-
Hot Encoding.
56
Neste caso, cada valor ganha uma coluna própria, na qual as linhas que
tiverem esse valor recebem o número 1, e as outras, 0.
Essa é a maneira mais genérica, que tende a funcionar bem com qualquer
tipo de modelo.
Existem duas maneiras mais avançadas que têm se tornado populares:
O Target Encoding, que consiste em calcular, numa amostra separada dos
dados, uma média do alvo para os exemplos que pertencem a uma
categoria. Nesse caso deve-se substituir o valor original pela média
calculada.
A outra maneira é usar Embeddings. Neste caso treina-se um modelo que
cria uma representação numérica para cada valor original da variável. Em
vez de termos um número só, esta técnica tenta entender como o valor se
encaixa em dimensões comuns a todos os valores da categoria.
Se estivermos falando de filmes, podemos imaginar o Embedding como
uma representação numérica tentando capturar quanto o filme possui de
ação, drama, comédia. A diferença é que o modelo tenta aprender isso
sozinho, baseando-se apenas nos relacionamentos entre os filmes.
Texto
A representação mais comum para texto chama-se Bag of Words, e é bem
parecida com a ideia do One-Hot Encoding.
Basicamente cada palavra (ou combinação de palavras) se torna uma
coluna na matriz. O valor de cada linha nesta coluna pode ser binário, o
57
número de vezes que a palavra aparece no documento representado na linha
ou uma combinação de fatores mais complexa.
A combinação mais famosa chama-se TF-IDF. Neste caso temos um
coeficiente que combina o número de vezes que a palavra aparece em cada
documento com o número de vezes que essa palavra aparece em todos os
documentos.
A ideia é dar mais peso para palavras que apareçam bastante no documento
da linha, mas pouco no total dos documentos modelados. Tende a funcionar
muito bem na prática!
Time Series
Sequências temporais, ou qualquer tipo de sequência, nos trazem a
possibilidade de carregar informações do passado com várias
representações diferentes.
Veja o guia de time series que veio como bônus ao comprar este e-book.
Valores Nulos
As abordagens tradicionais para tratar valores nulos sugerem que eles
sejam substituídos pela média, mediana ou valor mais frequente das linhas
que estão preenchidas.
Na prática eu recomendo usar duas outras alternativas:
1. Substitua os valores nulos por um valor que não esteja presente
naquela coluna dos dados, se o seu modelo for de árvores de decisão.
58
Dessa maneira você está informando o modelo que aquele valor é
diferente de todos os outros.
2. Use modelos que considerem valores nulos nativamente. Modelos
como LightGBM possuem suporte nativo para valores nulos. Isso
significa que estes valores terão um tratamento especial. O efeito é
muito parecido com o da primeira alternativa.
59
Seleção de features
Quando você começar a criar features, vai ver que se deixar a criatividade
solta, pode criar dezenas de milhares delas. E isso é muito bom.
O problema é que a maioria delas não vai ajudar o modelo. Pode ser
simplesmente porque o modelo não consegue lidar com tantas colunas, ou
que muitas delas são redundantes.
Neste caso podemos usar um mecanismo de seleção de features para
reduzir esta quantidade e tentar melhorar a performance do modelo.
Nem sempre um modelo vai melhorar se reduzirmos as features, mas essa
não é a única razão para fazer uma redução.
Se precisarmos rodar o modelo rapidamente em produção ou reduzir a
complexidade para implementar, pode ser que só seja possível calcular 100
ou 200 features.
Dentre as dezenas de técnicas, existem três tipos que eu costumo
recomendar. Você não precisa escolher apenas uma, pode combinar entre
elas.
Backward e Forward Selection
Se você tem tempo, esta é provavelmente a melhor opção.
Você pode começar com todas as features e tentar reduzir (backward). Ou
começar com uma feature e tentar aumentar o conjunto (forward).
60
Se o conjunto original é muito grande, eu recomendo fazer da segunda
maneira. Se você tem muito poder computacional, tempo e quer o melhor
resultado (em competições) use a primeira.
Se tivermos 100 features e escolhermos usar a primeira alternativa:
primeiro calculamos qual é a melhor delas treinando um modelo usando
cada feature isoladamente e guardamos o resultado.
Aí no segundo passo nós criaremos um modelo usando a melhor feature do
primeiro passo em combinação com cada uma das outras. Ou seja,
treinando 99 modelos e anotando o melhor resultado usando apenas duas
variáveis.
Vamos aumentando o conjunto de features, fazendo isso até não
encontrarmos mais nenhuma que ajude o modelo.
No caso da eliminação (backward) o procedimento é quase o mesmo, mas
começando com o conjunto completo.
Treine um modelo com as 100 features. Depois treine 100 modelos usando
99 features, cada vez eliminando uma das 100 originais. Anote qual é a
feature que, eliminada, ajuda mais o modelo em relação ao conjunto
completo.
No segundo passo, agora com 99 features, faça o mesmo procedimento. E
assim vai, até termos um conjunto de features que, se eliminarmos mais
alguma, o modelo piora.
Filtro
61
Neste caso você usará alguma função que servirá para filtrar as features
mais importantes.
Geralmente é usada a correlação para regressão ou o information gain para
classificação. Mas essa não é a maneira que funciona melhor na minha
experiência.
Em vez de usar uma função simples, você pode treinar um modelo que te
diga quais foram as features mais importantes para prever o alvo e
selecionar uma quantidade delas.
Se tivermos 100 features, podemos treinar uma Regressão Linear e
selecionar as 20 features com os maiores coeficientes absolutos (lembre-se
de fazer o scaling antes).
O modelo que eu gosto de usar neste caso é baseado em árvores de decisão:
uma Random Forest.
Para encontrar o melhor ponto de corte você pode testar números diferentes
em seu processo de validação. Trate esse número como outro
hiperparâmetro de sua solução.
62
Métricas de avaliação (técnicas)
Existe uma infinidade de maneiras de calcular o erro/acerto de seu modelo,
mas as mais populares já resolvem boa parte dos problemas.
Classificação
Na classificação existe a acurácia, que é basicamente a taxa de acerto, mas
eu recomendo que você passe longe dela. Existem métricas muito
melhores.
Em vez da acurácia você pode usar a precisão, recall e a combinação destas
duas, o F1 score.
A precisão responde: de todos os exemplos que o modelo previu como
pertencendo a uma classe, quantos ele acertou?
Se você tem um conjunto de 100 e-mails e o modelo diz que 10 deles são
spam. Quantos realmente eram spam? Digamos que 2 eram spam. Isso
significa que a precisão do modelo é de 20% (2 / 10).
Em resumo, se o seu modelo diz que um e-mail é spam, existe 20% de
chance dele realmente ser spam.
O recall pode ser entendido como a taxa de detecção: de todos os exemplos
desta classe, quantos meu modelo encontrou?
No caso do spam, se dos 100 e-mails que temos, 20 deles forem spam,
quantos nosso modelo previu como spam? Digamos que o modelo previu
63
10 deles como spam. Significa que ele detectou 50% (10 / 20) do que
poderia em condições perfeitas.
O F1 Score reúne essas duas métricas em uma média harmônica. Eu estou
evitando colocar equações neste livro, mas você pode encontrar a fórmula
facilmente na internet.
Normalmente se usa o F1 Score quando tanto a precisão quanto o recall são
importantes. Maximizando o F1 Score você maximiza essas duas métricas
de maneira equilibrada.
As métricas acima exigem que você tenha um ponto de corte. Elas não
aceitam pontuações ou probabilidades. Você precisa efetivamente passar a
classe a que cada exemplo pertence.
Mesmo quando quero melhorar essas métricas, eu prefiro usar alguma outra
que eu possa calcular usando probabilidades. E existem duas (ou três) que
servem para isso.
A primeira delas é o ROC-AUC. Quando digo que são possivelmente três,
é porque existe uma métrica muito parecida com esta, que é a AUPRC.
Basicamente elas vão criar uma curva baseada em vários pontos de corte
possíveis para suas previsões e te dar um número indicando a qualidade do
modelo “independente” do ponto de corte que você escolher.
Em vez de tentarmos maximizar a performance do modelo para um
determinado ponto, estamos melhorando o modelo “em geral”.
Eu gosto dessas métricas justamente porque eu posso melhorar meu modelo
sem ter que me prender a um ponto de corte que pode não ser o ideal.
64
Se for necessário ter um ponto de corte, ele pode ser selecionado depois,
sabendo que o modelo funcionaria bem nele ou em seus vizinhos.
Muita gente têm dificuldade em entender ROC-AUC, assim como eu tive,
até encontrar a seguinte explicação:
Imagine que tenhamos duas caixas numa classificação binária: uma com
todos os nossos exemplos positivos e outra com todos os negativos. Cada
exemplo é um envelope que contém a previsão feita por nosso modelo.
Se eu pegar, aleatoriamente, um envelope da caixa positiva e um da caixa
negativa, qual é a chance do envelope positivo ter um número maior do que
o envelope negativo?
Dessa forma dá pra entender que essa é uma métrica muito mais
preocupada em garantir que os exemplos positivos estejam com uma
previsão maior do que os negativos em vez de capturar a taxa de ocorrência
deles na realidade.
A outra métrica muito comum é a log loss. Nesse caso queremos punir
previsões erradas que tenham alta probabilidade.
O mais importante de saber sobre essa métrica é que, diferente da ROC-
AUC que está mais preocupada com a ordem das previsões, aqui estamos
querendo aproximar a previsão da probabilidade real do alvo acontecer.
Se eu quero prever a probabilidade de um time de futebol ganhar uma
partida para calcular qual o valor que posso esperar de retorno numa
aposta, eu quero a taxa dessa ocorrência na realidade.
Isso simplesmente significa que, se de 10 partidas o time ganha 4, eu quero
que meu modelo me retorne 0,4. Ou seja, o quanto eu realmente posso
esperar que o evento previsto aconteça.
65
Já no caso do spam, não me importa prever exatamente qual a chance de
ser spam, mas eu quero que o modelo preveja um valor maior para os e-
mails que forem spam do que para os normais.
Por que é importante diferenciar estes dois casos (ROC-AUC vs Log
Loss)?
Existem métodos, algoritmos e modelos que vão favorecer a otimização de
uma dessas métricas e piorar a outra.
É importante entender o que é mais adequado para a tarefa que você quer
modelar: saber a probabilidade “exata” ou garantir que as maioria das
previsões positivas esteja acima das negativas.
Regressão
A métrica mais comum é o RMSE (traduzido: Raiz Quadrada do Erro
Médio Quadrado). Essa métrica vai elevar os erros ao quadrado.
Prever que serão vendidas 3 unidades de um produto, quando a previsão
certa seria apenas 1, nos dá um erro igual a 4 (2 x 2). Se a previsão fosse 4,
o erro seria igual a 9 (3 x 3). Ou seja, o erro mais que dobrou ao prevermos
apenas uma unidade a mais.
Se valores extremos não forem tão importantes quanto acertar valores
próximos do centro do intervalo (mediana), podemos usar o MAE (Erro
Médio Absoluto).
Nesse caso o erro é igual ao valor absoluto da diferença entre a previsão e a
realidade. Uma previsão 3, para um valor real 1, tem erro igual a 2. A
previsão 4, para o mesmo valor real, tem erro igual a 3.
66
Por não termos uma penalização que eleva o erro ao quadrado, os valores
extremos perdem importância.
A escolha entre valor absoluto ou quadrado deve ser feita entendendo qual
a importância de prever corretamente os valores extremos.
Na prática eu gosto de monitorar os dois erros, pois eles me dão visões
diferentes de como meu modelo está funcionando. Mudanças que
provoquem a redução dos dois erros tendem a ser mais robustas, confiáveis.
Mudanças que melhoram um dos erros e pioram o outro são ótimas
indicações de casos a investigar.
Por que este modelo melhorou bem o erro quadrado mas piorou o erro
absoluto? O que ele está capturando de diferente? Como essa feature afetou
as previsões mais próximas do meio do intervalo?
Em casos que a porcentagem do erro seja mais importante do que essas
métricas “absolutas” (lembrando que podemos usar o lift em todos esses
casos), podemos usar uma variação do erro quadrado para treinar o modelo.
O RMSLE (Raiz Quadrada do Erro Médio Quadrado do Logaritmo) é uma
aproximação do MAPE (Erro Médio Percentual Absoluto).
Este erro mede a diferença percentual entre a nossa previsão e a realidade.
É bastante útil ao prever vendas por ser mais fácil de interpretar e explicar.
Se eu previ que venderíamos 120 itens, mas vendemos 100, temos um erro
de 20%. Se eu calcular a diferença entre o logaritmo natural de 120 e 100, o
erro fica por volta de 18%, que é próximo o bastante do valor do erro
percentual original.
67
Os modelos geralmente precisam de funções matemáticas com certas
características que não temos no caso do MAPE, por isso que modelar com
o RMSLE se tornou uma alternativa popular, já que este possui as
propriedades necessárias.
Por último, uma métrica que gosto de monitorar também é a correlação.
Seja ela a comum (Pearson) ou entre os rankings (Spearman).
Como escolher uma métrica
Não escolha uma, use várias.
Como falei acima, cada métrica vai te dar uma visão diferente sobre o
comportamento do seu modelo. Em vez de confiar apenas em um número,
monitore 3 ou 4 deles.
Seus modelos ficarão muito mais confiáveis.
Existem muitas outras métricas que você pode encontrar na internet. O
mais importante é entender quais são as vantagens e desvantagens de cada
uma para usá-las como sinais na hora da avaliação do modelo durante o
desenvolvimento.
68
Modelos mais utilizados na prática
Conjuntos (Ensembles) de árvores
Modelos baseados em árvore de decisão estão cada vez mais populares.
Eles exigem quase nenhum pré-processamento dos dados e funcionam
muito bem com dados estruturados.
Dados estruturados são aqueles que a gente costuma ver em bancos de
dados SQL. Possuem uma estrutura natural de campos e valores. Dados
tabulares se encaixam nessa categoria.
Alguns exemplos são: bancos de dados de perfis de clientes, produtos,
preços de ações, posts de redes sociais, controle de acesso, pedidos.
O mais popular é a Random Forest. Basicamente é uma forma de criar um
conjunto de árvores em partes diferentes da amostra, usando apenas uma
porção das colunas de cada vez, para capturar padrões diferentes e
específicos.
Isso varia um pouco de acordo com a implementação, mas cada árvore
recebe uma amostra com reposição (bagging) e cada divisão (split)
seleciona apenas um conjunto de features para encontrar o melhor ponto de
corte.
Ao fazer uma média das previsões dessas árvores individualmente
especializadas temos um resultado muito bom para a amostra completa.
69
Meu modelo preferido é o Gradient Boosted Decision Trees (também
conhecido como GBDT). Este modelo poderoso é parte significativa das
soluções vencedoras em competições de machine learning.
Eu explico como ele funciona (boosting em geral) na parte de ensembles no
final desse capítulo.
Tanto na Random Forest quanto no GBDT é importante usar uma
quantidade grande de árvores (no mínimo 100), pois isso dá mais
estabilidade às previsões.
Um detalhe pouco falado, mas problemático, dos ensembles de árvores é
que você pode fixar uma seed do gerador de números aleatórios, mas ainda
assim ter resultados diferentes.
Se você tem 10 colunas e fixa a seed em 0. Vamos imaginar a primeira
árvore. Digamos que quando passamos os valores de 1 a 10, foram
selecionadas as colunas 1, 2 e 3 para criar o primeiro split. Até aí tudo bem.
Agora você resolveu testar uma feature nova, e aumentou o número de
colunas para 11. Quando você fizer o sorteio, mesmo usando a mesma seed,
agora de 1 a 11, ele vai selecionar colunas diferentes.
Parece óbvio, mas isso pode fazer um modelo parecer melhor simplesmente
porque deu mais sorte na hora de pegar as colunas com a nova seed. E
quando falamos de centenas de sorteios dessas colunas, isso pode ser um
problema.
Esse problema também acontece em redes neurais e o efeito pode ser ainda
maior.
Se você simplesmente treinar o modelo com uma ordem diferente nas
colunas esse problema já acontece.
70
Para reduzir esse problema, você pode usar a técnica de média de seeds que
eu explico na parte sobre ensembles.
É esse tipo de coisa que eu quero dizer quando falo que competições
ensinam a gente a entender mais profundamente os modelos.
Modelos lineares
Os modelos mais simples como regressão linear e regressão logística são
exemplos de modelos lineares.
Matematicamente eles procuram a melhor linha (ou hiperplano, quando
estamos falando de muitas dimensões) que explique ou separe os seus
dados.
Justamente por isso eles acabam não tendo a complexidade necessária para
capturar padrões sofisticados que modelos de árvores e redes neurais são
capazes.
Mas essa “desvantagem” pode ser útil quando temos poucos dados. O fato
deles não conseguirem capturar padrões complexos os ajuda a evitar
capturar padrões que só existem na amostra de treino por “sorte” e nos
atrapalhariam na hora de prever em novos dados.
Como sempre, é importante testar um modelo deste tipo.
Redes Neurais Artificiais (e Deep Learning)
As grandes estrelas dos artigos sobre inteligência artificial são as redes
neurais.
71
O uso delas para resolver problemas que envolvem dados não-estruturados
como imagens, vídeo, áudio e texto é o responsável por toda a expectativa
que se vê ao redor do Deep Learning.
Deep Learning nada mais é do que treinar uma rede neural com mais de
uma camada oculta (hidden layer). A grande vantagem disso é que a rede
consegue aprender representações internas úteis para a previsão.
Então todos os nossos problemas estão resolvidos? É só usar Deep
Learning?
Não.
Redes neurais são extremamente complexas e por isso exigem uma
quantidade muito maior de dados que os outros modelos para funcionar
bem. Se você pesquisar os casos de sucesso do Deep Learning, vai ver que
foram redes treinadas em bancos de dados gigantes durante semanas.
O que é outro ponto complicado: mesmo com os avanços em GPUs, ainda é
muito caro treinar uma rede neural porque exige bastante tempo em uma
infraestrutura quase especializada.
Então nunca devemos usar redes neurais?
Também não é assim.
Elas realmente vão muito bem com dados não-estruturados, como citado
acima. Então mesmo que você tenha poucos dados, se forem deste tipo,
vale a pena tentar criar uma rede neural simples.
Para imagens as redes convolucionais são imbatíveis, mesmo em conjuntos
de dados menores.
72
Podemos usar modelos pré-treinados. Modelos que foram treinados por
semanas em grandes servidores estão disponíveis online gratuitamente.
Podemos usá-los como features ou ajustar alguns de seus pesos para nosso
caso específico.
Isso pode nos dar uma performance muito boa, mesmo não tendo milhões
de exemplos para alimentar a rede, já que ela vem com muitos padrões
aprendidos em casos parecidos.
Além das redes mais simples (feedforward), temos redes convolucionais,
que tentam criar representações dos dados de entrada usando convoluções
sobre os valores para depois passar para as camadas ocultas.
E também redes recorrentes. Essas são especializadas em capturar padrões
em sequências. São as redes por trás dos melhores sistemas de
reconhecimento de voz e tradução automática disponíveis no mercado.
Apesar de não recomendar que sejam o primeiro modelo que você deve
testar, mesmo sendo mais complicadas de fazer funcionar, vale a pena testar
redes neurais em suas tarefas.
Elas não costumam bater as previsões de modelos de árvores em dados
estruturados, mas por terem uma forma bem diferente das árvores de
encontrar soluções, as melhores combinações de modelos acontecem
quando juntamos GBDTs e redes neurais para fazer a previsão num
ensemble.
Mais sobre isso na parte de ensembles abaixo. Mas antes…
Por que redes neurais não funcionam tão bem em dados
tabulares/estruturados?
73
Essa é uma pergunta sem resposta definitiva. Aliás, muitas características
das redes neurais ainda não são explicadas por teorias. Existe bastante
pesquisa envolvida em entender porque elas funcionam.
A resposta mais interessante que encontrei para essa pergunta foi numa
postagem do Reddit. O autor sugere que dados estruturados tendem a vir
com representações (features) bem definidas, servindo como um filtro de
ruído.
Já nos casos em que as redes neurais vão bem, como classificação de
imagens, não temos representações tão boas. Normalmente são aplicados
filtros às imagens e passados como features.
Então é muito mais difícil para uma árvore de decisão aprender o
“conteúdo” de uma imagem olhando para um monte de números que
representam os pixels.
Já as redes neurais convolucionais aprendem filtros otimizados para a tarefa
que estão tentando resolver, em vez de usar filtros genéricos. Uma das
razões pelas quais elas precisam de muitos exemplos.
Essa explicação faz muito sentido considerando as experiências que tive
com esses dois tipos de modelos.
Vizinhos mais próximos (KNN)
O KNN é um modelo que acaba encontrando uma solução diferente dos
citados acima e é uma opção boa para complementá-los.
Esse é o modelo mais intuitivo de machine learning.
74
Ele não tem uma fase de treinamento propriamente dita, pois em sua versão
mais simples vai apenas armazenar todos os dados de treino.
Quando queremos fazer uma nova previsão, passamos as features do novo
exemplo e ele encontra os K exemplos mais próximos dentre os
armazenados.
Apesar da simplicidade, ele já ajudou muita gente a ganhar os poucos
pontos que faltavam para vencer uma competição (inclusive eu). Por isso
tem um lugar especial.
Nas implementações mais populares existem otimizações para não termos
que comparar os novos exemplos com o conjunto de dados de treino
inteiro.
Existem dois parâmetros muito importantes: o número de exemplos
vizinhos (K) e a fórmula usada para calcular a distância.
Regularização
Todos estes modelos possuem alguma forma de regularização. Esse é o
nome de qualquer método que seja utilizado para ajustar a complexidade
dos padrões que serão capturados por um modelo.
Mais regularização significa menor complexidade, menor capacidade do
modelo encontrar padrões muito específicos. Menos regularização quer
dizer que o modelo tem uma capacidade maior de encontrar padrões menos
comuns.
Em árvores de decisão a forma mais clara de regularização é ajustar a
profundidade dos ramos. Árvores mais profundas conseguem capturar
75
padrões mais complexos e específicos de pequenos grupos de exemplos. Já
árvores mais superficiais estarão limitadas a padrões mais comuns da
amostra.
Ou seja, profundidade maior significa menor regularização. E vice-versa.
Em redes neurais isso pode ser feito ajustando a arquitetura: quanto menos
camadas e unidades, menor a capacidade de aprendizado. Mas também com
métodos mais avançados como Dropout ou a adição de coeficientes de
penalização dos pesos.
Uma característica comum de métodos de regularização é atribuir algum
tipo de penalidade proporcional ao nível de complexidade do modelo.
Como saber qual modelo vai funcionar melhor?
Testando.
Não existe um modelo que seja superior aos outros em todas as situações.
Existe até um teorema explicando isso: o No Free Lunch.
Mesmo o GBDT (árvores em geral) sendo meu favorito, e mostrando ser o
melhor na maioria dos casos, existem situações em que ele não foi a melhor
opção. Um deles pode ser visto na série que fiz para o canal do Youtube
com os dados do Titanic, em que um modelo linear foi o melhor.
Então não se “case” com um modelo. Sempre entenda que pode aparecer
um caso em que outro modelo funcione melhor.
76
Classes desequilibradas (Class Imbalance)
Muitos dados que encontramos na prática não terão uma proporção exata
de exemplos entre as classes que queremos prever. É muito mais fácil obter
exemplos de pessoas que nunca fizeram compras do que de pessoas que
fizeram compras.
Nem sempre isso vai afetar o modelo negativamente, mas é importante
saber como lidar com essa situação, principalmente quando você está
otimizando uma métrica como AUC ou F1 Score.
Pesos diferentes (Weighting)
De longe a maneira mais bem sucedida que eu conheço de tratar esse
problema é penalizando erros de acordo com a proporção de exemplos de
cada classe.
Uma maneira simples de fazer isso é: imagine que temos 5% de exemplos
positivos (95% de negativos). Vamos programar o modelo para multiplicar
os erros cometidos na classe positiva por 19 (0,95 / 0,05).
Ou seja, em vez do modelo receber uma penalidade proporcional à
frequência real do exemplo, nós vamos simular que esse exemplo aparece
em quantidade igual aos da classe mais frequente.
Reduzir ou aumentar a amostra
77
Popularmente se fala em reduzir ou aumentar a amostra para equalizar as
proporções.
No caso da redução, jogaríamos fora 90% dos dados no exemplo acima,
ficando com quantidades iguais de registros positivos e negativos.
No caso do aumento da amostra, iríamos duplicar os exemplos positivos até
ter a mesma quantidade de linhas dos negativos.
Existem maneiras mais sofisticadas de fazer a redução e aumento da
amostra. Como tudo na prática de data science, você precisa testar o que
funciona melhor no seu caso específico.
Na minha experiência os resultados desses métodos de amostragem são
iguais ou piores aos do método de pesos diferentes.
78
Validação
Na modelagem com machine learning, em 99,786% (número claramente
inventado por mim) dos casos o mais importante é que a solução funcione
em dados novos, nunca vistos pelo modelo.
Para simular o ambiente de produção, nós usamos dois conjuntos de dados:
treino e validação.
Tradicionalmente é recomendado ter três conjuntos de dados: treino,
validação e teste.
Você otimiza os parâmetros internos do modelo no treino. Otimiza os
hiperparâmetros do modelo na validação. No fim de tudo, com o modelo
final selecionado, aplica no teste e vê qual foi o erro.
A ideia é que a avaliação no teste, por acontecer (idealmente) apenas uma
vez, é a mais confiável.
Hoje eu penso um pouco diferente.
Primeiro que, se os seus dados forem problemáticos ou você tiver errado na
hora de dividir entre esses conjuntos, seu teste não vai representar uma
amostra verdadeiramente nova.
Segundo, você só descobre se um sistema vai funcionar ou não de verdade
quando coloca em produção.
Por isso, o que eu recomendo é ter apenas dados de treino e validação.
Geralmente a validação, mesmo sendo usada para otimizar algumas partes
do modelo, vai te dar uma boa ideia do que esperar em produção.
79
Quem conseguir inutilizar a validação, vai acabar fazendo isso com o teste
também.
O mais importante é ter um ciclo de desenvolvimento rápido que nos
permita fazer testes pequenos em produção para poder corrigir aquilo que
realmente importa.
Por isso só trato de conjuntos de treino e validação.
A validação é uma parte extremamente importante. Se ela estiver errada
todo o projeto fica comprometido.
A regra de ouro para a validação é: faça esse conjunto de dados o mais
parecido possível com a maneira como você receberá os dados novos em
produção.
Com todos os atrasos, falta de dados e qualquer outra situação.
Vamos ver alguns exemplos genéricos abaixo que você pode usar para
montar a validação básica e fazer pequenos ajustes para adequar ao caso
que você esteja resolvendo.
Overfitting e Underfitting
Antes de entrar nos métodos de validação, precisamos entender o que ela
ajuda a evitar.
Overfitting é o nome que damos à situação em que o modelo acaba
memorizando os dados de treino. Isso significa que ele não aprendeu
apenas padrões reais que possam ser utilizados para fazer a previsão em
dados novos, mas também padrões falsos que inevitavelmente vão parar na
amostra de treino.
80
Uma equipe estava fazendo um classificador de imagens para diferenciar
entre cães domésticos e lobos. O modelo tinha ficado muito bom, até que
eles foram tentar entender quais eram os padrões que ele tinha encontrado
para diferenciar entre esses casos.
Em vez de focar num padrão dos animais, o modelo usava o fundo da
imagem como melhor informação para prever se era um lobo ou um
cachorro. Todas as imagens de lobo tinham o fundo na neve e as de
cachorros não.
Esse é um exemplo de overfitting não-trivial. Mas fica claro que, ao mostrar
novas imagens de lobos tiradas em ambientes sem neve, ou de cachorros na
neve, o modelo iria falhar.
Do ponto de vista técnico, overfitting acontece quando o seu erro nos dados
de treino continua caindo mas o erro na validação começa a subir.
É comum ter o erro do treino menor que o do teste, mas até um ponto do
treino eles continuam reduzindo juntos. Então se teu erro de treino estiver
distante do de validação, mas os dois ainda estiverem reduzindo, não se
preocupe.
O problema é quando passa desse ponto e eles começam a divergir.
Já o underfitting acontece quando seu modelo é simples demais para
conseguir capturar os padrões dos dados. Nesse caso ele não consegue
capturar os padrões falsos, mas também não captura os verdadeiros.
Se você comparar o erro nos mesmos dados de treino entre um modelo
linear e um modelo de árvores, vai ver que as árvores tendem a reduzir
mais do que o modelo linear.
Isso acontece porque a capacidade de modelagem delas é maior.
81
Então se você perceber que o seu modelo não reduz o erro nem nos dados
de treino e consequentemente também não consegue nos dados de
validação, é um caso de underfitting.
Validação Simples
O método de validação clássico, que todo mundo aprende em cursos de
machine learning, é a divisão aleatória entre treino e validação.
Basicamente você pega seus exemplos e sorteia uma parte para treinar o
modelo e outra parte para avaliar após o treino.
A recomendação geral é deixar 70% para treino e 30% para teste, mas a
pergunta mais comum é: por que?
Isso eu respondo após te explicar outras maneiras de validar, porque a
resposta vai servir em todos os casos.
Em casos reais geralmente temos que fazer a validação levando em conta o
tempo (os exemplos de validação precisam estar no “futuro”) então este
método é pouco utilizado.
Validação Cruzada
A validação cruzada é uma “evolução” da primeira.
Em vez de termos apenas uma divisão, dividimos os dados originais em
vários blocos, também com sorteios aleatórios, e usamos uma parte dos
blocos para treino e outra para validar.
82
Imagine que você tenha 1000 exemplos e decida fazer uma validação
cruzada com 5 divisões.
Vamos separar esses dados em 5 blocos, sorteando aleatoriamente qual
exemplo vai para cada bloco.
Depois faremos 5 ciclos de treino e validação. No primeiro ciclo
treinaremos o modelo nos blocos 1, 2, 3, 4 e validaremos no 5. No segundo
ciclo treinaremos nos blocos 2, 3, 4, 5 e validaremos no bloco 1. E assim
vai.
Sempre selecionando 4 blocos para treino e 1 para validar.
No fim teremos N (no exemplo, 5) valores de erros em conjuntos de dados
de treino e validação “diferentes”. Podemos fazer a média e também avaliar
como o modelo se comportou em cada bloco.
Grupos
Os esquemas de validação acima foram pensados para casos em que temos
linhas “independentes”. Quando temos uma linha por cliente, por exemplo,
podemos considerar que um cliente não influencia o outro ou que a
influência é quase nula.
Mas existem casos em que várias linhas podem se referir à mesma
entidade.
Se você tiver um conjunto de dados de lista de preços de produtos, cada
linha pode ser uma combinação do produto e o preço para uma determinada
quantidade.
83
Nesse caso teremos mais de uma linha por produto. Isso aconteceu na
competição da Caterpillar. Cada tubo que deveria ser precificado possuía
linhas indicando a quantidade mínima para um determinado preço.
Se nosso interesse for prever para produtos novos, não podemos
simplesmente separar dados aleatórios por linha, pois estaremos treinando
em parte das linhas do mesmo produto que teremos na validação.
Também já conversei com uma empresa que tinha grupos de clientes que
influenciavam as compras dos outros, fazendo a validação aleatória não
representar a realidade.
Podemos separar aleatoriamente, mas por grupo, colocando todas as linhas
referentes a um determinado grupo (um produto, cliente) nos dados de
treino ou validação.
Estratificação
Estratificar a validação significa adicionar um passo na hora de dividir os
dados, de maneira que a proporção das classes seja a mesma em todas as
divisões.
Se temos 1% de spam nos dados originais, ao dividirmos em 10 partes para
validar, cada parte dessas terá 1% dos dados como spam.
Não existe uma conclusão sobre a superioridade desse método.
Eu não recomendo fazê-lo, pois em produção não podemos garantir que as
amostras virão exatamente com a mesma proporção de classes.
Além disso, se a pequena variação na proporção de classes feita pela
divisão aleatória for um problema, é sinal que o modelo não é tão robusto.
84
A maioria dos competidores usou validação estratificada na competição da
Telstra. Em um momento eu decidi testar a validação sem estratificação.
Isso me deu uma validação muito similar aos dados de teste e me ajudou a
vencer.
Time Series
Como a maioria de validações que faremos será em Time Series, eu
coloquei todos os detalhes no guia bônus que acompanha esse livro.
Avaliando cada bloco da validação
Na prática eu gosto de ver meu modelo melhorar pelo menos a maioria das
divisões, seja em time series ou validação aleatória.
Isso significa que em vez de olhar apenas a média dos erros nas divisões, eu
quero ver como os erros de cada uma se comparam à versão anterior do
modelo.
Se olharmos só a média pode ser que uma divisão tenha seu erro muito
melhor, e as outras tenham piorado um pouco, o que vai puxar a média para
baixo mas aumenta a chance de ser uma melhora por “sorte”, capturando
um padrão falso que existe apenas na divisão que melhorou.
Tamanho do treino e da validação
Na hora de decidir o tamanho dos dados de treino e validação é importante
pensar no tamanho total de nossos dados e na variabilidade que aceitaremos
na métrica de avaliação.
85
Quanto maior for o tamanho de seu conjunto de dados de treino, menor a
chance do modelo capturar padrões falsos. Só que isso significa que seus
dados de validação serão menores, então o erro medido não será tão
confiável, já que pequenas mudanças nos dados podem ter um efeito
significativo no erro.
E vice-versa, dados de treino pequenos aumentam a possibilidade de
overfitting, mas o erro que você verá na validação é mais confiável.
Aqui vale a regra geral de experimentos estatísticos, quanto maior a
amostra de um lado ou de outro, mais confiável a estimativa.
Se você tiver milhões de linhas, a proporção entre treino e validação se
torna menos importante, já que uma validação com 1 milhão de linhas ou
mais tende a ser (na maioria dos casos) o bastante, mesmo que seja só 10%
dos dados totais.
A minha recomendação padrão é 50/50. Metade de seus dados para treino e
metade para validação. Principalmente se você ainda não tem experiência
para saber como uma outra proporção afeta a confiabilidade de seus
resultados na tarefa específica.
Quando falamos de séries temporais, é importante ter vários momentos de
tempo nos dados de validação.
Avaliar um modelo de vendas usando apenas três meses, por exemplo, pode
deixar de mostrar como o modelo vai agir em datas comemorativas, épocas
com efeitos específicos, como o Natal (sazonalidade).
Assim como avaliar um modelo de previsão de retornos financeiros sem
incluir momentos de crise como os anos de 2007 a 2009 pode nos dar
estimativas otimistas.
86
Tuning
Existem pelo menos dois tipos de parâmetros que precisam ser ajustados
num modelo.
Os do primeiro grupo, normalmente chamados de parâmetros mesmo, são
otimizados durante o treinamento. São os pesos de uma regressão linear,
pesos de uma rede neural, splits de uma árvore de decisão.
Os do segundo grupo, chamados de hiperparâmetros, precisam ser
otimizados manualmente ou com algum mecanismo de busca automático.
Alguns exemplos são: a arquitetura de uma rede neural, a profundidade da
árvore de decisão, o coeficiente de regularização de um modelo linear.
Neste livro vou considerar quase qualquer escolha que deva ser feita
durante a modelagem como um hiperparâmetro.
Por exemplo: o método de scaling, as transformações de variáveis, o
próprio modelo, os hiperparâmetros do modelo, o método de seleção de
variáveis.
Essa visão veio com a experiência e a leitura do artigo de um dos melhores
competidores do Kaggle, Marios “Kazanova”, que cita considerar tudo
como hiperparâmetro.
Isso torna a modelagem em um grande problema de otimização mista.
O “tuning” ou otimização de hiperparâmetros é feito em ciclos de treino e
validação. Treine o modelo/pipeline em uma combinação, veja o resultado
87
e repita até encontrar a melhor combinação ou atingir o limite de tempo que
você tem para encontrar.
Muita gente acha que essa é a parte mais importante. Apesar de ser uma
parte que ajuda o modelo, não é a que vai te dar o melhor retorno pelo
tempo gasto. Feature Engineering é a parte mais importante.
Não use Grid Search
O que mais se ensina em cursos de machine learning é a fazer Grid Search.
Essa é uma busca onde você determina uma lista de valores para cada
hiperparâmetro e visita cada uma das combinações, avaliando seu modelo.
Essa é uma busca extremamente ineficiente quando passamos de alguns
poucos hiperparâmetros.
Se você tiver 5 hiperparâmetros e 10 valores para cada um, vai ter que
visitar 100.000 combinações. Se levar 30 minutos para treinar e validar o
modelo, vai demorar mais de 1.000 dias.
Use Random Search
Random search, ou busca aleatória, significa que em vez de visitar todas as
combinações, você sorteia alguns pontos e os visita.
Dessa maneira você visitará várias áreas do possível espaço de
combinações. Isso aumenta a chance de encontrar uma combinação
próxima da melhor possível em bem menos tempo.
88
Varia de caso para caso, mas na prática, visitando 50 a 100 pontos você já
vai achar uma combinação muito próxima da ideal.
Existem vários trabalhos acadêmicos e casos de uso que provam a
superioridade da random search sobre a grid search.
Essa é uma das raras oportunidades de dizer que sabemos a superioridade
de um método (random search) sobre outro método (grid search) na prática
de data science.
Bayesian Optimization: o futuro?
Uma evolução da random search é a otimização bayesiana.
A diferença aqui é que o início da busca é aleatória, mas depois é iniciada
uma busca guiada por um modelo treinado sobre os pontos já visitados,
tentando encontrar quais são os próximos pontos mais promissores.
Imagine que você faça uma busca aleatória visitando 10 combinações.
Treine um modelo usando os valores dessas combinações como features e o
erro encontrado como alvo.
Usando uma função chamada de “função de aquisição”, o algoritmo faz a
previsão para vários pontos e determina qual deles tem a maior chance de
ser uma combinação melhor. Então faz o ciclo de validação usando essa
combinação para saber o resultado.
Ainda não é conclusivo se esse tipo de busca é realmente superior à random
search, mas na minha experiência ela encontra uma combinação boa em
cerca de 30-50 iterações.
Todos esses métodos possuem implementações prontas para você usar.
89
Abrindo a caixa preta: Interpretação do Modelo
Está cada vez mais importante saber explicar as decisões que o modelo
toma. Tanto para dar mais confiança ao usuário, quanto para estar de acordo
com as novas leis.
Um profissional de saúde fica muito mais confortável em usar um modelo
para auxiliar na hora de tomar uma decisão se souber como ele chegou até a
previsão.
A regra geral é que: quanto mais poderoso o modelo, mais difícil entender
como ele está gerando a previsão.
SHAP
A melhor biblioteca que eu conheço para interpretar modelos é o SHAP.
Este é um método que pode ser aplicado a qualquer modelo, e inclusive
possui implementações otimizadas para as bibliotecas mais utilizadas como
XGBoost, LightGBM, Scikit-learn e Tensorflow.
Com ele é possível entender as previsões do modelo desde a amostra inteira
até quais foram os fatores que influenciaram uma previsão específica.
O único problema é que ele pode demorar um pouco com conjuntos de
dados muito grandes, mas nesse caso você pode calcular os valores em uma
amostra menor.
90
Feature Importance e Coeficientes
Vários modelos podem calcular algum tipo de influência das variáveis em
suas previsões nativamente.
Random Forests geralmente calculam quanto cada feature contribuiu para a
redução da impureza dos nós ou quantas vezes ela foi escolhida para fazer
um split.
Essa informação é computada rapidamente e pode te dar uma ideia inicial
de quais fatores são importantes para sua tarefa.
Existem duas situações em que você deve tomar cuidado:
Se uma feature é muito mais importante do que as outras, ela pode ter
algum vazamento de dados. Várias vezes investiguei ou eliminei a feature
mais importante e tive uma melhora na generalização do modelo.
Features com muitos valores diferentes, dependendo da fórmula usada para
calcular a importância, tendem a ter sua importância inflada.
Modelos lineares são considerados os mais interpretáveis. Você
simplesmente olha os coeficientes e já sabe exatamente quanto aquela
feature contribuiu para a previsão.
Mas tome cuidado, se as features estiverem em escalas diferentes (você não
tiver feito a subtração da média e divisão pelo desvio padrão, por exemplo),
os coeficientes terão valores diferentes por causa do intervalo da feature e
não por causa da importância.
Se eu estiver prevendo o preço de uma casa com um modelo linear e tiver
duas features: número de quartos e área construída. O número de quartos
91
terá seu intervalo mais comum entre 1 e 4. Já a área construída terá um
intervalo de 30 a 3000 ou mais.
Passando essas informações brutas para o modelo, ele vai criar um
coeficiente muito mais baixo para a área construída, já que ela possui
valores muito mais altos, mas isso não significa que ela tem mais
importância.
92
Ensembles (Conjuntos de Modelos)
Está se tornando cada vez mais fácil colocar um conjunto de modelos em
produção. Essa é uma das maneiras mais certeiras de melhorar a sua
solução de machine learning: combinar previsões de modelos diferentes.
A característica mais importante dos modelos de um bom ensemble é a
diversidade. A performance individual deles se torna secundária.
Já tive modelos que não chegariam nem nos primeiros 1000 lugares de uma
competição, mas quando combinados com outros, o conjunto chegava ao
top 10.
Vou te contar como criar essa diversidade, mas antes vamos ver como
podemos combiná-los.
Média e média ponderada (blending)
A forma mais simples de combinar modelos é fazer uma média, seja ela
simples ou ponderada.
Um outro nome dado a esse tipo de ensemble é “blending”, mas tem gente
que chama qualquer ensemble de blending também.
Não tem segredo, é só pegar as previsões dos modelos, fazer uma média e
ver se melhora a validação.
Bagging e Boosting
93
Os métodos mais conhecidos de se criar ensembles, e que formam a base de
modelos como Random Forest e GBDT, são Bagging e Boosting.
Bagging consiste em pegar repetidamente amostras aleatórias, com
reposição, dos dados originais e treinar modelos. Para novos dados a
previsão é a média simples das previsões dos modelos treinados.
Quanto mais modelos, maior a estabilidade do ensemble.
Boosting em poucas palavras: ir treinando modelos sequencialmente com
custo maior nos erros da combinação de modelos anteriores.
Modelo 1: Você treina um modelo nos teus dados de treino. Faz a previsão
para estes mesmos dados.
Modelo 2: Você treina este modelo nos teus dados de treino, mas dessa vez
vai dar um peso maior para aqueles exemplos em que o primeiro modelo
teve mais dificuldade. Ou seja, esses exemplos "errados" vão influenciar
mais na criação deste segundo modelo. Pegue as previsões do modelo 1 e
junte com as previsões do modelo 2 (pode ser uma soma ou média).
Modelo 3: Treine este modelo, nos mesmos dados, mas novamente dando
um peso maior para os erros cometidos pela combinação da previsão dos
modelos anteriores. Combine as previsões dos modelos 1, 2 e 3.
Nesse exemplo sua previsão final seria:
P_final = p_modelo1 + p_modelo2 + p_modelo3
Na prática existem vários mecanismos mais sofisticados para criar esses
modelos de maneira que a combinação funcione melhor. Isso tudo é feito
internamente por ferramentas como o LightGBM.
94
Média de Seeds
Quando temos modelos afetados por aleatoriedade durante o treinamento,
como é o caso do GBDT e redes neurais, podemos fazer uma média
simples entre o mesmo modelo, treinado sobre os mesmos dados, mas
mudando a seed do gerador de números aleatórios.
No caso da rede neural, os pesos iniciais serão diferentes, o que vai fazer
com que ela ache um ponto de convergência diferente dependendo destes
pesos. Se juntarmos as previsões de várias delas teremos uma combinação
mais poderosa, removendo um pouco dessa aleatoriedade.
Na prática, quando posso, gosto de juntar pelo menos 3 redes, mas em
alguns casos já cheguei a juntar 20.
O número de redes ideal pode ser um hiperparâmetro. Conforme você vai
treinando mais redes e fazendo a média, chega um ponto em que a melhora
é muito pequena.
Quanto mais pesos (camadas diferentes) tiver a rede, mais eficaz será esse
procedimento.
No caso do GBDT, a aleatoriedade é menor, mas ela acontece no momento
em que ele faz uma amostra dos dados ou das features para criar a próxima
árvore. Normalmente a média de 3 a 10 destes modelos já é o bastante.
A Random Forest não precisa disso, pois como ela cria árvores
relativamente independentes, você pode simplesmente aumentar o número
de árvores da mesma seed.
Stacking: o queridinho do Kaggle
95
Esta é a maneira mais poderosa de se fazer um ensemble, mas isso não
significa que funciona em todos os casos.
Em poucas palavras: você vai usar uma parte dos dados para treinar os
modelos nas features originais, prever em outro conjunto de dados
(validação, por exemplo) e depois vai usar estas previsões como features
para treinar novos modelos.
É natural ficar confuso nas primeiras vezes que você pensar em como isso
tudo funciona. Normalmente isso é feito dentro de uma validação cruzada.
Eu vou explicar o procedimento em uma validação simples, e você só
precisa adequar o processo às divisões de sua validação.
Eu preciso de, pelo menos, 3 divisões dos dados. Vamos chamar as divisões
(criativamente) de 1, 2 e 3.
Primeiro eu pego a parte 1 e treino meus modelos. Digamos que seja uma
rede neural e um GBDT.
Este é o primeiro nível de modelos.
Com esses modelos treinados, eu faço previsões na parte 2 e salvo essas
previsões. Ou seja, para cada exemplo da parte 2 eu terei uma previsão da
rede neural e uma do GBDT.
Agora eu treino um (ou mais) modelos usando a parte 2. Ou seja, minhas
features nesse nível serão as duas previsões que tenho para cada exemplo.
Este é o segundo nível de modelos.
Então eu pego os modelos de primeiro nível, faço previsões para a parte 3.
Com essas previsões dos modelos de primeiro nível, eu criei as features
96
necessárias para meus modelos de segundo nível.
Pego as previsões geradas e uso como features nos modelos de segundo
nível, que vão gerar as previsões finais para a parte 3.
Você pode ter mais de dois níveis, já vi até 4 níveis, mas a cada nível você
precisa tomar cuidado com o overfitting. Além disso, as melhoras vão
sendo cada vez menores.
Validação do Ensemble
Como você percebeu no caso do Stacking, precisamos de dados fora de
todas as amostras para validar robustamente os nossos modelos de
ensemble.
No caso de validação cruzada, para ter uma estimativa confiável do erro,
você precisa fazer dois ciclos, um interno e um externo.
Eu adicionei aos bônus deste livro um artigo que escrevi com código em
Python para fazer esse tipo de validação.
Para entender tudo isso eu recomendo que você literalmente desenhe numa
folha de papel. Pegue as instruções de stacking que descrevi e desenhe
como cada parte interage, depois tente imaginar isso numa validação
cruzada.
Foi assim que eu aprendi.
Como conseguir modelos diferentes?
97
Como eu falei no início, a grande sacada dos ensembles é ter modelos que
façam previsões diferentes, porque aí eles tendem a prever melhor uma
parte dos dados que outros modelos podem ter dificuldade, melhorado o
conjunto.
Eu costumo pensar em quatro maneiras de gerar modelos diferentes. Elas
estão na ordem que eu considero mais eficaz.
Quando crio modelos para fazer ensembles, gosto de pensar nisso como
feature engineering para o próximo nível. A diferença é que, em vez de
extrair as features dos dados originais diretamente, eu estou usando um
modelo como “filtro”.
Tipos de Modelos
O tipo de modelo que você usa acaba influenciando nos padrões que serão
capturados. Uma rede neural vê os dados de maneira diferente de um
conjunto de árvores.
Treinar modelos de tipos diferentes tende a ser o caminho mais fácil para
conseguir um bom ensemble.
A combinação de ouro do Kaggle é rede neural com GBDT.
A grande maioria das soluções vencedoras de competições de machine
learning possui um ensemble entre redes neurais e modelos de árvores, em
especial o GBDT.
Em alguns casos você vai treinar modelos que serão fraquinhos perto de
seu melhor modelo, mas ainda assim eles podem ser úteis.
98
O processo para definir se um modelo é útil é o mesmo usado para
selecionar features.
Grupos de Features
A segunda opção que gosto de tentar é criar modelos usando grupos de
features diferentes. Podem ser grupos pré-definidos ou aleatoriamente.
Houve uma competição em que um dos times do top 3 criou 500 modelos
selecionando colunas aleatoriamente. No fim a combinação funcionou.
Quando você cria modelos em grupos específicos de features, você está
forçando o modelo a achar a melhor solução que use apenas aquelas
colunas.
Amostra
A terceira ideia é separar amostras diferentes dos seus dados. Também pode
ser aleatoriamente (como vemos no Bagging) ou por algum grupo de
exemplos.
Na segunda competição que participei no Kaggle era necessário determinar
se um anúncio (em Russo) era permitido no site de classificados Avito.
No meu ensemble final havia modelos treinados especificamente para cada
categoria. Simplesmente peguei todos os exemplos de uma categoria e
treinei o modelo. Nos dados de teste peguei os exemplos dessa mesma
categoria e usei esse modelo para fazer a previsão.
Cada modelo prevendo os exemplos de sua categoria. No fim você tem
previsões para a amostra inteira.
99
Nada impede você de usar esse modelo para prever exemplos de outras
categorias. Pode funcionar em casos específicos.
Hiperparâmetros
A última forma de criar diversidade que eu considero é mudar os
hiperparâmetros.
Aqui pode ser desde mudar a arquitetura da rede neural até mudar a
profundidade das árvores de um GBDT. Basicamente treinar modelos com
diversos valores de hiperparâmetros.
Em alguns casos isso pode ajudar, mas é a forma mais fraca que eu
considero de criar modelos diferentes.
100
4 DEPLOY
❧
Chegou a hora de colocar o seu modelo para funcionar em produção.
Aqui nós vamos ver os passos necessários do ponto de vista da modelagem
sem entrar em detalhes de engenharia de dados.
101
Salve o modelo
Praticamente toda biblioteca em Python ou R possui uma maneira de salvar
seus modelos em um arquivo binário.
Depois que você tiver treinado o modelo ou a pipeline, basta usar essas
funções para salvá-los em um arquivo que será usado para fazer as
previsões em produção.
Uma alternativa menos utilizada é programar o modelo diretamente no
código. Um modelo linear, por exemplo, seria uma soma de coeficientes
multiplicados pelas features.
102
Servindo o modelo
Se o seu modelo for usado com pouca frequência, você pode simplesmente
adaptar os notebooks utilizados durante o desenvolvimento para capturar
novos dados e fazer as previsões.
Mas eu recomendo que, no mínimo, você organize o código em scripts, já
que notebooks não foram otimizados para rodar em produção.
API
Uma forma muito comum de servir modelos é criando uma API que
receberá os dados de entrada e emitirá a previsão.
Em alguns casos essa API recebe os dados brutos, faz todas as
transformações e cálculos de features necessários internamente, retornando
apenas a previsão.
Em outros casos ela recebe as features já transformadas por outros
processos. Isso vai depender de como foi decidido que o modelo será usado
em produção na fase inicial do projeto.
Quando temos uma interface de contato com o usuário, ela pode fazer parte
ou não da API.
No caso de um sistema de busca, geralmente será uma interface separada.
Já numa aplicação interna da empresa, ela pode ser parte da API.
103
Um exemplo de app com interface embutida: numa apresentação um
cientista de dados da Netflix mostrou um sistema que os executivos da
empresa usam para colocar informações sobre uma possível produção e
receber previsões de custo e sucesso.
104
Computando as features em produção
O primeiro passo é garantir o acesso a bancos de dados atualizados com as
informações que vai usar. Procure saber qual a frequência de atualização
dos dados para garantir que você receba os resultados que espera.
Durante a modelagem você pode ter usado funções otimizadas para
trabalhar com matrizes. Pode não ser possível organizar as informações da
mesma maneira em produção.
Neste caso você precisa criar funções que calculem as features usando as
estruturas de dados recebidas em produção.
Por exemplo, em vez de uma array do Numpy, a sequência de acessos do
usuário pode vir numa lista ou dicionário. Se houver comunicação com
softwares em outras linguagens, a informação pode vir em formatos como
JSON e XML.
Teste as funções
Como em todo projeto de software, é importante criar alguns casos de teste
e ver se as funções estão realmente retornando o que você espera.
Você pode pegar exemplos dos dados históricos e simular que eles tenham
vindo de sua pipeline de produção.
Eu prefiro essa alternativa porque por mais que você pense em casos
extremos para criar, os dados reais acabam surpreendendo.
105
Faça o registro de tudo que for possível
Dados brutos, features, tempo de processamento, previsões, horário da
chamada da API.
Tudo o que você tiver de informação que possa ser relevante para o
monitoramento (idealmente) deve ser armazenada em um log.
Dessa maneira você poderá comparar os resultados com dados históricos e
resolver problemas muito mais facilmente.
Idealmente você vai criar uma dashboard (que pode ser um notebook) para
carregar esses dados e fazer as comparações recomendadas no próximo
capítulo.
106
Como testar esse modelo?
Você geralmente não deve colocar todos os usuários da empresa para
receber a previsão de um modelo antes de saber que tudo está
implementado corretamente.
Além disso, precisamos de uma maneira para medir se nossa solução
realmente está agregando valor ao processo de negócios no qual estamos
trabalhando.
Teste A/B
A forma mais popular de fazer isso é com um teste A/B. Vou usar um
exemplo de usuários, mas a unidade que será considerada em cada teste vai
depender do problema que estamos resolvendo.
Em uma recomendação de produtos pode ser o usuário, em um site de
classificados pode ser cada anúncio, num site de busca pode ser cada
palavra-chave, num fundo de investimentos pode ser cada instrumento
financeiro operado.
Pense nas unidades possíveis para sua situação, liste possíveis problemas
em usar cada uma delas e opte pela que pareça mais adequada.
Você vai separar os usuários aleatoriamente em duas categorias (A e B, que
surpresa).
Na categoria A os usuários continuarão recebendo a mesma experiência.
Não serão afetados pela nova solução. Este grupo também é chamado de
107
grupo de controle.
Na categoria B os usuários serão afetados pela nova solução. Também
chamado de grupo de tratamento.
Isso não quer dizer que a quantidade de usuários precisa ser igual nos dois
grupos. Pelo contrário, é melhor começar com uma porção menor de
usuários no grupo B e aumentar gradativamente.
Feito isso, você deve calcular as métricas de negócio e de machine learning
separadamente para o grupo A e para o grupo B.
Para saber se sua solução está funcionando rigorosamente você deve usar
um teste de hipóteses adequado à distribuição dos seus dados.
Você deve calcular o tamanho da amostra necessária e o tempo para atingir
o nível de significado estatístico esperado (p-value) se houver um efeito.
Como em qualquer experimento, defina estes valores antes de começar ou
você comprometerá os resultados.
Isso pode ajudar a definir a proporção mínima de usuários que devem ser
colocados no grupo B.
Na prática fica difícil convencer o time de produto a largar uma solução que
tenha melhorado as métricas, mesmo que não seja uma melhora
“estatisticamente significativa”.
Nos primeiros dias de teste eu costumo ficar muito mais preocupado em
garantir que tudo esteja implementado corretamente do que esperar um
efeito positivo nas métricas de negócio, mas elas devem ser monitoradas
com cuidado durante todo o teste.
108
Controle sintético
O teste A/B e suas variações vai muito bem na maioria dos casos, mas às
vezes precisamos de uma técnica mais complexa. E uma delas é a forma
como o Uber usou o “controle sintético” para avaliar a introdução da
possibilidade de pagamento em dinheiro no Brasil.
Essa história é baseada numa apresentação que foi feita no PyData, então
modifiquei algumas partes para ficar mais fácil de entender.
Vamos considerar a métrica número de viagens realizadas.
Neste caso, claramente seria problemático fazer um teste A/B dividindo os
usuários, motoristas ou viagens. Então eles decidiram fazer a divisão entre
cidades.
Isso significa, por exemplo, que eles ativariam a nova forma de pagamento
em São Paulo (grupo B), mas deixariam o Rio de Janeiro e Belo Horizonte
no formato antigo (grupo A).
Mas aí surge outro problema: como você sabe se os efeitos calculados são
realmente por causa de sua solução e não de outra característica específica
de São Paulo, como a ocorrência de eventos no período de testes?
Se simplesmente compararmos a dados do passado podemos rejeitar ou
aceitar a nova solução por causa de efeitos alheios.
A solução que eles utilizaram foi treinar um modelo para prever o número
de viagens em São Paulo utilizando os números do Rio de Janeiro e Belo
Horizonte (no nosso exemplo). Imagino que tenham usado outras features
também.
109
Então a comparação dos números em um determinado dia foi feita com
relação à previsão deste modelo para aquele dia. Dessa maneira eles teriam
uma ideia melhor de qual foi o efeito real do novo método de pagamento.
Claro que nenhum método é perfeito, mas o controle sintético é uma
ferramenta boa para usar nesses casos mais complexos.
110
Cuidados
Teste A/B está aleatório?
Verifique se o mecanismo que separa os indivíduos no teste A/B está
realmente aleatório.
Houve um caso em que eu estava testando um modelo e quando olhei a
proporção de produtos em cada categoria vi que eles não eram distribuídos
de maneira aleatória.
As proporções das características dos indivíduos do teste devem ser iguais
entre os dois grupos.
No caso acima, os produtos mais vendidos estavam caindo no grupo A, o
que dava a impressão que a nova solução era muito pior quando, na
verdade, após esse problema ser corrigido, vimos que o resultado era o
contrário.
Retreino online vs offline
Existem soluções de machine learning que treinam o modelo com cada
novo exemplo recebido. Isso é chamado de aprendizado online.
Eu não recomendo usar este aprendizado, porque ele acaba sendo bastante
vulnerável a ataques e problemas técnicos em geral.
111
Se um usuário mal intencionado enviar várias requisições para enviesar o
modelo a mudar as previsões, seu modelo estará comprometido.
O que eu mais vejo na prática (em todos os projetos que já trabalhei e
também de meus amigos mais próximos) é o retreino offline.
Basicamente, a cada N dias, semanas ou meses você vai rodar um conjunto
de scripts que vai baixar os novos dados, fazer as devidas verificações de
consistência, retreinar e salvar o modelo.
Neste passo ainda é importante a supervisão manual, olhando relatórios de
estatísticas sobre os dados, previsões e modelos para garantir que os dados
usados para treinar o novo modelo sejam confiáveis.
112
5 MONITORAMENTO DA
SOLUÇÃO
❧
Seu trabalho não acaba quando você coloca o sistema para funcionar em
produção.
Inevitavelmente os dados vão mudar e você terá que atualizar seu modelo.
Fora isso, problemas na ingestão dos dados, mudanças de arquitetura do
sistema e versões de software podem afetar o funcionamento do modelo.
Por isso é importante criar ferramentas de monitoramento.
113
Modos de monitorar
Podemos dividir o monitoramento em duas partes: monitorar os dados de
entrada do modelo (features) e monitorar a saída do modelo (previsão).
Os mesmos métodos podem ser utilizados para os dois tipos de
monitoramento.
Intervalos de valores
A forma mais simples de garantir que os dados que você está vendo em
produção são iguais àqueles que você usou para desenvolver o modelo é
verificar a distribuição.
Com os dados de treino você pode determinar quais os valores máximo e
mínimo esperados, além de percentis, média e desvio padrão.
Imagine que uma de suas variáveis seja a temperatura na cidade de
Salvador, Bahia.
Se você começar a receber dados dizendo que a temperatura está abaixo
dos 10 graus Celsius, provavelmente algo está errado. Se a temperatura
estiver negativa, pior ainda.
Ou imagine que nos últimos 1000 exemplos recebidos, 50% tenham um
valor que só deveria ocorrer em 5% do tempo. Pode ser um problema
técnico ou uma mudança drástica nos dados.
114
Distribuições dos valores
Uma alternativa mais atraente de monitoramento, além dos alertas de
valores fora dos intervalos, é visualizar a distribuição dos dados num
determinado período.
Desta maneira você conta com mais informações para decidir se tudo está
correndo bem, em vez de contar apenas com alguns cálculos de valores
extremos e médias.
Você também pode computar testes estatísticos que comparem a
distribuição de dados mais recentes com uma amostra representativa dos
dados de treino.
Mesmo que tudo pareça estar correndo bem, eu recomendo que você olhe
os dados periodicamente. O período correto varia em cada caso. Modelos
mais maduros podem ser verificados semanalmente, enquanto os mais
novos devem ser acompanhados de perto.
Não custa nada. E pode te economizar muita dor de cabeça.
Valores nulos
Mais comum do que valores fora dos intervalos esperados é monitorar
valores nulos. A falta de dados.
Você deve ter um alerta para saber quando uma conexão com a fonte de
dados falha ou qualquer outra razão que pare de enviar informações para
sua pipeline de produção.
115
Erros de implementação
Quanto mais complexa for a sua solução: envolvendo vários modelos e
milhares de features, maior a chance de algo ser computado de forma
incorreta.
O monitoramento de intervalos nos ajuda a encontrar estes erros mais
simples como, por exemplo, uma divisão que deveria ser multiplicação.
Durante o desenvolvimento de um dos mais bem-sucedidos fundos de
investimentos quantitativos do mundo (o Medallion da Renaissance
Technologies) uma estratégia que parecia muito boa em testes offline não
repetia os resultados em produção.
Após bastante investigação, e quase no ponto de desistir da estratégia, um
programador descobriu que alguém havia esquecido de mudar o código da
variável onde deveria ter o valor diário de um índice do mercado de ações
americano.
Em vez de receber o valor diário do índice, estava colocado um valor fixo.
Ao consertar este erro, os tão esperados retornos positivos começaram a
aparecer.
Esta empresa é conhecida por recrutar as mentes mais brilhantes de áreas
como física, matemática e engenharia. E mesmo assim não está imune a
este tipo de erro.
Comparar com offline
116
Uma maneira mais complexa e detalhada de verificar o funcionamento do
modelo em produção é comparar com resultados offline.
Se você baixar os dados que foram gerados em produção e usar os
notebooks/scripts de desenvolvimento para gerar as previsões, com o
modelo treinado, o resultado é similar?
Imagine que seu modelo gere resultados relevantes para busca o dia todo e
armazene as features e previsões num banco de dados. Como esses valores
se comparam ao resultado do parágrafo acima?
Você pode avaliar comparando diferenças numéricas com um nível de
tolerância: se a diferença estiver abaixo de 5 dígitos, por exemplo, tudo
pode estar de acordo com o planejado.
Dessa maneira você verá exatamente os pontos onde estão ocorrendo
diferenças. Dificilmente o resultado será exatamente igual.
117
Métricas do Alvo
Métricas técnicas
É importante computar também os dados correspondentes ao seu alvo em
produção.
Se você estiver fazendo recomendações de produtos numa campanha e
prevendo quais clientes vão comprar nos próximos 7 dias, é importante
calcular quais foram os exemplos com alvo positivo e negativo ao final do
período.
Dessa maneira você pode calcular as mesma métricas técnicas que você
usou durante a modelagem.
Em alguns casos isso pode ser complicado: se você quiser prever se um
cliente vai cancelar uma inscrição nos próximos 3 meses, por exemplo.
Tente encontrar um ponto intermediário.
Métricas de negócios
Mais importante do que as métricas técnicas, é saber como seu modelo está
afetando as métricas de negócio.
Se essas métricas estiverem negativas, não adianta justificar que as métricas
técnicas, features e modelo estão corretos. O que importa é como o seu
modelo vai impactar o negócio.
118
Essas são as métricas definidas no primeiro passo da nossa jornada.
119
Degradação Natural de Performance
Todo modelo vai degradar pelo tempo porque todo fenômeno modelado vai
mudando (mesmo que lentamente) com o passar do tempo.
É importante esperar e monitorar essa degradação em produção.
No guia de séries temporais você aprende a medir qual deve ser o período
esperado para um nível de degradação “aceitável”.
Geralmente o modelo obedecerá esse ciclo, mas assim como os fenômenos
modelados mudam, o tempo que eles demoram para mudar também muda.
Então fique atento e verifique se a performance do modelo está caindo mais
rápida do que o esperado.
120

Idioma

OManual Praticode Data Science

Enviado por

Dados do documento

Título original

Direitos autorais

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

OManual Praticode Data Science

Enviado por

Direitos autorais:

Transaction: HP15615810282991 e-mail: edubastosmail@gmail.com CPF: 052.348.

Você também pode gostar