Modèles de langage récursifs (Recursive Language Models)

• Une nouvelle stratégie de raisonnement RLM (Recursive Language Model) a été proposée pour permettre aux grands modèles de langage (LLM) de traiter des prompts d’entrée très longs
• RLM considère les longs prompts comme une partie de l’environnement externe et permet au modèle de les explorer, décomposer et appeler récursivement de manière programmatique
• Cette approche dépasse les limites de la fenêtre de contexte et traite des entrées allant jusqu’à plusieurs dizaines de millions de tokens, avec une forte amélioration de la qualité par rapport aux LLM existants
• Les résultats expérimentaux montrent que les RLM basés sur GPT-5 et Qwen3-Coder affichent des gains de performance à deux chiffres sur diverses tâches longues, pour un coût comparable ou inférieur
• Elle est considérée comme une approche générale capable d’élargir fortement les capacités de raisonnement des LLM en surmontant les limites du traitement de longs contextes

---

Vue d’ensemble de RLM

• Recursive Language Model (RLM) est conçu pour que le LLM n’injecte pas directement une longue entrée dans le réseau neuronal, mais la traite comme une variable de l’environnement externe avec laquelle il interagit
  • Le prompt d’entrée P est chargé comme variable dans un environnement Python REPL, et le LLM l’explore, le décompose et l’appelle récursivement via du code
  • Le LLM perçoit l’état de l’environnement REPL (par ex. la longueur d’une chaîne), observe les effets de bord de l’exécution du code et résout progressivement le problème
• Cette structure résout le problème de perte de détails des approches classiques de compaction du contexte ou basées sur le résumé
• RLM est présenté comme un paradigme général de raisonnement capable d’étendre à la fois la longueur des entrées et celle des sorties

Limites des approches existantes

• Les LLM existants montrent un phénomène de context rot, avec une forte dégradation des performances sur les longues entrées à cause des limites de la fenêtre de contexte
• Les techniques de compaction du contexte répètent les résumés au-delà d’une certaine longueur, mais elles sont inadaptées aux tâches nécessitant un accès fin à l’information
• RLM traite le prompt comme un objet externe, ce qui permet d’étendre la taille d’entrée au-delà des limites du modèle

Configuration expérimentale

• Modèles évalués : GPT-5 (OpenAI, 2025) et Qwen3-Coder-480B-A35B (Team, 2025)
• Méthodes comparées :
  • appel direct du LLM de base
  • agent de résumé (Summary agent)
  • agent basé sur la recherche CodeAct + BM25
  • RLM (avec environnement REPL) et RLM (REPL, sans appels récursifs)
• Dans les expériences GPT-5, GPT-5-mini est utilisé pour les appels récursifs et GPT-5 comme modèle racine afin d’équilibrer performances et coûts

Tâches d’évaluation

• S-NIAH : problème unique de type « needle-in-a-haystack », avec un coût de traitement constant quelle que soit la longueur d’entrée
• BrowseComp-Plus : tâche de questions-réponses multi-hop à travers plusieurs documents, la bonne réponse étant incluse parmi 1000 documents
• OOLONG : tâche de raisonnement long nécessitant une transformation et une intégration sémantique de presque tous les éléments de l’entrée, avec un coût de traitement linéaire en fonction de la longueur d’entrée
• OOLONG-Pairs : variante d’OOLONG nécessitant une combinaison d’informations par paires, avec un coût de traitement quadratique par rapport à la longueur d’entrée
• LongBench-v2 CodeQA : tâche à choix multiple demandant une compréhension d’un dépôt de code, difficile même pour les modèles récents

Principaux résultats

• RLM ne montre quasiment aucune dégradation par rapport à GPT-5, même sur de longs contextes
  • GPT-5 voit ses performances chuter fortement à mesure que la longueur d’entrée et la complexité de la tâche augmentent
  • RLM traite efficacement des entrées dépassant la limite de 272K tokens (jusqu’à plus de 10M de tokens)
• Sur toutes les tâches longues, RLM obtient des gains de performance à deux chiffres par rapport aux autres méthodes
• L’efficacité en coût est également maintenue, avec un coût par requête comparable, voire inférieur, aux approches existantes

Analyse de la complexité des tâches longues

• La fenêtre de contexte effective d’un LLM peut être plus courte que sa limite physique selon la complexité de la tâche
  • Un problème NIAH simple peut être résolu même avec plus de 1M de tokens
  • Des tâches plus complexes de type OOLONG voient leurs performances baisser dès des longueurs bien plus modestes
• Il faut donc considérer ensemble la densité d’information de la tâche et sa corrélation avec la longueur d’entrée

