Avaliação de LLM: dos benchmarks públicos ao seu golden set

Quase todo argumento sobre avaliação é duas pessoas medindo coisas diferentes. Existem três projetos e eles não compartilham instrumento.

A confusão custa caro em uma direção. Um leaderboard diz que um model é forte em raciocínio de pós-graduação; ele não pode dizer se vai rotear seus tickets de suporte. E uma avaliação de aplicação que pontua uma resposta por input não consegue ver um agent, porque um agent tem uma distribuição de trajetórias e uma resposta é uma única amostra dela. O Capítulo 22 nomeou essa terceira linha e a deixou vazia: a medida de desempenho, a única parte da especificação de um agent que as equipes escrevem por último ou nunca escrevem.

A ordem também importa, e o fornecedor que vende o model para você diz isso. O guia de agents da OpenAI reduz a seleção de model a três etapas, nesta ordem: “Configure evals para estabelecer um baseline de desempenho”, “Concentre-se em atingir sua meta de accuracy com os melhores models disponíveis”, “Otimize custo e latência substituindo models maiores por menores quando possível”.¹ A avaliação vem primeiro, porque as etapas dois e três não significam nada sem um número.

Um golden set é uma lista de inputs, cada um com a resposta escrita, e um avaliador que decide se um output corresponde. É chato, é pequeno, e é o único artefato deste capítulo que é seu. O construído aqui tem vinte tarefas sobre um diretório de cinco arquivos — não os três do Capítulo 23, portanto as respostas não são as mesmas — e o avaliador é escrito antes de o agent rodar:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

Duas propriedades sustentam tudo. A lista mustNot existe porque um model que nomeia três arquivos incluindo o correto não respondeu. E answer é escrito em prosa além de padrões, porque uma pessoa e um judge precisarão dele depois — e escrever o mesmo fato duas vezes em duas notações é como você descobre que não concordava consigo mesmo sobre o que era a tarefa.

Agora a tabela que decide. Quatro sistemas candidatos, as mesmas vinte tarefas, accuracy com seu intervalo, e as duas colunas que uma tabela apenas de accuracies sempre esconde:

Leia os intervalos antes do vencedor. As execuções do braço B vão de 11% a 47%; as do braço A vão de 3% a 30%. Elas se sobrepõem na maior parte do caminho, que é a conclusão do Capítulo 4 chegando exatamente onde foi prometida: vinte casos não conseguem ranquear quatro sistemas. O Capítulo 15 refinou isso perguntando a questão pareada — nos casos em que dois braços discordam, quão desequilibrada é a divisão? — porque a dificuldade compartilhada do conjunto se cancela. Aqui está cada par:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

Nenhuma das seis comparações está estabelecida. O melhor braço vence o braço sem ferramentas por quinze pontos, e três casos discordantes é tudo o que sustenta isso. Vinte casos mostram um mecanismo e não conseguem escolher um fornecedor; dizer o contrário em uma reunião é como um model ruim acaba comprado.

Há uma coisa que esta tabela estabelece, e é a coluna que ninguém inclui. O braço D custa treze vezes o braço B por tarefa resolvida, porque amostrar três trajetórias e pegar a resposta modal triplica a conta, triplique ou não a accuracy. Tabelas de accuracy que omitem custo tornam essa troca invisível.

Agora a descoberta que muda como você lê todo benchmark que verá daqui em diante. Pegue as mesmas duzentas transcrições — vinte tarefas, dez execuções, sem regenerar um único token — e pontue-as de três formas:

Zero, treze, vinte e seis. O sistema não mudou. O avaliador mudou. A correspondência exata retorna zero não porque o agent é inútil, mas porque nenhuma resposta em texto livre é byte a byte idêntica a uma referência: ela mede formatação e a reporta como capacidade.

Isso não é uma curiosidade, é um mecanismo, e tem nome. Uma métrica de corte rígido pontua uma tarefa como tudo-ou-nada sobre vários subfatos, então ela compõe. A tarefa t12 pede três códigos de status de uma vez. Nas dez execuções:

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

Cada fato está certo cerca de três quartos das vezes; exigir os três de uma vez corta a pontuação pela metade, e $0.77^3 = 0.457$ é perto o suficiente dos 0,50 medidos para mostrar de onde veio a queda. Generalize:

