DeepSWE v1.1: cosa misura una patch che supera il suo verificatore e quando il suo pass@1 smette di dimostrare che l’agente ha risolto il compito

Il numero non appartiene soltanto al modello

Un punteggio di DeepSWE v1.1 non descrive una proprietà isolata di un modello linguistico. Descrive il risultato di una configurazione sperimentale completa: un modello erogato da un fornitore, un livello di sforzo di ragionamento quando questa opzione esiste, un’imbracatura per agenti, un insieme di strumenti, limiti di contesto e tempo, istruzioni, una politica di arresto e un sistema di valutazione. L’unità osservata è la patch sottoposta a commit da quella configurazione davanti a un compito concreto, non una risposta testuale del modello né una capacità generale misurata fuori da quell’ambiente.

La distinzione è particolarmente importante quando si legge la leaderboard di DeepSWE. Il sito ufficiale indica che i modelli vengono eseguiti con mini-SWE-agent per cercare coerenza, ma questa scelta non elimina tutte le variabili. Una stessa famiglia di modelli può apparire con diversi livelli di ragionamento o fornitori; inoltre, un aggiornamento dell’imbracatura, del prompt, degli strumenti o dell’infrastruttura può modificare il risultato senza che sia cambiato il modello sottostante. Un confronto diretto richiede quindi di verificare che le due righe usino condizioni equivalenti e la stessa versione della valutazione.

Nemmeno il termine pass@1 va letto come una garanzia che l’agente risolverà il prossimo ticket di un repository aziendale. Nel paper metodologico di DeepSWE, pass@1 è definito come la media, per compito, del tasso di successo ottenuto nelle esecuzioni. È un’aggregazione della prestazione osservata in questa raccolta e con questo protocollo. Riassume risultati sperimentali, ma non identifica da solo la causa di ogni successo, di ogni fallimento o di ogni differenza fra configurazioni.

Cosa tenta di misurare DeepSWE

DeepSWE si presenta come un benchmark per agenti di ingegneria del software che lavorano su compiti originali e di lunga durata. La documentazione degli autori descrive 113 compiti distribuiti su 91 repository. Ogni compito combina un contesto di repository con una richiesta di modifica e meccanismi programmatici per verificare il comportamento atteso. L’obiettivo non è recuperare una correzione già pubblicata, bensì produrre una nuova soluzione per il compito proposto.

Secondo la presentazione di Datacurve, le soluzioni di riferimento sono state scritte da zero e non copiate né adattate da una pull request, un commit o una patch pubblica esistente. Alcuni compiti possono essere motivati da problemi irrisolti, ma questa motivazione non equivale all’esistenza di una soluzione upstream utilizzabile come riferimento. Si tratta di un’affermazione di progettazione dei creatori: è rilevante perché tenta di ridurre la sovrapposizione con benchmark costruiti su issue storiche, ma non basta da sola a dimostrare l’assenza di contaminazione nei dati di addestramento o negli strumenti esterni.

Il formato pubblico del repository ufficiale è utile per un audit perché documenta componenti quali metadati, prompt, Dockerfile, test o verificatore e soluzione di riferimento. Questo consente di ispezionare un compito specifico invece di dedurne la difficoltà dal nome del repository. La disponibilità degli artefatti, tuttavia, non rende automaticamente riproducibile ogni conclusione: per ripetere una riga servono anche il commit, le immagini o dipendenze effettivamente usate, le credenziali e versioni degli strumenti, nonché i log di esecuzione pertinenti.

La patch, il contenitore pulito e il verificatore

In v1.1, Datacurve descrive una procedura nella quale viene valutata soltanto la patch sottoposta a commit in un contenitore di verifica separato e pulito. Il repository ufficiale documenta inoltre l’estrazione del commit come patch e la sua applicazione in un ambiente vergine a partire da questa versione. Il disegno cerca di separare il risultato finale dagli effetti transitori verificatisi nella traiettoria dell’agente, quali modifiche non sottoposte a commit o manipolazioni del processo di test nell’ambiente di lavoro.

La documentazione di v1.1 sostiene che il report CTRF registra per nome ogni test che definisce il compito. In questa impostazione, eliminare test o forzare un’uscita anticipata dovrebbe comparire come risultato assente o fallito, non come superamento. Sono inoltre presentate modifiche per correggere deriva delle dipendenze e test instabili. Sono miglioramenti ragionevoli rispetto all’obiettivo di valutare una patch trasportabile, ma vanno letti come decisioni di implementazione del benchmark: un sistema di scoring incorpora sempre ipotesi su quali file ripristinare, quali comandi eseguire e quali evidenze contino come risultato.

