Pare de Avaliar Modelos pelo Benchmark Deles. Extraia o Seu da Fila de Merge.

Dois times publicaram benchmarks de código neste trimestre, e nenhum dos dois usou um dataset público. A Ramp montou 80 tarefas a partir dos próprios pull requests já mergeados em produção. A Epoch AI, em parceria com a METR, criou o MirrorCode, no qual o modelo precisa reimplementar um programa inteiro e reproduzir a saída dele exatamente, contra testes que nunca vê. Os dois definiram um critério de aceitação mais duro que o de qualquer leaderboard em circulação. E os dois publicaram o pipeline que produz as tarefas, que é a parte aproveitável.

Já argumentamos à exaustão que benchmarks públicos de código são contaminados, inválidos por construção, quebrados nas duas pontas da medição e manipulados pelos fornecedores que pontuam neles. Esse caso está feito. O que vem agora é a instrução de construção do substituto, montada a partir do que esses dois times divulgaram.

A sua fonte de tarefas já existe, e é a fila de merge

As tarefas da Ramp vêm de pull requests que já foram para produção em autorização de cartão, pagamento de contas, reembolsos, contabilidade, compras, tesouraria, fraude e os próprios sistemas de agentes da empresa. Oito domínios de produção, nenhum deles um repositório de brinquedo.

O motivo de isso funcionar é estrutural. Um PR mergeado já carrega todo componente que uma tarefa de benchmark precisa, escrito por gente que não fazia ideia de estar redigindo uma avaliação. A issue vinculada ou a descrição é o prompt. O diff é a solução de referência. Os testes que rodaram no CI, somados à revisão humana que liberou o merge, são o avaliador. O trabalho aqui é de extração, não de autoria, sobre material que já foi especificado, já foi resolvido e já foi aceito por um revisor que se importava com o resultado.

Essa procedência também resolve o problema de distribuição. O SWE-Bench e seus descendentes amostram repositórios Python populares de código aberto, o que é uma proxy estranha para um ledger de fintech, um pipeline de sinistros ou um monólito Rails com quinze anos de regras de domínio acumuladas. A sua fila de merge é uma amostra exatamente da distribuição que te interessa, porque ela é essa distribuição.

Descarte toda tarefa que não carrega sinal

O filtro que a Ramp descreve é a parte que quase nenhuma suíte interna de eval implementa, e adotá-lo sai de graça.

“Quando nenhum modelo resolve a tarefa, isso pode significar um teste frágil ou um ambiente quebrado, mais do que dificuldade real. Quando todo modelo resolve, a tarefa é descartada por não carregar sinal.”

Duas regras apontando para lados opostos. Falha universal é tratada primeiro como suspeita sobre o seu próprio harness, antes de virar evidência sobre o modelo. Sucesso universal é tratado como tarefa morta e removido. Sobra a faixa em que os modelos de fato divergem, a única faixa em que uma nota consegue informar uma decisão.

Rode esse filtro na sua suíte interna e espere que ela encolha. Uma suíte em que todos os modelos de fronteira tiram 94% te diz que as tarefas venceram, e não diz nada sobre qual modelo colocar em produção.

Quatro códigos de defeito antes de a tarefa valer

A Ramp nomeia quatro modos de falha na construção das próprias tarefas: test_overconstrained, test_missing_assertion, prompt_solution_leakage, prompt_missing_context.

Leia isso como checklist antes de tratar como taxonomia. Dois deles punem trabalho correto: um teste superrestrito reprova uma solução válida por ela ter escolhido outra estrutura interna, e um prompt sem contexto cobra comportamento sobre o qual o modelo nunca foi avisado. Dois deles inflam a nota: uma asserção ausente deixa passar uma correção parcial, e o vazamento de solução entrega a resposta ao modelo dentro do próprio enunciado.

O vazamento é o defeito específico deste caminho de construção, e é o que você vai encontrar. Quando o prompt é gerado a partir de um PR mergeado, a descrição frequentemente contém a correção. “Cachear a consulta de taxa na sessão” é o diff em prosa, com rótulo de enunciado. Cada tarefa extraída precisa de uma passagem em que um humano retira a solução e deixa apenas o problema observável: o relato do bug, o comportamento que falhava, o requisito como quem pediu enunciou antes de alguém saber resolvê-lo.

A sobreposição com a auditoria do SWE-Bench Pro feita pela OpenAI merece atenção. Duas organizações, trabalhando de forma independente sobre corpora diferentes, convergiram essencialmente para as mesmas quatro formas de uma tarefa de código quebrar. Essa convergência é sinal forte de que esses são os modos de falha reais, em vez de um artefato da metodologia de um time só.

Coloque a barra onde os seus engenheiros a colocam

A Ramp pontua pass@1 em tentativa única. Sem retentativas, sem best-of-n. Estourar a janela de contexto conta como falha, e não como execução incompleta a ser descartada.

A justificativa declarada: “Cada resultado é uma única tentativa pass@1, espelhando a barra que os engenheiros aplicam a agentes em segundo plano: uma mudança correta e pronta para revisão logo na primeira tentativa.”

