Quantos exemplos rotulados um classificador de texto realmente precisa? Medimos

Por que isso importa agora

“É só usar um LLM para isso” virou a resposta padrão para quase todo problema de classificação de texto — rotear tickets de suporte, etiquetar feedback, ordenar solicitações. A classificação zero-shot com um modelo moderno não exige nenhum dado de treino, o que a torna a escolha fácil no início de um projeto. Mas essa conveniência tem um custo que a maioria dos times nunca mede: classificar com LLM significa uma chamada de rede e uma cobrança por requisição em cada item, para sempre.

Um baseline clássico como TF-IDF com um classificador linear não custa nada para rodar depois de treinado — sem API, sem ida e volta na rede, inferência em frações de milissegundo. A pergunta que vale responder antes de pular direto para o LLM não é “qual método é melhor” no abstrato, mas sim: quantos dados rotulados eu tenho, e quão bom fica a opção gratuita e instantânea com eles?

Para responder, o cientista de dados Himanshu Sharma rodou um experimento pequeno e concreto — rotear tickets de suporte em categorias — e mediu exatamente como a acurácia escala conforme os exemplos rotulados aumentam. Veja o que ele descobriu e como aplicar a decisão no seu projeto.

Prós e contras da abordagem clássica

✅ O que você ganha

• Custo marginal zero: uma vez treinado, o classificador roda localmente sem API e sem cobrança por item.
• Latência ínfima: inferência em ~0,005 ms por ticket, ideal para fluxos em tempo real.
• Independência de fornecedor: nenhuma dependência de API externa ou disponibilidade de serviço.
• Transparência: é possível inspecionar exatamente quais termos (TF-IDF) pesaram na decisão.
• Privacidade: os dados nunca saem do seu ambiente.

⚠️ O que você NÃO ganha

• Compreensão de intenção: bag-of-words não capta tom, urgência nem intenção implícita.
• Desempenho com pouquíssimos dados: com 2 exemplos por categoria, a acurácia ficou em apenas 40%.
• Generalização semântica: não entende reformulações ou sinônimos fora do vocabulário treinado.

O experimento, em detalhes

O cenário foi: classificar tickets de suporte em cinco categorias — billing, technical_bug, feature_request, account_access e general_question. Foram usados 70 tickets (14 por categoria), escritos manualmente como exemplos sintéticos, misturando casos óbvios (“fui cobrado duas vezes pela assinatura”) com ambíguos (“existe desconto para estudante?” — cobrança ou dúvida geral de política?). O conjunto de teste foi fixo: 20 tickets (4 por categoria), nunca usados no treino.

O método foi vetorização TF-IDF (unigramas + bigramas) alimentando uma regressão logística, treinada em três volumes de dados — 2, 5 e 10 exemplos por categoria — para isolar a única variável que muda ao longo da vida de um projeto: quanto dado rotulado você acumulou.

vec = TfidfVectorizer(ngram_range=(1, 2), min_df=1)
X_train = vec.fit_transform(train_texts)
X_test = vec.transform(test_texts)
clf = LogisticRegression(max_iter=1000)
clf.fit(X_train, train_labels)
preds = clf.predict(X_test)

O ngram_range=(1, 2) faz o vetorizador capturar palavras isoladas e pares de palavras, o que dá contexto local à classificação. O max_iter=1000 garante convergência da regressão logística em conjuntos pequenos.

Os resultados

Três coisas se destacam. Primeiro, a acurácia sobe de forma acentuada no início e depois achata: ir de 2 para 5 exemplos por categoria rendeu +15 pontos — o movimento de maior alavancagem de todo o experimento — enquanto ir de 5 para 10 rendeu apenas +5. Segundo, a inferência é praticamente instantânea e gratuita. Terceiro, mesmo com 60% de acurácia, isso não é território de “publicar e esquecer”: um roteador que erra 2 em cada 5 tickets é um problema real de produto.

Onde os casos ambíguos realmente quebraram

A acurácia agregada esconde o diagnóstico mais útil: quais tickets o classificador errou e se mais dados corrigem o erro. Ao registrar cada erro em cada tamanho de treino, surgiram dois padrões de falha distintos.

Alguns erros são pura escassez de dados — mais rótulos resolvem. Com 2 exemplos por categoria, tickets como “pode redefinir minha senha? o e-mail de redefinição nunca chega” (account_access, previsto como billing) estavam errados. Com 10 exemplos, já eram classificados corretamente. O modelo simplesmente não tinha visto vocabulário suficiente de account_access ainda.

Outros erros são estruturais — nunca desaparecem. “Existe desconto para estudante no plano pro?” era billing, mas foi previsto como technical_bug e depois general_question; o modelo nunca acertou. “O app móvel me desconecta a cada poucos minutos” era technical_bug, mas foi previsto como feature_request em todos os tamanhos de treino. A distinção vive no tom e na urgência, não nas palavras — e um modelo bag-of-words não tem acesso a isso.

