Definir o problema e construir quatro alternativas comparáveis

Com o parecer aprovado, Helena pediu a Caio o que muito piloto pula: a prova de que o RLM ganhou de alternativas montadas com o mesmo cuidado. Comparar um sistema novo, ajustado por semanas, contra um sistema antigo deixado como estava infla o ganho. Os sócios da Veredas, e depois os clientes, fariam a pergunta que derruba esse tipo de resultado: e se o RAG tivesse recebido a mesma atenção?

Sem essa prova, a recomendação vira opinião de quem construiu o protótipo. Com ela, vira uma medida que outra pessoa refaz. A diferença aparece no dia em que um cliente contesta um número e a consultoria precisa mostrar de onde ele saiu.

Ao terminar, você escreve a ficha de um problema com critério de sucesso fechado antes da primeira linha de código e monta quatro alternativas que respondem às mesmas perguntas sob o mesmo registro de custo, tempo e evidência. A avaliação e a recomendação ficam para o fechamento do projeto.

Por que o critério vem antes da primeira linha de código

Toda avaliação honesta depende de uma régua fixada antes do resultado. A equipe de pesquisa da Vetto, liderada por Arthur Kamienski, resume a exigência em três palavras: um bom teste é difícil, justo e válido. Difícil porque os sistemas bons ainda erram nele. Justo porque premia a resposta correta e só a resposta correta. Válido porque mede o que diz medir. O texto trata de benchmarks em geral e não fala de RLM, mas as três palavras servem de régua para o projeto.

No projeto da Veredas, justo quer dizer que uma resposta com o número certo e a evidência errada não conta como acerto. Válido quer dizer que as 120 perguntas se parecem com as que os clientes fazem, e não com as que o sistema responde bem. Difícil está garantido pelo próprio RAG anterior, que erra 56 das 120 perguntas.

Para garantir a validade, Helena não inventou perguntas do zero. Partiu de dois anos de e-mails de clientes, separou os pedidos que envolviam monitoramento hídrico e reescreveu cada um como pergunta fechada, com resposta que se confere no acervo. Onde a resposta dependia de julgamento técnico, como decidir se dois laudos discordam de fato ou só usam métodos diferentes, ela registrou a regra de decisão junto da referência, para que o corretor não precisasse adivinhar.

Unidade de resposta é o formato mínimo que a correção aceita, e defini-la cedo evita discussão sem fim. Na Veredas, uma resposta sem empreendimento, condicionante, situação e documento com página está incompleta, mesmo que o texto em volta esteja correto. Essa exigência favorece sistemas que guardam o rastro, e Helena a manteve de propósito: é o que o órgão ambiental cobra da consultoria quando pede a comprovação de uma condicionante.

Mudar a régua depois de ver o placar é a forma mais comum de enganar a si mesmo sem perceber. Armadilha comum: afrouxar o critério de acerto quando o sistema preferido erra por pouco, aceitando “quase certo” numa contagem. Em licenciamento, uma condicionante a menos na contagem é uma obrigação esquecida diante do órgão ambiental. Por isso Helena escreveu a ficha, assinou e datou antes de Caio rodar qualquer alternativa.

Execução interrompida pelo teto conta como erro, e essa regra pesa mais do que parece. O artigo do RLM descreve trajetórias de custo e tempo com cauda longa: a mediana fica comparável ao modelo base e a média sobe por causa de poucas execuções muito caras. Se a execução que estoura o teto fosse simplesmente descartada, o RLM ganharia pontos justamente nas perguntas em que ele se perde.

Com a ficha fechada, a régua fica igual para todos. Cada alternativa responde às mesmas 120 perguntas, na mesma ordem, com o mesmo corretor e o mesmo teto de tempo. Nenhuma recebe perguntas extras para ajuste, e nenhuma pode pular uma pergunta difícil. O placar final só compara o que foi medido do mesmo jeito.

Quatro alternativas construídas com o mesmo cuidado

Caio montou quatro sistemas. O primeiro é o RAG em produção, o “buscar, depois gerar” que descende do artigo de Lewis e colegas de 2020: recupera trechos parecidos com a pergunta e entrega ao modelo. Antes de aceitá-lo como linha de base, Caio deu a ele uma rodada de ajuste, subindo de 5 para 10 o número de trechos recuperados. O placar ficou nos mesmos 64 de 120, e o registro dessa tentativa entrou no projeto.

Contexto longo numa chamada foi a segunda alternativa, e ela esbarra no tamanho antes de chegar à qualidade. As 52 janelas do acervo não cabem numa chamada, então ela só concorre em perguntas cujo material cabe em 1 milhão de tokens. O número de referência continua o do recorte da mina e da barragem: 31 de 50 em agregação, lendo cerca de 900 mil tokens por pergunta.

A ficha tira o contexto longo da disputa geral por outra via, antes mesmo da qualidade. Ler 900 mil tokens no Opus 5.5, a US$ 4 por milhão, custa 0,9 vezes 4, ou US$ 3,60 por pergunta só de entrada. O teto escrito na ficha é de US$ 1,00. A alternativa fica no projeto como referência de qualidade no recorte em que cabe, e o registro diz por que ela não concorre ao uso.

