Desenhar a árvore de chamadas e decidir a profundidade

Com o acervo guardado numa variável, o modelo raiz precisa de quem leia os pedaços por ele. Cada leitura delegada é uma subchamada, e o conjunto delas forma uma árvore: o raiz no topo, as subchamadas embaixo e, às vezes, subchamadas das subchamadas.

O formato dessa árvore decide custo, tempo e acerto. Uma árvore rasa demais põe pedaços grandes demais em cada folha e repete o problema do contexto longo. Uma árvore funda demais multiplica chamadas e minutos, e cada nível acrescenta uma chance de erro. E uma resposta montada no lugar errado sai cortada ou sai como plano em vez de resultado.

Ao terminar, o leitor sabe quais funções delegam a leitura e em que diferem, o que a profundidade mede e o que os números do artigo dizem sobre subir de nível. Sabe também como cada implementação devolve a resposta final e por que esse detalhe falha com frequência. A Veredas desenha e roda a árvore de uma pergunta real sobre a PCH.

Subchamadas, as funções com que o modelo raiz delega a leitura

Subchamada é uma chamada a outro modelo feita de dentro do código do REPL, como um coordenador que entrega uma pasta a um assistente e espera o resumo. Na biblioteca oficial rlms existem quatro formas. llm_query manda um texto a um modelo comum e recebe a resposta. llm_query_batched faz o mesmo com uma lista de textos, em paralelo.

As outras duas sobem um degrau. rlm_query entrega o pedaço a um sub-RLM, que ganha o próprio REPL e pode delegar de novo. rlm_query_batched faz isso em paralelo. O paralelismo é limitado pelo parâmetro max_concurrent_subcalls. No DSPy, o dspy.RLM oferece llm_query e llm_query_batched, e o parâmetro sub_lm escolhe o modelo das subchamadas; a documentação recomenda um modelo mais barato.

A divisão de papéis entre modelos pesa no custo. Na configuração principal do artigo, o GPT-5 com raciocínio médio fica no topo e o GPT-5-mini faz as subchamadas. Pelos preços de referência de setembro de 2026, o GPT-5 cobra US$ 1,25 por milhão de tokens de entrada e o GPT-5-mini, US$ 0,25. Como quase toda a leitura acontece nas subchamadas, o modelo barato paga a maior parte da conta.

Quantas subchamadas uma execução faz depende muito do modelo raiz. No artigo, o GPT-5 fez da ordem de dez subchamadas por pergunta. O Qwen3-Coder-480B fez centenas a milhares num problema simples, e cerca de 500 em média nas trajetórias corretas do OOLONG. Os autores precisaram acrescentar uma linha ao prompt do Qwen3-Coder, porque sem ela o modelo disparava milhares de subchamadas para problemas básicos.

Nos experimentos do artigo, todas as chamadas eram bloqueantes e sequenciais: cada uma esperava a anterior terminar. O próprio blog de outubro de 2025 descreve consultas que levam de alguns segundos a vários minutos, sem garantia de custo total nem de tempo total. As versões em lote e o limite de concorrência da biblioteca existem para cortar esse tempo de espera.

O DSPy põe tetos padrão contra a execução sem fim. O parâmetro max_llm_calls limita a 50 as subchamadas por execução, e max_iters limita a 20 os turnos do REPL antes da extração de reserva. Quem encontrar código antigo com max_iterations deve saber que o nome mudou para max_iters no DSPy 3.3.0, de agosto de 2026. O código antigo precisa de ajuste para rodar nas versões atuais.

Quantos níveis descer e como devolver a resposta final

Profundidade é quantos níveis de RLM a árvore admite. Na profundidade 0 não há subchamada: o modelo raiz usa só o REPL, com código e expressões regulares. Na profundidade 1, as subchamadas são modelos comuns, e esse é o padrão do artigo. Acima de 1, as subchamadas são RLMs com REPL próprio. O artigo escreve a configuração como RLM(model, depth=N).

A intuição diz que mais níveis dão mais capacidade. A tabela principal da versão 3 do artigo, com GPT-5 no topo e GPT-5-mini nas subchamadas, desmente a intuição em parte. No OOLONG-Pairs, que exige cruzar pares de trechos, a profundidade 3 foi a melhor, com F1 de 76,0. No CodeQA, a profundidade 3 marcou 58,0, abaixo dos 66,0 da profundidade 2. F1 é uma nota que pesa ao mesmo tempo o que o sistema acertou e o que deixou de achar.

No Qwen3-Coder, subir de nível piorou o OOLONG: 48,0 na profundidade 1, 26,0 na 2 e 32,0 na 3. Os autores atribuem a queda a erros de sintaxe que se propagam para os sub-RLMs. No CodeQA com o mesmo modelo, a profundidade 0, sem nenhuma subchamada, marcou 66,0 e superou todas as variantes com subchamadas. O resultado vale para esses modelos e esses testes, e nada garante que se repita em outro acervo.

O custo também oscila com a profundidade. No OOLONG com GPT-5, a profundidade 2 custou em média US$ 1,10 por pergunta, com desvio-padrão de US$ 3,25. Desvio-padrão maior que a média quer dizer que a maioria das execuções saiu barata e algumas saíram muito caras. O artigo descreve essas trajetórias como de cauda longa e alta variância, e a trilha de custo volta a esse número.

