Costo in SWE-bench: come calcolare il prezzo per issue risolta senza nascondere fallimenti, tentativi ripetuti o valutazione

La cifra ingannevole: il prezzo per issue risolta non si spiega da solo

Esprimere il risultato di un agente come «costo per issue risolta» sembra trasformare una valutazione tecnica in una semplice decisione economica. Tuttavia, questa cifra è un rapporto tra variabili che possono essere state definite in modi molto diversi. Il numeratore può includere soltanto i token di una chiamata finale, oppure tutte le chiamate avviate nel corso di una traiettoria. Il denominatore può essere il numero di patch che superano il verificatore, il numero di issue inizialmente selezionate oppure un risultato scelto tra più tentativi. Senza queste definizioni, due cifre uguali non descrivono necessariamente operazioni comparabili.

La distinzione è particolarmente importante in SWE-bench. Il compito parte da issue reali associate a repository e richiede di produrre una modifica verificabile in un ambiente predisposto a tale scopo. Il costo osservabile, quindi, non si limita alla stesura di una patch. Un sistema può ispezionare file, richiedere contesto aggiuntivo, eseguire strumenti, riavviare una strategia oppure esaurire un limite senza generare una soluzione valida. Tutti questi eventi possono consumare risorse anche se l'istanza non viene conteggiata come risolta.

La domanda economica corretta dipende dalla decisione. Per preventivare un'esecuzione completa interessa il costo medio per issue tentata. Per valutare il rendimento di un flusso che consegna soltanto modifiche verificate può interessare il costo totale diviso per i successi stretti. Per decidere se una configurazione più costosa vale la pena, il confronto rilevante è spesso il costo aggiuntivo per successo aggiuntivo rispetto a una baseline. Se inoltre sono autorizzate più traiettorie e se ne conserva una, occorre misurare il costo della politica completa, non soltanto quello della traiettoria selezionata.

Questo non significa che una metrica sintetica sia inutile. Significa che va letta come la copertina di una scheda dei costi. La scheda deve indicare la versione del dataset, il sottoinsieme effettivamente eseguito, le esclusioni, il numero di tentativi, la regola di selezione, il protocollo di arresto, le categorie di consumo e quale parte dell'infrastruttura di valutazione è stata inclusa. In assenza di questi elementi, la cifra può essere un'osservazione interna valida, ma non una base sufficiente per confrontare agenti o stimare un'automazione.

Che cosa si paga durante un'esecuzione

La prima componente è l'inferenza. In un'API, il registro dei consumi deve distinguere i token di input e di output quando il fornitore li fattura in modo diverso. Se la piattaforma riporta input in cache o token di ragionamento fatturabili, anche queste categorie devono apparire separatamente. La documentazione di OpenAI, applicabile soltanto ai sistemi che usano tale API, distingue queste categorie e segnala che richiedere più completamenti comporta consumo di token aggiuntivi. Questa terminologia, né la relativa struttura tariffaria, non deve essere estesa automaticamente ad altri fornitori.

La seconda componente comprende le chiamate ausiliarie e gli strumenti. Un agente può effettuare ricerche, riassumere file, generare test, rivedere diff oppure richiedere nuovi completamenti dopo aver eseguito comandi. Alcuni strumenti non hanno un prezzo API diretto, ma aumentano il contesto delle chiamate successive o utilizzano capacità di calcolo propria. Se uno strumento esterno addebita un costo per utilizzo, deve comparire come voce indipendente. Se non gli viene attribuito un costo monetario, occorre almeno registrare il numero di invocazioni e le risorse che consuma, affinché un'altra organizzazione possa valutarle con le proprie tariffe.

La terza componente è la valutazione. L'harness di SWE-bench prepara immagini Docker, applica patch ed esegue test con limiti di tempo per istanza. La relativa documentazione contempla inoltre requisiti di CPU, memoria, archiviazione e meccanismi di cache. Costruire o recuperare immagini, eseguire container e conservare artefatti può rappresentare un costo materiale, soprattutto nelle campagne estese, pur non essendo costo di inferenza. Mescolare tali voci senza dettaglio impedisce di capire se un miglioramento derivi dall'agente o dall'infrastruttura; ometterle da un budget operativo può sottostimare la spesa reale.

Conviene inoltre separare il costo ammortizzato da quello marginale. Preparare un'immagine condivisa per molte istanze non costa uguale per esecuzione rispetto a ricostruirla da zero. Allo stesso modo, una cache dei risultati può evitare lavoro successivo. Queste efficienze sono legittime se documentate, ma non devono essere presentate come se ogni issue avesse richiesto la stessa spesa marginale. Una scheda robusta presenta entrambi i livelli: il costo della campagna osservata e le regole usate per attribuire i costi condivisi.

