Data Science Financeira Parte 0: 7 coisas que tornam a data science financeira diferente do ML comum
(han-co.com)Estamos começando a série «Fundamentos de Data Science Financeira». Este texto é o primeiro episódio (Parte 0). A ideia é explicar, em ordem, como em um livro, desde a Parte 0, por que a data science funciona de forma diferente do ML comum no campo da análise de crédito. Vamos tratar de temas como reject inference, inferência causal, calibração, validação, fairness e regulação.
O texto original foi publicado primeiro no meu blog → https://han-co.com/ko/blog/part0-finance-ds-7-differences
Não sou um veterano com longos anos de experiência nessa área. Trabalhei como engenheiro na indústria e depois migrei para o setor financeiro; hoje trabalho como cientista de dados na área de análise de crédito. Então, em vez de ler este texto como “esta é a resposta certa”, prefiro que ele seja visto como uma organização das dúvidas em que me embananei ao entrar nesse campo, daquelas situações em que pensei: “Ué, eu fiz exatamente como estava no livro, então por que continua dando errado?”.
O curioso é que isso não aconteceu só comigo. Mesmo pessoas que dominam muito bem todo o processo de construção e avaliação de modelos de ML em geral acabam cometendo erros parecidos quando chegam à análise de crédito. Os indicadores de validação estão bons, mas em produção o modelo não entrega o desempenho esperado; a acurácia é de 99%, mas ninguém fica feliz; você extrai mais 0,01 de performance e o time de risco bloqueia o deploy…
Isso não é tanto um problema de habilidade, mas sim porque finanças (especialmente análise de crédito) não é simplesmente “aplicar ML a dados financeiros”; é uma área com regras um pouco diferentes. E quase tudo que vou abordar nesta série daqui para frente — reject inference, inferência causal, calibração, validação, fairness — no fim se baseia nessas regras.
1. Viés de seleção é o padrão
Nos dados de treino que temos, na verdade existe um grande buraco: só conseguimos ver o resultado de pagamento dos clientes aprovados. Nunca saberemos se os clientes rejeitados teriam pago ou entrado em default. Afinal, eles nem chegaram a receber o cartão.
No ML em geral, costuma-se assumir que “os dados representam a população”. Mas na análise de crédito essa premissa já nasce quebrada. Os dados de treino são de clientes aprovados no passado, enquanto o alvo que o modelo precisa avaliar é o conjunto completo de solicitantes que ainda não foram aprovados. São populações diferentes.
Todos os solicitantes
├─ Aprovados (resultado observado)
│ ├─ Pagamento → pagamento normal
│ └─ Default → atraso/default
└─ Rejeitados (resultado não observado) → ??? não sabemos se pagariam ou entrariam em default
O modelo aprende apenas com “clientes aprovados”. O resultado real dos clientes rejeitados não fica registrado nos dados.
Essa única característica gera mais problemas do que parece. Como não existem dados posteriores à rejeição dos “clientes rejeitados”, o modelo não consegue aprender a região que ele próprio rejeitou e acaba herdando, tal como está, o viés da política de análise do passado. Por isso, nessa área, reject inference (inferência sobre rejeitados) e inferência causal não são técnicas especiais, mas fundamentos. (Vou tratar de cada uma delas em profundidade em textos separados mais adiante.)
2. O tempo flui em uma direção, e o modelo envelhece
Se você embaralhou aleatoriamente os dados e rodou K-fold, na prática deu uma espiadinha no futuro. Isso porque os dados de validação acabam misturando passado e futuro.
Dados de crédito seguem o tempo. Um modelo treinado com dados de clientes de 2024 avalia clientes de 2026. Nesse intervalo, a economia muda, os juros sobem, o comportamento dos clientes muda, os produtos também. A distribuição deriva (drift). O K-fold aleatório mistura passado e futuro, colocando discretamente na validação informações que nunca estariam disponíveis no mundo real.
Por isso, a validação básica em finanças é OOT (out-of-time), isto é, avaliar em um período posterior ao de treinamento. E, depois do deploy, é preciso monitorar continuamente o quanto a distribuição se moveu e como os clientes mudam ao longo do tempo. O envelhecimento do modelo começa no exato momento em que ele entra em produção.
3. “Quem é mais arriscado?” não basta; é preciso “exatamente quantos %?”
Em problemas de classificação em geral, normalmente basta acertar a ordem. Se você consegue ranquear bem quem é mais arriscado, já está resolvido, e a AUC mede essa capacidade.
Mas em crédito isso não é suficiente. É preciso uma probabilidade absoluta, ou seja, um PD calibrado (calibrated PD). É necessário ter um número como “a probabilidade de default deste cliente é exatamente 3,2%” para precificar (risk-based pricing), constituir provisões (provisioning) e calcular perda esperada. Só o ranking não permite fazer nada disso.
Por isso, em crédito, esta situação é mais comum do que parece: um modelo com AUC excelente, mas com PD errado. Discriminação (discrimination) e calibração (calibration) são eixos diferentes, então é preciso cuidar dos dois. (Também preparei um texto dedicado só à calibração. Surpreendentemente, muita gente deixa isso passar.)
4. O custo é assimétrico, chega muito tarde e é medido em dinheiro
A acurácia (accuracy) conta todos os erros como se fossem iguais. Mas, em crédito, o peso dos erros não é nem de longe o mesmo.
O lucro de aprovar um bom cliente é a margem (alguns milhares de ienes), enquanto o custo de um default é LGD × EAD (centenas de milhares de ienes). Um lado pode ser dezenas de vezes mais pesado. Então, o que precisamos otimizar não é acurácia, mas lucro esperado e perda esperada.
Lucro esperado = (1 − PD) × margem − PD × LGD × EAD
A perda esperada em caso de default (EL) se decompõe novamente no produto de três elementos.
EL = PD × LGD × EAD
- PD: probabilidade de default
- LGD: perda dado o default
- EAD: exposição no momento do default
Cada um desses três elementos é um problema de modelagem diferente. O núcleo do scoring é o PD.
Além disso, a resposta correta chega muito depois. Só 12 a 24 meses depois é que se confirma se um cliente aprovado hoje entrou ou não em default. O fato de o rótulo chegar tão tarde entra bastante em choque com a mentalidade de ML acostumada a feedback rápido. É preciso continuar acumulando decisões sem ainda saber o resultado.
5. Estabilidade vence performance no limite
Em competições de ML, extrair mais 0,001 de AUC é uma virtude. Como em competições tipo Kaggle. Mas, em modelos de crédito de produção, isso muitas vezes sai caro.
Um modelo que ganha uma gota extra de performance ao custo de ficar instável logo vira custo operacional. É o caso de modelos cuja pontuação oscila com pequenas variações na entrada, não são reprodutíveis ou criam trechos estranhos como “quanto maior a renda, menor a pontuação”. Estabilidade operacional, reprodutibilidade e monotonicidade muitas vezes importam mais do que alguns decimais de desempenho. Esse também é um dos motivos pelos quais a regressão logística continua viva como padrão de scoring mesmo na era do GBM.
6. Interpretabilidade não é opção, é obrigação
Em outras áreas, conseguir explicar “por que saiu esta previsão?” é um bônus interessante. Mas, em crédito, sem isso muitas vezes o modelo se torna ilegal ou simplesmente não pode ser colocado em produção.
Notificação do motivo da rejeição (adverse action, 否決理由), explicações para o órgão regulador e governança interna — tudo exige explicar “por que esta pontuação”. Por isso, caixa-preta não é algo elegante; é um risco em si. É por isso que, no dia a dia, prefere-se estruturas como WOE ou scorecards, nas quais os motivos saem naturalmente, e mesmo quando se usa boosting, costuma-se preparar junto um mecanismo para extrair motivos com SHAP.
7. O overhead de regulação e governança está sempre presente
Por fim, não é possível colocar modelos em produção livremente.
Não acaba quando o modelo está pronto. Gestão de risco de modelo (MRM), validação independente, documentação e trilha de auditoria fazem parte do processo de desenvolvimento. Desenvolvedores e validadores são separados, e um modelo novo normalmente fica um bom tempo em shadow mode com observação paralela antes de entrar nas decisões reais. A intuição de startup de “vamos colocar logo em produção o modelo com melhor performance” não funciona muito bem aqui. Se é lento, há motivo. Um único modelo pode impactar até provisões e cálculo de capital.
(Trabalhando no Japão, isso fica ainda mais tangível. Em emissão de cartões e definição de limite, existe a obrigação legal, pela Lei de Vendas a Prazo Parcelado (割賦販売法), de calcular o valor estimado de capacidade de pagamento (支払可能見込額), então o modelo acaba se tornando fundamento legal. Vou tratar disso separadamente na parte sobre regulação.)
Isso tudo não vai ser feito pela IA?
Tenho ouvido muito essa pergunta ultimamente. Com IA generativa e agentes evoluindo tão rápido, será que ainda vale a pena aprender esse tipo de conhecimento de modelagem? Minha resposta sincera é: na verdade, ele ficou ainda mais necessário (pelo menos por enquanto).
Esses 7 pontos que vimos até aqui não dizem respeito a um algoritmo específico, mas à estrutura do problema nessa área. Contrafactuais não observados, dados que fluem no tempo, custos assimétricos, probabilidade absoluta, estabilidade, obrigação de explicação, regulação. Colocar um LLM em cima disso não faz esses problemas desaparecerem. Pelo contrário: é preciso alguém que saiba que eles existem para impedir que um modelo gerado automaticamente erre com toda a confiança do mundo.
Em especial, os itens 6 e 7 são centrais. É preciso explicar os motivos da rejeição, validar o modelo de forma independente, e o resultado disso serve de base para provisões e cálculo de capital. Modelos caixa-preta esbarram estruturalmente nesses requisitos. Por isso, a IA generativa não toma para si a análise de crédito inteira; em vez disso, permanece no papel de julgar o resultado que a IA produziu quem entende por que a explicabilidade é necessária e como a validação deve ser feita.
Claro, algumas coisas mudam. Escrita repetitiva de código e análises básicas gradualmente passam a ser papel da IA. Por isso, o centro de gravidade do trabalho sai da habilidade de montar modelos à mão e vai para a capacidade de formular corretamente o problema, validar e auditar com critério. É justamente esse segundo ponto que esta série pretende abordar.
Então, o que é ter habilidade nessa área?
Se condensarmos esses 7 pontos em uma frase, fica assim:
Data science financeira não é uma “competição de acurácia preditiva”, mas o trabalho de estimar contrafactuais não observados (counterfactuals) de forma explicável e estável, em um ambiente onde o tempo passa e os custos são assimétricos.
Métricas de avaliação e scorecards são como o ingresso de entrada. A diferença real de habilidade aparece em viés de seleção, causalidade, validação e governança.
Nesta série, pretendo explorar essas 7 questões uma a uma, com calma. Como resolver reject inference, por que tanta gente erra em calibração, por que inferência causal é central na análise, e como validar para sobreviver em produção. Vamos juntos a partir do próximo texto.
Este texto foi publicado originalmente em han-co.com e será serializado em coreano e japonês. O original com diagramas desenhados à mão e a assinatura por e-mail estão aqui → https://han-co.com/ko/blog/part0-finance-ds-7-differences
Ainda não há comentários.