Como acompanhar o caminho de uma resposta

Exemplo: Uma resposta bem escrita pode esconder uma leitura incompleta. O rastro de execução registra ações, chamadas, falhas e evidências utilizadas. DSPy é uma biblioteca para organizar programas com modelos de linguagem; seu módulo RLM oferece outra maneira de montar esse fluxo. O objetivo de Helena é conferir o caminho da conclusão sem precisar ler todo o código.

Sem isso, o protótipo acerta e ninguém assina. Helena responde ao cliente e ao órgão ambiental; uma condicionante declarada vencida sem o laudo que prova o vencimento vira retrabalho, e uma declarada em dia por engano vira multa. O acerto que não se audita vale pouco num parecer técnico.

Ao terminar, você configura o dspy.RLM com os parâmetros atuais, entende por que o nome do limite de iterações mudou em agosto de 2026 e lê a trajetória de uma execução para achar onde o tempo, o dinheiro e o erro apareceram.

Por que o rastro vale tanto quanto a resposta

Os autores do artigo RLM listam fragilidades que só aparecem olhando o caminho. O modelo às vezes entrega o plano como se fosse a resposta final. O Qwen3-Coder, sem uma linha extra no prompt, fazia milhares de subchamadas numa tarefa básica. Modelos de raciocínio estouravam o limite de saída com tokens de pensamento. Nenhum desses defeitos aparece na nota final; todos aparecem na trajetória.

DSPy é uma biblioteca de Stanford para montar programas com modelos de linguagem a partir de assinaturas, declarações curtas de entrada e saída como “pergunta -> resposta”. O módulo dspy.RLM entrou na versão 3.1.1, de 19 de janeiro de 2026, e a documentação ainda o marca como experimental, com o aviso de que a API pode mudar. A evolução desde então foi rápida, e ela importa para quem copia código de tutorial.

Antes de adaptar um tutorial, compare os parâmetros com a versão instalada. A API atual usa max_iters; exemplos com max_iterations precisam de ajuste. A documentação oferece o RLM como opção para programas que exploram o contexto com código, mas a escolha deve ser testada contra alternativas simples na tarefa da equipe.

O intérprete padrão executa Python por meio de Pyodide e Deno, com restrições de acesso ao sistema hospedeiro. Permissões adicionais e ferramentas da aplicação podem ampliar esse alcance. A alternativa LocalInterpreter traz aviso explícito de que não é um sandbox de segurança: use apenas código confiável nesse modo.

A fábrica de intérpretes exige cuidado em execução paralela. A documentação pede que ela devolva um intérprete novo a cada vez e que o PythonInterpreter fique na mesma linha de execução em que foi usado primeiro. Há uma versão assíncrona, chamada com await rlm.acall(...). Caio rodou as 120 perguntas em sequência no primeiro protótipo; pela mediana, isso leva perto de 7 horas e 20 minutos (120 vezes 3 minutos e 40 segundos), e a cauda acrescenta mais.

Dentro do sandbox, o modelo raiz encontra llm_query, llm_query_batched, print e SUBMIT, com as bibliotecas re, json, collections e math. SUBMIT encerra a execução com os campos da assinatura preenchidos. Cada implementação escolheu um nome diferente para esse gesto, e confundir os nomes leva a execuções que não reconhecem o próprio fim. Quem migra código entre as três implementações precisa trocar o gesto de encerramento junto com o import, porque o resto do código costuma funcionar sem aviso de erro.

O parâmetro max_output_chars reproduz a escolha central do artigo. Só 10 mil caracteres da saída de cada passo voltam ao histórico do modelo raiz. Se ele imprimir um laudo inteiro, verá só o começo; para ler o resto, precisa guardar o texto numa variável e passá-lo a uma subchamada. O limite força o trabalho por variáveis, que é o que mantém a janela do modelo raiz pequena mesmo com o acervo grande.

Como a Veredas leu o rastro das 120 respostas do primeiro protótipo