La separazione fra contenitore dell’agente e contenitore di verifica ha una conseguenza pratica. Una patch può funzionare durante una traiettoria concreta e fallire quando viene riapplicata in modo pulito; in tal caso, il fallimento esprime una mancanza di riproducibilità della modifica finale secondo il protocollo. Viceversa, una modifica che soddisfa l’intento del compito può fallire se il ripristino, la sostituzione di file o il rilevamento dei risultati interferiscono con il comportamento da verificare. Distinguere i due casi richiede la conservazione di artefatti sufficienti per riesaminare il verdetto.

Cosa misurano pass@1 e pass@4, e cosa occorre dichiarare

Il paper di DeepSWE definisce pass@1 come la media per compito del tasso di successo, e pass@4 come la frazione di compiti risolti in almeno uno di quattro tentativi. La differenza conta: pass@1 informa sulla resa di un singolo tentativo sotto la distribuzione di esecuzioni usata; pass@4 riflette il vantaggio di disporre di più tentativi. Non sono metriche intercambiabili e una classifica basata sull’una può ordinare le configurazioni in modo diverso dall’altra.

Gli autori documentano approssimativamente quattro rollout per compito e intervalli di confidenza al 95%. Tali intervalli aiutano a evitare un’interpretazione eccessiva di separazioni piccole, soprattutto quando configurazioni vicine si sovrappongono. Un intervallo, però, non corregge un’incompatibilità metodologica. Se due risultati derivano da verificatori, politiche di ritentativo, tempi di esecuzione o criteri di esclusione differenti, l’incertezza statistica non risolve il cambiamento dell’oggetto misurato.

Una scheda di risultato responsabile dovrebbe dichiarare almeno la versione di DeepSWE, il modello e il fornitore, la versione di mini-SWE-agent, il livello di ragionamento, il numero di rollout, la politica di arresto, i limiti di tempo e contesto, la data o versione dell’infrastruttura e il trattamento degli errori. Dovrebbe inoltre separare il punteggio calcolato dai casi esclusi. Senza queste informazioni, il lettore non può sapere se una differenza dipenda dalla capacità risolutiva, dalla disponibilità del servizio, da decisioni di budget o da cambiamenti del valutatore.

Fallimenti conteggiati, errori esclusi e bias di selezione

La metodologia pubblicata dagli autori indica che i timeout contano come fallimenti. Indica anche che possono essere esclusi errori del fornitore, di rete o del verificatore. La distinzione ha senso operativo: un’interruzione esterna all’agente non equivale necessariamente a un’incapacità di risolvere il problema. L’esclusione crea tuttavia un obbligo di trasparenza, perché la classificazione di un evento determina quale denominatore viene usato nel punteggio pubblicato.

Un timeout può rivelare un limite reale del sistema che si intende distribuire, anche quando non rivela un limite semantico del modello. Una valutazione utile dovrebbe dunque mostrare sia il tasso principale secondo le proprie regole sia il numero e la natura delle esecuzioni escluse, oltre agli artefatti che motivano ogni decisione. Raggruppare sotto la voce “infrastruttura” un errore riproducibile nella preparazione del compito, per esempio, impedirebbe a terzi di valutare se si tratti di un difetto del benchmark o di una condizione eccezionale dell’ambiente.

Occorre inoltre chiedere se un’esclusione venga decisa prima di ispezionare la patch e se la regola venga applicata allo stesso modo a tutti i modelli. Una politica retrospettiva o poco documentata può favorire involontariamente una configurazione. Le fonti qui disponibili non forniscono evidenza per affermare che ciò accada in DeepSWE; è una condizione di audit da verificare prima di usare il punteggio per acquisti, selezione di fornitori o decisioni di distribuzione.

Perché v1 e v1.1 non vanno mescolate senza riesecuzione

Datacurve afferma che v1.1 conserva gli stessi compiti, ma modifica esecuzione e valutazione. Fra i cambiamenti descritti figurano la verifica della patch sottoposta a commit in un contenitore pulito, il report CTRF e correzioni relative a dipendenze e test instabili. Anche se l’insieme degli enunciati resta invariato, una modifica dell’ambiente di scoring può cambiare quali patch passano e quali falliscono.

Questo impedisce di trattare una cifra di v1 e una di v1.1 come punti della stessa serie senza un’avvertenza chiara. Non sarebbe valido attribuire ogni differenza a un miglioramento o a una regressione del modello se è cambiato anche il modo di ricostruire l’ambiente o di controllare i test. Il modo più solido per confrontare le versioni consiste nel rieseguire la stessa configurazione con ogni protocollo e pubblicare i risultati per compito, insieme ai cambiamenti di verdetto.

La stessa cautela vale per confronti interni a v1.1 se la leaderboard evolve. Una tabella pubblica è una registrazione preziosa di esecuzioni dichiarate, non una prova sufficiente di equivalenza storica. Chi deve prendere una decisione ad alto impatto dovrebbe congelare un commit del benchmark e dell’imbracatura, conservare le immagini dei contenitori ed eseguire una matrice controllata di configurazioni.

Il conflitto sulle modifiche ai test