Quattro denominatori per quattro domande diverse

La prima metrica è il costo medio per issue tentata: il costo totale della campagna diviso per tutte le issue per le quali è stato avviato il protocollo. È la misura più adatta per stimare la spesa necessaria a elaborare una coda di lavoro simile, perché include successi, fallimenti, traiettorie non valide e casi esauriti dai limiti. Deve essere chiaro se un'issue esclusa prima di avviare l'agente faccia parte dell'universo oppure no. Un'esclusione successiva all'esecuzione non dovrebbe cancellarne il costo.

La seconda metrica è il costo per successo stretto: il costo totale delle traiettorie incluse nella politica diviso per il numero di issue la cui patch supera il processo di verifica definito. Descrive quale spesa sia stata necessaria, in media, per ottenere un risultato validato sotto quel protocollo. Può crescere anche quando il costo per tentativo diminuisce, se cala il tasso di risoluzione; per questo non va pubblicato senza entrambe le quantità di base.

La terza è il costo incrementale dell'aumento della risoluzione. Se una configurazione B risolve più issue di una configurazione A, si calcola come la differenza di costo totale tra B e A divisa per la differenza di successi. Questo rapporto risponde a una decisione marginale: quanto costa ottenere ciascun successo aggiuntivo con una configurazione più ambiziosa. È interpretabile soltanto se entrambi i sistemi vengono eseguiti sullo stesso insieme, con criteri di successo e risorse di valutazione equivalenti.

La quarta riguarda le politiche con più tentativi per issue. Se sono consentiti pass@k, retry o selezione successiva, il costo deve sommare le traiettorie generate per ciascuna issue, comprese quelle non scelte. Riportare il costo della migliore traiettoria trovata equivale a riportare un risultato condizionale che non riproduce la spesa per trovarla. La pubblicazione deve chiarire se sia stata eseguita una sola traiettoria per istanza, più traiettorie indipendenti oppure un albero decisionale adattivo.

Il protocollo modifica la fattura e il significato del risultato

Un limite di passi, tempo, chiamate o budget monetario fa parte dell'intervento valutato. Aumentarlo può consentire a certe issue difficili di ricevere più esplorazione, ma può anche concentrare una quota importante della spesa in una lunga coda di casi irrisolti. Per questo, oltre alla media, è opportuno pubblicare mediana, percentili e distribuzione per istanza. Una media bassa può convivere con pochi casi eccezionalmente costosi che sarebbero inaccettabili in produzione.

La politica di arresto deve essere esplicita. Un'esecuzione può fermarsi quando ottiene una patch, quando non trova file rilevanti, quando supera un budget, dopo il fallimento dei test o al raggiungimento di un numero di iterazioni. Ogni opzione modifica sia il costo sia la probabilità di successo. I retry richiedono la stessa precisione: occorre indicare che cosa li attiva, se ereditano il contesto, se riutilizzano la cache e se vengono contabilizzati i tentativi scartati. Chiamare «un tentativo» una sequenza di riavvii interni può nascondere una differenza materiale di consumo.

Pass@1 e pass@k rispondono a domande diverse. Pass@1 approssima il rendimento di una singola opportunità in una configurazione fissa. Pass@k descrive la possibilità che almeno una di più opportunità produca un successo, ma non equivale al costo di una sola opportunità. Quando esiste una selezione successiva, devono essere documentati il segnale utilizzato per selezionare, l'eventuale consumo aggiuntivo di modello o calcolo e l'accesso ai risultati dei test. Una selezione informata dal verificatore può essere utile nella ricerca, ma non va confusa con una politica disponibile prima della verifica.

Il confronto più informativo tende a fissare vincoli comuni: stesso insieme di istanze, stesso harness, stessi limiti di valutazione e, quando l'obiettivo è economico, un budget massimo comparabile per issue. Si possono poi mostrare curve di costo rispetto alla risoluzione. Questa presentazione fa emergere se il guadagno di risoluzione compaia a un costo graduale oppure dipenda da una minoranza di traiettorie molto costose. Evita anche di attribuire alla qualità dell'agente ciò che potrebbe dipendere dal fatto di avergli consentito di spendere di più.

Inferenza e valutazione: separarle non significa ignorarne nessuna

