λ-RLM — du λ-calcul pour fiabiliser le raisonnement des LLM

En bref

λ-RLM (Lambda Recursive Language Model) est une architecture qui remplace la génération libre de code par une bibliothèque de combinateurs fonctionnels pré-vérifiés, inspirée du λ-calcul. Sur 9 modèles et 4 tâches à contexte long, elle gagne en moyenne +21,9 points de précision et réduit la latence de 3,1× à 6,2× par rapport à l’approche RLM standard. Un modèle 8B sous λ-RLM surpasse en précision un modèle 405B en inférence directe — soit 50× moins de paramètres pour de meilleures performances sur les tâches ciblées.

Le problème : la dégradation exponentielle sur les longs contextes

Imaginez un lecteur humain à qui l’on demande de retenir intégralement un livre de 1 000 pages avant de répondre à une question portant sur trois lignes au chapitre 7. Plus le volume à mémoriser augmente, plus la probabilité de manquer la ligne décisive grandit. Un LLM long-contexte se comporte de manière analogue, sauf que la dégradation est mathématiquement formalisable.

Quand un LLM reçoit un prompt très long, ses performances chutent. Ce phénomène est souvent décrit de façon informelle, mais le paper λ-RLM lui donne une formulation mathématique précise : A(n) = A₀ · ρ^(n/K), où n est la longueur du prompt, K la fenêtre de contexte du modèle, et ρ un paramètre de dégradation compris entre 0 et 1.

La conséquence directe : la précision décroît exponentiellement à mesure que le prompt grossit, et tend vers zéro quand n → ∞. Cette décroissance exponentielle est la propriété mathématique qui justifie le terme context rot — le contexte “pourrit” progressivement.

La solution habituelle consiste à injecter toujours plus de contexte dans la fenêtre du modèle. Mais l’expérience montre que remplir la fenêtre avec du contenu non pertinent n’aide pas : c’est la structure de traitement, pas le volume d’information, qui détermine les performances.

En clair : plus on charge le modèle de pages, moins il se souvient correctement de ce qu’il y a dedans, et la chute de précision suit une loi exponentielle — pas linéaire. Doubler le contexte coûte beaucoup plus que la moitié de la précision finale.

L’approche RLM : décomposer récursivement

Les Recursive Language Models (RLM), introduits par Zhang et al. (arXiv:2512.24601), attaquent ce problème autrement. Au lieu d’injecter un prompt géant dans la fenêtre du modèle, ils décomposent le problème en sous-problèmes de taille bornée, résolvent chaque sous-problème indépendamment, puis agrègent les résultats.

L’architecture s’appuie sur un environnement d’exécution externe (REPL) qui stocke le prompt sans l’injecter dans la fenêtre de contexte. Le LLM génère du code Python pour orchestrer la décomposition, exécute ce code dans le REPL, et itère jusqu’à obtenir une réponse.

Le résultat théorique est notable : sous cette architecture, la précision décroît non plus exponentiellement mais en puissance de loi — soit une dégradation strictement plus lente que l’inférence directe.

Le problème pratique : le LLM génère lui-même le code de contrôle. Ce code peut être incorrect, produire des boucles infinies, ou varier d’une exécution à l’autre. RLM standard itère typiquement 5 à 12 tours de code LLM-généré pour une seule tâche.

λ-RLM : remplacer le code libre par des combinateurs formels

λ-RLM conserve l’architecture RLM mais remplace la génération libre de code par une bibliothèque fermée de combinateurs déterministes et pré-vérifiés :

• SPLIT — partitionner un input en chunks de taille k*
• PEEK — inspecter un chunk localement sans traitement complet
• MAP — appliquer récursivement une fonction à chaque chunk
• FILTER — sélectionner des éléments selon un critère symbolique
• REDUCE — agréger les résultats de plusieurs branches
• CONCAT — concaténer des séquences
• CROSS — calculer le produit cartésien de deux ensembles
• M — le seul opérateur neural : appel au LLM sur un chunk de taille bornée (≤ τ*)

Tous les combinateurs sauf M sont déterministes et exécutés symboliquement, sans appel au LLM. M est l’unique point d’incertitude du système.

L’exécuteur récursif central suit la structure du Y-combinateur du λ-calcul : si le prompt tient dans la fenêtre (|P| ≤ τ*), appeler M directement ; sinon, SPLIT en chunks de taille k*, appliquer MAP récursivement, puis REDUCE pour agréger.

La terminaison est garantie par construction — elle ne dépend pas du comportement du LLM, contrairement à la boucle while ouverte de RLM standard. Le nombre total d’appels au modèle est calculable avant l’exécution : pour un contexte de 128K tokens avec une fenêtre de 8K, cela représente 17 appels M en 4 niveaux de récursion.

En clair : RLM standard demande au modèle d’écrire lui-même le code qui orchestre la décomposition — code qui peut boucler ou planter. λ-RLM remplace ce code par 8 briques fixes pré-vérifiées, dont une seule (M) parle au modèle. Le reste s’exécute mécaniquement, comme un assemblage de pièces Lego. On sait à l’avance combien de fois le modèle sera appelé.

