Preparar o acervo e rodar a biblioteca oficial rlm

Com o protocolo assinado por Helena, Caio precisava de algo que rodasse sobre o acervo de verdade. O acervo, porém, não era texto: eram PDFs, planilhas de laboratório e atas digitalizadas, parte delas escaneada nos primeiros anos. O RLM lê o que estiver na variável que recebe, e mais nada.

Pular a preparação produz o pior tipo de erro, o silencioso. Um laudo escaneado sem camada de texto vira uma string vazia, o modelo raiz conta zero laudos naquele poço e responde com segurança que a condicionante está vencida. A resposta sai bem escrita, com documento citado, e errada.

Ao terminar, você sabe transformar um acervo heterogêneo no formato que a biblioteca oficial espera, escolhe entre os sete ambientes de execução que ela oferece e lê o resultado de uma execução com tokens, tempo e custo na mão.

Por que a preparação do acervo decide metade do resultado

No RLM, o prompt do usuário vai para uma variável chamada context dentro do REPL, e o modelo raiz começa sem ver o conteúdo. Recebe só metadados: o tipo da variável, o total de caracteres e o tamanho de cada pedaço. Tudo o que ele sabe sobre o acervo, descobre escrevendo código. Por isso o formato do acervo guia a exploração tanto quanto o prompt guia uma resposta comum.

Alex Zhang, no blog de outubro de 2025, descreve os primeiros movimentos que o modelo raiz costuma fazer: espiar o começo do texto e filtrar linhas com palavra-chave ou expressão regular. Expressão regular: um padrão de busca escrito em código, como pedir “toda linha que tenha LO seguido de número”. Os dois movimentos só funcionam se o acervo tiver marcas estáveis para espiar e filtrar.

Caio deu a cada documento um cabeçalho de uma linha, sempre no mesmo formato, com identificador, empreendimento, tipo, data e origem do texto. Com isso, uma única expressão regular separa os laudos de um empreendimento em milissegundos, sem gastar nenhuma subchamada. O cabeçalho custa cerca de 120 caracteres por documento, perto de 768 mil no acervo inteiro (6.400 vezes 120), uma fração desprezível do total.

Tamanho pede outra conta, e ela define a arquitetura. Na aproximação de 4 caracteres por token, que Caio conferiu numa amostra do acervo, os 52 milhões de tokens viram cerca de 208 milhões de caracteres. A função llm_query aceita cerca de 500 mil caracteres por chamada, segundo o prompt da própria biblioteca. Ler o acervo inteiro numa pergunta exigiria umas 416 subchamadas (208 milhões divididos por 500 mil).

Em dinheiro, a mesma leitura completa custaria cerca de US$ 13 só de entrada no GPT-5-mini (52 milhões de tokens a US$ 0,25 por milhão), antes de qualquer saída. Esse número fixa a regra de ouro do laboratório: o modelo raiz precisa recortar com código antes de delegar leitura, e o cabeçalho existe para tornar esse recorte barato.

Aqui aparece a armadilha comum de quem monta o primeiro protótipo: descartar em silêncio o documento que não tem texto. Na Veredas, 1.150 dos 6.400 documentos eram PDFs escaneados sem camada de texto, quase 18% do acervo (1.150 divididos por 6.400), a maioria laudos de laboratório anteriores a 2016. Caio rodou OCR, o reconhecimento de caracteres que transforma imagem de página em texto, e recuperou 1.112. Os 38 restantes entraram com um aviso no lugar do conteúdo.

Um dicionário é aceito como prompt pela biblioteca. Quando o prompt é texto puro, ela grava um arquivo .txt e o lê para a variável; quando é dicionário ou lista, grava em JSON e carrega a estrutura. Caio preferiu o dicionário porque a chave é o próprio identificador do documento, e citar evidência vira ler a chave.

A alternativa seria juntar os 6.400 documentos numa única string e deixar o modelo raiz separá-los pelo cabeçalho. Funciona, mas obriga o modelo a escrever e acertar essa separação a cada pergunta, e um erro de expressão regular ali contamina tudo o que vem depois. Com o dicionário, o recorte por empreendimento é uma compreensão de lista de uma linha, e o custo fica na preparação, feita uma vez só.

Como Caio rodou a biblioteca oficial sobre o acervo da Veredas

A biblioteca do artigo fica no repositório alexzhang13/rlm, mantido pelo laboratório MIT OASYS, com licença MIT e 5.641 estrelas em 23 de setembro de 2026. O pacote no PyPI se chama rlms, pede Python 3.11 ou superior e está na versão 0.1.3, de 26 de junho de 2026. O GitHub ainda exibe uma tag v1.0.0 de janeiro, anterior às versões 0.x; a numeração do PyPI é a que vale para instalar.

Clientes de modelo cobrem OpenAI, Anthropic, OpenRouter e Portkey, e modelos locais entram pelo vLLM através do cliente da OpenAI. A escolha que mais pesa, porém, é o ambiente: onde o código escrito pelo modelo vai rodar. O README separa três ambientes não isolados de quatro isolados, que rodam em sandbox na nuvem, e avisa que o ambiente local não deve ser usado em produção.

