O conjunto de avaliação é a especificação

Em maio de 2024, uma equipe da Scale AI lançou o GSM1k, um conjunto de problemas novos de matemática do ensino fundamental, escritos para espelhar o estilo e a dificuldade do GSM8K, o benchmark que a maioria dos laboratórios vinha citando para raciocínio elementar. Os autores igualaram os dois conjuntos em taxas de acerto entre anotadores humanos, número de passos da solução e tamanho das respostas. Depois rodaram os modelos. Várias famílias de modelos abertos e fechados tiraram até 8% menos nos problemas inéditos do que no GSM8K, e os modelos mais propensos a reproduzir de memória itens do GSM8K mostraram diferenças maiores. Os modelos de fronteira exibiram pouco disso, o que vale dizer com clareza, porque a conclusão é mais específica do que "benchmarks estão quebrados". Uma nota é a medida do desempenho num conjunto particular de problemas, e quando os problemas vazam para os dados de treino a medida deixa de descrever a habilidade.

Em abril de 2025, um grupo liderado por Shivalika Singh e Sara Hooker examinou o Chatbot Arena, o ranking de preferência humana mais visível, e relatou que alguns provedores puderam testar variantes privadas antes do lançamento e publicar apenas a melhor pontuação. Contaram 27 variantes privadas testadas pela Meta antes do Llama 4. Estimaram que Google e OpenAI receberam cada uma cerca de um quinto de todos os dados do Arena, o que importa porque treinar nessa distribuição eleva as notas nela.

Nenhum dos dois resultados significa que rankings públicos são inúteis. Servem bem para montar uma lista de candidatos. O que não conseguem é dizer se um modelo é bom na sua tarefa, porque a sua tarefa não estava na prova. Para isso é preciso um conjunto de casos que você escreveu, rotulou e defendeu, e meu argumento neste ensaio é que, numa aplicação com LLM, esse conjunto ocupa o lugar da especificação. Ele declara, em forma executável, o que o sistema deve fazer nas entradas que importam. Todo o resto do projeto, incluindo o prompt, o índice de recuperação e a escolha do modelo, é uma implementação que precisa satisfazê-lo.

Comece pelas falhas que você consegue ver

O método que mais merece confiança é também o menos glamoroso. Hamel Husain, que escreve sobre avaliação com mais concretude do que a maioria, manda as equipes lerem traces: as entradas e saídas reais do sistema, quantas aguentarem, antes de construir qualquer métrica automática. A posição dele é que não se pode parar de olhar para os dados, e que o trabalho de olhar deve ser facilitado com um visualizador sob medida que ponha a entrada, a saída e os registros ao redor numa única tela.

Ler cem traces produz uma lista de modos de falha, e essa lista é o primeiro rascunho da especificação. Pense num assistente de suporte de uma loja virtual. Depois de uma tarde de leitura, a lista pode dizer: cita a versão errada da política, promete um reembolso que o atendente não tem autoridade para conceder, responde no idioma errado, inventa um número de pedido e fica ríspido com clientes irritados. Cada item vira uma verificação com resultado binário. Husain defende rótulos de aprovado ou reprovado em vez de notas de 1 a 5, e concordo, por um motivo além da conveniência. Uma escala de cinco pontos deixa dois revisores discordarem sobre se um 3 é aceitável sem nunca descobrirem isso. Um rótulo binário força a decisão que o produto vai forçar de qualquer modo.

Uma primeira versão do conjunto de dados pode viver numa planilha. O que importa é que cada linha tenha uma entrada, uma referência ao contexto que o sistema deveria ter usado, o comportamento esperado em palavras simples e o modo de falha que ela exercita. As linhas devem vir do tráfego real sempre que possível e de construção deliberada quando os casos reais são raros: o cliente furioso, a pergunta que a política não cobre, o pedido que nunca foi feito.

Verifique com código primeiro, depois com um juiz

As verificações se dividem em três níveis de custo. As mais baratas são asserções que o código consegue avaliar: a saída passa no esquema, o ID do documento citado aparece entre os documentos recuperados, o SQL que o sistema escreveu devolve as mesmas linhas que a consulta de referência, a resposta não contém nenhum número de pedido ausente do banco. Elas rodam em milissegundos, são determinísticas e devem ser a maior parte da suíte. Husain as chama de testes unitários e observa que a taxa de aprovação é uma decisão de produto, já que 100% pode não ser a meta certa.

