🤖 AI

The Hidden Footprint: Making Storage a First-Class Metric for LLM Agent Evaluation

Questo articolo introduce AgentFootprint, un benchmark che rivela come l'impronta di memoria persistente degli agenti LLM vari drasticamente tra i diversi framework e configurazioni indipendentemente dall'accuratezza del compito, dimostrando al contempo che lo storage basato su indirizzi di contenuto può ridurre significativamente tale overhead senza compromettere la ricostruibilità dei dati.

Autori originali: Chenglin Yu, Hongquan Gui, Ying Yu, Hongxia Yang, Ming Li

Pubblicato 2026-07-14

📖 6 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Chenglin Yu, Hongquan Gui, Ying Yu, Hongxia Yang, Ming Li

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immagina di guardare un brillante detective robot risolvere un mistero. Legge indizi, pone domande e scrive la sua risposta finale. Tutti esultano quando il detective trova la risposta corretta, e controllano quanto è stato veloce nel pensare e quanto è costato farlo girare. Ma nessuno sta guardando il disordine che il detective lascia dietro di sé sul pavimento.

Questo articolo, chiamato The Hidden Footprint (L'impronta nascosta), è come il rapporto di un custode. Chiede: "Quando il detective finisce, quanta spazzatura lascia nella stanza?"

La grande sorpresa: Il disordine è enorme

La scoperta principale è scioccante: Due detective possono risolvere esattamente lo stesso mistero alla perfezione, ma uno lascia dietro di sé una pila di spazzatura 15,7 volte più grande dell'altro.

Pensatelo così: Tu e un tuo amico avete cucinato entrambi una torta al cioccolato perfetta. Consegni la torta (il risultato). Ma mentre tu hai appena pulito il bancone, il tuo amico ha lasciato dietro di sé 15 ciotole, 30 tazze di farina e una montagna di involucri appiccicosi. La torta è la stessa, ma la cucina del tuo amico è una zona di disastro.

Nel mondo reale, questa "spazzatura" non è solo carta; sono byte digitali memorizzati su un disco rigido. I ricercatori hanno scoperto che per un singolo compito, alcuni framework lasciano dietro di sé 131 MB di dati, mentre la risposta effettiva (la "torta consegnata") era di soli 2,6 MB. Ciò significa che il "residuo" del framework era 24.033 volte più grande del lavoro che doveva effettivamente svolgere!

Il trucco del "doppio conteggio invisibile"

Ecco la parte complicata: Se conti semplicemente i file sul computer, potresti pensare che il disordine non sia poi così grave. L'articolo sostiene che il conteggio standard è una trappola.

Immagina di scrivere la parola "Ciao" su un foglio di carta. Poi fai una fotocopia di quel foglio, ma la fotocopiatrice aggiunge un piccolo timbro di "inchiostro invisibile" su ogni copia. Se conti la carta, vedi un unico foglio. Ma se guardi l'inchiostro, vedi la parola "Ciao" scritta dodici volte.

I ricercatori hanno scoperto che, a causa di come i computer salvano i dati (usando cose come le pagine "SQLite" e l'escaping "JSON"), la stessa informazione viene memorizzata ripetutamente, nascosta all'interno del sistema.

Il conteggio ingenuo diceva: "Oh, c'è solo una piccola duplicazione."
Il conteggio intelligente dell'articolo diceva: "In realtà, lo stesso contenuto è memorizzato 12,1 volte!"

Hanno dimostrato che se non guardi dentro l'"inchiostro invisibile", perdi l'effettiva dimensione del disordine per un margine enorme.

Il problema della "crescita"

L'articolo ha anche testato cosa succede quando il detective deve controllare lo stesso indizio 200 volte.

Alcuni framework (come LangGraph e AutoGen) si comportano come uno scoiattolo che non dimentica mai nulla. Ogni volta che controlla l'indizio, riscrive l'intera cronologia. Questo fa sì che l'archiviazione cresca in modo superlineare (sempre più velocemente). Dopo 200 round, hanno lasciato dietro di sé 323 MB di dati solo per un minuscolo file.
Altri framework (come OpenAI Agents) si comportano come un bravo prenditore di appunti. Scrivono solo le cose nuove. La loro archiviazione è cresciuta lentamente, quasi in linea retta.

L'articolo ha misurato questo tasso di crescita (chiamato $\alpha$ ) e ha scoperto che variava da 0,73 (che diminuisce!) a 1,95 (che esplode in dimensioni).

Un disordine maggiore significa un detective più intelligente?

Potresti pensare: "Forse il detective disordinoso è solo extra premuroso, quindi è più intelligente?"
L'articolo dice: No.

Hanno esaminato 108 invii reali da una famosa sfida di programmazione (SWE-bench). Hanno scoperto che la quantità di dati esportati da questi sistemi variava di 1.617 volte (da file minuscoli a file enormi). Ma ecco il punto cruciale: Non c'era alcuna connessione tra la dimensione del disordine e quanto bene il sistema risolveva il problema.

Infatti, la correlazione era così debole che era praticamente nulla. Un sistema poteva lasciare dietro di sé una montagna di dati e fallire comunque, oppure lasciare un'impronta minuscola e avere successo. L'articolo esclude esplicitamente l'idea che "più memoria = migliori prestazioni".

Lo "Gomma Magica" (Ma non compratela ancora)

I ricercatori non si sono limitati a evidenziare il problema; hanno mostrato un modo per risolverlo, ma avvertono che questo è una prova di concetto, non un prodotto finito.

Hanno costruito un "magazzino basato sul contenuto" (content-addressed store). Immaginate una biblioteca dove, invece di mettere ogni libro su uno scaffale, scattate una foto all'impronta digitale unica del libro. Se due libri sono identici, ne conservate solo uno e una nota che dice "Questo è lo stesso di quello".

Quando hanno applicato questa "gomma magica" ai framework disordinosi:

Ha ridotto l'archiviazione di 4,8 - 32,7 volte.
Fondamentalmente, hanno dimostrato che anche con tutti quei dati rimossi, era possibile ricostruire perfettamente l'intera cronologia della conversazione. Il "punteggio" per la capacità di riprodurre i pensieri del detective è rimasto esattamente lo stesso.

Cosa esclude l'articolo

Esclude l'idea che dovremmo semplicemente ignorare l'archiviazione perché "è economica". L'articolo sostiene che l'archiviazione è un debito persistente che si accumula nel tempo, a differenza del costo di esecuzione dell'IA che svanisce quando il compito termina.
Esclude l'idea che i contatori di file standard siano accurati. Hanno dimostrato che il semplice conteggio ignora la duplicazione nascosta all'interno del codice del sistema.
Esclude l'idea che tracce di dati più grandi significhino risultati migliori. I dati non mostrano alcun legame con il successo.

Quanto sono sicuri?

Gli autori sono molto sicuri delle misurazioni effettuate. Hanno eseguito 1.061 esperimenti in stanze isolate e pulite (sandbox) per assicurarsi che nient'altro interferisse. Hanno testato 8 framework diversi (come LangGraph, CrewAI e AutoGen) usando esattamente gli stessi compiti e modelli.

Non hanno solo tirato a indovinare; hanno misurato. Hanno scoperto che, in condizioni identiche, la quantità di dati lasciati dietro variava di 15,7 volte tra i migliori e i peggiori esecutori. Hanno anche dimostrato che questa differenza non è dovuta al fatto che un framework sia più "intelligente" nel risolvere i compiti, ma a come sono costruiti per salvare i dati.

Il punto fondamentale

L'articolo conclude che dobbiamo iniziare a misurare l'"impronta" degli agenti IA proprio come misuriamo la loro velocità o il loro costo. In questo momento, stiamo permettendo ad alcuni sistemi di lasciare dietro di sé montagne di spazzatura digitale mentre altri non lasciano quasi nulla, e si scopre che i sistemi disordinosi non fanno un lavoro migliore.

Gli autori suggeriscono che se vogliamo far girare questi agenti su scala massiccia (come una flotta di 10.000 robot al giorno), la differenza tra un framework "pulito" e uno "disordinoso" potrebbe significare la differenza tra aver bisogno di 3 GB di archiviazione o 51 GB ogni singolo giorno. Questa è una differenza enorme per un problema che, come hanno dimostrato, non rende nemmeno il robot più intelligente.

Riepilogo Tecnico: L'Impronta Nascosta: Rendere lo Storage un Metrica di Prima Classe per la Valutazione degli Agenti LLM

1. Problematica

I benchmark attuali per gli agenti basati su Large Language Model (LLM) si concentrano sul completamento dei task, l'affidabilità (es. pass@k) e il costo di inferenza. Tuttavia, essi ignorano sistematicamente l'impronta di storage persistente — ovvero i byte che un'esecuzione dell'agente lascia su disco dopo il completamento. Ciò include log, snapshot del contesto, checkpoint, tracce di debug e database di sessione.

Il paper sostiene che questa omissione sia critica perché:

Persistenza vs Flusso: A differenza del costo di inferenza (un flusso consumato durante l'esecuzione), lo storage è uno stock che si accumula attraverso le esecuzioni, impattando i costi di storage a lungo termine, la conformità alla ritenzione dei dati e la capacità di riprodurre o auditare il comportamento dell'agente.
Sottostima: Nelle implementazioni in produzione, il residuo del framework può superare gli artefatti consegnati di ordini di grandezza (es. 79 MB di residuo contro 2,6 MB di output).
Trappole di Misurazione: Le misurazioni naïve a livello di byte (es. du -sh) non riescono a rilevare la duplicazione logica perché i meccanismi di serializzazione come il paging di SQLite e l'escaping di JSON oscurano il contenuto ripetuto. Ad esempio, uno store che contiene logicamente lo stesso contenuto 12 volte potrebbe riportare un fattore di duplicazione ( $D$ ) di soli 1,01 se misurato a livello di file grezzo.

2. Metodologia: AgentFootprint

Gli autori introducono AgentFootprint, un benchmark sistematico cross-framework progettato per misurare le impronte di storage post-esecuzione.

2.1 Setup Sperimentale

Framework: Sono stati valutati otto framework rappresentativi: LangGraph, AutoGen, CrewAI, SmolAgents, OpenAI Agents SDK, LlamaIndex, Agno e InfiAgent.
Controllo: Tutti i framework sono stati eseguiti sotto condizioni identiche: lo stesso modello backend (DeepSeek-V4-Flash, temperatura 0), strumenti identici e configurazioni documentate di "durable-session" (senza tuning specifico per lo storage).
Isolamento: Ogni esecuzione è avvenuta in un sandbox fresco (container Docker) con le directory workspace e home fotografate prima e dopo l'esecuzione per isolare il delta.
Suite di Task:
- File-QA: 10 task che comportano la rilettura di documenti per testare l'amplificazione di lettura.
- Long-Horizon: 25–200 round di rilettura di un file di stato da 2 KB per misurare gli esponenti di crescita.
- Write-Task: Generazione di file di riepilogo per confrontare gli artefatti legittimi rispetto al residuo del framework.
- Esplorativo/Eterogeneo: Task valutati sia sulla correttezza della risposta che sulla consegna degli artefatti.
- Fixed-Trace Control: Riproduzione di una traiettoria identica attraverso diversi adapter per isolare l'amplificazione dello strato di persistenza dal comportamento dell'agente.

2.1 Suite di Metriche

Il benchmark definisce sei metriche per affrontare l'oscuramento da serializzazione e l'ambiguità semantica:

$S_{total}$ : Totale byte trattenuti (artefatti dello workspace + residuo del framework).
Composizione dello Store: Suddivisione per canale (stato/checkpoint, log di debug, cronologia conversazione, ecc.).
$D$ (Fattore di Duplicazione): $S_{logical}^{total} / S_{unique}$ . Calcolato analizzando i flussi di contenuto logico (celle SQLite, linee JSONL) piuttosto che i file grezzi, utilizzando il content-defined chunking (FastCDC) e sonde di contenuto per rilevare duplicati escaped in JSON.
$\alpha$ (Esponente di Crescita): Calcolato tramite il fitting di $\log S_{total} \sim \alpha \log T$ su task di osservazione ripetuta per determinare se lo storage cresce linearmente, sottolineamente o superlinearmente.
$C$ (Compressione): Rapporto tra $S_{total}$ e la sua dimensione sotto compressione zstd (un baseline sintattico).
$R$ (Punteggio di Ricostruibilità): Un punteggio da 0 a 3 che indica se i byte trattenuti permettono la ricostruzione esatta della cronologia della conversazione al passo $k$ .

3. Risultati Chiave

3.1 Accuratezza Uguale, Dispersione Massiccia

Differenza di 15,7×: A parità di accuratezza del 100%, i byte trattenuti variavano di un fattore di 15,7 tra i framework (LangGraph: 5,10 MB vs CrewAI: 0,32 MB per task).
Ritenzione Zero: SmolAgents ha trattenuto 0 byte, ottenendo il 100% di accuratezza ma offrendo nessuna capacità di replay o recupero ( $R=0$ ).
Dominanza del Residuo: Nei task di scrittura, il residuo del framework ha superato i file di output legittimi fino a 24.033×.

3.2 Regimi di Crescita

Crescita Superlineare: I framework che persistono la cronologia completa ad ogni step (LangGraph, AutoGen, LlamaIndex) hanno mostrato esponenti di crescita ( $\alpha$ ) compresi tra 1,74 e 1,95. Un loop di monitoraggio di 200 round ha lasciato 323 MB di dati.
Crescita Lineare/Sottolineare: I framework con contesti a finestra o store limitati (InfiAgent, Agno, CrewAI) sono rimasti vicini alla linearità ( $\alpha \approx 0,98–1,20$ ).
Amplificazione Fixed-Trace: Riproducendo una traiettoria identica, lo strato di persistenza da solo ha causato una differenza di 6,7× nella dimensione trattenuta tra i framework.

3.3 La Serializzazione Maschera la Duplicazione

L'analisi del chunking dei file grezzi ha riportato un fattore di duplicazione ( $D$ ) di 1,01 per LangGraph.
L'analisi del flusso logico ha rivelato $D = 12,8$ , indicando che la serializzazione (paging SQLite, escaping JSON) oscura una massiccia ridondanza.
Le misurazioni naïve sottostimano la duplicazione di un ordine di grandezza.

3.4 Risultati "In-the-Wild" (SWE-bench)

L'analisi di 108 sottomissioni normalizzate per istanza di SWE-bench Verified ha mostrato una dispersione di 1.617× nel volume della traiettoria esportata.
Nessuna Correlazione: Non c'è stata alcuna correlazione rilevabile tra il volume della traiettoria e il tasso di risoluzione ( $\tau_b = 0,080, p = 0,222$ ). Traiettorie più pesanti non sono correlate a una maggiore capacità di successo.

3.5 Potenziale di Mitigazione

Un compattatore basato su content-addressed store (CAS) ha ridotto la ritenzione di 4,8–32,7× attraverso i framework, preservando tutti i punteggi di ricostruibilità ( $R$ ) e superando i controlli di ripristino.
Ciò dimostra che il "rifiuto" è una ridondanza rimovibile, non un requisito fondamentale per un'alta fedeltà della ricostruzione della cronologia.

4. Contributi

Suite di Metriche & Metodologia: Una nuova serie di metriche ( $S_{total}, D, \alpha, C, R$ ) e una metodologia di misurazione che tiene conto dell'oscuramento da serializzazione, rivelando che i conteggi dei byte naïve sottostimano significativamente la duplicazione.
Benchmark AgentFootprint: Un harness riproducibile che esegue 1.061 run in sandbox su otto framework, fornendo il primo confronto sistematico della post-esecuzione dello storage tra i framework.
Studio In-the-Wild: Evidenza da SWE-bench che mostra come il volume di storage sia non correlato al successo e vari enormemente anche tra le sottomissioni di successo.
Prova di Esistenza: Una dimostrazione del fatto che un content-addressed store può ridurre lo storage fino a 32,7× senza sacrificare la ricostruibilità della cronologia, provando che le attuali configurazioni di default sono lontane dal minimo teorico.

5. Significato e Rivendicazioni

Il paper sostiene che l'impronta di storage sia una dimensione critica, precedentemente non misurata, della valutazione degli agenti. Sostiene che:

Lo Storage è una Risorsa di Sistema: Come l'impronta di memoria per le app mobili, lo storage non misurato limita la distribuzione su scala (es. operazioni di flotta che accumulano terabyte giornalmente).
I Default non sono Efficienti: Le configurazioni "durable" documentate spesso danno priorità alle funzionalità di recupero rispetto all'efficienza, portando a un enorme e inutile accumulo di storage.
L'Accuratezza è Insufficiente: I leaderboard focalizzati solo sul successo del task o sul costo di inferenza penalizzano i framework per la bassa accuratezza ma ignorano i framework che ottengono un'alta accuratezza con 15× più storage.
La Ricostruibilità è Raggiungibile a Basso Costo: Il paper dimostra che la ricostruzione esatta della cronologia non richiede megabyte di dati; lo stesso punteggio $R=3$ può essere ottenuto con molti meno byte se la ridondanza viene gestita.

Gli autori posizionano AgentFootprint non come una proposta per un nuovo sistema di storage, ma come uno strumento di misurazione per esporre l' "impronta nascosta" e consentire alla comunità di ottimizzare l'efficienza dello storage insieme ad accuratezza e costo.