Como ler benchmarks de programação com IA e evitar escolher um vencedor no papel

Em suma: o número «resolve 76 por cento das tarefas» diz quase nada por si só. O que importa é o conjunto de tarefas que produziu esse resultado, que modelo e wrapper do agente foram avaliados em conjunto, se as tarefas são recentes ou antigas e quanto custou. Sem estas condições, a percentagem serve para um banner publicitário, mas não para escolher uma ferramenta.

A seguir, explico em termos simples o que medem os dois principais benchmarks de programação, onde se esconde a armadilha nas tabelas e como verificar qualquer classificação num minuto antes de confiar nela. As definições históricas dos benchmarks são discutidas abaixo. Não se reproduz aqui um retrato atual emparelhado da classificação; comparar pontuações ou custos atuais exige tabela ligada, data e configuração próprias.

Saiba mais sobre como trabalhar com modelos na documentação da Ailoot.

O que mostra realmente uma percentagem de benchmark?#

Um benchmark funciona de forma simples. Existe uma lista preparada de tarefas de programação. A ferramenta recebe cada tarefa, devolve código e o sistema executa testes automatizados para verificar se a solução funciona. A proporção de tarefas aprovadas é a percentagem apresentada na tabela.

A vantagem é a objetividade da avaliação. Um teste passa ou falha; ninguém atribui uma pontuação «a olho». Neste aspeto, os benchmarks são mais honestos do que quaisquer análises ou testemunhos.

A fragilidade é precisamente a mesma. O conjunto de tarefas é finito e conhecido antecipadamente por todos, incluindo por quem treina os modelos. Cada medição tem as suas próprias condições. E é quase certo que as tarefas do conjunto não se parecem com aquilo que faz. Daí resultam todas as armadilhas que explico abaixo. A percentagem descreve o comportamento de uma ferramenta perante uma lista fechada de tarefas de outra pessoa e não se transfere diretamente para o seu projeto.

O que mede o HumanEval e porque já não pode escolher com base nele?#

O HumanEval foi criado pela OpenAI e lançado em 2021 com o modelo Codex. Contém 164 pequenas tarefas em Python: os modelos recebem a descrição verbal de uma função, escrevem o seu corpo e um conjunto de testes automatizados verifica se funciona corretamente.

Na altura, era um bom elemento de distinção. No seu próprio artigo, os autores apresentam este valor: o primeiro Codex resolveu 28,8 por cento das tarefas numa tentativa, enquanto o GPT-3 normal não resolveu nenhuma.

Desde então, os modelos evoluíram e, hoje, os mais fortes completam quase todo o HumanEval. Quando todos obtêm resultados próximos de 100 por cento, a tabela deixa de distinguir o que quer que seja: as diferenças entre ferramentas desaparecem. A isto chama-se saturação do benchmark, e o HumanEval está nesse estado há muito tempo.

A segunda falha é mais grave. As tarefas são minúsculas: escrever uma função a partir de uma descrição. O seu trabalho real é diferente: envolve um projeto grande, com histórico, em que é preciso compreender o código de outra pessoa, encontrar um defeito e evitar danificar o código adjacente. Existe um abismo entre «escrever uma função de raiz» e «corrigir um erro num projeto ativo». Por isso, hoje uma pontuação elevada no HumanEval já não é motivo para escolher uma ferramenta; é mais uma indicação de que «os conceitos básicos estão assegurados».

O que mede o SWE-bench e como se aproxima mais do trabalho real?#

O SWE-bench é fundamentalmente diferente e, por isso, mais interessante. Foi criado a partir de problemas reais e pull requests em projetos populares do GitHub. Segundo os autores, contém 2 294 tarefas de 12 grandes repositórios Python e foi lançado em outubro de 2023.

A lógica de avaliação é honesta. Seleciona-se um ponto num projeto em que existia um defeito real e um conjunto de testes que falhavam na altura. A ferramenta recebe a descrição do problema e edita o código. Depois, executam-se esses mesmos testes: se passarem, a tarefa está realmente resolvida; aqui ninguém confia em promessas verbais.

Os primeiros valores mostram quanto isto é mais difícil do que as tarefas de brinquedo. A primeira abordagem de referência obteve apenas 1,96 por cento no SWE-bench, e o primeiro agente obteve 12,47 por cento. Por outras palavras, até aproximar-se do trabalho real de programação era difícil; as percentagens cresceram mais tarde, mas começaram perto de zero.

