DeepSWE v1.1: o que mede um patch que supera o seu verificador e quando o seu pass@1 deixa de demonstrar que o agente resolveu a tarefa

O número não pertence apenas ao modelo

Uma pontuação do DeepSWE v1.1 não descreve uma propriedade isolada de um modelo de linguagem. Descreve o resultado de uma configuração experimental completa: um modelo servido por um fornecedor, um nível de esforço de raciocínio quando essa opção existe, um arnês de agente, um conjunto de ferramentas, limites de contexto e de tempo, instruções, uma política de paragem e um sistema de avaliação. A unidade observada é o patch submetido por essa configuração perante uma tarefa concreta, e não uma resposta textual do modelo nem uma capacidade geral medida fora desse ambiente.

Esta distinção é particularmente importante ao ler o leaderboard do DeepSWE. O site oficial indica que os modelos são executados com mini-SWE-agent para procurar consistência, mas essa decisão não elimina todas as variáveis. Uma mesma família de modelos pode surgir com diferentes níveis de raciocínio ou fornecedores; além disso, uma atualização do arnês, do prompt, das ferramentas ou da infraestrutura pode alterar o resultado sem que o modelo subjacente tenha mudado. Por isso, uma comparação direta exige verificar que ambas as linhas usam condições equivalentes e a mesma versão de avaliação.

O termo pass@1 também não deve ser lido como uma garantia de que o agente resolverá o próximo incidente de um repositório próprio. No artigo metodológico do DeepSWE, pass@1 é definido como a média, por tarefa, da taxa de sucesso obtida nas execuções. É uma agregação do desempenho observado nesta coleção e com este protocolo. Serve para resumir resultados experimentais, mas não identifica por si só a causa de cada sucesso, de cada falha ou de uma diferença entre configurações.

O que o DeepSWE procura medir

O DeepSWE apresenta-se como um benchmark para agentes de engenharia de software que trabalham em tarefas originais de longo horizonte. A documentação dos autores descreve 113 tarefas distribuídas por 91 repositórios. Cada tarefa combina o contexto de um repositório com um pedido de alteração e mecanismos programáticos para verificar o comportamento esperado. A intenção não é recuperar uma correção já publicada, mas produzir uma solução nova para a tarefa proposta.

Segundo a apresentação da Datacurve, as soluções de referência foram escritas de raiz e não foram copiadas nem adaptadas de um pull request, commit ou patch público existente. Algumas tarefas podem ser motivadas por problemas ainda não resolvidos, mas essa motivação não equivale à existência de uma solução upstream utilizável como referência. Esta é uma alegação de conceção dos criadores; é relevante porque procura reduzir a sobreposição com benchmarks construídos a partir de incidentes históricos, mas não basta, por si só, para demonstrar a ausência de contaminação nos dados de treino ou em ferramentas externas.

O formato público do repositório oficial é útil para uma auditoria porque documenta componentes como metadados, prompt, Dockerfile, testes ou verificador e solução de referência. Isso permite inspecionar uma tarefa específica em vez de inferir a sua dificuldade a partir do nome do repositório. Ainda assim, a disponibilidade dos artefactos não torna automaticamente reproduzível toda a conclusão: para repetir uma linha, também são necessários o commit, as imagens ou dependências efetivamente usadas, as credenciais e versões das ferramentas, bem como os registos de execução relevantes.

O patch, o contentor limpo e o verificador

Na v1.1, a Datacurve descreve um procedimento no qual é avaliado apenas o patch submetido num contentor de verificação separado e limpo. O repositório oficial também documenta a extração do commit como patch e a sua aplicação num ambiente imaculado desde essa versão. O desenho procura separar o resultado final dos efeitos transitórios que possam ter ocorrido durante a trajetória do agente, como alterações não submetidas ou manipulações do processo de teste no seu ambiente de trabalho.

A documentação da v1.1 afirma que o relatório CTRF regista pelo nome cada teste que define a tarefa. Sob essa abordagem, eliminar testes ou forçar uma saída antecipada deveria surgir como resultados ausentes ou falhados, e não como uma aprovação. Também são apresentadas alterações para corrigir deriva de dependências e testes instáveis. São melhorias razoáveis para o objetivo de avaliar um patch transportável, mas devem ser lidas como decisões de implementação do benchmark: um sistema de pontuação incorpora sempre pressupostos sobre que ficheiros restaurar, que comandos executar e que evidência conta como resultado.

