Quando o LLM é a única opção viável (e o modelo de decisão tradicional não serve)?

Fala aí, beleza? Tem decisão que nenhum classificador tradicional dá conta, e insistir nele sai MUITO mais caro do que simplesmente usar um LLM

No comparativo a gente já viu onde o modelo de decisão tradicional ganha com folga

Agora é o lado oposto: o território em que ele não serve

Texto aberto, intenção ambígua, cliente escrevendo em idioma misturado, nenhum histórico rotulado pra treinar…

Se liga que a ideia aqui não é dizer que LLM resolve tudo, beleza? É te dar critérios pra saber quando usar LLM sem culpa e como segurar o risco quando não existe alternativa determinística 🙂

Como reconhecer o território em que o modelo de decisão tradicional não serve?

A própria Anthropic tem um guia de ticket routing que lista os sinais de que vale usar o Claude em vez de ML tradicional

Bora ver esses critérios um por um, pra tu bater com o teu caso

Quando não há histórico rotulado suficiente

ML tradicional exige conjuntos de dados rotulados enormes pra aprender alguma coisa

Segundo o guia da Anthropic, o Claude consegue classificar com algumas dezenas de exemplos rotulados

Então se o teu sistema é novo e não tem histórico, esperar juntar dataset massivo pode significar meses parado

Quando as categorias mudam com frequência

Mudar uma abordagem de ML tradicional que já está em produção é trabalhoso e pede muitos dados novos

Com o Claude, a documentação aponta que ele se adapta a definições de classe novas ou alteradas sem precisar rerrotular dados de treino em larga escala

É como mudar a regra do jogo só explicando a regra nova, em vez de treinar o jogador do zero haha

Quando a entrada é texto aberto e não estruturado

Modelos de ML tradicional costumam ter dificuldade com dados não estruturados e exigem engenharia de features extensa

Que engenharia de features? É o trabalho de transformar o texto em colunas que o modelo entende: contar palavras, marcar presença de termo, extrair tamanho da frase e por aí vai

Idioma variado entra exatamente aqui: aquele cliente que escreve metade em português, metade em inglês, com gíria e abreviação, é texto aberto no estado mais bruto possível

Nesse caso, mede com exemplos reais no idioma do teu público antes de confiar em qualquer coisa, combinado?

Quando a decisão depende de significado e não de palavra-chave

Abordagens tradicionais se apoiam em bag-of-words ou correspondência de padrões

E o que é bag-of-words? É tratar o texto como um saco de palavras soltas, sem ordem e sem contexto

O problema é que "quero cancelar o cancelamento" e "quero cancelar" têm quase as mesmas palavras e significados opostos 😛

O guia da Anthropic destaca que o Claude aplica regras quando as classes são definidas por condições, e não por exemplos

Quando a intenção é ambígua ou cai em caso de borda

Sistemas tradicionais tendem a classificar errado ou jogar a entrada numa categoria genérica tipo "outros"

Segundo a documentação, o Claude interpreta contexto e nuance, e isso pode reduzir tickets mal roteados

Quem já viu a fila "outros" crescer sem parar sabe o tamanho do problema…

Quando alguém precisa entender o porquê da decisão

O Claude pode fornecer explicações legíveis por humanos para as decisões de classificação

Isso muda o jogo quando o time de suporte, o jurídico ou o próprio cliente pergunta "por que foi pra essa fila?"

LLM vs modelo de decisão tradicional: critério a critério

Juntei tudo numa tabela, incluindo os pontos em que o LLM perde (sim, eles existem):

Critério	LLM	Modelo de decisão tradicional
Dados rotulados necessários	Algumas dezenas de exemplos rotulados (guia da Anthropic)	Datasets rotulados massivos
Adaptação a categorias novas	Aceita definições novas ou alteradas sem rerrotular em larga escala	Mudança trabalhosa e que pede muitos dados
Texto não estruturado	Lida com texto complexo e aberto	Dificuldade, exige engenharia de features extensa
Entendimento semântico	Aplica regras definidas por condições	Bag-of-words ou correspondência de padrões
Casos de borda	Interpreta contexto e nuance	Tende a errar ou jogar em categoria genérica
Explicabilidade	Explicação legível por humanos	Depende do modelo, sem explicação em linguagem natural
Latência em tempo real	Lento para inferência em tempo real (Databricks)	Vale avaliar aqui, sozinho ou em híbrido
Custo em volumes gigantes	Lote pode não ser viável ou custo-efetivo em bilhões de linhas (Databricks)	Vale avaliar aqui, sozinho ou em híbrido
Tarefas estabelecidas vs novas	Competitivo nas estabelecidas, pior nas novas; few-shot e fine-tuning melhoram (estudo arXiv 2405.10523)	Supervisionado se sai melhor nas tarefas novas do estudo

