A arte de avaliar modelos: métricas de classificação no palco do Azure

Olá, meus guerreiros! Espero que estejam bem. Escrevo este artigo com entusiasmo porque acredito que ele é fundamental para quem deseja trilhar o caminho rumo a se tornar um grande Cientista de Dados — quase como um capítulo de uma bíblia da área.

Hoje, com a evolução de ferramentas como o framework Scikit-Learn, a plataforma Azure Machine Learning e tantas outras, nunca foi tão simples construir modelos de Machine Learning. Se somarmos a isso a geração de código por IAs generativas como o ChatGPT, em poucas linhas já conseguimos montar um modelo, seja ele de classificação, regressão ou clusterização.

Mas aqui entra o nosso “calcanhar de Aquiles”: a avaliação. Muito além de apenas “cuspir previsões”, precisamos entender profundamente a performance do modelo por meio de métricas. É essa análise que nos permite julgar se o desempenho é realmente bom ou se o modelo não é confiável.

A avaliação não é uma etapa trivial: ela revela a maturidade do Cientista de Dados e é o momento de “vender o peixe” para a área de negócios, mostrando de forma clara e fundamentada se aquele modelo agrega valor ou não. Embora utilizemos o Azure Machine Learning como exemplo, a avaliação de modelos não se limita a essa plataforma. O que realmente importa — e será o nosso foco — é o raciocínio, o cálculo e a interpretação das métricas, aspectos que podem ser aplicados em qualquer ferramenta.

Neste artigo, vamos explorar de forma didática as principais métricas utilizadas em modelos de classificação em Machine Learning — e, para deixar a jornada mais leve, usaremos como exemplo uma base inspirada no clássico desenho Pokémon. Então, prepare-se: ajuste o assento, aperte os cintos e vamos decolar rumo ao mundo das métricas!

1. Relembrando: O que é um modelo de classificação?

Um modelo de classificação é um modelo de Machine Learning (ou Aprendizado de Máquina, em português) cujo objetivo é prever um rótulo (label), cujo valor representa uma categoria — em termos estatísticos, uma variável qualitativa.

Exemplo: Suponha que queremos prever a probabilidade de um paciente ter câncer com base em exames de rotina. O rótulo (label) nesse caso pode ser:

1. Sim → probabilidade de o paciente ter câncer

2. Não → probabilidade de o paciente não ter câncer.

   É importante ressaltar que o rótulo sempre deriva do contexto de negócio e pode ser representado de diferentes formas nas bases de dados. Por exemplo, em vez de usar as palavras "Sim" ou "Não", poderíamos representar os valores como 1 (para sim) e 0 (para não). O que realmente importa é a interpretação correta da variável.

   Outro exemplo é prever a previsão de nível de satisfação de cliente a partir de respostas de pesquisas ou comportamento de uso do produto. Exemplo de rótulos:

   1. Satisfeito - cliente feliz, propenso a recomendar o produto.

   2. Neutro - cliente indiferente, pode continuar ou cancelar o produto.

   3. Insatisfeito - cliente com probabilidade alta de cancelar o uso do produto e recomendá-lo negativamente. Nesse exemplo teríamos três opções de labels. Embora estejamos falando do resultado final gerado pelo modelo, o que acontece nos bastidores é que ele calcula a probabilidade de cada label. Por padrão, o modelo escolhe a classe com maior probabilidade, mas esse comportamento pode ser ajustado conforme a necessidade.

   
   

3. Contextualizando nosso 'BO', problema de negócio ...

Antes de partirmos para a construção de qualquer solução analítica — seja um dashboard, um modelo de Machine Learning, um aplicativo de Inteligência Artificial ou outra ferramenta — é fundamental compreender o propósito da solução. Ou seja, precisamos entender por que estamos construindo isso e qual problema de negócio queremos resolver, pois tudo gira em torno do negócio. Não criamos uma solução apenas porque Machine Learning é moderno; ela deve existir para atender a uma necessidade real. Construiremos um modelo de classificação que prevê o tipo de Pokémon com base nas seguintes estatísticas: ataque, defesa, ataque especial, defesa especial, HP e velocidade — atributos utilizados inclusive em batalhas de Pokémon. Atualmente na base de dados, disponibilizada em formato csv, existem cerca de 800 Pokémons registrados e 18tipos diferentes. O Pokemon, por exemplo, Pikachu é do tipo Elétrico, Chamander fogo enquanto Bulbasaur grama.

Brevemente, faremos a análise exploratória dos dados e, em seguida, a construção do modelo, utilizando uma Decision Tree. Este artigo não vai detalhar essas etapas, mas sim focar na avaliação do modelo. Ou seja: construímos o modelo e agora, produção? Primeiramente iremos preparar o ambiente no Microsoft Azure Machine Learning Studio seguindo o passo 2 descrito em detalhes nesse artigo. Veja o código.