É o critério de aceitação fazendo trabalho de verdade. Um número pass@10 informa que o modelo eventualmente produz um patch correto se um humano continuar re-rolando o dado. Isso serve como métrica de pesquisa e não serve para decisão de compra, porque ninguém aloca uma pessoa para re-rolar um agente dez vezes por ticket. Contar o estouro de contexto como falha fecha a outra saída de emergência: um modelo que não termina dentro da própria janela não resolveu a sua tarefa, seja qual for a aparência do diff parcial.

O leaderboard interativo da Ramp não renderizou quando puxamos a página, então não temos nenhuma nota de modelo para reportar de lá. O ativo transferível é a metodologia, de qualquer forma.

A variante mais dura: um oráculo que o modelo nunca vê

O MirrorCode chega ao mesmo objetivo por outro caminho. O modelo recebe a documentação de um programa e precisa reimplementá-lo do zero, em uma linguagem especificada, bem o bastante para que a saída bata exatamente com a do original. Os testes ficam ocultos. Não há o que casar por padrão, porque o critério de aceitação é equivalência de comportamento com uma implementação de referência que o modelo não consegue ler.

A configuração do leaderboard (15 alvos, duas linguagens, três execuções cada, com 10 bilhões de tokens e sete dias permitidos por tentativa) reporta solve@100% de 64% ±10 para o Claude Fable 5, 20% ±9 para o GPT-5.6 Sol, 16% ±8 para o GPT-5.4 e 10% ±6 para o GPT-5.5. O paper da Epoch usou outra configuração e afirma que esses números não são comparáveis, então trate este leaderboard como uma medição isolada, sem portar o ranking para outro contexto.

Os números de orçamento são o que torna isso operacionalmente interessante. O Claude Opus 4.7 reimplementou o gotree, cerca de 16.000 linhas de Go com mais de 40 comandos, em 14 horas por US$ 251, contra uma estimativa humana de duas a dezessete semanas. As melhores execuções passaram em 2.000 dos 2.001 testes. A maior tarefa do conjunto custou US$ 2.600 em uma única execução, com o modelo trabalhando 19 dias sem intervenção humana.

A observação da Epoch sobre por que ninguém enxerga isso: “Muitos benchmarks existentes de engenharia de software limitam o gasto de inferência a algo em torno de US$ 1 a 10, mesmo quando a tarefa levaria semanas para um humano concluir.” Um teto de dez dólares sobre uma tarefa de duas semanas não mede capacidade. Mede o teto. Se a sua eval interna impõe um orçamento de tokens escolhido por conveniência, você está publicando um número sobre o seu orçamento com o rótulo de número sobre o modelo.

Duas ressalvas que a Epoch declara abertamente, e você deve carregar as duas. Mesmo tentativas fracassadas costumam passar em 90% ou mais dos testes, então uma taxa binária de resolução esconde a maior parte do sinal real. E eles não conseguem descartar que memorização contribua para o desempenho, já que os programas de referência são públicos.

O dado precisa ficar contratualmente fora do treino

A Ramp fecha o ciclo com uma frase: “Os dados do Ramp SWE-Bench nunca são usados para treinamento, o que é garantido por acordos com os provedores de modelos.”

É o que separa um benchmark de um benchmark que continua válido. No instante em que as suas tarefas chegam a um corpus de treino, a geração seguinte de modelos pontua bem nelas pelo motivo errado, e você reconstruiu o problema do qual saiu dos leaderboards públicos para fugir. Controle técnico não basta aqui, porque os prompts estão sendo enviados ao endpoint de inferência de outra empresa. O controle é contratual, e o lugar dele é no mesmo acordo de fornecedor em que você negocia retenção e residência de dados.

Se o contrato com o seu provedor hoje não diz que os seus dados de avaliação estão excluídos do treinamento, o seu benchmark interno tem validade contada em releases de modelo.

Construa a primeira versão neste sprint

Puxe os últimos 200 PRs mergeados. Fique com os que têm issue vinculada, mudança de teste e diff abaixo de umas 400 linhas. Vão sobrar de 30 a 50 candidatos, o suficiente para começar.

Para cada candidato, retire a solução do prompt e mantenha só o problema como ele foi enunciado antes de a correção existir. Depois rode os quatro códigos de defeito contra ele e jogue fora tudo que falhar. Pontue três modelos em pass@1, tentativa única, com estouro de contexto contando como falha. Apague toda tarefa que os três resolvem e toda tarefa que nenhum resolve, checando antes se as não resolvidas escondem um ambiente quebrado.

O que sobra é pequeno, feio e seu. Vai prever qual modelo lida melhor com a sua base de código com mais precisão do que qualquer nota pública já previu, pela razão simples de ser feito da sua base de código. Depois procure o time de conta do seu provedor e obtenha a exclusão de treinamento por escrito, porque é essa cláusula que mantém tudo isso medindo alguma coisa daqui a um ano.

---

Fontes

• Ramp Labs. “Ramp SWE-Bench.” Julho de 2026.
• Epoch AI, em codesenvolvimento com a METR. “MirrorCode: What’s the largest software project AI can complete on its own?.” Junho de 2026.

A Victorino ajuda organizações de engenharia a construir benchmarks internos a partir do próprio histórico de produção, para que decisões sobre modelos se apoiem em evidência da base de código que paga as contas: contato@victorino.com.br | www.victorino.com.br