🤖 AI

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

Cet article introduit AgentFootprint, un benchmark révélant que l'empreinte de stockage persistant des agents LLM varie considérablement selon les frameworks et les configurations indépendamment de la précision des tâches, tout en démontrant que le stockage adressable par contenu peut réduire significativement ce surcoût sans compromettre la reconstructibilité des données.

Auteurs originaux : Chenglin Yu, Hongquan Gui, Ying Yu, Hongxia Yang, Ming Li

Publié 2026-07-14

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Chenglin Yu, Hongquan Gui, Ying Yu, Hongxia Yang, Ming Li

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous regardez un brillant détective robot résoudre un mystère. Il lit des indices, pose des questions et écrit sa réponse finale. Tout le monde applaudit lorsque le détective trouve la bonne réponse, et l'on vérifie à quelle vitesse il a réfléchi et combien il a coûté à faire fonctionner. Mais personne ne regarde le désordre que le détective laisse derrière lui sur le sol.

Ce document, intitulé The Hidden Footprint (L'empreinte cachée), est comme un rapport de concierge. Il demande : « Quand le détective a fini, quel tas de déchets laisse-t-il dans la pièce ? »

La grande surprise : Le désordre est énorme

La conclusion principale est choquante : Deux détectives peuvent résoudre exactement le même mystère parfaitement, mais l'un laisse derrière lui une pile de déchets 15,7 fois plus grande que l'autre.

Voyez cela comme ceci : Vous et votre ami avez tous deux cuisiné un parfait gâteau au chocolat. Vous présentez le gâteau (le résultat). Mais alors que vous venez de nettoyer le plan de travail, votre ami a laissé derrière lui 15 bols, 30 tasses de farine et une montagne d'emballages collants. Le gâteau est identique, mais la cuisine de votre ami est une zone de catastrophe.

Dans le monde réel, ce « déchet » n'est pas seulement du papier ; ce sont des octets numériques stockés sur un disque dur. Les chercheurs ont découvert que pour une seule tâche, certains frameworks laissent derrière eux 131 Mo de données, alors que la réponse réelle (le « gâteau livré ») ne pesait que 2,6 Mo. Cela signifie que le « résidu » du framework était 24 033 fois plus grand que le travail qu'il était censé accomplir !

L'astuce du double comptage « invisible »

Voici la partie délicate : Si vous comptez simplement les fichiers sur l'ordinateur, vous pourriez penser que le désordre n'est pas si grave. Le papier soutient que le comptage standard est un piège.

Imaginez que vous écriviez le mot « Bonjour » sur une feuille de papier. Ensuite, vous photocopiez cette feuille, mais la photocopieuse ajoute un minuscule tampon à l'« encre invisible » sur chaque copie. Si vous comptez le papier, vous voyez une feuille. Mais si vous regardez l'encre, vous voyez le mot « Bonjour » écrit douze fois.

Les chercheurs ont découvert qu'en raison de la manière dont les ordinateurs enregistrent les données (en utilisant des choses comme les pages « SQLite » et l'échappement « JSON »), la même information est enregistrée encore et encore, cachée à l'intérieur du système.

Le comptage naïf disait : « Oh, il y a peu de duplication. »
Le comptage intelligent du papier disait : « En fait, le même contenu est stocké 12,1 fois ! »

Ils ont prouvé que si vous ne regardez pas à l'intérieur de l'« encre invisible », vous manquez la taille réelle du désordre par une marge énorme.

Le problème de la « croissance »

Le papier teste également ce qui se passe lorsqu'un détective doit vérifier le même indice 200 fois.

Certains frameworks (comme LangGraph et AutoGen) agissent comme un écureuil qui n'oublie jamais rien. Chaque fois qu'il vérifie l'indice, il réécrit l'intégralité de l'historique. Cela provoque une croissance de l'espace de stockage de manière superlinéaire (de plus en plus vite). Après 200 tours, ils ont laissé derrière eux 323 Mo de données pour un seul petit fichier.
D'autres frameworks (comme OpenAI Agents) agissent comme un preneur de notes intelligent. Ils n'écrivent que les nouveautés. Leur stockage a grandi lentement, presque en ligne droite.

Le papier a mesuré ce taux de croissance (appelé $\alpha$ ) et a constaté qu'il variait de 0,73 (en diminution !) à 1,95 (explosion de la taille).

Un plus gros désordre signifie-t-il un détective plus intelligent ?

