Medir o limite real do contexto e dividir o problema

Com a linha de base medida, a Veredas precisa decidir como fazer o modelo ler o que a busca por trechos não entrega. A saída mais óbvia é colar mais material na chamada. Janelas de 1 milhão de tokens existem, e parece natural encher a mesa com todos os papéis de um empreendimento e perguntar.

Essa saída tem dois limites, e ignorar qualquer um deles custa caro. O primeiro é de tamanho: 52 milhões de tokens são 52 janelas cheias, e nenhum modelo aceita isso numa chamada. O segundo é de qualidade: dentro da janela, o modelo não lê tudo com a mesma atenção, e a queda aparece bem antes do limite anunciado.

Ao terminar, o leitor distingue a janela máxima da capacidade efetiva, sabe citar as medições que separam as duas e entende a recursão pelas quatro partes que a definem: dividir, caso-base, parada e retorno. Entende também por que o Tiny Recursive Model, que ganhou manchetes em 2025, compartilha só o nome com os RLMs.

Por que caber na janela não garante que o modelo leia

Janela máxima é o número que o fornecedor publica: quantos tokens a API aceita numa chamada. Capacidade efetiva é outra medida, a partir de que tamanho o modelo começa a errar o que acertaria com menos texto. A diferença lembra a de um auditório com mil lugares e uma voz que só alcança as primeiras fileiras. Todos entram, poucos escutam.

Medir a capacidade efetiva exige teste controlado. Em abril de 2024, a NVIDIA publicou o RULER e testou 17 modelos: só metade sustentou desempenho satisfatório a 32 mil tokens, embora todos anunciassem janelas maiores. Em novembro de 2025, o benchmark OOLONG pediu agregação sobre contextos de 128 mil tokens. GPT-5, Claude Sonnet 4 e Gemini 2.5 Pro ficaram abaixo de 50 por cento nas duas divisões do teste.

O estudo que deu nome ao fenômeno saiu em 14 de julho de 2025. Kelly Hong, Anton Troynikov e Jeff Huber, da Chroma, testaram 18 modelos de Anthropic, OpenAI, Google e Alibaba e chamaram a queda de context rot, o apodrecimento do contexto. O desempenho variou com o tamanho da entrada mesmo em testes simples, como repetir uma sequência de palavras.

Três achados do Context Rot interessam a quem lida com acervos técnicos. Um único distrator, trecho parecido com a resposta e errado, já reduz o acerto. Prompts focados, com só o trecho relevante, superaram prompts completos em todas as famílias de modelos. E os modelos foram pior quando o texto de fundo preservava o fluxo lógico do que quando as frases estavam embaralhadas, um resultado contraintuitivo.

O experimento mais próximo do uso real usou o LongMemEval, um teste de memória de conversas longas. A mesma pergunta foi feita com cerca de 300 tokens focados, só o trecho que importava, e com cerca de 113 mil tokens completos, a conversa inteira. Os modelos responderam melhor com a versão curta. Para quem monta assistentes sobre acervos, a lição é direta: mandar tudo custa mais e rende menos.

Esse último achado toca a Veredas diretamente. Um acervo de licenciamento é o oposto de um palheiro aleatório: laudos de um mesmo poço se repetem com pequenas diferenças, trimestre após trimestre. Cada laudo antigo é um distrator perfeito para a pergunta sobre o laudo novo. A Chroma concluiu que importa como a informação é apresentada, e recomendou praticar engenharia de contexto.

Engenharia de contexto é escolher o que entra na janela, em que ordem e com que tamanho. O RLM leva essa ideia ao extremo: em vez de uma pessoa escolher, o próprio modelo escreve o código que escolhe, pedaço por pedaço. Armadilha comum: ler a janela de 1 milhão como promessa de leitura de 1 milhão. O número informa quanto a API aceita, e nada diz sobre quanto o modelo usa bem.

A própria contagem de tokens engana quem faz conta de janela. Ela depende do tokenizador, o programa que corta o texto em tokens, e muda de um modelo para outro. A Anthropic informa que o tokenizador usado desde o Claude Opus 4.7 gera cerca de 30 por cento mais tokens para o mesmo texto. Os 52 milhões da Veredas são uma estimativa, e a mesma pasta pode pesar mais em outro modelo.

Dividir, caso-base, parada e retorno, as quatro partes da recursão

Recursão é resolver um problema grande chamando a mesma solução sobre pedaços menores dele. A apuração de uma eleição é o exemplo mais familiar. Cada seção eleitoral conta os próprios votos, a zona soma as seções, o estado soma as zonas. Ninguém conta o país inteiro de uma vez, e o total sai da soma dos totais parciais.

Toda recursão tem quatro partes. Dividir: partir o problema em pedaços do mesmo tipo. Caso-base: o pedaço pequeno o bastante para resolver direto, como a seção que conta a própria urna. Parada: a regra que impede a divisão de continuar para sempre. Retorno: o resultado de cada pedaço volta para quem o pediu e é combinado. Falte uma das quatro e o programa não termina ou termina errado.

