Context Rot, RAG e Contexto Longo: Como Arquitetar Sistemas LLM em 2026

O Ano em que as Janelas de 2M Tokens Pararam de Importar

Por cerca de seis meses no final de 2024 e início de 2025, um argumento familiar circulava nos canais de Slack de engenharia: o RAG está obsoleto agora. Basta colar tudo dentro.

O raciocínio soava limpo. A Anthropic lançou o Claude Sonnet com uma janela de contexto de 1M tokens. O Google expandiu o Gemini 2.5 e o 2.5 Pro para 2M tokens. A Meta anunciou o Llama 4 Scout com um limite teórico de 10M tokens. Se a sua base de conhecimento cabe dentro de um único prompt, por que se preocupar com vector stores, pipelines de embedding e estratégias de chunking?

Então, em julho de 2025, a Chroma Research publicou "Context Rot: How Increasing Input Tokens Impacts LLM Performance", por Kelly Hong, Anton Troynikov e Jeff Huber. O artigo conduziu experimentos cuidadosos com 18 modelos de fronteira e mostrou algo que as páginas de marketing não mostravam: janelas de contexto longas se degradam de formas não óbvias muito antes de atingirem seu limite. Uma janela de 200K tokens pode mostrar perda séria de precisão com 50K tokens de entrada. Uma janela de 1M tokens não raciocina de forma confiável sobre 1M tokens.

Esse resultado reenquadrou a conversa sobre arquitetura. O RAG não está obsoleto. O contexto longo não é um almoço grátis. A pergunta interessante já não é "qual deles vence", mas "qual padrão se encaixa neste formato de dados, orçamento de latência e requisito de atualidade".

Este artigo é a resposta em nível de arquitetura: quando seu sistema deve recuperar, quando deve despejar e quando deve fazer ambos.

O Que o Artigo da Chroma Realmente Mostrou

Vale a pena ler o artigo da Chroma com cuidado, porque o título ("context rot existe") subestima o que está de fato lá. A equipe rodou versões estendidas de benchmarks needle-in-a-haystack (NIAH) em GPT-4.1, na família Claude 4 incluindo Opus 4 e Sonnet 4, Gemini 2.5 e Qwen3. O kit de replicação aberto deles no GitHub permite reproduzir as execuções.

Três descobertas se destacam.

Descoberta 1: O desempenho se degrada de forma não uniforme conforme o tamanho da entrada cresce. Este é o resultado central. Os modelos não pioram de forma lenta e previsível a uma taxa linear conforme a entrada fica mais longa. Eles batem em precipícios. Alguns modelos vão bem em 32K e colapsam em 64K. Outros se sustentam até que de repente não se sustentam mais. O tamanho da janela de contexto documentada se correlaciona fracamente com o quão bem o modelo realmente usa esse contexto.

Descoberta 2: A similaridade semântica impulsiona a degradação mais do que o comprimento. Quando a "agulha" é semanticamente distinta do "palheiro" ao redor, os modelos a encontram bem. Quando os distratores são semanticamente similares à resposta, a precisão cai acentuadamente, e a queda piora com o comprimento. Em outras palavras: quanto mais difícil for distinguir a resposta do ruído, mais rápido o contexto longo desmorona. Isso bate com um resultado separado de Liu et al. (2024), "Lost in the Middle: How Language Models Use Long Contexts" no TACL, que mostrou uma curva de desempenho em forma de U, na qual o meio de contextos longos é sistematicamente subponderado.

Descoberta 3 (a surpreendente): Texto estruturado e coerente degrada a atenção MAIS do que texto embaralhado. Este é o resultado que deveria mudar o modo como engenheiros pensam. A intuição era que um documento limpo e bem organizado de 100K tokens fosse mais fácil para um modelo raciocinar do que um amontoado bagunçado de 100K tokens. Os dados dizem o contrário, ou pelo menos, nem sempre. Texto coerente parece espalhar a atenção de forma mais difusa por uma sequência longa, enquanto texto embaralhado cria sinais locais mais distintos aos quais o modelo pode se agarrar. A implicação: alimentar o modelo com um PDF arrumado e bem formatado não é automaticamente mais seguro do que alimentá-lo com um conjunto de recuperação bagunçado.