4. Uma lupa: Avaliando o modelo

   
   

Meu guerreiro, para a avaliação de resultados, separamos uma parte da base de dados chamada teste, que o modelo ainda não conhece. Destinamos cerca de 10% dos dados para avaliar o modelo e calcular suas métricas. De forma geral, costuma-se reservar 80 a 90% para treino e 10 a 20% para teste.

Como estamos lidando com um modelo de classificação, cada previsão possui apenas duas possibilidades de resultado: acerto ou erro. Já em um modelo de regressão, preveríamos uma variedade de valores numéricos para a label, buscando que a previsão fique o mais próxima possível do valor real. Isso aumenta a complexidade do modelo, inclusive nos aspectos de avaliação e interpretação das métricas. Vale ressaltar que não existe modelo com 100% de acerto. Quando alcançamos esse resultado, a probabilidade de o modelo estar se enganando é muito alta. Isso pode indicar overfitting, que ocorre quando o modelo “decorou os dados” em vez de aprender padrões gerais — como um aluno que decora exatamente as questões de uma prova de matemática. O problema surge quando ele enfrenta uma prova diferente: nesse caso, provavelmente se perderá.

As métricas principais em problemas de classificação são: 1. matriz de confusão, 2. acurácia, 3. precisão, 4. recall, 5. f1-score, 6. curva ROC e 7. importância de features (disponíveis em modelos de árvores).

5. Matriz de Confusão

Para facilitar a compreensão, vamos considerar apenas um tipo de Pokémon: Fogo (Fire). Nesse caso, existem apenas duas possibilidades de valor: ser do tipo Fogo ou não. Para os demais tipos de Pokémon, o mesmo raciocínio se aplica. A partir disso, podemos derivar os seguintes conceitos fundamentais para avaliação de modelos de classificação:

• VP (Verdadeiro Positivo): o Pokémon é do tipo Fogo e o modelo previu corretamente. O modelo acertou.

• VN (Verdadeiro Negativo): o Pokémon não é do tipo Fogo e o modelo previu corretamente. O modelo acertou.

• FP (Falso Positivo): o Pokémon não é do tipo Fogo , mas o modelo previu que é. O modelo errou.

• FN (Falso Negativo): o Pokémon é do tipo Fogo, mas o modelo previu que não é. O modelo errou.

Nosso principal objetivo é reduzir o máximo possível os falsos (falso positivo e falso negativo) e aumentarmos os verdadeiros (verdadeiro positivo e verdadeiro negativo). Consolidarmos todos os valores em uma tabela chamada matriz de confusão.

Considerando o contexto, a classe positiva é: Pokémon do tipo Fogo, enquanto a classe negativa é: Pokémon não do tipo Fogo. É importante destacar que a conotação de “positivo” ou “negativo” não tem qualquer implicação de valor ou julgamento — trata-se apenas de uma forma de categorizar os resultados para análise do modelo. Ao invés de contabilizarmos manualmente cada valor, a biblioteca Scikit-Learn oferece um método pronto para isso, chamado confusion_matrix. Esse método calcula automaticamente os Verdadeiros Positivos (VP), Verdadeiros Negativos (VN), Falsos Positivos (FP) e Falsos Negativos (FN) a partir das previsões do modelo e dos valores reais da base de teste. Guerreiro, o óbvio precisa ser dito: comparamos os acertos do modelo confrontando os valores reais da base de teste com as previsões geradas pelo modelo. Estamos diante de um problema de Aprendizado de Máquina Supervisionado, no qual o modelo aprende a partir de exemplos previamente rotulados. Para cada tipo de Pokémon, teremos uma matriz de confusão própria, o que nos permite avaliar o desempenho do modelo individualmente para cada tipo. Isso significa que o modelo pode ser mais preciso em alguns tipos e menos em outros, revelando suas forças e limitações. A matriz de confusão é base para cálculo de todas as demais métricas. Para chegar nesses valores basta calcular os acertos e erros. Veja:

Previsões de resultados para os 15 primeiros

As cores verde e vermelha não foram escolhidas apenas para deixar a tabela mais atraente, mas para enfatizar o nosso foco na construção de modelos: maximizar os acertos (valores de VP e VN) e minimizar os erros (FP e FN).

6. Acurácia

   Esta é uma das métricas mais conhecidas e fáceis de compreender, oferecendo uma visão geral dos acertos do modelo, independentemente das classes. Ela indica a proporção de previsões corretas em relação ao total de previsões. Matematicamente o cálculo é dado por:

   

   VP - Verdadeiro Positivo, VN - Verdadeiro Negativo, FP - Falso Positivo, FN - Falso Negativo.,

   
   

