Como o acervo fica disponível fora da conversa

Se o material não cabe na conversa, ele pode continuar disponível em um ambiente de execução. No RLM, o modelo escreve pequenos programas para examinar partes desse acervo. REPL é o nome do ambiente que recebe um comando, executa e devolve o resultado. Para o gestor, o ponto central é distinguir acesso ao material de envio do material inteiro ao modelo.

Exemplo: Errar esse lugar produz um sistema caro e cego ao mesmo tempo. Quem envia o acervo no histórico de um agente precisa considerar o material transmitido, a janela disponível e as regras de cobrança do provedor. O reaproveitamento por cache pode alterar o custo; ele deve ser conferido na configuração contratada. Quem esconde o acervo atrás de uma busca volta ao problema dos oito trechos, que custou à Veredas 31 erros de contexto.

No desenho de Zhang, Kraska e Khattab, o acervo fica disponível como variável no ambiente de execução. O modelo coordenador começa com informações sobre esse material e escolhe o que examinar por código. Ele não precisa receber tudo na primeira chamada, mas os trechos e resultados devolvidos pelo programa entram em seu contexto. O limite continua existindo em cada chamada.

Por que tirar o prompt da janela muda o que o modelo consegue fazer

REPL é um terminal que executa uma linha de código por vez e guarda as variáveis entre uma linha e outra, como um caderno de rascunho que lembra as contas anteriores. O nome vem de read, eval, print e loop: ler, avaliar, imprimir e repetir. Quem já usou um notebook de Python conhece a sensação de definir uma lista numa célula e usá-la três células depois.

No RLM, o prompt do usuário entra nesse caderno como uma variável chamada context. O modelo que coordena, chamado modelo raiz, não recebe o texto. Recebe metadados de tamanho constante: o tipo da variável, o comprimento total em caracteres, o tamanho dos pedaços, um prefixo curto e a forma de acessar o conteúdo. Um acervo de mil páginas e outro de dez mil geram metadados do mesmo tamanho.

A partir daí, o modelo raiz trabalha como um analista com um terminal aberto. Escreve código num bloco marcado como repl, o ambiente executa, e o resultado fica guardado em variáveis. O código pode fatiar o texto, usar expressões regulares e chamar a função llm_query, que manda um pedaço a outro modelo. O prompt do artigo informa ao modelo que essa função aceita cerca de 500 mil caracteres.

Essa ideia nasceu de um incômodo prático. No post de outubro de 2025, Zhang descreve o modelo raiz que não vê o contexto e só sabe o tamanho dele. Por isso a primeira coisa que ele faz é espiar: no exemplo do OOLONG, lê os primeiros 2.000 caracteres para entender o formato. Só depois escreve o código que filtra, divide e delega. O autor chama os RLMs de generalização natural das estratégias de resumo.

Depois de cada execução, só um prefixo curto da saída e o tamanho dela voltam ao histórico do modelo raiz. A saída do REPL é truncada de propósito. Se o modelo imprime o acervo inteiro, recebe de volta as primeiras linhas e um aviso de tamanho. Esse corte força o trabalho a acontecer nas variáveis e nas subchamadas, e não na janela do modelo raiz.

O artigo contrasta esse desenho com um segundo algoritmo, marcado como falho, que descreve como muitos agentes funcionam. A comparação isola três escolhas. Handle simbólico: o prompt fica fora da janela, acessível por um nome; a falha número um é pôr o prompt no histórico. Handle é uma alça, uma referência que permite pegar o objeto sem carregá-lo.

A segunda escolha é a saída construída no REPL. A resposta pode ser montada numa variável, linha a linha, e devolvida no fim, o que permite respostas maiores que a janela do modelo. A falha correspondente é gerar a resposta direto no texto do modelo, limitada ao que ele consegue escrever num turno.

Por último vem a recursão simbólica. O código chama o modelo sobre pedaços do prompt construídos por programa, dentro de laços. Um laço sobre 6.400 documentos pode disparar milhares de subchamadas sem que o modelo raiz escreva milhares de mensagens. A falha número três é tratar a subchamada como uma ação verbal do agente, que ele precisa pedir uma de cada vez e não consegue pôr num laço.

Há um custo escondido nesse desenho, e os autores o registram. Se cada turno do modelo raiz for aparado a c tokens, o raiz faz no máximo K dividido por c iterações antes de encher a própria janela K. Cada iteração pode disparar quantas subchamadas quiser, e os autores afirmam que o limite não é fundamental. Na prática, ele explica por que as implementações cortam a saída de cada passo com rigor.

Cada implementação escolheu os próprios nomes e limites. A biblioteca oficial rlms segue o artigo na variável context e nas subchamadas, mas na versão 0.1.3 encerra pelo dicionário answer, e não por FINAL. O dspy.RLM entrega a resposta com SUBMIT e corta a saída do REPL em 10 mil caracteres por padrão. O desenho da Prime Intellect para o verifiers corta em 8.192 caracteres e dá 120 segundos a cada chamada ao REPL. Código escrito para uma implementação não roda em outra sem ajuste.

No DSPy, o tamanho da prévia e o intérprete fazem parte da configuração. O parâmetro interpreter_factory fornece a fábrica que cria um intérprete para cada execução; assim, a implementação padrão não reaproveita automaticamente as variáveis da pergunta anterior. Ferramentas externas, arquivos e registros persistentes exigem controle próprio. O módulo continua experimental: confira a versão e os parâmetros antes de adaptar um exemplo.

