Modelo de churn com desempenho enganoso
Um modelo de propensão ao churn para clientes PJ foi treinado com 100 mil registros históricos. A base tem 4% de clientes que efetivamente cancelaram. O modelo final apresenta acurácia de 96%, AUC de 0,71 e recall de 0,22 para a classe positiva. A área de negócio quer usar o modelo para priorizar 2.000 ligações de retenção por mês. O time de dados comemora a acurácia e sugere publicar o modelo em produção na próxima semana. Há ainda um alerta do comitê de privacidade: algumas variáveis usadas são proxies de região e de renda média do bairro. O split foi feito aleatoriamente, mas os dados cobrem 18 meses e o comportamento de cancelamento mudou após uma alteração de tarifas ocorrida no 12º mês.
1. Avalie se a acurácia de 96% é um bom indicador para este problema. Explique o que os números de recall e AUC revelam.
Read the worked answer
Não. Com apenas 4% de positivos, um modelo trivial que classifique todos como 'não churn' já acertaria 96%. A acurácia é, portanto, inflada pela classe majoritária e não mede a capacidade de encontrar quem vai cancelar.
O recall de 0,22 significa que o modelo identifica só 22% dos cancelamentos reais; se há cerca de 4.000 positivos na base, ele deixa passar mais de 3.000. Para uma ação de retenção, isso é grave: a maior parte de quem sairia nunca receberia a ligação. O AUC de 0,71 indica poder discriminatório modesto - melhor que o acaso, mas longe de separar bem as classes. Antes de publicar, seria necessário analisar a matriz de confusão, a precision na faixa dos 2.000 primeiros scores (o topo do ranking é o que importa operacionalmente) e a curva de ganho acumulado, além de calibrar o limiar de decisão conforme o custo de cada ligação.
2. Identifique dois riscos metodológicos no setup e proponha como mitigá-los.
Read the worked answer
Risco 1: vazamento temporal no split aleatório. Como o comportamento mudou após o 12º mês, embaralhar os registros mistura passado e futuro, inflando o desempenho e escondendo a degradação. Mitigação: validação temporal (treinar nos meses 1 a 12 e testar nos meses 13 a 18) e monitoramento de drift em produção, com reavaliação periódica.
Risco 2: variáveis proxy de região e renda. Elas podem gerar discriminação indireta e violar políticas de uso responsável de dados, além de tornar o modelo frágil a mudanças de cadastro. Mitigação: análise de impacto por subgrupos, teste de substituição ou remoção dessas variáveis, documentação do racional e validação com o comitê de privacidade antes da publicação.
Há ainda um risco de desalinhamento com o negócio: otimizar AUC em vez do ganho nas 2.000 ligações. Recomenda-se definir a métrica operacional (por exemplo, precision@2000) e comparar com a política atual antes de ir a produção.