‍Neste artigo, iremos abordar uma etapa do processo de construção de um modelo preditivo, a estruturação do problema e definição da variável resposta. Esta etapa, na minha opinião, é a mais importante do processo na prática, impactando muito a qualidade da solução gerada. É nesta fase do projeto que pensamos nas seguintes questões:
‍

• Em qual momento meu modelo irá ser executado para cada observação? Será necessário eu calcular em tempo real ou pode ser em batch? Quais dados tenho disponível neste momento?
• Meus dados históricos possuem algum viés?
• Minha variável resposta está bem definida? Quais são os problemas dela?
• Como iremos validar o modelo?
• Como meu modelo irá impactar a próxima geração do modelo?
  ‍

Apesar da sua importância, muitas vezes é deixada de lado, principalmente pelos iniciantes na área. Os motivos pelas pessoas não darem a devida importância a essa etapa são muitos. Um dos que mais me incomoda é quando o cientista diz que isto é uma definição de negócio. É claro que toda definição tem que ser acompanhada pela área de negócio, mas é fundamental o cientista acompanhar e sugerir / validar cada escolha, visto que temos que saber se os dados que temos atendem as escolhas, se temos problemas de vieses, se temos os dados no momento que o modelo irá ser executado e assim por diante. Logo, é um trabalho que deve ser feito em conjunto e, por isso, é fundamental, cada vez mais, os cientistas terem mais noção de business. Outra razão para isso é o Kaggle. Nada contra ele, o considero uma ferramenta sensacional e tem contribuído muito para a evolução da Ciência de Dados no mundo. Porém, muitos cientistas iniciantes acreditam que o trabalho de um cientista de dados é igual a uma competição do Kaggle e isso não é verdade – apesar de que temos etapas que lembram muito. E a principal diferença é que no Kaggle, na maioria das vezes, a estrutura do problema e a variável resposta já estão definidas e o trabalho é muito mais a parte de construção e validação do modelo.
‍
Para exemplificar, iremos mostrar estes desafios em três situações que vemos frequentemente na Datarisk: um problema de aprovação de crédito, um problema de Churn de clientes e um problema de otimização de uso de cupom de descontos.
‍
Assim, podemos deixar claro o quanto o senso de negócio é importante para um cientista de dados. Vamos lá!
‍

Problema de aprovação de crédito
‍

Atendemos muitos clientes com o problema comum de como otimizar a aprovação de crédito. O objetivo é sempre o mesmo: “como aumento minha taxa de aprovação e reduzo minha inadimplência ao mesmo tempo?” A estruturação deste problema depende muito do tipo de crédito também. Aqui, vamos exemplificar com um produto de cartão de crédito e imagine que fomos contratados por uma fintech com dados históricos de um ano de operação.
‍

Tempo
‍

As primeiras perguntas que devemos fazer são: “em que etapa do pedido de crédito devemos responder se o prospect é aprovado ou não?” e “devemos responder a decisão na hora da aplicação?”. Por exemplo, se precisamos responder na hora e depois da terceira tela do aplicativo, não poderemos usar nenhum dado informado ou coletado posteriormente, o que pode impactar o modelo.
‍

Viés
‍

A terceira pergunta é: “meus dados históricos possuem algum viés?”. Em geral, a resposta para modelos de crédito é sim. Mas porquê? Isso ocorre pois, muito provavelmente, seus dados históricos são de clientes que foram aprovados anteriormente por alguma regra de crédito e não temos dados dos clientes que foram rejeitados por esta regra. Logo, se não nos atentarmos a isso, construiremos um modelo somente com o público aprovado anteriormente e aplicaremos em qualquer prospect novo. Assim, nossa amostra não reflete o público em que o modelo preditivo será utilizado e isto pode ser bem grave. Existem algumas maneiras para diminuir este viés, dentre elas, podemos destacar as técnicas de inferência de rejeitados.
‍

Variável resposta
‍

