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

Quase todos os argumentos sobre avaliação são duas pessoas a medir coisas diferentes. Há três projetos e não partilham instrumento.

A confusão é cara numa direção. Uma leaderboard diz-lhe que um modelo é forte em raciocínio de nível pós-graduado; não lhe consegue dizer se vai encaminhar os seus tickets de suporte. E uma avaliação de aplicação que pontua uma resposta por input não consegue ver um agent de todo, porque um agent tem uma distribuição de trajetórias e uma resposta é uma única amostra dela. O Capítulo 22 deu nome a essa terceira linha e deixou-a vazia: a medida de desempenho, a parte da especificação de um agent que as equipas escrevem por último ou nunca escrevem.

A ordem também importa, e o fornecedor que lhe vende o modelo di-lo. O guia de agents da OpenAI reduz a seleção de modelo a três passos, por esta ordem: «Configure evals para estabelecer uma baseline de desempenho», «Concentre-se em atingir o seu objetivo de precisão com os melhores modelos disponíveis», «Otimize custo e latência substituindo modelos maiores por modelos mais pequenos sempre que possível».¹ A avaliação vem primeiro, porque os passos 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. É aborrecido, é pequeno, e é o único artefacto neste capítulo que é seu. O que é construído aqui tem vinte tarefas sobre um diretório de cinco ficheiros — 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 correr:

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 suportam o peso. A lista mustNot existe porque um modelo que nomeia três ficheiros, incluindo o correto, não respondeu. E answer é escrito em prosa e também em padrões, porque um humano e um juiz precisarão ambos dele mais tarde — e escrever o mesmo facto duas vezes em duas notações é a forma de descobrir que não concordava consigo próprio sobre qual era a tarefa.

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

Leia os intervalos antes do vencedor. As execuções do braço B vão de 11 % a 47 %; as do braço A, de 3 % a 30 %. Sobrepõem-se em grande parte da sua extensão, que é a conclusão do Capítulo 4 a chegar exatamente onde foi prometida: vinte casos não conseguem ordenar quatro sistemas. O Capítulo 15 afiou isto fazendo antes a pergunta emparelhada — nos casos em que dois braços discordam, quão desequilibrada é a divisão? — porque a dificuldade partilhada do conjunto se cancela. Eis todos os pares:

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 fica estabelecida. O melhor braço vence o braço sem ferramentas por quinze pontos, e isso assenta em três casos discordantes. Vinte casos mostram um mecanismo e não conseguem escolher um fornecedor; dizer o contrário numa reunião é como se compra um mau modelo.

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 escolher a resposta modal triplica a fatura, quer triplique a accuracy quer não. Tabelas de accuracy que omitem custo tornam essa troca invisível.

Agora a conclusão que muda a forma como lê todos os benchmarks que alguma vez verá. Pegue nas mesmas duzentas transcrições — vinte tarefas, dez execuções, nem um token regenerado — e pontue-as de três formas:

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

Isso não é uma curiosidade, é um mecanismo, e tem nome. Uma métrica de corte duro pontua uma tarefa como tudo-ou-nada sobre vários subfactos, por isso compõe-se. A tarefa t12 pede três códigos de estado 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 facto está certo cerca de três quartos das vezes; exigir os três de uma vez reduz a pontuação para metade, e $0.77^3 = 0.457$ fica suficientemente perto 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 melhoria de cinco pontos por facto torna-se vinte e cinco pontos na conjunção. Nada de descontínuo aconteceu ao modelo. Uma curva suave lida através de uma métrica tudo-ou-nada parece um salto — que é precisamente o argumento que Schaeffer, Miranda e Koyejo fizeram sobre capacidades emergentes, e que o Capítulo 10 adiou para aqui.² A auditoria deles concluiu que, no máximo, 5 das 39 métricas preferidas do BIG-Bench exibem emergência, com duas métricas descontínuas a responderem por mais de 92 % dos casos alegados.

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

Há uma versão de segunda ordem disto que Kalai e colegas argumentam estar a causar dano a montante: benchmarks pontuados como certo-ou-errado recompensam adivinhar em vez de dizer «não sei», por isso um modelo otimizado contra eles aprende a adivinhar. A correção proposta não é outro benchmark de alucinações, mas «modificar a pontuação de benchmarks existentes que estão desalinhados mas dominam leaderboards».³ O seu golden set tem a mesma alavanca, e é uma linha: decida se uma abstenção conta como falha ou como a sua própria categoria. A maioria das pessoas nunca decide, por isso conta silenciosamente como falha, e o sistema que enviam para produção adivinha.

