pass@1, pass@k e média de tentativas: o que a métrica de acerto dos benchmarks realmente mede?

Fala aí, beleza? O mesmo modelo, no mesmo benchmark, aparece com 28,8% e com 70,2%

Não trocou de modelo, não trocou de problema, trocou só a métrica 😀

Esse é o Codex no HumanEval, e é o exemplo mais limpo de uma coisa que virou rotina nas tabelas de lançamento: pass@1, pass@k e avg@k são jogadas ali como se fossem a mesma ideia de "taxa de acerto", e não são

Cada uma responde uma pergunta diferente, e cada uma corresponde a um jeito diferente de você usar o modelo no dia a dia

Então bora traduzir sigla por sigla, e no fim você vai saber qual coluna da tabela é a que fala com o SEU uso: uma tentativa por prompt ou várias

De onde vem a métrica pass@k:

A métrica pass@k foi introduzida no paper do Codex, em julho de 2021, junto com o benchmark HumanEval

O HumanEval é composto por 164 problemas de programação escritos à mão

O mecanismo é simples de entender: gera k amostras por problema, e o problema conta como resolvido se qualquer uma dessas amostras passa nos testes unitários

O score reportado é a fração de problemas resolvidos

Repare no "qualquer uma"

É o coração da coisa: pass@k não mede se o modelo acerta, mede se ele acerta ao menos uma vez em k tiros

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 114 aulas
• 4 projetos
• 9h 18min

Conhecer formação

E por que existe um estimador com fatorial no meio?

Porque medir isso na marra é ruim de estatística

Se você gera exatamente k amostras e olha se alguma passou, o número balança MUITO com sorte, principalmente em problema difícil onde quase nada passa

Aí o paper define um estimador não enviesado: gera n amostras (n maior que k), conta quantas ficaram corretas (c), e calcula a probabilidade de, sorteando k dessas n, pelo menos uma ser correta

pass@k := E[ 1 - C(n-c, k) / C(n, k) ]

n = total de amostras geradas por problema
c = amostras corretas
C(a, b) = combinação de a elementos tomados b a b

Em português: C(n-c, k) / C(n, k) é a chance de sortear k amostras e TODAS serem das erradas

Um menos isso é a chance de pelo menos uma dar certo

O que ele corrige é justamente o ruído de sorte de rodar poucas amostras, estimando o valor a partir de uma base maior de n amostras

pass@1 x pass@k x avg@k: o que cada uma responde:

O contraste do Codex no HumanEval dá a régua do tamanho do efeito: 28,8% resolvendo com uma única amostra (pass@1) contra 70,2% com 100 amostras por problema

É o mesmo modelo nas duas linhas…

A diferença entre as duas de cima e a de baixo é conceitual, não é detalhe: pass@k mede a probabilidade de ao menos uma das k amostras estar correta, enquanto avg@k estima a correção esperada de uma amostra sorteada, servindo como proxy de acurácia de amostra única

pass@k é "alguma acertou"

avg@k é "média das tentativas"

São perguntas diferentes, e por isso os números não são comparáveis entre si

Qual métrica olhar conforme o seu jeito de usar o modelo:

Agora a parte que interessa: traduzir isso pro seu cotidiano

Você manda um prompt e aceita a primeira resposta

Esse é o uso mais comum, e o seu número é pass@1 (e avg@k como proxy da mesma coisa, com menos ruído)

pass@k com k alto não descreve a sua experiência, porque você não vai gerar 100 saídas e escolher a boa a dedo

Você gera várias tentativas, roda os testes e fica com a que passou

Aqui você está muito mais perto do espírito do pass@k

É literalmente o mecanismo da métrica: várias amostras, vale se qualquer uma passar nos testes

Você tem verificador automático (testes, CI, lint)

Esse é o único caso em que k alto vira ganho real

E o porquê é o pulo do gato: pass@k assume que ALGUÉM sabe qual das k saídas está certa