Repara na última linha, ela é importante!

O estudo acadêmico mostra que LLM via prompt vai bem em tarefa já conhecida, mas cai em tarefa nova

Ou seja: se o teu problema é inédito, não basta jogar um prompt e torcer, tu precisa de exemplos (few-shot) e de medição

Como reduzir o risco quando não existe alternativa determinística?

Beleza, caiu no território LLM

Agora o trabalho deixa de ser "escolher o modelo" e vira contenção de risco

Bora ver passo a passo:

1. Prenda a saída num schema com structured outputs

A Claude API tem structured outputs com duas funções: JSON outputs (parâmetro output_config.format) e strict tool use (strict: true), garantindo que a resposta siga o schema JSON que você definiu

O schema precisa incluir "additionalProperties": false, olha um exemplo de schema de classificação:

{
  "type": "object",
  "properties": {
    "categoria": {
      "type": "string",
      "enum": ["cobranca", "suporte_tecnico", "cancelamento", "nao_sei"]
    },
    "justificativa": {
      "type": "string"
    }
  },
  "required": ["categoria", "justificativa"],
  "additionalProperties": false
}

O recurso está disponível de forma geral para Claude Opus 4.8, Mythos Preview, Opus 4.7, Opus 4.6, Sonnet 4.6, Sonnet 4.5, Opus 4.5 e Haiku 4.5

O erro comum deste passo: esquecer o additionalProperties: false, que é exigido no schema, e deixar a categoria como texto livre em vez de lista fechada

Repara que eu já coloquei nao_sei como categoria válida, isso conversa com o passo 3 😉

2. Use few-shot com exemplos diversos, incluindo casos de borda

A Anthropic mantém a página Increase output consistency, e ali o recado é claro: exemplos diversos, com casos de borda, ajudam a dar consistência em entradas ambíguas

Coloca no prompt aquele ticket irônico, o que mistura dois assuntos, o que vem em outro idioma

O erro comum deste passo: só colocar exemplos "bonitinhos", que são justamente os que o modelo já acertaria sem ajuda

3. Deixe o modelo dizer "não sei" e crie uma rota humana pra isso

A documentação Reduce hallucinations lista permitir que o Claude diga "não sei" como uma das estratégias básicas

Na prática: toda resposta nao_sei vai pra uma fila de revisão humana, e não pra categoria genérica

O erro comum deste passo: liberar o "não sei" e não ter ninguém olhando essa fila, aí tu só trocou o "outros" de nome haha

4. Ancore em citações diretas quando há documentos longos

Pra documentos com mais de 20K tokens, a mesma página recomenda usar citações diretas pra ancorar a resposta e verificar as respostas com essas citações

Se o modelo afirma algo, ele precisa apontar o trecho de onde tirou

O erro comum deste passo: pedir a citação e nunca conferir se o trecho citado existe mesmo no documento

5. Peça raciocínio passo a passo antes da resposta final e guarde pra auditoria

Na documentação Reduce hallucinations, a Anthropic cita como técnica avançada pedir que o modelo raciocine passo a passo antes da resposta final

Junta isso com o campo justificativa do schema e tu ganha um rastro de cada decisão, que é exatamente o critério de explicabilidade lá de cima

E o "guardar pra auditoria"? É salvar essa justificativa junto com a categoria escolhida e a entrada original, no mesmo registro da decisão

Assim, quando alguém perguntar "por que foi pra essa fila?", tu abre o registro e a resposta já tá lá, sem precisar rodar nada de novo

O erro comum deste passo: gerar a explicação e jogar fora, quando ela é o teu melhor material pra depurar erro depois

6. Comece com algumas dezenas de exemplos rotulados pra medir o acerto antes de escalar

Se o Claude classifica com algumas dezenas de exemplos rotulados, tu também consegue medir com esse tamanho de amostra antes de colocar em produção

Separa um conjunto rotulado à mão, roda, compara e só então aumenta o volume

O erro comum deste passo: confiar no primeiro resultado bonito sem ter um conjunto de referência pra comparar

Na prática: entrada aberta que nenhuma regra fixa resolveria

No vídeo abaixo eu testo um modelo novo dentro do Claude Code, e uma parte dele casa direitinho com esse post

Criei uma funcionalidade de análise de refeição por imagem: a aplicação converte a foto pra base64 e envia pra API do modelo

Aí subi a foto de uma refeição real: arroz, feijão, ovo, linguiça calabresa e tomate

O modelo leu bem a imagem, identificou corretamente os itens e devolveu uma estimativa de 605 calorias