Uma reprodução independente, publicada por Daren Wang em março de 2026, mediu o preço em tempo. Com DeepSeek v3.2 no teste S-NIAH e 20 amostras por condição, a resposta levou 3,6 segundos no modelo base, 89,3 na profundidade 1 e 344,5 na profundidade 2. O Kimi K2 chegou a 545,5 segundos por consulta na profundidade 2. Armadilha comum: tratar profundidade como botão de inteligência. Cada nível multiplica chamadas e minutos, e o ganho de acerto aparece em alguns testes e some em outros.

Resta devolver a resposta. No artigo, a execução termina quando o modelo define a resposta final: FINAL(texto) para uma resposta curta escrita direto, FINAL_VAR(nome) para devolver uma variável montada no REPL. A segunda forma permite saídas maiores que a janela do modelo, como uma tabela com todas as condicionantes de um acervo. O DSPy usa SUBMIT(...), e tanto a biblioteca rlms na versão 0.1.3 quanto o desenho da Prime Intellect encerram quando o modelo marca answer["ready"] como verdadeiro.

Os autores registram que distinguir resposta final de pensamento é frágil: às vezes o modelo entrega o plano de trabalho como se fosse o resultado. O dado de treino confirma o problema. Ao preparar o RLM-Qwen3-8B, 16 por cento dos turnos usavam FINAL de forma errada e 13 por cento usavam FINAL_VAR de forma errada, e os autores precisaram de uma correção programática para consertar o formato.

Para a Veredas, a escolha entre as duas formas tem efeito direto. Uma resposta à pergunta de negócio lista condicionantes, empreendimentos, prazos e o código de cada documento de evidência. Em 38 empreendimentos, essa tabela pode passar de dezenas de milhares de caracteres. Escrita pelo modelo raiz num turno, ela sairia resumida ou cortada. Montada numa variável e devolvida por FINAL_VAR, ela sai inteira, com cada linha rastreável.

Como a Veredas desenhou a árvore de uma pergunta sobre a PCH

Helena escolheu o menor empreendimento com histórico de problema: a PCH Ribeirão Claro, com 140 documentos e cerca de 1,1 milhão de tokens. A pergunta foi a de negócio, restrita a um lugar: “quais condicionantes de monitoramento hídrico da PCH estão vencidas ou com laudos contraditórios, e com que evidência?”. A resposta de referência dela tinha 11 condicionantes hídricas, 3 vencidas e 1 com laudos contraditórios.

Caio fixou profundidade 1, com um modelo raiz forte e um modelo barato nas subchamadas, e rodou. O modelo raiz usou quatro turnos. No primeiro, mediu o acervo pelos cabeçalhos. No segundo, filtrou os 140 documentos da PCH e, dentro deles, os que citavam condicionante e água, turbidez ou vazão: sobraram 23. No terceiro, mandou os 23 em lote a subchamadas, pedindo de cada um a condicionante, o prazo e a data do último laudo.

No quarto turno, o raiz agrupou os registros por ponto de coleta e comparou os laudos de um mesmo trimestre. A execução devolveu 11 condicionantes, 3 vencidas e 1 contradição: dois laudos de turbidez do mesmo ponto, no mesmo trimestre de 2025, com valores incompatíveis. Cada linha trazia o código do documento de origem. Helena conferiu contra a referência e bateu nas três contagens.

A execução inteira levou 1 minuto e 20 segundos. A maior parte do tempo foi das 23 subchamadas, que rodaram em lote e em paralelo; o modelo raiz gastou poucos segundos em cada turno. Se as subchamadas tivessem rodado uma depois da outra, como nos experimentos do artigo, a mesma árvore passaria de cinco minutos pela estimativa de Caio.

O ponto que mais impressionou Helena foi o filtro. Das 140 peças da PCH, só 23 foram lidas por um modelo; as outras 117 foram descartadas por código, pelo cabeçalho e por palavra-chave. Caio lembrou o risco: um documento de condicionante sem as palavras do filtro ficaria de fora sem aviso. Por isso ele imprimiu a lista dos 117 descartados por tipo, e Helena a revisou em dez minutos.

Helena ainda abriu cinco dos códigos de documento citados na tabela, escolhidos ao acaso, e leu os trechos originais. Os cinco sustentavam a linha em que apareciam. Esse gesto de conferência, abrir a evidência e comparar, é o que separa uma resposta rastreável de uma resposta apenas convincente, e ele só é possível porque cada linha carrega a origem.

Os dois discutiram então a pergunta de negócio completa, sobre os 38 empreendimentos. A primeira ideia de Caio foi profundidade 2: um rlm_query por empreendimento, cada sub-RLM repetindo a árvore da PCH. A conta assustou. Com 38 sub-RLMs e cerca de 24 subchamadas cada, seriam perto de 900 chamadas por pergunta, 18 vezes o teto padrão de 50 do dspy.RLM. O custo ficaria perto de US$ 9,90, se cada sub-RLM custasse o mesmo que a PCH.

Helena pediu a alternativa rasa, e Caio a desenhou em profundidade 1. Um único filtro por código sobre os 6.400 cabeçalhos separa os documentos de condicionantes hídricas de todos os empreendimentos, e cada documento filtrado ganha uma subchamada. A árvore fica mais larga e menos funda. Qual das duas acerta mais é uma pergunta de medição, e a próxima trilha trata de como explorar o acervo e dividir o trabalho antes de rodar.

A Veredas ganhou sua primeira execução rastreável: 4 turnos, 23 subchamadas, cerca de US$ 0,26 e as três contagens batendo com a referência de Helena. Rode agora a mesma árvore em mais dois empreendimentos e anote quantas subchamadas cada execução fez; se alguma passar de 50, o filtro do segundo turno está largo demais e precisa de outro critério.