Prevendo inadimplência de 90+ dias em uma carteira de crédito não garantido

Entendimento do negócio

o que a decisão precisa ser, antes de existir modelo

A Aurora é uma fintech de crédito pessoal não garantido para renda baixa e média. Cresceu em volume, mas a margem líquida oscila. A pergunta do comitê não é "quem é bom pagador" — é qual política de aprovação gera mais valor sem assumir risco incompatível com a estratégia.

Três objetivos em conflito: crescimento (manter volume de aprovações), risco (reduzir exposição) e rentabilidade (o árbitro entre os dois). O modelo não resolve o conflito — ele dá a linguagem comum para negociá-lo.

A saída do modelo é uma probabilidade, não uma classe

O modelo estima a probabilidade de inadimplência. A decisão de aprovar ou negar vem depois, aplicando um limiar econômico. Isso torna a calibração um requisito: um modelo que ranqueia bem mas cuja probabilidade não corresponde à realidade invalida qualquer limiar.

A assimetria de custo e o que ela implica

Um falso negativo (aprovar quem dá calote) custa 10× um falso positivo (negar quem pagaria). Duas consequências saem direto dessa razão:

• O limiar ótimo teórico é p* = 1 / (1 + 10) = 9,09%, não 50%.
• Acurácia está descartada como critério — ela pesa os dois erros igualmente.

Baselines simulados

A base não tem coluna de decisão histórica, então o custo da política atual não é observável. Foram simulados quatro pontos de referência:

A última linha é a barra a bater: 0,3749 por cliente.

Entendimento dos dados

o arquivo se chama credito_tratado.csv e não está tratado

O arquivo não abre com leitura padrão

pandas.errors.ParserError: Error tokenizing data.
        C error: Expected 1 fields in line 57579, saw 2

Separador é ;, quebra de linha CRLF. Corrigido isso, apareceu algo pior: duas colunas contínuas chegam como texto.

Um teto artificial em 2,0

Distribuição de razao_divida acima de 1: existem 34.779 registros entre 1 e 2, zero entre 2 e 10, e 358 acima de 10. Distribuição contínua não tem buraco assim. Alguém winsorizou em 2,0 ao produzir o arquivo, e os registros gravados como texto escaparam do clip — 355 dos 358 valores acima do teto são exatamente eles.

Resultado: 31.215 clientes (20,81% da base) empilhados em razao_divida == 2,0, com valor sintético.

Ausência de dado é sinal de risco menor

Contraintuitivo e decisivo: quem não informou renda inadimple menos. Imputar pela mediana sem sinalizar destruiria essa informação. A ausência também é aninhada — todos os 3.924 sem dependentes estão dentro dos 29.731 sem renda_mensal, nenhum ao contrário. É falha estrutural de coleta, não acaso.

Descartar as linhas com nulo não é opção

Custaria 29.731 clientes (19,82%) e 1.669 inadimplentes — 16,65% de toda a evidência de calote da base. E os descartados são um perfil específico: mediana de idade 57 contra 51, razao_divida 6,76× maior. Além disso, em produção esse cliente vai chegar: uma em cada cinco propostas não traz renda informada.

Outros problemas catalogados

• Sentinelas 96 e 98 nas colunas de atraso — 269 clientes, sempre nas três colunas ao mesmo tempo (prova de que é marcação de registro, não comportamento), com 54,65% de inadimplência contra 6,60% do restante.
• Renda máxima de R$ 3.008.750 contra p99 de R$ 25.000 — 120×. E 1.634 clientes com renda exatamente 0, que é ausência disfarçada.
• 1.573 linhas 100% duplicadas (1,05%). Sem id_cliente, não há como saber se é a mesma pessoa.
• Caudas impossíveis: um cliente com 54 financiamentos imobiliários (p99 = 4).
• Sem id_cliente e sem coluna temporal — impede split temporal, que seria o correto para um alvo de janela de 2 anos. Limitação declarada.

Preparação dos dados

uma função, chamada por todo mundo — inclusive pelo app

Split 75/25 estratificado no alvo. A assimetria foi preservada com 0,0018 ponto percentual de diferença entre treino (6,684444%) e teste (6,682667%).

