Classificação multilabel com IA: quando uma mensagem tem várias intenções

Classificação multilabel com IA permite atribuir vários rótulos à mesma mensagem. Se um cliente escreve “quero trocar o produto e saber como fica o frete”, o sistema pode reconhecer troca e dúvida sobre entrega simultaneamente. Forçar uma única intenção apaga parte do pedido e pode encaminhar o atendimento para uma fila que não resolve tudo.

Para implantar essa abordagem, defina quais intenções podem coexistir, anote exemplos reais com critérios claros e avalie tanto os rótulos individuais quanto o conjunto completo. A decisão seguinte também precisa estar definida: reconhecer várias intenções não determina, por si só, quem atende primeiro nem autoriza executar ações solicitadas.

Resumo rápido

• Multilabel aceita vários rótulos por mensagem; multiclasse normalmente escolhe apenas um.
• O catálogo precisa distinguir intenção, assunto, sentimento e prioridade.
• Precisão e cobertura por rótulo revelam falhas que uma média pode esconder.
• O conjunto completo de intenções deve orientar o fluxo de atendimento.
• Casos ambíguos e rótulos desconhecidos precisam de revisão humana.

Quando uma única intenção deixa de representar o pedido

Considere “a cobrança veio duplicada, preciso da nota e quero cancelar a renovação”. Há solicitações relacionadas, mas diferentes. Uma equipe pode conferir a cobrança, outra emitir o documento e outra analisar a renovação. Selecionar somente “financeiro” pode ser suficiente para uma triagem inicial, porém não descreve todas as tarefas pendentes.

A documentação do scikit-learn distingue classificação multiclasse, com uma classe por observação, de multilabel, com várias decisões binárias por observação. Nesse segundo formato, cada rótulo indica presença ou ausência de uma característica. Essa distinção ajuda a escolher a representação dos dados antes de comparar algoritmos.

Multilabel também não significa que tudo deva virar intenção. “Produto”, “insatisfeito” e “urgente” podem representar assunto, sentimento e prioridade. Misturá-los em uma lista sem explicação dificulta interpretar erros. Recomenda-se separar esses campos quando cada um tiver uma finalidade operacional própria, mantendo relações explícitas entre eles.

Uma pergunta útil é: duas etiquetas podem ser verdadeiras ao mesmo tempo? Troca e reembolso podem coexistir quando dizem respeito a itens diferentes. Já “pedido entregue” e “pedido não entregue” exigem contexto, identidade do pedido ou uma regra para informação contraditória. O problema deve ser resolvido no desenho da tarefa.

Como criar um catálogo de rótulos que a equipe consiga usar

Comece pelas decisões que o atendimento realmente precisa tomar. Para cada rótulo, escreva uma definição curta, exemplos positivos, exclusões e uma regra para situações próximas. “Cancelamento” pode abranger encerrar uma assinatura, enquanto “cancelamento de entrega” pertence a outro processo. Sem essa distinção, duas pessoas podem produzir respostas diferentes para o mesmo texto.

Registre o trecho que justifica cada intenção. Na frase “já pedi cancelamento ontem, agora só preciso do comprovante”, o histórico menciona cancelamento, mas a solicitação atual é o comprovante. A política de anotação deve dizer se identifica qualquer intenção mencionada ou somente as que permanecem abertas. Essa escolha muda o significado do conjunto de referência.

Inclua mensagens sem intenção prevista, cumprimentos, textos incompletos e solicitações fora do catálogo. Uma lista vazia pode indicar ausência de intenção reconhecida; não deve ser usada silenciosamente como sinônimo de falha técnica. Separe o estado da execução do resultado semântico para que o sistema consiga identificar os dois casos.

Peça que revisores anotem parte das mesmas mensagens independentemente e discutam desacordos. O objetivo dessa etapa é melhorar as regras, não transformar uma pessoa em padrão infalível. Preserve o histórico das alterações do catálogo, porque um resultado avaliado com definições antigas não é diretamente comparável ao de uma taxonomia nova.

