Apple propose SelfCompact : l'agent décide lui-même quand compresser son contexte

Les chercheurs d'Apple ML Research proposent SelfCompact, un cadre pour agents LLM dans lequel le modèle choisit lui-même quand et comment compresser l'historique accumulé. La conception repose sur deux éléments qui opèrent au moment de l'inférence. Le premier est un outil de compactification, que le modèle appelle pour résumer le contexte accumulé. À la place de la règle rigide « compresser à N tokens », c'est l'agent qui prend la décision. Le fragment de l'abstract dont nous disposons s'interrompt à la description du premier élément. Le second élément et les résultats chiffrés n'y figurent pas : il est donc impossible, pour l'instant, d'évaluer l'efficacité de la méthode sur la base de chiffres.

Le problème : un contexte qui gêne le raisonnement

Les longues trajectoires d'agents se composent de chaînes de raisonnement et d'appels d'outils. Au fil du travail, elles accumulent du contenu périmé : hypothèses intermédiaires, options écartées, volumineuses réponses de recherche. Les auteurs relèvent deux conséquences. D'abord, cette traîne « ancre » les générations suivantes : le modèle continue de s'appuyer sur ce qui a déjà perdu sa pertinence. Ensuite, la trajectoire finit tôt ou tard par dépasser la fenêtre de contexte.

La pratique actuelle est la suivante : le cadre compte les tokens et, une fois le seuil atteint, lance la compression à intervalles réguliers. Cette approche est simple à implémenter, mais elle a un point faible. Le déclencheur ne voit pas la structure de la tâche. Le seuil peut être franchi au milieu d'une déduction mathématique ou d'une recherche en plusieurs étapes. Un résultat partiel, qui ne s'est pas encore mué en conclusion, risque alors de passer à la trappe ou de perdre des détails importants.

Ce que change SelfCompact

L'idée consiste à confier la décision à celui qui connaît le mieux l'état du raisonnement, c'est-à-dire au modèle lui-même. Celui-ci reçoit un outil de compactification et l'appelle comme il appellerait une recherche ou un interpréteur de code. L'agent peut terminer une sous-tâche, consigner sa conclusion, et seulement ensuite compresser l'historique. Il détermine aussi lui-même le contenu du résumé : quels faits conserver, quelles étapes intermédiaires considérer comme closes.

La formulation « inference-time elements » laisse penser qu'il s'agit d'une surcouche au modèle, et non d'une modification de son architecture. Le texte disponible ne l'affirme pas explicitement : on ne peut donc pas le tenir pour confirmé. Si c'est bien le cas, la méthode peut être testée sur des modèles existants, sans réentraînement.

Ce que l'on sait de la source

• Auteur : Apple ML Research, publication du 12 octobre 2026.
• Nom de la méthode : SelfCompact.
• Schéma de référence pour la comparaison : compactification à intervalle fixe, déclenchée par un seuil de tokens.
• Composition de la méthode : deux éléments à l'inférence, dont le premier est un outil de compression appelé par le modèle.
• Le fragment disponible ne donne ni benchmarks, ni tailles de modèles, ni gain de précision, ni économie de tokens.

Comment l'utiliser en pratique

Tant que le texte complet n'est pas disponible, mieux vaut considérer SelfCompact comme une hypothèse à tester. Les équipes qui construisent des agents de longue durée pour le code, la recherche ou le support gagneraient à faire plusieurs choses.

Premièrement : examiner les logs de leurs agents et repérer les cas où la compression par seuil s'est déclenchée au mauvais moment. Les signes sont les suivants : l'agent répète une recherche déjà effectuée, perd un résultat intermédiaire ou revient à une hypothèse écartée. Si ces cas sont nombreux, le sujet vous concerne.

Deuxièmement : monter une petite expérience. Donnez au modèle un outil de compression accompagné d'une instruction claire sur le moment de l'utiliser, puis comparez avec votre déclencheur actuel sur un même jeu de tâches. Les métriques s'imposent d'elles-mêmes : taux de tâches menées à bien, nombre de tokens par tâche, nombre d'étapes répétées.

Troisièmement : prévoir des garde-fous contre les mauvais comportements. Le modèle peut compresser trop souvent ou, à l'inverse, ne pas compresser du tout jusqu'au débordement de la fenêtre. Il est raisonnable de conserver un seuil strict comme filet de sécurité et de faire de la décision du modèle le mécanisme principal.

L'intérêt de cet article tient au fait qu'il fait passer la gestion de la mémoire de l'agent de la couche d'infrastructure à la responsabilité du modèle lui-même. On saura si cela fonctionne après la publication des résultats complets et de la comparaison avec les schémas à intervalle fixe sur de longues tâches.