Squeez: Task-Conditioned Tool-Output Pruning for Coding Agents

1. Il Problema

Gli agenti di codifica (coding agents) operano consumando flussi continui di osservazioni generate da strumenti (tool), come letture di file, output di grep, stack trace, log di build, risposte API e cronologie di version control.

• Sfida principale: Sebbene solo una piccola frazione dei token in queste osservazioni sia rilevante per il passo decisionale successivo, l'agente è spesso costretto a rileggere l'intero output.
• Conseguenza: Questo genera un collo di bottiglia nell'efficienza, aumentando i costi computazionali e il tempo di elaborazione.
• Obiettivo dello studio: Definire e risolvere un problema specifico di "pruning" (potatura) condizionato al compito: dato una query focalizzata e un singolo output di uno strumento, restituire il più piccolo blocco di evidenza testuale (verbatim) che l'agente deve ispezionare. A differenza della compressione generica o del riassunto astrattivo, l'obiettivo è preservare l'evidenza originale esatta, scartando il resto.

2. Metodologia e Dataset

Dataset di Benchmark

Gli autori hanno creato un nuovo benchmark composto da 11.477 esempi, derivati da due fonti principali:

1. Interazioni da SWE-bench: Sono stati clonati snapshot di repository e sono stati eseguiti 14 tipi di strumenti (es. read file, grep, git log, pytest, pip install). Questo ha generato 10.713 osservazioni grezze.
2. Output sintetici multi-ecosistema: Per coprire linguaggi e contesti non presenti in SWE-bench (che è prevalentemente Python), sono stati generati 2.039 output realistici per TypeScript, Go, Rust, Java, Docker, Terraform e Kubernetes. Sono stati inoltre creati 575 esempi negativi (query non supportate dall'output).

• Set di Test: Un sottoinsieme di 618 esempi è stato curato manualmente per garantire alta qualità, rimuovendo duplicati, output banali o annotazioni errate.
• Struttura: Ogni esempio è una coppia (Query, Osservazione Grezza). L'etichetta ("Gold") è un insieme di intervalli di righe contigue nell'output originale che costituiscono la risposta minima necessaria.

Modello e Addestramento

• Modello: È stato utilizzato Qwen 3.5 2B, un modello di grandi dimensioni ma compatto, scelto per il suo equilibrio tra capacità di ragionamento su codice e efficienza di deployment.
• Fine-tuning: Il modello è stato adattato tramite LoRA (Low-Rank Adaptation) per tre epoche.
• Task di Addestramento: Il modello riceve la query e l'output grezzo e deve generare il testo estratto esatto, racchiuso in tag <relevant lines>.
• Inferenza: Il modello è stato servito tramite vLLM e può essere utilizzato come filtro CLI su output in pipe, permettendo un'integrazione minima negli stack degli agenti esistenti (es. Codex, Claude Code).

Valutazione

Il modello è stato confrontato con:

• Baseline Generative Zero-shot: Qwen 3.5 35B A3B, Kimi K2 e la versione base non fine-tunata di Qwen 3.5 2B.
• Baseline Euristiche: BM25, First-N (prime N righe), Last-N (ultime N righe) e Random, configurate per mantenere circa il 10% dell'input (livello di compressione simile alle etichette).
• Metriche: Recall, F1 (con matching tollerante di substring), Precisione e Compressione (frazione di token rimossi).

3. Risultati Chiave

Il modello Squeez-2B (il modello fine-tunato) ha ottenuto prestazioni superiori rispetto a tutte le controparti:

• Recall: 0.86 (superiore di 11 punti rispetto al modello zero-shot Qwen 35B A3B che ha ottenuto 0.75).
• F1 Score: 0.80 (vs 0.73 del modello 35B).
• Compressione: Rimuove il 92% dei token di input mantenendo un'alta accuratezza.
• Confronto con Euristiche: Supera le basi euristiche (BM25, First-N, ecc.) con un margine significativo (es. Recall di 0.22 per BM25 vs 0.86 per Squeez).
• Precisione: Il modello fine-tunato è anche il più preciso, indicando che ha imparato una politica di estrazione specifica per lo strumento e non sta semplicemente seguendo istruzioni generiche.

Analisi degli Errori:

• I modelli zero-shot più grandi tendono a selezionare blocchi semanticamente adiacenti ma errati (es. un commit sbagliato ma correlato) o a non gestire bene i casi negativi (generano testo esplicativo invece di restituire vuoto).
• Squeez-2B eccelle nel restituire output vuoti quando non ci sono evidenze (80% di successo sui casi negativi vs 7% per il modello 35B) e nell'isolare blocchi di fallimento compatti in log rumorosi.

4. Contributi Principali

1. Formulazione del Task: Definizione del "Task-Conditioned Tool-Output Pruning" come compito distinto dalla risoluzione dei bug o dalla compressione generica di prompt.
2. Dataset e Benchmark: Rilascio di un dataset di 11.477 esempi che copre 27 tipi di strumenti e multi-ecosistemi, con un set di test curato manualmente.
3. Soluzione Efficiente: Dimostrazione che un modello piccolo (2B parametri) fine-tunato per un compito specifico supera modelli molto più grandi (35B+) usati in modalità zero-shot, offrendo una soluzione economicamente sostenibile per gli agenti.
4. Accessibilità: Rilascio del modello, del dataset, del codice di valutazione e di un'interfaccia CLI sotto licenza Apache 2.0.

5. Significato e Conclusioni

Il paper dimostra che gli output degli strumenti per la codifica, che sono spesso un mix eterogeneo di codice, log, metadati e output strutturati, non sono gestiti efficacemente dai modelli generativi zero-shot o dalle semplici euristiche di recupero (come BM25).

La lezione fondamentale è che un'addestramento supervisionato stretto e specifico per il compito su un modello compatto è la via migliore per l'efficienza degli agenti. Squeez permette di inserire un filtro intelligente prima del passo di ragionamento dell'agente, riducendo drasticamente il contesto senza perdere le informazioni critiche, rendendo gli agenti di codifica più scalabili ed economici.