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. O texto da versão 3, de 11 de maio de 2026, recuou para mais de uma ordem de grandeza, embora o resumo na página do arXiv ainda traga a frase antiga. Cite a formulação do texto mais recente e anote a versão, o modelo e o teste.

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.