Classes desbalanceadas aparecem quando um classificador recebe muito mais exemplos de uma categoria do que de outra. Nessa situação, a taxa geral de acertos pode esconder um sistema que ignora justamente o evento que você precisa encontrar. Para avaliar com clareza, acompanhe a matriz de confusão, precisão e revocação por classe, além do volume de casos enviados para revisão.
A decisão prática deve partir do erro que custa mais no seu processo. Deixar passar uma reclamação urgente e encaminhar uma mensagem comum para a equipe especial são falhas diferentes. Defina esses custos, preserve uma amostra de teste que represente a operação e escolha o limiar de decisão em dados separados do teste final.
Resumo rápido
- Acurácia alta pode coexistir com nenhuma detecção da classe rara.
- Mostre quantidades de acertos e erros, além das métricas agregadas.
- Precisão mede a qualidade dos alertas; revocação mede quanto do evento foi encontrado.
- Reamostragem deve ocorrer dentro do treinamento, sem contaminar a avaliação.
- Escolha limiares conforme o custo dos erros e a capacidade real de revisão.
Por que a acurácia isolada pode enganar
Imagine um conjunto fictício de mil mensagens, das quais vinte pertencem à categoria “problema urgente”. Um sistema que responde “mensagem comum” para todas acerta 980 casos. Sua acurácia seria 98%, apesar de não encontrar nenhum problema urgente. Esses números são apenas uma demonstração aritmética, não um resultado de mercado.
O desbalanceamento não torna a acurácia matematicamente incorreta. Ela continua sendo a fração de previsões corretas. O problema é usá-la como resposta para uma pergunta diferente: “o sistema encontra os casos importantes sem criar uma fila impossível?”. Essa pergunta exige analisar tipos de erro e suas consequências.
Também não há uma proporção universal a partir da qual o conjunto passa a ser inadequado. A dificuldade depende da separação entre as classes, da qualidade dos rótulos e da quantidade de exemplos relevantes. Uma categoria rara com sinais claros pode ser mais simples que duas categorias igualmente frequentes e mal definidas.
Antes de alterar o algoritmo, revise a definição do alvo. “Cliente insatisfeito”, “pedido de cancelamento” e “risco de cancelamento” não são sinônimos. Uma equipe que mistura esses rótulos cria divergências que nenhum balanceamento resolve. Registre critérios de inclusão, exclusão e casos em que a classificação precisa de contexto adicional.
Leia a matriz de confusão antes do placar
Na classificação binária, escolha explicitamente a classe positiva. Ela é o evento que a avaliação acompanha, não necessariamente algo desejável. Para a triagem de mensagens, “urgente” pode ser positivo. Um verdadeiro positivo é um caso urgente identificado; um falso positivo é uma mensagem comum encaminhada como urgente.
| Medida | Pergunta respondida | Limitação prática |
|---|---|---|
| Precisão | Entre os alertas, quantos eram positivos reais? | Pode melhorar quando o sistema emite pouquíssimos alertas |
| Revocação ou recall | Entre os positivos reais, quantos foram encontrados? | Pode crescer junto com muitos alertas incorretos |
| F1 | Como resumir precisão e revocação em uma média harmônica? | Não expressa sozinho custos diferentes dos erros |
| Acurácia balanceada | Qual é a média da revocação entre as classes? | Não informa diretamente o tamanho da fila de revisão |
| Suporte | Quantos exemplos reais existem em cada classe? | É contagem, não uma medida de qualidade |
A documentação de avaliação do scikit-learn apresenta essas métricas e suas definições. Use os nomes acompanhados da interpretação operacional. Um gestor precisa entender se “revocação baixa” significa que reclamações relevantes estão ficando na fila comum, e não apenas ver uma célula destacada em vermelho.
Mostre também denominadores. Acertar todos os dois exemplos de uma classe não oferece a mesma evidência que acertar centenas de casos diversos. Quando não há exemplos reais de uma classe na amostra, sua revocação não pode ser estimada ali. Quando não há previsões positivas, não interprete uma convenção de preenchimento da precisão como desempenho observado.
Em tarefas com várias classes, apresente cada categoria e a média macro, que dá o mesmo peso às classes. A média ponderada acompanha o tamanho de cada grupo e pode ser dominada pelas categorias frequentes. Examine ainda quais classes se confundem entre si, pois duas médias iguais podem representar problemas operacionais diferentes.
Separe treinamento, escolha e teste final
O conjunto de treinamento serve para ajustar o classificador. A validação ajuda a escolher configuração, prompt, regras e limiar. O teste final deve estimar o desempenho depois dessas decisões. Se você escolhe repetidamente a melhor versão olhando o teste, ele vira parte do desenvolvimento e deixa de oferecer uma avaliação independente.
A divisão estratificada busca preservar a proporção de classes nas partes. Isso é útil, mas não resolve dependências entre registros. Mensagens do mesmo atendimento, cadastros duplicados ou textos quase idênticos podem atravessar a divisão e facilitar artificialmente a previsão. Separe por cliente, conversa ou outra unidade relevante quando houver esse vínculo.
Se a aplicação prevê casos futuros, uma separação temporal pode ser mais adequada. Treine no passado e teste em um período posterior, respeitando as informações disponíveis no momento da decisão. Um campo preenchido depois da resolução do chamado não poderia ser usado para prever sua urgência na abertura.
A documentação de validação cruzada explica divisões estratificadas, por grupos e por tempo. Nenhuma delas deve ser escolhida apenas para produzir um número maior. A estrutura precisa representar a maneira como novos exemplos chegam ao sistema.
Para ampliar a análise de uma classe rara, você pode manter uma amostra adicional enriquecida com casos positivos. Identifique-a como diagnóstico dirigido. Não apresente a precisão calculada nessa amostra como estimativa direta da operação se a proporção das classes foi alterada. Preserve também uma avaliação com distribuição compatível com o uso pretendido.
Ajuste o limiar sem sobrecarregar a operação
Um classificador pode produzir um escore antes de escolher o rótulo. O limiar determina a partir de qual valor um caso recebe a classe positiva. Mudar esse ponto altera a decisão sem necessariamente mudar os escores do modelo. A documentação de ajuste de limiar distingue essas duas etapas.
Como método proposto, monte uma planilha de candidatos com limiar, verdadeiros positivos, falsos positivos, falsos negativos e volume de encaminhamentos. Discuta esses resultados com a equipe que atende a fila. Um ponto com maior revocação pode ser inviável se exigir revisão de quase todas as mensagens recebidas.
A curva de precisão e revocação ajuda a observar esse compromisso em diferentes limiares. A referência de precision_recall_curve descreve a construção para classificação binária. Ela precisa de rótulos reais e escores; uma coluna contendo apenas a classe final não oferece o mesmo diagnóstico.
Se a aplicação usa um modelo de linguagem, não trate automaticamente o número que ele escreveu como probabilidade calibrada. “Confiança 0,9” pode ser apenas texto gerado. Verifique empiricamente se faixas de escore correspondem a frequências observadas e mantenha os critérios consistentes entre versões.
Também é possível encaminhar casos ambíguos para pessoas. Nesse desenho, informe cobertura automática, qualidade dentro dos casos automatizados e tamanho da revisão. O guia de abstenção e limiar em classificadores aprofunda essa decisão. Um sistema que se abstém muito pode ter bons acertos nos poucos casos restantes e ainda entregar pouca utilidade.
Exemplo: triagem de suporte em uma loja de Curitiba
Considere uma loja de equipamentos em Curitiba que separa mensagens sobre risco de uso das demais solicitações. O exemplo é ilustrativo e não descreve resultados de uma empresa real. A equipe quer que mensagens sobre superaquecimento recebam atenção rápida, sem transformar qualquer dúvida sobre temperatura em alerta crítico.
Primeiro, o atendimento define a categoria com exemplos positivos e negativos. “O aparelho começou a soltar fumaça” entra na fila especial. “Qual temperatura posso configurar?” não entra apenas por mencionar temperatura. Uma mensagem ambígua vai para revisão. Essa etapa documenta a decisão esperada e evita que cada anotador use sua própria intuição.
Em seguida, a equipe separa atendimentos completos por período, impedindo que mensagens da mesma conversa apareçam em treino e teste. O relatório mostra os erros da classe rara e também quais dúvidas comuns acionam alertas. Uma amostra de falsos negativos é revisada para distinguir falha de classificação de rótulo incorreto.
Na validação, diferentes limiares são comparados ao volume de trabalho disponível. A decisão escolhida recebe uma justificativa explícita: quais perdas são aceitáveis, quais exigem escalonamento e quem responde pela revisão. O teste final fica reservado para avaliar a configuração escolhida, sem nova rodada de ajustes baseada em seu resultado.
Depois da implantação, mudanças no catálogo e na linguagem dos clientes entram no acompanhamento. A loja registra quantidade de alertas e revisa exemplos de mensagens não alertadas, pois olhar somente a fila positiva impede descobrir parte dos erros. Se a dificuldade estiver no entendimento de “não aquece” e “não para de aquecer”, vale consultar a avaliação de negação em português.
Erros comuns
Balancear todo o conjunto antes de dividir. Reamostrar primeiro pode transferir informação entre treinamento e teste. A documentação de práticas do imbalanced-learn alerta para esse vazamento. Aplique o procedimento somente à parte de treinamento em cada divisão e preserve a avaliação independente.
Achar que pesos de classe resolvem qualquer problema. Pesos e reamostragem são alternativas a comparar, não certificados de qualidade. Eles podem mudar a distribuição dos escores e o tipo de erro. Avalie cada configuração no mesmo protocolo, incluindo um modelo simples de referência e a regra de prever sempre a classe mais frequente.
Usar apenas exemplos sintéticos como prova. Casos produzidos artificialmente ajudam a testar condições específicas, mas podem repetir padrões fáceis que não representam mensagens reais. Mantenha identificação de origem, revise rótulos e procure diversidade dentro da classe rara, incluindo expressões curtas, contexto incompleto e pedidos indiretos.
Ignorar a proporção de positivos em produção. Se o evento se torna mais raro, a composição dos alertas pode mudar mesmo com comportamento semelhante do classificador. Acompanhe a frequência observada e investigue alterações na coleta ou no processo de anotação antes de concluir que o modelo melhorou ou piorou.
Perguntas frequentes
Devo deixar todas as classes com o mesmo tamanho?
Não obrigatoriamente. Equalizar contagens é uma técnica possível no treinamento, mas pode remover exemplos úteis ou repetir poucos casos. Compare alternativas com dados independentes e mantenha a distribuição de avaliação identificada.
F1 é sempre a melhor métrica?
Não. Ela resume precisão e revocação, mas não representa sozinha custos, tempo de atendimento ou capacidade da equipe. Escolha a métrica principal a partir da decisão operacional e mostre as medidas complementares.
Uma classe rara precisa de quantos exemplos?
Não há número universal. A evidência depende da variedade dos casos e da precisão necessária na estimativa. Informe o suporte, examine a incerteza e evite conclusões fortes baseadas em poucos exemplos semelhantes.
Posso escolher o limiar no conjunto de teste?
Use validação ou procedimento de seleção separado. Escolher no teste e reportar o mesmo resultado favorece a configuração que se adaptou àquela amostra. Reserve uma avaliação final após concluir a escolha.
O que acompanhar depois de implantar?
Volume por classe, encaminhamentos, amostras de erros e alterações no padrão das entradas. Revise também casos sem alerta. Sem observar negativos, o acompanhamento pode deixar de perceber eventos relevantes que o sistema não encontrou.