O segundo nível é um modelo atuando como juiz, para critérios que o código não consegue expressar, como saber se uma resposta é educada ou se um resumo preserva o sentido da fonte. Lianmin Zheng e colegas estudaram isso no artigo do MT-Bench (NeurIPS 2023) e descobriram que um juiz GPT-4 concordava com as preferências humanas mais de 80% das vezes, quase tanto quanto humanos concordam entre si. O artigo também cataloga as fraquezas: juízes preferem a resposta que vem primeiro, preferem respostas mais longas e preferem respostas escritas por eles mesmos, e sua capacidade de raciocínio é limitada. As regras práticas decorrem daí. Embaralhe a ordem nas comparações em pares. Julgue com um modelo de família diferente da que gerou a resposta. Mantenha a rubrica em um critério por julgamento.

Vem então o passo que as equipes pulam, que é validar o juiz contra rótulos humanos nos seus próprios dados. Um único número de concordância engana quando a maioria das saídas é boa. Suponha que 90% das respostas sejam aceitáveis. Um juiz que aprova tudo concorda com os rótulos humanos em 90% das vezes e não pega falha nenhuma. Relate as duas taxas separadamente: das respostas que humanos marcaram como ruins, que fração o juiz sinalizou, e das que humanos marcaram como boas, que fração ele aprovou. Um juiz que vale o uso tem as duas taxas altas em algumas centenas de exemplos rotulados, e quando não tem, a rubrica precisa ser reescrita antes de o juiz receber a confiança de decidir um lançamento.

O terceiro nível é uma pessoa, usada numa amostra, nas divergências entre os outros níveis e em todo caso em que o risco justifique.

O ruído é o padrão

A maior parte dos resultados de avaliação em circulação é relatada sem noção de precisão, e é aí que nascem muitas más decisões. Imagine uma suíte de 200 casos em que um sistema passa em 80%. O erro-padrão é a raiz quadrada de 0,8 × 0,2 / 200, cerca de 2,8 pontos, de modo que o intervalo de 95% vai de uns 74,5% a 85,5%. Com 1.000 casos o intervalo estreita para cerca de mais ou menos 2,5 pontos. Uma mudança que leva o número de 80% para 83% em 200 casos fica dentro do ruído.

Comparações entre duas versões são mais bem tratadas por pareamento: rode as duas nos mesmos casos e olhe apenas para aqueles em que discordam. Digamos que um prompt novo conserta 14 casos que o antigo errava e quebra 8 que o antigo acertava. O ganho líquido é de 6 casos em 200, três pontos. Sob a hipótese nula de que os prompts são igualmente bons, os 22 casos discordantes se dividiriam em 14 a 8, ou algo mais extremo, cerca de 29% das vezes (um teste binomial exato bicaudal). É uma base fraca para publicar, e uma equipe que enxerga apenas "80% para 83%" não saberia disso.

Para detectar uma diferença real de três pontos entre 80% e 83% com um desenho não pareado e 80% de poder, uma conta de guardanapo pede em torno de 2.600 casos por sistema. O pareamento reduz bastante isso quando as duas versões na maior parte concordam, embora a economia dependa da frequência com que discordam. O artigo de Evan Miller de 2024 sobre barras de erro em avaliações expõe as fórmulas para erros-padrão, para a comparação de dois modelos e para o planejamento de uma avaliação, e é curto o bastante para ler numa noite. O que fica é um hábito: todo número de uma avaliação deve viajar com o seu intervalo, e toda comparação deve informar quantos casos viraram em cada direção.

Mantenha o conjunto de teste limpo

A contaminação não exige um vazamento vindo da internet. Uma equipe pode fazê-la a si mesma. Se os mesmos 200 casos orientam cada revisão do prompt, o prompt vai se ajustando a esses casos, e a nota neles sobe sem nenhuma promessa sobre entradas novas. É o problema mais antigo do aprendizado de máquina, e vale para a engenharia de prompts sem mudanças.

O remédio é o que cientistas de dados usam com modelos. Separe os casos em um conjunto de desenvolvimento, que você olha e contra o qual itera, e um conjunto reservado, que roda raramente, talvez antes de cada lançamento, e de cujas falhas você nunca lê os detalhes enquanto ajusta. Renove ambos a partir do tráfego de produção num ritmo regular, já que a distribuição das entradas reais se move. Versione o conjunto de dados e registre a versão ao lado de cada nota, para que um número de março só seja comparado com um de setembro quando tiverem sido medidos nos mesmos casos.

O resultado do GSM1k acrescenta uma cautela sobre as alegações dos fornecedores. Quando os números publicados de um modelo vêm de um benchmark público há anos, a pergunta a fazer é quanto do benchmark o modelo já viu. Um conjunto de teste privado e pequeno no seu domínio responde melhor a essa pergunta do que qualquer quantidade de leitura sobre o modelo.

A produção fecha o ciclo