Caio tomou uma decisão de desenho antes de escrever o protótipo. A fábrica de intérpretes cria um sandbox novo a cada pergunta, e copiar 208 milhões de caracteres para dentro dele 120 vezes gastaria tempo antes de qualquer raciocínio. Ele passou ao sandbox só o índice, uma linha de cabeçalho por documento, e uma ferramenta que devolve o texto de um documento pelo identificador. O modelo raiz filtra o índice com código e busca só o que vai delegar.

A assinatura carrega a outra metade do desenho. Em “indice, pergunta -> resposta, evidencias: list[str]”, a saída tem dois campos, e o segundo é uma lista de textos, como no exemplo da documentação que devolve uma contagem e uma lista de erros críticos. O SUBMIT só encerra a execução com os dois campos preenchidos, e a lista de evidências pode ser conferida por programa antes de chegar a Helena.

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.

A ferramenta ler_documento roda fora do sandbox, e por isso Caio a fez recusar qualquer identificador fora do padrão. Sem essa linha, um texto malicioso escondido num documento poderia induzir o modelo a pedir um caminho como “../../credenciais”. A defesa completa contra instruções embutidas no acervo fica para a trilha de segurança; a validação do identificador custou uma linha e entrou já no protótipo.

O sub_lm aponta para o GPT-5-mini pela mesma razão do artigo, que usa GPT-5 na raiz e GPT-5-mini nas subchamadas: a documentação do DSPy recomenda um modelo mais barato ali. O modelo raiz decide o que ler e como juntar; as subchamadas leem trechos e extraem datas e números. Trocar o raiz por um modelo menor é outra decisão, com outro risco, e fica para a trilha de custo.

No cenário da Veredas, o protótipo acertou 94 das 120 perguntas: 37 de 40 em localização, 38 de 50 em agregação e 19 de 30 em cruzamento. O RAG fazia 64. O salto veio onde a trilha anterior previa: agregação foi de 21 para 38 e cruzamento de 7 para 19, enquanto localização ganhou uma pergunta. O custo médio ficou em US$ 0,86 por pergunta, a mediana de tempo em 3 minutos e 40 segundos, e a pior execução levou 19 minutos.

Os US$ 0,86 têm conta. Numa execução média, o modelo raiz fez 12 turnos de cerca de 15 mil tokens de entrada, 180 mil no total, a US$ 1,25 por milhão: US$ 0,225. Escreveu 24 mil tokens a US$ 10 por milhão: US$ 0,24. As 30 subchamadas leram 1,2 milhão de tokens a US$ 0,25 por milhão, US$ 0,30, e escreveram 45 mil a US$ 2, US$ 0,09. A soma dá US$ 0,855. Pouco mais da metade do custo estava no modelo raiz (US$ 0,465 de 0,855), e isso orienta a trilha de custo.

Todas as 94 respostas certas citavam documento, e o protocolo passou nos cinco limiares. Helena foi além e abriu a evidência de cada acerto. Em 88, o documento citado sustentava a resposta. Em 6, a resposta estava certa e a citação apontava para um documento vizinho, um laudo do mesmo poço de outro ano. Helena registrou esses 6 como acerto sem rastro, ressalva que entrou no relatório.

A primeira conferência foi automática. Um script de dez linhas cruzou cada identificador da lista de evidências com o índice, e nenhum identificador citado nas 94 respostas certas era inventado. Essa checagem barata elimina o erro mais grosseiro, a citação de documento que não existe, e deixa para Helena só a pergunta que exige leitura técnica: o documento citado prova o que a resposta diz?

Os 26 erros foram lidos um a um no rastro, e quatro causas explicaram todos. Em 11, o filtro por expressão regular perdeu documentos porque a mesma condicionante aparecia como “condicionante nº 14” e “cond. 14”. Em 8, uma subchamada extraiu a data errada de uma tabela mal convertida. Em 6, o modelo chamou SUBMIT com o plano no lugar da resposta, a fragilidade que o artigo descreve. Em 1, o teto de chamadas foi atingido.

