RLM 2027 · Capítulo 14 de 24 · 14 min
Baixar o custo por pergunta e vigiar o que a média esconde
Filtrar o índice por código antes de delegar, agrupar chamadas independentes e acompanhar percentis levou o custo da Veredas de US$ 0,86 para US$ 0,41.
Este capítulo faz parte do curso gratuito RLM 2027. Para marcar como concluído e salvar o progresso, abra este capítulo na página do curso.
Com a cauda cortada e o custo médio em US$ 0,72, sobrou a execução comum, a US$ 0,571, e o rastro mostrava onde ela gastava: turnos do raiz espiando e refiltrando o índice, subchamadas lendo documentos que um filtro melhor teria descartado, leituras em fila. A mediana continuava em 3 min 40 s, tempo demais para Helena responder a um cliente durante uma reunião.
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.
Estrutura contra código livre no estudo do λ-RLM
48,3% → 24,1%
OOLONG ao liberar código livre
Modelos abertos, contextos de até 128 mil tokens
62,4 s → 241,6 s
Latência na mesma troca
Quase quatro vezes mais espera
8,9× e 4,3×
Razão entre a execução mais lenta e a mais rápida
RLM padrão e λ-RLM, nessa ordem
29 de 36
Comparações vencidas pelo λ-RLM
Média de 26,1% para 45,5%; latência 4 vezes menor
Fonte: Roy et al., The Y-Combinator for LLMs, arXiv 2603.20105 (março de 2026); 9 modelos abertos e 4 benchmarks
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.
Seis alavancas de custo e o que cada uma arrisca
| Alavanca | O que reduz | O que pode piorar | Como medir |
|---|---|---|---|
| Submodelo mais barato (sub_lm) | Custo de cada subchamada | Leitura de documentos difíceis e comparações | Acurácia por tipo de pergunta, no conjunto inteiro |
| Raiz mais barato | Custo dos turnos e do histórico | Decomposição e cruzamento | Acurácia em cruzamento, no conjunto inteiro |
| Subchamadas em lote (llm_query_batched) | Tempo de espera | Limite de requisições do provedor | Mediana e percentil 95 de tempo |
| Ferramenta de índice (tools) | Voltas de exploração do raiz | Perguntas que o índice descreve mal | Voltas por execução e perguntas sem documento achado |
| Cache de prefixo | Custo de reler o histórico | Nada na qualidade; depende do provedor | Tokens de entrada lidos do cache |
| Modelo treinado para o papel | Tempo e custo de todas as partes | Exige dados, GPU e reavaliação | Mesmo conjunto, mesmo orçamento |
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.
import dspy
raiz = dspy.LM("openai/gpt-5") # US$ 1,25 / US$ 10 por milhão de tokens
leitor = dspy.LM("openai/gpt-5-mini") # US$ 0,25 / US$ 2 por milhão de tokens
dspy.configure(lm=raiz)
def listar_documentos(empreendimento: str, tipo: str = "", desde: str = "") -> str:
"""Devolve id, tipo, data e condicionante dos documentos que casam com o filtro."""
linhas = INDICE.filtrar(empreendimento=empreendimento, tipo=tipo, desde=desde)
return "\n".join(linhas) # ferramentas chamadas do sandbox devolvem texto
class ConsultaAcervo(dspy.Signature):
"""Responda sobre condicionantes do acervo. Consulte listar_documentos antes de ler.
Leituras independentes de documentos vão juntas numa chamada a llm_query_batched."""
acervo: str = dspy.InputField()
pergunta: str = dspy.InputField()
resposta: str = dspy.OutputField()
rlm = dspy.RLM(
ConsultaAcervo,
sub_lm=leitor, # subchamadas no GPT-5-mini, como no protótipo
tools=[listar_documentos], # índice do acervo ao alcance do código
max_iters=14,
max_llm_calls=50,
max_output_chars=4_000,
)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.
Veredas: execução comum antes e depois das duas mudanças
| Medida | Com os tetos | Com índice e lotes |
|---|---|---|
| Turnos do raiz | 10,5 | 7 |
| Raiz (GPT-5): entrada e saída | 80 mil e 14,1 mil tokens, US$ 0,241 | 56 mil e 9,8 mil tokens, US$ 0,168 |
| Subchamadas (GPT-5-mini) | 27 | 18 |
| Subchamadas: entrada e saída | 1 milhão e 40 mil tokens, US$ 0,33 | 720 mil e 20 mil tokens, US$ 0,22 |
| Custo da execução comum | US$ 0,571 | US$ 0,388 |
| Execuções na cauda | 20, a US$ 1,465 cada | 4, a US$ 1,02 cada |
| Média geral por pergunta | US$ 0,72 | US$ 0,41 |
| Tempo mediano | 3 min 40 s | 1 min 50 s |
| Acertos nas 120 perguntas | 93 | 93 |
Cenário ilustrativo. Antes: (100 × 0,571 + 20 × 1,465) ÷ 120 = 0,72. Depois: (116 × 0,388 + 4 × 1,02) ÷ 120 = 0,409.
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.
import time
def medir(rlm, raiz, leitor, **entradas):
"""Roda uma pergunta e devolve os campos que o painel guarda.
Use uma pergunta por vez em cada par de modelos: o histórico é compartilhado."""
n_raiz, n_leitor = len(raiz.history), len(leitor.history)
inicio = time.monotonic()
pred = rlm(**entradas)
novas_raiz = raiz.history[n_raiz:] # chamadas do raiz nesta execução
novas_leitor = leitor.history[n_leitor:] # subchamadas nesta execução
return {
"custo_raiz": sum(h.get("cost") or 0 for h in novas_raiz),
"custo_leitor": sum(h.get("cost") or 0 for h in novas_leitor),
"voltas": len(pred.trajectory),
"subchamadas": len(novas_leitor),
"segundos": round(time.monotonic() - inicio, 1),
"no_teto": len(pred.trajectory) >= rlm.max_iters,
}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.
Veredas: distribuição nas 120 perguntas, linha de base depois das mudanças
| Medida | Mediana | Percentil 90 | Percentil 95 | Máximo |
|---|---|---|---|---|
| Custo por pergunta | US$ 0,36 | US$ 0,52 | US$ 0,61 | US$ 1,12 |
| Tempo por pergunta | 1 min 50 s | 3 min 10 s | 4 min 20 s | 8 min (tempo-limite) |
| Subchamadas | 17 | 26 | 31 | 44 |
Cenário ilustrativo. A média de custo, US$ 0,41, fica acima da mediana por causa das quatro execuções da cauda.
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.
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.
- Etapa 1 de 5: Registrar cada execução
Seis campos tirados do rastro e do histórico dos modelos
- Etapa 2 de 5: Calcular os percentis da semana
Mediana, 90 e 95 de custo, tempo e subchamadas
- Etapa 3 de 5: Comparar com a linha de base
A rodada de 93 acertos em 120, a US$ 0,41 por pergunta
- Etapa 4 de 5: Abrir o rastro das execuções no teto
Ver em que volta o raiz se perdeu e por quê
- Etapa 5 de 5: Rodar as 120 perguntas antes de trocar algo
Modelo, prompt ou teto só mudam com placar novo
Dois jeitos de acompanhar o custo de um RLM
Otimizar pela média
Coluna a evitar
- Um número por mês, tirado da fatura
- Troca de modelo aprovada pelo custo, sem placar
- Execução de 15 minutos diluída no total
- Parada no teto misturada com resposta completa
Otimizar pela distribuição
Coluna recomendada
- Seis campos por execução, percentis por semana
- Troca aprovada só com as 120 perguntas rodadas
- Percentil 95 de tempo com alerta próprio
- Parada no teto contada e enviada à revisão
No cenário da Veredas, a pergunta passou a custar US$ 0,41, com mediana de 1 min 50 s e 93 acertos em 120; 400 perguntas por mês saem por cerca de US$ 164. O próximo risco mora no conteúdo que entra no REPL. Liste os tipos de documento do acervo escritos por terceiros e marque quais chegam ao sandbox sem revisão humana; o critério é ter essa lista fechada antes de ligar o sistema a qualquer pasta que guarde credenciais.
Seu caderno neste capítulo
Abrir o caderno completoSelecione um trecho do capítulo para destacar ou anotar. No teclado, selecione com Shift e as setas e use Alt+Shift+D para destacar ou Alt+Shift+N para anotar.
Salvo neste navegador. Entre na sua conta para levar o caderno a outros aparelhos.
Entre na sua conta para compartilhar o que aprendeu e convidar alguém para estudar com você.
Voltar ao capítulo anterior: Decompor o custo de uma execução e pôr teto em cada parte
Todos os capítulos de RLM 2027
- 01Descobrir onde o modelo encontra cada informação que usa
- 02Medir o limite real do contexto e dividir o problema
- 03Guardar o acervo numa variável e deixar o modelo programar a leitura
- 04Desenhar a árvore de chamadas e decidir a profundidade
- 05Explorar o acervo antes de decidir onde cortar
- 06Processar as partes e juntar as respostas sem perder a evidência
- 07Comparar contexto longo, RAG e compactação antes de escolher o RLM
- 08Situar agentes, híbridos e RLM numa matriz de decisão
- 09Julgar um benchmark antes de acreditar no número dele
- 10Comparar métodos nas mesmas condições e ler os resultados contrários
- 11Preparar o acervo e rodar a biblioteca oficial rlm
- 12Montar o protótipo com dspy.RLM e auditar o rastro de cada resposta
- 13Decompor o custo de uma execução e pôr teto em cada parte
- 14Baixar o custo por pergunta e vigiar o que a média esconde
- 15Isolar o código gerado e tratar cada documento como dado
- 16Impedir que o erro de uma folha chegue à resposta final
- 17Treinar um modelo pequeno para decidir quando delegar
- 18Provar uma auto-melhoria antes de acreditar nela
- 19Julgar as apostas de recursão aprendida e execução previsível
- 20Mapear híbridos, imagem e trabalho prolongado com evidência e lacuna
- 21Ler 2027 por sinais observáveis em vez de apostar numa previsão
- 22Escolher onde o RLM entra primeiro e decidir o piloto
- 23Definir o problema e construir quatro alternativas comparáveis
- 24Avaliar as alternativas e dizer em quais condições o RLM compensa