A separação entre o contentor do agente e o contentor de verificação tem uma consequência prática. Um patch pode funcionar durante uma trajetória concreta e falhar quando é reaplicado de forma limpa; nesse caso, a reprovação exprime falta de reprodutibilidade da alteração final segundo o protocolo. No sentido inverso, uma alteração que cumpre a intenção da tarefa pode reprovar se o processo de restauração, substituição de ficheiros ou deteção de resultados interferir com o comportamento que devia ser verificado. Distinguir os dois casos exige conservar artefactos suficientes para rever o veredito.

O que pass@1 e pass@4 pontuam, e o que deve ser declarado

O artigo do DeepSWE define pass@1 como a média por tarefa da taxa de sucesso e pass@4 como a fração de tarefas resolvidas em pelo menos uma de quatro tentativas. A diferença importa: pass@1 informa sobre o desempenho de uma tentativa individual sob a distribuição de execuções usada; pass@4 reflete o benefício de dispor de várias tentativas. Não são medidas permutáveis, e uma classificação por uma delas pode ordenar as configurações de modo diferente.

Os autores documentam aproximadamente quatro rollouts por tarefa e intervalos de confiança de 95%. Esses intervalos ajudam a evitar leituras excessivas de separações pequenas, sobretudo quando configurações próximas se sobrepõem. Contudo, um intervalo não corrige uma incompatibilidade metodológica. Se dois resultados provêm de verificadores, políticas de repetição, prazos de execução ou critérios de exclusão distintos, a sua incerteza estatística não resolve a alteração do objeto medido.

Uma ficha de resultado responsável deve declarar, no mínimo, a versão do DeepSWE, o modelo e fornecedor, a versão do mini-SWE-agent, o nível de raciocínio, a quantidade de rollouts, a política de paragem, os limites de tempo e contexto, a data ou versão da infraestrutura e o tratamento de erros. Deve também separar a pontuação calculada dos casos excluídos. Sem esta informação, o leitor não consegue saber se uma diferença se deve à capacidade de resolução, à disponibilidade do serviço, a decisões de orçamento ou a mudanças no avaliador.

Falhas que contam, erros excluídos e viés de seleção

A metodologia publicada pelos autores indica que os timeouts contam como falhas. Também assinala que erros do fornecedor, da rede ou do verificador podem ser excluídos. Esta distinção faz sentido operacional: uma interrupção externa ao agente não equivale necessariamente a uma incapacidade de resolver o problema. Mas a exclusão introduz uma obrigação de transparência, porque a classificação de um evento determina que denominador é usado na pontuação publicada.

Um timeout pode revelar uma limitação real do sistema que se pretende implementar, mesmo quando não revela uma limitação semântica do modelo. Por isso, uma avaliação útil deveria mostrar tanto a taxa principal sob as suas regras como o número e a natureza das execuções excluídas, além dos artefactos que justificam cada decisão. Agrupar sob “infraestrutura” um erro reproduzível na preparação da tarefa, por exemplo, impediria terceiros de avaliar se se trata de um defeito do benchmark ou de uma condição excecional do ambiente.

Convém também perguntar se uma exclusão é decidida antes de inspecionar o patch e se a regra é aplicada da mesma forma a todos os modelos. Uma política retrospetiva ou pouco documentada pode favorecer inadvertidamente uma configuração. Não há evidência apresentada aqui para afirmar que isso ocorra no DeepSWE; é uma condição de auditoria que deveria ser verificada antes de usar a pontuação para compras, seleção de fornecedores ou decisões de implementação.

Porque v1 e v1.1 não devem ser misturadas sem reexecução

A Datacurve afirma que a v1.1 mantém as mesmas tarefas, mas altera a execução e a avaliação. Entre as mudanças descritas estão a verificação do patch submetido num contentor limpo, o registo CTRF e correções relacionadas com dependências e testes instáveis. Ainda que o conjunto de enunciados se mantenha, uma modificação do ambiente de pontuação pode alterar quais patches passam e quais falham.

Isto impede tratar um número da v1 e outro da v1.1 como pontos da mesma série sem um aviso claro. Não seria válido atribuir toda a diferença a uma melhoria ou regressão do modelo se também mudou a forma de reconstruir o ambiente ou de verificar os testes. A via mais sólida para comparar versões é reexecutar a mesma configuração com cada protocolo e publicar os resultados por tarefa, juntamente com as alterações de veredito.

A mesma cautela aplica-se a comparações dentro da v1.1 se o leaderboard evoluir. Uma tabela pública é um registo valioso de execuções declaradas, e não prova suficiente de equivalência histórica. Quem necessitar de uma decisão de grande impacto deveria congelar um commit do benchmark e do arnês, conservar as imagens de contentor e executar uma matriz controlada de configurações.

O conflito sobre as modificações de testes

