Aurora: um modelo de risco de crédito do zero ao deploy

Uma fintech de crédito pessoal precisa decidir a quem emprestar sem travar o crescimento nem deixar o risco comer a margem. Este é o mapa de um projeto que atravessa essa decisão inteira — do arquivo que nem abre no pandas até o ponto de corte que minimiza o custo da carteira. Doze partes, cinco modelos, e as armadilhas que quase custaram caro no caminho.

O case usa uma fintech fictícia — a Aurora Crédito Digital — sobre uma base pública de risco de crédito. A arquitetura, o código e todos os números são reais.

A série, parte a parte

Do problema ao dado

• 1. Além do score: prevendo inadimplência e explicando o risco — por que 90 dias e por que dois anos: a definição do alvo que transforma um desejo em problema verificável.
• 2. As 7 perguntas que transformam um pedido vago em problema de dados — e o custo assimétrico de 10:1 do qual sai, por derivação, o limiar de corte de 9,09%.
• 3. Seis armadilhas numa base de crédito — o conversor ingênuo que apagaria 2.950 clientes com 40% de inadimplência, em silêncio.
• 4. Garimpando sinais: quais features realmente preveem o calote — histórico de atraso domina renda e idade, e duas features novas saem de uma conta simples.
• 5. Um pipeline onde o vazamento é impossível por construção — a diferença entre evitar data leakage com disciplina e torná-lo estruturalmente impossível.

Modelagem

• 6. Cinco candidatos e um piso de comparação — 93,3% de acurácia é o resultado de aprovar todo mundo. O Dummy entra como candidato oficial.
• 7. A árvore que decorou a base inteira — ROC AUC 0,99997 no treino contra 0,6148 na validação, e a poda que recuperou +0,231. Mais a armadilha do class_weight.
• 8. Boosting: dois caminhos, o mesmo desenho vencedor — 50 sorteios de hiperparâmetros, e dois algoritmos independentes convergindo para a mesma configuração.

Avaliação e decisão

• 9. A diferença entre os dois melhores modelos é real? — 2.000 reamostragens para descobrir que a vantagem do primeiro sobre o segundo é cara ou coroa.
• 10. Abrindo a caixa-preta: por que o modelo negou este cliente — as três perguntas que o comitê de crédito faz, e por que "o modelo disse" não é resposta.
• 11. O ponto de corte que vale milhares de reais — o limiar sai do custo do erro, não do 0,5 de fábrica.
• 12. Do notebook à decisão: o que falta para um modelo virar produto — o que já está pronto para o deploy e a limitação da base que impede detectar drift.

O resultado, em uma tabela

Cinco candidatos, mesmas dobras, avaliados uma única vez em 37.500 clientes que nenhum deles tinha visto:

O LightGBM perde em ROC AUC por 0,000062 — diferença que o bootstrap mostra ser ruído — e lidera em PR AUC, acurácia e calibração. É a probabilidade calibrada, não o terceiro decimal do AUC, que sustenta a decisão de crédito.

Cinco conclusões que a série produziu

• Num problema com 6,7% de eventos, 93,3% de acurácia é o resultado de não fazer nada.
• errors="coerce" é uma decisão de negócio disfarçada de argumento técnico — aqui, apagaria o grupo de maior risco da base.
• Balancear classe destruiu a calibração: o modelo passaria a prever 30% de inadimplência onde a real é 6,7%, e o limiar econômico negaria 87% da carteira.
• A vantagem do boosting sobre a floresta é real; a do XGBoost sobre o LightGBM não é. Saber a diferença mudou o critério de escolha.
• O ponto de corte é uma decisão de negócio derivada do custo do erro, e o modelo só serve para ela se a probabilidade estiver calibrada.

Um projeto irmão

Se você chegou aqui pelo tema de modelagem preditiva aplicada a decisão, o outro case completo do blog segue o mesmo rigor em um problema de regressão: prevendo LTV do zero ao deploy, onde a regressão linear venceu o Random Forest — e o motivo disso é informação, não fracasso.