notícias

한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina

Relatório do coração da máquina

Editor: Zhang Qian, Xiaozhou

Alguém disse: “Estávamos esperando morangos, mas lançaram couve”. Vamos ver para que serve essa “couve”.

As capacidades de programação de grandes modelos sempre atraíram muita atenção, e o surgimento do superpoderoso programador de IA Devin trouxe o tópico "A IA pode substituir os programadores" para o primeiro plano. Recentemente, Devin também introduziu um novo oponente - um programador independente de IA lançado pela empresa start-up CosineGênio. A empresa disse que Genie superou facilmente Devin, marcando 30% no benchmark SWE de terceiros, enquanto Devin marcou apenas 13,8%.

Este SWE-Bench é um conjunto de dados de referência usado para avaliar a capacidade do LLM de resolver problemas reais de software no GitHub. Ele coleta 2.294 pares Issue-Pull Request de 12 repositórios Python populares. Durante o teste, o LLM obterá uma base de código e uma descrição do problema e, em seguida, gerará um patch para resolver o problema descrito no problema. Este conjunto de dados tem sido amplamente utilizado na avaliação das capacidades de programação de IA.

À medida que as capacidades de programação de IA evoluem, o mesmo acontece com este benchmark. Esta manhã, o modelo OpenAI "Strawberry" relatado online foi adiado novamente, mas a OpenAI lançou algo novo, que é uma versão melhorada do SWE-Bench - SWE-bench Verified.

A OpenAI apontou que o banco SWE original tinha alguns problemas que podem ter feito com que as capacidades autônomas de engenharia de software do modelo fossem subestimadas. Portanto, durante o processo de melhoria, eles colaboraram com os autores originais do SWE-Bench para realizar triagem manual e melhoria para garantir que o escopo dos testes unitários fosse apropriado e a descrição do problema fosse clara.

Em novos testes realizados no SWE-bench Verified, muitos agentes de programação de IA obtiveram pontuações mais altas do que antes. Entre eles, a solução Agentless da UIUC até dobrou a pontuação. OpenAI acredita que isso prova que o benchmark anterior tem a falha de subestimar as capacidades de programação de IA.

Mas para internautas de todo o mundo que estão assistindo “Strawberry”, este lançamento ainda é muito superficial. Alguém disse: “Estávamos esperando morangos, mas soltaram couve”.

Conhecimento prévio sobre SWE-bench

Cada exemplo no conjunto de testes SWE-bench foi criado a partir de um problema resolvido do GitHub em 12 repositórios de código Python de código aberto no GitHub. Cada amostra tem uma solicitação pull (PR) associada que inclui código de solução e testes de unidade para verificar a exatidão do código. Esses testes de unidade são chamados de testes FAIL_TO_PASS porque falham antes que o código da solução no PR seja adicionado e são aprovados após sua adição. Cada amostra também inclui testes PASS_TO_PASS que passam antes e depois da mesclagem do PR para verificar se o PR quebra outros recursos na base de código que não estão relacionados ao problema.

No SWE-bench, o agente de IA obtém o texto original do problema do GitHub, que é a declaração do problema, e tem acesso à base de código. Dada esta informação, o agente deve editar os arquivos na base de código para resolver o problema.

As edições feitas pelo agente de IA serão avaliadas executando os testes FAIL_TO_PASS e PASS_TO_PASS. Se o teste FAIL_TO_PASS for aprovado, significa que o editor corrigiu o problema. Se o teste PASS_TO_PASS for aprovado, significa que a edição não quebrou partes estranhas da base de código. Para resolver totalmente o problema original do GitHub, ambos os conjuntos de testes devem ser aprovados.

Três direções de melhoria para melhorar a robustez e confiabilidade do banco SWE

A fim de melhorar a robustez e confiabilidade do banco SWE. A equipe de desenvolvimento identificou três direções principais para melhoria:

• Os testes unitários usados ​​para avaliar a correção de uma solução são muitas vezes muito específicos e às vezes nem relevantes para o problema. Isso pode resultar na rejeição da solução correta.
• As descrições dos problemas para muitas amostras não eram suficientemente claras, levando à ambiguidade sobre qual era o problema e como deveria ser resolvido.
• Às vezes é difícil configurar de forma confiável um ambiente de desenvolvimento de bancada SWE para o agente, o que pode inadvertidamente causar falhas nos testes de unidade, independentemente da solução. Neste caso, uma solução perfeitamente válida pode ser classificada como incorreta.

SWE-bench verificado

Para resolver esses problemas, a OpenAI iniciou uma campanha de anotação manual por desenvolvedores de software profissionais, examinando cada amostra no conjunto de testes do SWE-bench para garantir que os testes de unidade tivessem o escopo adequado e as descrições dos problemas fossem claras e inequívocas.

Juntamente com os autores do SWE-bench, eles lançaram o SWE-bench Verified: um subconjunto do conjunto de testes original do SWE-bench, contendo 500 amostras que foram verificadas por anotadores humanos. Esta versão substitui os conjuntos de testes originais SWE-bench e SWE-bench Lite. Além disso, eles estão lançando anotações humanas para todas as amostras de teste de bancada SWE.