O benchmark Sequential-NIAH (arXiv 2504.04713) estende isso ainda mais, testando se modelos conseguem encadear múltiplas recuperações de diferentes partes de um contexto longo. A queda é ainda mais íngreme para raciocínio em múltiplos passos ao longo da distância.

Hamel Husain resumiu bem a implicação prática em suas notas sobre context rot: a postura de engenharia não deveria ser "encaixar tudo dentro", deveria ser "dar ao modelo o menor contexto e mais relevante que responda à pergunta".

Por Que o Contexto Longo Falha: O Mecanismo

O mecanismo importa porque ele prevê quais cargas de trabalho vão falhar.

A atenção padrão de transformers usa um softmax sobre todos os pares de tokens. Conforme o comprimento da sequência N cresce, os pesos de atenção se espalham por mais posições. Mesmo com codificações de posição relativa como RoPE (rotary position embeddings) ou ALiBi, o denominador do softmax cresce e o peso por posição em qualquer token único encolhe. Em 1M tokens, o token "certo" precisa competir com 999.999 outros por um orçamento finito de atenção.

Codificações de posição ajudam, mas não são mágicas. O RoPE tem uma curva de degradação conhecida ao extrapolar muito além do comprimento de treinamento. Modelos treinados em sequências de até 32K tokens que são implantados em 1M tokens estão fazendo uma extrapolação que a matemática subjacente não suporta totalmente. Truques como YaRN, interpolação de posição e escalonamento ciente do NTK estendem o alcance utilizável, mas nenhum produz um modelo que use 1M tokens com a mesma eficácia com que usa 32K.

Há também um problema de dados de treinamento. Mesmo quando um modelo treina em sequências longas, exemplos que requerem raciocínio entre contextos por 800K tokens são raros. Modelos aprendem a usar as partes do contexto que os dados de treinamento ensinaram a usar.

Context rot não é um bug que o próximo lançamento vai consertar. É uma propriedade da arquitetura e da distribuição de treinamento. Modelos futuros vão empurrar os limites mais adiante, mas o padrão básico vai persistir por um tempo.

Onde o RAG Ainda Vence

Dada a existência do context rot, retrieval-augmented generation não é infraestrutura legada. Veja onde ele continua vencendo em 2026.

Corpora multi-documento em escala. Se a sua base de conhecimento tem 50.000 documentos totalizando 500M tokens, ela não cabe em nenhuma janela de contexto. Recuperação é a única arquitetura viável.

Atualidade e recência. Vector stores atualizam de forma incremental. Um prompt de contexto longo exige reconstruir o prompt toda vez que o conteúdo muda. Para documentos que atualizam a cada hora (notícias, catálogos, tickets de suporte, repositórios de código), a recuperação lida com a mudança de forma barata.

Custo. O custo de inferência escala aproximadamente de forma linear com os tokens de entrada. Enviar 200K tokens custa 200x o que 1K tokens custa. Se 95% das suas consultas podem ser respondidas com 5K tokens relevantes, a recuperação te dá uma redução de custo de 40x sem perda de precisão.

Citação e proveniência. A recuperação te dá uma lista estruturada de documentos de origem que você pode exibir, vincular e classificar. Saídas de contexto longo são mais difíceis de fundamentar em fontes específicas sem encanamento extra de extração de citações.

Controle de acesso e tenancy. Se o seu corpus tem visibilidade por usuário, por tenant ou por papel, você não pode simplesmente despejar tudo dentro. A recuperação filtra por política de acesso antes que o modelo veja os dados. Inegociável para produtos B2B.

Raciocínio multi-corpus. Quando a resposta combina uma mensagem do Slack, uma página do Notion, uma issue do Linear e um PR do GitHub, a recuperação é a ponte.

Se o seu produto se encaixa em qualquer um desses casos, o RAG não é opcional. A pergunta se torna como tornar a recuperação boa, não se deve fazê-la.

Onde o Contexto Longo Vence

O contexto longo tem cargas de trabalho nas quais é a resposta certa.

Raciocínio profundo em documento único. Ler um contrato jurídico de 100 páginas e responder a perguntas que cruzam cláusulas. Analisar um artigo de pesquisa. Resumir uma teleconferência de resultados. Quando a resposta certa conecta dois parágrafos separados por 80 páginas, a recuperação frequentemente quebra a conexão. O contexto longo a preserva.

