LCM: Lossless Context Management

Ce papier présente la Gestion de Contexte Sans Perte (LCM), une architecture déterministe qui améliore la mémoire des LLM grâce à une compression contextuelle récursive et à une partition des tâches, permettant à l'agent Volt de surpasser Claude Code sur des tâches de codage à contexte long allant jusqu'à 1 million de tokens tout en garantissant une récupération d'état sans perte et une terminaison.

L'essentiel

Imaginez que vous essayez de résoudre un mystère massif s'étalant sur plusieurs jours. Vous disposez d'un détective brillant (l'IA), mais il possède une mémoire très à court terme. Si vous lui donnez une pile de 1 000 indices, il oubliera les premiers avant d'arriver aux derniers.

Pendant longtemps, la solution consistait simplement à donner au détective un carnet plus grand (une « fenêtre de contexte » plus large). Mais éventuellement, même les plus grands carnets deviennent trop lourds à porter, et le détective commence à se perdre face au volume écrasant de papier.

Ce papier présente une nouvelle façon d'aider le détective : la Gestion de Contexte Sans Perte (LCM). Imaginez cela comme donner au détective un bibliothécaire super-intelligent et automatisé qui gère les notes pour lui, plutôt que de lui demander de concevoir son propre système de classement.

Voici comment cela fonctionne, en utilisant des analogies simples :

1. Le Problème : Le Débat « GOTO » vs « Structuré »

Le papier compare deux façons de gérer la mémoire :

• L'Ancienne Méthode (RLM) : Imaginez demander au détective de concevoir son propre système de classement en code. Il doit décider comment organiser les notes, quand jeter des éléments et comment les retrouver plus tard. C'est comme donner à un programmeur une liberté illimitée d'utiliser des instructions GOTO (sauter n'importe où dans le code). C'est puissant, mais si le détective fait une erreur dans son script de classement, tout le système plante ou devient désordonné.
• La Nouvelle Méthode (LCM) : Au lieu de demander au détective d'écrire le système de classement, le moteur (l'ordinateur exécutant le détective) fournit une armoire de classement préconstruite et parfaite. Le détective dit simplement : « Voici un nouvel indice », et le moteur décide automatiquement quand résumer les anciens indices et où les stocker. C'est comme utiliser la programmation structurée (boucles et instructions conditionnelles) : c'est moins flexible, mais cela ne plante jamais à cause d'une logique défectueuse.

2. Les Deux Outils Magiques de la LCM

Le papier indique que la LCM utilise deux astuces principales pour maintenir le détective concentré :

A. L'Armoire de Classement « Sans Perte » (DAG Hiérarchique)

• Fonctionnement : Le moteur conserve une « Copie Maîtresse » de chaque note, mot pour mot, dans un coffre-fort sécurisé (le Stockage Immutable).
• Le Résumé : Pour économiser de l'espace dans l'espace de travail actif du détective, le moteur crée une « carte de résumé » pour les anciennes notes. Il place la carte de résumé dans l'espace de travail et cache la note complète dans le coffre-fort.
• La Magie : Si le détective a besoin de voir la note originale plus tard, il peut la demander, et le moteur échange instantanément la carte de résumé contre la note complète. Rien n'est jamais vraiment perdu ; c'est simplement compressé jusqu'à ce qu'il soit nécessaire.
• Analogie : Imaginez lire un livre de 500 pages. Au lieu de porter tout le livre, vous portez un marque-page avec un résumé d'une phrase pour chaque chapitre. Si vous devez vérifier un détail, vous retournez à la page spécifique du livre. Vous ne perdez jamais le texte original.

B. L'Équipe « Parallèle » (LLM-Map)

• Le Problème : Si le détective doit lire 1 000 fichiers un par un, il se fatiguera et oubliera le premier fichier avant d'atteindre le dernier.
• La Solution : Au lieu que le détective lise les fichiers lui-même, le moteur agit comme un patron qui embauche 16 assistants. Le détective donne au patron une seule instruction : « Lisez ces 1 000 fichiers et dites-moi l'essentiel de chacun. » Le moteur envoie alors les 1 000 fichiers aux assistants simultanément.
• Le Résultat : Les assistants effectuent le gros du travail en parallèle. Le détective ne voit que la liste finale et organisée des résultats. Le détective n'a jamais à garder 1 000 fichiers en tête en même temps.

