Separar o sinal do ruído nas avaliações de código

Medir com precisão as capacidades dos nossos modelos é importante para decisões sólidas de implementação e segurança, incluindo decisões no âmbito do Preparedness Framework⁠(abre numa nova janela) da OpenAI. A cada lançamento de um modelo, comunicamos resultados para vários benchmarks externos e internos, a fim de acompanhar o progresso dos modelos. Quando as avaliações têm falhas que afetam os resultados, podem criar uma perceção falsa das capacidades, deturpando análises de segurança e afetando prioridades de investigação.

Investigámos recentemente como um dos benchmarks de programação mais utilizados, o SWE-bench Verified, tinha problemas fundamentais de conceção e contaminação, e concluímos que a avaliação já não fornecia um sinal significativo sobre capacidades de desenvolvimento de software. Na altura, incentivámos a comunidade em geral a mudar para o SWE-Bench Pro.

O SWE-Bench Pro⁠(abre numa nova janela) foi concebido para melhorar o SWE-bench Verified, testando modelos em horizontes mais longos e tarefas de programação mais realistas, de modo a acompanhar melhor as capacidades de programação agêntica. Tal como no SWE-bench Verified, as tarefas são extraídas programaticamente do histórico de alterações de funcionalidades num conjunto de repositórios públicos e privados. Os modelos têm de implementar uma solução que passe novos testes para uma funcionalidade, sem quebrar a funcionalidade existente. Na partição pública de 731 tarefas, os modelos de fronteira melhoraram de uma taxa de aprovação de 23,3% para 80,3% em oito meses.

Desde então, realizámos uma auditoria semelhante ao SWE-Bench Pro, revendo o conjunto de dados com um pipeline de análise de pontos de dados. O pipeline analisou tentativas do modelo na tarefa, metadados da tarefa e rastos de falha para assinalar prováveis falhas de avaliação. Cada tarefa assinalada foi depois avaliada através de várias passagens por agentes investigadores e revista de forma independente por cinco engenheiros de software experientes, com os desacordos escalados para investigação adicional.

Os problemas enquadraram-se sobretudo em quatro categorias:

• Testes demasiado rigorosos¹ impõem detalhes de implementação específicos não especificados no prompt, invalidando muitas submissões funcionalmente corretas.
• Prompts subespecificados² omitem requisitos que os testes ocultos impõem e que não são razoavelmente inferíveis.
• Testes com baixa cobertura verificam de forma insuficiente a funcionalidade pedida, permitindo que correções incompletas passem.
• Um prompt enganador orienta os modelos para o comportamento errado ou contradiz o que os testes exigem.

As nossas conclusões apontam para a dificuldade de criar benchmarks exigentes mas justos e para a utilidade crescente dos agentes em verificações escaláveis da qualidade dos dados. À luz destes resultados, estimamos que cerca de 30% das tarefas do SWE-bench Pro têm falhas e aconselhamos os programadores de modelos a examinarem cuidadosamente os resultados.

O nosso objetivo é garantir que as falhas nas tarefas refletem limitações reais do modelo e que os sucessos refletem soluções completas e válidas para os requisitos do prompt. Para verificar a qualidade dos dados usados na avaliação, criámos um pipeline de garantia da qualidade para avaliar se cada ponto de dados reflete corretamente as capacidades do modelo.

Um filtro automatizado inicial analisa as instruções dadas ao modelo, as tentativas do modelo para resolver a tarefa e os testes usados para classificar essas tentativas, assinalando exemplos provavelmente defeituosos ou problemáticos. Este filtro assinalou 286 tarefas potencialmente defeituosas. Depois, fizemos uma revisão mais aprofundada desse subconjunto de duas formas: uma revisão por agentes com supervisão humana, que realiza verificações extensas com agentes investigadores e um juízo humano final; e uma campanha de anotação humana com programadores de software experientes.

