A pergunta já não é se convém usar inteligência artificial, mas que tipo de modelo se adequa a cada problema. Nos últimos dois anos, vi equipes técnicas gastarem orçamento em APIs de modelos generativos para tarefas nas quais um classificador treinado sob medida teria custado uma fração e teria sido mais previsível. E também o contrário: tentar resolver com regras e árvores de decisão um problema de extração de informação em linguagem natural que um LLM resolve em uma tarde de trabalho. Esta comparação foi pensada para quem precisa decidir entre as duas opções com orçamento e prazos reais.
O que realmente separa um LLM de um modelo tradicional
Um modelo tradicional (regressão logística, random forest, gradient boosting, SVM, redes convolucionais específicas) é treinado para uma tarefa concreta com um conjunto de dados rotulado e produz saídas delimitadas: uma classe, um número, uma probabilidade. Um LLM é um modelo de linguagem pré-treinado sobre corpus massivos que prevê o próximo token e, a partir daí, generaliza para tarefas para as quais não foi ajustado explicitamente.
A diferença prática mais importante não é a arquitetura, mas o contrato de uso. Com um modelo clássico, você sabe exatamente que entrada ele espera e que faixa de saída produz. Com um LLM, a entrada é texto livre e a saída é texto livre, o que transfere o esforço de engenharia do treinamento para o design de prompts, a validação de saídas e a avaliação contínua.
Custo: não é apenas o preço por token
O custo de um LLM é medido por token de entrada e saída, e escala com o uso. O de um modelo tradicional concentra-se na fase de rotulagem e treinamento, e depois a inferência é barata e local. Em um caso real de classificação de tickets de suporte em cinco categorias, com dezenas de milhares de tickets por mês, a inferência de um modelo pequeno ajustado sai a centavos por cada mil requisições em infraestrutura própria, enquanto chamar um LLM grande para cada ticket multiplica o gasto e acrescenta latência de rede. Se o volume é alto e a tarefa é estável, o modelo clássico costuma ganhar em custo total.
Dados: o gargalo muda de lugar
Um modelo tradicional exige dados rotulados de qualidade. Se você não os tem, o projeto fica bloqueado. Um LLM permite começar sem rótulos, mas você precisa de exemplos de avaliação para saber se ele acerta. Na prática, muitas equipes começam com um LLM para prototipar, geram rótulos com ele e depois treinam um modelo clássico com esses rótulos revisados por humanos. Essa estratégia de destilação funciona bem quando o domínio é delimitado; falha quando as classes são ambíguas ou a linguagem é muito variável.
Cenários em que cada opção ganha
Quando um modelo tradicional é a escolha correta
- Dados tabulares estruturados: scoring de risco, previsão de churn, detecção de fraude com variáveis numéricas e categóricas. Os modelos de gradient boosting continuam sendo referência nesses casos, segundo a documentação das principais bibliotecas do setor.
- Requisitos rigorosos de latência: se você precisa de respostas em milissegundos sem depender de uma API externa, um modelo pequeno local é mais confiável.
- Auditabilidade regulatória: em setores com obrigação de explicar decisões, um modelo com importância de variáveis documentada é mais fácil de defender do que a saída de um LLM.
- Tarefas repetitivas e bem definidas: classificação de imagens de produto, detecção de anomalias em séries temporais, rotulagem de sentimento com um domínio muito específico.
Quando o LLM traz algo que o modelo clássico não consegue
- Extração de informação de texto não estruturado: converter e-mails, contratos ou relatórios em campos estruturados sem definir um esquema rígido de antemão.
- Tarefas com instruções variáveis: resumir com um tom diferente, reformatar saídas ou adaptar respostas a um contexto que varia sem retreinar.
- Geração e transformação de conteúdo: redação assistida, tradução com nuances, reescrita.
- Prototipagem rápida: validar se um caso de uso tem valor antes de investir em dados rotulados.
O erro que vejo se repetir: tratar o LLM como um banco de dados
Um padrão que aparece repetidamente é pedir ao modelo que memorize informações de negócio (preços, políticas, catálogo) e confiar que ele as devolverá corretamente. Ele não faz isso de forma confiável: alucina dados plausíveis, mas falsos. A solução não é trocar de modelo, mas adicionar recuperação de informação (RAG) com uma fonte de verdade consultável. E, mesmo assim, a validação da resposta final continua sendo necessária para dados sensíveis.
Outro erro frequente: avaliar um LLM com dez exemplos manuais e considerá-lo bom. Sem um conjunto de avaliação representativo e repetível, não há como detectar regressões quando você muda a versão do modelo ou modifica o prompt. Segundo a documentação dos principais fornecedores, as versões são atualizadas com frequência e o comportamento pode variar sem aviso claro.
Comparação prática por critérios de decisão
| Critério | Modelo tradicional | LLM |
|---|---|---|
| Dados necessários para começar | Rotulados e representativos | Nenhum para prototipar; exemplos para avaliar |
| Custo de inferência | Baixo e previsível | Variável conforme tokens e fornecedor |
| Latência | Muito baixa em local | Depende da rede e do tamanho do modelo |
| Explicabilidade | Alta com as técnicas adequadas | Limitada; a cadeia de raciocínio nem sempre é confiável |
| Adaptação a tarefas novas | Exige retreinar | Alterar instruções costuma bastar |
| Robustez diante de entradas incomuns | Degrada de forma previsível | Pode inventar ou divagar |
Arquiteturas híbridas: o que costuma funcionar de verdade
Na maioria dos projetos maduros, a resposta não é escolher um dos dois, mas combiná-los. Um padrão habitual: um modelo clássico filtra e classifica o grosso do volume (por exemplo, separar consultas urgentes de informativas), e apenas os casos ambíguos ou complexos passam para um LLM que redige ou extrai informação. Isso reduz custo, mantém a latência controlada e reserva a capacidade do modelo generativo para onde ele agrega valor.
Outro padrão: usar o LLM para gerar dados de treinamento sintéticos ou para rotular em escala, e depois treinar um modelo clássico com revisão humana. Funciona bem em domínios fechados; convém revisar uma amostra para detectar vieses herdados da rotulagem automática.
Limitações que convém assumir antes de começar
Nenhuma das duas opções resolve problemas de dados mal definidos. Se os rótulos são inconsistentes, o modelo clássico aprende a inconsistência e o LLM a reproduz com mais segurança. Também não há garantia de precisão de cem por cento em nenhum dos dois casos: qualquer sistema em produção precisa de monitoramento, limiares de confiança e um caminho de escalonamento para revisão humana.
Os LLMs também têm limites de contexto, custo crescente com a extensão da entrada e dependência de fornecedores externos se não forem implantados localmente. Os modelos tradicionais, por sua vez, não generalizam fora da distribuição com a qual foram treinados: uma mudança no formato dos dados de entrada pode degradar o desempenho sem que nenhum alarme dispare.
Como decidir na prática
Uma sequência que costumo recomendar: primeiro definir a métrica de sucesso e o volume esperado; depois verificar se existe uma fonte de dados rotulada ou se ela pode ser construída; se a tarefa é de linguagem natural e não há dados, prototipar com um LLM para validar o valor; se o volume é alto e a tarefa é estável, avaliar treinar um modelo clássico com os dados gerados; e, em todos os casos, montar um conjunto de avaliação antes de passar para produção. A decisão entre LLM e modelo tradicional não é ideológica: depende do volume, da latência, da explicabilidade exigida e da disponibilidade de dados. Mudar de opinião quando os números justificam faz parte do trabalho.