O Retrieval-Augmented Generation (RAG) se consolidou como a abordagem padrão para conectar documentos a modelos de linguagem. O padrão é elegante: indexar um corpus, recuperar os trechos mais relevantes por similaridade vetorial e injetá-los no prompt. Funciona bem em demonstrações — e falha de maneiras previsíveis e documentadas que só aparecem em escala.
Este artigo mapeia os modos de falha mais comuns do RAG em produção e apresenta as alternativas que engenheiros estão adotando para contorná-los.
Os Três Modos de Falha do RAG
1. Irrelevância de Recuperação
O padrão mais comum: um usuário pergunta sobre a política de licença parental de 2025. O recuperador retorna a versão de 2022, a de 2024 e um post institucional do blog corporativo. Cada trecho tem alta similaridade vetorial porque compartilha vocabulário com a consulta. Nenhum responde à pergunta. O modelo não sabe que o conteúdo recuperado está desatualizado ou fora de tópico — e sintetiza uma resposta confiante e factualmente errada.
2. Envenenamento de Contexto
Bases de conhecimento empresariais frequentemente armazenam múltiplas versões do mesmo documento de política. Quando o recuperador devolve trechos de versões diferentes, o modelo não sinaliza a contradição — escolhe uma, mescla as duas ou apresenta uma síntese confiante. O leitor recebe uma resposta. A resposta pode estar errada. Nem o usuário nem o modelo sabem disso.
3. Conflito Estrutural de Chunk
A causa raiz é um trade-off arquitetural: boa recuperação exige chunks pequenos (100-256 tokens) para precisão; boa compreensão de contexto exige chunks grandes (1.024+ tokens) para coerência. Todo engenheiro de RAG escolhe um lado e aceita a penalidade do outro.
O Custo do Over-Engineering
Quando o RAG convencional falha, a resposta instintiva é adicionar complexidade: embeddings de dimensão maior, reranking mais sofisticado, recuperação em múltiplas etapas. Isso agrava o problema. Em 2025, implementações enterprise de RAG tiveram uma taxa de falha de 72% no primeiro ano. Uma fabricante global chegou a US$ 1,2 milhão em custos para 23% de acurácia. Uma empresa de saúde atingiu US$ 75 mil por mês só em banco vetorial.
Alternativa 1: Long-Context Prompting
Se o corpus cabe na janela de contexto do modelo, carregue-o integralmente e deixe o modelo ler. Um estudo de benchmark mostrou que LLMs de contexto longo superam consistentemente o RAG em tarefas de QA quando há capacidade computacional disponível.
O trade-off de custo é significativo: com 1 milhão de tokens, a latência é de 30 a 60 vezes maior que um pipeline RAG, e o custo por consulta é cerca de 1.250 vezes superior. Com prompt caching para aplicações de alto tráfego, o long-context pode se tornar competitivo. Regra prática: se o corpus cabe na janela e o volume de consultas é moderado, comece com long-context. Adicione recuperação apenas quando o corpus exceder a janela ou a latência violar os SLOs.
Alternativa 2: Recuperação Baseada em Sumarização
Quando o corpus é grande demais para a janela, comprima antes de recuperar. Em vez de puxar chunks brutos, a sumarização condensa documentos antes da injeção. Benchmarks mostram que essa abordagem tem desempenho comparável ao long-context completo — enquanto o RAG baseado em chunks fica consistentemente atrás de ambos.
Um resultado concreto: uma abordagem RAG com preservação de ordem usando 48K tokens bem escolhidos superou a recuperação de contexto completo com 117K tokens em 13 pontos F1, com um sétimo do orçamento de tokens. Um documento bem comprimido vence um dump bruto de trechos tangencialmente relacionados.
Alternativa 3: GraphRAG para Consultas Multi-Hop
Para consultas que exigem entender relações entre documentos — não apenas buscar uma passagem específica — a recuperação vetorial falha por definição. Exemplo: “Quais decisões o conselho reverteu no terceiro trimestre e qual foi a justificativa em cada caso?” Nenhum chunk único responde a isso. A resposta está nas conexões entre documentos.
O GraphRAG, introduzido pela Microsoft Research em 2024, constrói um grafo de conhecimento a partir do corpus e percorre relações entre entidades em vez de casar vetores. Ele resolve diretamente o caso de falha que o RAG padrão não consegue tratar: síntese entre múltiplos documentos que exige raciocínio relacional.
O trade-off é o custo: a extração do grafo de conhecimento é de 3 a 5 vezes mais cara que o RAG baseline e exige ajuste específico por domínio. Vale a pena para análise temática e raciocínio multi-hop. Para buscas factuais de passagem única, não.
Roteamento por Tipo de Consulta
Quando a recuperação é a arquitetura correta, a solução é rotear por tipo de consulta em vez de aplicar embeddings melhores uniformemente. Uma pesquisa apresentada na EMNLP 2024 introduziu o Self-Route, que deixa o modelo classificar se uma consulta precisa de contexto completo ou recuperação focada antes de executá-la. Consultas factuais simples vão para RAG focado. Perguntas multi-hop complexas vão para contexto longo.
O resultado: melhor acurácia geral com menor custo computacional. Sistemas adaptativos com essa abordagem híbrida demonstraram melhorias de 15% a 30% na precisão de recuperação com busca híbrida e reranking.
A chave é tornar o roteamento explícito: cada consulta é classificada antes que qualquer recuperação aconteça, e o sistema para de tratar todas as consultas como problemas idênticos de embedding.
Descubra mais sobre noticiAI
Assine para receber nossas notícias mais recentes por e-mail.