Vous pourriez penser : « Peut-être que le détective désordonné est juste plus prudent, donc il est plus intelligent ? »
Le papier dit : Non.

Ils ont examiné 108 soumissions réelles provenant d'un célèbre défi de codage (SWE-bench). Ils ont découvert que la quantité de données exportées par ces systèmes variait de 1 617 fois (des fichiers minuscules aux fichiers énormes). Mais voici le plus frappant : Il n'y avait aucun lien entre la taille du désordre et la capacité du système à résoudre le problème.

En fait, la corrélation était si faible qu'elle était pratiquement nulle. Un système pouvait laisser derrière lui une montagne de données et échouer, ou laisser une empreinte minuscule et réussir. Le papier écarte explicitement l'idée que « plus de stockage = de meilleures performances ».

La « Gomme Magique » (Mais ne l'achetez pas encore)

Les chercheurs n'ont pas seulement souligné le problème ; ils ont montré un moyen de le résoudre, mais ils précisent qu'il s'agit d'une preuve de concept, et non d'un produit fini.

Ils ont construit un « magasin adressé par le contenu » (content-addressed store). Imaginez une bibliothèque où, au lieu de mettre chaque livre sur une étagère, vous prenez une photo de l'empreinte digitale unique du livre. Si deux livres sont identiques, vous ne gardez qu'une seule photo et une note disant « Celui-ci est le même que celui-là ».

Lorsqu'ils ont appliqué cette « gomme magique » aux frameworks désordonnés :

Cela a réduit le stockage de 4,8 à 32,7 fois.
Crucialement, ils ont prouvé qu'en supprimant toutes ces données, vous pouviez toujours reconstruire parfaitement l'intégralité de l'historique de la conversation. Le « score » pour pouvoir rejouer les pensées du détective est resté exactement le même.

Ce que le papier écarte

Il écarte l'idée que nous devrions simplement ignorer le stockage sous prétexte qu'il est « bon marché ». Le papier soutient que le stockage est une dette persistante qui s'accumule avec le temps, contrairement au coût de fonctionnement de l'IA qui disparaît une fois la tâche terminée.
Il écarte l'idée que les compteurs de fichiers standards sont précis. Ils ont montré que le comptage simple manque la duplication cachée à l'intérieur du code du système.
Il écarte l'idée que des traces de données plus grandes signifient de meilleurs résultats. Les données ne montrent aucun lien avec le succès.

À quel point sont-ils sûrs ?

Les auteurs sont très sûrs des mesures qu'ils ont prises. Ils ont mené 1 061 expériences dans des environnements isolés et propres (sandboxes) pour s'assurer que rien d'autre n'interfère. Ils ont testé 8 frameworks différents (comme LangGraph, CrewAI et AutoGen) en utilisant exactement les mêmes tâches et modèles.

Ils n'ont pas seulement deviné ; ils ont mesuré. Ils ont constaté que, dans des conditions identiques, la quantité de données laissées derrière elles variait de 15,7 fois entre les meilleurs et les moins bons performeurs. Ils ont également montré que cette différence ne provient pas du fait qu'un framework est plus « intelligent » pour résoudre les tâches, mais de la manière dont ils sont construits pour sauvegarder les données.

Ce qu'il faut retenir

Le papier conclut que nous devons commencer à mesurer l'« empreinte » des agents IA de la même manière que nous mesurons leur vitesse ou leur coût. Actuellement, nous laissons certains systèmes laisser derrière eux des montagnes de déchets numériques tandis que d'autres ne laissent presque rien, et il s'avère que les systèmes désordonnés ne font pas un meilleur travail.

Les auteurs suggèrent que si nous voulons faire fonctionner ces agents à une échelle massive (comme une flotte de 10 000 robots par jour), la différence entre un framework « propre » et un framework « désordonné » pourrait signifier qu'il faudra 3 Go de stockage ou 51 Go chaque jour. C'est une différence énorme pour un problème qui, comme ils l'ont montré, ne rend même pas le robot plus intelligent.

Résumé Technique : L'Empreinte Cachée : Faire du Stockage une Métrique de Premier Rang pour l'Évaluation des Agents LLM

1. Énoncé du Problème

Les benchmarks actuels pour les agents basés sur les Grands Modèles de Langage (LLM) se concentrent sur l'accomplissement des tâches, la fiabilité (par exemple, le pass@k) et le coût d'inférence. Cependant, ils ignorent systématiquement l'empreinte de stockage persistante — les octets qu'une exécution d'agent laisse sur le disque après achèvement. Cela inclut les journaux (logs), les instantanés de contexte (snapshots), les points de contrôle (checkpoints), les traces de débogage et les bases de données de session.

L'article soutient que cette omission est critique car :

Persistance vs Flux : Contrairement au coût d'inférence (un flux consommé pendant l'exécution), le stockage est un stock qui s'accumule au fil des exécutions, impactant les coûts de stockage à long terme, la conformité de la rétention des données et la capacité de rejouer ou d'auditer le comportement de l'agent.
Sous-estimation : Dans les déploiements en production, les résidus de framework peuvent dépasser les artefacts livrés de plusieurs ordres de grandeur (par exemple, 79 Mo de résidus contre 2,6 Mo de sortie).
Pièges de Mesure : Les mesures naïves au niveau de l'octet (par exemple, du -sh) ne parviennent pas à détecter la duplication logique car les mécanismes de sérialisation comme le partitionnement SQLite et l'échappement JSON masquent le contenu répété. Par exemple, un magasin tenant logiquement le même contenu 12 fois peut rapporter un facteur de duplication ( $D$ ) de seulement 1,01 lorsqu'il est mesuré au niveau du fichier brut.

