A pergunta já não é se os LLMs são melhores que os modelos tradicionais de NLP. A pergunta útil é: qual peça do meu pipeline precisa de cada abordagem? Esta lista de verificação destina-se a equipas que já têm um produto em produção e hesitam entre substituir o seu stack clássico (spaCy, scikit-learn, regex, CRF, embeddings estáticos) por um modelo generativo, ou manter ambos.
Cada ponto é uma decisão verificável, não uma opinião. Se assinalar menos de metade, provavelmente ainda não precisa de migrar.
1. Defina a tarefa antes de escolher a tecnologia
1.1 É extração fechada ou compreensão aberta?
Se precisa de extrair campos com um esquema fixo (datas, montantes, NIF, entidades de um domínio concreto), um modelo supervisionado tradicional com etiquetagem própria costuma ganhar em precisão e custo. Os LLMs brilham quando o esquema muda todas as semanas ou quando a saída requer raciocínio sobre o texto.
1.2 Precisa de reprodutibilidade exata?
Um classificador de regressão logística sobre TF-IDF devolve a mesma previsão com a mesma entrada. Um LLM com temperatura maior que zero, não. Se o seu produto é auditoria, conformidade normativa ou scoring, a determinação exata pesa mais do que a fluidez.
1.3 Existe uma métrica de referência?
Antes de mudar nada, fixe uma linha de base: F1 por classe num conjunto de teste congelado. Segundo documentação de fornecedores de NLP clássico, em tarefas de classificação de texto com categorias bem definidas e milhares de exemplos etiquetados, os modelos lineares costumam alcançar valores próximos dos de modelos grandes, com uma fração do custo. Se não tem essa linha de base, não pode justificar a migração.
2. Verifique o custo real, não o da demo
2.1 Latência por pedido
Um modelo clássico em CPU responde em milissegundos. Um LLM na nuvem acrescenta latência de rede e de geração. Para um motor de busca interno ou um autocompletar, essa diferença é visível para o utilizador. Isto não funciona para X: não use um LLM no caminho crítico de uma interface que exige resposta abaixo de 200 ms, a menos que tenha cache agressiva ou um modelo local pequeno.
2.2 Custo por volume
Faça a conta com o seu tráfego real: tokens de entrada médios × pedidos × preço do modelo. Um classificador tradicional treinado uma vez custa praticamente o mesmo a 10.000 que a 10 milhões de inferências. Muitas equipas descobrem em produção que 80% das suas chamadas são a tarefas triviais que um modelo clássico resolvia igual.
2.3 Custo de manutenção da etiquetagem
O modelo clássico exige anotar dados. O LLM exige redigir prompts, avaliar sistematicamente e vigiar mudanças de versão do fornecedor. Ambos têm custo humano; escolha o que a sua equipa consegue sustentar.
3. Verifique a qualidade com dados próprios
3.1 Teste no domínio, não em benchmarks públicos
Um LLM pode pontuar alto num benchmark geral e falhar no seu jargão. Caso concreto que aparece com frequência em equipas de suporte: um modelo clássico treinado com tickets históricos identificava corretamente a categoria de reclamação de faturação porque aprendeu as abreviaturas internas da empresa; o LLM geral, sem exemplos dessas abreviaturas no prompt, confundia-as com nomes de produto. A solução não foi descartar o LLM, mas sim acrescentar um passo de normalização prévia com o modelo clássico.
3.2 Avalie com estratificação por dificuldade
Separe o seu teste em casos fáceis, ambíguos e adversariais. É habitual que o LLM ganhe nos ambíguos e empate ou perca nos fáceis. Se a sua distribuição real é maioritariamente fácil, a média engana.
3.3 Meça a alucinação, não apenas o acerto
Na extração, um campo inventado é pior do que um campo vazio. Os modelos clássicos falham devolvendo a etiqueta mais provável; os LLMs podem fabricar o valor. Defina uma métrica de abstenção correta.
4. Reveja requisitos de privacidade e implementação
4.1 Os dados podem sair da sua infraestrutura?
Se o texto contém dados pessoais, contratos ou informação médica, o envio para uma API externa exige revisão legal. Um modelo clássico local elimina esse vetor por completo. Os LLMs autoalojados existem, mas mudam o perfil de custo: precisa de GPU e de alguém que a mantenha.
4.2 Precisa de funcionar sem ligação?
Dispositivos em campo, quiosques, ambientes industriais: o modelo clássico embebido continua a ser a opção pragmática. Um LLM pequeno quantizado pode correr localmente, mas a sua qualidade em tarefas complexas cai e deve ser validada tarefa a tarefa.
5. Verifique se o problema é de dados, não de modelo
5.1 Volume de etiquetas disponíveis
Com menos de umas centenas de exemplos por classe, o modelo clássico fica aquém e o LLM com few-shot parte com vantagem. Com dezenas de milhares, a vantagem estreita-se e o custo por inferência torna-se o fator decisivo.
5.2 Deriva do domínio
Se o seu vocabulário muda rapidamente (novos produtos, novas gírias), o modelo clássico degrada-se e é preciso retreinar. O LLM absorve melhor a mudança sem retreino, mas introduz variabilidade. Um padrão robusto é usar o LLM para gerar etiquetas novas e o modelo clássico para servir à escala.
5.3 Idiomas e variedades
Os modelos clássicos multilingues existem, mas o seu desempenho em variedades dialetais ou em texto informal é irregular. Os LLMs costumam generalizar melhor em idiomas de baixos recursos. Ainda assim, verifique com amostras reais: não assuma que um modelo grande entende a sua variante local melhor do que um modelo treinado com os seus dados.
6. Decida a arquitetura híbrida antes da substituição
6.1 Padrão de duas etapas
Modelo clássico para filtrar e classificar o volume alto; LLM apenas para os casos que superam um limiar de confiança. Reduz o custo e mantém a qualidade onde importa.
6.2 Padrão de geração de dados
Use o LLM para etiquetar um lote inicial, reveja uma amostra humana e treine um modelo clássico com essas etiquetas. É uma forma documentada na prática de reduzir o custo de anotação sem renunciar a um servidor determinístico.
6.3 Padrão de recurso
Se o LLM falhar ou devolver uma saída que não valida o esquema, recorre ao modelo clássico. Nunca deixe que uma falha da API externa quebre o seu fluxo completo.
7. Lista de verificação final antes de tocar em produção
- ☐ Tenho uma linha de base medida com o meu próprio teste, não com benchmarks públicos.
- ☐ Calculei custo e latência com o meu volume real, não com uma demo.
- ☐ Sei que tarefas requerem determinismo e quais toleram variabilidade.
- ☐ Revejo privacidade e localização dos dados com quem de direito.
- ☐ Tenho uma métrica de abstenção, não apenas de acerto.
- ☐ Existe um plano de recurso caso o fornecedor mude o modelo.
- ☐ Testei a abordagem híbrida antes de substituir por completo.
- ☐ Documentei o que não sei: limites do modelo no meu domínio e casos sem cobertura.
Nenhum destes pontos garante resultados. A evidência do setor aponta para que as equipas que mantêm ambas as abordagens obtêm melhor relação qualidade-custo do que as que apostam tudo numa única tecnologia, mas cada domínio tem as suas exceções e convém medi-las.