RAG morreu? O que a medição diz sobre contexto longo e recuperação

Contexto longo acertou 73,1% das perguntas. RAG semântico acertou 65,4%.

E o contexto longo custou 26 vezes mais por consulta.

Essa é a resposta curta para a pergunta do título, e ela não é sim nem não. Existe uma fronteira entre acurácia e custo, e o que você deve fazer depende de onde está nela.

A parte boa é que existe uma saída medida. Em 63% das consultas, os dois métodos dão a mesma resposta — o que significa que dá para mandar a maioria pelo caminho barato sem perder nada.

A pergunta ficou razoável quando as janelas passaram de um milhão de tokens. Se tudo cabe, recuperar vira uma etapa que talvez dê para pular.

E ela acerta numa coisa. A arquitetura padrão de 2023 — fatiar todo documento, gerar embeddings, guardar num banco vetorial e trazer os k mais parecidos — era pesada para boa parte dos problemas que resolvia. Muita gente montou essa stack para um corpus de duzentos documentos que caberia numa busca por texto.

O que a pergunta erra é supor que o resultado é binário. Os dois métodos foram medidos lado a lado, e o que aparece é uma troca, não um vencedor.

Em junho de 2026, um grupo publicou uma comparação direta entre carregar a coleção inteira no contexto e recuperar apenas as passagens relevantes.

O trabalho é "The Token Tax of Epistemic Accuracy: Comparing RAG and Long-Context Architectures for Document-Grounded Generative AI Applications", de Austin Hamilton, Ryan Singh, Michael Wise, Ibrahim Yousif, Arthur Carvalho, Zhe Shan, Mohammad Mayyas, Lora A. Cavuoto e Fadel M. Megahed (arXiv 2606.20898, acesso em 28/08/2026). O estudo de caso é treinamento de segurança industrial, com 972 respostas avaliadas contra um benchmark validado por especialistas, em três máquinas e dois modelos pequenos.

O enquadramento dos autores vale reusar. Eles tratam os dois métodos como regimes de acesso epistêmico: o acesso mais amplo aumenta a chance de o modelo ter a evidência certa em mãos, e cobra por isso um imposto de tokens.

Sete vírgula sete pontos de acurácia, ao preço de vinte e seis vezes o custo. Se isso vale a pena depende inteiramente do que uma resposta errada custa no seu caso.

O que dá confiança no resultado acima é que ele não é novo.

Em julho de 2024, Zhuowan Li, Cheng Li, Mingyang Zhang, Qiaozhu Mei e Michael Bendersky publicaram "Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach" (arXiv 2407.16833, revisto em outubro de 2024; acesso em 28/08/2026). Compararam os dois métodos em vários conjuntos públicos, com três modelos.

As duas conclusões, no texto dos autores: quando há recurso suficiente, o contexto longo supera o RAG de forma consistente no desempenho médio; e o custo significativamente menor do RAG permanece uma vantagem distinta.

Dois grupos, dois anos de distância, domínios e métodos diferentes, e a mesma forma de resultado. Essa convergência é o argumento mais forte deste post, e é o que permite tratar a fronteira como fato e não como opinião de quem mediu.

<!-- [UNIQUE INSIGHT] -->

Aqui é preciso conciliar duas medições que parecem brigar.

O post sobre os quatro pilares do contexto trouxe o trabalho da Chroma, em que 18 modelos degradam conforme a entrada cresce, antes de a janela encher. Agora aparece uma medição em que carregar tudo produz mais acerto.

As duas coisas convivem, e a explicação está na escala.

A vantagem de acurácia do contexto longo existe enquanto a coleção cabe na zona confiável da janela. Nesse regime, ter todo o material disponível supera o risco de a recuperação trazer a passagem errada. Conforme o corpus cresce, dois efeitos se somam contra ele: a degradação por comprimento come o ganho de acurácia, e o custo continua subindo de forma linear.

A consequência prática é que a resposta certa não é estável ao longo da vida do projeto. Um sistema que começa com duzentos documentos e vai para vinte mil atravessa a fronteira em algum momento, e ninguém envia um aviso quando isso acontece.

A saída proposta pelo estudo de 2024 tem nome: Self-Route. O modelo avalia a própria capacidade de responder com a passagem recuperada e, quando conclui que não consegue, a consulta é reenviada com o contexto completo.

Os números explicam por que isso funciona tão bem:

Em quase dois terços dos casos, os dois métodos chegam à mesma resposta. Pagar 26 vezes mais por eles é desperdício puro, e o roteamento existe para não pagar.

Uma versão simples do roteamento cabe em qualquer projeto, antes de sofisticar. Uma heurística por tipo de pergunta resolve boa parte: perguntas sobre um documento específico vão para recuperação; perguntas que exigem comparar ou sintetizar a coleção inteira vão para contexto completo. Medir qual rota ganha nos seus casos é trabalho de eval, com um conjunto pequeno e estável.

Um caso concreto, decidido

Abstração ajuda pouco aqui. Um exemplo torna a regra utilizável.