Toda a preparação vive em uma função única, em módulo autocontido que o app Streamlit importa direto. Passar parametros=None faz a função aprender; passar o dicionário do treino faz apenas aplicar.

# os sinalizadores precisam ser criados antes da imputacao
        base["renda_ausente"] = base["renda_mensal"].isna().astype("int8")
        base["dependentes_ausente"] = base["dependentes"].isna().astype("int8")

        base["renda_mensal"] = base["renda_mensal"].fillna(parametros["mediana_renda"])

        # as sentinelas aparecem sempre nas tres colunas ao mesmo tempo
        base["historico_atraso_sentinela"] = (
            base[COLUNAS_ATRASOS].isin(parametros["valores_sentinela"]).any(axis=1).astype("int8"))
        for coluna in COLUNAS_ATRASOS:
            base[coluna] = base[coluna].clip(upper=parametros["limite_atrasos"])

        base["renda_por_dependente"] = base["renda_mensal"] / (base["dependentes"] + 1)
        base["sobra_caixa"] = base["renda_mensal"] * (1 - base["razao_divida"])

Resultado: 112.500 × 17 no treino, zero nulos, zero linhas perdidas. Seis colunas novas.

As colunas novas carregam sinal?

Das duas features contínuas, renda_por_dependente tem gradiente monotônico limpo por quartil — 9,66% / 6,79% / 5,49% / 4,64%. Já sobra_caixa saiu contaminada: 6,62% / 9,47% / 6,44% / 4,20%, com o quartil mais baixo tendo risco menor que o do meio.

O pipeline

Três passos: preparo → imputação → modelo. O preparo é uma casca em volta da função acima e não trata nada por conta própria. Como o fit acontece dentro de cada dobra da validação cruzada, o vazamento fica impossível por construção — na prova, a dobra 1 aprendeu mediana de renda 5.386 enquanto as outras aprenderam 5.400.

O SimpleImputer é rede de segurança, não tratamento: hoje recebe zero nulos. Existe para o campo vazio inesperado vindo do app. E todos os passos devolvem DataFrame, para que o SHAP explique razao_divida e não feature 4.

Modelagem

validação cruzada estratificada, 5 dobras, sempre sobre o treino

Métricas: ROC AUC, PR AUC e acurácia. Nenhuma delas significa nada sem o chão ao lado — dado que a prevalência é 6,684%, o chão é ROC AUC 0,5000, PR AUC 0,066844 e acurácia 0,933156.

Primeira rodada: o chão e a árvore sem poda

ROC AUC de 0,999997 no treino contra 0,614817 na validação. A árvore com max_depth=None cresce até isolar cada cliente numa folha própria: não aprendeu o padrão da inadimplência, decorou os 112.500 clientes do treino.

Onde exatamente começa o overfitting

Catorze tamanhos testados, cada um com validação cruzada de 5 dobras.

A árvore por dentro: três níveis

Uma árvore de profundidade 3, treinada na base completa de treino. Oito folhas, e apenas 3 das 16 features entram nela.

Com três níveis a árvore não tem espaço para renda, idade, dependentes ou as features criadas. Ela gasta toda a profundidade disponível em comportamento de pagamento — o que é coerente com o negócio, e mostra por que a explicabilidade por SHAP será necessária: a importância global esconde que o resto das variáveis só aparece em árvores mais profundas.

Random Forest: profundidade contra desbalanceamento

Vinte e quatro configurações — oito profundidades por três tratamentos de class_weight. Com prevalência de 6,684%, balanced daria à classe inadimplente 14× mais peso que à adimplente.

Sem peso, a probabilidade média (0,066968) bate com a taxa real (0,066844) na terceira casa decimal. Com balanced, o modelo prevê 30,4% de inadimplência onde a realidade é 6,7% — e o Brier mais que dobra. A consequência é operacional, não estatística: aplicando o limiar econômico de 9,09% definido na Fase 1, o modelo balanceado negaria 87% da carteira contra 18,8% do modelo sem peso.