A Prime Intellect levou a mesma lógica a outra peça, as ferramentas. No desenho publicado em janeiro de 2026, busca na web e outras ferramentas extras ficam disponíveis só para os modelos das subchamadas. O modelo raiz não as recebe, para que as descrições e os resultados delas não inchem a janela de quem coordena. A regra é a mesma do prompt: o raiz decide, e quem lê material volumoso é outro modelo.

Armadilha comum: abrir o REPL e, no primeiro turno, mandar o modelo imprimir o contexto para “dar uma olhada”. É a falha número um por outra porta. A saída volta truncada, o modelo decide com base nas primeiras linhas e trata o resto como se fosse igual. O desenho pede o contrário: medir, espiar um pedaço pequeno e só então escrever o código que lê.

O código gerado precisa de um ambiente de execução definido. O ambiente local da biblioteca rlms e o LocalInterpreter do DSPy não oferecem isolamento de segurança. O PythonInterpreter padrão do DSPy usa Deno e Pyodide, com acesso ao hospedeiro restrito por padrão. As permissões podem ser ampliadas e as ferramentas fornecidas pela aplicação executam fora desse compartimento; por isso, o nome “sandbox” não substitui a revisão da configuração.

Como a Veredas pôs 52 milhões de tokens numa variável

Caio começou pelo formato. Em vez de um único texto gigante, montou context como uma lista de 6.400 textos, um por documento. Na primeira linha de cada um, acrescentou um cabeçalho padronizado com empreendimento, tipo de documento, data e código interno. Esse cabeçalho custou dois dias de limpeza e é o que permite ao modelo raiz filtrar sem ler.

Na simulação, Caio usa a aproximação de quatro caracteres por token: 52 milhões de tokens equivalem a cerca de 208 milhões de caracteres. Ele adota blocos de até 500 mil caracteres como hipótese inicial do exercício. Um documento de 1,9 milhão de caracteres exigiria pelo menos quatro blocos nessa conta. Na implementação, é preciso medir tokens, reservar espaço para instruções e resposta e verificar se cada bloco conserva o sentido.

Aprofundamento de implementação. A sequência a seguir requer Python e um ambiente isolado. Você pode acompanhá-la com a equipe responsável: confira os dados de entrada, o limite de acesso e a evidência produzida, mesmo que não execute o código.

No primeiro turno, o modelo raiz fez o que o desenho pede. Não leu nenhum documento: extraiu só os cabeçalhos, contou os tipos e descobriu que o acervo tinha 1.130 laudos de água, 212 documentos de condicionantes e 96 pareceres do órgão ambiental. A saída coube em algumas centenas de caracteres e voltou inteira. No segundo turno, filtrou os documentos de condicionantes e espiou os 2.000 primeiros caracteres de um deles.

Dessa espiada saiu um formato que Caio não tinha documentado. Os documentos de condicionantes da maioria dos empreendimentos traziam uma tabela com número, descrição, prazo e situação, mas os de quatro empreendimentos antigos listavam as condicionantes em texto corrido. O modelo raiz registrou isso numa variável e, no terceiro turno, escreveu dois filtros diferentes, um para cada formato.

A conta da tabela mostra por que o desenho escala. Depois de três turnos, o modelo raiz carrega cerca de 9 mil tokens, contra 52 milhões no acervo. Ao preço de referência do GPT-5, o modelo raiz do artigo, US$ 1,25 por milhão de tokens de entrada, o terceiro turno custa pouco mais de um centavo de dólar. O dinheiro vai para as subchamadas, que leem de fato.

Caio também anotou o que o cabeçalho não resolvia. Dos 6.400 documentos, 140 não tinham data legível no arquivo original e ficaram com a data marcada como desconhecida. O filtro por data ignoraria esses 140 em silêncio. Ele deixou a regra explícita no cabeçalho, com o valor desconhecido escrito por extenso, para que qualquer código que filtrasse por data tivesse de decidir o que fazer com eles.

Helena fez a pergunta que todo gestor faz nesse ponto: se o modelo raiz nunca lê os documentos, como ela confia na resposta? Caio mostrou o rastro. Cada bloco de código, cada saída truncada e cada variável ficam registrados, e o filtro que separou os 212 documentos de condicionantes é uma expressão regular que ela pode ler e contestar. A confiança passa a depender de um rastro auditável, e não de uma impressão sobre o texto gerado.

No exemplo, Caio configura o PythonInterpreter sem liberar arquivos, rede ou variáveis de ambiente da empresa ao código gerado. Ele também revisa as ferramentas do processo hospedeiro e quais trechos podem ser enviados ao provedor de modelos. São controles diferentes: isolar a execução não transforma uma chamada de API em processamento local.

Guia prático para marketing: avaliações e comentários numa variável. A ideia deste capítulo resolve uma tarefa que toda equipe de marketing adia, que é ler de verdade milhares de avaliações de loja, comentários de redes sociais e respostas abertas de pesquisa. O passo a passo abaixo usa a biblioteca oficial rlms, versão 0.1.3, com o acervo inteiro guardado na variável do REPL e o modelo raiz programando a leitura.

Peça um desenho que mostre o acervo, o ambiente de execução e as chamadas ao modelo. Confira quais dados atravessam cada fronteira e quem pode acessá-los. O limite de cada parte precisa considerar o modelo, a tarefa e o orçamento; um tamanho fixo em caracteres não garante que a resposta terá qualidade.