A acurácia varia de 0 a 1 (ou 0% a 100%), quanto mais alta, melhor. Particularmente na avaliação de um modelo de classificação a acurácia é a primeira métrica indicada ser utilizada, porque fornece uma visão geral do desempenho, sendo as demais complementares e detalhistas.

• Ex.: Acurácia = 0,75 → significa que 75% das previsões do modelo estão corretas. Calculando rapidamente com o pacote sklearn, a acurácia do nosso modelo é 0,89, ou seja, o modelo acerta aproximadamente 89% das previsões para o tipo Fogo. No entanto, apenas olhar para a acurácia pode ser enganoso, especialmente em problemas com classes desbalanceadas, como é o nosso caso, em que a quantidade de cada tipo 1 de Pokémon varia bastante. Logo devemos considerar também as demais métricas.

  
  

7. Precisão

Essa métrica diz quantos exemplos que o modelo classificou como positivos são realmente positivos. Traduzindo para o nosso contexto de negócio, diz dos pokemons que o modelo disse que são do tipo Fogo, quantos realmente são? Em outras palavras, estamos enfatizando a exatidão. Assim como a acurácia, o valor da precisão varia entre 0 - 1 (ou 0 - 100%), sendo quanto mais alta melhor. A fórmula matemática é simples, veja:

VP Verdadeiro Positivo, FP Falso Positivo

Assim como qualquer métrica, podemos calcular manualmente ou utilizar bibliotecas e funções próprias para automatizar. A função classification_report do sklearn exibe as métricas principais de acurácia precisão, recall, F1 de maneira visual simples. Um clique, um relatório completo das métricas. Guerreiro, é o que eu sempre digo nas aulas: ferramenta é fácil. Hoje existem várias maneiras de codar, várias bibliotecas gratuitas, vários caminhos diferentes inclusive sugerido pelo agente ChatGPT. Mas o maior desafio nunca é escrever o código — é interpretar os resultados. É olhar para os números, pensar com a cabeça de negócio e se perguntar: “isso faz sentido?” Porque no fim, não é o modelo que entrega valor, é você entendendo o que aqueles números realmente significam. O cliente não te contrata porque você domina Python, Machine Learning ou o estado da arte da tecnologia. Ele te contrata para resolver um problema de negócio e facilitar a vida dele. E isso inclui avaliar modelos de forma inteligente, garantindo que eles realmente façam sentido e possam ser usados pelo cliente no dia a dia. Isso não é fácil, exige dedicação, tempo e muito treino.

Retornando ao nosso contexto: a precisão para Pokémons do tipo Fogo foi de apenas 14%. Isso significa que, a cada 100 Pokémons que o modelo afirma serem de Fogo, apenas 14 realmente são. O modelo está cometendo muitos falsos positivos — ou seja, diz que o Pokémon é de Fogo quando, na verdade, pode ser de qualquer outro tipo (Água, Venenoso, Elétrico, etc.). Em um cenário real, esse modelo dificilmente seria adotado, porque uma precisão tão baixa torna as previsões pouco confiáveis e pode prejudicar completamente a tomada de decisão. Não existe um valor “ideal” universal para métricas como precisão, acurácia, recall ou F1. Porém, em um cenário real, espera-se que esses valores sejam pelo menos superiores a 60%, para que o modelo comece a ser considerado minimamente útil e confiável. Por outro lado, métricas muito altas — em torno de 97% — geralmente indicam problemas na modelagem, tornando o produto pouco confiável. Na prática, é muito difícil alcançar valores tão elevados devido a diversos fatores, como a baixa qualidade da base de dados ou a imaturidade das features, o que costuma gerar resultados artificialmente inflados, enviesados e pouco realistas. Achar os valores ideias das métricas é um trabalho em conjunto do cientista de dados e a área de negócio. Guerreiros, não fique confuso, aos poucos conforme o trabalho e estudos, os conceitos irão simplificando.

8. Recall(Sensibilidade)

Conhecida também como taxa de detecção, mensura o quanto o modelo consegue encontrar corretamente os exemplos da classe positivo. Guarde bem essa palavra: encontrar. A métrica responde a seguinte pergunta: ”De todas as amostras que realmente pertenciam à classe positiva, quantas o modelo conseguiu identificar corretamente?”. Ela foca capturar o máximo possível de verdadeiros positivos (VP). No contexto de negócio, a métrica responde: de todos os pokemons que são de fogo, quantos o modelo conseguiu encontrar?

