Vous ne manquez pas de jetons. Vous les gaspillez. Voici la différence.

Plus je travaille avec les LLM, plus je me retrouve dans le combat éternel entre assez de contexte, trop de contexte, gaspillage de tokens et guerre de compaction. En regardant les systèmes de mémoire agentiques, on voit qu'il existe quelques armes puissantes pour nous aider.

Le constat qui revient sans cesse dans les 19 systèmes que j'ai examinés est que des fenêtres plus grandes intensifient le problème du budget plutôt que de le résoudre. Une fenêtre de 200 000 tokens ne prête pas une attention égale à tous les 200 000 tokens. Les performances se dégradent bien avant que la fenêtre ne soit pleine. La dégradation n'est pas uniforme : les éléments au milieu d'un long contexte sont systématiquement moins bien pris en compte que ceux aux extrémités. De plus, la tâche réelle de l'agent occupe une portion fixe de la fenêtre, quelle que soit sa taille, ce qui signifie que tout le reste est un surcoût qui rivalise pour le même budget d'attention.

Les systèmes qui gèrent bien cela ont convergé vers six mécanismes. Aucun d'eux n'est exotique. Plusieurs sont d'une simplicité embarrassante. Mais ceux qui les ignorent paient le prix.

Les six mécanismes

Passes de compaction

Le mécanisme le plus visible. On prend une longue conversation ou un large segment de mémoire, on le résume, et on remplace l'original par le résumé. MemoryOS le fait au niveau du segment : son résumeur de segment se déclenche lorsqu'un segment de conversation dépasse un seuil, le réduisant à une représentation compacte avant qu'il ne puisse empiéter sur le contexte de travail. Les wikis de type Karpathy (purpose.md, overview.md) en font une version au niveau des connaissances : le wiki est la forme compactée de tout ce que l'agent a appris sur un sujet, maintenue entre les sessions.

Le compromis est la perte d'information. La compaction est par définition une opération avec perte. Le résumé capte ce que le résumeur a jugé pertinent au moment de la compaction. Si l'agent a plus tard besoin d'un détail qui n'a pas été jugé pertinent, il est perdu. Ce n'est pas une raison pour éviter la compaction, mais c'est une raison pour ne pas en faire le seul mécanisme.

Il y a un deuxième coût facile à manquer. La compaction n'est pas gratuite en temps d'exécution. MemoryOS peut dépenser 20 appels LLM ou plus en une seule interaction pour maintenir ses résumés de segments. Pour les systèmes à haute fréquence d'interaction, c'est un coût opérationnel réel.

Troncature par aperçu des résultats

Plutôt que de retourner le contenu complet de la mémoire à chaque récupération, on retourne un court aperçu et on laisse l'agent décider s'il veut récupérer l'enregistrement complet. supermemory expose des contrôles de longueur d'extrait qui permettent aux appelants de régler la quantité de texte renvoyée par résultat. mem9 va plus loin : il décore les tours de source avec trois variables d'environnement (MEM9_SOURCE_TURN_MIN_SCORE, MEM9_SOURCE_TURN_PER_MEMORY_LIMIT, MEM9_SOURCE_TURN_TOTAL_LIMIT) qui donnent aux opérateurs un contrôle précis sur le nombre de tours de source affichés et le score de pertinence minimum.

Le compromis est un appel d'outil supplémentaire. Si l'agent a besoin du contenu complet, il doit le demander explicitement. Pour la plupart des schémas de récupération, c'est le bon compromis : l'agent reçoit suffisamment de signal pour décider si l'enregistrement est pertinent avant de payer le coût en tokens pour le lire en entier.

Récupération en deux étapes

Une variante spécifique et importante de la troncature par aperçu. La recherche retourne des identifiants et de courts aperçus. Un appel GetByID séparé récupère l'enregistrement complet si nécessaire. L'interface MemoryRepo de mem9 est construite autour de ce schéma : la recherche et la récupération sont des opérations distinctes avec des empreintes token distinctes.

Les chiffres parlent d'eux-mêmes. Dix correspondances à 1 500 tokens chacune représentent 15 000 tokens injectés dans le contexte, que l'agent les utilise ou non. La récupération en deux étapes retourne 10 identifiants et de courts aperçus pour environ 450 tokens au total, puis ne récupère que les enregistrements dont l'agent a réellement besoin. Sur 20 étapes de rappel dans une session, cette différence s'accumule pour atteindre environ 200 000 tokens économisés.