Caio escolheu o Docker para o desenvolvimento. O contêiner roda na máquina dele, com uma cópia do acervo que nunca sai da rede da Veredas, e o código gerado não toca o sistema de arquivos do computador. O README coloca o Docker entre os não isolados, e Caio registrou essa ressalva no protocolo: nenhum documento de cliente iria para um ambiente de nuvem antes da revisão de segurança.

O ambiente local ficou restrito a documentos públicos de teste por um motivo concreto. Ele executa o código gerado com exec dentro do próprio processo, e o README avisa do risco quando prompts ou chamadas de ferramenta podem ser tocados por usuários mal-intencionados. No acervo da Veredas, boa parte do texto veio de terceiros: laboratórios, órgãos ambientais, empreiteiras. Qualquer um deles poderia ter escrito num PDF uma frase que o modelo leria como instrução.

Três parâmetros merecem leitura. O max_depth=1 reproduz o padrão do artigo: o modelo raiz chama modelos comuns, sem REPL próprio; com esse valor, rlm_query recai em llm_query. O other_backends manda as subchamadas para o GPT-5-mini, e o root_prompt deixa o modelo raiz ver a pergunta sem ver o acervo. O max_timeout interrompe a execução e devolve a melhor resposta parcial disponível.

Dentro do REPL, o modelo raiz encontra a variável context, as funções llm_query e llm_query_batched, as recursivas rlm_query e rlm_query_batched, a função SHOW_VARS, que lista as variáveis criadas, e o dicionário answer. O prompt da biblioteca avisa que saídas acima de cerca de 20 mil caracteres são truncadas. Por isso o modelo imprime amostras e contagens, e manda o texto longo para as subchamadas.

Existe também um max_budget, em dólares, mas a documentação do código avisa que ele exige um cliente que informe custo, como o OpenRouter. Com o cliente da OpenAI, Caio calculou o custo por conta própria, multiplicando os tokens do usage_summary pelo preço congelado no protocolo.

Dois recursos ficaram desligados no primeiro teste. O parâmetro persistent reaproveita o ambiente entre chamadas, útil para conversa com várias perguntas encadeadas, e compaction resume o histórico do modelo raiz quando ele chega a 85% da janela. Caio preferiu medir primeiro a execução mais simples, uma pergunta por ambiente novo, para ter uma linha de base limpa antes de ligar qualquer otimização. O paralelismo das subchamadas recursivas segue o padrão de max_concurrent_subcalls, quatro linhas de execução.

Encerrar a execução mudou de nome entre o artigo e a biblioteca. O artigo descreve FINAL(resposta) e FINAL_VAR(variável). Na versão 0.1.3 do pacote, o prompt de sistema entrega ao modelo um dicionário answer: ele grava a resposta em answer["content"] e marca answer["ready"] como verdadeiro, e a execução termina ali. Quem escreve um prompt de sistema próprio copiando o artigo, com FINAL, arrisca uma execução que a biblioteca não reconhece como encerrada e que gasta as 30 iterações.

O primeiro teste foi uma pergunta de agregação sobre um empreendimento só. O modelo raiz seguiu os padrões que o blog descreve. Espiou, filtrou os 212 documentos de Serra Azul pelo cabeçalho e estreitou para 57 com termos como poço, piezômetro e qualidade da água. Só então delegou leitura, em 14 subchamadas agrupadas. As datas foram comparadas em Python, sem modelo nenhum, e a resposta listou três condicionantes vencidas com cinco documentos citados.

Custo e tempo saíram do usage_summary e do execution_time. O modelo raiz fez 9 turnos com cerca de 12 mil tokens de entrada cada, 108 mil no total, e 1.500 de saída por turno. As 14 subchamadas leram cerca de 45 mil tokens cada e escreveram mil. A conta, com os preços do protocolo, fecha em US$ 0,46 por essa pergunta, em 2 minutos e 50 segundos.

O usage_summary separa as contas por modelo, e essa separação foi a primeira surpresa de Caio. Ele esperava que a leitura dos documentos, feita pelo GPT-5-mini, dominasse o custo. Nessa pergunta, o modelo raiz custou US$ 0,27 e as subchamadas US$ 0,19: o modelo caro, lendo pouco, pesou mais que o barato lendo muito. A conta só aparece quando o custo sai separado por modelo.

Helena abriu os cinco documentos citados e confirmou as três condicionantes. Mais útil que o acerto foi o arquivo de log: pela primeira vez ela via o caminho da resposta, com cada filtro e cada lote. O mesmo arquivo mostrou que 2 dos 57 documentos filtrados tinham o aviso de texto ilegível e que o modelo raiz os listou à parte, em vez de contá-los como laudo ausente.

A pergunta sobre Serra Azul também mostrou o limite do teste. Um empreendimento só, com 212 documentos, fica longe do caso difícil do protocolo, que cruza laudos de empreendimentos diferentes ao longo de 14 anos. Uma execução boa diz que a montagem funciona; ela não diz nada ainda sobre as 120 perguntas, e Caio escreveu isso no relatório do dia para ninguém confundir teste de fumaça com resultado.

Caio saiu do teste com o acervo preparado, o ambiente escolhido e uma execução de ponta a ponta com custo calculado. Rode agora as dez primeiras perguntas do conjunto na mesma configuração e anote tempo, custo e número de subchamadas de cada uma. O critério é que as dez terminem com answer["ready"] antes de 20 minutos; o passo seguinte é dar à resposta um formato tipado e um rastro que Helena consiga auditar sozinha.