Escolher onde o RLM entra primeiro e decidir o piloto

Com os quatro cenários no painel, a pergunta desce do mercado para a mesa de Helena: em que trabalho o RLM entra primeiro? Escolher mal custa de dois jeitos. Um piloto em perguntas de localização gasta dinheiro para empatar com o RAG, que já acerta 36 de 40 nesse tipo contra 37 de 40 do protótipo recursivo. Um piloto num problema que cabe na janela gasta meses para provar o que uma chamada de contexto longo resolveria.

O custo menos visível é político. Um piloto que empata vira argumento contra a próxima tentativa, mesmo quando a próxima seria a certa. Por isso a escolha do problema pesa mais que a escolha da biblioteca, e merece um documento próprio, com pressupostos que alguém consegue contestar.

Ao terminar, você separa aplicações candidatas pelo formato da pergunta e pelo tamanho do material, pesa custo, latência, rastro e risco antes de aprovar um piloto e escreve um parecer de adoção que diz de antemão quais números fariam a decisão mudar. O caso é o parecer que Helena assinou para a Veredas.

Que tipo de problema favorece a recursão

Quem formulou a pergunta com mais cuidado foram os próprios autores do RLM. Zhang, Kraska e Khattab mostram ganho em tarefas densas em informação, aquelas em que a resposta depende de ler quase tudo: contar ocorrências, agregar rótulos, cruzar pares. No OOLONG, com 131 mil tokens, o GPT-5 base marca 44,0 e o RLM com profundidade 1 marca 56,0. No OOLONG-Pairs, que pede cruzamento de pares, o salto vai de 0,1 para 58,0 de F1.

F1 é uma nota que combina acerto e cobertura, como avaliar um fiscal pelo que ele apontou certo e pelo que deixou passar. Nas perguntas de localizar um trecho, o quadro se inverte. Na reprodução independente de Daren Wang, os modelos base acertam 100% no S-NIAH, a busca de uma agulha num palheiro, e o DeepSeek v3.2 com RLM cai para 85% na profundidade 1 e 70% na profundidade 2, com a latência subindo de 3,6 para 89,3 segundos.

Há mais dois limites documentados. A Prime Intellect registrou que o RLM piora o ambiente de matemática com Python, e o SRLM da Apple observou que, dentro da janela nativa, a recursão muitas vezes degrada em relação ao modelo base. Juntando as peças, o RLM ganha quando a pergunta agrega ou cruza e quando o material passa da janela. Nos demais casos, empata ou perde, e cobra mais tempo.

Acervos maiores que a janela formam o outro lado da condição. No BrowseComp-Plus com 1.000 documentos, entre 6 e 11 milhões de tokens, o GPT-5 base marca 0,0 porque o material não cabe, e o RLM de profundidade 1 marca 91,3 ao custo médio de US$ 0,99. O artigo compara esse valor à conta de ingerir tudo no GPT-5-mini, de US$ 1,50 a US$ 2,75. Na mesma tabela, o OpenCode com o contexto em arquivo marcou 94,0, lembrando que o concorrente do RLM em acervo grande também inclui o agente de código bem configurado.

Fora do licenciamento ambiental, o mesmo filtro separa bem outros acervos. Uma auditoria de contratos que pergunta quantos têm cláusula de reajuste vencida agrega. Uma revisão de registros de atendimento que procura reclamações contraditórias sobre o mesmo pedido cruza pares. Uma área jurídica que só quer achar a cláusula de foro de um contrato localiza. As duas primeiras são candidatas; a terceira fica na busca, por maior que seja o arquivo.

Escolher pelo tamanho do acervo, e não pelo formato da pergunta, é o erro que mais desperdiça piloto. Armadilha comum: ver 52 milhões de tokens e concluir que tudo ali pede recursão. Na Veredas, 40 das 120 perguntas do conjunto de avaliação são de localização, e para elas a busca já resolve. O tamanho diz se o material cabe na janela; o formato diz se a leitura precisa ser completa. As duas perguntas juntas definem o quadrante.

Como pesar custo, latência, rastro e risco antes do piloto

Passar no filtro de formato e tamanho abre a porta; quatro contas decidem se vale entrar. A primeira é valor contra custo por pergunta. O artigo mostra que a mediana do RLM sai mais barata que a do modelo base, mas a média sobe por causa de trajetórias fora da curva, com desvio-padrão maior que a própria média em vários casos. Quem orça pela média de dez perguntas de demonstração não enxerga a cauda que aparece na centésima.

Tempo é a segunda conta. O blog do autor fala em “alguns segundos a vários minutos” por consulta, sem garantia de teto. Um atendimento que precisa responder ao cliente em tempo real não aceita isso; um parecer técnico com prazo de dias aceita. Rastro vem em terceiro: o RLM guarda a trajetória de cada execução, o que permite mostrar de qual documento saiu cada número. Em licenciamento ambiental, resposta sem evidência vale pouco diante do órgão.

Na Tabela 1 do artigo, o RLM com GPT-5 e profundidade 2 no OOLONG custa US$ 1,10 de média com desvio-padrão de US$ 3,25. A média engana nos dois sentidos: boa parte das perguntas sai mais barata que ela e algumas saem muitas vezes mais caras. Para o orçamento do piloto, a pergunta útil é quanto custa a pergunta do percentil 95 e se o teto de chamadas corta essa cauda antes da fatura.

