Julgar um benchmark antes de acreditar no número dele

Com a matriz de decisão pronta, a Veredas tinha um candidato forte para o RLM e nenhuma prova de que ele funcionaria no acervo dela. Os artigos citam ganhos de dois dígitos, mas cada número nasceu de um modelo, de um conjunto de perguntas e de um orçamento que não são os da consultoria.

Comprar a técnica pelo número do artigo expõe a empresa a dois erros opostos. Helena pode pagar por uma melhora que aparece em textos sintéticos de 131 mil tokens e some em pareceres escaneados. Ou pode descartar o método porque um teste mal montado o reprovou. Nos dois casos, a resposta dela ao cliente fica sem base.

Ao terminar, você separa um benchmark difícil de um justo e de um válido, reconhece as cinco famílias de teste usadas no artigo de Zhang, Kraska e Khattab e sabe qual delas se parece com cada tipo de pergunta do seu próprio acervo.

Por que a régua importa mais do que o número

Benchmark: um conjunto fixo de perguntas com resposta conhecida, como uma prova que todos os candidatos fazem igual. Em 22 de setembro de 2026, a equipe de pesquisa da Vetto, liderada por Arthur Kamienski, publicou um texto sobre o que torna essa prova útil. A Vetto vende avaliação de IA e conjuntos de dados, e o texto não fala de RLM. Ele trata de qualquer avaliação, e por isso dá a régua para ler os números desta trilha.

Três qualidades aparecem no texto. Difícil quer dizer que os modelos de ponta ainda falham; prova que todos gabaritam não separa ninguém. Justo quer dizer que a prova premia a resposta correta e só ela, sem aceitar acerto por atalho nem punir quem responde certo com outras palavras. Válido quer dizer que a prova mede o que diz medir: uma pergunta sobre leitura de documentos que o modelo acerta de memória mede memória.

Os autores defendem que a maioria dos benchmarks “endurecidos” perde justiça e validade no caminho. Endurecer é tornar a prova mais difícil de propósito, e a forma mais barata de fazer isso é inserir pegadinhas. A pegadinha derruba o modelo, mas derruba pelo motivo errado: ele erra porque a pergunta tem duas leituras, e a nota cai sem dizer nada sobre a capacidade medida.

Daí vem a armadilha comum: tratar a dificuldade como prova de qualidade. Uma equipe que escreve perguntas mais tortas a cada rodada até o sistema antigo errar consegue um teste difícil e injusto ao mesmo tempo. A Vetto acrescenta que autoria de especialista não resolve sozinha: o especialista também escreve pergunta ambígua quando ninguém revisa a resposta de referência.

Ler com essa régua muda o peso de números conhecidos. O post de Alex Zhang de outubro de 2025 mostrou o RLM com GPT-5-mini superando o GPT-5 em mais de 34 pontos no OOLONG a 132 mil tokens, um aumento de cerca de 114%. O próprio autor chamou o resultado de experimento preliminar. O ganho é real naquela condição, e a condição é estreita: um modelo, uma família de teste, um tamanho de texto.

Tamanho de amostra pesa do mesmo modo. No artigo, o OOLONG-Pairs tem 20 itens, e cada item vale 5 pontos percentuais da nota (100 dividido por 20). Uma diferença de 10 pontos entre dois métodos cabe em dois itens. Isso não anula o resultado, mas pede cautela antes de extrapolar, e a cautela cresce quando a execução é única, como na reprodução independente de março de 2026.

Subconjuntos pequenos aparecem até nos resultados mais citados. No post de outubro de 2025, o teste com mil documentos do BrowseComp-Plus, mais de 10 milhões de tokens, usou 20 consultas sorteadas, e o autor frisou que o recorte é pequeno. O RLM com GPT-5 não degradou ali. O dado vale como sinal forte de escala, e continua sendo um sinal medido em 20 perguntas.

Cinco perguntas bastam para ler qualquer número desta trilha. Qual modelo fez a raiz e qual fez as subchamadas? Qual família de teste e quantos tokens por item? Quantos itens e quantas execuções? Qual custo, com mediana e dispersão, e não só a média? Contra qual alternativa, lida com as mesmas regras? Um número que responde às cinco pode entrar na decisão; um que responde a duas entra como pista.

As cinco famílias de teste e o que cada uma exige do modelo

Na versão 3 do artigo, de maio de 2026, o RLM é medido em cinco famílias. Cada uma exige um tipo diferente de trabalho sobre o texto, e o ganho do RLM muda de família para família. Saber a família de uma pergunta prevê melhor o resultado do que o tamanho do documento.

S-NIAH é a sigla de agulha única no palheiro: um fato plantado num texto longo, que o modelo precisa achar. A resposta depende de um trecho só; o resto do texto é ruído. O artigo usa 50 itens. É a família em que o RLM menos tem a oferecer, porque achar um trecho é trabalho de busca, e a reprodução de Daren Wang registrou queda de acerto quando se trocou o modelo direto pelo RLM.

OOLONG, de Bertsch e colegas (novembro de 2025), mede agregação: a resposta depende de rotular muitas entradas do texto e combinar os rótulos, como contar quantas perguntas de uma lista pertencem a cada categoria. No artigo RLM, os itens têm 131 mil tokens e são 50. Os autores do OOLONG relatam que GPT-5, Claude Sonnet 4 e Gemini 2.5 Pro ficam abaixo de 50% nos dois recortes a 128 mil tokens.