No primeiro momento as métricas recall e precisão podem parecer semelhantes, mas ambas caminham em direções diferentes. Recall = alcance, encontrar. Precisão = acertar. Um modelo pode identificar todos os Pokémons de fogo corretamente (ou seja, ter 100% de recall), mas ainda assim errar bastante na previsão. Por exemplo, ele pode marcar vários Pokémons que não são de fogo como se fossem — aumentando os falsos positivos. Nesse caso, o modelo “encontra” todos os de fogo, mas não acerta quem realmente pertence à classe, resultando em baixa precisão. Matematicamente, a fórmula é:

VP = Verdadeiro Positivo, FN = Falso Negativo

No nosso contexto, o recall dos pokemons de Fogo é 12%. Ou seja, o modelo consegue apenas detectar de 12% de todos os pokemons que são de Fogo, um valor bem baixo.

9. F1 Score

Ela é a média harmônica entre Precisão e Recall. Ela responde a pergunta: "O modelo está conseguindo encontrar os casos positivos e acertar ao mesmo tempo?" Em outras palavras, observando ela conseguimos avaliando simultaneamente a precisão e recall. A métrica varia de 0 a 1, sendo quanto mais alta, melhor. Matematicamente temos:

No nosso contexto, a F1-score responde à seguinte pergunta: o modelo está conseguindo detectar os Pokémons de fogo e, de fato, acertar essa previsão? As métricas precisão e recall são naturalmente conflitantes, formando um trade-off. Isso acontece porque, ao tentar aumentar o recall — ou seja, fazer o modelo encontrar o maior número possível de casos positivos — ele passa a classificar mais itens como pertencentes à classe positiva, o que tende a aumentar também os falsos positivos e, consequentemente, reduzir a precisão. Por outro lado, quando tentamos aumentar a precisão — deixando o modelo mais “exigente” para afirmar que algo é positivo — ele evita erros, mas acaba deixando de identificar muitos casos realmente positivos, reduzindo o recall. Por isso, melhorar uma dessas métricas geralmente piora a outra, e equilibrá-las é essencial, especialmente em problemas desbalanceados. Aí você meu guerreiro me questiona: e qual priorizar uma detrimento da outra? Bem, tudo dependerá do objetivo que se deseja alcançar com negócio. Se você disse para mim que é mais importante que o modelo identifique o maior número possível de pokemons Fogo, mesmo que ele algumas vezes, optaremos pelo Recall. Agora caso diga que o modelo deve acertar o máximo possível pokemons que são de fato de Fogo, mesmo que deixe de identificar alguns, optaremos pela Precisão. A F1 está com o valor de 13%, bem baixo assim como as demais métricas.

Guerreiro, perceba claramente se olharmos apenas para a acurácia com o valor de 89% para pokemons do tipo Fogo, iremos inferir que o desempenho está muito bom. Porém ao observamos as demais métricas que se complementam, notamos que o modelo está horrível e de fato está. Consegue perceber a importância de observar atentamente todas as métricas, uma a uma, analisar e principalmente interpretar. Bem, diante do cenário o próximo passo é melhorar o desempenho do modelo, porém isso é assunto riquíssimo para outro post. Brevemente aumentar o número de amostras da classes minoritárias, troca e teste de algoritmo utilizada na modelagem, construção de mais features significativas são algumas possíveis estratégias.

9. E no Final das Contas

Construir um modelo de machine learning de classificação nunca foi tão trivial principalmente devido as IAs generativas como, por exemplo, ChatGPT. Porém muito mais que "codar" por horas, um dos maiores desafios é avaliar o desempenho do modelo por meio de métricas. Metaforicamente, estaríamos experimentando "o peixe" para saber se precisa de mais tempero, assar mais ou não para que então oferecer e vender para o freguês. Para problemas de classificação, a matriz de confusão e as métricas de acurácia, precisão, recall e F1 auxiliam em uma compreensão profunda do desempenho do modelo. Elas permitem identificar não apenas quantas previsões o modelo acertou, mas também como ele acertou e onde errou — distinguindo falsos positivos, falsos negativos e o equilíbrio entre encontrar e acertar as classes. Esse conjunto de métricas oferece uma visão abrangente, essencial para avaliar a qualidade real do modelo e tomar decisões mais confiáveis sobre sua utilização. Se utilizarmos as métricas para avaliar o modelo de identificar pokemons de Fogo, estamos no caminho correto de uma solução inteligente. Agora é hora de limpar os recursos. Para evitar surpresas no cartão de crédito, exclua todos os recursos que criamos no decorrer da aula. Siga o passo 7 descrito em detalhe nesse artigo. Os scripts estão aqui. Beijos e até mais.