Agora podemos nos questionar: “qual é a melhor variável resposta?”. Vocês devem estar pensando que a variável resposta deve ser inadimplência, isto é, quero saber quem irá pagar ou não a fatura do cartão. Mas o que é a inadimplência? Como definimos? O que vocês acham de considerarmos quem ficou mais de 180 dias de atraso como inadimplente? Parece fazer sentido, dado que, muito provavelmente, quem ficar mais de 180 dias em atraso não irá pagar a fatura.
‍
Mas qual o problema de usar 180 dias? Bom, para saber quem ficou mais de 180 dias, temos que olhar faturas que aconteceram anteriormente ao período e isto pode impactar bastante no modelo, pois dados mais “velhos” (mais de 6 meses atrás) podem não representar tão bem dados mais recentes e além disso, como temos apenas um ano de histórico, utilizar 180 dias é equivalente a perdemos metade dos dados históricos.
‍
Mas por que não podemos usar os dados mais recentes? Imagine todas as faturas de 3 meses atrás, é esperado que boa parte já tenha sido paga hoje e podemos concluir que estes clientes são bons, já os que estão em atraso ainda não sabemos se serão bons ou ruins (na nossa definição de 180+). Por que não podemos usar a parte que sabemos que é boa para construir o modelo e ignorarmos os outros clientes? Se fizermos isso, o modelo irá aprender que todo mundo que é novo (características do público mais recente) é bom.
‍
Já vimos que 180 dias pode não ser uma boa solução. E se utilizarmos 10 dias? Qual é o problema? Bom, com 10 dias de atraso, muito provavelmente, marcaremos como “maus” clientes que esquecerem de pagar ou que estão passando por uma pequena dificuldade, mas que irão pagar. Isto é, a taxa de falsos positivos com esta definição será alta.

Bom , 10 e 180 não parecem boas escolhas. Então, como escolhemos? Há algumas situações em que a escolha é baseada em alguma regulação (Banco Central, por exemplo), mas em muitos casos, temos liberdade. Assim, o que costumamos fazer é uma série de análises para escolher, junto com a área de negócios, o que funciona melhor, sempre levando em consideração os prós e contras de cada escolha. Uma análise que fazemos com frequência é calcular a porcentagem de cura (voltar a ficar adimplente) para cada dia de atraso e o número de observações que teremos para cada dia de atraso. Um bom critério é selecionarmos o dia de atraso que a porcentagem de cura é baixa e perdemos poucas observações recentes.
‍
E quanto ao número de faturas consideradas? Utilizamos apenas a primeira fatura ou utilizamos 12 faturas para decidir o que é bom ou mau? Este também é outro ponto muito importante na definição da nossa variável resposta. Os prós e contras de cada escolha são parecidos com relação ao número de dias de atraso. Se optarmos por olharmos a primeira fatura, teremos mais dados, mas a taxa de falso negativo pode ser bem alta, além de que teremos problemas de sazonalidade, visto que a inadimplência, em geral, apresenta sazonalidade. E se considerarmos 12 faturas? Teremos muito menos falsos negativos, mas também teremos menos dados para modelar e dados mais antigos. De novo, não há certo ou errado, e sim quais prós e contras você prefere. Provavelmente, a melhor solução é um número entre estes dois.
‍

Validação
‍

Com a variável resposta, estamos quase prontos para começar de fato o modelo preditivo. Mas como iremos garantir que nosso modelo preditivo irá funcionar em produção da mesma forma que durante sua construção? Não há como termos esta garantia, mas há um conjunto de técnicas para validarmos os resultados e assim reduzir a probabilidade de um problema futuro. Em geral, aplica-se às técnicas usuais de criar bases de treino, validação e teste (há várias nomenclaturas aqui) ou usar alguma outra estratégia como cross-validation.
‍
Porém, na prática, isso pode não ser suficiente. O que percebemos bastante é que o efeito do tempo pode impactar e muito seus resultados, isto é, o modelo treinado com dados de 2020 pode funcionar muito pior em 2021, simplesmente por uma mudança de comportamento da sociedade ou qualquer outro motivo. Assim, é essencial, na prática, levar o tempo para fazermos nossas validações, com pelo menos uma base de validação out-of-time.
‍
Na Datarisk, além destas técnicas, também costumamos avaliar cada variável do modelo no tempo. Fazemos isso por um monitoramento das distribuições das variáveis ao longo do tempo, mas também construindo um modelo de classificação em que dados do treino tem a variável resposta como 0 e dados da validação do tempo tem a variável resposta como 1 e utilizamos as mesmas variáveis explicativas no modelo. Sob a hipótese de que a distribuição das variáveis não se alteraram, é esperado que este modelo tenha uma performance aleatória. Na prática, é comum encontrarmos boas métricas de performance, mas com esse modelo podemos ver quais variáveis se destacam e assim podemos pensar nos planos de ação.
‍