Do texto à saída estruturada: opções de implementação

Uma implementação pode aprender uma decisão por rótulo, usar um classificador com suporte nativo a múltiplas etiquetas ou pedir a um modelo de linguagem uma lista estruturada de intenções. A documentação de algoritmos multioutput descreve estratégias como classificadores independentes e cadeias de classificadores. O desenho deve acompanhar a tarefa e os dados disponíveis.

Defina um contrato de saída antes da integração. Um registro pode conter identificador da mensagem, versão do catálogo, lista de intenções, trechos de evidência e indicação de revisão. Valide se os rótulos existem, remova duplicatas e evite depender da ordem dos elementos quando a ordem não tiver significado.

Quando houver pontuações por rótulo, ajuste a regra de decisão em dados de validação. Um valor apresentado como “confiança” por um modelo generativo não deve ser tratado automaticamente como probabilidade calibrada. Se a aplicação precisa dessa interpretação, será necessário verificar a relação entre a pontuação e os acertos observados.

A representação tabular costuma ter uma coluna para cada etiqueta, com indicadores de presença. A ferramenta MultiLabelBinarizer documenta essa conversão no scikit-learn. Fixe a ordem das colunas e a versão do catálogo ao exportar dados; uma inversão silenciosa pode fazer uma integração trocar o significado de previsões corretas.

Como medir qualidade sem esconder as intenções esquecidas

Avalie primeiro cada rótulo. Precisão responde se as marcações feitas estavam corretas; cobertura, também chamada recall, responde quanto das ocorrências reais foi encontrado. F1 combina essas duas medidas. Na documentação de F1, a média micro agrega as contagens, enquanto a macro calcula a média entre rótulos com pesos iguais.

Mostre também o suporte, isto é, quantos exemplos reais de cada intenção aparecem na avaliação. Um rótulo raro pode ter uma medida instável ou nem aparecer no conjunto de teste. O guia sobre classes desbalanceadas em classificadores de IA ajuda a interpretar esse tipo de diferença entre volume e importância operacional.

A correspondência exata exige que o conjunto previsto seja igual ao esperado. Ela é útil quando esquecer qualquer solicitação inviabiliza o fluxo, mas não distingue um erro pequeno de uma resposta inteiramente errada. A documentação de accuracy_score explicita esse comportamento para dados multilabel. Por isso, apresente a medida ao lado dos resultados por intenção.

A perda de Hamming mede a fração de decisões de rótulo incorretas. Já Jaccard compara a interseção com a união dos conjuntos. São perspectivas complementares: uma média confortável não garante que uma intenção crítica esteja preservada. Defina também o tratamento de conjuntos vazios e divisões sem exemplos positivos antes de calcular o relatório.

Separe os resultados por mensagens com uma intenção, várias intenções e combinações não vistas no desenvolvimento. Analise textos curtos, pedidos longos e mensagens com negação. Evite espalhar partes da mesma conversa entre treino e teste. Essa separação reduz a chance de o sistema parecer generalizar quando apenas reconhece conteúdo muito semelhante.

Exemplo: uma loja de utilidades em Campinas

Imagine uma loja de utilidades domésticas em Campinas que recebe pedidos de suporte pelo site. Este é um exemplo ilustrativo, sem resultados de uma empresa real. A equipe define intenções como acompanhar entrega, trocar produto, pedir reembolso e obter documento fiscal. O catálogo também explica quando uma referência histórica deve ser ignorada.

Uma cliente escreve: “a panela chegou amassada, quero trocar, mas também preciso da nota para a garantia”. A referência esperada inclui troca e documento fiscal. O dano explica a troca, mas não precisa virar uma terceira intenção se não existir uma ação específica de registro de avaria no processo escolhido.