La revisione indipendente di Epoch AI solleva una limitazione specifica di DeepSWE v1.1. Secondo tale revisione, i suoi autori hanno confermato manualmente almeno 23 falsi negativi tra i 113 compiti. Spiegano che 18 di questi casi sono collegati ad agenti che modificano test esistenti e a una successiva preparazione del verificatore che ripristina o sostituisce file. Il risultato segnalato è che un agente può avere prodotto una modifica funzionalmente corretta rispetto all’intento del compito e ricevere comunque un fallimento a causa dell’interazione fra la sua patch e il protocollo di valutazione.

Questo risultato va attribuito a Epoch AI e letto nella portata dichiarata. La revisione indica di essersi fermata dopo aver superato la propria soglia per ritenere il benchmark difettoso; pertanto, non offre una stima definitiva del tasso totale di falsi negativi né dimostra che ogni risultato di DeepSWE sia invalido. Non consente neppure di inferire, soltanto da quel numero, quanto cambierebbero le posizioni della leaderboard: per farlo, bisognerebbe ripetere i casi coinvolti con una versione corretta e pubblicare la riassegnazione dei verdetti per configurazione.

Esiste inoltre una tensione effettiva fra due obiettivi. Il valutatore vuole impedire che un agente ottenga un superamento alterando i test del compito. Ma una regola che ripristina o sostituisce file deve distinguere tra una manipolazione che aggira il controllo e una modifica ai test che fa parte di un cambiamento legittimo o interagisce in modo imprevisto con il verificatore. La documentazione ufficiale di v1.1 sostiene che il report dei test rilevi assenze e uscite premature. L’audit suggerisce che questa salvaguardia non eviti tutti i falsi negativi individuati. Con le fonti disponibili, le due affermazioni descrivono livelli diversi: il disegno previsto e un insieme di comportamenti osservati durante la revisione.

Cosa permette di concludere un punteggio elevato

Un punteggio elevato in DeepSWE v1.1 è evidenza del fatto che una configurazione concreta è riuscita a produrre patch accettate dal protocollo in una raccolta di compiti originali di ingegneria del software. Quando il risultato è accompagnato da artefatti e condizioni riproducibili, offre un segnale utile per preselezionare agenti destinati a compiti di correzione e sviluppo autonomo con repository, comandi e test.

Il segnale è più informativo di una valutazione limitata a frammenti di codice isolati perché include navigazione in un repository, modifiche a più file, uso di strumenti e verifica funzionale. Può anche aiutare a rilevare differenze pratiche fra configurazioni che sembrano simili in benchmark più saturi. Il valore resta tuttavia condizionale: dipende dal fatto che la popolazione dei compiti, i vincoli dell’imbracatura e il verificatore assomiglino al caso d’uso sul quale si deve decidere.

La conclusione prudente non è che l’agente “sa mantenere software in produzione”, ma che ha dimostrato una capacità misurata di risolvere una frazione dei compiti di questo benchmark con un protocollo definito. Questa formulazione conserva informazione utile ed evita di trasferire un risultato sperimentale in ambiti che DeepSWE non osserva direttamente.

Cosa non permette di concludere e come leggere una riga della leaderboard

Il benchmark non dimostra da solo affidabilità nel repository aziendale, sicurezza delle modifiche, qualità di una revisione di progettazione, compatibilità con politiche interne o capacità di eseguire debug di sistemi connessi alla produzione. Non misura neppure in modo completo il costo operativo: un punteggio comparabile può richiedere quantità diverse di token, tempo reale, ritentativi o supervisione umana. L’autonomia aziendale richiede inoltre permessi, isolamento, controllo delle dipendenze, revisione, osservabilità e procedure di rollback.

Una riga non dimostra neanche che l’agente non abbia trovato una soluzione che sfrutta una lacuna del verificatore, né che ogni fallimento rappresenti l’incapacità di risolvere il requisito. La revisione di Epoch AI rende questa seconda riserva particolarmente rilevante nei casi esaminati. D’altra parte, un audit parziale di falsi negativi non consente di concludere che il benchmark sia privo di valore. L’interpretazione corretta è che l’errore di misurazione e il disaccordo tra intento e verdetto debbano entrare nell’analisi del rischio.

Per confrontare Grok 4.6, DeepSeek V4.1 Flash o altri sistemi in DeepSWE, un acquirente tecnico dovrebbe prima filtrare le righe per stessa versione, stessa imbracatura e condizioni di inferenza equivalenti. Poi dovrebbe esaminare gli intervalli, gli errori esclusi e gli artefatti dei compiti al limite. Infine, dovrebbe integrare la preselezione con una valutazione interna su repository rappresentativi, con politiche di sicurezza e costi vicini alla distribuzione prevista. DeepSWE può essere un input della decisione, non il suo sostituto.

Continua a esplorare

Correzioni e trasparenza

Se trovi un dato errato o non aggiornato, inviaci la pagina e la fonte da verificare.