Como reduzir desperdício e acompanhar a operação

Exemplo: Depois de limitar as execuções extremas, Caio investiga o trabalho repetido: filtros refeitos, documentos lidos sem necessidade e tarefas que poderiam ocorrer em paralelo. O objetivo é reduzir desperdício mantendo a qualidade medida. As contas da Veredas continuam sendo uma simulação; cada equipe precisa usar preços e volumes do próprio contrato.

Otimizar às cegas tem custo próprio. Trocar o modelo raiz por um mais barato sem medir de novo pode derrubar as perguntas de cruzamento, justamente as que justificaram o RLM no lugar do RAG. E acompanhar só a média de custo esconde a execução que volta a durar 15 minutos depois de uma atualização do provedor, até o cliente reclamar.

Ao terminar, você sabe quais alavancas baixam o custo de uma execução recursiva, em que ordem testá-las e como medir cada uma contra o conjunto de avaliação. Também monta um painel mínimo por execução (custo por modelo, voltas, subchamadas, tempo e teto atingido) que avisa quando a distribuição muda antes da fatura chegar.

Onde a otimização rende numa execução recursiva

A primeira alavanca vem do próprio desenho do artigo. Zhang, Kraska e Khattab rodaram o GPT-5 como raiz e o GPT-5-mini em todas as subchamadas; nos preços da OpenAI, o mini custa US$ 0,25 por milhão de tokens de entrada contra US$ 1,25 do GPT-5, cinco vezes menos. A documentação do dspy.RLM diz o mesmo sobre o parâmetro sub_lm: use ali um modelo mais barato. A Veredas usa esse arranjo desde o protótipo, e por isso o peso que sobrou estava no raiz.

Paralelismo é a segunda. As chamadas do artigo eram bloqueantes e sequenciais, e os autores atribuem a cauda de tempo a subchamadas em fila. No DSPy, llm_query_batched recebe uma lista de prompts e os executa de forma concorrente; na biblioteca rlms, rlm_query_batched faz o mesmo com sub-RLMs, limitado por max_concurrent_subcalls. Paralelizar mantém os tokens e corta a espera: dez leituras de 6 segundos em paralelo terminam perto de 6 segundos, longe dos 60 da fila.

Um atalho até o material certo é a terceira. Quando o raiz só conhece o tamanho do contexto, ele gasta iterações espiando e filtrando. Uma ferramenta que devolve o índice do acervo (tipo, data e empreendimento de cada documento) troca duas ou três voltas de exploração por uma consulta. No DSPy, ferramentas entram pelo parâmetro tools, como funções Python que o código do sandbox chama pelo nome e que devolvem texto.

Estrutura reduz custo e variância ao mesmo tempo, e há número publicado sobre isso. No estudo do λ-RLM, com nove modelos abertos e contextos de 8 mil a 128 mil tokens, deixar o modelo escrever código livre derrubou o OOLONG de 48,3% para 24,1% e subiu a latência de 62,4 s para 241,6 s. A razão entre a execução mais lenta e a mais rápida foi de 8,9 vezes no RLM padrão e 4,3 vezes no λ-RLM. A condição limita a leitura: só modelos abertos, nenhum de fronteira fechado.

Cache de prefixo é a quarta alavanca, e ela depende do provedor. Cache de prefixo: o provedor guarda o começo da conversa já processado e cobra menos para lê-lo de novo, como um leitor que marca a página em vez de reler o livro. O raiz relê o mesmo começo a cada iteração, o caso ideal. Na Anthropic, a leitura de cache custa 0,1 vez o preço de entrada na maior parte dos modelos. O blog original listava a falta desse cache entre as limitações da implementação.

Toda alavanca mexe na qualidade junto com o custo, e o conjunto de avaliação é o único juiz. Armadilha comum: testar um modelo mais barato, no raiz ou nas subchamadas, só nas perguntas fáceis e declarar vitória. Ler um documento isolado tolera um modelo menor; comparar dois laudos com metodologias diferentes pode não tolerar. A Prime Intellect relatou que o RLM piorou o ambiente math-python em relação ao modelo sozinho, e a reprodução de Daren Wang viu o Kimi K2 cair de 86,6% para 60,0% no OOLONG ao virar RLM.

Existe uma quinta alavanca, fora do alcance da maioria das equipes hoje: treinar o modelo para o papel. O RLM-Qwen3-8B, ajustado pelos autores do artigo, ficou mais de três vezes mais rápido que o Qwen3-8B sem ajuste usado como RLM. A trilha de treinamento trata desse caminho; aqui basta saber que parte do custo vem de um modelo que não foi feito para operar o REPL.

Testar as alavancas numa ordem ajuda porque elas interagem. Primeiro entram as que não mexem na qualidade, como o lote e o cache; depois a ferramenta, que muda o comportamento do raiz; por último a troca de modelo, sempre com a rodada completa do conjunto. Cada rodada leva uma mudança só. Duas mudanças juntas impedem saber qual delas moveu o placar, e o placar de 120 perguntas é pequeno demais para separar efeitos misturados.

Como a Veredas foi de US$ 0,72 para US$ 0,41

Caio começou pelo rastro que tinha anotado. Numa execução comum, dos 10,5 turnos do raiz, 4 serviam só para espiar e refiltrar o índice, muitas vezes por causa das grafias diferentes de condicionante que já tinham derrubado 11 perguntas no protótipo. Das 27 subchamadas, cerca de um terço lia documentos que não entravam na resposta. A execução comum custava US$ 0,571: US$ 0,241 no raiz (80 mil tokens lidos e 14,1 mil escritos) e US$ 0,33 nas subchamadas (1 milhão lido e 40 mil escritos).