Por isso, quando hoje vê valores elevados numa classificação de agentes de programação com IA, na maioria das vezes vêm do SWE-bench ou da sua subcategoria verificada por humanos, com 500 tarefas, chamada SWE-bench Verified. É um benchmark razoável. Mas também tem condições sem as quais a percentagem é enganadora, e é disso que vou falar a seguir.

Nem o benchmark mais honesto de uma tabela representa ainda um resultado no seu projeto. O resultado depende da forma como trabalha com a ferramenta, e a primeira linha da classificação determina muito pouco. Para trabalhar de forma fiável, importa a combinação: clone de IA, Second Brain e engenharia de contexto. Um contexto limpo melhora a sua taxa de sucesso pessoal de forma muito mais evidente do que escolher um modelo numa tabela.

Porque apresenta o mesmo modelo percentagens diferentes?#

É aqui que se esconde o erro mais comum ao ler benchmarks. As pessoas leem uma tabela como uma classificação de modelos: este modelo é dois por cento mais inteligente do que aquele. Mas há três elementos que afetam a percentagem, e o modelo é apenas um deles.

Primeiro, o próprio modelo. Segundo, o wrapper do agente que o envolve: um programa que permite ao modelo percorrer ficheiros, executar comandos, ler erros e reescrever código. O mesmo modelo num wrapper inteligente e num simples apresenta resultados diferentes, porque o wrapper determina como o modelo trabalha com o projeto. Terceiro, o nível de raciocínio, ou seja, a profundidade com que o modelo pondera cada passo. Quanto mais tempo pensa, normalmente mais elevada é a percentagem e maior é o custo.

Uma comparação reproduzível deve preservar a configuração completa. Use isto como modelo de relatório, não como classificação medida:

Isto permite ver o que mudou e se a comparação isola realmente o nível de raciocínio. O exemplo numérico anterior sem ligação não é tratado como resultado medido.

A regra é esta: uma boa classificação indica sempre qual foi o modelo, o wrapper e o nível de raciocínio utilizados. Se a tabela só tiver o nome do modelo e uma percentagem, sem especificar o wrapper, é difícil confiar nela: não se sabe o que foi realmente medido. O artigo sobre a classificação de agentes de programação com IA explica melhor o que compõe a combinação «modelo mais wrapper».

Isto também explica porque é que uma ferramenta com uma pontuação de topo por vezes tem dificuldades consigo. O benchmark mede um modelo no wrapper refinado de outra pessoa, com as tarefas de outra pessoa. O seu wrapper, o seu projeto e o contexto que fornece ao modelo são diferentes. No seu projeto, o resultado depende do contexto; a linha da tabela é secundária.

Porque é que as tarefas «expiram» e o que é a fuga de dados de treino?#

Eis a armadilha que não se vê no próprio valor, mas que o compromete mais do que qualquer outra coisa. Os modelos são treinados com enormes quantidades de texto e código recolhidos na Internet. E quase todos os benchmarks de programação estão disponíveis publicamente: as tarefas, os testes e as soluções de referência.

O mecanismo é simples. Se uma tarefa e a sua solução correta tiverem entrado nos dados de treino, o modelo pode tê-las memorizado. Durante a avaliação, em vez de resolver a tarefa, pode estar a recuperar uma resposta conhecida da memória. Parece uma solução, mas é apenas memória. A isto chama-se fuga de dados de treino ou contaminação dos dados.

Quanto mais antigo e popular for o conjunto de tarefas, maior é o risco. O HumanEval está online desde 2021; foi reescrito, analisado e incluído inúmeras vezes em incontáveis conjuntos de dados. Seria estranho esperar que um modelo moderno nunca o tivesse «visto». Por isso, a atualidade das tarefas é um indicador de qualidade independente para um benchmark. Um bom conjunto é atualizado regularmente ou mantém algumas tarefas fechadas para que não possam ser aprendidas antecipadamente.

O que deve fazer ao consultar uma classificação? Verifique a data das tarefas e se o conjunto é atualizado. Se um benchmark se basear em defeitos recentes dos últimos meses, merece mais confiança. Se for um conjunto de há cinco anos, uma percentagem elevada diz mais sobre a boa memória do modelo do que sobre a sua capacidade para resolver uma tarefa nova. Este efeito é demonstrado com um exemplo concreto no artigo sobre o benchmark FrontierCode recente, cujas tarefas eram deliberadamente novas.

Porque é que uma diferença de alguns pontos percentuais muitas vezes não significa nada?#