Se liga no ponto: imagem de prato de comida é entrada aberta no último nível, não tem regra fixa nem classificador de palavra-chave que processe isso

Porém, e aqui vem a honestidade: eu não tenho como validar se as 605 calorias estão certas, porque não sou nutricionista 😅

É a estimativa do modelo, não um fato

E isso é exatamente o que o bloco de redução de risco cobre: valor estimado por LLM pede validação, seja por schema, por rota humana ou por conferência com fonte confiável

Outra coisa que notei: o modelo demorou pra começar a gerar código, ficou um tempo "planejando" antes de agir

Isso conversa com o critério de latência da tabela, quando a resposta precisa sair em tempo real, essa demora pesa

No teste dá pra ver o modelo lidando com entrada aberta de verdade, e também onde a saída ainda precisa de um humano conferindo

Veredito: quando escolher o LLM sem culpa (e quando ainda não)?

A regra que eu usaria é simples:

• Entrada aberta, intenção ambígua, categorias que mudam e nenhum histórico rotulado? O LLM é a única opção viável, e o teu trabalho passa a ser conter o risco
• Volume massivo ou latência de tempo real? Aí vale pensar numa abordagem híbrida: o LLM rotula dados ou trata as exceções, e o modelo tradicional roda no volume
• Tarefa totalmente nova? Não confia só no prompt, investe em few-shot e mede

Não vou te prometer número de acerto nem de economia, porque isso depende MUITO do teu caso e de medição real

E se o modelo leve não estiver dando conta das exceções, vale olhar os sinais de que precisa de um modelo maior antes de culpar a abordagem inteira

Próximo passo: teste o critério no seu caso

Com esse post o comparativo fecha o ciclo: de um lado, onde o modelo de decisão tradicional ganha, do outro, onde ele simplesmente não serve

Então bora pra prática?

• Lista todas as decisões automáticas do teu sistema
• Marca quais caem nos critérios do território LLM: sem histórico rotulado, categorias que mudam, texto aberto, significado acima de palavra-chave, ambiguidade, necessidade de explicação
• Pra essas, monta um piloto com schema estruturado, algumas dezenas de exemplos com casos de borda e uma rota de "não sei" com humano olhando

O resto continua com o modelo tradicional, sem drama nenhum 🙂

Faz o teste e depois me conta o que caiu de cada lado

Até o próximo post!

Perguntas frequentes

LLM é sempre mais caro que modelo de decisão tradicional, mesmo em volume baixo?

Não necessariamente, o custo alto aparece em outro cenário: segundo a Databricks, LLM fica caro e lento quando a inferência precisa ser em tempo real ou quando o lote tem bilhões de linhas. Em volume baixo, com poucas dezenas de exemplos rotulados disponíveis, o LLM costuma compensar justamente por não exigir dataset massivo

Dá pra usar LLM sem ter nenhum dado rotulado pra treinar?

O guia da Anthropic mostra que o Claude classifica com algumas dezenas de exemplos rotulados, bem diferente do ML tradicional que pede datasets massivos. Ainda assim, poucos exemplos ajudam bastante na consistência, principalmente se cobrirem os casos de borda

Structured outputs funciona em qualquer modelo da Claude API?

Não, structured outputs está disponível de forma geral pra Opus 4.8, Mythos Preview, Opus 4.7, Opus 4.6, Sonnet 4.6, Sonnet 4.5, Opus 4.5 e Haiku 4.5. O schema precisa incluir additionalProperties: false pra garantir que a resposta siga exatamente o formato definido

Como evitar que o LLM alucine na hora de classificar um caso ambíguo?

A documentação Reduce hallucinations da Anthropic recomenda deixar o Claude responder ‘não sei’ em vez de forçar uma categoria errada. Pra textos longos, acima de 20 mil tokens, vale usar citações diretas pra ancorar a resposta e depois verificar essas citações, e em casos mais complexos pedir raciocínio passo a passo antes da resposta final

Few-shot resolve o problema do LLM em tarefas totalmente novas?

Ajuda bastante, mas não resolve sozinho. O estudo acadêmico (arXiv 2405.10523) mostra que LLM via prompt é competitivo em tarefas já estabelecidas, mas vai pior em tarefas novas, e que few-shot junto com fine-tuning melhora esse desempenho

Quando vale montar um modelo híbrido em vez de escolher só LLM ou só ML tradicional?

Vale quando tu tem volume gigante de dados de um lado e texto ambíguo do outro, misturando os dois mundos. Nesse caso, o modelo tradicional entra pra filtrar o grosso em alta velocidade e o LLM entra só nos casos de borda, nos textos abertos ou onde a explicação da decisão importa