Compreensão de código dentro de um repositório. Muitas tarefas de raciocínio sobre código precisam de imports, tipos, definições e call sites simultaneamente. Fragmentar por arquivo perde relações entre arquivos. Colocar o repositório inteiro no contexto (quando cabe) preserva a estrutura.

Continuidade conversacional. Sessões de agente de longa duração se beneficiam de histórico completo no contexto. A recuperação sobre o histórico de conversa é frágil: você frequentemente precisa dos últimos 50 turnos, não dos 50 turnos semanticamente mais similares.

Raciocínio exploratório quando você não conhece a consulta. Se você não tem certeza do que perguntar a um documento até começar a raciocinar sobre ele, a recuperação é difícil de usar. Você não consegue escrever a consulta de antemão. O contexto longo permite que o modelo navegue pelo material.

Referência cruzada dentro de uma unidade coerente. Um capítulo de livro, um artigo de pesquisa, uma peça jurídica: estes são logicamente unificados. Fragmentar e remontar frequentemente perde a estrutura do argumento.

Heurística aproximada: se os seus dados são um único documento lógico e ele cabe, o contexto longo é a arquitetura mais limpa.

O Padrão Híbrido que Realmente Funciona

O padrão de 2026 para sistemas LLM sérios não é nem RAG puro nem contexto longo puro. É híbrido: recupere um conjunto substancial mas limitado de tokens, depois raciocine sobre eles com contexto longo.

Aqui está o fluxo canônico:

User query
   |
   v
[Retrieval Stage]
   - Vector search (top 100 chunks)
   - Optional keyword/BM25 search merged in (hybrid retrieval)
   - Optional reranker (cross-encoder over top 100, keep top 30)
   |
   v
[Assembly Stage]
   - Concatenate retrieved chunks
   - Add metadata, source headers, structural hints
   - Target total: 50K to 200K tokens
   |
   v
[Long-Context Reasoning Stage]
   - Send to frontier model with reasoning prompt
   - Model uses the full retrieval set as its context
   |
   v
Answer + citations

Por que isso funciona: cada estágio lida com o modo de falha do outro. A recuperação reduz um corpus que é grande demais para qualquer janela de contexto a um conjunto gerenciável. O raciocínio de contexto longo sobre o conjunto recuperado restaura o raciocínio multi-documento e multi-chunk que o RAG puro frequentemente quebra quando envia apenas os 5 chunks mais relevantes.

A decisão chave de engenharia é o tamanho do conjunto de recuperação. Envie poucos tokens demais e você perde o benefício do contexto longo (poderia muito bem fazer RAG clássico top-5). Envie tokens demais e você dispara o context rot. Os dados da Chroma sugerem que o teto seguro está bem abaixo do limite documentado do modelo, frequentemente em 4x a 10x. Um modelo de janela de 200K geralmente é sólido até 40K a 80K. Um modelo de janela de 1M pode frequentemente lidar com 150K a 300K com rot mínimo.

Este é o padrão de arquitetura no qual a maioria das equipes que entregam funcionalidades LLM em escala convergiu até o final de 2025. Não é glamoroso, mas funciona.

Ajustando o Híbrido: Números e Heurísticas

Deixe-me colocar números nos botões. Estas não são verdades universais; são pontos de partida que funcionam em produção para muitas equipes.

Tamanho do chunk. 500 a 1.500 tokens por chunk para a maior parte da prosa. 200 a 500 para código (por função ou por bloco lógico). 1.500 a 3.000 para texto jurídico ou acadêmico onde o contexto dentro de um chunk importa. Sobreponha os chunks em 10 a 20 por cento.

Recuperação top-k. Puxe mais do que você vai enviar. Recupere os top 50 a 200, depois faça rerank. O reranker (um cross-encoder, frequentemente um modelo pequeno especializado como o Cohere Rerank ou um reranker BGE com fine-tune) custa mais por par do que o modelo de embedding, mas é dramaticamente mais preciso em relevância de granularidade fina.

Razão rerank-para-contexto. Após o rerank, mantenha os top 20 a 100 chunks para o estágio de contexto longo. O número exato depende do tamanho do chunk e do seu orçamento de contexto seguro.