O código abaixo mostra as quatro partes numa contagem sem modelo de linguagem, só com Python. Ele conta quantos documentos mencionam uma condicionante hídrica vencida. A lógica é a mesma que um RLM aplica, com uma diferença: no RLM, o caso-base é uma chamada ao modelo que lê o pedaço, e não uma busca por palavra.

Com 6.400 documentos e lotes de até 50, a lista se divide sete vezes até chegar ao caso-base: 6.400 vira 3.200, depois 1.600, 800, 400, 200, 100 e 50. São 128 lotes na última camada. Por isso a parada de segurança do exemplo, fixada em seis níveis, cortaria a divisão um nível antes, com lotes de 100. Escolher a parada é uma decisão de custo, e a trilha de custo trata dela.

No RLM, duas coisas mudam em relação a esse código. O caso-base deixa de ser uma busca por palavra e passa a ser uma chamada ao modelo que lê o pedaço e responde em texto. E a divisão deixa de ser fixada pelo programador: o próprio modelo raiz escreve o código que decide como partir o acervo, depois de medir o tamanho dele. A recursão continua com as mesmas quatro partes, só que escritas pelo modelo durante a execução.

Recursão dentro da rede e recursão entre chamadas

Em 6 de outubro de 2025, Alexia Jolicoeur-Martineau, do Samsung SAIL Montréal, publicou o Tiny Recursive Model, ou TRM. Uma rede de 2 camadas e 7 milhões de parâmetros, treinada do zero em cerca de mil exemplos, marcou 44,6 por cento no ARC-AGI-1 e 7,8 por cento no ARC-AGI-2. O Gemini 2.5 Pro, na mesma comparação, marcou 37,0 e 4,9 por cento.

Os números correram o mundo arredondados para 45 e 8 por cento, e o nome fez muita gente juntar o TRM aos RLMs. Os dois são coisas diferentes. No TRM, a recursão acontece dentro da rede: ela repassa o próprio estado interno várias vezes antes de responder, como quem relê a mesma conta de cabeça. No RLM, a recursão acontece entre chamadas: um programa chama o modelo de linguagem várias vezes sobre pedaços de texto.

A distinção tem consequência prática. Um TRM não ajuda a Veredas a ler laudos, porque não lê texto longo; seus resultados valem para quebra-cabeças de grade. Trabalhos de 2026 derivados dele seguem na mesma linha: uma versão autorregressiva publicada em março não mostrou ganhos confiáveis. Quem cita o TRM como prova de que RLMs funcionam está somando evidências de dois mecanismos que nada têm em comum além do adjetivo.

Como a Veredas mediu o limite da janela no próprio acervo

Caio fez primeiro a conta de tamanho. Com 52 milhões de tokens e janelas de cerca de 1 milhão, o acervo inteiro equivale a 52 janelas cheias. O maior teste do artigo do RLM com GPT-5 usou de 6 a 11 milhões de tokens contra uma janela de 272 mil, entre 22 e 40 vezes a janela. O acervo da Veredas passa desse patamar, o que já pedia cautela ao ler qualquer promessa.

A formulação da promessa também mudou com o tempo. As versões 1 e 2 do artigo diziam que os RLMs processam entradas de até duas ordens de grandeza acima da janela. A versão 3, de maio de 2026, recuou para mais de uma ordem de grandeza. Textos de terceiros escritos depois disso, como um post da LangChain de julho de 2026, ainda repetem a frase antiga. Use a formulação mais recente e confira a versão do artigo antes de citar.

Depois, testou o que cabia. Os dois empreendimentos com mais condicionantes hídricas, uma mina e uma barragem de rejeito, somam cerca de 900 mil tokens e entram numa janela de 1 milhão. Caio restringiu as 50 perguntas de agregação a esses dois processos, colou os documentos inteiros na chamada e comparou com a resposta de referência de Helena.

O contexto longo acertou 31 de 50, dez a mais que a busca por trechos, com 150 vezes mais tokens de entrada por pergunta. E errou 19. Helena leu os erros e achou sinais parecidos com os do Context Rot. O modelo perdia condicionantes do meio do material e confundia laudos quase iguais do mesmo ponto de coleta, que agiam como distratores.

Caio fez um teste a mais para confirmar a suspeita. Repetiu dez das perguntas erradas com os mesmos documentos em ordem inversa, do mais novo para o mais antigo. Três respostas mudaram, duas para certo e uma para errado. Um sistema que muda de resposta quando a ordem dos papéis muda não está lendo tudo com a mesma atenção, e Helena não assinaria um parecer apoiado nele.

Ficou claro para os dois que ampliar a mesa não resolvia. Para 36 dos 38 empreendimentos seria preciso dividir de qualquer jeito, e mesmo nos dois que cabiam a leitura de uma vez perdia o meio. A pergunta de Caio mudou de “como colar mais texto” para “como dividir o acervo, mandar cada pedaço a uma leitura curta e juntar os resultados sem perder a evidência”.

A Veredas saiu com duas medidas novas: 31 de 50 no contexto longo e US$ 3,60 de entrada por pergunta nesse desenho. Abra agora o Algoritmo 1 do artigo de Zhang, Kraska e Khattab e anote o que o modelo raiz recebe no primeiro turno. A leitura está certa se a anotação não incluir o texto do prompt.