IT
Come il contesto degli agenti di coding cambia il lavoro del server
The Physical Cost of Context: Quality-Constrained Resource Accounting for Coding Agents · arXiv:2610.34763
In parole semplici
Ogni volta che un agente di coding chiede al modello di intervenire, gli invia informazioni sul progetto software. Un messaggio più corto può comunque richiedere più lavoro se le modifiche ai messaggi precedenti impediscono al server di riutilizzare informazioni già elaborate.
Il paper presenta un metodo che controlla la qualità delle attività e conta sia le chiamate al modello sia l'input che il server deve elaborare di nuovo. In prove separate di localizzazione del codice, fornire in anticipo frammenti recuperati ha superato il controllo di qualità e ha richiesto meno chiamate e meno energia GPU misurata rispetto alla ricerca basata solo sulla descrizione del problema.
La ricerca
Quando gli agenti di coding inviano ripetutamente il contesto di un progetto, ridurre i prompt abbassa davvero il lavoro svolto dal server? La risposta può dipendere dalla possibilità di riutilizzare l'input precedente e dal fatto che una politica cambi il numero di richieste fatte dall'agente.
Gli autori introducono un metodo con vincolo di qualità che distingue la dimensione del prompt dal lavoro del server, poi misurano come recupero, modifiche alla cronologia e cache cambino quel lavoro.
Gli autori confrontano Grep, che avvia la localizzazione partendo dal problema, con Eager, che fornisce dieci frammenti di codice recuperati prima del primo turno; entrambi mantengono l'intera cronologia.
Su 450 problemi Python, il Recall@5 di Eager è stato 0,478 contro 0,470 per Grep, e la differenza di qualità appaiata ha superato il criterio di non inferiorità con soglia di cinque punti.
In un gruppo distinto di attività per misurare le risorse, con cache disattivata, Eager ha usato meno chiamate e meno proxy del consumo energetico della GPU per attività tentata.
Nel complesso, questi risultati sostengono che in questa configurazione fornire in anticipo le prove riduca il lavoro misurato; il metodo di contabilità mostra anche perché il totale dei token del prompt, da solo, non dimostra un risparmio.
I risultati sulla qualità della localizzazione e quelli dettagliati sulle risorse provengono da gruppi distinti di attività; lo studio sulle patch ha usato un limite fisso di 32 chiamate. Le prove hanno riguardato quattro politiche fissate su un solo dispositivo, con una richiesta alla volta.
Non stabiliscono quali sarebbero i risultati con il batching, su GPU cloud o con altre politiche. Il proxy energetico della GPU non include CPU, memoria host o l'energia dell'intero sistema.
Cosa mostrano le prove
- Chiedersi quale lavoro si riduce
Il paper introduce un protocollo di contabilità delle risorse con un vincolo di qualità per confrontare le politiche di gestione del contesto degli agenti di coding. La domanda è se prompt più brevi significhino davvero meno lavoro quando gli agenti fanno richieste ripetute e i server possono riutilizzare l'input precedente.
Il protocollo controlla prima la qualità, poi misura le chiamate al modello, l'elaborazione di input non riutilizzato, l'occupazione della cache, il tempo e un proxy del consumo energetico della GPU.
- Verificare il criterio di qualità
Nella localizzazione, Grep parte solo dalla descrizione del problema, mentre Eager fornisce dieci frammenti di codice recuperati prima del primo turno dell'agente; entrambi mantengono l'intera cronologia. Il successo significa che la funzione o la classe cercata appare in uno dei cinque blocchi di codice restituiti.
Su 450 problemi Python provenienti da repository distinti, il punteggio di Eager è stato 0,478 contro 0,470 per Grep. La differenza di qualità appaiata ha superato il criterio di non inferiorità degli autori, con una soglia di cinque punti.
- Misurare i costi della localizzazione
Gli autori hanno misurato le risorse su un gruppo separato di 100 attività di localizzazione, con il prefix caching disattivato e contando anche le attività fallite. In quel gruppo, Eager ha richiesto meno chiamate riuscite al server e meno proxy del consumo energetico della GPU per attività tentata rispetto a Grep.
Questo sostiene l'interpretazione che, in questo confronto, fornire prove in anticipo abbia ridotto il lavoro evitando alcune chiamate di ricerca; le misure di qualità e costo non provengono però dalle stesse attività.
- Confrontare cache e modifiche alla cronologia
Altri due confronti mostrano perché la lunghezza del prompt non basta per stimare il lavoro. Mantenendo Eager invariato, attivare il prefix caching ha lasciato il volume logico dei prompt statisticamente simile, ma ha ridotto nettamente il prefill non memorizzato in cache.
In una diversa configurazione di generazione delle patch, Mask-5 ha accorciato i prompt ma non ha superato il criterio di qualità e ha aumentato nettamente il prefill non memorizzato e l'energia GPU misurata. I risultati mostrano che il riutilizzo e il comportamento dell'agente possono cambiare il rapporto tra dimensione del prompt e lavoro effettivo.
Dettagli
- Autori del paper originale
- Zhongming Yu, Yitong Ma, Hengjia Yu, Boqin Yuan, Xiangye Lin
- Inviato ad arXiv
- Licenza
- arXiv non-exclusive