Explorar o acervo antes de decidir onde cortar

Com a árvore de chamadas desenhada, falta decidir o que cada galho recebe para ler. O modelo raiz começa a execução sem ver um único documento: conhece o tipo da variável context, o comprimento total e um prefixo curto. Qualquer corte feito nesse estado é um palpite sobre 6.400 documentos.

Palpite custa caro nos dois sentidos. Um corte fino demais dispara centenas de subchamadas que leem texto irrelevante e cobram por cada token. Um corte grosso demais separa a condicionante do laudo que a contradiz, e a resposta sai limpa, bem escrita e errada, sem nenhum sinal de alerta.

Ao terminar, você reconhece três gestos de exploração que custam quase nada: espiar, filtrar por padrão e contar em código. Sabe ler o que eles revelam sobre a estrutura do material e escolhe a unidade de divisão a partir da pergunta de negócio.

Por que olhar antes de cortar muda a resposta

Alex L. Zhang descreveu esses gestos em outubro de 2025, no post de blog que apresentou os RLMs, assinado com Omar Khattab. Ao observar as execuções, ele deu nome ao que os modelos faziam sem que ninguém pedisse. O primeiro padrão é o peeking, ou espiar: o modelo raiz sabe o tamanho do contexto, mas não o conteúdo, e por isso imprime o começo. No exemplo do OOLONG, um benchmark de agregação sobre texto longo, eram os primeiros 2.000 caracteres.

Em seguida vem o grepping: usar palavra-chave ou expressão regular para estreitar as linhas de interesse. Expressão regular é um padrão de busca escrito em código, como um filtro de planilha que aceita variações de grafia. O autor registra que o modelo prefere esse filtro exato à busca semântica, aquela que acha trechos parecidos em significado e que o RAG da Veredas usava.

Os outros três padrões do post dependem desses dois. Partition + Map divide o contexto em pedaços e roda uma subchamada por pedaço. Summarization resume subconjuntos para o modelo de fora decidir. Long-input, long-output cuida de saídas extensas, como gerar o BibTeX de uma lista inteira de artigos. Esta trilha segue essa ordem: reconhecer, dividir, processar e juntar.

Explorar em código tem uma razão técnica no desenho do laço. Pelo algoritmo do artigo de Zhang, Kraska e Khattab, só um prefixo curto da saída de cada comando volta ao histórico do modelo raiz; o resto fica guardado em variáveis. Um print do acervo inteiro seria truncado e ensinaria pouco. Contar tipos, agrupar cabeçalhos e listar códigos devolve pouca saída e muita informação sobre a forma do material.

Os metadados iniciais também seguem o artigo. O modelo raiz recebe informação de tamanho constante: o tipo do contexto, o comprimento total em caracteres, os tamanhos dos pedaços, um prefixo curto e a forma de acessar o conteúdo. Tamanho constante quer dizer que a ficha de apresentação de um acervo de mil páginas ocupa o mesmo espaço que a de um acervo de um milhão. O resto, o raiz descobre escrevendo código.

Cada implementação põe o seu teto na saída que volta. No dspy.RLM, o parâmetro max_output_chars tem padrão de 10 mil caracteres, e a versão 3.2.0, de abril de 2026, fixou em 1.000 caracteres a prévia de cada variável. No desenho da Prime Intellect, a saída do REPL fica em 8.192 caracteres por turno. Quem explora com print longo gasta o turno e recebe um recorte; quem explora com contagens recebe a resposta inteira.

Quanto rende explorar só com código aparece numa linha da Tabela 1 do artigo, na versão de maio de 2026. A profundidade 0 é o RLM sem subchamadas: o modelo raiz tem o REPL, filtra, conta e responde, mas não chama outro modelo. A profundidade 1 acrescenta as subchamadas, que no caso do GPT-5 vão ao GPT-5-mini.

Lida com cuidado, a tabela diz duas coisas. Com GPT-5, o REPL sozinho já chega a 88,0 no BrowseComp+, onde a resposta pode ser localizada por padrão; as subchamadas acrescentam pouco ali. No OOLONG e no OOLONG-Pairs, que pedem julgamento semântico sobre cada trecho, as subchamadas somam 20 e 14 pontos. Com Qwen3-Coder, a profundidade 0 vence todas as variantes com subchamadas no CodeQA.

Explorar também contém a conta. O artigo relata que o GPT-5 faz subchamadas “on the order of ten” por consulta, enquanto o Qwen3-Coder chegou a centenas ou milhares numa consulta simples e precisou de uma linha extra no prompt para parar. Um modelo raiz que conhece a forma do acervo antes de dividir tem menos motivo para mandar cada linha a uma subchamada.

Filtros por padrão têm um limite que a pressa esconde. Armadilha comum: tratar o resultado do filtro como inventário completo. Uma expressão regular procura “condicionante” e não acha “condicio-” quebrado no fim de linha de um PDF digitalizado, nem “cond.” abreviado, nem “hidrico” sem acento. O filtro devolve uma lista plausível, e ninguém percebe o que ficou de fora até uma resposta sair curta.

Escolher a unidade de divisão pela pergunta

Depois de reconhecer o acervo, o modelo raiz decide como cortar. Há quatro unidades comuns: tamanho fixo (blocos de N caracteres), documento, entidade de negócio (um empreendimento, uma condicionante) e período. A escolha certa é a unidade onde a resposta mora. Se a pergunta cruza uma condicionante com os laudos que a verificam, os dois precisam cair no mesmo pedaço, ou a subchamada nunca os vê juntos.