A revisão independente da Epoch AI levanta uma limitação específica do DeepSWE v1.1. Segundo essa revisão, os seus autores confirmaram manualmente pelo menos 23 falsos negativos entre as 113 tarefas. Explicam que 18 desses casos estão relacionados com agentes que modificam testes existentes e com uma preparação posterior do verificador que restaura ou substitui ficheiros. O resultado apontado é que um agente pode ter produzido uma alteração funcionalmente correta para a intenção da tarefa e, ainda assim, receber uma reprovação devido à interação entre o seu patch e o protocolo de avaliação.

Esta conclusão deve ser atribuída à Epoch AI e lida no âmbito que declara. A revisão indica que foi interrompida depois de ultrapassar o seu limiar para considerar o benchmark defeituoso; por isso, não fornece uma estimativa definitiva da taxa total de falsos negativos nem demonstra que todos os resultados do DeepSWE são inválidos. Também não permite inferir, apenas a partir desse número, quanto as posições do leaderboard mudariam: para isso seria necessário repetir os casos afetados sob uma versão corrigida e publicar a reatribuição de vereditos por configuração.

Existe, além disso, uma tensão real entre dois objetivos. O avaliador quer impedir que um agente consiga aprovação alterando os testes da tarefa. Mas uma regra que restaura ou substitui ficheiros deve distinguir entre uma manipulação que contorna a verificação e uma edição de testes que integra uma alteração legítima ou que interage de forma não prevista com o verificador. A documentação oficial da v1.1 sustenta que o relatório de testes deteta ausências e saídas antecipadas. A auditoria sugere que essa salvaguarda não evita todos os falsos negativos identificados. Com as fontes disponíveis, ambas as afirmações descrevem níveis diferentes: o desenho pretendido e um conjunto de comportamentos observados em revisão.

O que uma pontuação alta permite concluir

Uma pontuação alta no DeepSWE v1.1 é evidência de que uma configuração concreta conseguiu produzir patches que o protocolo aceitou numa coleção de tarefas originais de engenharia de software. Quando o resultado é acompanhado por artefactos e condições reproduzíveis, fornece um sinal útil para pré-selecionar agentes destinados a tarefas de correção e desenvolvimento autónomo com repositórios, comandos e testes.

O sinal é mais informativo do que uma avaliação limitada a fragmentos de código isolados porque inclui navegação num repositório, alterações em vários ficheiros, utilização de ferramentas e uma verificação funcional. Pode também ajudar a detetar diferenças práticas entre configurações que parecem semelhantes em benchmarks mais saturados. O valor, contudo, é condicional: depende de a população de tarefas, as restrições do arnês e o verificador se assemelharem ao caso de uso sobre o qual será tomada uma decisão.

A conclusão prudente não é que o agente “sabe manter software em produção”, mas que demonstrou capacidade medida para resolver uma fração de tarefas deste benchmark sob um protocolo definido. Esta formulação preserva informação útil e evita transferir um resultado experimental para domínios que o DeepSWE não observa diretamente.

O que não permite concluir e como ler uma linha do leaderboard

O benchmark não comprova, por si só, fiabilidade no repositório próprio, segurança das alterações, qualidade de uma revisão de desenho, compatibilidade com políticas internas ou capacidade de depurar sistemas ligados à produção. Também não mede de forma completa o custo operacional: uma pontuação comparável pode exigir um número diferente de tokens, tempo de relógio, tentativas repetidas ou supervisão humana. A autonomia empresarial exige ainda permissões, isolamento, controlo de dependências, revisão, observabilidade e procedimentos de reversão.

Uma linha também não demonstra que o agente não encontrou uma solução que explora uma lacuna do verificador, nem que toda a reprovação representa incapacidade de resolver o requisito. A revisão da Epoch AI torna esta última ressalva particularmente relevante nos casos que examinou. Por outro lado, uma auditoria parcial de falsos negativos não permite concluir que o benchmark não tem valor. A interpretação correta é que o erro de medição e o desacordo entre intenção e veredito devem fazer parte da análise de risco.

Para comparar Grok 4.6, DeepSeek V4.1 Flash ou outros sistemas no DeepSWE, um comprador técnico deveria primeiro filtrar as linhas pela mesma versão, pelo mesmo arnês e por condições de inferência equivalentes. Depois, deve rever os intervalos, os erros excluídos e os artefactos de tarefas-limite. Por fim, deveria complementar a pré-seleção com uma avaliação interna em repositórios representativos, com políticas de segurança e custos próximos da implementação prevista. O DeepSWE pode ser uma entrada nessa decisão, não o seu substituto.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.