Por que a complexidade do RAG precisa ser conquistada

Um erro comum em sistemas de RAG (Geração Aumentada por Recuperação) é empilhar técnicas avançadas — reescrita de consulta, reranking neural, agentes, reflexão — antes de verificar se a etapa básica de recuperação funciona. Um artigo de Tahreem Rasul no Towards Data Science defende uma tese provocadora: a complexidade deve ser conquistada, não adotada como padrão.

O sintoma: arquitetura sofisticada, causa simples

O padrão descrito pelo autor é familiar a quem trabalha com IA em produção: surge um problema de recuperação e, antes de estabelecer se a recuperação funciona, a arquitetura acumula query rewriting, roteamento, múltiplas passadas, reflexão e um agente decidindo se mais evidência é necessária.

O problema: o sistema pode continuar falhando por um motivo muito mais simples — a evidência relevante foi ranqueada fora do conjunto de candidatos e nunca entrou no contexto do modelo. “Se a falha dominante é que a evidência não foi recuperada, mais raciocínio após a recuperação provavelmente não corrige a causa raiz”, escreve Rasul. “Pode apenas aumentar latência, consumo de tokens e o número de componentes que precisam ser avaliados.”

Recuperação e geração são capacidades distintas

O artigo insiste em separar dois conceitos que costumam ser avaliados juntos: recuperação (identificar informação relevante) e geração (interpretar e responder). Quando um contrato tem a cláusula de rescisão certa, mas ela fica fora do top-k retornado, o modelo pode até produzir uma resposta plausível — mas o sistema falhou na recuperação. Nenhum ajuste no prompt recupera evidência que nunca entrou no contexto.

A pergunta diagnóstica central, então, é: a evidência necessária estava presente no conjunto recuperado?

BM25 continua competitivo

Um dos pontos mais interessantes é a defesa do BM25, o algoritmo clássico de busca lexical. Em domínios onde termos exatos importam — códigos de erro, identificadores de contrato, citações legais, siglas, nomes de produto — a busca lexical supera a busca semântica. Um benchmark financeiro de 2026 com 23.088 perguntas e 7.318 documentos mistos (texto + tabela) mostrou o BM25 vencendo o melhor método de recuperação densa avaliado.

A conclusão não é “lexical é melhor que embeddings”, mas que cada método resolve uma falha diferente. A busca densa brilha quando há pouca sobreposição de vocabulário (ex.: o usuário pergunta sobre “demissão voluntária” e a política fala em “rescisão por iniciativa do empregado”).

Um caminho progressivo em oito níveis

O artigo propõe tratar a complexidade como uma escalada, em que cada mecanismo novo corresponde a uma limitação observada no nível anterior:

1. Estabelecer se a recuperação é necessária (bases pequenas podem ir direto ao contexto);
2. Representar o corpus corretamente (parsing, hierarquia, metadados, chunks);
3. Baseline lexical (BM25);
4. Recuperação densa (quando há mismatch lexical-semântico);
5. Recuperação híbrida (quando lexical e densa são complementares);
6. Reranking (quando o recall é bom mas a ordem é fraca);
7. Transformação de consulta (reescrita e decomposição);
8. Recuperação agêntica (quando o processo exige decisões adaptativas).

Onde os agentes realmente ajudam

O artigo não é contra RAG agêntico — apenas o situa corretamente. Agência faz sentido quando a necessidade de informação é multi-hop, iterativa ou condicional: identificar a fonte certa, recuperar um dado, usar esse dado para formular a próxima busca. Um estudo de escala de 2026 trouxe um resultado revelador: uma camada de recuperação mais forte não tornou o agente redundante — tornou o agente consideravelmente melhor.

Para times que constroem sistemas de busca sobre documentos, a lição é direta: antes de adicionar complexidade, meça onde a falha acontece. “A presença de um componente deve ser explicável em termos de uma limitação medida do sistema” — não porque a técnica está em alta.