Eles também colaboraram com os autores do SWE-bench para desenvolver uma nova ferramenta de avaliação para o SWE-bench que usa um ambiente Docker conteinerizado para tornar a avaliação no SWE-bench mais fácil e confiável.

• Endereço da ferramenta: https://github.com/princeton-nlp/SWE-bench/tree/main/docs/20240627_docker

Método de melhoria

A OpenAI trabalhou com 93 desenvolvedores de software com experiência em Python para selecionar manualmente amostras do SWE-bench e anotar 1.699 amostras aleatórias no conjunto de testes do SWE-bench e, finalmente, obteve o SWE-bench Verified.

Sua abordagem é anotar as amostras no conjunto de testes de bancada SWE para garantir a imparcialidade e a precisão do teste. Especificamente, eles se concentram em dois pontos principais: primeiro, avaliar se a descrição do problema é detalhada o suficiente para evitar que uma descrição excessivamente vaga cause testes injustos; segundo, verificar se o teste de unidade FAIL_TO_PASS filtrará incorretamente soluções válidas;

Cada critério de anotação possui um rótulo no intervalo [0, 1, 2, 3] com gravidade crescente. Os rótulos 0 e 1 são menores; os rótulos 2 e 3 são graves, indicando que a amostra é inadequada de alguma forma e deve ser descartada.

Além disso, a OpenAI avalia a dificuldade de cada amostra pedindo aos anotadores que estimem quanto tempo levaria para os desenvolvedores decidirem e implementarem uma solução, assumindo que a amostra está livre de problemas. Por fim, o OpenAI oferece uma opção de entrada de formato livre para sinalizar quaisquer outros problemas importantes com a amostra.

Para construir o SWE-bench Verified, o OpenAI filtra quaisquer amostras do conjunto de testes original com uma declaração de problema ou gravidade de teste de unidade FAIL_TO_PASS de 2 ou superior, e também filtra quaisquer amostras marcadas com outros problemas sérios.

Anotar resultados

De acordo com os novos padrões, grande parte das amostras na bancada SWE original não são qualificadas. Conforme mostrado na figura, 38,3% das amostras foram sinalizadas porque a declaração do problema não era clara o suficiente e 61,1% foram sinalizadas porque os testes de unidade poderiam sinalizar injustamente soluções válidas como incorretas (Gravidade 2, 3 Os dois níveis se somam) . No geral, seu processo de anotação resultou na filtragem de 68,3% das amostras do banco SWE devido a declarações de problemas pouco claras, testes de unidade injustos ou outros problemas.

A figura abaixo compara a distribuição de dificuldade do conjunto de dados do banco SWE original e do novo conjunto de dados verificado do banco SWE. Eles estimam a distribuição de dificuldade do banco SWE com base em um subconjunto aleatório de 1.699 amostras.

Como pode ser visto na figura, no conjunto de dados do banco SWE original, o tempo estimado de conclusão da maioria (77,8%) das amostras é inferior a uma hora de trabalho para um engenheiro de software experiente. O SWE-bench Lite e o novo conjunto de dados verificados do SWE-bench aumentam ainda mais essa proporção, com expectativa de que menos de 10% dos problemas levem mais de uma hora para serem resolvidos. No entanto, os mecanismos por trás dessa mudança são bem diferentes: o SWE-bench Lite é uma subamostragem do conjunto de dados original para facilitar o benchmarking, enquanto o SWE-bench Verified tenta remover recursos inviáveis ​​da amostra do conjunto de dados.

Desempenho de cada agente no banco SWE verificado

No novo conjunto de dados verificado pelo SWE-bench, a equipe de desenvolvimento testou o desempenho do GPT-4o usando vários andaimes de código aberto que tiveram um bom desempenho na tabela de classificação do SWE-bench original.

Verificou-se que o desempenho do GPT-4o no andaime de melhor desempenho atingiu 33,2% no banco SWE verificado, mais que o dobro da pontuação de 16% no banco SWE original. No geral, isso confirma a suspeita inicial da OpenAI de que o banco SWE original subestimou as capacidades do agente.

É importante notar que o salto do SWE-bench Lite para o SWE-bench Verified não é tão óbvio, pois após a filtragem, o SWE-bench Lite já é mais fácil do que o conjunto de dados completo.

Análise de desempenho estratificada por dificuldade

A melhoria no desempenho quando avaliada no SWE-bench Verified pode ser parcialmente devida à distribuição das amostras de teste sendo distorcidas em direção a amostras mais simples.

A OpenAI investigou isso traçando o desempenho estratificado por dificuldade. Se o novo conjunto de dados simplesmente alterar a distribuição de dificuldade para incluir amostras mais fáceis, o desempenho estratificado dentro de cada categoria não muda, como é o caso do SWE-bench original para o SWE-bench Lite.

Em contraste, a OpenAI observou que o desempenho do agente melhorou em todas as categorias de dificuldade ao mudar para o SWE-bench Verified, consistente com o efeito esperado de remover amostras impossíveis de todas as categorias, em vez de simplesmente mover Remover amostras difíceis.

Link de referência: https://openai.com/index/introduzindo-swe-bench-verified/