Uma suíte offline descreve o passado. Usuários reais seguem inventando entradas que ninguém na equipe imaginou, então a suíte precisa de um caminho para que falhas de produção virem casos de teste. A versão mais simples é um botão de "não gostei", ou um encaminhamento para atendente humano, que grava o trace completo numa fila de revisão. Alguém lê a fila toda semana, rotula o trace e o adiciona ao conjunto de desenvolvimento se ele expuser um modo de falha que a suíte não tem. Depois de um trimestre a suíte reflete o produto como ele é usado, o que o descreve melhor do que qualquer coisa escrita no início.

O terceiro nível de Husain, o teste A/B, fica no fim dessa cadeia. As avaliações offline dizem se uma mudança é segura para ser tentada, e um experimento com tráfego real diz se a mudança ajuda os usuários de maneiras que os casos não capturaram: menor tempo de atendimento, menos escalações, mais compras concluídas. As duas respondem a perguntas diferentes, e uma mudança normalmente deve passar na primeira antes de merecer a segunda. Um ganho offline que nunca aparece na métrica real também é informação. Significa que a suíte mede algo com que os clientes não se importam, e os casos precisam ser reescritos.

Casos sintéticos podem preencher lacunas, com uma ressalva. Um modelo gera centenas de mensagens plausíveis de clientes numa tarde, o que ajuda a cobrir categorias raras. Mas entradas sintéticas herdam os hábitos do gerador e tendem a ser mais limpas e mais cooperativas do que as reais, então devem complementar traces reais, e a taxa de aprovação nelas deve ser relatada separadamente da taxa nos casos reais.

Modelos se aposentam, a suíte fica

Um motivo prático para investir vem do calendário dos próprios fornecedores. A documentação de preços da Anthropic em outubro de 2026 lista vários modelos como aposentados, exceto em plataformas de nuvem específicas: Claude Opus 4 e 4.1, Sonnet 4, Haiku 3.5. Outros provedores descontinuam em ciclos parecidos. Uma equipe que construiu sobre um modelo aposentado precisa migrar, e a migração é ou uma semana rodando uma suíte e lendo a diferença, ou um mês de testes manuais ansiosos.

A suíte também é o meio de experimentar um modelo novo. Quando um provedor lança algo mais barato, mais rápido ou mais inteligente, a pergunta "isso é bom o bastante para nós?" se responde rodando o conjunto de desenvolvimento, lendo os casos discordantes e conferindo o intervalo, o que pode acontecer no dia do lançamento. Sem a suíte, a decisão é tomada pela reputação, e a reputação foi construída sobre o benchmark de outra pessoa.

Quem é o dono da suíte

Um conjunto de avaliação precisa de um dono, e o dono precisa da autoridade para barrar um lançamento. O papel se parece mais com o de um líder de testes do que com o de um cientista de dados. O dono cura os casos, aposenta os obsoletos, acrescenta as falhas que a produção gera e decide quais verificações travam um deploy. Se reprovar na suíte nunca bloqueia nada, ela será ignorada em um trimestre.

Um primeiro mês razoável é assim. Na semana um, leia cem traces reais e anote os modos de falha, com um rótulo binário para cada trace. Na semana dois, transforme todo modo de falha que o código consegue detectar em uma asserção e rode as asserções a cada mudança. Na semana três, escreva rubricas para o que sobrou, rode um juiz nos traces rotulados e calcule as duas taxas dele contra os rótulos humanos. Na semana quatro, separe um conjunto reservado, ponha as taxas de aprovação com seus intervalos num painel e ligue as asserções ao pipeline de entrega, de modo que uma regressão pare o lançamento. Tudo depois disso é manutenção: novas falhas viram novos casos.

Fontes

1. Zhang, H., Da, J., Lee, D., et al. (2024). A Careful Examination of Large Language Model Performance on Grade School Arithmetic. NeurIPS 2024 Datasets and Benchmarks. arXiv:2405.00332.
2. Singh, S., Nan, Y., Wang, A., et al. (2025). The Leaderboard Illusion. arXiv:2504.20879.
3. Husain, H. (2024). Your AI Product Needs Evals. hamel.dev/blog/posts/evals.
4. Zheng, L., Chiang, W.-L., Sheng, Y., et al. (2023). Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena. NeurIPS 2023 Datasets and Benchmarks. arXiv:2306.05685.
5. Miller, E. (2024). Adding Error Bars to Evals: A Statistical Approach to Language Model Evaluations. arXiv:2411.00640.
6. Anthropic. Pricing and model deprecations, documentação para desenvolvedores do Claude (modelos aposentados em outubro de 2026). platform.claude.com/docs.