A primeira mudança tirou o filtro das mãos do modelo. O acervo já tinha, desde a preparação, um índice com tipo, data, empreendimento e condicionante de cada um dos 6.400 documentos. Caio normalizou nele as grafias de condicionante e o expôs como a função listar_documentos, que o código do sandbox chama com filtros. O raiz passou de 10,5 para 7 turnos, e as subchamadas, de 27 para 18, lendo 720 mil tokens em vez de 1 milhão. As execuções da cauda, acima de US$ 1, caíram de 20 para 4.

Antes de adotar, Caio rodou as 120 perguntas. A normalização recuperou três perguntas que o filtro por regex perdia, e a ferramenta custou outras três, de documentos que o índice descrevia mal. O placar ficou em 93. Pela conta dos tokens, a execução comum foi a US$ 0,388: US$ 0,168 no raiz (0,056 × 1,25 + 0,0098 × 10) e US$ 0,22 nas subchamadas (0,72 × 0,25 + 0,02 × 2).

As quatro execuções que ficaram na cauda tinham um traço em comum: eram perguntas de cruzamento sobre a PCH, cujos documentos mais antigos tinham entrado no acervo digitalizados e sem tipo no índice. O raiz não encontrava os laudos pelo filtro e voltava a espiar o texto bruto. Helena pôs a correção do índice desses documentos na fila do estagiário; até lá, as quatro seguem marcadas para revisão quando param em algum teto.

Caio testou também um raiz mais barato. O blog de Alex Zhang relatou o RLM com GPT-5-mini superando o GPT-5 em mais de 34 pontos no OOLONG a 132 mil tokens, num experimento preliminar. Com o GPT-5-mini no raiz, a execução comum da Veredas cairia de US$ 0,388 para cerca de US$ 0,25, mas o placar foi de 93 para 85, com seis das oito perdas em cruzamento. Helena vetou a troca: cruzamento é a razão de a Veredas ter um RLM.

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 segunda mudança custou uma frase. Parte das execuções ainda chamava llm_query em laço, um documento por vez, o padrão que tinha produzido a execução de 19 minutos. A docstring da assinatura passou a pedir que leituras independentes fossem juntas em llm_query_batched. Das 18 subchamadas, 12 passaram a sair em dois lotes de seis, de cerca de 12 segundos cada; seis seguem em sequência, a 4 s cada, porque dependem de uma leitura anterior. A conta: 7 turnos do raiz a 9 s, 2 lotes a 12 s e 6 leituras a 4 s dão 111 s. A mediana medida ficou em 1 min 50 s.

Lote tem um custo que não aparece na fatura. Seis chamadas simultâneas gastam de uma vez seis unidades da cota de requisições por minuto do provedor, e dez perguntas rodando ao mesmo tempo multiplicam isso por dez. Caio anotou a cota contratada ao lado do tamanho do lote, porque é ela que decide até onde o paralelismo rende antes de virar fila outra vez.

Caio considerou o cache de prefixo, que atacaria direto o custo de reler o histórico, e deixou para depois. Antes, precisava medir quanto do histórico do raiz se repete de uma volta para a outra na pilha da Veredas, e se o provedor escolhido reconhece esse começo como o mesmo. Uma alavanca sem medição de base ficaria sem como provar o ganho no conjunto de avaliação.

O painel que acompanha cada execução

Otimização sem monitoramento dura até a próxima troca de modelo pelo provedor. O painel da Veredas registra, por execução, seis campos: custo do raiz, custo das subchamadas, número de voltas, número de subchamadas, tempo total e se a execução parou em algum teto. Todos saem do rastro do dspy.RLM e do histórico que cada dspy.LM guarda das próprias chamadas, com poucas linhas de código.

Um detalhe da coleta evita número falso no painel. O campo de custo do histórico depende de a biblioteca conhecer o preço do modelo usado; quando ele vem vazio, a soma dá zero e a execução parece de graça. O painel da Veredas guarda também os tokens de entrada e de saída de cada chamada e recalcula o custo pela tabela de preços contratada, conferindo as duas contas uma vez por semana.

Percentis ocupam o lugar das médias no painel. O artigo do RLM apresenta custo e tempo nos percentis 25, 50, 75 e 95 exatamente porque a média engana numa distribuição de cauda longa. Na Veredas, a rodada de referência das 120 perguntas depois das mudanças virou a linha de base que toda semana seguinte é comparada.

Três regras de alerta saíram dessa tabela: percentil 95 de tempo acima de 5 minutos durante uma semana; mais de 5% das execuções paradas em algum teto; uma única pergunta acima de US$ 1,50. Cada alerta aponta para uma causa provável. Tempo subindo costuma ser modelo trocado ou limite de requisições; execuções no teto, perguntas de um tipo novo; custo isolado alto, um documento que o índice descreve mal. Alerta avisa, mas não corta: num agente que trabalha sem pausa, o gasto precisa de teto duro por dia, como mostra o capítulo Governar o agente contínuo.

O primeiro alerta disparou na terceira semana de uso interno: percentil 95 de tempo em 6 min 10 s, com custo e acurácia estáveis. O rastro mostrou lotes de seis subchamadas esperando a vez, porque o provedor tinha reduzido o limite de requisições por minuto da conta da Veredas. Caio pediu a cota anterior de volta e, com ela restabelecida, o percentil 95 voltou a 4 min 20 s. Sem o painel, a lentidão teria chegado como reclamação de cliente.

Altere uma variável por vez e repita o conjunto de avaliação. Registre qualidade, custo total e tempo, incluindo as falhas. Mantenha a mudança quando o ganho sobreviver à comparação e encaminhe a próxima decisão: quais documentos e recursos o código poderá alcançar.