Imagine um assistente interno que responde perguntas sobre a documentação de uma empresa. Quatro mil documentos, atualizados toda semana, com áreas que nem todo funcionário pode ver.

Pelo critério de tamanho, quatro mil documentos não cabem numa janela com folga, então o contexto completo já sai da mesa por custo. Pelo critério de frescor, recarregar tudo a cada atualização semanal seria desperdício. E pelo critério de permissão, a decisão está tomada antes de qualquer conta: a filtragem precisa acontecer antes da geração.

Recuperação vence os três, e nem foi preciso comparar acurácia.

Agora mude um detalhe. O mesmo assistente, mas o escopo de cada pergunta é um único manual de trinta páginas, escolhido pelo usuário antes de perguntar.

Aí a resposta inverte. Trinta páginas cabem com folga, o custo por consulta é baixo, e a permissão já foi resolvida na escolha do manual. Carregar o documento inteiro entrega os 7,7 pontos de acurácia sem pagar o imposto que só aparece em coleções grandes.

É o mesmo produto, com duas respostas certas diferentes. O que mudou não foi a tecnologia disponível, e sim o recorte da pergunta. É por isso que o roteamento vence a escolha única: dentro de um mesmo sistema, consultas diferentes estão em pontos diferentes da fronteira.

O recuperador ficou mais simples, e essa é a mudança mais subestimada da história.

O argumento está bem colocado por Fabio Akita, em "RAG Está Morto? Contexto Longo, Grep e o Fim do Vector DB Obrigatório", de abril de 2026: o gargalo de 2023 era a recuperação, e o de 2026 é raciocinar sobre contexto bagunçado. Com um leitor grande, rápido e barato, faz mais sentido um recuperador simples de alta cobertura do que uma stack sofisticada de busca semântica.

Concordo, e a medição do imposto de tokens explica por quê. Se o modelo lida bem com material extra, a recuperação não precisa ser cirúrgica. Ela precisa não perder o que importa, o que é um problema mais fácil e mais barato de resolver.

Na prática, busca por texto resolve mais caso do que a arquitetura padrão sugeria, sobretudo quando você escreveu os documentos e a consulta usa o mesmo vocabulário deles.

Vale nomear o que de fato morreu, porque não é a recuperação. É o conjunto de decisões que virou padrão sem nunca ter sido medido: fatiar todo documento em pedaços de tamanho fixo, ignorando onde as ideias começam e terminam; gerar embeddings de tudo, inclusive do que ninguém consulta; trazer sempre os mesmos k resultados, independentemente de a pergunta precisar de um ou de nove; e tratar banco vetorial como requisito de entrada, antes de existir volume que o justifique.

Nenhuma dessas quatro escolhas era necessária. Todas foram copiadas juntas, como se fossem uma coisa só, e é esse pacote que está sendo desfeito.

O que continua justificando busca vetorial é específico:

• Corpus grande demais para uma varredura textual ser viável.
• Vocabulário divergente entre a pergunta e o documento, quando o usuário pergunta de um jeito e o texto responde de outro.
• Necessidade real de similaridade semântica, e não de correspondência de termo.

Vale notar que recuperar ferramenta é o mesmo problema com outro nome. No post sobre design de ferramentas, a acurácia de escolha despencou com o número de ferramentas expostas, e a solução medida foi recuperar em vez de listar. A pergunta "quais das minhas opções esta tarefa precisa ver?" é sempre a mesma.

O critério não é o tamanho da janela. São cinco características do problema.

A linha de permissão merece destaque porque não é uma questão de preferência. Quando cada usuário pode ver um subconjunto diferente dos documentos, carregar a coleção inteira no contexto deixa de ser uma opção cara e passa a ser uma opção errada. A filtragem precisa acontecer antes da geração, e é isso que a recuperação faz por construção.

A fronteira se move enquanto o projeto anda, e ninguém envia aviso. Três sinais indicam que a arquitetura escolhida ficou para trás.

O custo por consulta cresce sem a qualidade acompanhar. É o sintoma clássico de contexto completo com corpus crescente. O gráfico da conta sobe de forma linear com o tamanho da coleção, e a acurácia não. Vale acompanhar pelo mesmo raciocínio de quanto custa cada padrão de uso.

A recuperação passa a errar em perguntas que antes acertava. Indica corpus crescendo mais rápido que a qualidade do índice, ou vocabulário de usuário se afastando do vocabulário dos documentos. Esse é o momento em que a busca por texto começa a pedir busca semântica.

As respostas ficam boas em pergunta específica e ruins em pergunta ampla. É o sinal de que existe uma classe de consultas precisando da rota cara, e que uma escolha única está prejudicando metade do produto.

Nenhum dos três aparece sem instrumentação. Com o rastro descrito em observabilidade de agente, os três são consultas simples: tokens por consulta ao longo do tempo, taxa de acerto por tipo de pergunta, e a comparação entre as duas rotas nos mesmos casos.