3. La Promesse « Zéro Coût »

L'une des plus grandes affirmations du papier est que ce système ne ralentit pas les choses pour les petites tâches.

• Analogie : Si vous n'avez que 5 notes à classer, le moteur ne prend pas la peine de créer un système de classement complexe. Il laisse simplement le détective les lire directement. L'« armoire de classement » ne s'active que lorsque la pile devient trop grande. Cela signifie que pour des conversations normales et courtes, le système semble tout aussi rapide qu'une IA standard.

4. Les Résultats : Battre la Concurrence

Les auteurs ont testé leur système (appelé Volt) contre Claude Code, qui est actuellement l'un des meilleurs assistants de codage IA au monde.

• Le Test : Ils ont soumis aux deux systèmes un « mystère » massif contenant jusqu'à 1 million de mots d'indices (tokens).
• Le Résultat :
  • Pour les petits indices (moins de 32 000 mots), les deux systèmes ont performé à peu près de la même manière.
  • Pour les énormes indices (de 32 000 à 1 million de mots), Volt a gagné à chaque fois.
  • Le papier affirme que Volt était nettement meilleur pour trouver la bonne réponse dans des ensembles de données massifs car il ne se perdait pas dans le volume de texte, alors que Claude Code commençait à avoir des difficultés à mesure que le texte s'allongeait.

5. Pourquoi Cela Compte (Selon le Papier)

Le papier soutient que demander à une IA de gérer sa propre mémoire (comme dans la « Vieille Méthode ») est risqué car l'IA peut faire des erreurs dans son propre code. En déplaçant la gestion de la mémoire vers le moteur informatique (la « Nouvelle Méthode »), le système devient :

1. Plus Fiable : Il ne plante pas parce que l'IA a écrit un mauvais script.
2. Plus Efficace : Il gère d'énormes quantités de données sans que l'IA ne soit submergée.
3. Sans Perte : Il garantit qu'aucune information n'est jamais vraiment supprimée, seulement résumée.

En bref, le papier suggère que pour des tâches très longues et complexes, il vaut mieux donner à l'IA un assistant structuré et automatisé pour gérer la mémoire, plutôt que de laisser l'IA essayer d'être elle-même le bibliothécaire.

Résumé technique

Résumé Technique : Gestion de Contexte Sans Perte (LCM)

Énoncé du Problème

Le goulot d'étranglement principal pour les tâches agentic complexes et à long horizon reste la fenêtre de contexte effective des Grands Modèles de Langage (LLM). Même les modèles dont les fenêtres nominales dépassent 1 million de tokens peinent avec les sessions de plusieurs jours où le volume d'appels d'outils, de contenus de fichiers et de raisonnements intermédiaires excède la capacité. Ceci est aggravé par la « dégradation du contexte » (context rot), où les performances se détériorent considérablement avant d'atteindre la limite stricte en tokens.

Les travaux antérieurs, spécifiquement les Modèles de Langage Récursifs (RLM), ont proposé que les modèles gèrent activement leur propre contexte via une récursivité symbolique (par exemple, écrire des scripts pour découper et traiter leurs propres invites). Bien que les RLM aient démontré la viabilité d'une gestion active du contexte, ils héritent de la stochasticité du modèle : une stratégie de mémoire qui fonctionne lors d'une exécution peut échouer lors de la suivante. De plus, encapsuler chaque interaction dans un échafaudage récursif introduit de la latence et des coûts (« pénalité de contexte court ») pour les tâches qui tiennent dans des fenêtres standard. Il existe une tension entre l'expressivité du flux de contrôle généré par le modèle et la fiabilité requise pour les systèmes de production.

Méthodologie : Gestion de Contexte Sans Perte (LCM)

