O seu modelo está certo. E completamente inútil. Como isso é possível?

Imagine que você é contratado para resolver um problema real.

Uma empresa de crédito quer prever quais clientes vão deixar de pagar. O histórico tem cem mil transações. Você prepara os dados, escolhe o algoritmo, treina o modelo, avalia no conjunto de teste. A acurácia aparece na tela: 97,3%.

Você respira fundo. Isso é um resultado excelente. Você prepara a apresentação, mostra os números, o cliente fica impressionado. O modelo vai para produção.

Duas semanas depois, o telefone toca. O modelo não está funcionando. Está sinalizando quase ninguém como inadimplente. A equipe de risco continua no escuro.

Você volta para os dados e descobre o que deveria ter visto antes de treinar qualquer coisa: 97,3% dos clientes no histórico nunca deixaram de pagar.

O modelo aprendeu uma política perfeita e completamente inútil: classificar todo mundo como adimplente. Acerta 97,3% das vezes. Não detecta um único caso de inadimplência. E do ponto de vista da métrica que você otimizou, é um modelo excelente.

Esse cenário tem um nome técnico. Chama-se problema de classes desbalanceadas. É um dos erros mais comuns em projetos reais de Machine Learning. E ele não acontece porque o engenheiro não sabia programar. Acontece porque a métrica errada foi escolhida para o problema errado — e ninguém percebeu até ser tarde.

A ilusão da acurácia

A acurácia é a métrica mais intuitiva em classificação: de todas as previsões que o modelo fez, qual fração estava correta?

É também, em muitos problemas reais, a métrica mais enganosa que existe.

O motivo é simples. A acurácia trata todos os erros como iguais e todos os acertos como iguais. Mas no mundo real, erros não são iguais. Classificar um e-mail legítimo como spam é um inconveniente. Classificar um tumor maligno como benigno é uma tragédia. Classificar uma transação fraudulenta como legítima custa dinheiro. Classificar uma transação legítima como fraudulenta constrange um cliente inocente.

Quando as classes são desbalanceadas — quando um resultado é muito mais raro que o outro — a acurácia infla artificialmente porque o modelo aprende que a estratégia mais segura é sempre prever a classe majoritária. Ele nunca erra na maioria. E a maioria é quase tudo.

O problema, claro, é que a classe minoritária é frequentemente a que importa. Fraudes são raras — mas são o que você quer detectar. Tumores malignos são menos comuns que benignos — mas são o que o diagnóstico precisa pegar. Falhas em equipamentos industriais são infrequentes — mas são exatamente o que o sistema de manutenção preditiva existe para antecipar.

Um modelo com 99% de acurácia num problema de detecção de fraude pode estar errando em 100% das fraudes reais. E a métrica não vai te contar isso.

O problema mais fundo: medir o que é fácil, não o que importa

O desbalanceamento de classes é apenas o exemplo mais visível de um problema mais profundo.

Em Machine Learning, medimos o que conseguimos medir com facilidade. Acurácia, precisão, recall, F1-score, AUC-ROC — todas são métricas que calculamos sobre um conjunto de dados rotulados, num momento específico, sob condições controladas. São números reais, reproduzíveis, comparáveis entre modelos.

O que raramente medimos com a mesma rigor é o que realmente importa: o modelo funciona no mundo real, com dados que ninguém rotulou, em situações que não estavam no conjunto de teste, produzindo consequências para pessoas reais?

Essa distância — entre o que medimos e o que importa — tem um nome que já mencionei no artigo anterior: a Lei de Goodhart. Quando uma métrica se torna o alvo, ela deixa de ser uma boa medida do objetivo original. O modelo otimiza a métrica. E a métrica não é o objetivo.

Deixa eu tornar isso concreto com três casos que qualquer estudante de ML vai encontrar cedo ou tarde.

