Porque 83% de Accuracy me enganou: as métricas que realmente importam em
Machine Learning
Quando comecei a trabalhar no meu primeiro projeto de Machine Learning, uma das
primeiras métricas que procurei foi a Accuracy.Faz sentido. É simples. É intuitiva. E parece responder à pergunta mais importante: Quantas vezes o modelo acertou? Após treinar o modelo surgiu um resultado que, à primeira vista, parecia bastante positivo. Accuracy = 82,89%. A minha reação inicial foi semelhante à de muitos iniciantes. Pensei: Excelente. O modelo acerta em mais de 80% dos casos. Mas bastaram alguns minutos de análise para perceber que a realidade era bastante diferente. Na verdade, aquele valor estava a esconder um problema importante. Foi uma das lições mais valiosas que retirei desta fase de aprendizagem. Nem sempre um número aparentemente bom significa que o modelo é realmente útil.
O problema da Accuracy
Vamos imaginar uma situação muito simples. Uma empresa possui 100 clientes. Destes 100 clientes: 95 estão satisfeitos. 5 estão insatisfeitos. Agora imagine que desenvolvemos um sistema extremamente preguiçoso. Sempre que recebe um cliente responde: Cliente satisfeito.
Independentemente da situação. O que acontece? O sistema acerta nos 95 clientes satisfeitos.
Falha apenas os 5 insatisfeitos. Resultado: Accuracy = 95%. Parece fantástico. Mas o sistema é praticamente inútil. Nunca identifica os clientes problemáticos. Nunca gera alertas.
Nunca apoia decisões. A Accuracy é elevada porque a maioria dos casos pertence à mesma categoria. Este é precisamente um dos problemas mais comuns em Machine Learning.
O que aconteceu no meu projeto
No exercício da empresa logística, o objetivo era prever reclamações. O conjunto de dados apresentava uma característica muito importante. A maioria dos envios não gerava reclamações. Apenas uma pequena parte dos registos correspondia a casos problemáticos. O modelo aprendeu rapidamente uma estratégia simples. Em vez de tentar identificar reclamações, começou a assumir que praticamente todos os
envios eram normais. Como a maioria dos casos realmente não apresentava reclamações, a Accuracy manteve-se elevada. Mas havia um problema.
Uma analogia com a segurança
Imagine um aeroporto. Existe um sistema de segurança responsável por identificar passageiros perigosos. Agora imagine que o sistema toma sempre a mesma decisão:
Passageiro seguro. Se apenas 1 em cada 10.000 passageiros representar um risco, o sistema terá uma Accuracy extremamente elevada. Mas será um bom sistema? Claro que não. O objetivo não é acertar nos passageiros normais. O objetivo é identificar precisamente os casos raros. O mesmo acontece em muitas aplicações empresariais. Fraude. Falhas. Avarias. Reclamações. Incumprimentos. São normalmente eventos raros. E é precisamente por isso que a Accuracy isolada pode ser enganadora.
A Matriz de Confusão
Foi então que descobri uma ferramenta chamada Matriz de Confusão. O nome parece complicado, mas a ideia é bastante simples. A matriz permite visualizar quatro situações possíveis.
Verdadeiro Positivo
O modelo prevê uma reclamação. reclamação acontece. Acertou.
Verdadeiro Negativo
O modelo prevê ausência de reclamação. Não existe reclamação.
Acertou.
Falso Positivo
O modelo prevê reclamação. Mas a reclamação nunca acontece.
Erro.
Falso Negativo
O modelo prevê que tudo irá correr bem. Mas o cliente reclama.
Erro. Este último caso costuma ser o mais perigoso. Porque transmite uma falsa sensação de segurança.
Precision: quando o modelo dispara um alerta
Imagine um sistema que identifica possíveis fraudes. Sempre que gera um alerta queremos que esse alerta seja credível. É aqui que surge a Precision. A Precision responde à pergunta:
Quando o modelo prevê um problema, quantas vezes está correto? Uma Precision elevada significa que os alertas tendem a ser confiáveis. Uma Precision baixa significa que os utilizadores irão começar a ignorar os avisos.
Recall: a métrica que mais me surpreendeu
Foi aqui que encontrei a maior limitação do meu modelo. O Recall responde à pergunta:
Quantos dos problemas reais foram efetivamente identificados? o meu caso:
Recall = 0.00. Quando vi este valor percebi imediatamente que algo não estava bem. O modelo praticamente não identificava reclamações. Era como um detector de incêndios que nunca toca. Mesmo quando existe fogo. Pode parecer silencioso e eficiente. Mas falha precisamente quando mais precisamos dele.
O exemplo da eficiência energética
Imagine um sistema destinado a identificar edifícios energeticamente ineficientes.
Um município possui 500 edifícios. Apenas 15 apresentam desperdícios significativos.
Se o sistema concluir que todos os edifícios estão a funcionar corretamente, poderá
apresentar uma Accuracy muito elevada. Mas não identificará nenhum dos edifícios problemáticos. Na prática não gera qualquer valor. O Recall torna-se muito mais importante do que a Accuracy. Porque queremos garantir que os edifícios problemáticos são realmente identificados.
F1 Score: procurar equilíbrio
Em muitos projetos existe uma tensão natural entre Precision e Recall. Se quisermos identificar todos os problemas possíveis, podemos gerar demasiados falsos
alarmes. Se quisermos apenas alertas extremamente fiáveis, podemos deixar escapar situações
importantes. O F1 Score procura equilibrar estas duas dimensões. Funciona como uma espécie de compromisso entre:
● Precisão.
● Capacidade de deteção.
É uma métrica particularmente útil quando trabalhamos com conjuntos de dados
desequilibrados.
ROC AUC: olhar para o modelo de forma global
Outra métrica que utilizei foi o ROC AUC. O nome assusta muitos iniciantes. Mas a interpretação é relativamente simples. Podemos imaginar uma escala.
0.50 = Aleatório
0.60 = Fraco
0.70 = Aceitável
0.80 = Bom
0.90 = Excelente
O meu modelo obteve aproximadamente: ROC AUC = 0.60
Isto indicava que o sistema possuía alguma capacidade de distinguir operações
problemáticas das restantes. Mas ainda estava longe de um desempenho robusto.
Foi uma avaliação muito mais honesta do que olhar apenas para a Accuracy.
Porque isto é importante para as empresas
Muitas organizações estão a iniciar projetos de Inteligência Artificial. Naturalmente procuram indicadores simples. É tentador apresentar apenas uma Accuracy elevada. Mas isso pode conduzir a decisões erradas. Imagine sistemas destinados a:
- Detetar fraude.
- Identificar falhas industriais.
- Prever avarias.
- Antecipar reclamações.
- Identificar desperdícios energéticos.
Nestes casos, compreender as métricas corretas pode ser mais importante do que escolher
o algoritmo mais avançado. Um modelo aparentemente excelente pode revelar-se inútil quando chega ao mundo real.
A maior lição que aprendi
Antes deste projeto eu via a Accuracy como a métrica principal. Hoje vejo-a apenas como uma peça do puzzle. Um modelo não deve ser avaliado apenas pelo número de vezes que acerta.
Deve ser avaliado pela sua capacidade de gerar valor para o negócio. E isso depende do contexto. Em alguns casos queremos evitar falsos alarmes. Noutros queremos garantir que nenhum problema passa despercebido. As métricas devem refletir esse objetivo.
Conclusão
Uma Accuracy de 83% parece impressionante. No meu caso, acabou por ser uma excelente lição de humildade. Mostrou-me que os números precisam de contexto. Mostrou-me que um modelo aparentemente bom pode esconder limitações importantes. E mostrou-me que a interpretação dos resultados é tão importante quanto o desenvolvimento do próprio modelo.
Talvez esta seja uma das maiores diferenças entre fazer Machine Learning e fazer Machine
Learning útil. Os algoritmos produzem números. Mas são as pessoas que lhes atribuem significado.