O que é context rot em LLMs
Context rot é a tendência medida de um modelo de linguagem grande usar a informação cada vez pior conforme a entrada fica mais longa, bem antes de a janela de contexto encher. A Chroma Research colocou números nisso em 18 modelos de fronteira em julho de 2025, e os trabalhos seguintes, ao longo de 2026, aguçaram o achado em vez de amolecê-lo. Um modelo anunciado com 1M tokens não raciocina sobre 1M tokens com a qualidade que demonstra em 30K.
A versão prática, para quem precisa decidir o que construir: a janela de contexto documentada é o que você tem permissão de enviar. Sua janela utilizável é onde o modelo ainda alcança a sua barra de qualidade. São números diferentes, e o segundo costuma ser uma fração do primeiro.
Essa diferença é o motivo de o argumento que circulou pelos canais de engenharia no fim de 2024 e no início de 2025 ("RAG está obsoleto agora, é só colar tudo lá dentro") ter envelhecido mal. As janelas realmente chegaram. A Anthropic entrega 1M tokens no Claude Opus 5 e no Claude Sonnet 5. A família GPT-5.6 da OpenAI carrega cerca de 1.05M. O Gemini 3.1 Pro do Google carrega 1M. O Llama 4 Scout da Meta documenta 10M. O que não chegou foi um modelo que use tudo isso bem.
Então a pergunta interessante deixou de ser "qual dos dois vence" e virou "qual padrão serve para este formato de dado, este orçamento de latência, este requisito de frescor e esta conta". É isso que o resto deste texto responde.
O que a pesquisa de context rot da Chroma mostrou
A manchete ("context rot existe") não faz jus ao trabalho. Em Context Rot: How Increasing Input Tokens Impacts LLM Performance, publicado em 14 de julho de 2025, Kelly Hong, Anton Troynikov e Jeff Huber conduziram experimentos controlados em 18 modelos, incluindo a família Claude 4 mais o Claude 3.7 e o 3.5, o o3, a família GPT-4.1, o GPT-4o, o GPT-4 Turbo, o Gemini 2.5 Pro e o Flash, e três tamanhos do Qwen3. O kit de replicação deles no GitHub permite rodar tudo de novo.
Quatro achados importam para a arquitetura.
O desempenho se degrada de forma não uniforme conforme a entrada cresce. Se você veio aqui atrás do gráfico do context rot, o formato é o ponto: não é uma ladeira linear suave. A precisão se mantém, depois despenca de um penhasco, e o penhasco fica num lugar diferente para cada modelo. Plote e você terá uma descida serrilhada, não uma rampa, e é exatamente por isso que uma verificação pontual em um tamanho de contexto diz quase nada sobre o comportamento em outro.
O tamanho da queda é grande. No LongMemEval, um benchmark de perguntas e respostas conversacionais, o time reduziu o conjunto a 306 prompts e comparou duas versões de cada um. A versão focada contém apenas o material relevante e tem em média cerca de 300 tokens. A versão completa enterra a mesma resposta na conversa ao redor e tem em média cerca de 113k tokens. Os modelos lidaram bem com os prompts focados e se degradaram de forma consistente nos completos. A diferença varia bastante conforme o modelo, e a Chroma observou que os modelos Claude apresentaram a versão mais pronunciada dela. Mesma pergunta, mesmo modelo, mesma resposta presente na entrada. A única mudança foi quanto texto irrelevante veio junto.
A similaridade semântica dirige a degradação mais do que o comprimento. Quando a "agulha" é fácil de distinguir do "palheiro", os modelos a encontram. Quando os distratores se parecem semanticamente com a resposta, a precisão cai com força, e a queda aumenta com o comprimento. Até um único distrator reduz o desempenho em relação à linha de base só com a agulha, e quatro deles se acumulam. Isso bate com Liu et al. (2024), "Lost in the Middle," in TACL, que encontrou uma curva em U na qual o meio de um contexto longo é sistematicamente subponderado.
Texto estruturado e coerente degrada a atenção mais do que texto embaralhado. Este é o resultado que deveria mudar a forma como os engenheiros pensam. A intuição diz que um documento limpo de 100K tokens é mais fácil de processar do que um bagunçado. A Chroma encontrou o oposto, de forma consistente, nos 18 modelos: embaralhar o palheiro e destruir seu fluxo lógico melhorou o desempenho. Por que isso acontece continua em aberto, e a Chroma vai só até dizer que a estrutura de uma entrada poderia influenciar como a atenção é aplicada. A parte acionável não precisa de mecanismo: um PDF arrumadinho e bem formatado não é automaticamente a opção segura.
Mais um detalhe para levar para produção: os modos de falha são específicos de cada modelo. Sob distratores, os modelos Claude apresentaram as menores taxas de alucinação e tenderam a se abster quando incertos, enquanto os modelos GPT apresentaram as maiores e tenderam a responder com confiança, e de forma errada. Se você está escolhendo entre eles, está em parte escolhendo qual falha prefere depurar.
| O que você muda | O que acontece com a precisão | O que isso significa para o seu pipeline |
|---|---|---|
| A entrada cresce de ~300 para ~113k tokens | Degradação consistente no LongMemEval | Contexto irrelevante não é enchimento grátis |
| A agulha se parece com o palheiro | Queda acentuada, que piora com o comprimento | Reordene por precisão, não apenas some tokens |
| Um distrator adicionado | Queda mensurável em relação à linha de base | Corte os quase acertos antes da montagem |
| Palheiro embaralhado vs coerente | O embaralhado pontuou melhor nos 18 modelos | Formatação limpa não é margem de segurança |
| Modelo trocado sob distratores | Claude se abstém, GPT alucina | Escolha o modo de falha que você consegue detectar |
O benchmark Sequential-NIAH (arXiv 2504.04713) pressiona a mesma costura por outro ângulo, testando se os modelos conseguem extrair agulhas que precisam voltar na ordem certa. Em seis LLMs, com contextos de 8K a 128K, o melhor modelo chegou a 63.5 por cento. Recuperação em vários passos ao longo da distância é mais difícil do que as demonstrações de agulha única sugerem.
Para uma porta de entrada mais leve, Hamel Husain recebeu Kelly Hong para percorrer a pesquisa e publicou um resumo anotado dessa conversa. As conclusões batem com as do relatório: o desempenho não é uniforme entre os comprimentos de contexto, a forma como você apresenta a informação importa, e a engenharia de contexto deliberada é a alavanca.
Por que o contexto longo falha: o mecanismo
O mecanismo importa porque ele prevê quais cargas de trabalho quebram.
A atenção do Transformer roda um softmax sobre pares de tokens. Conforme o comprimento da sequência cresce, a atenção se espalha por mais posições. Mesmo com codificações de posição relativa como RoPE ou ALiBi, o denominador do softmax cresce e o peso disponível para qualquer token individual encolhe. Em 1M tokens, o token certo compete com outros 999,999 por um orçamento finito.
As codificações de posição esticam o alcance sem remover o problema. O RoPE se degrada ao extrapolar muito além do comprimento de treinamento, então um modelo treinado em sequências de 32K e implantado em 1M está fazendo uma extrapolação que a matemática por baixo não sustenta totalmente. YaRN, interpolação de posição e escalonamento consciente de NTK ajudam, e nenhum deles produz um modelo que use 1M tokens tão bem quanto usa 32K.
Há também um problema de dados de treinamento. Mesmo quando um modelo treina em sequências longas, exemplos que exigem raciocínio genuíno ao longo de 800K tokens são raros. Os modelos aprendem a usar as partes do contexto que os dados de treinamento os ensinaram a usar.
Portanto, o context rot é uma propriedade da arquitetura e da distribuição de treinamento, e não um bug que a próxima versão corrige. Modelos futuros vão empurrar a fronteira mais para frente, e o formato da degradação vai persistir.
Terminação prematura: o que a pesquisa de 2026 acrescentou
O resultado novo mais útil desde a primeira publicação deste artigo veio do trabalho com agentes de horizonte longo, e não de trabalho com benchmarks.
Em Diagnosing and Mitigating Context Rot in Long-horizon Search (junho de 2026), Shijie Xia, Yikun Wang, Zhen Huang e Pengfei Liu estudaram quatro modelos de ponta em três benchmarks e nomearam um modo de falha que a literatura anterior tinha pulado: a terminação prematura. Sob um contexto grande, os modelos desistem, ou devolvem uma resposta errada e incerta, muito antes de esgotarem a janela. Controlando pela dificuldade da consulta, eles descobriram que a taxa de terminação prematura sobe com o comprimento do contexto.
Isso reenquadra o problema. Context rot cobre duas falhas diferentes, e elas pedem correções opostas. Se o modelo não consegue mais encontrar a agulha, melhore a precisão. Se o modelo para de procurar, ele precisa de espaço e de motivo para continuar explorando. Para um agente que faz busca em vários passos, confundir as duas custa semanas.
O segundo achado deles é o que vale roubar. Eles analisaram sete métodos de gerenciamento de contexto em três categorias e concluíram que esses métodos funcionam principalmente como estratégias de escalonamento em tempo de teste: ao cortar a taxa de terminação prematura, eles compram mais exploração para o modelo. Compactação e poda se pagam como recursos de precisão, não apenas como controles de custo. Os autores também construíram uma estratégia de filtragem consciente do comportamento para amostragem paralela e mediram um ganho de 2.6 a 4.9 por cento em três métodos de agregação.
Se você roda agentes em sessões longas, acompanhe com que frequência os seus desistem cedo. É uma métrica barata e quase ninguém a instrumenta.
Onde o RAG ainda vence
Diante de tudo isso, a geração aumentada por recuperação continua merecendo seu lugar. Eis onde ela segue vencendo.
Corpora de vários documentos em escala. Se a sua base de conhecimento tem 50,000 documentos somando 500M tokens, ela não cabe em janela nenhuma. Recuperação é a única arquitetura viável.
Frescor e atualidade. Bancos vetoriais atualizam de forma incremental. Um prompt de contexto longo precisa ser reconstruído sempre que o conteúdo muda. Para qualquer coisa que se atualize de hora em hora (notícias, catálogos, tíquetes de suporte, código), a recuperação lida com a mudança de forma barata.
Custo. O custo de entrada escala com os tokens de entrada e, acima de certos limiares, escala pior do que linearmente. Se 95 por cento das suas consultas podem ser respondidas a partir de 5K tokens relevantes, a recuperação sai várias vezes mais barata sem perda de precisão.
Citação e proveniência. A recuperação te entrega uma lista estruturada de fontes que você pode exibir, linkar e ordenar, enquanto ancorar uma resposta de contexto longo em fontes específicas exige encanamento extra. É a mesma razão pela qual uma ferramenta de leitura que guarda a passagem e a sua fonte vence uma que guarda um resumo: quando você faz perguntas sobre tudo o que salvou no Glasp, cada resposta pode apontar de volta para o destaque de onde ela veio.
Controle de acesso e multi-inquilino. Se o seu corpus tem visibilidade por usuário, por inquilino ou por papel, você não pode despejar tudo. A recuperação filtra por política antes de o modelo ver qualquer coisa. Isso é inegociável em B2B.
Raciocínio entre corpora. Quando a resposta atravessa uma thread do Slack, uma página do Notion, uma issue do Linear e um PR do GitHub, a recuperação é a ponte.
Se qualquer um desses casos se aplica, o RAG não é opcional. A pergunta passa a ser como tornar a recuperação boa, e não se você deve fazê-la.
Onde o contexto longo vence
O contexto longo tem cargas de trabalho em que ele é simplesmente a resposta certa.
Raciocínio profundo em um único documento. Ler um contrato de 100 páginas e responder cruzando cláusulas. Analisar um artigo. Percorrer uma teleconferência de resultados. Quando a resposta conecta dois parágrafos separados por 80 páginas, o chunking costuma cortar o elo.
Compreensão de código dentro de um repositório. Boa parte das tarefas de código precisa de imports, tipos, definições e pontos de chamada ao mesmo tempo. Fatiar por arquivo perde as relações entre arquivos.
Continuidade conversacional. Sessões longas de agente se beneficiam de um histórico de verdade. Recuperação sobre histórico de conversa é frágil, porque em geral você precisa dos últimos 50 turnos, e não dos 50 semanticamente mais parecidos.
Raciocínio exploratório quando você ainda não sabe a consulta. Se você não consegue escrever a consulta com antecedência, fica difícil mirar a recuperação. O contexto longo deixa o modelo navegar.
Referência cruzada dentro de uma unidade coerente. Um capítulo de livro-texto, um artigo, uma petição jurídica. Fatiar e remontar essas coisas tende a perder o argumento.
Heurística grosseira: se os seus dados são um único documento lógico e cabem dentro do seu orçamento seguro medido, o contexto longo é a arquitetura mais limpa.
O padrão híbrido em que a maioria dos times acaba
O padrão de 2026 para sistemas sérios não é nem RAG puro nem contexto longo puro. Recupere um conjunto substancial, mas limitado, de tokens, e então raciocine sobre eles.
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
Cada estágio cobre o modo de falha do outro. A recuperação reduz a algo administrável um corpus grande demais para qualquer janela. Raciocinar sobre todo o conjunto recuperado restaura o raciocínio entre chunks que o RAG clássico de top-5 joga fora.
A decisão que sustenta tudo é o tamanho do conjunto recuperado. Poucos tokens demais e você só reconstruiu o RAG de top-5. Tokens demais e você está na zona de apodrecimento, pagando mais por uma resposta pior. Uma regra prática que funciona, e que a próxima seção transforma em medição: planeje um orçamento seguro em torno de 20 a 40 por cento da janela documentada e depois verifique isso nos seus próprios dados. Para um modelo com janela de 200K, são 40K a 80K. Para um modelo com janela de 1M, são 200K a 400K, que, por coincidência, é mais ou menos onde a cobrança muda.
Ajustando o híbrido: números e heurísticas
Estas não são verdades universais. São pontos de partida que se sustentam em produção.
Tamanho do chunk. De 500 a 1,500 tokens para prosa. De 200 a 500 para código, por função ou bloco lógico. De 1,500 a 3,000 para texto jurídico ou acadêmico, em que o contexto interno ao chunk carrega significado. Sobreponha de 10 a 20 por cento.
Recuperação top-k. Puxe mais do que você vai enviar. Recupere os 50 a 200 melhores e depois reordene. Um cross-encoder custa mais por par do que um modelo de embedding e é dramaticamente melhor em relevância de granularidade fina.
Proporção entre rerank e contexto. Fique com os 20 a 100 melhores chunks depois do rerank. O número exato decorre do tamanho do chunk e do seu orçamento seguro.
Recuperação híbrida. Combine denso e esparso (BM25, SPLADE) com fusão recíproca de rankings (RRF). Denso sozinho perde correspondências exatas como SKUs, códigos de erro e nomes próprios. Esparso sozinho perde paráfrases.
Dois desses parâmetros merecem mais do que um marcador, porque é neles que os times perdem precisão sem perceber.
O primeiro é o seu orçamento de contexto seguro, e a única forma honesta de defini-lo é medir. Monte um pequeno conjunto de avaliação com perguntas que exijam raciocínio sobre vários chunks e então pontue a precisão com 16K, 32K, 64K, 128K e 256K de contexto empilhado. Pegue o maior tamanho que ainda passa da sua barra e opere 20 por cento abaixo dele para ter folga. Esse número medido deve cair perto da regra de 20 a 40 por cento acima e, quando não cair, confie na sua avaliação em vez da heurística.
O segundo é o que acontece quando você troca de modelo, e foi isso que mordeu vários times em 2026. O tokenizador da Anthropic mudou com o Claude Opus 4.7, e o mesmo texto agora mapeia para algo entre 1.0 e 1.35 vezes mais tokens dependendo do conteúdo, o que a Anthropic resume como cerca de 30 por cento a mais. Seus documentos não cresceram. Seu orçamento encolheu. Se você fixou um teto de tokens um ano atrás e trocou o modelo por baixo dele, aquele teto significa outra coisa agora, e nada nos seus logs vai avisar.
Pule a recuperação por completo quando a consulta pedir isso. "Resuma o documento que acabei de enviar" é uma tarefa de documento único. Detecte esses casos com um classificador pequeno, pule a recuperação, economize latência e evite trazer ruído sem relação.
Camadas de sumarização e poda. Para históricos muito longos, comprima o material mais antigo antes da montagem. Resumos também custam tokens, então meça se eles de fato ajudam.
| 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 da entrada | 2K-10K tokens | 100K-1M tokens | 50K-200K tokens |
| Latência | Rápida | Lenta | Média |
| Custo por consulta | Baixo | Alto, e pior depois do penhasco de preço | Médio |
| Precisão em escala | Boa se o top-k estiver certo | Degrada com o apodrecimento | Melhor para consultas complexas |
| Frescor | Fácil (atualizar o índice) | Difícil (reconstruir o prompt) | Fácil (atualizar o índice) |
| Citação | Nativa | Exige trabalho extra | Nativa (via conjunto recuperado) |
| Controle de acesso | Nativo (filtrar na recuperação) | Difícil | Nativo |
| Raciocínio em doc único | Costuma quebrar | Forte | Forte |
| Raciocínio entre docs | Limitado (só o top-k) | N/D a menos que seja um doc | Forte |
Antipadrões que os engenheiros continuam entregando
Algumas armadilhas se repetem com frequência suficiente para merecerem nome.
"É só jogar tudo no contexto." Tentador depois de cada lançamento que dobra a janela. A degradação é silenciosa, então você passa nas verificações pontuais e falha em produção exatamente nas consultas que precisavam de raciocínio entre contextos. Rode uma avaliação no seu tamanho alvo antes de entregar.
"Sempre use RAG." Recuperação reflexa perde os casos de documento único. Indexar um PDF de 50 páginas e puxar os 5 melhores chunks costuma ser melhor do que nada e perde para simplesmente enviar o PDF.
"Ignore a contagem de tokens montada." Os times definem o top-k como "o que couber" e três meses depois descobrem que o prompt médio deles tem 350K tokens, que a precisão escorregou em silêncio e que a conta dobrou num limiar que ninguém leu. Trate o tamanho do contexto montado como métrica de primeira classe e configure alertas para ele.
"Confie na janela documentada." O limite documentado é o que você pode enviar. O limite utilizável é onde a qualidade se mantém. São números diferentes, e só um deles está na ficha técnica.
"Pule as avaliações porque o modelo agora é bom." Trocas de modelo mudam qual arquitetura é a certa e, às vezes, mudam a sua contabilidade de tokens por baixo. Reavalie quando os modelos mudarem.
"Suponha que uma falha silenciosa é uma falha segura." Sob distratores, alguns modelos alucinam e outros se abstêm, e em trabalho de horizonte longo alguns simplesmente param cedo. Saiba qual é o caso do seu, e instrumente para isso.
O que mudou em 2026: janelas, preços e compactação
Duas coisas mudaram desde a primeira versão deste artigo, e as duas apontam para o mesmo lado.
O contexto longo agora tem um penhasco de preço publicado, em dois fornecedores. A OpenAI cobra a família GPT-5.6 em dois medidores. Abaixo do limiar, o GPT-5.6 Sol custa $4 por milhão de tokens de entrada e $20 por milhão de saída. Acima dele, o mesmo modelo custa $8 e $30. O Terra vai de $2/$12 para $4/$18, e o Luna de $0.20/$1.20 para $0.40/$1.80. O limiar fica em 272K tokens de entrada, e cruzá-lo reprecifica a requisição inteira, não apenas o excedente. Um prompt de 272,001 tokens cobra cada um desses tokens pela tarifa mais alta. Contra uma janela anunciada de 1.05M tokens, isso é mais ou menos um quarto dela pelo preço anunciado.
O Google faz a mesma coisa num limiar mais baixo. O Gemini 3.1 Pro custa $2 por milhão de entrada e $12 por milhão de saída para prompts de até 200K tokens, e depois $4 e $18 acima disso. Mesma estrutura de 2x na entrada e 1.5x na saída, 72K tokens antes. Se você dimensionou o seu pipeline contra o penhasco da OpenAI e depois trocou de fornecedor, dá para passar direto pelo do Google sem mudar uma linha de código.
Dois fornecedores independentes precificando contexto longo como item premium é evidência mais forte do que qualquer um deles sozinho. Isso transforma um argumento de qualidade em um argumento de orçamento: ficar abaixo do seu orçamento de contexto seguro já era a jogada que preservava a precisão, e agora também é a diferença entre uma conta e duas.
Os fornecedores entregam gerenciamento de contexto como recurso de produto. A compactação da Anthropic resume o contexto anterior no servidor conforme a conversa cresce. Ela é opcional em vez de ligada por padrão, mas, uma vez habilitada, o limiar de disparo assume 150K tokens por padrão em modelos cuja janela é de 1M. Leia de novo: o fornecedor com uma janela de um milhão de tokens define o próprio padrão em 15 por cento dela. A Anthropic também entrega a edição de contexto, que limpa resultados antigos de ferramentas ou blocos de raciocínio em vez de resumi-los. Dois mecanismos diferentes, a mesma admissão por baixo.
O cache de prompt é a alavanca de custo de verdade, e ela é real: leituras de entrada em cache custam cerca de um décimo do preço normal de entrada nas duas principais APIs. O cache torna consultas repetidas sobre conteúdo estável muito mais baratas. Ele não resolve o context rot e, na OpenAI, também não te isenta da faixa de contexto longo.
| Modelo | Janela documentada | Ressalva prática |
|---|---|---|
| Claude Opus 5 / Sonnet 5 | 1M tokens | A compactação assume 150K por padrão quando habilitada |
| Claude Haiku 4.5 | 200K tokens | O orçamento seguro fica perto de 40K-80K |
| GPT-5.6 (Sol / Terra / Luna) | ~1.05M tokens | A requisição inteira é reprecificada acima de 272K de entrada |
| Gemini 3.1 Pro | 1M tokens | A requisição inteira é reprecificada acima de 200K |
| Llama 4 Scout | 10M tokens (iRoPE) | Documentado, não demonstrado nessa profundidade |
O que não mudou é o resultado de fundo. Nenhum desses lançamentos veio com evidência de que uma janela maior conserta o apodrecimento. Janelas maiores elevam o teto, o formato da degradação persiste, e você ainda precisa de recuperação para cargas frescas, multi-inquilino e de várias fontes.
Essa é a mesma disciplina que aparece na engenharia de contexto em geral: o que você deixa de fora do prompt importa tanto quanto o que você coloca. É também por isso que a camada de recuperação merece o mesmo escrutínio de qualquer outro caminho de entrada, já que a injeção indireta de prompt chega através de documentos recuperados, e não através dos seus usuários.
Um framework de decisão que você pode aplicar hoje
Percorra isto de cima a baixo para qualquer funcionalidade nova com LLM.
Passo 1: qual é o tamanho do seu corpus?
- Abaixo de 100K tokens no total: pule a recuperação, use contexto longo.
- De 100K a 1M tokens: depende do frescor, vá para o Passo 2.
- Acima de 1M tokens: recuperação é obrigatória.
Passo 2: quão frescos os dados precisam ser?
- De hora em hora ou mais rápido: recuperação. Reconstruir prompts longos é caro demais.
- De diário a semanal: qualquer um dos padrões funciona.
- Estático: contexto longo com cache de prompt é barato e limpo.
Passo 3: qual é o formato da consulta?
- Raciocínio profundo em um único documento: puxe para contexto longo.
- Síntese entre vários documentos: puxe para híbrido.
- Consulta pontual ou busca de fato: puxe para RAG clássico.
- Exploratório: contexto longo se o conjunto de documentos for limitado, senão híbrido.
Passo 4: você precisa de citação ou de controle de acesso?
- Sim para qualquer um dos dois: recuperação é obrigatória. Adaptar citações e filtragem por usuário num design só de contexto longo é doloroso.
Passo 5: qual é o seu orçamento de latência?
- Abaixo de 1 segundo: RAG clássico.
- De 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 de vários passos acima de 50K tokens: híbrido com reranker.
- Melhor esforço: o RAG clássico costuma bastar.
Passo 7: onde o seu prompt montado cai em relação ao penhasco de preço?
- Abaixo de 272K na OpenAI, abaixo de 200K no Google, ou, em qualquer outro fornecedor, abaixo do seu orçamento seguro medido: tudo bem.
- Pairando perto de qualquer um dos limiares: adicione um reranker e corte o conjunto recuperado. Você normalmente vai obter uma resposta melhor e uma conta menor ao mesmo tempo.
A maioria dos sistemas em produção acaba no híbrido, porque cargas de trabalho reais carregam pelo menos uma restrição que quebra o contexto longo puro (multi-inquilino, frescor, custo, citação) e pelo menos uma que quebra o RAG puro de top-k (raciocínio em documento único, consultas entre contextos, exploração).
Existe uma versão humana dessa mesma habilidade. Decidir o que merece entrar na frente de um processo de raciocínio é o que leitores atentos sempre fizeram à mão, e destacar é essa decisão tornada explícita. O destacador web do Glasp guarda as passagens que você julgou dignas de guardar em vez da página inteira, o que é recuperação com um reranker humano. Se você quiser apontar as suas próprias ferramentas para esse conjunto, o conector MCP do Glasp expõe seus destaques diretamente para um LLM. Escrevemos mais sobre essa configuração em transformando suas anotações em um servidor MCP.
Perguntas frequentes
O que é context rot em LLMs?
Context rot é a constatação de que os LLMs usam contexto longo pior do que o marketing sugere. Conforme você alimenta mais tokens, a precisão em recuperação e em raciocínio se degrada de forma não linear, batendo em penhascos em vez de descer uma rampa. Piora mais rápido quando o texto distrator se parece com a resposta, e a Chroma descobriu que até entradas coerentes e bem estruturadas prejudicaram a atenção mais do que entradas embaralhadas nos 18 modelos testados. Encher uma janela de 1M tokens não te compra uma resposta com qualidade de 1M tokens.
O RAG está ultrapassado em 2026?
Não, e a evidência aponta para o outro lado. A recuperação continua obrigatória para corpora que excedem qualquer janela, para dados que mudam de hora em hora, para controle de acesso por inquilino e para citação. O que está ultrapassado é o RAG clássico de top-5 como único padrão. O padrão atual é híbrido: recupere um conjunto limitado e depois raciocine sobre ele inteiro. Janelas de contexto maiores mudaram quanto você recupera, não se você recupera.
O contexto longo substitui o RAG?
No caso geral, não. O relatório Context Rot da Chroma mostrou o desempenho se degradando muito antes de a janela encher, e desde então os fornecedores concordaram nos próprios produtos: a compactação opcional da Anthropic assume por padrão resumir em 150K num modelo de 1M tokens, a OpenAI reprecifica requisições acima de 272K tokens de entrada, e o Google acima de 200K. O contexto longo substitui, sim, o RAG para um único documento limitado que caiba dentro do seu orçamento seguro medido.
Qual deve ser o tamanho do meu conjunto recuperado antes de o context rot aparecer?
Teste o seu modelo específico, mas um ponto de partida razoável é de 20 a 40 por cento da janela documentada. Isso dá 40K a 80K para um modelo de 200K e 200K a 400K para um modelo de 1M, embora na OpenAI você vá querer ficar abaixo de 272K por motivos de cobrança e no Google abaixo de 200K. Monte uma avaliação pequena com perguntas de vários saltos, meça a precisão ao longo dos tamanhos de contexto e fique com o maior tamanho que ainda passa da sua barra.
O cache de prompt resolve o context rot?
Não. O cache resolve custo, não precisão. Leituras de entrada em cache custam cerca de um décimo do preço normal de entrada, então consultas de contexto longo sobre conteúdo estável ficam bem mais baratas e a vantagem de custo do RAG diminui. O modelo continua lendo o mesmo contexto longo e se degradando do mesmo jeito, então você está pagando menos pela mesma resposta mais fraca. Na OpenAI, o cache também não te isenta da faixa de preço de contexto longo.
Devo usar um reranker antes de mandar para o contexto longo?
Para a maioria dos sistemas híbridos em produção, sim. Um cross-encoder pontuando os seus 50 a 200 chunks recuperados melhora muito o que chega ao estágio de raciocínio. Pular o rerank normalmente significa empilhar mais tokens para compensar a precisão mais fraca, o que te empurra tanto para a zona de apodrecimento quanto para o penhasco de preço. É uma das mudanças de maior impacto que você pode fazer num pipeline híbrido.
Meu agente para cedo em tarefas longas. Isso é context rot?
Provavelmente, e agora isso tem nome. O artigo de 2026 Diagnosing and Mitigating Context Rot in Long-horizon Search chama isso de terminação prematura: sob contexto pesado, os modelos desistem ou respondem com uma confiança não merecida antes de esgotar a janela, a uma taxa que sobe com o comprimento do contexto. O gerenciamento de contexto ajuda principalmente por cortar essa taxa, de modo que o agente continue explorando. Instrumente as desistências antecipadas como métrica própria.
Considerações finais
Todo lançamento com uma janela maior carrega a mesma promessa implícita: pare de fazer engenharia, é só despejar. A Chroma colocou números duros no motivo de essa promessa não ter se cumprido, o trabalho de 2026 acrescentou um segundo modo de falha que ninguém estava observando, e a matemática por baixo (diluição do softmax, extrapolação de posição, distribuição de treinamento) diz que ela também não vai se cumprir direito em 100M tokens.
O que resta é a resposta chata e produtiva. Construa recuperação. Ajuste. Adicione um reranker. Escolha um orçamento de contexto seguro medindo, em vez de confiar numa ficha técnica, e meça de novo quando o modelo ou o seu tokenizador mudar. Envie o conjunto de tokens menor e mais relevante que contenha a resposta. Deixe o modelo raciocinar sobre isso. Cite as fontes.
A novidade de 2026 é que os fornecedores agora precificam e projetam como se concordassem com você. Penhascos em 272K e 200K, e um padrão de compactação em 150K, são todos admissões de que a janela utilizável é uma fração da anunciada. Isso é útil, porque significa que a arquitetura disciplinada também é a barata, e essas duas raramente apontam para a mesma direção.
Se você quiser um mapa mais amplo de qual modelo apontar para qual tarefa, mantemos um na matriz de tarefas e modelos de IA. Decisões de arquitetura duram mais do que lançamentos de modelo. Acerte essas e a próxima atualização será uma melhoria de graça em vez de uma reescrita forçada.