O erro comum é decidir a arquitetura uma vez, no começo, quando o corpus era pequeno e a pergunta era simples — e nunca mais revisitar.

<!-- [PERSONAL EXPERIENCE] -->

Não existe banco vetorial nesta operação. A recuperação é busca por texto no repositório e leitura de trechos de arquivo.

É o recuperador simples da tese do Akita, e chegou aqui por preguiça produtiva: nunca houve um momento em que a busca textual falhasse o bastante para justificar montar outra coisa.

Funciona por duas razões que vale nomear, porque são condições e não virtudes. O corpus é pequeno, com algumas dezenas de arquivos. E eu escrevi os documentos, então a consulta usa as mesmas palavras que o texto — o problema de vocabulário divergente não existe aqui.

Onde essa escolha falharia é previsível: corpus de terceiros, vocabulário do usuário diferente do vocabulário do documento, ou volume que não caiba numa varredura.

E ela já tem um custo observável. O post de ontem descreveu o terceiro modo de falha da memória, que é a informação existir e o agente não consultá-la. Com recuperação por texto, esse risco é maior do que seria com busca semântica: se eu escrevi "capa" no arquivo e a tarefa fala em "imagem de destaque", a busca não encontra. Já aconteceu.

A conclusão honesta é que a escolha certa aqui é a mais simples, e que isso é uma propriedade do meu corpus, não uma lei geral.

Se o blog crescer para algumas centenas de posts, ou se alguém além de mim passar a escrever, os dois sinais da seção anterior aparecem juntos e a decisão muda. Anotar isso agora é mais barato que descobrir depois.

RAG morreu?

Não. Num estudo de junho de 2026 com 972 respostas avaliadas, o contexto longo acertou mais — 73,1% contra 65,4% — a um custo 26 vezes maior por consulta. O que ficou obsoleto foi a arquitetura padrão de 2023, com fatiamento de todo documento e busca vetorial obrigatória para qualquer volume. A recuperação continua vencendo em custo, em corpus grande, em conteúdo que muda e em cenários com permissão por documento.

Contexto longo substitui RAG?

Substitui quando a coleção inteira cabe com folga na janela, o orçamento por consulta comporta o custo e não há controle de acesso por documento. Fora disso, não. A vantagem de acurácia do contexto longo encolhe conforme o corpus cresce, porque o desempenho dos modelos degrada com o comprimento da entrada mesmo antes de a janela encher, e o custo continua subindo.

Preciso de banco vetorial?

Não necessariamente. Busca por texto resolve muitos casos, sobretudo quando o corpus é pequeno e o vocabulário da consulta é parecido com o dos documentos. Banco vetorial se justifica quando o corpus é grande demais para varredura, quando usuário e documento usam palavras diferentes para a mesma coisa, ou quando você precisa de similaridade semântica de verdade. Comece pelo simples e migre quando a busca falhar de forma mensurável.

Qual é mais barato?

Recuperação, por uma ordem de grandeza. A medição revisada aponta 26 vezes menos tokens por consulta em relação ao contexto longo. Desconfie de números muito maiores que esse: circula por aí a alegação de "1.250 vezes mais barato", sem fonte primária que a sustente.

Dá para usar os dois na mesma consulta?

Dá, e é o padrão híbrido que se tornou comum: recuperar para estreitar o material e depois usar a janela grande para raciocinar sobre o que sobrou. A diferença para o roteamento é que aqui as duas técnicas atuam na mesma pergunta, em vez de uma escolher entre elas. Funciona bem quando a coleção é grande e a resposta exige comparar várias fontes: a recuperação garante que as peças certas entraram, e o contexto amplo dá espaço para o modelo relacioná-las. O custo fica entre os dois extremos, e o ajuste principal é quantas passagens trazer — poucas demais perdem a peça necessária, muitas demais recriam o imposto de tokens.

Como decidir entre os dois?

Roteie em vez de escolher. Em 63% das consultas, os dois métodos produzem resposta idêntica, então mandar a maioria pelo caminho barato não custa desempenho. Uma heurística simples já entrega boa parte do ganho: pergunta sobre documento específico vai para recuperação, pergunta que exige sintetizar a coleção vai para contexto completo. Depois meça, com um conjunto pequeno de casos seus, quais consultas realmente precisam da rota cara.

• Contexto longo é mais preciso e 26 vezes mais caro. 73,1% contra 65,4%, em 972 respostas avaliadas.
• Dois estudos independentes, com dois anos de distância, chegam à mesma fronteira.
• Em 63% das consultas os dois dão a mesma resposta. Rotear corta de 39% a 61% dos tokens.
• A vantagem do contexto longo tem teto, e o teto é o tamanho do corpus.
• O "R" ficou mais simples. Busca por texto resolve mais do que a stack de 2023 sugeria.
• Permissão por documento decide sozinha: com ela, carregar tudo vaza, e o preço deixa de importar.

Isso fecha a semana de contexto. A próxima trata de como os agentes conversam entre si e com o mundo: o mapa dos protocolos. As cinco camadas continuam no pilar sobre harness engineering.