Recuperação híbrida. Combine recuperação densa (vetor) e esparsa (BM25, SPLADE) com fusão recíproca de ranking. Densa pura erra consultas de correspondência exata (SKUs, códigos de erro, nomes próprios). Esparsa pura erra paráfrases. A híbrida captura ambas.

Orçamento de contexto seguro. Teste o seu modelo. Construa um pequeno conjunto de avaliação de perguntas cuja resposta exige raciocínio entre múltiplos chunks em diferentes tamanhos de contexto. Meça a precisão em 16K, 32K, 64K, 128K, 256K tokens de contexto preenchido. Escolha o maior tamanho onde a precisão ainda é aceitável. Esse é o seu orçamento seguro. Fique 20 por cento abaixo dele em produção para ter uma margem.

Pular a recuperação totalmente. "Resuma o documento que acabei de enviar" é uma tarefa de documento único. Detecte essas consultas com um pequeno classificador e pule a recuperação; economiza latência e evita trazer à tona ruído não relacionado.

Camada de sumarização. Para históricos muito longos (conversas de vários meses, grandes bases de código), intercale um passo de sumarização que comprime material mais antigo antes da montagem. Resumos também custam tokens, então teste se eles ajudam.

Aqui está uma tabela de comparação que captura os tradeoffs:

Eixo	RAG Puro (top-5 chunks)	Contexto Longo Puro	Híbrido (recuperar 50K-200K, depois raciocinar)
Formato dos dados	Muitos docs, corpus amplo	Um doc ou conjunto pequeno	Muitos docs, raciocínio profundo
Tamanho típico de entrada	2K-10K tokens	100K-2M tokens	50K-200K tokens
Latência	Rápida	Lenta	Média
Custo por consulta	Baixo	Alto	Médio
Precisão em escala	Boa se o top-k estiver certo	Degrada com rot	Melhor para consultas complexas
Atualidade	Fácil (atualizar índice)	Difícil (reconstruir prompt)	Fácil (atualizar índice)
Citação	Nativa	Requer trabalho extra	Nativa (via conjunto recuperado)
Controle de acesso	Nativo (filtra na recuperação)	Difícil	Nativo
Raciocínio em doc único	Frequentemente quebra	Forte	Forte
Raciocínio entre docs	Limitado (apenas top-k)	N/A a menos que seja um doc	Forte

Antipadrões que Engenheiros Continuam Entregando

Algumas armadilhas se repetem com frequência suficiente para serem destacadas.

"Apenas despeje tudo no contexto". Tentador após cada lançamento que dobra a janela. Os dados da Chroma dizem que isso se degrada silenciosamente. Você vai passar em verificações pontuais e falhar em produção em consultas que precisam de raciocínio entre contextos. Sempre execute uma avaliação no seu tamanho de contexto alvo antes de entregar.

"Sempre use RAG". RAG reflexivo para toda carga de trabalho perde casos de documento único. Colocar um PDF de 50 páginas em um índice vetorial e depois recuperar os top-5 chunks geralmente produz uma resposta pior do que alimentar o PDF inteiro ao modelo. Heurística: se um único documento cabe no seu orçamento de contexto seguro e a consulta é sobre esse documento, pule a recuperação.

"Ignorar a contagem de tokens do conjunto de recuperação". Equipes definem o top-k como "quantos couberem" e descobrem três meses depois que o prompt médio é de 350K tokens e a precisão se degradou silenciosamente. Acompanhe o tamanho do contexto montado como uma métrica de primeira classe. Configure alertas para ele.

"Confiar na janela documentada". Uma janela de 1M tokens não significa que o modelo usa 1M tokens igualmente bem. O limite documentado é o que você pode tecnicamente enviar. O limite utilizável é onde o modelo ainda performa no seu padrão de qualidade. São números diferentes, frequentemente por uma ordem de magnitude.

"Pular avaliações porque o modelo é bom agora". Atualizações de modelos de fronteira mudam a escolha ótima de arquitetura. Uma carga de trabalho que precisava de RAG no GPT-4-32K pode ir bem com contexto longo no Gemini 2.5 Pro. Reavalie quando os modelos mudam.

O Que o Hardware de 2026 Muda

Janelas maiores realmente deslocam algumas decisões. Ser específico sobre quais é o que importa.

