Comment les RLM dépassent les limites des context windows
Les LLM classiques plafonnent entre 150K et 800K tokens effectifs, même si certains annoncent 1 M ou 10 M. GPT-5.2 gère 400K (250K effectifs), Claude Opus 4.5 atteint 200K (150K), Gemini 3 Pro monte à 1 M (800K) et Llama 4 Scout s’approche de 10 M (8 M effectifs). Pour un CTO, ces limites se traduisent en analyses partielles, hallucinations et coûts exponentiels. Ce phénomène appelé “context rot” se manifeste par une dégradation de la qualité au fur et à mesure que le prompt s’allonge, et il varie en fonction de la complexité de la tâche : sur OOLONG (tâche linéaire) et OOLONG-Pairs (tâche quadratique), GPT-5 chute brutalement dès 16K-33K tokens, tandis que sur S-NIAH (needle-in-a-haystack à complexité constante), il reste robuste jusqu’à 1M tokens.
Du standard transformer au framework récursif
MIT CSAIL a dévoilé un paradigme complémentaire aux transformers : les Recursive Language Models (RLM). Plutôt que de tout charger en mémoire, le RLM découpe le corpus en chunks, le stocke en externe et le modèle racine (le modèle qui pilote) génère du code Python qui appelle récursivement llm_query(). Chaque appel produit un résumé compressé porté vers l’appel suivant, jusqu’à fusion hiérarchique des résultats. Plus précisément, le RLM initialise un environnement REPL persistant dans lequel le prompt P est chargé comme variable, et seule une métadonnée de taille constante (longueur, court préfixe, méthode d’accès) est transmise au modèle racine (jamais le prompt entier). À chaque itération, le modèle écrit du code, observe `stdout`, et la boucle s’arrête uniquement quand la variable `Final` est définie dans le REPL.
Les trois choix de design qui distinguent les RLM des autres scaffolds
Le papier insiste sur trois propriétés essentielles que les approches concurrentes (`CodeAct`, `ReAct`, `summary agents`, `sub-agent delegation`) ne combinent jamais simultanément :
- Handle symbolique sur le prompt : le LLM ne reçoit jamais P directement, ce qui élimine la dépendance à la fenêtre de contexte du modèle de base.
- Pas de sortie autorégressive imposée : le modèle peut construire des réponses arbitrairement longues en stockant des fragments dans des variables, puis en les concaténant programmatiquement, dépassant ainsi la limite de tokens de sortie du LLM.
- Récursion symbolique : le code dans l’environnement peut invoquer le LLM dans des boucles arbitrairement larges, autorisant un nombre linéaire de sous-appels (proportionnel à la taille du prompt) ou même quadratique (proportionnel à son carré), chose impossible avec les délégations verbales d’agents de type Claude Code ou THREAD.
Scalabilité et économies radicales
Ce découpage hiérarchique permet de franchir la barre des 10 M de tokens (soit l’équivalent de 20–25 romans, plusieurs codebases ou centaines de papiers) tout en conservant un état mémoire constant. Selon Dmitry Labintcev, développeur du RLM-Toolkit, cette méthode entraîne une baisse de coûts de 80–90 % : les coûts passent de 15–30 $ par analyse large à seulement 1–3 $.
Mécanismes clés du cadre récursif MIT
Génération de code et appels llm_query
Le modèle produit du code Python pour explorer le fichier de données via la fonction `llm_query()`, agissant comme un REPL externe. Chaque invocation traite un chunk, détecte les patterns et renvoie un résumé intermédiaire. Le processus se répète jusqu’à produire un FINAL(answer) global. Dans l’implémentation MIT, le LLM dispose en réalité de deux balises distinctes : FINAL(response) pour renvoyer une chaîne directement, et FINAL_VAR(variabl_name) pour renvoyer le contenu d’une variable construite dans le REPL — c’est ce second mécanisme qui permet de produire des sorties arbitrairement longues, en accumulant les résultats de sous-appels dans une variable Python avant retour final.
Compression d’état et fusion hiérarchique
Au lieu de recharger tout le prompt, seules les métadonnées de stdout (préfixe court et longueur) sont transmises au modèle racine pour l’itération suivante, l’état complet restant stocké comme variables dans le REPL. Cette approche réduit le contexte rot et assure des performances stables au-delà de plusieurs millions de tokens. Plus précisément, le mécanisme repose sur trois patterns émergents observés dans les trajectoires : (1) chunking par newlines ou marqueurs sémantiques pour les contextes denses comme OOLONG, (2) filtrage par regex basé sur les priors du modèle (ex : RLM(GPT-5) cherche « festival », « La Union » dans BrowseComp-Plus avant tout sous-appel), et (3) accumulation de sous-résultats dans des buffers variables pour reconstituer une réponse longue.
Performance et coût : un nouveau ratio
Baisse de coûts de 80–90 %
En mode classique, l’input coûte environ 0,10 $ par million de tokens et l’output 0,40 $ par million. Avec 20 $ de budget et un ratio 5:1, un LLM classique permet de traiter 111,1 M de tokens en input pour 22,2 M output. En RLM, ce même budget couvre 166,7 M input et 8,3 M output grâce à la compression et aux appels ciblés.
Benchmarks long-context
Un modèle de 8 milliards de paramètres, grâce à cette architecture, surpasse les plus grosses configurations de 28,3 % sur tâches long-context. Sur des challenges complexes, la précision monte de moins de 1 % à plus de 58 %.
Enjeux et perspectives pour les CTO
Risques techniques et complexité
Si la scalabilité à 10 M+ est prouvée (jusqu’à 11M sur BrowseComp-Plus), la performance reste dépendante de la qualité du chunking, des résumés et de la gestion des erreurs cumulées. La génération de code ajoute un overhead qu’il faut optimiser pour éviter les latences.
Modèle vs scaffold : un trade-off à anticiper
Sur les contextes courts (8K tokens), un LLM de base bat son équivalent RLM. La récursion introduit un overhead de raisonnement non productif quand la tâche tient déjà nativement dans la fenêtre. Le RLM n’est donc pas une solution universelle, mais une stratégie à activer dynamiquement au-delà d’un seuil de complexité (taille de prompt × densité d’information). Une bonne architecture combinera probablement les deux : LLM direct sur petits prompts, bascule en RLM au-delà d’un threshold
Adoption et ROI attendu
À l’horizon 2026, les LLM long-context domineront les usages documentaires et RLM deviendra le paradigme post-RAG avec un toolkit open-source déjà disponible. Pour un CTO, investir dans le framework récursif, c’est multiplier la fenêtre contextuelle, réduire fortement la facture cloud et améliorer la fiabilité des extractions d’informations sur de larges corpus.