Leia a linha 0,90 contra a linha 0,95 em $k = 10$: uma melhora por fato de cinco pontos vira vinte e cinco pontos na conjunção. Nada descontínuo aconteceu com o model. Uma curva suave lida por uma métrica tudo-ou-nada parece um salto — que é exatamente o argumento de Schaeffer, Miranda e Koyejo sobre habilidades emergentes, e que o Capítulo 10 adiou para cá.² A auditoria deles descobriu que no máximo 5 das 39 métricas preferidas do BIG-Bench exibem emergência, com duas métricas descontínuas respondendo por mais de 92% dos casos alegados.

Então a disciplina, em uma linha: um salto em um gráfico é evidência sobre a métrica até prova em contrário. Antes de acreditar que uma capacidade apareceu, plote as mesmas execuções com uma métrica que dá crédito parcial e veja se o penhasco sobrevive.

Há uma versão de segunda ordem disso que Kalai e colegas argumentam estar causando dano antes: benchmarks pontuados como certo-ou-errado recompensam chutar em vez de dizer “não sei”, então um model otimizado contra eles aprende a chutar. A correção proposta não é outro benchmark de alucinação, mas “modificar a pontuação de benchmarks existentes que estão desalinhados mas dominam leaderboards”.³ Seu golden set tem a mesma alavanca, e ela é uma linha: decidir se uma abstenção conta como falha ou como sua própria categoria. A maioria nunca decide, então ela conta silenciosamente como falha, e o sistema que eles lançam chuta.

Tudo até aqui pontuou uma tentativa por tarefa. Um agent não é uma tentativa. O Capítulo 17 estabeleceu que você não tem determinismo nem em temperatura zero, então o mesmo input produz uma distribuição de trajetórias e um benchmark que roda cada tarefa uma vez reporta uma amostra dela.

A contribuição do τ-bench é a métrica para isso. O artigo a define de forma direta: “propomos uma nova métrica – pass^k (pass hat k), definida como a chance de que todas as k tentativas i.i.d. da tarefa sejam bem-sucedidas, em média entre as tarefas”.⁴ Rode cada tarefa $n$ vezes, conte os $c$ sucessos, e os estimadores não viesados são:

O segundo é o conhecido pass@k da geração de código: a chance de que pelo menos uma de $k$ tentativas tenha sucesso. Coloque-os lado a lado nas mesmas contagens medidas e eles se movem em direções opostas:

Mesmas execuções, mesmo avaliador, mesmas vinte tarefas. Uma coluna diz que o sistema melhora com mais tentativas e a outra diz que ele piora, e ambas estão corretas, porque respondem a perguntas diferentes. pass@k é a métrica certa quando uma pessoa filtra o output — geração de código, rascunhos, brainstorming — e as tentativas extras são baratas. pass^k é a métrica certa quando o agent age sem filtro, que é o que “agent” significa. Publicar a primeira onde a segunda se aplica é o exagero mais comum nesta área, e a própria manchete do τ-bench é a versão honesta: gpt-4o em cerca de 61% pass^1 no varejo cai para cerca de 25% em pass^8.⁴

Agora a ferroada nos meus próprios números. pass^10 nas minhas vinte tarefas é 5,0%: exatamente uma tarefa em vinte resolvida em todas as dez execuções. Essa tarefa é t19, “O deploy 42 teve sucesso?”, e aqui estão duas das dez respostas que a rubrica pontuou como corretas:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

A primeira nunca responde. A segunda adiciona uma afirmação falsa — o deploy 41 sofreu rollback. Ambas corresponderam a /succe|yes/. A única tarefa mantendo pass^10 acima de zero é um artefato do avaliador, então o valor real é zero, e nenhum agregado teria me mostrado isso. Amostrar as transcrições por trás da sua tarefa de melhor pontuação é onde avaliadores vão morrer.

E mais um número, aquele que dá nome a esta seção. Dez avaliações idênticas — mesmo sistema, mesmas vinte tarefas, mesmo código, nada mudou além das seeds:

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

Um intervalo de trinta pontos em um sistema que não mudou. Se você roda sua suite uma vez antes de um release e uma vez depois, uma “melhora” de oito pontos está dentro dessa dispersão e você vai lançar acreditando que a causou. É por isso que o intervalo agrupado acima — 26,0% [20,4, 32,5] — é estreito demais para citar sozinho: ele trata duzentos ensaios correlacionados como duzentos independentes. O resumo honesto de uma avaliação de agent é uma média e uma dispersão entre repetições, e quase ninguém publica a segunda.

