NLP vs LLM vs RAG: o formato da tarefa decide a rota antes do preço

Por que isso importa agora

A maioria dos pedidos de “adicionar IA” a um fluxo de documentos nunca precisou de um modelo generativo. Tire a linguagem de negócio e o pedido se resume, quase sempre, a um de cinco formatos de tarefa — e quatro deles terminam em componentes determinísticos que custam frações de centavo por página e, estruturalmente, não podem alucinar, porque nada neles gera texto. Essa é a resposta honesta para o debate NLP vs LLM vs RAG: o formato do pedido decide o ramo antes de você abrir qualquer página de preços.

Em um cenário de orçamento apertado, a diferença entre um pipeline que custa centavos por milhar de documentos e outro que custa dólares por centena vira um item de linha que alguém vai questionar. E, em fluxos de documentos, uma resposta silenciosamente errada é pior que uma exceção, porque ela flui rio abaixo parecendo correta.

Prós e contras de rotear pelo formato da tarefa

• ✅ Custo marginal mínimo: tarefas de classificar, casar e limpar rodam a frações de centavo, contra centavos por chamada de um modelo de fronteira.
• ✅ Falhas que se anunciam: componentes determinísticos falham alto e local (zero-match, exceção, stack trace) — fáceis de detectar e testar.
• ✅ Comportamento testável: regras e classificadores podem ser cobertos por testes unitários, o que nenhuma técnica de prompting oferece.
• ✅ Acurácia pode melhorar com menos gasto: o LLM só vê os casos realmente ambíguos, onde o julgamento dele é o que você está pagando.
• ✅ Custo decrescente com o tempo: o loop de promoção transforma correções recorrentes do LLM em regras e aliases permanentes.

• ⚠️ Exige dados rotulados no início: o classificador assume que já existe um conjunto de treino; o custo de rotular alguns milhares de documentos pode dominar no cold start.
• ⚠️ RAG é uma assinatura de pipeline: alguém precisa cuidar de ingestão, chunking e embeddings a cada atualização do corpus — para sempre.
• ⚠️ Ramos silenciosos exigem supervisão contínua: RAG e LLM falham quietos; você paga monitoramento (eval sets, auditorias) para sempre.

Os cinco formatos de tarefa

Dois desses formatos merecem atenção, porque são os que as equipes mais superengenheiram. Casar texto livre com uma lista de referência não é um problema de compreensão semântica: “Acme Mfg Corp” contra “Acme Manufacturing Corporation” é um cálculo de distância, e bibliotecas resolvem milhões dessas comparações em um laptop. Ler uma tabela não é compreensão de leitura: é geometria, e parsers com consciência de layout resolvem detectando fronteiras de células. Nenhum dos dois recompensa um modelo generativo — e ambos punem um em volume.

O ramo NLP clássico e sua matemática de custo

As técnicas clássicas são velhas e pouco glamourosas por um motivo: elas já resolveram esses problemas. Um exemplo com a aritmética exposta: casar 1.000 faturas por dia contra uma lista mestre de 5.000 fornecedores são 5 milhões de comparações, que o fuzzy matching resolvido em CPU resolve em segundos em hardware comum. O custo de computação por documento arredonda para zero; o custo real é escrever a lista de referência e ajustar limiares.

Para classificação em produção, um modelo linear sobre features TF-IDF — ou um pipeline spaCy pequeno — permanece o padrão. Benchmarks públicos colocam esses modelos na faixa de milissegundos por documento em CPU, o que precifica a classificação de um milhão de documentos perto do custo de rodar uma VM pequena por um dia. A ressalva que a matemática esconde: isso assume que já existem dados rotulados. No cold start, o orçamento de rotulagem pode dominar todo o resto — e é aí que entra o roteador híbrido, descrito mais adiante.

O ramo RAG, quando a recuperação é o trabalho

Adotar RAG significa assinar um pipeline de dados, não chamar uma feature. Alguém precisa cuidar da ingestão, do chunking e dos embeddings a cada atualização do corpus; alguém precisa manter o índice fresco quando as fontes mudam diariamente; e cada query ainda paga um imposto de geração por cima. A pergunta real é se a organização vai sustentar esse pipeline indefinidamente — porque uma stack de RAG negligenciada não degrada com elegância: continua respondendo fluentemente a partir do que o índice por acaso contém.

Três condições concretas justificam o RAG: o corpus é grande, as perguntas são de vocabulário aberto (não dá para enumerar respostas com antecedência) e o corpus muda. Responder perguntas sobre um arquivo de contratos, um wiki interno ou histórico de suporte atende aos três. Os sinais de “não-RAG” merecem igual peso: um conjunto fixo de respostas é território de matcher ou classificador; um único documento é uma chamada direta de LLM (recuperar sobre um documento só é um LLM com etapas extras); e um corpus pequeno e estático que cabe em uma janela de contexto moderna favorece o contexto longo — cole o corpus e pule o pipeline.

O ramo LLM, para o que serve uma chamada de fronteira

Uma chamada de fronteira é para pedidos que genuinamente produzem texto novo dependente de síntese ou julgamento: redigir um memorando, avaliar se uma cláusula é arriscada, extrair campos de texto livre muito variado ou tratar o documento estranho que a camada determinística recusou.