Cada problema assinalado é auditado com agentes investigadores baseados no Codex, aos quais foi dado acesso ao repositório e ao ambiente da tarefa. Isto ajuda-os a distinguir uma ambiguidade razoável da tarefa, que muitas vezes pode ser resolvida estudando código próximo e convenções do repositório, de uma verdadeira subespecificação. O agente pode executar testes, inspecionar ficheiros no repositório e investigar tentativas do modelo e os seus modos de falha comuns na tarefa. Após várias repetições independentes destas auditorias mais aprofundadas, um investigador reviu os resumos, tomou uma decisão final e etiquetou os problemas prováveis.

Em paralelo, realizámos uma campanha de anotação humana sobre o subconjunto assinalado. Trabalhámos com engenheiros de software experientes, formados nos objetivos do benchmark, na taxonomia de problemas e nos casos-limite antes de reverem as tarefas. Cada tarefa foi revista por cinco engenheiros.

Os revisores formaram um juízo independente a partir do enunciado visível do problema, dos casos de teste e da solução de referência verdadeira (conhecida como gold patch), antes de usarem a análise do pipeline ou a transcrição como contexto de apoio. Depois, os revisores atribuíram uma etiqueta e uma classificação de gravidade com base em provas concretas, e escalaram desacordos ou casos de baixa confiança para revisão adicional.

Os revisores humanos tiveram maior probabilidade do que os agentes investigadores de marcar tarefas como defeituosas. Também houve algum desacordo sobre as categorias entre as duas vias de revisão, mas em nenhuma tarefa assinalada “sem falhas” foi a etiqueta humana mais comum. Nas categorias assinaladas pelo pipeline de agentes, os juízos dos revisores coincidiram em 74% dos casos.

Em comparação com o pipeline de agentes, os revisores humanos também foram mais propensos a selecionar várias etiquetas para uma tarefa, indicando que encontraram tarefas com falhas de várias formas ou que não se enquadravam claramente numa única categoria. Isto sugere que o pipeline agente-mais-revisor resultou numa etiquetagem conservadora: captou os mesmos modos gerais de falha identificados pelos humanos, mas subcontou casos em que os revisores viram problemas adicionais ou sobrepostos. A maior diferença ocorreu nos testes com baixa cobertura, que os humanos selecionaram como o problema mais comum em 9,4% do benchmark, em comparação com 4,1% no pipeline de agentes.

Os problemas que identificámos, juntamente com casos semelhantes no SWE-bench Verified, sublinham a importância de verificar rigorosamente os benchmarks. Os problemas e pull requests de repositórios open-source foram originalmente criados para colaboração humana, muitas vezes através de longas trocas entre responsáveis pela manutenção e contribuidores. Como resultado, as descrições dos problemas, o código integrado e os testes unitários nem sempre se alinham para formar tarefas limpas e isoladas que permitam avaliar modelos de forma fiável. Em particular, os testes incluídos em pull requests podem ser demasiado rigorosos, porque são escritos para validar uma alteração específica, e não para definir um padrão independente da implementação para resolver a tarefa.

Ao mesmo tempo, as falhas de avaliação são agora mais fáceis de detetar do que teriam sido ainda há pouco tempo. À medida que as capacidades dos modelos melhoram, podemos usar esses modelos para inspecionar prompts, testes, patches, rastos e casos-limite com muito maior profundidade e consistência, ajudando a revelar problemas de benchmarks que antes eram dispendiosos ou impraticáveis de encontrar em escala.

Esperamos que a comunidade de avaliação em geral desenvolva novos benchmarks criados por programadores de software experientes especificamente para testar capacidades dos modelos. Essa abordagem pode preservar o elevado nível de exigência e realismo que queremos para medir capacidades dos modelos, e permite uma melhor supervisão humana ao longo de todo o processo. Tendo em conta os problemas revelados nesta análise, retiramos a nossa recomendação anterior de adotar o SWE-Bench Pro.

Em última análise, uma avaliação deve fornecer um sinal significativo através de benchmarks difíceis de manipular, fáceis de confiar e genuinamente representativos da capacidade ou do alinhamento dos modelos. Como estes resultados informam as decisões de implementação e segurança da OpenAI, as avaliações que acompanhamos têm de ser válidas e informativas.