Terceira alternativa, o RLM otimizado na trilha de custo roda sobre o acervo inteiro, com 93 de 120, US$ 0,41 por pergunta e mediana de 1 min 50 s. A quarta é nova: um híbrido que manda as perguntas de localização ao RAG e, nas de agregação e cruzamento, usa uma busca por metadado para escolher os empreendimentos envolvidos antes de entregar ao RLM só os documentos deles.

Uma pergunta simples orientou o desenho: se o sistema consegue saber em quais empreendimentos a resposta está, por que lê os outros? Nenhuma peça do híbrido é nova em si. A mudança está em dar a cada peça o trabalho em que ela é boa. A busca escolhe o recorte, o RLM lê o recorte inteiro e o RAG continua achando documentos, como fazia antes. Cada peça continua sujeita ao próprio erro, e o registro comum mostra qual delas falhou em cada pergunta.

Como a Veredas construiu o híbrido sem trapacear na comparação

Olhando os rastros do RLM otimizado, Caio achou a ideia do híbrido. Em boa parte das perguntas de agregação, o modelo raiz gastava as primeiras iterações descobrindo quais empreendimentos importavam, espiando nomes e filtrando pastas por expressão regular. Esse trabalho uma busca por metadado faz em milissegundos, porque cada documento já traz empreendimento, tipo e data. Entregar ao RLM só o recorte certo reduziria as iterações e o ruído.

Roteador é o componente que decide para qual sistema cada pergunta vai, como a triagem de um pronto-socorro. Caio podia usar os rótulos que Helena escreveu nas 120 perguntas, mas isso seria trapaça: em produção ninguém rotula a pergunta do cliente. Ele usou um classificador com um modelo barato, e o erro do classificador passou a contar no placar do híbrido. Nas 120 perguntas, o classificador acertou o tipo em 114.

Busca por metadado filtra por campos exatos, como empreendimento, tipo de documento e data. A busca vetorial procura trechos de texto parecidos com a pergunta, como quem acha um livro pelo assunto e não pelo número na estante. Para escolher empreendimentos, o filtro exato ganha, porque a pergunta costuma nomear o empreendimento ou a região. Quando não nomeia, o híbrido manda ao RLM os três mais prováveis e registra a escolha, para que um erro de recorte apareça no rastro.

No código, o híbrido ficou curto. O trecho abaixo mostra a estrutura, com o nome atual do parâmetro de iterações no DSPy, max_iters, que substituiu max_iterations na versão 3.3.0. O sub_lm recebe um modelo mais barato para as subchamadas, como recomenda a documentação, e max_llm_calls limita quantas vezes o código pode chamar o modelo numa pergunta.

Cada alternativa grava o mesmo registro por pergunta: custo em dólares, tempo de parede, trajetória quando existe e a evidência citada. Helena exigiu esse formato comum porque, sem ele, a comparação vira quatro relatórios com quatro vocabulários. A execução roda em sandbox isolado, com o documento tratado como dado, nunca como instrução, conduta herdada da trilha de segurança.

Para esse registro, cada biblioteca oferece um caminho. No rlms, o RLMLogger grava cada execução em JSONL e há um visualizador local. No DSPy, o resultado traz a trajectory, com o raciocínio, o código e a saída de cada passo. Caio converteu as duas saídas para uma tabela comum com pergunta, alternativa, custo, tempo, evidência citada e acerto, que Helena corrige numa planilha sem abrir código.

Quanto ao ambiente, o intérprete padrão do DSPy é Deno com Pyodide, um sandbox WASM. Depois da análise da Cyera sobre fugas de sandboxes Pyodide em outros produtos, Caio rodou tudo dentro de um contêiner sem acesso à rede além da API do modelo, somando o isolamento do sistema operacional ao do WASM, como a própria Cyera recomenda.

O cuidado com a linha de base tem apoio nos números do próprio artigo do RLM. Na Tabela 1, o Claude Code sobe de 12,0 para 62,0 no CodeQA quando o contexto vai para um arquivo, e o OpenCode sobe de 0,0 para 94,0 no BrowseComp-Plus. A mesma ferramenta, configurada de outro jeito, muda de patamar. Uma linha de base mal configurada faz qualquer alternativa nova parecer genial, e um comitê que conhece esse efeito desconfia de ganhos grandes demais.

Havia um viés que a Veredas não conseguiu eliminar, e o projeto o registrou em vez de escondê-lo. As 120 perguntas foram usadas durante a otimização de custo, então o RLM e o híbrido foram ajustados olhando para elas. Helena decidiu que a recomendação final valeria para o piloto, mas seria confirmada nas primeiras perguntas reais de clientes, que nenhum sistema viu antes.

No cenário da Veredas, as quatro alternativas ficaram prontas para rodar sobre as mesmas 120 perguntas, com um registro comum e uma ficha que ninguém pode reescrever depois. Escreva a ficha do seu próprio problema antes de qualquer código: pergunta de negócio, unidade de resposta, critério de acerto, teto de custo e teto de tempo. A ficha está pronta quando outra pessoa consegue corrigir uma resposta usando só ela, sem perguntar nada a você.