Risco fecha as quatro contas. O RLM escreve e executa código sobre documentos que vêm de terceiros, e o README da biblioteca oficial avisa que o ambiente local não serve para produção. No estudo de Samuel Korn, com GPT-5-mini e um único documento envenenado, o ataque teve sucesso em 24,4% das vezes contra o RLM e em 81,9% contra o RAG simples. É um resultado de um modelo e um conjunto de perguntas, e não autoriza dispensar o sandbox isolado.

Na prática, isolar significa escolher onde o código gerado roda. A biblioteca oficial separa os ambientes não isolados (local, IPython e Docker) dos que rodam em sandbox na nuvem: Modal, Prime Intellect, Daytona e E2B. O DSPy usa por padrão Deno com Pyodide, um sandbox WASM local. A Cyera mostrou em agosto de 2026 fugas de sandboxes Pyodide em sete produtos, sem testar o dspy.RLM. A leitura prudente é somar o isolamento do sistema operacional ao do WASM.

Como a Veredas escreveu o parecer de adoção

Helena começou pelo recorte. Das 120 perguntas do conjunto de avaliação, 80 são de agregação ou cruzamento e 40 de localização. Nas 80, o RAG anterior acerta 28 (21 de agregação e 7 de cruzamento), e o RLM otimizado acerta 56. Nas 40 de localização, os dois ficam a um ponto de distância. O parecer recomendou um piloto de 90 dias só com perguntas de monitoramento hídrico que agregam ou cruzam, mantendo o RAG para localizar documentos.

Caio contestou a exclusão das perguntas de localização, porque o protótipo acertava uma a mais que o RAG. Helena mostrou a conta ao contrário: um acerto em 40 não paga minutos de espera por resposta nem o custo do RLM sobre perguntas que a busca responde em segundos. O ponto entrou no parecer como decisão, com a conta ao lado, para que ninguém o reabra sem número novo.

Pressupostos vieram em seguida, cada um escrito com o número que ele assume. Volume: 120 perguntas por mês de agregação e cruzamento, estimativa de Helena pelo histórico de pedidos dos clientes. Custo: 120 vezes US$ 0,41 dá US$ 49,20 por mês de chamadas. Trabalho humano: cada resposta passa por revisão de evidência, estimada em 10 minutos, o que soma 1.200 minutos, ou 20 horas por mês. Esse é o custo que o parecer mais destaca, porque é maior que a fatura de API.

Profundidade também entrou no parecer como decisão de projeto, tomada antes do primeiro teste. No artigo, a profundidade 1, em que as subchamadas são modelos comuns, é o padrão. Mais profundidade não melhora de forma consistente: no GPT-5 ajuda no OOLONG-Pairs e piora no CodeQA, e no Qwen3-Coder piora o OOLONG. Na reprodução de Wang, a latência do DeepSeek v3.2 foi de 89,3 para 344,5 segundos ao passar da profundidade 1 para a 2. O piloto da Veredas fixou profundidade 1.

Noventa dias saíram de uma conta de amostra. Com 120 perguntas por mês, o piloto acumula cerca de 360 perguntas reais, três vezes o conjunto de avaliação, e passa por três retestes mensais. É o bastante para ver se a acurácia se sustenta fora das perguntas que Helena escreveu, e curto o bastante para que um erro de escolha custe pouco: 360 vezes US$ 0,41 dá US$ 147,60 em chamadas.

Cada pressuposto ganhou um indicador e um limiar que muda a decisão. Caio insistiu que o limiar fosse escrito antes do piloto começar, para ninguém ajustá-lo depois de ver o resultado. Helena acrescentou uma linha que vem do painel de cenários: se um modelo novo acertar mais de 38 de 50 perguntas de agregação no recorte de 900 mil tokens, a escolha de arquitetura reabre, mesmo com o piloto indo bem.

Nos sócios, a pergunta mais dura foi sobre o custo humano. Vinte horas por mês de revisão pareciam muito até Helena mostrar que a alternativa era cruzar laudos à mão, trabalho que hoje ninguém faz por completo porque não cabe na agenda. O parecer foi aprovado com uma condição dos sócios: a revisão de evidência cai para uma amostra de 30% se, depois de dois meses, menos de 5% das respostas vierem sem evidência.

Ficou registrado também o que o parecer não cobre. Perguntas sobre fauna, atas e pareceres de órgão ambiental continuam no RAG até que um segundo recorte temático passe pelo mesmo filtro de formato e tamanho. Ampliar o piloto sem esse filtro repetiria o erro que o parecer quis evitar desde o começo: escolher pelo tamanho do acervo.

No cenário da Veredas, o piloto nasceu estreito de propósito: 80 das 120 perguntas, uma área temática e seis limiares escritos antes do primeiro teste. Liste as três perguntas de negócio mais caras do seu acervo, classifique cada uma em localizar, agregar ou cruzar e anote se o material cabe numa janela de 1 milhão de tokens. Só as que agregam ou cruzam acima da janela entram na lista do piloto; se nenhuma entrar, o RLM ainda não é o seu problema.