Llama 4 Scout em 10M tokens. Se o contexto utilizável for até mesmo metade do limite documentado, corpora inteiros de tamanho médio cabem em um único prompt. Assistentes single-tenant sobre uma base de conhecimento interna de 1M tokens podem pular a recuperação. A economia importa, no entanto: 5M tokens de entrada em um modelo de fronteira é caro por consulta.

Gemini 2.5 / 3 Pro em 2M tokens. Uma janela de 2M com cache de prompt desloca o cálculo para fluxos de trabalho que consultam repetidamente o mesmo grande conjunto de documentos. Faça cache de 1,5M tokens de contexto de fundo, pague apenas pela consulta marginal, e o custo por consulta começa a competir com a recuperação.

Claude Sonnet 1M. Útil para cargas de trabalho agênticas onde o estado da sessão cresce muito. Agentes conversacionais que tinham de resumir ou fazer RAG sobre seu próprio histórico agora podem manter mais histórico bruto no contexto.

Cache de prompt entre fornecedores. Anthropic, Google e OpenAI todos suportam cache de entrada. Arquiteturas de contexto longo ficam muito mais baratas para consultas repetidas contra conteúdo estável. A vantagem de custo do RAG encolhe quando o cache entra em ação, embora não desapareça.

O que não mudou: context rot. Nenhum desses lançamentos inclui dados de benchmark mostrando que janelas maiores resolvem o problema do rot. Janelas maiores elevam o teto, mas o mesmo formato de degradação persiste. Você ainda precisa medir o seu orçamento seguro. Você ainda precisa de recuperação para cargas de trabalho frescas, multi-tenant e multi-fonte. O híbrido continua sendo o padrão certo.

Um Framework de Decisão que Você Pode Realmente Aplicar

Aqui está um fluxo que você pode aplicar a qualquer nova funcionalidade LLM. Percorra-o de cima para baixo.

Passo 1: Quão grande é o seu corpus?

Abaixo de 100K tokens no total: pule a recuperação, use contexto longo diretamente.
100K a 1M tokens: depende da atualidade (vá para o Passo 2).
Acima de 1M tokens: a recuperação é obrigatória.

Passo 2: Quão fresca os dados precisam ser?

Atualizações por hora ou mais rápidas: recuperação. Prompts de contexto longo são caros demais para reconstruir.
Atualizações por dia ou semana: qualquer padrão funciona.
Estático ou raramente atualizado: contexto longo com cache de prompt é barato e limpo.

Passo 3: Qual é o formato da consulta?

Raciocínio profundo em documento único: pendendo para contexto longo.
Síntese multi-documento: pendendo para híbrido.
Lookup ou recuperação de fatos: pendendo para RAG clássico (top-k, contexto pequeno).
Exploratório ou aberto: pendendo para contexto longo se o conjunto de documentos for limitado; caso contrário, híbrido.

Passo 4: Você precisa de citação ou controle de acesso?

Sim para qualquer um: recuperação é obrigatória (seja RAG clássico ou híbrido). Arquiteturas apenas de contexto longo são muito difíceis de adaptar com citações e filtragem por usuário.

Passo 5: Qual é o seu orçamento de latência?

Abaixo de 1 segundo: RAG clássico (contexto pequeno, rápido).
1 a 5 segundos: híbrido é viável.
Acima de 5 segundos: qualquer padrão funciona.

Passo 6: Qual é o seu piso de precisão em consultas longas?

Alta precisão em raciocínio multi-passo sobre 50K+ tokens: híbrido com um reranker.
Melhor esforço: RAG clássico geralmente é suficiente.

Percorra esses seis passos e você vai aterrissar em uma de três arquiteturas: RAG top-k clássico, contexto longo puro ou híbrido. A maioria dos sistemas de produção para cargas de trabalho sérias aterrissa no híbrido. Não porque o híbrido seja universalmente melhor, mas porque cargas de trabalho reais geralmente têm pelo menos uma restrição (dados multi-tenant, atualidade, custo, citação) que quebra o contexto longo puro, e pelo menos uma (raciocínio em doc único, consultas entre contextos, exploração) que quebra o RAG top-k puro.

O artigo da Chroma mudou o discurso. Ele fez o argumento de contexto longo versus RAG parecer um pouco constrangedor em retrospecto. Eles não são concorrentes; são dois dos três componentes de uma stack LLM funcional, e o terceiro (reranking) é o que torna o híbrido estável.