Separare inferenza e valutazione permette di rispondere a due domande che una singola cifra confonde. La prima è quanto costa all'agente proporre una modifica. La seconda è quanto costa stabilire se tale modifica supera il protocollo del benchmark. In SWE-bench, la valutazione richiede di applicare la previsione ed eseguire test in un ambiente di repository. L'harness documenta preparazione delle immagini, esecuzione con container, limiti temporali e opzioni di cache; trattare dunque la verifica come un'operazione gratuita sarebbe metodologicamente incompleto.

La separazione non obbliga a scegliere una sola convenzione. Per la ricerca sui modelli può essere ragionevole riportare prima il costo di inferenza e, accanto a esso, il costo di valutazione della campagna. Per pianificare un servizio di riparazione automatizzata è più pertinente il costo totale di proprietà: inferenza, orchestrazione, strumenti, calcolo dei test, archiviazione e revisione umana quando fa parte del flusso. Il punto essenziale è non sommare alcune voci per un agente e ometterle per un altro.

Esiste un'incertezza pratica: i costi dell'infrastruttura dipendono dalla regione, dal fornitore, dalla capacità riservata, dalla concorrenza e dalla politica di conservazione. Le fonti disponibili descrivono componenti dell'harness, ma non stabiliscono una tariffa universale per eseguirli. Per questo una pubblicazione rigorosa deve fornire unità fisiche, come il tempo di container e le risorse assegnate, oltre a qualsiasi conversione monetaria locale. In questo modo, un'altra organizzazione può ricalcolare l'importo secondo i propri contratti.

Gli artefatti sperimentali sono essenziali per questa separazione. Il repository degli esperimenti di SWE-bench contempla previsioni, registri di esecuzione, tracce e risultati per istanza. Condividere o riassumere questi artefatti con una struttura coerente consente di verificare quali patch siano state valutate, individuare istanze prive di risultato e riconciliare i totali di costo con le traiettorie. La verificabilità non richiede di rivelare credenziali, prompt riservati o dati protetti; richiede però che esclusioni e aggregazioni non impediscano di esaminare la contabilità.

La scheda minima di pubblicazione e la decisione operativa

La scheda dovrebbe iniziare dall'identità dell'esperimento: variante e revisione del dataset, numero di istanze idonee, tentate ed escluse, insieme alle motivazioni delle esclusioni. Questo è rilevante perché SWE-bench offre varie varianti e la documentazione del progetto identifica SWE-bench Verified come un insieme di 500 istanze. Indicare soltanto «SWE-bench» non basta per sapere quale popolazione sia stata valutata. Devono inoltre essere conservati l'identificatore dell'harness, le immagini o la configurazione pertinente e le regole di verifica.

Devono poi comparire modello, fornitore o endpoint, regione se modifica il prezzo, data di consultazione dei prezzi e valuta. La contabilità deve mostrare i token di input, output, cache e ragionamento quando queste categorie esistono per il fornitore impiegato, oltre alle chiamate ausiliarie. Deve includere il limite per issue, la politica di arresto, i retry e il metodo di selezione. Le medie devono essere accompagnate dalla distribuzione per istanza e dai conteggi di traiettorie fallite, esaurite, non valide o non verificabili.

La scheda termina con due totali: inferenza e valutazione. Per ciascuno deve indicare quali voci incorpora, che cosa esclude e come attribuisce i costi condivisi. Se si pubblica una cifra per successo, il totale del numeratore deve riconciliarsi con le voci precedenti e il denominatore con i successi stretti osservati. Se vi sono più campioni per istanza, il costo riportato deve essere quello della generazione e della scelta tra tutti, non quello del campione vincente.

Per esplorare modelli in una fase iniziale, il costo per issue tentata e una curva di risoluzione con budget fissi sono in genere le metriche più utili. Per ottimizzare un agente, è utile aggiungere il costo incrementale per successo aggiuntivo e la distribuzione dei casi costosi. Per preventivare l'automazione, il riferimento è il costo totale di proprietà per issue in ingresso, inclusi verifica e intervento umano realmente richiesto dal processo. Nessuna di queste misure sostituisce le altre: ciascuna risponde a un rischio diverso.

La conclusione prudente è che un agente non riduce necessariamente il costo di risolvere issue solo perché ottiene un tasso di risoluzione più alto o mostra un importo basso associato ai propri successi. Può trasferire la spesa verso più traiettorie, più contesto, più calcolo per i test o una selezione successiva. Il confronto difendibile dichiara tale trasferimento. Con una scheda completa, un team può decidere se pagare per più successi, se limitare l'esposizione ai casi costosi oppure se adottare una configurazione che offra un'economia più prevedibile.

Continua a esplorare

Correzioni e trasparenza

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