Tudo até aqui pontuou uma tentativa por tarefa. Um agent não é uma tentativa. O Capítulo 17 estabeleceu que não tem determinismo nem sequer a temperature zero, por isso o mesmo input produz uma distribuição de trajetórias e um benchmark que executa cada tarefa uma vez relata uma amostra dela.

A contribuição do τ-bench é a métrica para isso. O artigo define-a claramente: «propomos uma nova métrica – pass^k (pass hat k), definida como a probabilidade de todos os k ensaios i.i.d. de tarefa serem bem-sucedidos, média sobre as tarefas».⁴ Execute cada tarefa $n$ vezes, conte os $c$ sucessos, e os estimadores não enviesados são:

O segundo é o conhecido pass@k da geração de código: a probabilidade de pelo menos uma de $k$ tentativas ter sucesso. Coloque-os lado a lado sobre as mesmas contagens medidas e movem-se 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 piora, e ambas estão corretas, porque respondem a perguntas diferentes. pass@k é a métrica certa quando um humano filtra o output — geração de código, rascunhos, brainstorming — e as tentativas extra são baratas. pass^k é a métrica certa quando o agent age sem filtro, que é o que «agent» significa. Publicar a primeira onde se aplica a segunda é o exagero mais comum neste campo, e o próprio título do τ-bench é a versão honesta: gpt-4o a cerca de 61 % pass^1 em retalho cai para cerca de 25 % em pass^8.⁴

Agora o golpe 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 eis 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 acrescenta uma afirmação falsa — o deploy 41 foi revertido. Ambas corresponderam a /succe|yes/. A única tarefa que mantém pass^10 acima de zero é um artefacto do avaliador, por isso o valor verdadeiro é zero, e nenhum agregado mo teria mostrado. Amostrar as transcrições por trás da sua tarefa com melhor pontuação é onde os avaliadores vão morrer.

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

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

Uma amplitude de trinta pontos num sistema que não mudou. Se correr a sua suite uma vez antes de uma release e uma vez depois, uma «melhoria» de oito pontos está dentro dessa dispersão e vai lançá-la acreditando que a causou. É por isso que o intervalo agregado acima — 26.0 % [20.4, 32.5] — é demasiado estreito para ser citado sozinho: trata duzentos ensaios correlacionados como duzentos ensaios 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, por isso o movimento padrão é fazer um modelo avaliar o output. Funciona suficientemente bem à escala frontier para ser o padrão, e tem três modos de falha com nome: enviesamento de posição, enviesamento de verbosidade e enviesamento de auto-valorização.⁵

Meça-o antes de confiar nele. As mesmas sessenta respostas — três das dez execuções — foram etiquetadas de três formas. A etiqueta humana é minha: li as sessenta com os cinco ficheiros abertos e apliquei uma regra escrita, passa se e só se a resposta declara o facto pedido pela pergunta e não contém nada contradito pelos ficheiros.

O juiz disse PASS sessenta vezes em sessenta. Teria relatado este agent a 100 % de accuracy num conjunto onde o humano o pontua a 18 %. Um juiz 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 das duas etiquetas na instrução moveu quatro veredictos. É um efeito mensurável e é o tipo errado de efeito: o juiz está a responder à forma do prompt em vez de responder à resposta à sua frente.

A demonstração limpa é par a par. Vinte perguntas, cada uma com uma candidata claramente correta e uma claramente errada, 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 %

Escolheu a posição A quarenta vezes em quarenta. Os 50 % na 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. A consistência aqui é definida como o MT-Bench a define, «a percentagem de casos em que um juiz dá resultados consistentes ao trocar a ordem de dois assistentes», o que permite uma comparação direta: o GPT-4 pontua 65.0 % nessa medida, e few-shot prompting elevou-a para 77.5 %.⁵ O meu pontua zero.

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

