Senior SWE-Bench: benchmark open source para avaliar agentes no nível de engenheiros seniores

 (senior-swe-bench.snorkel.ai)
3 pontos por GN⁺ 4 시간 전 | 1 comentários | Compartilhar no WhatsApp
  • Senior SWE-Bench é um benchmark criado para avaliar agentes de programação não com tarefas excessivamente organizadas de nível júnior, mas de forma mais próxima a desenvolvimento de funcionalidades, correção de bugs e problemas de desempenho que engenheiros seniores reais assumem
  • As tarefas de funcionalidade usam instruções realistas que soam como mensagens em linguagem natural, e aumentam a confiabilidade da avaliação com um agente de validação que cria testes comportamentais de acordo com a solução enviada
  • As tarefas de bug vêm de PRs que começam com relatos de usuários e exigem investigação em tempo de execução como executar o serviço, analisar logs, dados de profiling e procedimentos de reprodução
  • A pontuação combina consistência em tempo de execução com métricas de qualidade baseadas nas práticas do codebase para avaliar um tasteful solve, e práticas importantes que não estão nas instruções também podem entrar na validação
  • Até mesmo o melhor modelo do leaderboard, Claude Opus 4.8, no modo Mini-SWE-Agent max, ficou em apenas pass@1 de 24,0%, mostrando que até os modelos de ponta falham em mais de 75% dos casos em soluções com consistência e taste de nível sênior

Projetando tarefas mais próximas de PRs reais

  • O Senior SWE-Bench é um benchmark que busca reduzir a diferença entre o uso real de agentes de programação, como se fossem engenheiros seniores, e avaliações feitas como se fossem tarefas para juniores
  • As tarefas vêm de PRs de vários repositórios, de bibliotecas a aplicações com múltiplos serviços, e focam em PRs criados por engenheiros que fizeram centenas de commits em cada repositório
  • Os principais tipos de tarefa se dividem em dois grupos
    • PRs de funcionalidade que atravessam várias etapas e várias stacks
    • PRs de bug e desempenho que exigiram investigação significativa em tempo de execução
  • Há 50 tarefas públicas e outras 50 privadas
  • Exemplos de repositórios incluídos

Tarefas de funcionalidade: instruções mais próximas da linguagem natural

  • As tarefas de funcionalidade usam instruções realistas que soam como mensagens em linguagem natural, em vez de requisitos excessivamente fragmentados
  • Para avaliar esse tipo de tarefa com estabilidade, foi introduzido um agente de validação (validation agent)
    • Ele usa receitas projetadas por especialistas
    • Ele escreve testes comportamentais de acordo com a solução enviada
  • As instruções refletem uma comunicação natural com agentes, e o tamanho mediano corresponde a 31% do SWE-Bench Pro

Tarefas de bug: de relatos de usuários à investigação em runtime

  • As tarefas de bug refletem relatos de usuários difíceis e exigem mais investigação de causa e processo de reprodução do que simples correções de código
  • As tarefas podem incluir trabalhos como
    • iniciar o serviço
    • depurar problemas sutis em runtime
    • verificar logs
    • usar dados de profiling
    • seguir procedimentos de reprodução
  • A origem são PRs cuja resolução exigiu investigação significativa em tempo de execução

Critérios de avaliação: medindo consistência e taste juntos

  • O Senior SWE-Bench combina testes de consistência em runtime com várias métricas de qualidade para pontuar um tasteful solve
  • As métricas de qualidade são baseadas em práticas observadas no codebase
  • O verificador e o agente de validação podem testar práticas importantes do codebase mesmo que elas não apareçam nas instruções
  • A condição de solve no leaderboard inclui os seguintes itens
    • Verifiers pass
    • Validation pass
    • Rubric > 0.5
    • Bloat < 2×
    • Practice > 2/5
    • Rel. taste > 2/5

Leaderboard: até o melhor modelo tem pass@1 baixo

  • O leaderboard mostra os resultados com base na Tasteful solve rate(pass@1)
  • Os principais resultados são
    • Claude Opus 4.8, Mini-SWE-Agent max: 24,0%
    • Claude Sonnet 5, Mini-SWE-Agent max: 19,4%
    • GPT-5.5, Mini-SWE-Agent xhigh: 16,0%
    • Claude Opus 4.7, Mini-SWE-Agent max: 14,1%
    • GPT-5.4, Mini-SWE-Agent xhigh: 14,0%
    • GLM-5.2, Mini-SWE-Agent max: 12,5%
    • Kimi K2.6, Mini-SWE-Agent default: 8,2%
    • Claude Sonnet 4.6, Mini-SWE-Agent high: 8,2%
    • Gemini 3.1 Pro, Mini-SWE-Agent high: 6,1%
    • Gemini 3.5 Flash, Mini-SWE-Agent medium: 3,0%
  • Mesmo os modelos de fronteira mais fortes não conseguem concluir mais de 75% das tarefas com consistência e taste de nível sênior