Cada pedaço também precisa caber na leitura de uma subchamada. No prompt do artigo, o texto avisa ao modelo que llm_query aguenta “around 500K chars”, e a documentação do dspy.RLM repete a ordem de grandeza de 500 mil caracteres. Quando uma unidade de negócio passa desse tamanho, entra a recursão da trilha anterior: o pedaço grande é dividido de novo, e o caso-base é o pedaço que cabe.

O tempo também pode ser a unidade. Uma condicionante vence numa data, e um laudo só a contradiz se for do período que ela cobre. Quando a pergunta depende de prazo, o grupo precisa levar as datas junto, e o reconhecimento deve medir de que ano a que ano vai cada tipo de documento. Um corte que separa a licença de 2019 da renovação de 2023 produz vencimentos que não existem.

Esse vocabulário está convergindo. O λ-RLM, proposto em março de 2026 por pesquisadores do IIT Delhi e do Huawei Noah's Ark, troca o código livre por combinadores fixos com nomes como Split, Peek, Map, Filter e Reduce. São os mesmos gestos do post de Zhang, agora em forma de peças verificadas. A trilha de perspectivas volta a ele; por ora, os nomes ajudam a descrever uma execução.

Como a Veredas mapeou o acervo antes do primeiro corte

Caio carregou o acervo como uma lista de 6.400 textos, um por documento, com uma linha de cabeçalho em cada: código do empreendimento, tipo, data e número do processo. Os metadados que o modelo raiz recebeu diziam lista, 6.400 itens e cerca de 208 milhões de caracteres. A conta do cenário usa 4 caracteres por token: 208 milhões divididos por 4 dão os 52 milhões de tokens do acervo.

No segundo turno, o modelo contou os tipos pelo cabeçalho e devolveu uma tabela de seis linhas, sem ler o corpo de nenhum documento. Helena reconheceu o acervo na hora, com uma surpresa: os relatórios de monitoramento eram mais numerosos que as planilhas de laboratório, e os estudos de impacto, poucos, concentravam mais de um quarto dos tokens.

O terceiro turno aplicou o filtro de condicionantes. A primeira versão, sem normalização, achou 1.212 menções em 489 documentos. Helena desconfiou do número e leu 40 PDFs digitalizados por amostragem: encontrou palavras quebradas no fim da linha, “hidrico” sem acento e “cond.” abreviado. Com a normalização do código acima, o filtro passou a 1.489 menções em 571 documentos. A versão ingênua perdia 277 menções, 18,6% do total.

Nos dois turnos seguintes, o modelo agrupou as menções por empreendimento e número de condicionante e mediu o tamanho de cada grupo. Resultado: 214 condicionantes de monitoramento hídrico distintas nos 38 empreendimentos. A mina e a barragem de rejeito, os dois processos com mais condicionantes hídricas, somam 31 delas. O material ligado a cada condicionante tem mediana de 180 mil caracteres, e 17 grupos passam de 500 mil.

A espiada evitou um erro de divisão antes que ele custasse. A primeira ideia de Caio era dividir por documento, uma subchamada por arquivo. A contagem de tamanhos mostrou que 23 dos 190 estudos de impacto passam de 500 mil caracteres e que 1.100 atas e planilhas têm menos de 2 mil caracteres cada. Dividir por documento mandaria textos grandes demais para uma ponta e milhares de chamadas quase vazias para a outra.

Medir as datas completou o mapa. Os relatórios de monitoramento vão de 2012 a 2026, com picos trimestrais. As condicionantes mudam de número a cada renovação de licença, e 9 dos 38 empreendimentos renovaram a licença pelo menos uma vez no período. Esse detalhe voltaria mais tarde, quando um laudo citasse a condicionante pelo número antigo.

O reconhecimento inteiro custou centavos. Foram seis turnos do modelo raiz, contando o que propôs as divisões, com histórico médio de 12 mil tokens por turno e 700 tokens de saída. A preços de referência do GPT-5, o raiz do artigo (US$ 1,25 por milhão de tokens de entrada e US$ 10 por milhão de saída): 72 mil tokens de entrada custam US$ 0,09, e 4.200 de saída custam US$ 0,04. Total perto de US$ 0,13, sem nenhuma subchamada.

Com o mapa pronto, Caio desenhou duas divisões candidatas. A primeira corta o acervo em blocos fixos de 200 mil caracteres, cerca de 50 mil tokens, e manda cada bloco a uma subchamada. A segunda forma um grupo por condicionante, com o texto da condicionante, os laudos e os pareceres que citam seu número, e divide de novo os 17 grupos grandes demais.

Helena pediu um ensaio antes de qualquer execução no acervo inteiro: rodar as duas divisões nos dois empreendimentos com mais condicionantes hídricas, a mina e a barragem, cerca de 900 mil tokens, contra uma lista de referência escrita por ela. A escolha do recorte foi deliberada. É o mesmo material que o teste de contexto longo já tinha usado, o que permite comparar as três leituras sobre a mesma base.

A Veredas saiu do reconhecimento com um mapa: 214 condicionantes, 17 grupos grandes demais para uma subchamada e um filtro que antes perdia quase um quinto das menções. Anote, para as duas divisões candidatas, quantas subchamadas cada uma dispara na mina e na barragem e quantos tokens lê; a divisão que passar de 40 subchamadas nesse recorte está fina demais para o ensaio.