Dez posições para RAG corporativo que os tutoriais ensinam errado

Uma arquitetura que discorda dos tutoriais

A receita padrão de RAG (geração aumentada por recuperação) aparece igual em todo lugar: divida os documentos em pedaços, coloque-os em um banco vetorial, gere embeddings da pergunta, recupere os top-k por similaridade de cosseno, opcionalmente reordene e envie tudo para um LLM. Funciona em exemplos de “hello world”, mas começa a falhar no dia em que um documento corporativo de verdade entra no sistema.

É contra essa receita que a série Enterprise Document Intelligence argumenta, em um manifesto de dez posições que rompem com o RAG ensinado nos tutoriais tradicionais. As posições se dividem em três camadas: as quatro primeiras atacam a receita de recuperação; as três seguintes definem o que “enterprise” realmente significa; e as três últimas tratam da auditoria e da avaliação.

As dez posições, uma a uma

1. Bancos vetoriais são um plano B, não o alicerce. O tutorial padrão coloca o banco vetorial como ponto de entrada, com tudo passando pela similaridade de cosseno. A série inverte: a recuperação estruturada (o índice do documento, o sumário, palavras-chave de especialistas) resolve a maior parte das perguntas reais. Embeddings entram como rede de segurança para os casos residuais — paráfrases, siglas internas — e não como etapa inicial. O argumento central é a interpretabilidade: com busca por palavras-chave você consegue explicar por que um trecho foi recuperado; com cosseno, não.

2. Dicionários de especialistas vencem melhores modelos de embedding. O problema dos sinônimos — “prêmio” vs. “custo”, “rescisão” vs. “cancelamento” — é resolvido de forma mais confiável por uma tabela mantida por especialistas do domínio do que por um modelo pronto. Embeddings continuam como fallback para formulações que o dicionário ainda não capturou.

3. Rerankers são ferramenta secundária, não etapa principal. Cross-encoders têm seu lugar quando o conjunto de candidatos é grande. No cenário corporativo, com conjuntos pequenos e bem escopados, eles só acrescentam latência e complexidade para ganho marginal. O caso clássico de falha são perguntas de listagem, em que o reranker promove o item mais relevante e rebaixa silenciosamente o resto.

4. Recuse “conectar tudo a um banco vetorial”. Esse padrão é otimizado para o modelo de negócio do provedor — uma chamada de embedding por pedaço, uma busca vetorial por consulta — e não para a precisão do cliente. A alternativa é uma arquitetura em escala de corpus: classificar antes de indexar, extrair campos estruturados, filtrar no índice e rotear perguntas de agregação para um agente SQL, não para o RAG.

5. Uma empresa não é o Google. O manual do “nós somos o Google” — recuperar em um índice de dez milhões de documentos — não se transfere para o contexto corporativo, que costuma ter algumas centenas de tipos de documento e algumas dezenas de especialistas. A arquitetura certa para esse cenário não tem nada a ver com a do Google.

6. Amplifique o especialista, não o substitua. RAG corporativo roda sobre documentos que os especialistas já conhecem de cor: contratos, laudos regulatórios, relatórios técnicos. O papel do sistema é escalar esse julgamento, não contorná-lo. A maioria dos erros de arquitetura vem de esquecer essa premissa.

7. Despachante determinístico vence agente autônomo. O “RAG agêntico” vende flexibilidade, mas um despachante determinístico — um arquivo de código que lê os campos estruturados da pergunta e roteia para um subpipeline nomeado — faz o mesmo trabalho com a vantagem de que um humano pode ler o código e um auditor pode reproduzir a decisão. Autonomia é boa para exploração; é errada em contextos regulados.

8. Avaliação por modo de falha, não agregada. Um sistema com 95% de precisão pode esconder 50% no subconjunto difícil — referências cruzadas, perguntas de listagem, cláusulas condicionais. A série defende conjuntos de referência fatiados por tipo de pergunta e modo de falha, porque métricas por fatia dizem a verdade.

9. Cada bloco produz dados relacionais estruturados, nunca strings cruas. O parsing retorna DataFrames (line_df, toc_df, image_df), não um objeto com texto solto. As junções entre blocos são tabelas, o que permite testar cada bloco isoladamente e reexecutar a recuperação sem reanalisar o documento.

10. Citações são evidência, não decoração. Toda resposta vem com coordenadas de página e linha, além de uma citação literal. A citação não torna o LLM menos opaco — mas torna essa opacidade irrelevante para a pergunta que importa no mundo corporativo: “de onde veio esta resposta?”. Com disciplina de armazenamento, a citação vira a única explicação que um sistema empresarial precisa.

O recado geral para quem constrói RAG em produção: pare de otimizar a parte errada. Em vez de varreduras de chunk-size e ajustes de embedding, classifique as perguntas, use o vocabulário dos especialistas e conserte o bloco que quebrou.