A pior execução, de 19 minutos, era a do teto de chamadas. No sexto passo, o modelo raiz escreveu um laço que chamava llm_query para um documento de cada vez, em sequência. Chegou às 50 chamadas no décimo quarto passo, gastou os seguintes tentando contornar o limite e terminou pela extração de reserva, com resposta errada. O artigo aponta a mesma origem para a cauda de latência: subchamadas sequenciais.

O rastro também mostrou o que funcionou, e isso pesa tanto quanto os erros. Em 71 das 94 respostas certas, o modelo raiz filtrou o índice por código antes da primeira subchamada, delegou a leitura com llm_query_batched e fez as contas em Python. Esse caminho é o padrão que o blog de Alex Zhang descreve, e virou a referência contra a qual Helena compara qualquer trajetória nova: quando um rastro foge dele, alguém abre o arquivo.

Para achar esses casos sem ler 120 trajetórias inteiras, Caio escreveu uma triagem curta. Ela marca as perguntas com muitos passos, com SUBMIT logo no começo, sem evidência ou com llm_query dentro de laço. Helena lê primeiro as marcadas.

A biblioteca oficial oferece o mesmo tipo de leitura por outro formato. O RLMLogger grava um arquivo JSONL por execução: a primeira linha traz os metadados da configuração, e cada linha seguinte é uma iteração, com a resposta do modelo, os blocos de código, a saída e os erros de cada bloco, as subchamadas feitas e o tempo. O repositório traz um visualizador em Node.js que abre esses arquivos no navegador, por padrão na porta 3001 da própria máquina (localhost:3001).

Caio manteve as duas ferramentas no laboratório por razões diferentes. O dspy.RLM deu a assinatura tipada, o teto de chamadas por pergunta e o sandbox WebAssembly local. O pacote rlms deu os ambientes em contêiner e em nuvem, o registro em JSONL e o visualizador. O protótipo das 120 perguntas rodou no DSPy; a comparação de ambientes para produção vai usar o rlms, e o formato do registro dele virou o modelo do arquivo de rastros da Veredas.

Configure o orçamento compartilhado antes de executar o RLM com subagentes. No DSPy 3.4.1, o código do REPL pode criar outros módulos DSPy, inclusive um RLM interno. O limite max_llm_calls conta também as chamadas desses subagentes; ele limita chamadas subordinadas, mas não estabelece um teto financeiro para toda a execução.

Mantenha interpreter_factory=dspy.PythonInterpreter para os documentos do roteiro. Desde a versão 3.4.0, a troca de intérprete na chamada exige uma fábrica nomeada, que cria uma instância nova. LocalInterpreter dispensa Deno, mas permite acesso aos arquivos, às credenciais e à rede do usuário. O módulo RLM continua experimental.

Audite as promessas de uma campanha antes de encaminhar as correções para publicação. O RLM compara anúncios, páginas de destino e regras da oferta preservando cada origem. Isso ajuda quando o volume exige cruzar muitos documentos; para quatro peças, uma tabela revisada por uma pessoa já resolve.

O exemplo sintético usa uma loja de cursos com uma campanha de matrícula. Todas as peças tratam do mesmo produto, público e período. Duas divergências foram inseridas para mostrar o resultado esperado; o método precisa encontrá-las sem transformar informações compatíveis em erro.

A divergência indica onde investigar, mas não escolhe a oferta válida nem prevê venda. Datas incompletas e páginas antigas podem produzir falsos alertas. Avalie uma amostra revisada por uma pessoa antes de ampliar o acervo; registre erros, tempo e custo da revisão junto ao custo da API.

Escolha uma resposta correta e uma incorreta e reconstrua o percurso de ambas. Verifique referências, tentativas e saídas intermediárias. Aprove uma ferramenta de acompanhamento somente se ela permitir investigar erros e medir consumo sem expor documentos ou credenciais nos registros.