O primeiro resultado foi bom demais e isso certamente estava mal.

Eu queria estudar uma modelagem para Crédito Verde e meu modelo tinha acertado quase tudo, a área sob a curva ROC que beirava 1, e qualquer pessoa que trabalha com Machine Learning sabe só pode significar uma coisa: o modelo não ficou bom, tem é alguma coisa está errada.

O contexto

Estou terminando um MBA e resolvi atacar um problema que me interessa: por que empresa pequena não acessa crédito com condições melhores quando se pensa em sustentabilidade? A resposta não é porque custa caro, afinal esse tipo de subsídio exige a contratação de auditorias, laudos, consultorias, relatórios. O que para uma grande empresa é uma linha no orçamento, para uma padaria o custo é inviável.

A pergunta que me fiz: dá para dizer alguma coisa útil sobre o perfil socioambiental de uma empresa usando só dado que já existe, sem pedir nada a ela?

Peguei 2,7 milhões de empresas ativas a partir de registros públicos: cadastro fiscal, autuações ambientais, sanções de integridade, dados de vínculos de trabalho. Todos os dados publicados pelos órgãos governamentais, nenhum dado enviado pela empresa.

A armadilha

Meu desenho inicial era o óbvio (e simplificado demais): agrupar as empresas por características socioambientais, usar os grupos como rótulo, treinar um modelo para prever esse rótulo.

Foi aí que veio o resultado perfeito e o grande erro: eu tinha criado o rótulo a partir das mesmas variáveis que depois entregava ao modelo. Ele não estava aprendendo nada sobre as empresas, estava redescobrindo a minha própria regra de agrupamento. Um espelho, não um modelo.

Esse tipo de erro não aparece em nenhuma métrica, pelo contrário, normalmente ele é um excelente disfarce para um resultado preguiçoso. Em Estatística você aprende desde o primeiro dia de aula que 90% do trabalho é tratar dados, analisar tabelas básicas e estatísticas simples para definir quais resultados importam. Quando se estuda modelos de regressão aprende-se o que é relação espúria e overfitting. E são justamente esses cuidados básicos que se deve ter ao colocar todos os seus dados no liquidificador do aprendizado de máquina.

A correção: separar quem define a régua de quem faz a previsão

A primeira correção foi abandonar o agrupamento automático de teste inicial. Afinal eu queria testar um modelo e não o que o grande liquidificador da combinação Claude Code e Python poderiam me entregar. Então, construí uma régua de classificação ancorada em critérios oficiais, como a taxonomia que o setor bancário usa para dizer quais atividades econômicas contribuem para a economia verde, combinada com as estatísticas descritivas do comportamento observável de cada empresa. Deixou de ser “o algoritmo decide” e passou a ser “o critério replicável e documentado, acelerado pelos algoritmos”.

Na segunda etapa, o modelo entrou para responder outra pergunta: dá para antecipar essa classificação usando apenas o que se sabe da empresa no balcão, antes de qualquer consulta cara? E foi aqui que tomei a decisão que considero a mais importante do projeto: proibi o modelo de enxergar qualquer variável usada na régua. Ele trabalha só com porte, capital social, tempo de atividade e ramo. Quatro informações que qualquer analista tem na tela em dois minutos.

As métricas caíram e eu comemorei

Com o desenho corrigido e o rótulo mais rico, a performance recuou e foi exatamente o que eu esperava. No universo de ML, o número quase perfeito significava somente uma coisa: o modelo estava lendo a resposta. A métrica de avaliação não pode se basear exclusivamente em um número alto, e sim no contexto geral. Construir um modelo impõe que ele seja capaz de inferir algo lidando com informações limitadas e ruídos reais, resultando em uma aproximação útil da realidade.

No contexto do meu estudo, a decisão que interessa na prática, a saber, se a empresa é elegível ou não ao crédito, a separação ficou forte o suficiente para servir como filtro inicial, e isso nunca substitui análise completa, apenas tenta reduzir o custo da triagem, indicando rapidamente quais casos realmente valem uma análise aprofundada.

A orientadora me pediu para testar fatos históricos

Um modelo de crédito pode reproduzir desigualdade regional sem que ninguém perceba, e os algoritmos e o Brasil têm histórico nisso. Então separei os resultados por região e comparei duas coisas: a taxa de acerto do modelo para empresas que deveriam ser aprovadas, e a taxa de erro em cada região.

Duas descobertas.

  • Primeira: Norte e Nordeste aparecem com aprovação mais alta que o Sudeste, resultado da composição setorial dessas regiões, não de qualquer ajuste que eu tenha feito.
  • Segunda: onde o modelo erra mais nessas regiões, ele erra para cima, isto é, aprova quem a régua não aprovaria. E partindo de um princípio de justiça, se é para haver assimetria, que seja a favor da concessão do subsídio.

Esse tipo de teste mostra que a avaliação de um score, que decide acesso a crédito, e não é testado contra viés geográfico não deveria sair do papel.

O que ainda não está resolvido

As probabilidades do modelo ordenam bem, mas ainda precisam passar por um processo de calibração mais intensivo para uso real em crédito. Para melhorar as análises deve-se conseguir maior profundidade no quesito dados, pois parte dos indicadores sociais vem do setor, e não de uma empresa específica, uma vez que os microdados públicos são anonimizados, e isso é só uma limitação estrutural do dado disponível, não uma escolha.

Outra melhoria é que a régua é uma construção minha, ancorada em critério oficial, mas sem um gabarito externo para validar. Eu não tive acesso, se é que existe uma base de “verdade” sobre quais pequenas empresas são elegíveis a crédito verde.

Por que estou compartilhando

Nenhuma ideia nasce pronta e ninguém pesquisa sozinho. Compartilhar os achados é a forma mais direta de ser questionado, aprender e dar o próximo passo. Espero que este relato ajude alguém que esteja lidando com desafios parecidos e que as trocas aqui me empurrem para a próxima etapa dessa pesquisa, que está apenas começando.