Conclusion

• RLM étend récursivement les capacités de raisonnement des LLM, ce qui permet de traiter des entrées extrêmement longues que les modèles existants ne peuvent pas gérer
• Le choix de conception qui traite le prompt comme un objet de l’environnement constitue l’innovation clé et résout les limites structurelles du traitement de longs textes
• Il est présenté comme un cadre général de raisonnement atteignant un équilibre entre performance, coût et passage à l’échelle sur différents modèles et tâches

[GN⁺]

Avis sur Hacker News

• Ça ressemble simplement au concept de subagent
  Autrement dit, on appelle un autre LLM pour lire des fichiers et en extraire les informations nécessaires afin de ne pas surcharger le contexte principal
  L’idée est bonne, mais ce n’est pas totalement nouveau

  • Je le vois davantage comme un moyen de gestion du contexte que comme un subagent anthropomorphisé à la manière humaine
    En ce moment, sur le projet Scope, on expérimente des subagents observables qui décomposent les tâches de manière récursive
    En revanche, je ne sais pas comment améliorer cette évaluation de l’étape de planification
    On consigne les heuristiques dans des fichiers Markdown, mais la structure est trop lâche pour permettre une mesure fiable
    Si quelqu’un connaît des publications ou des projets liés à ça, je serais preneur
  • Le papier dit ceci
    Un RLM n’est ni un agent ni un résumé
    Utiliser plusieurs appels à des LM dans un même système n’est pas une idée nouvelle, et c’est ce que font la plupart des agentic scaffolds
    L’exemple le plus proche serait ROMA agent, qui décompose un problème pour le résoudre avec plusieurs sub-agents
    De même, des assistants de code comme Cursor ou Claude Code résument ou élaguent quand le contexte devient trop long
    Ce type d’approche découpe généralement par unités de travail, tandis que RLM met l’accent sur une décomposition par unités de contexte, et considère que ce choix doit être décidé par le LM lui-même
  • À voir le titre, on pourrait croire que tout le calcul est differentiable et entraîné comme un seul modèle, mais en réalité cela ressemble simplement à des appels répétés au modèle
  • Si un subagent ne peut pas appeler un autre subagent à l’infini, on ne peut pas vraiment dire que c’est récursif
  • On semble parler d’un concept de sub-agent qui accède au même contexte (système de fichiers ou variables REPL) et le manipule

• L’intuition clé est qu’il ne faut pas injecter directement de longs prompts dans le réseau de neurones (Transformer), mais les traiter comme une partie d’un environnement avec lequel le LLM peut interagir symboliquement
  Cela dit, je me demande en quoi cela diffère fondamentalement du RAG
  À voir la figure 4, la différence semble être que c’est le LLM lui-même, et non un humain, qui implémente directement le mécanisme de retrieval

  • Pour moi, il y a deux différences
    1️⃣ Le RAG se rapproche davantage d’un workflow, tandis que ceci est plus agentic
    2️⃣ Il y a une structure récursive
    Dans un workflow, c’est un humain qui conçoit le flux étape par étape, alors que dans une approche agentic, l’agent décide lui-même quoi chercher, combien de fois appeler, et quand répondre
    Par exemple, Claude Code ou Codex explorent une base de code en lisant des fichiers et en lançant ripgrep
    Ce genre d’essais récursifs existait déjà auparavant (par ex. babyagi, vers 2023), mais les modèles de l’époque n’étaient pas assez performants, donc il fallait beaucoup de glue code
    Maintenant, les modèles sont suffisamment puissants pour que cette structure fonctionne réellement

• Comme dans la blague « T̶u̶r̶t̶l̶e̶s̶ LLMs all the way down », cela suggère une structure où des LLM appellent des LLM indéfiniment

  • C’est une application répétée de « attention is all you need », et au final ce que nous devrions viser, c’est la précision (precision)

• Il existe une version plus facile à lire de l’article : billet de blog d’alexzhang13

• Ce que j’aimerais voir en 2026, c’est qu’Anthropic ou OpenAI révèlent aux créateurs de plugins CLI « comment la compaction est exécutée »
  Cette technique pourrait remplacer une fonctionnalité intégrée à Claude Code, mais actuellement les hooks ou fonctionnalités appropriés ne sont pas exposés

  • Si Codex est open source, on ne peut pas simplement aller le lire ?
    J’ai regardé le code de Gemini, et la structure du prompt consistait simplement à résumer l’ensemble quand la fenêtre de contexte était pleine

• Cela semble similaire à ce papier : arXiv:2510.14826