Résultats expérimentaux : précision et latence

Les auteurs évaluent λ-RLM sur 4 tâches à contexte long (benchmark OOLONG) et 9 modèles couvrant trois niveaux de capacité (faibles, médians, forts).

Précision :

λ-RLM gagne 29 comparaisons sur 36 contre RLM standard (81% overall). L’avantage est maximal sur les modèles faibles, où la “coding tax” — le surcoût cognitif lié à la génération de code d’orchestration — est la plus lourde : 12/12 comparaisons gagnées sur les modèles weak-tier. Sur les modèles forts, l’avantage tombe à 6/12.

Sur la tâche OOL-Pairs (complexité O(n²)), λ-RLM gagne +28,6 points de précision avec 6,2× de speedup. Le produit cartésien quadratique est traité symboliquement par l’opérateur CROSS — coût neural nul — là où RLM standard doit le calculer neuralement.

Un résultat marquant : Llama-8B sous λ-RLM atteint 35,7% de précision contre 27,2% pour Llama-405B en inférence directe. Le même 8B égale un 70B sous RLM standard (35,7% vs 36,1%) tout en étant 3,1× plus rapide (57 s contre 177 s).

Latence :

La réduction de latence provient mécaniquement de la suppression des boucles de génération de code. RLM standard itère 5–12 tours ; λ-RLM exécute une unique chaîne de combinateurs pré-construite. Le ratio de variance de latence est également réduit : de 8,9× (RLM normal) à 4,3× (λ-RLM), ce qui améliore la prévisibilité en production.

En clair : un modèle 50× plus petit fait mieux qu’un modèle géant en inférence directe sur ces tâches structurées, parce qu’il n’a pas à porter tout le contexte en mémoire — il l’aborde par morceaux. La méthode est jusqu’à 6,2× plus rapide quand la tâche permet un calcul symbolique pur (CROSS, REDUCE).

Ce que révèlent les ablations

Quatre ablations identifient les leviers de performance :

• A4 — remplacer la bibliothèque par de la génération libre : −24,2 points de précision et ×3,9 de latence. C’est le contributeur unique le plus important à l’avantage de λ-RLM.
• A1 — taille de chunk aléatoire au lieu du k* optimal calculé par le théorème : −16,8 points. Le calcul analytique de k* = 2 produit un bénéfice mesurable.
• A3 — composition ⊕ neural (via LLM) au lieu de symbolique : −4,7 points seulement, mais la latence presque double (62 s → 108 s). La composition symbolique est le levier principal de réduction de latence.

Quand utiliser λ-RLM

Forces et limites

Forces :

• Terminaison garantie par construction, indépendante du comportement du LLM.
• Latence prévisible avant exécution grâce au calcul analytique du nombre d’appels M.
• Avantage maximal pour les modèles de taille modeste sur les tâches structurées à contexte long.
• Réduction des deux sources d’incertitude de RLM standard à une seule (le jugement sémantique du modèle).

Limites :

• Bibliothèque fixe : les 7/36 cas où RLM standard surpasse λ-RLM impliquent tous des modèles forts ou la tâche CodeQA, où la navigation créative de code (backtracking, chunking par fonction) nécessite une expressivité que les combinateurs pré-vérifiés ne permettent pas.
• Décomposabilité requise : l’architecture suppose que les tâches sont décomposables en sous-problèmes indépendants. Pour les tâches à dépendances croisées entre chunks, la garantie de performance ne tient pas.
• Capacité de codage résiduelle : le scaffold réduit mais ne supprime pas l’effet de la capacité de codage du modèle de base. Sous λ-RLM, Mistral-7B atteint 28,7% contre 44,6% pour Codestral-22B — un écart de 16 points (réduit depuis 28 points sous RLM standard, mais non éliminé).
• Alternative concurrente : Alizadeh et al. (2026) montrent qu’une sélection par uncertainty-aware self-reflection sur des programmes librement générés peut être compétitive, notamment pour les tâches créatives de code. Les deux approches coexistent avec des trade-offs différents.

Ce qu’il faut retenir

• λ-RLM remplace la génération libre de code d’orchestration par des combinateurs déterministes empruntés au λ-calcul. Seul l’opérateur M (appel au LLM) reste stochastique.
• La terminaison est garantie par construction : le nombre d’appels au modèle est calculable avant toute exécution.
• Un modèle 8B sous λ-RLM surpasse un modèle 405B en inférence directe sur les tâches long-contexte testées, avec 3,1× moins de latence qu’un 70B sous RLM standard.
• L’avantage disparaît sur les tâches de code créatif et les modèles à forte capacité de codage — la bibliothèque fixe de combinateurs ne couvre pas tous les cas.
• La formalisation mathématique du context rot (A(n) = A₀ · ρ^(n/K)) permet pour la première fois de comparer analytiquement les régimes de dégradation selon l’architecture.