É o mesmo raciocínio que já apareceu na Fase 1 por outro caminho: negar demais custa mais caro que aprovar demais. Decisão: Random Forest sem class_weight. O desbalanceamento se trata no limiar, que é onde ele é um problema de decisão — não nos pesos, onde ele vira um problema de probabilidade errada.

O que cada folha significa para a operação

Oito perguntas separam uma folha com 68,77% de inadimplência de outra com 2,10% — uma diferença de 33×. A folha 3 sozinha carrega 80.488 clientes, 71,5% da carteira, com risco três vezes menor que a média. É esse contraste que uma política de crédito consegue explorar.

Repare que só duas folhas saem rotuladas como inadimplente. As folhas com 52,10% e 49,25% são classificadas como adimplente porque o predict() padrão usa limiar 0,5. Com o limiar econômico de 9,09%, seis das oito folhas seriam negadas. O limiar não é detalhe de implementação — é a decisão de negócio.

Boosting: XGBoost e LightGBM

Busca aleatória com 25 sorteios por modelo, mesmas cinco dobras, scoring='roc_auc' e random_state=42. O pipeline inteiro entra na busca, então cada candidato refaz a preparação por dobra.

Os dois convergiram para o mesmo desenho, por caminhos diferentes: taxa de aprendizado baixa (~0,018), muitas árvores e regularização forte. O LightGBM conteve a complexidade com num_leaves=15; o XGBoost, com min_child_weight=50. Nos dois casos a busca ganhou menos em desempenho do que em estabilidade — o gap treino-validação do XGBoost caiu de 0,077 para 0,015.

Comparação final dos cinco candidatos

Mesmas dobras para todos, cada um na melhor configuração encontrada.

Avaliação

37.500 clientes nunca vistos — a leitura que vale

A base de teste foi separada na Fase 3 e não foi tocada desde então: nenhuma mediana, nenhum hiperparâmetro, nenhuma escolha de modelo passou por ela. Cada candidato foi treinado no conjunto completo de treino e avaliado uma única vez aqui. Depois desta leitura o teste está gasto — usá-lo de novo para escolher qualquer coisa o transformaria em um segundo conjunto de validação.

O teste confirmou a validação cruzada

Os quatro ficaram acima da validação cruzada. Nenhuma degradação: o protocolo da Fase 3 — preparação aprendida dentro de cada dobra, teste isolado desde o início — segurou. A diferença positiva soma dois efeitos esperados: o modelo final treina com 100% do treino, contra 80% em cada dobra, e este recorte de teste saiu marginalmente mais fácil que a média das dobras.

Existe diferença real entre os modelos?

Diferença pareada contra o XGBoost, que teve o maior ROC AUC. Se o intervalo de confiança cruza o zero, a vantagem não se distingue de ruído.

Calibração em dados nunca vistos

A decisão de não usar peso de classe se confirma da forma mais direta possível: os quatro erram a probabilidade média por menos de 0,0005 em dados que nunca viram. O limiar econômico de 9,09% definido na Fase 1 é aplicável como está — negaria cerca de 18% da carteira.

Onde o projeto está

e o que vem em seguida

Os cinco candidatos foram testados. A árvore isolada parou em 0,8458, abaixo da meta; o Random Forest atravessou a linha com 0,8629; e o boosting fechou em 0,8651 (LightGBM) e 0,8648 (XGBoost) — empate técnico entre os dois.

Vale registrar a escala do que sobrou: entre a árvore podada e o melhor boosting há 0,019 de ROC AUC. Entre a árvore sem poda e a árvore podada havia 0,231. A escolha do algoritmo importou dez vezes menos que a decisão de podar — e as duas juntas importam menos que os problemas de dados encontrados na Fase 2.

O teste foi aberto e confirmou tudo: 0,8692 de ROC AUC contra a meta contratada de 0,85, com calibração intacta. O que falta da Fase 5 é traduzir isso em decisão: varrer o limiar pelo custo da carteira — não pela acurácia — e produzir a explicabilidade individual por SHAP, que é o que permite dizer a um cliente e a um regulador por que aquele crédito foi negado.

O teste, a partir de agora, está gasto. Qualquer ajuste que venha a ser feito olhando para ele deixa de ser avaliação e vira seleção.