O atendimento mantém um único protocolo com tarefas vinculadas. A equipe responsável pela troca recebe o contexto completo; a emissão do documento fica registrada como pendência adicional. Essa organização é uma proposta de fluxo, não uma propriedade automática do classificador. Reconhecer as etiquetas sem criar as tarefas correspondentes deixaria parte do pedido sem resposta.

Para avaliar a solução, os revisores incluem versões como “não quero trocar, só a nota” e “a troca já foi resolvida”. Também verificam uma solicitação com itens diferentes. O relatório registra qual tarefa seria esquecida ou criada indevidamente em cada erro. Isso torna a comparação entre versões compreensível para quem coordena a operação.

Erros comuns

Escolher o rótulo mais provável e descartar o restante. Esse procedimento transforma o problema em escolha única. Se o processo aceita várias solicitações, a saída precisa preservar todas as que foram sustentadas pelo texto, sujeitas às regras de exclusão do catálogo.

Criar uma classe para cada combinação. “Troca mais nota” e “troca mais entrega” podem gerar uma lista difícil de manter. Antes de adotar essa representação, verifique se as combinações são realmente unidades de negócio estáveis ou apenas junções ocasionais de intenções independentes.

Tratar etiqueta como autorização. Reconhecer “reembolso” não comprova identidade, elegibilidade ou valor. A classificação pode encaminhar a análise, mas a execução depende das verificações do processo. Mantenha essa fronteira explícita no sistema e no treinamento dos atendentes.

Ajustar decisões olhando o teste final. Use desenvolvimento para escolher regras, validação para ajustá-las e teste reservado para avaliar a configuração definida. Ao corrigir repetidamente a partir do mesmo teste, a equipe passa a adaptar a solução àquele conjunto específico.

Medir apenas o formato da resposta. Uma lista válida pode conter a intenção errada. Combine validação estrutural com análise semântica e testes de comportamento. Os testes metamórficos para modelos de linguagem ajudam a criar variações que devem preservar ou alterar o conjunto esperado.

Perguntas frequentes

Multilabel e multiclasse são a mesma coisa?

Não. Na classificação multiclasse, uma observação recebe uma classe entre várias opções. Na multilabel, diferentes rótulos podem estar presentes na mesma observação. A escolha depende de como a tarefa foi definida, não apenas do número de etiquetas disponíveis.

Qual métrica deve ser a principal?

Depende da consequência do erro. Se o atendimento exige todas as tarefas corretas, acompanhe o conjunto completo. Se perder uma intenção específica é mais grave, acompanhe sua cobertura separadamente. Documente a prioridade antes de comparar soluções e mostre as medidas complementares.

É preciso ter muitos rótulos?

Não. Comece com distinções que mudam alguma decisão de atendimento. Um catálogo pequeno, bem explicado e revisado pode ser mais útil do que uma lista extensa de conceitos sobrepostos. Acrescente etiquetas quando houver exemplos e uma finalidade operacional clara.

Como lidar com duas intenções incompatíveis?

Revise a unidade de análise. A mensagem pode falar de pedidos diferentes, citar um histórico ou conter contradição real. Preserve as evidências e encaminhe para esclarecimento quando necessário. Não elimine automaticamente um rótulo só porque a combinação parece incomum.

Como saber se funciona no português do meu público?

Teste mensagens representativas do canal, com abreviações, informalidade e vocabulário do negócio. Compare os erros por esses recortes e revise a anotação com pessoas que conheçam o atendimento. O guia de avaliação da qualidade de modelos em português aprofunda esse cuidado.

Fontes e leitura recomendada

• scikit-learn: classificação multiclasse, multilabel e multioutput
• scikit-learn: representação com MultiLabelBinarizer
• scikit-learn: F1 e formas de agregação
• scikit-learn: correspondência exata em multilabel
• scikit-learn: perda de Hamming
• scikit-learn: similaridade de Jaccard
• scikit-learn: prevenção de vazamento de dados