RAG Inútil

A geração aumentada por recuperação (RAG) surgiu como a abordagem padrão para conectar documentos com grandes modelos de linguagem (LLMs). O padrão é simples: incorporar um corpus, recuperar os trechos mais relevantes por similaridade de vetor, injetá-los em um prompt. Funciona bem em demonstrações e muitos sistemas de produção. Também falha de maneiras previsíveis e documentadas que só aparecem em escala. Aqui estão os modos de falha e as alternativas que os engenheiros estão buscando para解决-los.

O padrão de falha mais comum é a irrelevância de recuperação. Um usuário consulta uma política de licença parental. O recuperador retorna a versão de 2022, a versão de 2024 e um post de blog cultural. Cada trecho obtém uma pontuação alta em distância de incorporação porque compartilha vocabulário com a consulta. Nenhum deles responde à pergunta que o usuário realmente fez. O modelo não sabe que o conteúdo recuperado está desatualizado ou fora do tópico. Ele mistura os trechos em uma resposta confiante e detalhada que é factualmente errada. Isso é similaridade tópica sem relevância factual, e é o modo de falha dominante em sistemas RAG de produção.

Uma versão mais sutil é a contaminação de contexto. Bases de conhecimento empresariais geralmente contêm o mesmo documento de política em várias versões. Quando o recuperador retorna trechos de ambas, o modelo não apresenta a contradição. Ele escolhe um, mistura ambos ou apresenta uma síntese confiante. O leitor obtém uma resposta. A resposta pode estar errada. Nem o usuário nem o modelo sabem disso. A causa subjacente é um conflito estrutural no pipeline de trecho-incorporação-recuperação. Uma boa lembrança precisa de trechos pequenos, em torno de 100 a 256 tokens, para recuperação focalizada. Uma boa compreensão de contexto precisa de trechos grandes, 1.024 tokens ou mais, para coerência. Cada designer de RAG escolhe um e aceita a compensação.

Quando o RAG padrão não atende às expectativas, a solução comum é torná-lo mais complicado: incorporações de dimensão mais alta, reclassificação mais sofisticada, recuperação em várias etapas. Isso complica o problema. Uma empresa de manufatura global orçou US$ 400 mil para seu sistema RAG. No primeiro ano, o custo foi de US$ 1,2 milhão. A precisão final em consultas de documentação técnica: 23%. O projeto foi encerrado. Uma empresa de saúde atingiu US$ 75 mil por mês em custos de banco de dados de vetores no sexto mês. Esses resultados refletem um padrão mais amplo: as implementações de RAG empresariais tiveram uma taxa de falha de 72% no primeiro ano em 2025.

Dimensões de incorporação mais altas e modelos de vetor mais sofisticados não melhoram automaticamente o desempenho. Eles aumentam os custos de processamento e adiam a pergunta mais útil, que é se a arquitetura de recuperação foi a escolha certa desde o início.

A alternativa mais direta para engenharia de um pipeline RAG em dificuldades é simplesmente pular a recuperação. Se o corpus couber na janela de contexto do modelo, carregue-o e deixe o modelo ler. Um estudo de benchmarking encontrou que os LLMs de contexto longo consistentemente superaram o RAG em tarefas de QA quando o processamento estava disponível, com a recuperação baseada em trechos atrasando o mais. A compensação de custo é significativa. Em 1 milhão de tokens, a latência é 30 a 60 vezes mais lenta do que um pipeline RAG, a um custo por consulta cerca de 1.250 vezes maior. Com cache de prompt para aplicativos de alto tráfego, o contexto longo pode se tornar competitivo em termos de custo.

Uma regra de decisão comum: se o corpus couber na janela de contexto e o volume de consultas for moderado, o contexto longo é o ponto de partida mais limpo. Adicione recuperação apenas quando o corpus exceder a janela, a latência violar os objetivos de nível de serviço (SLOs) ou o volume de consultas cruzar o ponto de equilíbrio econômico.

Quando o corpus é muito grande para a janela de contexto, resuma antes de recuperar. A recuperação baseada em resumo comprime os documentos antes de injetá-los, em vez de puxar trechos brutos. Os benchmarks mostram que essa abordagem tem um desempenho comparável aos métodos de contexto longo, enquanto a recuperação baseada em trechos consistentemente fica atrás de ambos. Um resultado concreto: uma abordagem RAG de preservação de ordem usando 48 mil tokens bem escolhidos superou a recuperação de contexto completo em 117 mil tokens por 13 pontos F1, a um sétimo do orçamento de tokens. Um documento relevante e bem comprimido supera um despejo bruto de trechos tangencialmente relacionados.

Quando a recuperação é a arquitetura certa, a solução é roteamento por tipo de consulta, em vez de aplicar melhores incorporações uniformemente. Pesquisas do EMNLP 2024 introduziram o Self-Route, que permite que o modelo classifique se uma consulta precisa de contexto completo ou recuperação focalizada antes de executá-la. Buscas factuais simples vão para o RAG focalizado. Perguntas complexas de múltiplos saltos que exigem compreensão global vão para um contexto longo. O resultado: melhor precisão geral a um custo computacional mais baixo. Sistemas adaptativos que usam essa abordagem híbrida mostraram melhorias de 15 a 30% na precisão de recuperação por meio de busca e reclassificação híbridas.

A mudança fundamental é tornar o roteamento explícito. Cada consulta é classificada antes de qualquer recuperação ser executada, e o sistema para de tratar todas as consultas como problemas de incorporação idênticos. Isso permite que