2. Méthodologie : AgentFootprint

Les auteurs introduisent AgentFootprint, un benchmark systématique multi-framework conçu pour mesurer les empreintes de stockage post-exécution.

2.1 Configuration Expérimentale

Frameworks : Huit frameworks représentatifs ont été évalués : LangGraph, AutoGen, CrewAI, SmolAgents, OpenAI Agents SDK, LlamaIndex, Agno et InfiAgent.
Contrôle : Tous les frameworks ont été exécutés dans des conditions identiques : même modèle backend (DeepSeek-V4-Flash, température 0), outils identiques, et configurations de "session durable" documentées (sans réglage spécifique au stockage).
Isolation : Chaque exécution a eu lieu dans un bac à sable (sandboxes) frais (conteneurs Docker) avec les répertoires de travail et de domicile photographiés avant et après l'exécution pour isoler le delta.
Suites de Tâches :
- File-QA : 10 tâches impliquant la relecture de documents pour tester l'amplification de lecture.
- Long-Horizon (Longue Durée) : 25 à 200 cycles de relecture d'un fichier de statut de 2 Ko pour mesurer les exposants de croissance.
- Write-Task (Tâche d'Écriture) : Génération de fichiers de résumé pour comparer les artefacts légitimes versus les résidus du framework.
- Exploratoire/Hétérogène : Tâches notées à la fois sur la justesse de la réponse et la livraison d'artefacts.
- Contrôle de Trace Fixe : Rejouer une trajectoire identique à travers différents adaptateurs pour isoler l'amplification de la couche de persistance du comportement de l'agent.

2.2 Suite de Métriques

Le benchmark définit six métriques pour répondre au masquage par sérialisation et à l'ambiguïté sémantique :

$S_{total}$ : Octets totaux conservés (artefacts de l'espace de travail + résidus du framework).
Composition du Magasin : Répartition par canal (états/checkpoints, logs de débogage, historique de conversation, etc.).
$D$ (Facteur de Duplication) : $S_{logical}^{total} / S_{unique}$ . Calculé en analysant les flux de contenu logique (cellules SQLite, lignes JSONL) plutôt que les fichiers bruts, en utilisant le découpage défini par le contenu (FastCDC) et des sondes de contenu pour détecter les doublons échappés en JSON.
$\alpha$ (Exposant de Croissance) : Ajusté à partir de $\log S_{total} \sim \alpha \log T$ sur des tâches d'observation répétées pour déterminer si le stockage croît de manière linéaire, sous-linéaire ou superlinéaire.
$C$ (Compressibilité) : Ratio de $S_{total}$ par rapport à sa taille sous compression zstd (une base syntaxique).
$R$ (Score de Reconstructibilité) : Un score de 0 à 3 indiquant si les octets conservés permettent la reconstruction exacte de l'historique de la conversation à l'étape $k$ .

3. Résultats Clés

3.1 Précision Égale, Dispersion Massive

Différence de 15,7× : À une précision de tâche identique de 100 %, les octets conservés variaient d'un facteur 15,7 entre les frameworks (LangGraph : 5,10 Mo vs CrewAI : 0,32 Mo par tâche).
Zéro Rétention : SmolAgents conservait 0 octet, atteignant 100 % de précision mais offrant aucune capacité de rejeu ou de récupération ( $R=0$ ).
Dominance des Résidus : Dans les tâches d'écriture, le résidu du framework dépassait les fichiers de sortie légitimes jusqu'à 24 033×.

3.2 Régimes de Croissance

Croissance Superlinéaire : Les frameworks persistant l'historique complet à chaque étape (LangGraph, AutoGen, LlamaIndex) présentaient des exposants de croissance ( $\alpha$ ) compris entre 1,74 et 1,95. Une boucle de surveillance de 200 cycles a laissé 323 Mo de données.
Croissance Linéaire/Sous-linéaire : Les frameworks avec des contextes fenêtrés ou des magasins bornés (InfiAgent, Agno, CrewAI) restaient proches du linéaire ( $\alpha \approx 0,98–1,20$ ).
Amplification de Trace Fixe : Lors du rejeu d'une trajectoire identique, la couche de persistance seule a causé une différence de 6,7× de la taille conservée entre les frameworks.

3.3 La Sérialisation Masque la Duplication

Le découpage de fichier brut rapportait un facteur de duplication ( $D$ ) de 1,01 pour LangGraph.
L'analyse du flux logique a révélé $D = 12,8$ , indiquant que la sérialisation (pagination SQLite, échappement JSON) occulte une redondance massive.
Les mesures naïves sous-estiment la duplication d'un ordre de grandeur.

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

L'analyse de 108 soumissions normalisées par instance de SWE-bench Verified a montré une dispersion de 1 617× dans le volume de trajectoire exporté.
Aucune Corrélation : Il n'y avait aucune corrélation détectable entre le volume de la trajectoire et le taux de résolution ( $\tau_b = 0,080, p = 0,222$ ). Des trajectoires plus lourdes n'étaient pas corrélées à un succès plus élevé.

3.5 Potentiel de Mitigation

Un compresseur de magasin adressé par contenu (CAS) a réduit la rétention de 4,8 à 32,7× à travers les frameworks tout en préservant tous les scores de reconstructibilité ( $R$ ) et en passant les tests de restauration.
Cela démontre que le "gaspillage" est une redondance supprimable, et non une exigence fondamentale pour une haute fidélité de reconstruction de l'historique.

4. Contributions

Suite de Métriques & Méthodologie : Un nouvel ensemble de métriques ( $S_{total}, D, \alpha, C, R$ ) et une méthodologie de mesure qui tient compte du masquage par sérialisation, révélant que les comptes d'octets naïfs sous-estiment considérablement la duplication.
Benchmark AgentFootprint : Un harnais reproductible exécutant 1 061 exécutions en bac à sable à travers huit frameworks, fournissant la première comparaison systématique de l'empreinte de stockage post-exécution.
Étude "In-the-Wild" : Preuve issue de SWE-bench montrant que le volume de stockage est sans corrélation avec le succès et varie énormément même parmi les soumissions réussies.
Preuve d'Existence : Démonstration qu'un magasin adressé par contenu peut réduire la rétention jusqu'à 32,7× sans sacrifier la reconstructibilité de l'historique, prouvant que les configurations par défaut actuelles sont loin du minimum théorique.

5. Signification et Revendications

L'article affirme que l'empreinte de stockage est une dimension critique, auparavant non mesurée, de l'évaluation des agents. Il soutient que :

Le Stockage est une Ressource Système : Comme l'empreinte mémoire pour les applications mobiles, le stockage non mesuré limite le déploiement à grande échelle (par exemple, des flottes opérant des téraoctets quotidiennement).
Les Valeurs par Défaut ne sont pas Efficaces : Les configurations "durables" documentées privilégient souvent les fonctionnalités de récupération au détriment de l'efficacité, menant à une accumulation massive et inutile de stockage.
La Précision est Insuffisante : Les classements se concentrant uniquement sur le succès de la tâche ou le coût d'inférence pénalisent les frameworks pour une faible précision mais ignorent les frameworks qui atteignent une haute précision avec 15× plus de stockage.
La Reconstructibilité est Accessible à Faible Coût : L'article démontre que la reconstruction exacte de l'historique ne nécessite pas des mégaoctets de données ; le même score $R=3$ peut être atteint avec beaucoup moins d'octets si la redondance est gérée.

Les auteurs positionnent AgentFootprint non pas comme une proposition de nouveau système de stockage, mais comme un outil de mesure pour exposer l'« empreinte cachée » et permettre à la communauté d'optimiser l'efficacité du stockage parallèlement à la précision et au coût.