Uma nota metodológica que vale mais do que o resultado. Também executei um teste de verbosidade: a mesma resposta correta, uma cópia acrescentada de uma frase de 36 palavras que não adiciona nada. O juiz preferiu a versão mais longa em exatamente 50 % dos ensaios — o que parece ausência de enviesamento de verbosidade e não é nada disso, porque um juiz que escolhe sempre a posição A pontua 50 % em qualquer emparelhamento equilibrado. Não consegue medir um segundo enviesamento até o primeiro estar controlado. Trocar posições não é um refinamento a acrescentar depois; é o que torna todas as outras medições interpretáveis.

A ressalva honesta: este juiz é um modelo de meio bilião de parâmetros, e ninguém deve avaliar com um. A questão não é que os juízes sejam maus. É que os números acima custaram oito minutos a produzir, e sem eles o veredicto deste juiz numa decisão de lançamento teria sido 100 %.

Este é o terceiro e último painel Python declarado do curso, e a razão está no sítio de onde vêm os números públicos. lm-evaluation-harness cobre «mais de 60 benchmarks académicos padrão para LLMs, com centenas de subtarefas e variantes implementadas» e é «o backend da popular Open LLM Leaderboard da Hugging Face»; HELM, SWE-bench e τ-bench são pacotes Python com pontos de entrada Python.⁶ Executar o seu modelo contra um valor publicado significa executar o código deles, e no dia em que quiser comparar com um número que alguém citou, este é o ecossistema em que está:

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

A segunda razão é que uma medição neste capítulo é impossível sobre HTTP. Contaminação — o conjunto de teste ter vazado para os dados de treino — é a falha que torna um benchmark público silenciosamente sem significado, e a sonda mais afiada para isso precisa da loss do próprio modelo, que nenhuma API de chat devolve. É a cross-entropy por token do Capítulo 8, apontada a 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 todos os crawls da web desde que existe, cinco escritas para este capítulo esta manhã, cada uma emparelhada com uma versão reformulada que carrega o mesmo conteúdo.

O modelo fica quatro vezes mais surpreendido por uma frase escrita esta manhã do que por uma que viu um milhão de vezes, e reformular custa o dobro nas famosas — sendo o custo extra a parte que foi memorizada em vez de compreendida. A loss absoluta confunde memorização com naturalidade comum, por isso a diferença é a estatística melhor e o teste de continuação é ainda melhor. Dê-lhe 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 frescas o fez. Isto é um modelo de meio bilião de parâmetros a recitar a MIT License. Se o seu benchmark está na web pública, assuma que está nos pesos. É também o argumento de todo o capítulo: um golden set que 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 pode ter a certeza que nunca foi treinado.

Ainda vale a pena lê-los, desde que leia o que cada um mede em vez do número único associado.

Fique com a tabela, não com uma linha. Os benchmarks agentic colocam todos os humanos muito acima dos modelos, que é o oposto dos benchmarks de conhecimento e o melhor resumo numa linha de onde está o campo; os seus valores envelhecem em meses, por isso cite-os com a data em que os leu; e todos medem uma tarefa que não é a sua.

Accuracy é a métrica sobre a qual se discute. Estas são as que decidem se a coisa é lançada. 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 realmente resolvida — 3.85 vezes mais, porque três quartos das tentativas não produzem nada. A latência comporta-se da mesma forma: 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 vence a accuracy. Em 123 de 200 tentativas, o agent respondeu sem chamar uma única ferramenta — adivinhou em vez de procurar. 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. Isto vale mais do que os 26 % agregados, porque nomeia a coisa a corrigir — o modelo não está a falhar no raciocínio, está a falhar em procurar — e a correção está no harness, não no modelo. Uma ressalva que este capítulo deve aos seus próprios padrões: os dois grupos são tarefas diferentes, não as mesmas tarefas emparelhadas, por isso parte dessa diferença pode dever-se a ele saltar as ferramentas precisamente nas perguntas que considera difíceis. A divisão é um diagnóstico, não uma afirmação causal.

Taxa de intervenção humana é a métrica que um comprador pergunta primeiro: que fração de execuções parou numa aprovação, num guardrail ou num handoff. As interrupções tipadas do Capítulo 23 tornam-na contável, e contada por tipo de tarefa e por semana é o que separa um agent que está a aprender o trabalho de um que se está silenciosamente a tornar uma fila.