O modelo de recomendação que maximiza cliques. Cliques são fáceis de medir. Satisfação do usuário, valor de longo prazo, qualidade da informação consumida — não são. Então você otimiza para cliques. O modelo descobre que conteúdo sensacionalista, indignante ou controverso gera mais cliques do que conteúdo preciso e equilibrado. A métrica sobe. O objetivo real desce.

O modelo de seleção de currículos que minimiza tempo de contratação. Contratar rápido é mensurável. Contratar bem é difícil de quantificar. O modelo aprende a favorecer candidatos parecidos com os que foram contratados antes — porque esses têm maior probabilidade histórica de passar pelo processo inteiro sem atritos. Diversidade cai. Viés histórico se perpetua. O tempo de contratação diminui. A métrica está ótima.

O modelo de saúde que reduz readmissões hospitalares. Readmissões são um indicador de qualidade do cuidado — pacientes que voltam ao hospital logo após a alta provavelmente não receberam tratamento adequado. Faz sentido otimizar para reduzi-las. Mas um estudo real mostrou que alguns hospitais reduziram readmissões simplesmente deixando de admitir pacientes de alto risco — porque se o paciente nunca é admitido, ele nunca pode ser readmitido. A métrica melhorou. O cuidado piorou.

Em todos esses casos, o modelo fez exatamente o que foi pedido. O problema estava na pergunta, não na resposta.

O que perguntar antes de olhar para qualquer métrica

Quando apresento resultados de modelos em aula, passei a exigir que os alunos respondam três perguntas antes de mostrar qualquer número.

A primeira: o que exatamente essa métrica está medindo? Não o nome dela — o que ela calcula, matematicamente, e o que isso representa no contexto do problema.

A segunda: quais tipos de erro essa métrica ignora ou subestima? Todo indicador agrega informação e, ao agregar, esconde alguma coisa. O que está escondido aqui?

A terceira: se o modelo otimizar perfeitamente essa métrica e nada mais, o problema estará resolvido? Essa é a mais difícil — e a mais importante. Porque frequentemente a resposta é não, e perceber isso antes do treinamento vale mais do que qualquer ajuste de hiperparâmetro depois.

Essas perguntas não são difíceis de entender. São difíceis de lembrar de fazer — especialmente quando você está no meio de um projeto, com prazo, com um conjunto de dados na mão e um algoritmo pronto para rodar. A pressão natural é começar a treinar e ver o que acontece. A disciplina necessária é parar um momento antes e perguntar: o que vou medir, e isso é realmente o que preciso saber?

Uma coisa que mudou na minha forma de ensinar

Durante um tempo, ensinei métricas de avaliação como uma lista de ferramentas: acurácia serve para isso, precision-recall serve para aquilo, use AUC-ROC quando as classes são desbalanceadas. Uma receita.

Receitas são úteis. Mas receitas não ensinam a pensar — ensinam a seguir passos. E o problema com seguir passos em ML é que os problemas reais raramente se encaixam nas categorias da receita.

Hoje começo pelo outro lado: pelo objetivo de negócio, pelo problema humano, pela consequência real de cada tipo de erro. Só depois chegamos às métricas — como traduções imperfeitas de algo que importa para algo que conseguimos calcular.

A pergunta que quero que os alunos saiam sabendo fazer não é qual métrica usar? É o que estou disposto a perder quando escolho otimizar isso?

Porque toda escolha de métrica é um trade-off. Aumentar a sensibilidade de um detector de fraude significa aceitar mais falsos positivos — mais clientes legítimos bloqueados. Reduzir falsos positivos significa aceitar mais fraudes passando despercebidas. Não há configuração perfeita. Há escolhas — e essas escolhas têm consequências para pessoas reais que nunca vão ver o código que as afeta.

Entender isso não é saber Machine Learning. É saber o que fazer com Machine Learning.

O modelo com 97,3% de acurácia estava certo.

E era completamente inútil.

A diferença entre as duas coisas não está no algoritmo. Está em quem, antes de apertar o botão de treinar, parou para perguntar: certo em relação ao quê — e isso é o que eu preciso?