Como montar o projeto de comparação

Exemplo: O projeto final reúne as decisões anteriores em uma pergunta de negócio delimitada. Você escolhe o acervo autorizado, prepara respostas de referência e compara leitura direta, busca, RLM e uma combinação quando fizer sentido. O caso da Veredas fornece um exemplo fictício; os resultados do seu projeto precisam vir da sua mediçã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 confiável depende de um critério fixado 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 critério 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 o critério 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, o critério 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.

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.

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. Como extensão opcional do seu projeto, separe desde o início um conjunto selado, que nenhuma otimização toca, e aplique o protocolo de Rodar o laço com conjunto selado.

Entregue a definição da tarefa, as versões das alternativas e o protocolo de avaliação antes de medir. Explique o que cada solução recebe e o que pode fazer. O próximo capítulo usa os resultados para escrever uma recomendação proporcional à evidência.