Abandono é a que nenhuma suite offline consegue ver: o utilizador que leu a resposta, fechou o separador e fez a tarefa sozinho. A avaliação offline é um portão; a avaliação em produção é uma amostra contínua de tráfego real, pontuada com o 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 topo 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 o seu próprio título em vez de um apêndice.

Meça o enviesamento, não o assuma. O que quer que acredite sobre o comportamento de um modelo em nomes, dialetos, géneros ou nacionalidades, é uma propriedade mensurável do seu pipeline, e o instrumento é o que já tem: pegue no seu golden set, varie apenas o atributo, compare emparelhado. HELM existe precisamente porque se estava a relatar apenas accuracy onde enviesamento, 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 os seus inputs.

Contaminação também é uma pergunta para o fornecedor. A sonda acima é a razão para perguntar sobre o que foi medido um número publicado, e quando foram cortados os dados do modelo.

Retenção, treino e residência, lido em 7 de setembro de 2026. Estas coisas mudam, por isso registe a data ao lado da resposta. A página de políticas da Anthropic declara: «Por defeito, não usaremos os seus inputs ou outputs dos nossos produtos comerciais (por exemplo, Claude for Work, Anthropic API, Claude Gov, etc.) para treinar os nossos modelos», com a exceção de conteúdo que submeta explicitamente como feedback, que é armazenado «até 5 anos».¹⁶ A documentação de controlos de dados da OpenAI declara que «dados enviados para a OpenAI API não são usados para treinar ou melhorar modelos da OpenAI (a menos que opte explicitamente por partilhar dados connosco)», descreve uma retenção predefinida de trinta dias para logs de monitorização de abuso, e oferece Zero Data Retention, que «exclui conteúdo de clientes dos logs de monitorização de abuso», mais residência de dados configurável numa lista de regiões.¹⁷

Quatro perguntas para obter por escrito antes da primeira chamada de produção, porque cada uma tem um dono diferente: os meus dados são usados para treino; durante quanto tempo são retidos e por quem; onde são processados e armazenados; e o que acontece a tudo isso se eu usar um revendedor, uma gateway ou um agregador em vez do fornecedor diretamente. É nessa última que vivem a maioria das surpresas, e nenhum benchmark lhe dirá.

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

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

Todas as tarefas no golden set deste capítulo foram escritas por mim, e todos os ficheiros que o agent leu foram escritos por mim. Nada naquele diretório estava a tentar fazer fosse o que fosse. Mude uma linha num ficheiro que o agent é instruído a ler — uma linha que termina com uma instrução dirigida ao que quer que a leia a seguir — e o agent que pontuou 26 % 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 atinge o seu objetivo. Não mede com que facilidade outra pessoa consegue substituí-lo pelo dela.

O Capítulo 30 é isso: prompt injection, a tríade letal de dados privados, conteúdo não fiável e comunicação externa, e quanto custa dar permissões reais a um agent. Abre com a observação que este capítulo tem evitado — que a mesma pontuação de passagem é compatível com um agent que faz exatamente o que um atacante escreveu num ficheiro que foi instruído a ler.

Todos os números acima foram produzidos numa máquina e nenhum tocou num endpoint pago. O agent é o ciclo do Capítulo 23 com duas das suas quatro ferramentas sobre um diretório de cinco ficheiros; o modelo por trás da porta é Qwen/Qwen2.5-0.5B-Instruct, exposto através de um pequeno servidor com a mesma forma de um endpoint de chat completions exatamente como no Capítulo 23, mas em half precision numa GPU de consumo em vez da CPU desse capítulo. Os 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 temperature 0.7 com seeds fixas para que todo o conjunto se reproduza; a tabela de quatro braços é greedy. Os intervalos são Wilson a 95 %, as comparações emparelhadas são testes exatos dos sinais bilaterais sobre os pares discordantes; o intervalo de Wilson é o do Capítulo 4 e o teste exato dos sinais emparelhado é o do Capítulo 15, ambos reutilizados sem alterações. As etiquetas humanas são minhas, aplicadas a sessenta respostas sob a regra escrita citada no texto. Leia cada magnitude aqui como uma propriedade de um modelo de meio bilião de parâmetros e cada método como transferível: um modelo maior move todos os números para cima e não move nenhum dos instrumentos.