Essa é a descoberta real, não só o número de acurácia: mais dados corrigem erros de escassez, mas não fazem nada por erros enraizados em intenção que o vetorizador literalmente não enxerga. Os dois tipos de falha pedem correções diferentes — um pede mais rótulos, o outro pede uma abordagem diferente para o texto (ou uma etapa de revisão humana, ou um modelo que raciocine sobre intenção).

Onde essa abordagem fica devendo

• Dados sintéticos: os 70 tickets foram escritos à mão; tickets reais têm erros de digitação, frases irregulares e volumes desbalanceados que tendem a prejudicar mais o bag-of-words do que um LLM.
• Divisão única: os números vêm de uma única divisão treino/teste, que mudaria com um embaralhamento — especialmente com 2 exemplos por categoria.
• Conjunto de teste pequeno: 20 exemplos significam que uma previsão invertida move a acurácia em 5 pontos. Leia a tabela como o formato da curva, não como um benchmark preciso.

O framework de decisão

A escolha certa não é “TF-IDF versus LLM” como decisão arquitetural fixa — é uma função de três perguntas que qualquer time consegue responder:

1. Quantos dados rotulados você tem agora? Perto de zero, um modelo clássico ainda não é utilizável — 2 exemplos por categoria renderam só 40%. Algumas dezenas por categoria mudam o cenário de forma considerável.
2. Qual é o seu volume e o que isso faz com a linha de custo? O custo de um modelo clássico é fixo após o treino; qualquer cobrança por requisição escala linearmente com cada item processado. Vale modelar isso explicitamente no seu volume real.
3. Qual é o seu orçamento de latência? Inferência local em frações de milissegundo versus uma ida e volta na rede é uma restrição real para qualquer coisa voltada ao usuário ou em tempo real.

Um padrão que vale considerar: use classificação zero-shot para gerar rótulos quando você não tem nenhum, e depois treine um modelo clássico sobre esses rótulos quando tiver acumulado o suficiente. Você tem um sistema funcionando no primeiro dia, sem problema de partida a frio, e custo marginal quase zero quando tiver dados.

Erros comuns e como corrigi-los

• ❌ Acurácia de 99% que não significa nada → causa: classes muito desbalanceadas fazem o modelo acertar sempre a classe majoritária. Solução: olhe Macro-F1 e a matriz de confusão, não só a acurácia.
• ❌ Treinar e testar com os mesmos exemplos → causa: vazamento de dados infla a acurácia. Solução: separe um conjunto de teste fixo antes de qualquer treino.
• ❌ Esperar que mais dados corrijam erros de intenção → causa: bag-of-words não capta tom nem urgência. Solução: troque a representação do texto ou adicione revisão humana.
• ❌ Comparar métodos em bases diferentes → causa: cada configuração deve ser julgada nos mesmos exemplos não vistos. Solução: congele o conjunto de teste.
• ❌ Ignorar o custo por requisição do LLM → causa: a conveniência esconde o custo recorrente. Solução: modele o custo no seu volume real antes de decidir.

Perguntas frequentes

Vale a pena trocar um LLM por TF-IDF em produção? Depende do volume e dos dados. Com dezenas de exemplos rotulados e alto volume, sim — o custo marginal zero compensa. Com quase nenhum dado rotulado, o LLM zero-shot ainda é a saída mais rápida.

Quanto dado rotulado eu preciso? O experimento mostrou que 5 a 10 exemplos por categoria já rendem um salto real de acurácia. A curva achata depois disso, então o primeiro punhado de exemplos importa mais.

TF-IDF entende o significado do texto? Não. Ele conta frequência de termos. Para intenção, tom ou urgência, é preciso outro tipo de modelo ou uma etapa de revisão.

Posso combinar os dois? Sim — use o LLM zero-shot para gerar rótulos iniciais e treine um modelo clássico sobre eles quando tiver volume suficiente.

O experimento usa dados reais? Não, são exemplos sintéticos escritos à mão. Isso é uma limitação: tickets reais têm ruído e desbalanceamento que afetam mais o bag-of-words.

O que isso significa para o futuro

Conforme os custos de API por requisição entram na conta de qualquer produto com volume, a pergunta “quantos dados rotulados eu tenho hoje, e quanto minha próxima leva de rótulos realmente compra?” tende a substituir o debate abstrato sobre qual método é mais inteligente. O ponto não é que TF-IDF “vence” ou “perde” — é que a decisão de arquitetura deveria ser dirigida por dados que você já tem, e não pela resposta padrão de todo mundo.