Le LCM propose une alternative déterministe et centrée sur l'architecture à l'approche centrée sur le modèle des RLM. Au lieu de demander au modèle d'inventer des stratégies de mémoire, le LCM transfère la charge de l'architecture de mémoire vers le moteur, fournissant une infrastructure déterministe basée sur une base de données. Le système repose sur deux piliers fondamentaux : la Compression Récursive du Contexte et la Partitionnement Récursif des Tâches.

1. Architecture de Mémoire à Double État

Le LCM assure une récupérabilité sans perte grâce à une conception à double état :

• Le Stockage Immutable : Un stockage persistant et transactionnel (par exemple, PostgreSQL) où chaque message utilisateur, réponse de l'assistant et résultat d'outil est persisté à l'identique et jamais modifié. C'est la source de vérité.
• Le Contexte Actif : La fenêtre envoyée au LLM à chaque tour, assemblée à partir de messages bruts récents et de nœuds de résumé précalculés.

Les nœuds de résumé fonctionnent comme des vues matérialisées dérivées de messages plus anciens via un résumé par LLM. Crucialement, le système conserve des « pointeurs sans perte » vers les données originales. Si un résumé est insuffisant, l'outil lcm_expand permet à l'agent de récupérer le contenu original à l'identique. Pour éviter l'inondation du contexte, lcm_expand est restreint aux sous-tâches, tandis que la boucle d'interaction principale n'observe que les résumés.

2. DAG Hiérarchique et Boucle de Contrôle

La structure de données centrale est un graphe orienté acyclique (DAG) de résumés. À mesure que le contexte actif se remplit, les messages plus anciens sont compactés en nœuds de résumé tandis que les originaux sont préservés.

• Boucle de Contrôle Déterministe : Le moteur gère la compaction en utilisant des seuils de tokens doux ($\tau_{soft}$) et durs ($\tau_{hard}$).
• Continuité à Coût Zéro : En dessous de $\tau_{soft}$, aucun résumé n'est effectué ; le système agit comme un journal passif, n'encourant aucune surcharge. La compaction est déclenchée de manière asynchrone lorsque les seuils sont dépassés, échangeant des résumés dans le contexte entre les tours du LLM.
• Escalade à Trois Niveaux : Pour garantir la convergence et prévenir l'« échec de compaction » (où un résumé est plus long que l'entrée), le LCM emploie un protocole d'escalade strict :
  1. Normal : Résumé par LLM préservant les détails.
  2. Agressif : Résumé par LLM sous forme de points avec des cibles de tokens réduites.
  3. Fallback Déterministe : Une troncature non-LLM vers une limite de tokens fixe (par exemple, 512 tokens).

3. Gestion des Fichiers Volumineux

Pour les fichiers dépassant les limites de contexte (par exemple, de grands journaux ou ensembles de données), le LCM ne charge pas le contenu complet. Au lieu de cela, il stocke une référence (chemin, ID) et un Résumé d'Exploration précalculé. Ce résumé est généré par un répartiteur sensible au type (extraction de schéma pour les données structurées, analyse structurelle pour le code, résumé par LLM pour le texte), permettant au modèle de raisonner sur le fichier sans le charger. Les ID de fichiers sont propagés à travers le DAG de résumés, garantissant que le modèle conserve la conscience des fichiers rencontrés même après plusieurs rounds de compaction.

4. Récursivité au Niveau Opérateur

Le LCM remplace les boucles écrites par le modèle par des primitives gérées par le moteur :

• LLM-Map : Traite une liste d'éléments en parallèle via des appels LLM sans état (par exemple, classification, extraction).
• Agentic-Map : Lance des sessions de sous-agent complètes pour chaque élément, adaptées au raisonnement multi-étapes ou à l'utilisation d'outils.
• Garanties : Le moteur gère l'itération, la concurrence, les nouvelles tentatives et la validation du schéma. Les sorties sont stockées dans des fichiers JSONL externes, empêchant la pollution du contexte.
• Invariant de Réduction de Portée : Pour prévenir les boucles de délégation infinies, un sous-agent doit déclarer quel travail il conserve par rapport à ce qu'il délègue. Si un agent tente de déléguer l'intégralité de sa responsabilité, le moteur rejette l'appel. Cette garantie structurelle assure la terminaison sans limites de profondeur arbitraires.

