Do notebook à decisão: o que falta para um modelo virar produto

Um modelo que fica no notebook não gera valor nenhum. A última fase do ciclo é a mais esquecida por quem aprende ciência de dados só pela teoria — e é a única que transforma ROC AUC em decisão de crédito. Este artigo é sobre o que já está pronto para essa travessia e o que ainda falta.

O que já está pronto

A decisão de arquitetura da fase de preparação foi tomada pensando neste momento. O módulo de preparo é autocontido de propósito — não importa nenhum outro arquivo do projeto — justamente para que a aplicação em produção possa chamá-lo sem arrastar o repositório inteiro:

parametros = carregar_parametros("parametros_preparacao.json")
proposta_preparada, _ = preparar_dados(proposta_do_cliente, parametros)
probabilidade = modelo.predict_proba(proposta_preparada)[:, 1]

A mesma função que preparou o treino prepara a proposta que chega pelo formulário. Passar parametros=None faz a função aprender; passar o dicionário do treino faz ela apenas aplicar. Isso elimina a classe de bug mais comum em deploy de ML: treino e produção tratando o dado de formas sutilmente diferentes.

O que o monitoramento precisa vigiar

Comportamento de crédito muda — com a economia, com a política de originação, com o perfil de quem procura a fintech. Três coisas entram no painel:

• Distribuição das features — a população que chega hoje parece a que treinou o modelo?
• Calibração — a probabilidade média prevista ainda bate com a taxa realizada? Este é o alarme mais importante, porque a decisão depende da probabilidade, não do ranking.
• Custo realizado × custo previsto — a economia projetada na simulação está acontecendo na carteira?

A limitação que não tem conserto aqui

Como registrei na parte sobre os dados: a base não tem identificador de cliente nem coluna temporal. Isso impede duas coisas que um projeto de crédito em produção exigiria — o split temporal (treinar no passado, validar no futuro) e a detecção de drift ao longo do tempo. Não é um detalhe menor, e por isso está declarado na documentação em vez de escondido.

O que essa série provou até aqui

• Acurácia de 93,3% é o resultado de não fazer nada — o piso precisa estar na tabela.
• Um conversor com errors="coerce" apagaria 2.950 clientes com 40% de inadimplência, em silêncio.
• Podar a árvore recuperou +0,231 de ROC AUC; o conselho padrão de balancear classe teria destruído a calibração e negado 87% da carteira.
• A diferença entre os dois melhores modelos não é real — e saber disso mudou o critério de escolha.
• O ponto de corte sai do custo do erro, não do 0,5 de fábrica.

Nenhuma dessas conclusões veio do algoritmo. Todas vieram de perguntar, em cada fase, o que o número realmente está dizendo.