RAG não é o kit completo: as técnicas de NLP que problemas reais ainda precisam

RAG não é o kit completo: as técnicas de NLP que problemas reais ainda exigem

Existe uma tentação comum em projetos de IA com documentos: usar RAG (geração aumentada por recuperação) para tudo. Mas a recuperação responde a um único tipo de pergunta. Classificar uma solicitação, casar texto livre com uma lista de referência, ler uma tabela ou limpar ruído de OCR — cada tarefa dessas tem um método mais barato e mais eficaz. A engenharia está em saber qual usar em cada caso.

É essa a tese central de uma série sobre inteligência de documentos corporativos publicada na Towards Data Science pelo engenheiro Kezhan Shi. O trabalho mapeia um “kit de ferramentas” além do RAG, organizado em quatro famílias de técnicas que pipelines de produção reais ainda precisam.

As quatro famílias

A primeira família são as preocupações práticas transversais — problemas que atravessam mais de uma etapa do pipeline. Destacam-se três exemplos que todo time encontra:

• Texto com ruído: typos de usuário, ruído de transcrição e erros de OCR. Quarenta anos de correção ortográfica clássica (Levenshtein, BK-tree, Soundex, SymSpell) resolvem apenas uma parte do problema; embeddings e LLMs absorvem o resto. A divisão prática defendida: corrigir a pergunta contra o vocabulário do corpus no momento da análise, deixar o ruído de volume como está e projetar a recuperação para conviver com ele.
• Respostas “não sei”: uma resposta errada e confiante é um bug; um “sem resposta” sem justificativa é quase tão ruim. A proposta é tornar o “não sei” auditável — cada etapa deve ao usuário uma evidência do que foi analisado, pesquisado e por que nada casou.
• Tabelas em PDFs: é onde a maioria dos pipelines de RAG falha em silêncio. Achatar a grade em texto linear destrói a estrutura. A alternativa é uma escada de quatro níveis de representação, com um diagnóstico por tabela em cinco eixos — e a maioria das tabelas fica no nível mais simples, pagando o custo da complexidade só quando necessário.

A segunda família são os formatos alternativos de pipeline. O caso clássico: quando o corpus é um FAQ controlado (em vez de um conjunto caótico de PDFs herdados), toda a lógica se inverte. A análise fica trivial, a recuperação funciona como cache e o prompting few-shot vira, ele próprio, um problema de recuperação.

As outras duas famílias completam o mapa: benchmarks reproduzíveis (para comparar variações de pipeline sem engano) e o stack de LLM local (para quem precisa rodar tudo on-premise).

O ponto que vale reter

O recado prático é direto: antes de empilhar um LLM com recuperação vetorial para qualquer problema documental, pergunte se a tarefa não é, na verdade, uma classificação, uma correspondência, uma leitura de tabela ou uma limpeza de OCR. Cada uma dessas tem uma solução clássica que funciona — mais barata, mais rápida e mais explicável.

A série também registra um princípio valioso para quem constrói pipelines: um mock de teste que simplifica um tipo de retorno por conveniência esconde bugs de produção. Todo mock deve ter exatamente a forma do objeto que substitui. Parece detalhe, mas é o tipo de disciplina que separa pipelines que quebram em produção dos que sobrevivem.

Para times brasileiros que estão adotando IA em documentos — contratos, notas fiscais, processos judiciais, prontuários —, a lição é valiosa: o RAG é uma ferramenta poderosa, mas longe de ser a única. Saber quando não usar é o que diferencia um sistema robusto de um protótipo frágil.