RLM 2027 · Capítulo 7 de 24 · 15 min
Comparar contexto longo, RAG e compactação antes de escolher o RLM
Três alternativas mais simples resolvem boa parte das perguntas; a decisão fica clara quando se sabe onde cada uma quebra e quanto custa.
Este capítulo faz parte do curso gratuito RLM 2027. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
A divisão por condicionante funcionou no ensaio, mas um protótipo recursivo cobra engenharia, latência de minutos e variância alta. Antes de adotá-lo, a Veredas precisa saber se uma alternativa mais simples resolveria as mesmas perguntas. Três candidatas estão à venda em setembro de 2026: pôr tudo numa janela de 1 milhão de tokens, buscar trechos e gerar (o RAG) ou resumir o material até caber.
Escolher sem comparar sai caro de dois jeitos. Quem adota RLM onde bastava busca paga minutos e dólares por pergunta que um RAG respondia em segundos. Quem fica no RAG onde a pergunta exige contar e cruzar recebe números errados com cara de certeza, como aconteceu em 29 das 50 perguntas de agregação da Veredas.
Ao terminar, você sabe em que tipo de pergunta cada alternativa quebra e faz a conta de custo de cada uma com preço público. E decide com o conjunto de 120 perguntas da Helena na mão.
Por que janela grande, busca e resumo falham em lugares diferentes
Janela grande deixou de ser diferencial. Em setembro de 2026, Claude Fable 5.1, Opus 5.5 e Sonnet 5 aceitam 1 milhão de tokens; a série GPT-6 aceita 1,05 milhão; o Gemini 3.x, 1.048.576. A Anthropic cobra o contexto de 1 milhão pelo preço padrão desde os modelos 4.6. A OpenAI indica variantes de contexto longo, acima de 272 mil tokens, pelo dobro do preço curto na série GPT-6 e no GPT-5.6.
Caber não é o mesmo que ler bem, e a trilha de fundamentos já separou janela máxima de capacidade efetiva. O que interessa aqui é o efeito na decisão. O Context Rot da Chroma, de julho de 2025, testou 18 modelos e viu queda com um único distrator. No RULER, só metade de 17 modelos sustentou desempenho satisfatório a 32 mil tokens. No OOLONG, GPT-5, Claude Sonnet 4 e Gemini 2.5 Pro ficaram abaixo de 50% a 128 mil tokens.
Um achado da Chroma pesa mais para a Veredas do que os outros. Os modelos se saíram pior quando o texto de fundo preservava o fluxo lógico do que quando as frases vinham embaralhadas. O acervo de uma consultoria é texto coerente, com relatórios que se parecem entre si e seguem a mesma ordem. Nesse material, a informação certa se disfarça bem entre as vizinhas, e janela cheia vira risco concreto.
Janela cheia não garante leitura: três medições independentes
18
modelos no Context Rot
um único distrator já reduz o desempenho; prompt focado vence o completo em todas as famílias
metade de 17
modelos sustentam 32 mil tokens no RULER
NVIDIA, abril de 2024
abaixo de 50%
GPT-5, Claude Sonnet 4 e Gemini 2.5 Pro no OOLONG
nos dois splits, a 128 mil tokens
1 milhão
tokens de janela nos modelos de ponta
Anthropic, OpenAI e Google em setembro de 2026
Fonte: Hong, Troynikov e Huber (Chroma), julho de 2025; Hsieh et al. (RULER), abril de 2024; Bertsch et al. (OOLONG), novembro de 2025; páginas de modelos das três empresas, setembro de 2026
Buscar antes de gerar tem data de nascimento: 22 de maio de 2020, quando Patrick Lewis e colegas do Facebook AI Research, da UCL e da NYU publicaram o artigo do RAG, aceito no NeurIPS 2020. A ideia combina memória paramétrica, o que o modelo guardou nos pesos durante o treino, com memória não paramétrica, um índice vetorial da Wikipédia consultado a cada pergunta. O método atingiu o estado da arte em três testes de perguntas abertas.
O artigo propôs duas formulações: as mesmas passagens para toda a resposta, ou passagens diferentes a cada token gerado. As duas partem da mesma aposta, a de que a resposta cabe em poucos trechos recuperáveis. É justamente a aposta que a pergunta de agregação quebra, porque a resposta certa depende de todos os trechos que citam a condicionante, muito além dos oito mais parecidos.
RAG quebra quando a resposta não mora em poucos trechos. Uma contagem sobre 38 empreendimentos precisa de todos os documentos que citam a condicionante, e o assistente da Veredas mandava ao modelo os 8 trechos mais parecidos com a pergunta. Na Tabela 1 do artigo do RLM, com GPT-5, o CodeAct com busca BM25 marca 51,0 no BrowseComp+, 38,0 no OOLONG e 24,7 no OOLONG-Pairs; o RLM com profundidade 1 marca 91,3, 56,0 e 58,0.
Antes de trocar o RAG, vale conferir a peça mais barata dele: o recuperador. No BrowseComp-Plus, de agosto de 2025, o mesmo GPT-5 marcou 55,9% com busca BM25, que casa palavras, e 70,1% com o Qwen3-Embedding-8B, que compara significado. São 14 pontos sem mudar o modelo nem a arquitetura. Um RAG com recuperador fraco pode estar sendo julgado pelo defeito errado.
Resumir é a terceira saída, e virou serviço. A Anthropic oferece compactação sob demanda, com o cabeçalho beta compact-2026-09-04, ou por limiar, e o resumo é escrito no servidor. A OpenAI oferece context_management com compact_threshold no endpoint /responses, ou o endpoint /responses/compact, que devolve um item de compactação criptografado e opaco. Opaco quer dizer que ninguém lê o que foi guardado, nem o próprio cliente.
A Anthropic documenta ainda o context editing como alternativa, que apaga do histórico blocos já usados em vez de resumi-los. Para a Veredas, o ponto comum das ofertas é o registro. Se a resposta precisa de trilha de auditoria, a trilha tem de ser guardada fora do item de compactação, porque o item não foi feito para ser lido por gente.
Para uma consultoria que responde ao órgão ambiental, o problema da compactação aparece na auditoria. Armadilha comum: medir só a acurácia e esquecer a rastreabilidade. Um resumo pode acertar que “o laudo de março está em conformidade” e ainda assim perder o número da planilha que prova isso, e resposta que não aponta o documento não entra num parecer técnico assinado.
Base, busca, compactação e RLM com o mesmo modelo raiz (GPT-5)
| Método | CodeQA | BrowseComp+ (1K docs) | OOLONG | OOLONG-Pairs |
|---|---|---|---|---|
| Modelo base | 24,0* | 0,0* | 44,0 | 0,1 |
| CodeAct + BM25 | 22,0* | 51,0 | 38,0 | 24,7 |
| Agente de compactação | 58,0 | 70,5 | 46,0 | 0,1 |
| RLM, profundidade 1 | 62,0 | 91,3 | 56,0 | 58,0 |
Acurácia em %, exceto OOLONG-Pairs (F1). O asterisco marca execução que bateu no limite de contexto. Subchamadas do RLM ao GPT-5-mini; a compactação usa GPT-5-nano.
Fonte: Zhang, Kraska e Khattab, Recursive Language Models, v3 (maio de 2026), Tabela 1
Existe uma versão treinada da compactação. O Context-Folding, publicado em outubro de 2025 por ByteDance Seed, CMU e Stanford, ensina o modelo a abrir uma subtrajetória e dobrá-la num resumo ao terminar. Com 32 mil tokens ativos, o Seed-OSS-36B treinado com FoldGRPO marcou 62,0% no BrowseComp-Plus, contra 47,8% do mesmo modelo como ReAct com 327 mil tokens. O GPT-5 como ReAct com 327 mil chegou a 79,3%.
No SWE-Bench Verified, o mesmo Context-Folding marcou 58,0%, contra 55,2% do ReAct com 327 mil tokens e 71,8% do GPT-5. A leitura tem dois lados. Aprender a dobrar o contexto ajuda um modelo aberto a render mais com pouca janela ativa. Não põe um modelo de 36 bilhões de parâmetros no nível de um modelo de fronteira com janela larga.
De onde vêm as alternativas que o RLM enfrenta
- 22 de maio de 2020Concluído
RAG, de Lewis et al.
Buscar trechos num índice vetorial e depois gerar; NeurIPS 2020.
- 9 de abril de 2024Concluído
RULER, da NVIDIA
Metade de 17 modelos não sustenta 32 mil tokens.
- 14 de julho de 2025Concluído
Context Rot, da Chroma
18 modelos perdem desempenho com o tamanho da entrada.
- 13 de outubro de 2025Concluído
Context-Folding
Compactação aprendida por reforço, com 32 mil tokens ativos.
- 31 de dezembro de 2025Concluído
Artigo do RLM, v1
Prompt como variável num REPL, com subchamadas por código.
- 4 de setembro de 2026Agora
Compactação sob demanda da Anthropic
Cabeçalho beta compact-2026-09-04; resumo escrito no servidor.
Como a Veredas pôs as três alternativas contra as 120 perguntas
O RAG já tinha número: 36 de 40 em localização, 21 de 50 em agregação e 7 de 30 em cruzamento, 64 de 120 no total. O custo por pergunta era baixo. Com 8 trechos de cerca de 800 tokens, a entrada fica perto de 6.500 tokens; a US$ 2 por milhão no Sonnet 5, são US$ 0,013, e 500 tokens de saída a US$ 10 por milhão somam US$ 0,005. Perto de US$ 0,02 por pergunta.
Contexto longo esbarrou no tamanho. O acervo tem 52 milhões de tokens, 52 janelas cheias, e não entra numa chamada. Restrito à mina e à barragem, os dois processos com mais condicionantes hídricas, com cerca de 900 mil tokens, acertou 31 das 50 perguntas de agregação dentro deles. Cada pergunta paga a leitura inteira: 900 mil tokens a US$ 4 por milhão no Opus 5.5 dão US$ 3,60 só de entrada; no Sonnet 5, US$ 1,80.
Os 19 erros de agregação dentro dos dois processos tinham padrão. Em 11, o modelo somou o mesmo laudo citado em três relatórios diferentes e contou três vezes. Em 8, deixou de fora condicionantes cujos laudos estavam espalhados por dezenas de planilhas curtas. Os documentos estavam todos ali, na mesma chamada. O que faltou foi um procedimento de contagem que o modelo seguisse item por item.
Cache muda essa conta quando as perguntas se repetem sobre o mesmo material. No Opus 5.5, a leitura de cache sai a 0,05 vez o preço de entrada: depois da primeira pergunta, os mesmos 900 mil tokens custam US$ 0,18. Na série GPT-6, a leitura acima de 272 mil tokens dobra de preço, e o GPT-6 Sol passa de US$ 2 para US$ 4 por milhão, o que devolve a conta aos US$ 3,60 por pergunta sem cache.
Duas regras de preço ainda mexem nessa conta. A Anthropic dá 50% de desconto em lote, para chamadas que podem esperar: a leitura de 900 mil tokens no Opus 5.5 cai para US$ 1,80. E o tokenizador adotado desde o Opus 4.7 gera cerca de 30% mais tokens para o mesmo texto. Se os 900 mil tokens foram contados com outro tokenizador, o recorte pode virar cerca de 1,17 milhão e deixar de caber na janela.
# Conta de custo por pergunta das três alternativas, a preços de setembro de 2026.
PRECO = { # US$ por milhão de tokens (entrada, saída)
"sonnet-5": (2.0, 10.0),
"opus-5.5": (4.0, 20.0),
}
def custo(modelo, tokens_entrada, tokens_saida):
entrada, saida = PRECO[modelo]
return tokens_entrada / 1e6 * entrada + tokens_saida / 1e6 * saida
print(round(custo("sonnet-5", 6_500, 500), 3)) # RAG, 8 trechos: 0.018
print(round(custo("opus-5.5", 900_000, 0), 2)) # contexto longo, sem cache: 3.6
print(round(custo("opus-5.5", 900_000, 0) * 0.05, 2)) # mesma leitura em cache: 0.18
print(round(custo("sonnet-5", 760_000, 800), 2)) # acervo compactado: 1.53A compactação foi a última tentativa. Caio resumiu cada empreendimento em cerca de 20 mil tokens, em resumos por partes, e os 38 resumos somaram 760 mil tokens, que cabem numa janela. O resultado ficou abaixo do RAG: 22 de 40 em localização, 24 de 50 em agregação e 9 de 30 em cruzamento, 55 de 120. Cada pergunta custou US$ 1,53 no Sonnet 5, fora a produção dos resumos, que exigiu ler os 52 milhões de tokens uma vez.
Localização foi o que mais caiu, de 36 para 22, porque o resumo apagou nomes de arquivo, páginas e números de processo. Nos cruzamentos, o ganho de 7 para 9 veio de perguntas em que o resumo guardou por acaso as duas datas em conflito. Helena conferiu as 9 respostas certas: em 5 delas, o resumo não permitia apontar o documento de origem.
Helena fez questão de um teste justo. As três alternativas responderam às mesmas 120 perguntas, contra as mesmas respostas de referência, com a mesma regra de correção. Resposta certa sem documento de origem contava como acerto, mas ganhava uma marca à parte. Foi essa marca que mostrou o problema da compactação, invisível numa planilha só de acurácia.
Somado, o custo das 120 perguntas separa as opções. O RAG gasta cerca de US$ 2,40 para responder a todas, a US$ 0,02 cada. A compactação gasta US$ 184 nas mesmas 120, a US$ 1,53 cada, fora a produção dos resumos. O contexto longo nem entra na soma, porque só responde perguntas restritas a recortes que cabem na janela.
As três alternativas contra as 120 perguntas da Veredas
| Alternativa | Localização (40) | Agregação (50) | Cruzamento (30) | Custo por pergunta | Aponta o documento? |
|---|---|---|---|---|---|
| RAG com 8 trechos | 36 | 21 | 7 | cerca de US$ 0,02 | sim |
| Contexto longo | não cabe o acervo | 31 (só nos 2 maiores) | não testado | US$ 1,80 a US$ 3,60 | sim, se o modelo citar |
| Acervo compactado | 22 | 24 | 9 | US$ 1,53 | raramente |
Cenário ilustrativo. Preços de referência de setembro de 2026: Sonnet 5 a US$ 2 e US$ 10 por milhão de tokens; Opus 5.5 a US$ 4 e US$ 20.
O que sobra da prova depois de cada leitura
Leituras que perdem a origem
Coluna a evitar
- Resumo que guarda a conclusão e apaga o número da planilha
- Item de compactação opaco, que ninguém consegue abrir
- Oito trechos parecidos, sem os documentos que ficaram de fora
Leituras que guardam a origem
Coluna recomendada
- Documento inteiro na janela, quando o recorte cabe
- Registro com id do documento e trecho literal, validado em código
- Tabela final montada sobre registros com prova
Helena leu a tabela como um mapa de lacunas. O RAG fica com as perguntas de localização, barato e rastreável. Contexto longo serve quando a pergunta cita um ou dois empreendimentos e o recorte cabe na janela. A compactação sai da mesa, porque perde exatamente a prova que o cliente paga para receber. Sobram as perguntas de agregação e cruzamento sobre o acervo inteiro, o terreno em que o ensaio recursivo acertou 11 de 12.
Nenhuma das três alternativas respondeu bem às perguntas que atravessam os 38 empreendimentos. Separe as 120 perguntas por duas dimensões, o tamanho do material relevante e quantas partes dele a resposta exige, e marque o quadrante de cada uma. Se mais de 40 caírem em material grande com resposta densa, o RLM tem espaço real para provar valor.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Voltar ao capítulo anterior: Processar as partes e juntar as respostas sem perder a evidência
Todos os capítulos de RLM 2027
- 01Descobrir onde o modelo encontra cada informação que usa
- 02Medir o limite real do contexto e dividir o problema
- 03Guardar o acervo numa variável e deixar o modelo programar a leitura
- 04Desenhar a árvore de chamadas e decidir a profundidade
- 05Explorar o acervo antes de decidir onde cortar
- 06Processar as partes e juntar as respostas sem perder a evidência
- 07Comparar contexto longo, RAG e compactação antes de escolher o RLM
- 08Situar agentes, híbridos e RLM numa matriz de decisão
- 09Julgar um benchmark antes de acreditar no número dele
- 10Comparar métodos nas mesmas condições e ler os resultados contrários
- 11Preparar o acervo e rodar a biblioteca oficial rlm
- 12Montar o protótipo com dspy.RLM e auditar o rastro de cada resposta
- 13Decompor o custo de uma execução e pôr teto em cada parte
- 14Baixar o custo por pergunta e vigiar o que a média esconde
- 15Isolar o código gerado e tratar cada documento como dado
- 16Impedir que o erro de uma folha chegue à resposta final
- 17Treinar um modelo pequeno para decidir quando delegar
- 18Provar uma auto-melhoria antes de acreditar nela
- 19Julgar as apostas de recursão aprendida e execução previsível
- 20Mapear híbridos, imagem e trabalho prolongado com evidência e lacuna
- 21Ler 2027 por sinais observáveis em vez de apostar numa previsão
- 22Escolher onde o RLM entra primeiro e decidir o piloto
- 23Definir o problema e construir quatro alternativas comparáveis
- 24Avaliar as alternativas e dizer em quais condições o RLM compensa