No benchmark, quem sabe é o teste unitário

Se do seu lado não tem teste, não tem CI, não tem nada verificando, você não tem como colher esse ganho: as k saídas chegam todas com a mesma cara de confiante e você vai escolher no olho 😛

Sem verificador, k alto é número bonito na tabela dos outros, não capacidade sua

Por que dois modelos com o mesmo percentual entregam resultados diferentes:

O sintoma você já viveu: dois modelos com percentual praticamente igual na tabela, e experiências opostas no editor

Um resolve a tarefa e o outro te faz perder a tarde

As causas são documentadas, e são três

Causa 1: o pass@1 que não é uma rodada única

"pass@1" soa como uma tentativa, certo?

Nem sempre

Em system card da OpenAI, o pass@1 reportado no SWE-bench Verified não é uma rodada única: é a média de várias tentativas por instância, com média sobre 4 tentativas por instância no o1 System Card

Ou seja, o rótulo é o mesmo do seu uso, mas o procedimento por trás não é

Causa 2: compute paralelo em tempo de teste

A Anthropic descreve, na sua metodologia de SWE-bench, como chega nos números mais altos: amostra várias tentativas paralelas, descarta patches que quebram testes de regressão visíveis e usa um modelo interno de pontuação pra escolher o melhor candidato

Percebe que isso é um pipeline inteiro, não é "o modelo respondeu"?

Tem geração múltipla, tem filtro e tem seleção

E tem o outro número, o score pass@1 sem artifícios (vanilla), em que a Anthropic conta os 11 problemas insolúveis como falha pra manter paridade com o leaderboard oficial

Dois números, do mesmo benchmark, com significados bem diferentes pro seu dia a dia

Causa 3: repetições e normalização

A metodologia de benchmarking de inteligência do Artificial Analysis roda 5 repetições por questão com pontuação pass@1 (com exceção do AA-Omniscience, que roda um único passe sobre 6.000 questões)

Já no Terminal-Bench v2.1 avaliado por eles, o pass@1 é média de 3 repetições por tarefa e normalizado por tarefa: primeiro a média das tentativas de cada tarefa, depois a média entre tarefas

Mais: harness Terminus 2 em sandbox e2b, e 5 das 89 tarefas excluídas por incompatibilidade de ambiente

Tome cuidado com isso na hora de comparar

A ordem das médias muda o resultado, o harness muda o resultado, e tarefa excluída muda o denominador

Como prevenir: ler a nota de rodapé da metodologia ANTES de comparar dois números

É chato? é

Mas é o único jeito de saber se você está comparando duas coisas medidas do mesmo jeito

O que conta como acerto: o critério binário do SWE-bench Verified:

Até aqui falamos do numerador

O denominador também importa, e muito

O SWE-bench Verified é um subconjunto do SWE-bench validado por humanos, criado em colaboração com a OpenAI, com 500 amostras validadas por anotadores humanos

O critério de acerto é binário por instância: o patch gerado tem que ser aplicado no harness de avaliação e passar em todos os testes associados (os testes golden)

Não existe meio acerto

Não existe "quase", não existe "foi por um caminho inteligente mas quebrou um teste"

A curadoria também é pesada: segundo o Epoch AI, foram 93 desenvolvedores de software, cada amostra revisada por 3 anotadores separados, com taxa de ambiguidade residual estimada em 5% a 10%

Segura essa última parte, porque ela abre o próximo bloco: mesmo com revisão redundante, sobra ambiguidade

O benchmark também erra: a saída da OpenAI do SWE-bench Verified:

A OpenAI publicou que deixou de avaliar o SWE-bench Verified como medida de capacidade de código de fronteira, citando testes falhos e contaminação de dados de treino

A análise que eles publicaram olhou 138 problemas difíceis e encontrou 59,4% com falhas materiais de teste

Dentro desse total aparecem dois tipos citados: 35,5% de testes estreitos e 18,8% de testes largos (repare que essas duas fatias não somam o total geral)