O custo é uma multiplicação com insumos públicos. Tome um contrato de dez páginas, cerca de 5.000 tokens de entrada e uma resposta estruturada de 400 tokens. A preços de lista intermediários — alguns dólares por milhão de tokens de entrada e cerca de cinco vezes isso para saída — a chamada custa perto de dois centavos de dólar. Dois centavos parecem inofensivos até multiplicar: 100.000 documentos por mês caem na casa dos milhares de dólares, contra uma camada de fuzzy matching cuja computação arredonda para zero. O gap entre a camada de matcher praticamente gratuita e uma chamada de fronteira abrange três a quatro ordens de magnitude.

Modos de falha: alto versus silencioso

A consequência de roteamento é direta: ramos altos escalam barato porque seus erros se anunciam; ramos silenciosos exigem supervisão paga para sempre.

O roteador híbrido com o LLM como manipulador de fronteira

O padrão de produção mais forte não é uma escolha entre os três ramos, e sim um cascata. A camada determinística responde tudo o que consegue, com um escore de confiança anexado. O que fica abaixo do limiar — a cauda da distribuição — é roteado para o LLM com um prompt enxuto e um formato de saída restrito. A acurácia frequentemente melhora junto com a redução de gasto, por uma razão estrutural: o determinístico cuida da cabeça repetitiva (onde é confiável) e o LLM vê apenas os casos genuinamente ambíguos.

def route(doc):
    score, result = deterministic_layer(doc)  # matcher, classifier, parser
    if score >= THRESHOLD:
        return result
    answer = llm_fallback(doc)                # prompt enxuto, saída restrita
    log_fallback(doc, answer)                 # alimenta o loop de promoção
    return answer

O loop de promoção transforma o fallback em um centro de custo que encolhe: registre cada saída do LLM com entrada e saída. Quando a mesma correção se repete, promova-a — um nome de fornecedor que o LLM corrige toda semana vira um alias canônico na lista de referência; uma classe recorrente de baixa confiança vira linhas de treino rotuladas ou uma regra nova. A camada determinística absorve o que o LLM ensinou, e a taxa de fallback cai. Trate o limiar como decisão de produto, não só de ML: comece conservador, meça a precisão em cada limiar candidato numa amostra rotulada e lembre que o limiar define, literalmente, quantos documentos por dia você está disposto a pagar centavos para processar.

Checklist para colocar em produção

1. Nomeie o formato: classificar, casar, ler, limpar, sintetizar. Se não conseguir nomear, pergunte ao requisitante como é uma saída correta — a resposta costuma nomear o formato.
2. Pergunte se a saída precisa ser texto novo: se não, um modelo generativo é o ramo errado, por custo e por falha.
3. Verifique se o conjunto de respostas é fixo: lista ou rótulo fixo roteia para determinístico; vocabulário aberto sobre corpus mutável roteia para RAG; julgamento e redação roteiam para LLM.
4. Faça a matemática de volume com preços públicos: custo por documento vezes volume mensal, por ramo candidato, escrito. O gap costuma ser o argumento inteiro.
5. Escreva o contrato de falha: como é um bug neste ramo, e quem nota primeiro?
6. Adicione o fallback antes de precisar: limiar de confiança, LLM como manipulador de fronteira, saídas registradas.
7. Instrumente o loop de promoção: revise fallbacks recorrentes mensalmente e converta vencedores em aliases, regras e linhas de treino.

Troubleshooting

• ❌ Resposta silenciosamente errada em fluxo de documentos → é o modo de falha do LLM/RAG. Adicione eval sets agendados e auditorias humanas; nada no pipeline avisa que errou.
• ❌ RAG respondendo fluentemente a partir de índice velho → o índice está obsoleto em relação à fonte. Monitore recall de chunks e frescor do índice como primeira métrica.
• ❌ Custo explodiu ao rotear tudo para o LLM → você está pagando preço de geração por trabalho de classificação. Roteie os formatos determinísticos de volta para matcher/classificador.
• ❌ Cold start sem dados rotulados → o orçamento de rotulagem domina. Use o LLM como manipulador de fronteira para o tráfego inicial e colha os fallbacks como linhas de treino.
• ❌ Falso positivo em fuzzy matching → o limiar está folgado demais. Ajuste o limiar em amostra rotulada; zero-match é o modo de falha alto esperado, não um bug.

FAQ

NLP, LLM e RAG são excludentes? Não. O padrão mais forte é o cascata: determinístico responde a cabeça, o LLM trata a cauda ambígua, e o RAG entra quando há corpus grande e mutável.

Quando o RAG vale a pena? Quando o corpus é grande, as perguntas são de vocabulário aberto e o conteúdo muda. Para um único documento, use chamada direta de LLM.

Qual é a diferença de custo real? Três a quatro ordens de magnitude entre fuzzy matching (praticamente grátis) e uma chamada de fronteira (centavos por chamada, milhares de dólares em volume).

Por que “ler tabela” não é tarefa de LLM? Porque é um problema de geometria (detectar fronteiras de células), não de compreensão de linguagem — e um parser de layout resolve a fração do custo.

O que é o loop de promoção? Registrar cada correção do LLM e promover as recorrentes para regras, aliases e linhas de treino, fazendo a taxa de fallback cair com o tempo.

Tendência

A pressão por eficiência de custo em IA só aumenta, e a separação entre “o que precisa de um modelo generativo” e “o que um componente determinístico resolve” tende a se tornar o novo senso comum da engenharia de dados. O roteamento por formato de tarefa — com o LLM como professor que devolve conhecimento à camada determinística — aponta para pipelines que ficam mais baratos e mais precisos com o tempo, em vez do contrário. Quem dominar essa disciplina de aritmética e contrato de falha sai na frente quando o orçamento apertar.