Rubricas não escalam para respostas abertas, então o movimento padrão é fazer um model avaliar o output. Funciona bem o suficiente na fronteira para ser o padrão, e tem três modos de falha nomeados: viés de posição, viés de verbosidade e viés de autoaprimoramento.⁵

Meça antes de confiar. As mesmas sessenta respostas — três das dez execuções — foram rotuladas de três formas. O rótulo humano é meu: li todas as sessenta com os cinco arquivos abertos e apliquei uma regra escrita, passa se e somente se a resposta afirma o fato que a pergunta pediu e não contém nada contradito pelos arquivos.

O judge disse PASS sessenta vezes em sessenta. Ele teria reportado este agent com 100% de accuracy em um conjunto em que o humano o pontua em 18%. Um judge sem poder discriminativo não é um instrumento ruidoso; é uma função constante, e uma função constante dá ao seu melhor sistema e ao seu pior sistema a mesma pontuação.

Prompting não o salvou. Quatro variantes, os mesmos sessenta itens:

Trocar a ordem dos dois rótulos na instrução moveu quatro vereditos. Isso é um efeito mensurável, e é o tipo errado de efeito: o judge está respondendo ao formato do prompt em vez de à resposta à sua frente.

A demonstração limpa é pareada. Vinte perguntas, cada uma com um candidato claramente correto e outro claramente errado, apresentadas nas duas ordens:

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

Ele escolheu a posição A quarenta vezes em quarenta. Os 50% em correção não são competência parcial — são aritmética, porque a resposta correta fica na posição A em exatamente metade dos ensaios. Consistência aqui é definida como o MT-Bench a define, “a porcentagem de casos em que um judge dá resultados consistentes ao trocar a ordem de dois assistentes”, o que permite comparar de igual para igual: GPT-4 marca 65,0% nessa medida, e few-shot prompting a elevou para 77,5%.⁵ O meu marca zero.

A mitigação padrão também vem desse artigo: “chamar um judge duas vezes trocando a ordem de duas respostas e só declarar uma vitória quando uma resposta é preferida nas duas ordens”.⁵ Aplique aqui e o judge produz zero vereditos utilizáveis em vinte pares — que é o resultado correto, e infinitamente melhor que vinte vereditos confiantes.

Uma nota metodológica que vale mais que o resultado. Também rodei um teste de verbosidade: a mesma resposta correta, uma cópia preenchida com uma frase de 36 palavras que não acrescenta nada. O judge preferiu a versão mais longa em exatamente 50% dos ensaios — o que parece ausência de viés de verbosidade e não é nada disso, porque um judge que sempre escolhe a posição A marca 50% em qualquer pareamento balanceado. Você não consegue medir um segundo viés até controlar o primeiro. Trocar posições não é um refinamento para adicionar depois; é o que torna toda outra medição interpretável.

A ressalva honesta: este judge é um model de meio bilhão de parâmetros, e ninguém deveria avaliar com um. O ponto não é que judges sejam ruins. É que os números acima custaram oito minutos para produzir, e sem eles o veredito desse judge sobre uma decisão de lançamento teria sido 100%.

Este é o terceiro e último painel declarado de Python do curso, e o motivo está em onde os números públicos vêm. lm-evaluation-harness cobre “mais de 60 benchmarks acadêmicos padrão para LLMs, com centenas de subtarefas e variantes implementadas” e é “o backend do popular Open LLM Leaderboard da Hugging Face”; HELM, SWE-bench e τ-bench são pacotes Python com entry points Python.⁶ Rodar seu model contra um número publicado significa rodar o código deles, e no dia em que você quiser comparar com um número que alguém citou, este é o ecossistema em que você está:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

O segundo motivo é que uma medição neste capítulo é impossível via HTTP. Contaminação — o conjunto de teste ter vazado para os dados de treinamento — é a falha que torna um benchmark público silenciosamente sem sentido, e a sonda mais afiada para isso precisa da loss do próprio model, que nenhuma chat API retorna. É a entropia cruzada por token do Capítulo 8, apontada para uma pergunta sobre memória:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

Dez pares de frases: cinco em todo crawl da web desde que ela existe, cinco escritas para este capítulo esta manhã, cada uma pareada com uma versão reformulada carregando o mesmo conteúdo.

