LLM como classificador: quando trocar ML tradicional

LLM como classificador é uma das primeiras coisas que um time testa quando descobre que dá para usar um modelo de linguagem no lugar de um modelo de ML tradicional. Faz sentido: você tem um LLM na stack, tem um problema de classificação, e a pergunta natural é "por que treinar um modelo separado se já pago por um?".

A resposta, na minha experiência, é: às vezes não precisa mesmo. E às vezes você vai se arrepender de não ter treinado o modelo separado desde o início.

O que é classificar com um LLM, na prática

Classificação com ML tradicional significa treinar um modelo que aprende a mapear um input para uma categoria a partir de exemplos rotulados. Você precisa de dados, de um pipeline de treino, de validação, de deploy separado.

Classificar com LLM significa descrever as categorias em linguagem natural e pedir para o modelo decidir. Sem treino, sem dados rotulados, sem pipeline adicional.

A diferença operacional é enorme. O que não significa que o LLM é a escolha certa por padrão.

Quando o LLM como classificador ganha de forma clara

Três cenários onde o LLM entrega mais valor do que um modelo treinado:

Categorias mudam com frequência. Se as classes que você precisa reconhecer mudam a cada sprint, treinar e re-treinar um modelo tradicional é overhead real. Com LLM, você ajusta a descrição das categorias e pronto.

Você não tem dados rotulados suficientes. Um modelo de classificação tradicional precisa de exemplos para cada classe. Se você tem menos de algumas centenas por categoria, a performance vai ser ruim. O LLM chega sem essa exigência.

O problema é ambíguo por natureza. Classificar sentimento de texto livre, categorizar tickets de suporte com nuances subjetivas, identificar intenção em perguntas abertas: esses casos pedem raciocínio sobre linguagem, não só pattern matching. A página oficial de zero-shot classification da Hugging Face documenta bem essa distinção: LLMs de geração atual vão além de modelos treinados em zero-shot em capacidade de raciocínio sobre categorias novas.

Quando o modelo tradicional ainda vence

Olha, tem cenários onde eu não usaria LLM para classificação nem que me pagassem.

Volume alto com latência baixa. Classificar mil requests por segundo com SLA de 50ms não é cenário para um LLM. Um modelo leve de ML, bem ajustado, vai ser 10x mais rápido e 20x mais barato.

Categorias bem definidas e estáveis com dados suficientes. Se você tem 50 mil exemplos rotulados e as categorias não mudam, um modelo fine-tuned bate LLM genérico em performance e custo. Sem discussão.

Compliance exige auditabilidade. LLM como caixa preta é difícil de auditar em contextos regulatórios. Um modelo treinado internamente com características explícitas é mais defensável.

Como medir se o LLM classificador está funcionando

Essa é a parte que a maioria pula, e é exatamente onde os projetos quebram.

Você precisa de um conjunto de avaliação antes de colocar qualquer coisa em produção. Não depois. Um conjunto de pelo menos 100 a 200 exemplos rotulados manualmente, distribuídos entre todas as classes que você quer reconhecer.

As métricas básicas:

• Accuracy geral para ter um número de referência
• Precision e recall por classe, porque accuracy geral esconde péssima performance em classes raras
• Erros de classificação por par de classes: o modelo confunde quais categorias com quais? Isso diz se o problema está na descrição ou é inerente ao LLM

Spoiler: se o modelo erra muito entre duas categorias específicas, o problema quase sempre está na forma como você as descreveu. Antes de concluir que "o LLM não consegue fazer isso", mude a descrição e meça de novo.

Para quem vai colocar isso em produção, o post sobre avaliação de LLM em produção cobre como monitorar qualidade depois do deploy, não só antes.

O custo é o elefante na sala

Usar LLM para classificar é caro comparado com ML tradicional, especialmente em volume. O post sobre custo de LLMs em produção cobre como estimar isso, mas a lógica prática para classificação é direta: multiplique o número de requests diários pelo custo médio por request. Se o número couber no seu orçamento, tudo bem.

Se não couber, a opção é usar um modelo menor. Um modelo como GPT-4o para classificar "isso é spam ou não" é desperdício claro. Um modelo pequeno como Claude Haiku ou GPT-4o-mini resolve isso a uma fração do custo com qualidade comparável para tarefas simples.

Outra saída é roteamento de LLMs: você manda tarefas de classificação para modelos mais baratos e reserva o modelo maior para raciocínio complexo.

Como estruturar a tarefa de classificação para o LLM

A qualidade do resultado depende muito de como você descreve o problema. Algumas práticas que funcionam:

Seja específico nas categorias. "Positivo, negativo, neutro" é vago. "Positivo: o cliente expressa satisfação com o produto ou elogia o atendimento. Negativo: o cliente reclama de algo específico ou demonstra frustração." Isso é utilizável.

Use exemplos de borda. Se tem casos ambíguos que aparecem com frequência, inclua na descrição como você quer que o modelo trate. Sem isso, o modelo inventa uma lógica própria.

Peça o raciocínio antes da resposta final. Pedir ao modelo que explique por que está classificando antes de dar a categoria reduz erros em casos ambíguos. Aumenta o uso de tokens, mas melhora consistência.

Peça indicação de confiança. Outputs de baixa confiança podem ser sinalizados para revisão humana em vez de ir direto para produção. Isso é especialmente importante em decisões que têm consequências reais.

FAQ

LLM como classificador precisa de fine-tuning para funcionar bem?

Não necessariamente. Em muitos casos, o modelo base com uma boa descrição das categorias já entrega resultado aceitável. Fine-tuning ajuda quando você tem muitos dados e precisa de performance máxima com custo menor por request. O post sobre fine-tuning vs prompt engineering cobre quando faz sentido ir por esse caminho.

É possível usar LLM como classificador sem escrever código?

Sim. Ferramentas de automação que conectam a APIs de LLM permitem construir um fluxo de classificação sem programação. O que você precisa definir é a lógica das categorias e o que fazer com o resultado de cada classe.

Como decidir entre LLM e um modelo treinado?

As perguntas certas: você tem dados rotulados suficientes? As categorias vão mudar? Qual é o volume de requests e qual custo é aceitável? Sem dados e com categorias fluidas, LLM. Com dados, volume alto e custo que precisa ser mínimo, modelo treinado.

O LLM pode classificar e extrair informações na mesma chamada?

Pode, e às vezes faz sentido fazer os dois juntos, especialmente quando o contexto necessário é o mesmo. Isso reduz o número de chamadas, o que impacta custo e latência diretamente.

LLM como classificador é uma ferramenta, não uma resposta padrão

A pergunta certa não é "posso usar LLM para classificar?" (a resposta técnica é quase sempre sim). A pergunta é: dado meu volume, meu custo tolerável, a estabilidade das minhas categorias e a disponibilidade de dados rotulados, o LLM é a escolha que vai funcionar em produção daqui a seis meses?

Se você não consegue responder isso antes de começar, comece pelo conjunto de avaliação. Ele vai fazer a pergunta por você.

Para continuar:

• Veja como avaliar LLM em produção para monitorar o classificador depois do deploy
• Entenda como controlar o custo de LLMs em produção antes de escalar o volume de classificações