OOLONG-Pairs pede pares de entradas que atendem a uma condição. O trabalho cresce com o quadrado do número de entradas: 100 entradas formam 4.950 pares (100 vezes 99, dividido por 2). A métrica é F1, uma nota que combina quantos pares certos o sistema achou e quantos dos pares que ele listou estavam certos. São 20 itens de 32 mil tokens, e o GPT-5 sozinho marca 0,1.

BrowseComp-Plus, de Chen e colegas (agosto de 2025), congela um corpus de documentos para testar agentes de pesquisa profunda com as mesmas fontes para todos. No artigo RLM, cada item traz mil documentos, de 6 a 11 milhões de tokens, em 150 itens. O próprio BrowseComp-Plus registra o GPT-5 com busca BM25 (ranqueamento clássico por palavra-chave) em 55,9% e com o recuperador Qwen3-Embedding-8B em 70,1%.

CodeQA vem do LongBench v2, de Bai e colegas (dezembro de 2024), que reúne 503 questões com contextos de 8 mil a 2 milhões de palavras. São perguntas sobre repositórios de código, e no artigo RLM os itens vão de 23 mil a 4,2 milhões de tokens. A resposta exige entender como partes distantes do código se ligam, o que mistura busca e raciocínio.

Duas medidas organizam as famílias. A primeira é quanto do texto a resposta precisa usar: um trecho, no S-NIAH, ou quase todas as entradas, no OOLONG. A segunda é o tamanho da entrada frente à janela do modelo. O RLM foi desenhado para o canto em que as duas crescem juntas, e a síntese das fontes aponta nessa direção: ele ganha em tarefas densas em informação e quando a entrada passa da janela.

Como a Veredas montou as 120 perguntas que decidem o piloto

Helena começou com 146 perguntas candidatas, tiradas de pedidos reais de clientes ao longo dos 14 anos do acervo. Para cada uma escreveu a resposta de referência e os documentos que a sustentam. Caio então passou as 146 pelos três critérios da Vetto, um de cada vez, e registrou por que cada pergunta saía.

Escrever referência leva tempo. Helena gastou cerca de 25 minutos por pergunta, entre achar os documentos, conferir datas e redigir a resposta, o que somou perto de 61 horas de trabalho (146 vezes 25, dividido por 60). Esse custo explica por que o conjunto tem 120 perguntas e não mil: cada pergunta a mais consome hora de quem decide, e a Veredas preferiu poucas perguntas bem escritas a muitas com referência duvidosa.

Seis saíram por falta de dificuldade. A resposta estava no título do próprio documento, e qualquer busca por nome acertaria; manter essas perguntas inflaria a nota de todos os métodos por igual. Onze saíram por injustiça: a palavra “vencida” tinha duas leituras, prazo da licença ou prazo do laudo, e a referência de Helena aceitava só uma. Ela reescreveu a definição para todas as perguntas que ficaram: vencida é a condicionante cujo prazo passou sem laudo protocolado.

Nove saíram por invalidez. A resposta dependia de e-mails e conversas que nunca entraram no acervo, então a pergunta media a memória de Helena, não a leitura dos 6.400 documentos. Para checar o outro lado da validade, Caio fez dez perguntas do conjunto a um modelo sem acesso ao acervo. Nenhuma saiu certa, sinal de que a nota não viria do conhecimento de treino do modelo. Sobraram 120 perguntas (146 menos 6, 11 e 9).

Cada tipo de pergunta ganhou uma família de referência. As 40 de localização se parecem com o S-NIAH: um laudo, uma data, um número de condicionante. As 50 de agregação se parecem com o OOLONG, porque pedem contar ou somar condicionantes por empreendimento. As 30 de cruzamento se parecem com o OOLONG-Pairs, porque pedem pares de laudos que se contradizem. A escala do acervo, 52 milhões de tokens, lembra o BrowseComp-Plus e passa 52 vezes uma janela de 1 milhão.

A pontuação seguiu a família. Localização e agregação valem acerto ou erro, com número exato nas contagens. Cruzamento vale F1, porque a resposta é uma lista de pares e um par a mais ou a menos não pode zerar a pergunta inteira. Toda resposta precisa citar o identificador do documento que a sustenta; sem essa citação, Helena não consegue assinar o parecer, e a pergunta conta como errada mesmo com o texto certo.

Essa tabela já adiantava o que esperar. O RAG acerta 36 de 40 em localização, a família em que as fontes mostram o RLM empatando ou perdendo. Onde ele cai é agregação e cruzamento, as famílias em que o artigo mostra os maiores saltos. Helena decidiu que a nota total nunca seria lida sozinha: cada relatório traria as três linhas separadas, para que um ganho em cruzamento não escondesse uma perda em localização.

A Veredas terminou com uma régua em que um resultado bom ou ruim diz algo sobre a leitura do acervo. Abra agora a sua lista de perguntas e anote, ao lado de cada uma, a família parecida e a métrica. Se mais de um terço cair na família de agulha, como as 40 de 120 da Veredas, reserve o RLM para o restante e prepare-se para medir o método contra alternativas nas mesmas condições.