O model fica quatro vezes mais surpreso com uma frase escrita esta manhã do que com uma que viu um milhão de vezes, e reformular custa o dobro nas famosas — o custo extra sendo a parte que foi memorizada em vez de compreendida. Loss absoluta confunde memorização com naturalidade comum, então o gap é a estatística melhor, e o teste de continuação é melhor ainda. Dê a ele as primeiras seis palavras:

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

Três das cinco strings famosas continuaram palavra por palavra a partir de seis palavras; nenhuma das cinco novas fez isso. Isso é um model de meio bilhão de parâmetros recitando a MIT License. Se seu benchmark está na web pública, presuma que ele está nos pesos. Esse também é o argumento para o capítulo inteiro: um golden set que você escreveu a partir dos seus próprios dados, mantido fora de qualquer repositório que um crawler leia, é o único conjunto de teste de que você pode ter certeza que nunca foi usado em treinamento.

Eles ainda valem a leitura, desde que você leia o que cada um mede, em vez do número único anexado a ele.

Pegue a tabela, não qualquer linha. Os benchmarks agentic colocam humanos muito acima de models, que é o oposto dos benchmarks de conhecimento e o melhor resumo em uma linha de onde a área está; seus números envelhecem em meses, então cite-os com a data em que você os leu; e cada um mede uma tarefa que não é a sua.

Accuracy é a métrica sobre a qual você discute. Estas são as que decidem se a coisa vai ao ar. Todas as quatro saem das duzentas execuções já medidas.

Custo por tarefa resolvida, não por chamada. O agent custa $0.001345 por tentativa e $0.005172 por tarefa de fato resolvida — 3,85 vezes mais, porque três quartos das tentativas não produzem nada. A latência se comporta do mesmo jeito: 1.213 ms por tentativa, 4.667 ms por tarefa resolvida. Cada retry, cada nova pergunta, cada trajetória abandonada está no segundo número e invisível no primeiro.

Um diagnóstico que supera accuracy. Em 123 de 200 tentativas, o agent respondeu sem chamar uma única ferramenta — chutou em vez de olhar. Dividindo por isso:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

Os intervalos nem chegam perto de se tocar. Isso vale mais que os 26% agregados, porque nomeia a coisa a corrigir — o model não está falhando em raciocinar, está falhando em olhar — e a correção está no harness, não no model. Uma ressalva que este capítulo deve aos próprios padrões: os dois grupos são tarefas diferentes, não as mesmas tarefas pareadas, então parte desse gap pode ser que ele pule as ferramentas justamente nas perguntas que considera difíceis. A divisão é um diagnóstico, não uma alegação causal.

Taxa de intervenção humana é a métrica que um comprador pergunta primeiro: que fração das execuções parou em uma aprovação, um guardrail ou um handoff. As interrupções tipadas do Capítulo 23 tornam isso contável, e contado por tipo de tarefa e por semana é o que separa um agent aprendendo seu trabalho de um que discretamente vira uma fila.

Abandono é a que nenhuma suite offline consegue ver: o usuário que leu a resposta, fechou a aba e fez a tarefa sozinho. Avaliação offline é um gate; avaliação em produção é uma amostra contínua do tráfego real, pontuada pelo mesmo avaliador mais estas quatro.

E uma regra herdada do Capítulo 17: nunca faça assert sobre output exato. Faça assert sobre propriedades — JSON válido, schema correto, a ferramenta certa chamada, um número dentro da tolerância, uma substring obrigatória presente. A coluna de correspondência exata no começo deste capítulo é o que acontece quando essa regra é quebrada.

Avaliar um fornecedor não é só accuracy, e esta é a segunda metade da ética deste curso, com seu próprio título em vez de um apêndice.

Meça o viés, não o presuma. O que quer que você acredite sobre o comportamento de um model em nomes, dialetos, gêneros ou nacionalidades, isso é uma propriedade mensurável do seu pipeline, e o instrumento é o que você já tem: pegue seu golden set, varie apenas o atributo, compare pareado. HELM existe precisamente porque accuracy sozinha estava sendo reportada onde viés, toxicidade, calibração e robustez também eram decidíveis.⁸ O model card de um fornecedor é um ponto de partida, não evidência sobre seus inputs.