Outro motivo pelo qual o primeiro lugar de uma tabela pode ser enganador: um modelo não responde sempre da mesma forma. Perante o mesmo prompt, pode seguir uma linha de raciocínio ligeiramente diferente. Assim, se executar uma ferramenta várias vezes no mesmo conjunto de tarefas, a percentagem varia um pouco entre execuções; a essa flutuação chama-se variância.

A conclusão prática é simples. Quando duas linhas de uma classificação diferem um ou dois por cento, essa diferença pode facilmente ser apenas ruído. É insensato perseguir uma ferramenta que é «dois por cento melhor»: na execução seguinte, podem facilmente trocar de posição. Vale a pena considerar uma diferença significativa quando é percetível e se mantém num conjunto amplo de tarefas; alguns pontos não chegam a esse patamar.

E a última coisa, quase sempre mais importante do que a própria percentagem, é o preço. Resultados semelhantes podem custar valores muito diferentes. Uma comparação de custos exige ambas as configurações de modelo e executor e a despesa total nas tarefas avaliadas, incluindo tentativas falhadas. Divida pelas tarefas tentadas para o custo por tentativa ou pelas resolvidas para o custo por tarefa resolvida e identifique a medida usada. Este artigo não fornece uma medição emparelhada de custos com fonte. Por isso, consulte sempre uma linha da classificação juntamente com o preço, porque a percentagem, por si só, pouco significa. O artigo sobre o custo de uma tarefa resolvida explica como comparar ferramentas de forma justa pelo custo.

Como ler qualquer tabela de benchmark num minuto?#

Vou condensar tudo numa lista breve. Abra qualquer tabela de classificação e percorra estes sete pontos por ordem.

1. Que conjunto de tarefas? Hoje, o HumanEval é fraco; o SWE-bench aproxima-se mais do trabalho real. Se o conjunto nem sequer for identificado, não vale a pena continuar a ler.
2. As tarefas são recentes ou antigas? Um conjunto recente ou parcialmente fechado é mais fiável do que um conjunto público antigo que o modelo possa ter aprendido.
3. Que modelo foi medido? O nome e a versão exatos, não um «IA» vago ou o nome de uma família de modelos.
4. Que wrapper do agente? A percentagem pertence à combinação «modelo mais wrapper». Se o wrapper não for especificado, não se sabe o que foi medido.
5. Que nível de raciocínio? O mesmo modelo apresenta percentagens e custos diferentes em níveis diferentes.
6. Quanto custa uma tarefa? Resultados semelhantes podem ter preços que diferem várias vezes. Consulte a percentagem juntamente com o custo.
7. Qual é a variância? Uma diferença de um ou dois pontos entre linhas é muitas vezes apenas ruído.

Há uma oitava pergunta, que diz respeito a si: As tarefas do conjunto são semelhantes ao seu trabalho? Um benchmark de tarefas em Python pouco diz a quem está a criar um site ou um bot com outro conjunto de ferramentas. Nem um valor honesto em tarefas de outra pessoa garante um resultado no seu projeto. Só há uma forma fiável de verificar: executar algumas das suas tarefas típicas com a ferramenta e analisar o resultado por si. O artigo sobre como verificar código gerado por IA explica como perceber se o código funciona, mesmo que não saiba programar.

Então, o que deve analisar no fim?#

A ideia principal de todo o artigo é simples: uma posição na classificação é um motivo para analisar melhor uma ferramenta, mas terá de investigar mais por si. Um valor elevado apenas diz que uma ferramenta teve um desempenho razoável numa lista fechada específica de tarefas e em determinadas condições. A percentagem não mostra se essas condições correspondem às suas.

Por isso, leia o que está por baixo da linha da classificação: que tarefas foram utilizadas, quão recentes são, que combinação de modelo e wrapper foi usada, qual era o nível de raciocínio, quanto custa e se a diferença se perde no ruído. Uma tabela que não responda a estas perguntas serve para um banner publicitário. A análise que ferramenta escolher para programar em 2026 explica que ferramenta escolher para as suas tarefas.

Eis algo que importa mais do que qualquer benchmark. Até a melhor ferramenta da classificação tem dificuldades com um contexto desorganizado e trabalha bem com um contexto limpo. A sua taxa de sucesso pessoal depende do que fornece ao modelo e da forma como define a tarefa; a linha da tabela é secundária. A classificação ajuda a eliminar as opções claramente fracas, mas é você quem produz o resultado.

Uma posição na classificação ajuda a eliminar opções fracas, mas os resultados no seu projeto dependem do método: clone de IA mais Second Brain mais engenharia de contexto.

Para continuar — Ailoot.