Fintomico
Guia técnico para montar um pipeline MLOps que re treina seu modelo de risco toda semana usando o comportamento de pagamento mais recente.
Em 2026, deixar um modelo de crédito estático por mais de 30 dias é jogar dinheiro fora. A inflação oscila, novas modalidades de pagamento via Pix surgem e o comportamento do consumidor muda rápido demais. O "Concept Drift" (a degradação da capacidade preditiva do modelo ao longo do tempo) não é uma exceção, é a regra.
Se você trabalha com Data Science em uma Fintech ou banco digital, sabe que o pesadelo não é treinar o primeiro modelo. É manter ele relevante. A solução real não é contratar mais cientistas de dados para ajustar manualmente hiperparâmetros, mas criar um sistema que se "auto-alimente".
Abaixo, detalho o processo exato para configurar um feedback loop de MLOps que retreina seu score de crédito semanalmente, usando Python, SQL e orquestração de workflows, sem depender de ferramentas de "botão mágico" que escondem a lógica.
O erro clássico é usar a tabela de inadimplência do ERP como "verdade". O ERP considera um atraso de 1 dia e 60 dias da mesma forma binária, ou usa regras de negócio obscuras que mascaram a performance real do cliente. Para um modelo de Machine Learning aprender, ele precisa de nuances.
Você precisa criar uma tabela SQL dedicada, o ground_truth_table, que é atualizada diariamente. Nela, o target não é apenas "pagou ou não pagou". Use a janela de observação correta.
Por exemplo, se o seu modelo aprova parcelado em 12 vezes, você não pode rotular o cliente como "bom" se ele pagou apenas a primeira parcela ontem. O target deve ser construído considerando a data de vencimento versus a data de liquidação, desconsiderando amortizações parciais menores que 10% do valor da parcela. Um script diário deve varrer o extrato bancário (conciliação Pix, boleto e TED) e marcar:
Sem essa separação limpa entre a ingestão de dados (brutos) e a construção do target (label), você estará treinando seu modelo com ruído.
Um modelo de crédito não aprende apenas com o que aconteceu "ontem". Ele precisa de contexto. O segredo do loop semanal é o uso de janelas móveis de tempo (time windows).
Configure sua query de treinamento para não pegar apenas dados da última semana, mas sim a evolução do cliente nos últimos 3 a 6 meses, atualizada semanalmente. Isso significa que, a cada domingo, o script deve recalcular as features para todos os clientes ativos nos últimos 180 dias.
Exemplo prático: a feature media_saldo_negativo_90d. Se você calcular isso apenas no momento da aprovação, ela fica obsoleta. No retreinamento semanal, você recalcularia:
SELECT
customer_id,
AVG(balance) FILTER (WHERE balance < 0) as media_saldo_negativo_90d
FROM transactions
WHERE transaction_date >= CURRENT_DATE - INTERVAL '90 days'
GROUP BY customer_id
Isso captura a degradação do perfil de risco. Um cliente que tinha score 900 em janeiro, mas que começou a ter的平均 saldo negativo em abril, precisa ter sua pontuação rebaixada agora, não quando o modelo anual for atualizado.
Automatizar tudo é ótimo, mas rodar o pipeline de retreinamento sem necessidade gera custo computacional alto e pode instabilizar o modelo se os dados da semana forem anômalos (como um feriado prolongado que atrasa pagamentos).
Implemente o cálculo do PSI (Population Stability Index). O PSI compara a distribuição das features do conjunto de treinamento original com a distribuição da última semana de dados recebidos.
A regra de ouro no mercado hoje é:
No seu orquestrador (seja Prefect, Airflow ou Dagster), crie uma tarefa de verificação que roda na sexta-feira às 18h. Se o PSI da feature renda_media_mensal ou utilizacao_limite_credito ultrapassar 0.1, a DAG libera o caminho para o próximo passo. Caso contrário, o pipeline aborta sem custo de GPU.
Nunca substitua o modelo em produção instantaneamente. Essa é a receita para uma crise de imagem se o modelo começar a negar crédito para todo mundo.
O passo 4 do seu loop é configurar o script para salvar o novo objeto binário (o arquivo .pkl ou .joblib) em um bucket S3 com um carimbo de data, sem sobrescrever o modelo atual. Configure sua API de score para carregar os dois modelos:
model_predictions_log.Durante as duas semanas seguintes ao retreinamento, você compara o que o "Challenger" teria feito versus o que o "Champion" fez. Se o "Challenger" tivesse aprovado 5% menos clientes e evitado R$ 200.000 em prejuízo de inadimplência, você tem um caso forte para a troca. Regressão Logística x Redes Neurais: Qual modelo satisfaz mais os auditores do Bacen?. Essa escolha técnica impacta diretamente a facilidade de explicar essa mudança para a auditoria.
Ao incorporar novos dados semanalmente, você corre o risco de o modelo capturar vieses sistêmicos recentes. Se a recessão atingiu duramente uma região específica nas últimas semanas, o modelo pode aprender que "morar no estado X" é fator de risco alto, o que pode configurar viés indevido.
Na etapa de pós-treinamento, antes mesmo de considerar o "Shadow Mode", rode testes de Fairness. Verifique se a Taxa de Aprovação (Approval Rate) para diferentes grupos demográficos não sofreu uma variação abrupta (limiar de desvio padrão > 2%) em relação ao modelo anterior. O argumento de que "a IA de crédito é neutra" cai por terra se os dados de entrada são tendenciosos. Mito: A IA de crédito 'neutra' elimina o viés humano na aprovação de empréstimos. Se o teste falhar, descarte o modelo da semana e investigue as features que causaram o viés.
A parte que a maioria dos tutoriais de MLOps esquece é o que dá errado. E se o seu pipeline de dados falhar e o score vier cheio de nulls? Se o cliente tentar fazer um empréstimo às 3 da manhã de um domingo e o modelo não responder, a experiência é frustrante.
Programe um bloco try-except na sua API de inferência:
try:
score = modelo_novo.predict(features)[0]
except:
score = modelo_antigo.predict(features)[0] # Rollback automático
alerta_sentry.capture_exception()
Além disso, configure uma regra simples de negócio no final da função de score: se o resultado for negativo e o valor do crédito solicitado for inferior a R$ 500,00, force uma aprovação manual ou use um modelo baseado apenas em regras (caso o modelo de ML tenha falhado). Isso garante que o sistema de pagamentos não pare completamente por causa de um erro numérico.
Implementar esse loop semanal consome recursos. Há o custo de armazenamento dos logs de inferência, o custo de computação para recalcular features a cada sete dias e o custo de manutenção da infraestrutura de orquestração. Mas, o custo da inação é maior.
Um modelo defasado em um ambiente de juros altos como o do Brasil em 2026 pode custar à instituição financeira entre 2% e 4% da sua Carteira de Crédito Classificada (CCL). Para um banco com R$ 100 milhões em crédito concedido, isso é R$ 4 milhões jogados fora por trimestre. O investimento no pipeline se paga no primeiro mês de operação.
Não tente construir todo o pipeline de uma vez. Comece monitorando apenas uma feature crítica (como atraso médio) e implemente o retreinamento manual baseado nesse alerta. Quando a confiança nos dados subir, automatize a troca. O objetivo não é substituir o cientista de dados, mas livrá-lo da tarefa repetitiva de calcular médias e atualizar arquivos CSV, permitindo que ele foque em estratégias de risco mais complexas.
A inteligência artificial não é um juiz isento; ela é um espelho matemático que replica e escalariza o racismo estrutural presente nos dados históricos dos bancos.
Para ciência de dados de crédito no Brasil, a escolha técnica entre modelos implica lidar com a auditoria do Bacen; descubra por que a 'explicabilidade' da Regressão Logística ainda vence a precisão das Redes Neurais na hora de justificar a recusa.