Contaminação também é uma pergunta de fornecedor. A sonda acima é o motivo para perguntar em que um número publicado foi medido e quando os dados do model foram cortados.

Retenção, treinamento e residência, lidos em 7 de setembro de 2026. Isso muda, então registre a data ao lado da resposta. A página de política da Anthropic afirma: “Por padrão, não usaremos seus inputs ou outputs de nossos produtos comerciais (por exemplo, Claude for Work, Anthropic API, Claude Gov etc.) para treinar nossos models”, com exceção do conteúdo que você envia explicitamente como feedback, que é armazenado “por até 5 anos”.¹⁶ A documentação de controles de dados da OpenAI afirma que “dados enviados à OpenAI API não são usados para treinar ou melhorar os models da OpenAI (a menos que você opte explicitamente por compartilhar dados conosco)”, descreve uma retenção padrão de trinta dias para logs de monitoramento de abuso e oferece Zero Data Retention, que “exclui conteúdo do cliente dos logs de monitoramento de abuso”, além de residência de dados configurável em uma lista de regiões.¹⁷

Quatro perguntas para obter por escrito antes da primeira chamada de produção, porque cada uma tem um dono diferente: meus dados são usados para treinamento; por quanto tempo são retidos e por quem; onde são processados e armazenados; e o que acontece com tudo isso se eu usar um revendedor, um gateway ou um agregador em vez do provedor diretamente. Essa última é onde mora a maioria das surpresas, e nenhum benchmark vai lhe dizer.

Agora você tem o instrumento: um golden set que você possui, um intervalo em cada número, um teste pareado para cada comparação, pass^k para as execuções que você não mostrou a ninguém, um judge medido, e uma sonda para saber se uma pontuação pública significa alguma coisa. A afirmação final do Capítulo 23 agora pode ser verificada em vez de afirmada — um harness torna um agent governável, não correto — e verificá-la levou duzentas execuções e oito minutos.

Há uma propriedade de um agent que nada disso mede, e é a que faz pessoas serem demitidas.

Cada tarefa no golden set deste capítulo foi escrita por mim, e cada arquivo que o agent leu foi escrito por mim. Nada naquele diretório estava tentando fazer nada. Mude uma linha em um arquivo que o agent deve ler — uma linha que termina com uma instrução endereçada a quem quer que a leia em seguida — e o agent que pontuou 26% vai segui-la com as mesmas ferramentas, as mesmas permissões e o mesmo trace limpo, e todos os números deste capítulo ficarão exatamente onde estão. Uma suite de avaliação mede com que frequência um sistema chega ao seu objetivo. Ela não mede a facilidade com que outra pessoa pode substituir o objetivo pelo dela.

O Capítulo 30 é isso: prompt injection, a tríade letal de dados privados, conteúdo não confiável e comunicação externa, e quanto custa dar permissões reais a um agent. Ele abre com a observação que este capítulo vinha evitando — que a mesma pontuação de aprovação é compatível com um agent que faz exatamente o que um atacante escreveu em um arquivo que ele recebeu a ordem de ler.

Cada número acima foi produzido em uma máquina e nada tocou um endpoint pago. O agent é o loop do Capítulo 23 com duas de suas quatro ferramentas sobre um diretório de cinco arquivos; o model por trás da porta é Qwen/Qwen2.5-0.5B-Instruct, exposto por um pequeno servidor no mesmo formato de um endpoint de chat completions exatamente como no Capítulo 23, mas em meia precisão em uma GPU de consumidor em vez da CPU daquele capítulo. Custos usam as tarifas do Capítulo 16 — $2,00 por milhão de input tokens e $12,00 por milhão de output — aplicadas a contagens de token medidas. As execuções repetidas usam temperatura 0,7 com seeds fixas para que o conjunto inteiro se reproduza; a tabela de quatro braços é greedy. Intervalos são Wilson a 95%, comparações pareadas são testes de sinais exatos bilaterais sobre os pares discordantes; o intervalo de Wilson é o do Capítulo 4 e o teste de sinais pareado exato é o do Capítulo 15, ambos reutilizados sem mudança. Os rótulos humanos são meus, aplicados a sessenta respostas sob a regra escrita citada no texto. Leia cada magnitude aqui como propriedade de um model de meio bilhão de parâmetros e cada método como transferível: um model maior eleva todos os números e não desloca nenhum dos instrumentos.