E eles passaram a recomendar o SWE-bench Pro

Até 4 de setembro de 2026, isso segue sem reversão pública

E o que é o SWE-bench Pro?

É um benchmark da Scale AI (laboratório SEAL), pontuado em Pass@1, com scaffolding padronizado e limite de turnos por tarefa

Os números dele, direto do leaderboard público:

• 1.865 tarefas em 41 repositórios (Python, Go, TypeScript e JavaScript)
• divididas em público (731), comercial (276) e held-out (858)
• limite de 250 turnos por tarefa

O que muda pra você aqui é direto: percentual sem metodologia e sem benchmark nomeado não sustenta decisão nenhuma

Um "tantos por cento em código" jogado solto no post de lançamento não quer dizer nada se você não sabe qual benchmark, qual métrica, quantas tentativas e com qual harness

Como ler uma tabela de benchmark em 5 checagens:

Roteiro curto pra você aplicar na próxima tabela de lançamento que cair no seu feed

1. Identifique a métrica: é pass@1, pass@k ou avg@k? Anota qual é antes de qualquer outra coisa. O erro comum: tratar as três como equivalentes e comparar o pass@k de um com o pass@1 do outro, quando pass@k pergunta "alguma acertou" e avg@k pergunta "a média das tentativas"
2. Descubra quantas amostras por problema, e se o pass@1 é média de tentativas. O erro comum: assumir que pass@1 significa uma rodada só. No o1 System Card, o pass@1 do SWE-bench Verified é média sobre 4 tentativas por instância
3. Verifique se teve compute paralelo, filtro de regressão ou seleção por scorer, ou se é score vanilla. O erro comum: comparar um número de pipeline completo (várias tentativas paralelas, descarte de patches que quebram regressão, seleção por scorer interno) com um vanilla, em que os 11 problemas insolúveis contam como falha. São réguas diferentes
4. Procure intervalo de confiança em vez de número único. O Epoch AI publica os scores de SWE-bench Verified com intervalo de mais ou menos um erro padrão em torno da média verdadeira do score, e o Artificial Analysis estima intervalo de confiança de 95% menor que ±1% no Intelligence Index v4.1.1, com base em experimentos com mais de 10 repetições em alguns modelos. O erro comum: comemorar diferença de um ponto entre dois modelos quando essa diferença cabe inteira dentro da incerteza da medição
5. Confira exclusões e ressalvas de harness. Tarefa removida por incompatibilidade de ambiente (como as 5 das 89 do Terminal-Bench v2.1), problema insolúvel contado como falha, passe único em vez de repetições (como o AA-Omniscience sobre 6.000 questões). O erro comum: olhar só o percentual grandão e ignorar a linha miudinha embaixo da tabela, que é justamente onde mora a explicação do número

Vídeo do canal:

Pra quem tá começando do zero e quer ver ferramenta de IA rodando na prática, do setup ao resultado na tela, esse vídeo do canal mostra o passo a passo

Conclusão: o número sozinho não decide nada

A métrica só serve se ela casar com o seu modo de trabalho, e é isso que a tabela nunca te conta

Se você manda um prompt e usa a resposta que veio, o seu número é pass@1 (e avg@k como proxy)

Se você tem pipeline com verificação automática, testes rodando e um jeito de escolher a saída boa, aí sim pass@k descreve algo real do seu lado

E lembra do contraste que abriu o post: 28,8% e 70,2%, mesmo modelo, mesmo HumanEval, só mudou a métrica

É o tamanho do buraco que existe entre "o modelo consegue" e "o modelo consegue na primeira"

Próximo passo prático: escolhe dois modelos candidatos, abre a metodologia de cada score e compara SÓ números medidos da mesma forma (mesma métrica, mesmas repetições, mesmo harness)

E depois roda um teste seu, com as suas tarefas reais, que é o único benchmark que tem o seu código dentro 🙂

até o próximo post!