Perguntas Frequentes

A janela de contexto de 2M do Gemini matou o RAG?

Não. A janela de 2M tokens é real, mas o artigo "Context Rot" da Chroma demonstrou que o desempenho se degrada muito antes da janela encher. Orçamentos práticos de contexto seguro para modelos de janela de 2M tendem a ficar em 150K a 400K tokens para cargas de trabalho de alta precisão, o que é muito menos do que o limite anunciado. O RAG (ou o padrão híbrido recuperar-então-raciocinar) continua sendo a arquitetura certa para corpora grandes, multi-documento, frescos ou multi-tenant.

O que é context rot em termos simples?

Context rot é a observação de que LLMs usam contexto longo pior do que os materiais de marketing sugerem. Conforme você alimenta mais tokens, a precisão em tarefas de recuperação e raciocínio se degrada de forma não linear. Piora mais rápido quando o texto distrator é semanticamente similar à resposta, e até mesmo entrada coerente e bem estruturada pode prejudicar a atenção mais do que entrada embaralhada. O resultado: encher uma janela de 1M tokens não te dá uma resposta de qualidade de 1M tokens.

Quão grande deve ser o meu conjunto de recuperação antes que o context rot entre em ação?

Teste o seu modelo específico. Um ponto de partida aproximado: fique em 20 a 40 por cento da janela de contexto documentada para cargas de trabalho de alta precisão. Para um modelo de janela de 200K, isso é de 40K a 80K tokens de recuperação. Para um modelo de janela de 1M, 200K a 400K. Construa um pequeno conjunto de avaliação de perguntas de raciocínio multi-hop e meça a precisão em diferentes tamanhos de contexto. Escolha o maior tamanho em que a precisão ainda esteja na sua faixa de qualidade.

O cache de prompt muda o cálculo?

Sim, de forma significativa. O cache de prompt (disponível em Anthropic, Google e OpenAI) torna o custo marginal de consultas de contexto longo contra conteúdo estável muito mais barato. Se você pode fazer cache de um grande conjunto de documentos de fundo e pagar apenas pelo delta por consulta, o contexto longo se torna economicamente competitivo com a recuperação para corpora mais ou menos estáticos. O cache, no entanto, não conserta o context rot: contexto longo em cache ainda é contexto longo, com a mesma degradação de precisão.

Devo usar um reranker antes de enviar ao contexto longo?

Para a maioria dos sistemas híbridos de produção, sim. Um reranker (modelo cross-encoder que pontua pares consulta-documento) sobre os seus top 50 a 200 chunks recuperados melhora dramaticamente a relevância do que você passa ao estágio de contexto longo. Pular o rerank frequentemente significa enfiar mais tokens para compensar a precisão mais baixa, o que te empurra para a zona de rot. O rerank é uma das melhorias de maior alavancagem que você pode fazer em um pipeline híbrido.

Considerações Finais

A coisa sedutora sobre cada novo lançamento de modelo com uma janela maior é a promessa implícita: "pare de fazer engenharia, apenas despeje". O artigo da Chroma colocou números concretos sobre o porquê dessa promessa não ter sido entregue, e a matemática subjacente (diluição do softmax, extrapolação de codificação de posição, distribuição de treinamento) sugere que ela não será entregue de forma limpa mesmo quando as janelas de contexto crescerem para 100M tokens.

O que nos resta é a resposta chata e produtiva. Construa recuperação. Ajuste-a. Adicione um reranker. Escolha um orçamento de contexto seguro medindo, não confiando na ficha técnica. Envie ao modelo o menor conjunto de tokens mais relevante que de fato contém a resposta. Deixe-o raciocinar sobre isso. Cite as fontes.

Isso é menos empolgante do que "a AGI está aqui, basta colar a sua base de código", mas entrega funcionalidades que funcionam em produção. As equipes que silenciosamente constroem bons produtos LLM em 2026 são as que trataram a narrativa de contexto longo com ceticismo e a narrativa de RAG com o mesmo ceticismo, e acabaram com pipelines híbridos que lidam com as cargas de trabalho que realmente têm.

Decisões de arquitetura sobrevivem aos lançamentos de modelos. Acerte essas e a próxima atualização de modelo será uma melhoria grátis em vez de uma reescrita forçada.