O ciclo repete-se a cada poucos meses com uma pontualidade suspeita. Um laboratório anuncia uma janela de contexto maior, o anúncio transforma-se em captura de ecrã, e na reunião seguinte alguém diz a frase: « então já não precisamos do RAG, metemos os documentos inteiros no prompt e está resolvido ». Soa a simplificação, que é exactamente o que todos querem ouvir sobre uma arquitectura que custou meses. E é o tipo de simplificação que se paga três vezes: em precisão, em factura e na noite em que algo responde mal e ninguém sabe porquê.
A tese numa linha: « janela de contexto grande ou RAG » não é uma alternativa, porque as duas coisas não resolvem o mesmo problema. A janela de contexto é uma medida de capacidade — quanto cabe numa chamada. A recuperação é uma decisão de selecção — o que entra, de tudo o que tens. Aumentar a primeira não responde à segunda. E quando desistes de decidir o que entra, o que acontece está medido: a precisão cai muito antes do limite anunciado, o custo por chamada sobe com o tarifário na mão, e a falha deixa de ser depurável porque já não sabes que fragmento o modelo usou.
Isto não é defender uma arquitectura por afecto. Há casos — estão no fim, com nome — em que a janela grande é efectivamente a resposta certa e montar recuperação seria sobre-engenharia. É sobre decidir pelos motivos reais e não pelo título de um lançamento.
Janela de contexto grande ou RAG: não é a mesma pergunta feita duas vezes
A confusão tem uma raiz concreta: as duas coisas acabam no mesmo sítio — texto à frente do modelo no momento de responder — e por isso parecem intercambiáveis. Não são. A janela de contexto é o espaço de trabalho desta chamada: enche-se, usa-se e esvazia-se. A recuperação é o mecanismo que escolhe, de um corpus que não cabe nem caberá nunca, os fragmentos que merecem ocupar esse espaço. Uma é o tamanho da mesa; a outra decide que papéis se põem em cima.
A taxonomia completa — contexto da conversa, conhecimento consultável e memória de longo prazo, onde vive cada camada e quanto custa — já está escrita no guia sobre a memória de um agente de IA, e reargumentá-la aqui não faria sentido. O que esse guia não cobre, porque não é a sua pergunta, é esta: o que acontece exactamente quando o mercado te oferece mais mesa e tu decides que assim poupas quem escolhe os papéis.
O que se rompe primeiro não é o limite: é a precisão
A parte contra-intuitiva é que o problema aparece muito antes de encher a janela. Um modelo com um milhão de tokens anunciados não mantém a sua qualidade até ao token 999.999 e cai depois de um precipício: degrada-se de forma progressiva, e bastante cedo. O benchmark NoLiMa mediu isso com um desenho que evita o atalho dos antigos testes de « agulha no palheiro » — no NoLiMa a pergunta e o fragmento relevante quase não partilham palavras, logo o modelo não o encontra por coincidência literal e tem de inferir a associação, que é exactamente o que lhe pedes em produção.
Os resultados: o GPT-4o partia de 99,3% com contexto curto e descia a 69,7% em 32K tokens e a 56% em 128K. E não era um caso isolado: a 32K, 11 dos 13 modelos avaliados caíam para metade ou menos da sua própria linha de base em contexto curto. Fonte: NoLiMa: Long-Context Evaluation Beyond Literal Matching, Modarressi et al., arXiv, Fevereiro de 2025.
A isto soma-se um efeito de posição documentado antes e de forma independente: a precisão depende de onde está a informação dentro do contexto. O trabalho que cunhou o termo descreve uma curva em U — o modelo recupera razoavelmente bem o que está no início e no fim, e falha no que fica no meio. Fonte: Lost in the Middle: How Language Models Use Long Contexts, Liu et al., Transactions of the ACL, 2024.
Juntos, os dois efeitos descrevem o verdadeiro modo de falha da estratégia « mete-se tudo ». Não é que o modelo se recuse a responder: responde com aplomo usando o que encontrou, que não é necessariamente o que importava. A resposta chega bem escrita, bem estruturada e mal fundamentada. É o pior tipo de erro que um sistema de empresa pode ter, porque não se distingue de um acerto sem ir verificar à mão.
| O que diz o anúncio | O que mede o benchmark | O que implica para o teu sistema |
|---|---|---|
| « Janela de 1M de tokens » | A degradação começa muito abaixo desse número | O limite anunciado é capacidade de entrada, não garantia de qualidade |
| « Cabe a tua documentação inteira » | A 32K, 11 de 13 modelos caem para ≤50% da sua base (NoLiMa, 2025) | Caber não é o mesmo que ser usado |
| « O modelo encontra o que precisa » | O que está no meio do contexto é recuperado pior (Liu et al., 2024) | A ordem em que empilhas os documentos passa a ser uma variável oculta |
| « Poupas montar recuperação » | Os benchmarks não medem a factura nem a rastreabilidade | A engenharia poupada transforma-se em custo recorrente e opacidade |
O fornecedor que te vende o milhão de tokens cobra-o ao dobro
Aqui não é preciso argumentar: basta ler o tarifário de quem vende a janela grande. Na lista de preços pública da API Gemini, dois modelos têm o preço dividido por comprimento do prompt, com o corte exactamente em 200.000 tokens. No Gemini 3.1 Pro Preview, tarifa padrão, a entrada passa de 2,00 para 4,00 dólares por milhão de tokens ao cruzar esse limiar, e a saída de 12,00 para 18,00. No Gemini 2.5 Pro, de 1,25 para 2,50 na entrada e de 10,00 para 15,00 na saída. A cache de contexto também duplica. Fonte: Gemini Developer API pricing, Google, consultada a 4 de Outubro de 2026.
O relevante não é o montante, que vai mudar. É a forma do tarifário: o fornecedor que te oferece a janela enorme decidiu cobrar-te o dobro por a usares a sério. Isso é uma declaração sobre o custo real de servir esses prompts, escrita por quem o paga. Quando alguém te coloca « janela de contexto grande ou RAG » como se a primeira opção fosse a gratuita, está a ignorar que o próprio fabricante a tarifou como um produto distinto e mais caro.
E é o efeito composto que desarruma orçamentos. A recuperação concentra a despesa em montar e manter um índice: um custo que existe uma vez e se amortiza em todas as consultas. Meter tudo no prompt move essa despesa para o lado variável, onde se multiplica por cada chamada, cada dia, para sempre. Um piloto com duzentas consultas por mês não nota. O mesmo sistema aberto a trezentas pessoas, nota. A aritmética é aborrecida, e é por isso que ninguém a faz antes da reunião: multiplica os teus tokens de entrada pelo volume esperado e compara-o com o que custa um índice. O guia sobre que modelo usar num agente cobre os restantes eixos dessa decisão, porque o tamanho da janela é uma especificação entre várias e quase nunca a que decide.
A falha que não consegues depurar
Este é o argumento que não aparece em nenhum benchmark e o que sai mais caro em operação. Com recuperação, quando uma resposta sai mal tens um rasto: sabes que fragmentos foram recuperados, com que consulta e com que pontuação. O diagnóstico reduz-se a duas perguntas com resposta — o fragmento correcto estava no índice? a recuperação trouxe-o? — e cada uma aponta para uma correcção diferente: reingerir a fonte, ou afinar a recuperação.
Sem recuperação não há rasto, porque não houve selecção para registar. Passaste duzentos mil tokens e o modelo usou o que usou. Não podes saber em que se apoiou, não podes reproduzir o caminho e não podes corrigi-lo com uma intervenção delimitada: a tua única alavanca é reordenar documentos e tentar outra vez, que é depurar por superstição. Num sistema interno com tolerância alta isso é um incómodo. Num sistema que responde a clientes ou alimenta uma decisão, é a diferença entre um incidente que se fecha e um que fica aberto.
Quando a janela grande é de facto a resposta certa
Montar recuperação sobre um corpus que não precisa dela é a outra forma de errar, e é mais comum do que parece. Três situações em que a janela grande ganha limpo:
- O corpus é pequeno e estável. Se tudo o que o sistema precisa de consultar cabe folgadamente abaixo do limiar em que o modelo se degrada, e não muda todas as semanas, um índice é infra-estrutura para manter e não ganhar nada.
- A evidência está repartida por todo o documento. Quando a tarefa é sintetizar, comparar secções ou detectar contradições ao longo de um texto longo, a recuperação trabalha contra ti: fragmentar é precisamente o que destrói a relação entre as partes. Aqui o contexto longo não é um luxo, é o requisito.
- É uma análise pontual, não um sistema. Um contrato, um relatório, uma exportação de dados analisada uma vez. Ninguém deveria montar um pipeline de ingestão para uma pergunta que se faz uma só vez.
A leitura honesta da literatura recente é que o enquadramento binário está ultrapassado pelos dois lados: o contexto longo rende melhor quando a evidência está distribuída, e a recuperação rende melhor quando a evidência é escassa e tem de ser encontrada. A arquitectura que está a ganhar não escolhe: recupera para estreitar o universo ao plausível e depois usa a janela longa para raciocinar sobre esse conjunto já reduzido. A recuperação deixa de ser um filtro de precisão cirúrgica e passa a ser um redutor de ruído, o que alivia bastante os requisitos do teu índice.
O teste de dois minutos antes de atirar nada fora
Se alguém na tua equipa propõe retirar a recuperação porque saiu um modelo com mais contexto, estas quatro perguntas resolvem a conversa sem reunião de seguimento:
- Quantos tokens tem o corpus completo, hoje e dentro de doze meses? Se a resposta a doze meses cruzar o limiar em que o modelo se degrada — e está muito abaixo do limite anunciado —, a janela não é uma solução, é uma prorrogação.
- Quanto custaria o volume real de consultas a tarifa de prompt longo? Com o preço dividido nos 200K tokens, o cálculo faz-se numa folha. Fá-lo com o volume a que aspiras, não com o do piloto.
- A evidência típica está num sítio ou repartida? Pontual e localizada: recuperação. Distribuída por todo o documento: contexto longo. As duas coisas segundo a pergunta: híbrido, e é a resposta mais frequente.
- O que respondes quando um cliente pergunta de onde saiu essa frase? Se a resposta tem de ser verificável, precisas do rasto do que entrou. Isso só a selecção dá.
Nenhuma das quatro se responde com o tamanho da janela, e era precisamente isso que se queria demonstrar.
O que isto muda na operação
Há uma razão menos técnica para a proposta de atirar o RAG fora soar tão bem, e convém nomeá-la: não é que a janela grande seja melhor, é que manter um índice é trabalho contínuo e ninguém está com vontade de o fazer. O conhecimento envelhece, as fontes mudam, os documentos são substituídos, e se ninguém reingere nem invalida o caducado, o sistema começa a responder com a versão do ano passado. É essa a fenda real que o argumento do contexto infinito explora: promete livrar-te de uma função operativa, não de uma peça de software.
O problema é que a função não desaparece, apenas se torna invisível. Se meteres os documentos inteiros no prompt, continuas a precisar que esses documentos sejam os vigentes — só que agora não tens índice nem pipeline onde o verificar. Por isso a frescura da base de conhecimento é uma função contínua que se opera, não um projecto que se fecha: o refrescamento por fonte, a invalidação do caducado e o dono de cada decisão editorial existem de igual modo, com RAG ou sem ele.
E se a discussão que tens realmente aberta não é esta mas a outra — se há que retreinar o modelo com os teus dados —, está resolvida noutro sítio e com a mesma lógica: a recuperação ganha quase sempre ao fine-tuning, por custo e por capacidade de actualizar sem retreinar. As três conversas — janela, recuperação e treino — misturam-se nas mesmas reuniões, e convém tê-las separadas, porque só uma delas muda quando sai um modelo novo.
A conclusão operativa é curta. Mais contexto é uma boa notícia: deixa-te passar mais evidência relevante por chamada e alivia a precisão que exiges à tua recuperação. O que não faz é decidir o que é relevante. Esse trabalho continua a ser feito por alguém — um índice, uma consulta, uma política — ou não é feito por ninguém, e então o que tens não é uma arquitectura mais simples: é a mesma complexidade, sem registo e a tarifa dobrada.