Impacto Futuro
‍

Por fim, também pensamos como a solução que estamos construindo irá impactar sua evolução. Por exemplo, com o modelo preditivo de crédito pronto, iremos passar a aprovar clientes de acordo com este modelo. Como estes dados que irão ser gerados por estes clientes irão impactar no retreino deste modelo? A resposta é parecida com o que já discutimos, mas será que podemos pensar em outras soluções? Algo que já vimos funcionar na prática é um teste, em que uma parte dos prospects são aprovados de uma forma aleatória (ou quase aleatória, somente com filtros de política ou uma regra menos rigorosa). É claro que isto gera um custo e, portanto, devemos sempre fazer isso com o mínimo possível e calcular o custo benefício de uma política dessa.
‍

Problema de Churn
‍

Neste tipo de problema, nosso cliente, geralmente, quer se antecipar a um possível Churn, ou seja, ter um cliente que se torne inativo.
‍
Não comentaremos todos os pontos como fizemos para o problema de crédito para não ficarmos repetitivos. Assim, falaremos apenas sobre a definição da variável resposta e possíveis vieses que podemos causar.
‍
Logo, nossas primeiras perguntas são: “o que é Churn?” e “é ficar inativo uma semana, um mês, dois meses, reduzir seu consumo em 80% ou alguma outra definição?” É um problema similar à definição da variável resposta de crédito e, mais uma vez, o cientista de dados precisará de suas habilidades de analista de negócio para conseguir definir de uma forma que o modelo final realmente seja útil.
‍
Um problema que já vimos na prática é o modelo aprender somente informações óbvias. Por exemplo, o modelo pode aprender apenas que as variáveis de recência, frequência e valor (RFV) são importantes, ou seja, o modelo pode falar que quem está usando o cartão de crédito não é Churn e quem não está é. Óbvio que isso faz sentido, o problema é que se o modelo aprender apenas isso, usar o modelo ou apenas regras simples teriam, aproximadamente, o mesmo resultado prático. Este problema pode ocorrer por uma variável mal definida ou ser algo característico no seu problema. Neste último caso, recomendamos criar uma solução combinando modelos com e sem as variáveis de RFV.
‍

Problema de otimização de cupom de desconto
‍

Nosso último exemplo aborda um problema um pouco mais complexo, o problema de otimização de cupom de desconto. “Para quem é lucrativo vale a pena eu dar um cupom de desconto?” “Será que com este cupom de desconto eu consigo evitar um Churn ou fazer o cliente ser mais fiel a minha marca?” Idealmente, o objetivo é saber quanto um cupom de desconto dado para o cliente “X” irá trazer de retorno.
‍
Assim, podemos pensar em criar uma variável resposta que seja o retorno ou uma proxy de retorno “Y” dias ou meses após cada cupom de desconto emitido ou não emitido. Se conseguirmos criar um modelo que nos dê essa resposta, podemos criar uma política para decidir quem irá ou não ganhar o cupom de desconto.
‍
Mas aí começam os problemas. O primeiro deles é que quase nunca é fácil criar uma proxy para retorno, além de que, no mundo real, não conseguimos controlar que o cupom de desconto é o único fator que interfere neste retorno. Entre outros pontos que temos que pensar estão:
‍

• Quanto tempo é o “efeito” do cupom de desconto?
• Há somente um tipo de cupom de desconto? Os valores dados são iguais ou diferentes? Como podemos diferenciar os diferentes tipos de cupom de descontos?
• Como medimos múltiplos cupom de descontos?
• No nosso histórico de dados, os cupons de descontos eram distribuídos aleatoriamente ou tinham algum viés de políticas anteriores?

Todas essas perguntas não são fáceis de serem respondidas, mas todas devem ser analisadas minuciosamente para melhorar a solução gerada pelo cientista de dados.
‍

Conclusão:
‍

Neste post discutimos uma das etapas que consideramos fundamental na construção de um modelo preditivo, a estruturação do problema. Por meio dos exemplos apresentados, tentamos deixar claro como cada decisão obtida nesta etapa é importante. A mensagem final é que cada vez mais o cientista deve se preocupar e trabalhar seu senso de negócio, além de sempre validar todos os passos da construção com a área que mais entende do problema.
‍
Quer saber mais sobre o assunto ou descobrir quais são as soluções que a Datarisk pode oferecer? Acesse o nosso site.

‍