Contributions Clés

1. Changement Architectural : Le LCM déplace la gestion du contexte d'un processus stochastique généré par le modèle (RLM) vers un processus déterministe géré par le moteur. Cela reflète le changement historique des instructions GOTO non restreintes vers un flux de contrôle structuré dans les langages de programmation.
2. Récupérabilité Sans Perte : Contrairement au RAG ou aux fenêtres glissantes, le LCM garantit que n'importe quel état antérieur peut être récupéré à l'identique via le stockage immutable, indépendamment du nombre de compressions du contexte.
3. Continuité à Coût Zéro : L'architecture n'encourt aucune surcharge de latence ou de coût pour les tâches courtes qui tiennent dans la fenêtre de contexte native, répondant à une inefficacité clé des échafaudages récursifs.
4. Convergence Déterministe : Le protocole d'escalade à trois niveaux et l'invariant de réduction de portée fournissent des garanties mathématiques contre l'échec de compaction et la récursion infinie, respectivement.

Résultats

Les auteurs ont évalué le LCM (implémenté dans l'agent Volt) par rapport à Claude Code (v2.1.4) et à l'Opus 4.6 brut sur le benchmark OOLONG (spécifiquement le split trec_coarse), testant des longueurs de contexte de 8K à 1M de tokens.

• Performance : Volt (LCM) a obtenu un score absolu moyen de 74,8, surpassant les 70,3 de Claude Code de 4,5 points.
• Sensibilité à la Longueur du Contexte :
  • < 32K tokens : Volt et Claude Code ont performé de manière comparable, Claude Code ayant un léger avantage sur les longueurs plus courtes.
  • > 32K tokens : Volt a constamment surpassé Claude Code. L'écart s'est considérablement élargi dans le régime ultra-long :
    • À 256K tokens : Volt menait de 10,0 points.
    • À 512K tokens : Volt menait de 12,6 points.
    • À 1M tokens : Volt menait de 4,3 points.
• Dégradation de la Base : Opus 4.6 brut sans échafaudage a montré une dégradation raide au-delà de 65K tokens, tombant en dessous d'un score de 20 aux plus grandes longueurs.
• Mécanisme : L'avantage de performance est attribué à l'utilisation par le LCM de LLM-Map pour l'agrégation parallèle, évitant la saturation du contexte. En revanche, Claude Code repose sur le modèle pour concevoir des stratégies de découpage, ce qui introduit une variance d'erreur et une charge cognitive à mesure que le contexte grandit.

Signification et Revendications

L'article revendique que le LCM représente une vindicte et une extension du paradigme récursif pionnier des RLM. Il démontre que la manipulation récursive du contexte peut surpasser non seulement les LLM conventionnels, mais aussi les agents de codage de pointe avec accès natif au système de fichiers (comme Claude Code).

Les auteurs soutiennent que le LCM offre un compromis supérieur pour les environnements de production :

• Fiabilité sur la Flexibilité : En sacrifiant la flexibilité maximale des boucles écrites par le modèle, le LCM gagne des garanties de terminaison, une continuité à coût zéro et une récupérabilité d'état sans perte.
• Viabilité de Production : Les primitives déterministes permettent le déploiement immédiat d'architectures à contexte infini sans attendre que les modèles maîtrisent la méta-compétence de gérer leur propre mémoire.
• Complémentarité : Les auteurs suggèrent que le LCM et les RLM ne sont pas mutuellement exclusifs ; un système futur pourrait utiliser par défaut les opérateurs structurés du LCM pour les cas courants tout en conservant la récursivité symbolique de style RLM pour les tâches exceptionnelles nécessitant une flexibilité maximale.

L'article conclut que le point de vue « Centrée sur l'Architecture » (fournir des primitives structurées) génère des avantages en termes de fiabilité et de coûts pour les charges de travail d'agrégation de production, particulièrement à mesure que les longueurs de contexte dépassent les capacités des fenêtres de modèles bruts actuelles.