Escopo das tarefas e características do benchmark

  • Os tipos de tarefa são indicados como feature, bug, perf e migrat
  • As stacks incluem Py Svc, Elixir, Go, SQL, TS Lib, Py Lib, Rust, TS FE e outras
  • As tarefas de funcionalidade podem abranger vários serviços e tocam, em média, 11 arquivos por tarefa
  • Elas foram projetadas para exigir fluxos de trabalho longos, e até os agentes mais fortes precisam de centenas de etapas
  • O SLOC e o número de arquivos das soluções de referência são medidos da mesma forma nos três benchmarks
  • O tamanho das instruções exclui boilerplate do harness
  • A contagem de tokens e de etapas em outros benchmarks se baseia nas métricas autorreportadas de cada benchmark

Leituras relacionadas

1 comentários

 
GN⁺ 4 시간 전
Opiniões do Hacker News

  • Pelo que vi no Twitter, em uma aula de aprendizado de máquina da Tsinghua University houve uma prova em que os alunos tinham de criar quizzes que fizessem o maior número possível de LLMs falhar.
    Fico pensando como seria criar um benchmark desse tipo e atribuir pontuações ELO. Os modelos se enfrentariam, propondo perguntas, bugs e implementações incompletas, e o oponente teria de responder, corrigir ou completar

    • Poderíamos chamar isso de rede adversarial generativa (GAN) :)
      https://en.wikipedia.org/wiki/Generative_adversarial_network
    • O problema é como impedir estratégias degeneradas. Por exemplo, se você dá um hash SHA256 e pede para adivinhar a entrada original, é fácil demais criar um problema impossível
      Em uma disciplina, daria para impor a regra de que pelo menos um LLM precisa conseguir responder, mas não sei como resolver isso em um duelo um contra um
    • Acho que não foi Tsinghua, foi Fudan

  • Fico curioso para saber como este benchmark vai manter sua relevância ao longo do tempo
    Se o benchmark consistir em implementar funcionalidades de projetos open source, o LLM pode ter essas alterações nos dados de treinamento e conseguir dar a resposta igual ou com pequenas mudanças
    Por outro lado, se o benchmark incluir apenas mudanças de código posteriores ao cutoff de conhecimento do modelo, os problemas em T e T+1 serão diferentes, reduzindo a comparabilidade ao longo do tempo

  • Se fosse o Staff SWE Bench, acho que o LLM começaria duvidando se isso deveria ser feito, questionaria o projeto inteiro, recusaria o merge do código, mas aceitaria deletá-lo com prazer

    • Parece piada, mas acho que recusar é, de fato, uma parte central do trabalho. Não é simplesmente “não, vá embora”, e sim dar um passo atrás, exigir a visão geral e verificar se a organização como um todo precisa daquele projeto no longo prazo e consegue sustentá-lo; isso é quase o procedimento mínimo antes de começar
      Acho que LLMs também poderiam fazer isso bem, talvez melhor que nós, mas teriam de ser treinados especificamente para isso. Só não consigo imaginar de onde viriam esses dados de treinamento
    • A versão Principal é parecida, mas também diz que a única abordagem aceitável é o jeito que se fazia na empresa anterior

  • Então isso explica por que sempre senti que o Opus 4.8 está muito à frente do GPT 5.5. Ele é realmente bom em receber requisitos incompletos e preencher as lacunas de uma forma razoável para o projeto

    • Para começo de conversa, não sei por que dar requisitos incompletos. Os dois modelos são bons em questionar premissas e edge cases e fazer perguntas de esclarecimento, mas parece que só fazem isso quando é pedido explicitamente. Por exemplo, quando você pede usando uma técnica como “brainstorming”
      Acho que nenhum dos dois métodos de avaliação incentiva o modelo o suficiente a duvidar de todas as premissas e fazer perguntas. Talvez porque isso possa irritar o usuário, mas considero essa etapa quase obrigatória
      Toda a linha GPT-5 foi muito minuciosa, o que foi útil para revisão de código e matemática. Isso é importante para o meu trabalho, mas parece atrapalhar código “estético”. Por exemplo, tenta se defender até contra edge cases muito improváveis
      Também parece haver um trade-off entre flexibilidade e seguir instruções. Na minha experiência, o Opus às vezes ignora instruções, mas preenche melhor as lacunas; o GPT-5.5 segue melhor as instruções, mas por isso parece mais rígido
    • O melhor benchmark é o benchmark que você mesmo cria
      Na minha experiência, o Opus não estava disparado na frente nem era claramente melhor. De qualquer forma, o GPT 5.5 tem Instant, Medium, High, Extra High e Pro; a tabela parece compará-lo com o Extra High, então não deveria ser comparado com o Pro?
    • Não sei se vivo em uma bolha estranha, mas, para mim, o GPT 5.5 é muito melhor que o Opus 4.8. Chego a ficar curioso sobre como vocês avaliam e que tipo de trabalho fazem
      Existem tarefas específicas em que o Opus é melhor, como desenvolvimento frontend e design, mas, fora isso, o 5.5 simplesmente domina
    • Pode ser melhor para vibe coders que sempre especificam menos. Mas a questão é a partir de que ponto o modelo decide que “os requisitos estão pouco especificados” e acaba implementando além de uma especificação que, na verdade, já era suficiente
    • Também observei isso. O Opus 4.8 era muito mais maduro e fazia perguntas ou até discordava quando um pedido parecia problemático. Já o GPT 5.5 concordava de bom grado e fazia o que era pedido, mas muitas vezes eu precisava mandar refazer algumas vezes
      O 4.8 também precisa de mais de um prompt às vezes, mas a qualidade da saída é muito maior e traz mais insights
      Dito isso, o Fable 5 é outra coisa

  • A melhor taxa de resolução atual é 24% com o Opus 4.8; que pontuação um humano competente deveria conseguir?

    • Imagino que acima disso, já que um humano também pode usar o melhor modelo disponível
      Por outro lado, fico curioso se o modelo pontuaria ainda mais se pudesse comandar humanos à vontade
    • Supondo que todos esses problemas já tenham sido resolvidos, eu diria 100%. Claro que não foi a mesma pessoa que resolveu todos, mas, enquanto o modelo precisa se sair bem em várias codebases, um humano pode se especializar e aprender um único produto
      Acho justo comparar com uma pessoa acostumada a trabalhar no produto
      Estou mais curioso para ver como o Fable vai se sair

  • O valor de uma função sênior está em aplicar soluções e estratégias conhecidas a problemas novos. Não sei se um benchmark que nunca muda pode continuar sendo um desafio novo por muito tempo
    Um benchmark decente deveria usar todo o TRIZ para primeiro criar um enorme conjunto de problemas e então ver se a IA infere a solução ideal

  • É bom ver um novo benchmark público vindo da Snorkel. Eles fazem um trabalho bastante sofisticado por lá

  • É interessante que o Sonnet 5 chegue bem perto do Opus 4.8

  • Se esse método funcionar, isso não significa que entrevistas técnicas também poderiam ser automatizadas?

  • A abordagem de fazer o LLM emitir julgamentos subjetivos com algo como “You are a senior SWE-Bench reviewer, make no mistakes.” parece fundamentalmente falha
    Não sei qual seria uma abordagem melhor mantendo a viabilidade

    • Mais importante: isso pode atrapalhar o trabalho de verdade. Quando o LLM comete um erro, pode ser induzido a minimizá-lo e seguir em frente, em vez de reconhecer e corrigir
    • Na prática, esse método injeta contexto sobre como o LLM deve se comportar. “senior reviewer” é o estilo de resposta desejado, e “SWE-Bench” é o contexto e o domínio em que o LLM vai operar
      É uma técnica comum em prompts de sistema e ajuda a enquadrar a resposta
      Por exemplo, “um pirata escrevendo uma canção de marinheiro sobre programação”, “um jornalista escrevendo uma matéria de física” e “um engenheiro de software sênior que conhece PostgreSQL perfeitamente” gerariam respostas diferentes
      No primeiro caso, poderia sair algo no estilo Wellerman como “There once was a program that was set to C ...”
      Mas a parte “make no mistakes” me parece suspeita. Seria interessante comparar os resultados com e sem essa frase e também testar outras formas de obter o mesmo comportamento desejado
    • A repreensão “make no mistakes” parece bem ridícula. Já foi bastante ridicularizada no YouTube, mas é fácil imaginar um modo pelo qual poderia funcionar. Por exemplo, poderia ser interpretada simplesmente como “revise o trabalho”
      Claro, não parece haver nenhum lugar que faça esse tipo de medição comparativa publicamente para chegar a uma conclusão razoável