C'est la discipline la moins coûteuse que l'on puisse adopter. Elle ne nécessite aucun changement architectural du stockage mémoire, aucun appel LLM supplémentaire, et aucune perte d'information. C'est une décision d'interface de récupération.

Décomposer puis rappeler

Plutôt que d'envoyer la requête utilisateur complète à la couche de récupération, on la décompose d'abord en sous-requêtes. Le planificateur de récupération basé sur l'intention de SimpleMem décompose les requêtes entrantes en intentions de récupération atomiques avant d'interroger le stockage mémoire. GitNexus fait quelque chose de similaire avec sa décomposition d'outils de requête : les requêtes complexes sont divisées en sous-requêtes ciblées, chacune récupérant une tranche focalisée du graphe mémoire.

Le bénéfice est la précision. Une requête décomposée récupère moins de matériel non pertinent, ce qui signifie moins de bruit dans le contexte. Le compromis est la latence : la décomposition ajoute une étape de planification avant que la récupération ne commence. Pour les agents interactifs, cela compte. Pour les agents par lots ou en arrière-plan, généralement pas.

Stockage hiérarchisé comme filtre budgétaire

Si vous avez déjà construit une architecture mémoire hiérarchisée (le sujet de l'article de la semaine dernière), vous obtenez un filtrage budgétaire comme effet secondaire. Le modèle à trois niveaux de supermemory signifie que le matériel chaud et fréquemment consulté vit dans un niveau qui renvoie des résultats compacts et à fort signal. Le matériel froid se trouve dans un niveau qui n'est pas interrogé par défaut. Le niveau d'observation de Hindsight fonctionne de la même manière : les observations brutes ne sont pas injectées directement dans le contexte ; elles sont promues vers des niveaux supérieurs avant de devenir des candidats à la récupération.

Le compromis est l'exhaustivité du rappel. Le matériel qui n'a pas été promu peut être pertinent mais ne remontera pas lors d'un passage de récupération standard. C'est le même compromis que la compaction, mais le mode d'échec est différent : au lieu de perdre de l'information par résumé, on la perd par rétrogradation.

Réponses d'outils auto-guidées

Le mécanisme le moins discuté, et l'un des plus intéressants. Plutôt que de laisser l'agent décider quoi faire après un appel d'outil, la réponse de l'outil elle-même inclut un indice sur la marche à suivre. GitNexus ajoute un bloc ---
**Next:** aux réponses d'outils, suggérant des actions de suivi. mem9 décore les tours de source avec des métadonnées structurées qui guident la prochaine étape de récupération de l'agent.

L'effet est que l'agent dépense moins de tokens en planification entre les appels d'outils. La réponse de l'outil porte suffisamment de structure pour rendre l'étape suivante évidente. Le compromis est l'effort d'ingénierie de prompt : écrire de bonnes réponses auto-guidées nécessite de savoir à l'avance ce dont l'agent aura probablement besoin ensuite, ce qui n'est pas toujours possible.

Le cas limite de Tolaria

Tolaria mérite d'être examiné séparément car il représente le point d'aboutissement logique de la discipline budgétaire poussée à l'extrême. ADR-0009 documente la décision de supprimer entièrement les plongements (embeddings) du système. Tolaria utilise uniquement la recherche par sous-chaîne. Pas d'index vectoriel, pas de récupération sémantique, pas d'appels de plongement.

Le raisonnement est direct : le token le moins cher est celui que l'on ne récupère jamais. La récupération basée sur les plongements renvoie des résultats sémantiquement similaires, ce qui signifie qu'elle renvoie des résultats que l'agent n'a pas explicitement demandés. Certains de ces résultats sont utiles. Beaucoup ne le sont pas. Tous coûtent des tokens.

La position de Tolaria est que le coût des résultats non pertinents mais similaires, cumulé sur une session, dépasse le bénéfice du rappel sémantique pour son cas d'usage. Que ce compromis tienne pour votre système dépend de ce à quoi votre système est destiné. Pour les systèmes où les requêtes sont précises et structurées (navigation dans le code, recherche de document par identifiant), la position de Tolaria est défendable. Pour les systèmes où les requêtes sont vagues et exploratoires, la suppression des plongements brise le rappel d'une manière dont il est difficile de se remettre.

La valeur du cas Tolaria n'est pas que vous devriez le copier. C'est qu'il rend le coût de la récupération sémantique visible d'une manière que la plupart des systèmes ne font pas.

Le cas contre les systèmes à compaction seule

Plusieurs des 19 systèmes s'appuient sur la compaction comme mécanisme budgétaire principal ou unique. Les modes d'échec méritent d'être nommés.

Le premier est que le résumé perd des détails qui n'ont pas été jugés pertinents au moment de la compaction mais qui le deviennent plus tard. Ce n'est pas hypothétique : c'est le mode d'échec standard de tout schéma de compression avec perte appliqué à des informations dont la pertinence future est inconnue.

Le second est que la compaction est un coût sur le chemin critique. MemoryOS dépensant 20+ appels LLM par interaction n'est pas rare pour les systèmes lourds en compaction. À grande échelle, ce coût n'est pas négligeable.

Le troisième, et le plus subtil, est que la compaction sans échappatoire est un oubli lent. Si la seule façon de réduire la taille du contexte est de résumer, et que les résumés sont avec perte, alors le système jette continuellement de l'information sans moyen de la récupérer. La récupération en deux étapes, le stockage hiérarchisé et la troncature par aperçu des résultats préservent tous l'enregistrement original. La compaction non.

Rien de tout cela ne signifie que la compaction est mauvaise. Cela signifie que la compaction seule ne suffit pas.

Pondération de la récence et file d'attente persistante

Deux mécanismes qui ne rentrent pas parfaitement dans les six catégories ci-dessus méritent d'être notés.

graymatter utilise la fusion RRF avec une récence à demi-poids. Ce n'est pas un mécanisme budgétaire au sens strict, mais il en fait office : en sous-pondérant le matériel ancien dans les classements de récupération, il réduit la probabilité que des enregistrements obsolètes et à faible signal évincent ceux récents et à fort signal. L'effet est une hiérarchisation douce via des pondérations de classement plutôt qu'une promotion explicite de niveau.

La machine d'état de file d'attente d'ingestion de llm-wiki (540 lignes) adopte une approche différente. La file d'attente sérialise les opérations d'ingestion et applique un classeur de pertinence à quatre signaux avant que quoi que ce soit n'entre dans le stockage mémoire. Le contrôle budgétaire se fait au moment de l'écriture plutôt qu'à la lecture. Le matériel qui ne franchit pas le seuil de pertinence n'est pas stocké, ce qui signifie qu'il ne peut pas être récupéré et ne peut pas consommer de contexte. C'est un contrôle budgétaire indirect, mais il est durable : les économies s'accumulent sur chaque session future.

Ce que les systèmes bien conçus ont en commun

En regardant les 19 systèmes, ceux qui gèrent bien les budgets de contexte partagent quelques propriétés.

Ils traitent la récupération comme une opération en deux étapes plutôt qu'une injection en une étape. Ils renvoient des aperçus avant les enregistrements complets. Ils préservent les enregistrements originaux plutôt que de les remplacer par des résumés. Ils donnent aux opérateurs le contrôle du volume de récupération via des paramètres explicites plutôt que des valeurs par défaut codées en dur. Et ils pensent au budget à la fois au moment de l'écriture et au moment de la lecture.

Ceux qui le gèrent mal ont tendance à s'appuyer sur un seul mécanisme, généralement la compaction, et à traiter la fenêtre de contexte comme un tampon à remplir plutôt qu'une ressource à gérer.

La conclusion de la recherche est simple. Des fenêtres plus grandes exigent plus de discipline, pas moins. Non pas parce que les remplir est mauvais en principe, mais parce que les remplir avec le mauvais matériel coûte plus cher que de laisser de la place vide.

Pour mon prochain article, je prévois de passer de la mémoire-comme-injection à la mémoire-comme-outils, en couvrant comment les 19 systèmes gèrent la frontière entre ce qui est poussé automatiquement dans le contexte et ce que l'agent doit demander explicitement.*

Comme toujours, si vous avez trouvé cela intéressant, utile ou si vous voulez simplement aider à diffuser le savoir :

Partagez, s'il vous plaît