Des chercheurs de Google, Google DeepMind, l'Université du Maryland et l'Université de Virginie ont publié Dream-RSI, un article sur arXiv, avec le code sur GitHub et un site dédié. L'idée sur laquelle il repose est réellement élégante. Quand un agent consomme des milliers d'appels à la recherche d'un algorithme plus rapide, l'arbre de tout ce qu'il a essayé — chaque tentative, son parent, l'instantané de son espace de travail, son score — n'est pas seulement un journal. C'est un simulateur gratuit de la portion de l'espace de recherche réellement visitée. Exécutez une stratégie de recherche différente à l'intérieur de cet arbre enregistré, révélez les résultats déjà stockés le long des branches qu'elle choisit, et vous savez comment cette stratégie s'en serait tirée sans appeler l'agent de codage ni exécuter une seule ligne de code. Les auteurs appellent cela « rêver » (dreaming), en référence à la lignée Dreamer d'apprentissage par renforcement fondé sur un modèle, et s'en servent pour améliorer la stratégie de recherche elle-même, ronde après ronde.
Le mécanisme est astucieux et les résultats sur les noyaux GPU le soutiennent solidement. Le cadrage qui l'entoure, et l'un des deux chiffres phares, demandent plus de précautions que l'article n'en prend.
Ce qui s'auto-améliore ici, c'est un ordonnanceur
À préciser avant toute chose, car « auto-amélioration récursive » figure dans le titre et ce terme porte une charge considérable depuis un mois. La boucle de Dream-RSI modifie exactement un artefact : le code d'une politique d'exploration — un petit programme qui, à chaque ronde, examine l'arbre de découverte courant et décide de quelles feuilles poursuivre, combien de tentatives lancer en parallèle, s'il faut ouvrir une nouvelle branche depuis la racine, et quand s'arrêter. L'article trace lui-même la frontière, en une phrase : « Seul le code de la politique d'exploration change ; les modèles sous-jacents, l'évaluateur et les interfaces d'exécution restent fixes. »
C'est une revendication bien plus étroite que celle de l'annonce AIRA₃ de Meta, et plus étroite encore que l'essai de Z.ai sur son Infra Agent couvert ici ce matin. Cette étroitesse est une qualité — un programme d'ordonnancement qui se réécrit lui-même est un objet bien défini, donc mesurable. Mais cela signifie que le composant qui s'améliore est un ordonnanceur de recherche, et que le titre, le résumé et la conclusion de l'article reprennent tous le terme large sans une seule phrase reconnaissant l'écart. Après tout un rapport dans lequel OpenAI distinguait un « stagiaire de recherche automatisé » de la RSI complète, un article qui applique l'étiquette sans réserve à un script d'ordonnancement par lots est un petit indice de la vitesse à laquelle le terme se dévalue.
Le simulateur de rejeu porte un plafond dans sa définition même
La mécanique mérite d'être détaillée, car elle borne ce que le rêve peut enseigner. En rejeu, quand la politique sélectionne un nœud, le simulateur renvoie l'enfant enregistré de ce nœud — de façon déterministe, sans nouvelle génération. Sélectionner la racine révèle la plus ancienne branche enregistrée encore non ouverte. Quand un nœud n'a plus de continuation enregistrée, rien n'est renvoyé. L'article est explicite : « aucun résultat au-delà de l'arbre enregistré n'est généré ».
Une politique alternative dans un monde de rejeu peut donc faire exactement quatre choses différemment : parcourir un sous-ensemble différent de branches, les parcourir dans un ordre différent, les regrouper en lots parallèles différents, et s'arrêter à un point différent. Chaque nœud qu'elle voit a été produit par l'ancienne politique. Le rêve peut ainsi découvrir qu'il aurait fallu s'arrêter à la tentative 50 plutôt qu'à la 110, ou que trois branches méritaient d'être groupées — il ne peut jamais dire ce qu'aurait produit une branche que personne n'a ouverte. Structurellement, c'est donc une boucle d'efficacité, pas une boucle de capacité : elle apprend à dépenser moins dans l'espace de recherche dont elle dispose déjà, pas à atteindre un espace dont elle ne dispose pas. L'article ne prétend pas le contraire, mais il ne pose jamais la limite non plus, et la différence compte pour qui lit l'étiquette RSI au pied de la lettre.
Il y a une seconde conséquence, plus subtile. L'objectif de rejeu contre lequel la politique est optimisée est défini comme le meilleur score atteint, moins une pénalité sur le nombre de tentatives, plus un bonus pour les tentatives par ronde. La réduction du coût est inscrite dans le signal d'apprentissage — dire que « Dream-RSI réduit le coût de découverte » revient donc en partie à constater que l'optimiseur a optimisé son objectif, ce qui est plus faible qu'il n'y paraît.
La garantie d'amélioration est calculée sur les données d'entraînement, et la corrélation qui compte n'est jamais rapportée
La seule garantie formelle de Dream-RSI est que la politique de la ronde suivante n'obtient pas un score inférieur à l'actuelle, puisque l'actuelle fait partie de l'ensemble de candidates parmi lesquelles la sélection s'opère. C'est exact — mais la sélection porte sur le score de rejeu moyen sur l'historique fixé, et les politiques candidates ont été écrites par un agent de développement LLM qui a vu les trajectoires et les scores de rejeu de ces mêmes mondes. C'est une sélection sur l'ensemble d'entraînement. Il n'y a pas de mondes de rejeu tenus à l'écart, pas de séparation entraînement/test entre arbres, et aucune vérification rapportée que la politique gagnante en rejeu gagne effectivement en ligne.
Cette dernière omission est la plus importante. Toute la prémisse de l'article est que le score de rejeu est un substitut peu coûteux du résultat en ligne. Le seul chiffre qui validerait cette prémisse — la corrélation entre le score de rejeu d'une politique et sa performance en ligne ultérieure, que chaque ronde de chaque expérience produit gratuitement — n'apparaît nulle part. Les résultats empiriques plaident pour le système de bout en bout ; ils n'isolent pas la qualité du substitut.
Également absentes : les valeurs des hyperparamètres de la méthode. Le nombre de révisions de politique par ronde, les deux coefficients de l'objectif et les deux limites de rondes sont nommés symboliquement et jamais chiffrés. Et la comptabilité des coûts exclut entièrement la phase de rêve — le « coût de découverte » ne compte que les appels à l'agent de découverte, de sorte que les appels LLM de l'agent de développement de politique, que la référence à exploration fixe ne passe pas du tout, restent hors de tous les budgets rapportés. Le rejeu n'exécute aucun code, mais écrire et évaluer des politiques candidates n'est pas gratuit, et les « milliers de politiques candidates » de la figure 2 cadrent mal avec une section méthodologique décrivant une boucle séquentielle où chaque révision attend le retour de la précédente.
Le résultat phare sur le Lasso tient à un choix de moyenne — sur l'un des deux modèles
C'est le résultat que l'article met en avant, et il demande à être déplié. La tâche consiste à découvrir un solveur rapide pour le chemin de régularisation du Lasso ; le tableau de bord donne les temps d'exécution sur six jeux de données de validation, plus bas étant meilleur. Face à sa propre référence contrôlée (Recursive Fixed Exploration — même agent, même évaluateur, même politique initiale, politique gelée d'une ronde à l'autre), Dream-RSI avec Gemini 3.1 Pro rapporte 2931,0 ms de moyenne contre 3587,1 ms, avec 317 appels à l'agent de découverte au lieu de 550.
Lisez les six colonnes plutôt que la moyenne, et cette exécution s'inverse. Le solveur Pro de Dream-RSI est plus lent que celui de l'exploration fixe sur cinq des six jeux de données de validation — Gisette 2841,0 contre 1861,8, DNA 49,9 contre 41,5, Leukemia 30,2 contre 26,1, Colon 16,4 contre 14,5, Duke Breast 32,5 contre 28,4. Il ne gagne que sur un seul : RCV1, 14 616,0 contre 19 550,1. RCV1 représente à lui seul environ 91 % de la somme des temps de la référence : la moyenne arithmétique de six nombres étalés sur quatre ordres de grandeur n'est donc, en pratique, que la colonne RCV1 déguisée. L'article remarque le phénomène et décrit le solveur Pro comme « particulièrement adapté aux matrices à grande échelle telles que RCV1 » — sans relier cette observation à la moyenne construite par-dessus.
Le choix de l'agrégation n'est pas non plus arbitraire, et c'est ce qui rend la remarque nécessaire plutôt que pointilleuse. Le score de recherche du benchmark lui-même, défini dans l'annexe de l'article, est une moyenne géométrique sur les instances de chronométrage — le correctif standard pour exactement ce problème, et la règle contre laquelle le système optimise pendant la découverte. Appliquez cette même règle aux six colonnes de validation et la comparaison Pro s'inverse : environ 179 pour Dream-RSI contre 159 pour l'exploration fixe, soit environ 13 % de moins bon. Le résultat phare ne survit que sous la moyenne arithmétique adoptée pour le tableau final.
L'exécution avec Gemini 3.7 Flash raconte une autre histoire et mérite d'être distinguée. Là, Dream-RSI est plus rapide sur cinq des six jeux de données, et gagne sous les deux agrégations — 2350,6 contre 2516,7 en arithmétique, et environ 118 contre 128 en géométrique, avec 1879 appels contre 3200. C'est un vrai résultat. C'est aussi celui que l'article mentionne en second.
« 162× moins d'appels » compare deux systèmes différents
L'autre chiffre du résumé est une réduction « jusqu'à 162× » du nombre d'appels d'agent face à SimpleTES. Cette comparaison oppose 317 appels à Gemini 3.1 Pro via la CLI Gemini à 51 200 générations de GPT-OSS-120B : modèle différent, harnais différent et — surtout — unité différente, puisqu'un appel à une CLI de codage agentique enveloppe de nombreux appels de modèle en interne. Quoi que mesure ce 162×, ce n'est pas la politique d'exploration. Le chiffre contrôlé pour cela est 1,7×, face à la référence à politique gelée de l'article, et il est rapporté clairement. Le 162× n'a sa place dans le résumé que comme énoncé sur les agents de frontière face aux petits modèles ouverts, ce qui n'est pas la façon dont il est présenté.
Une bizarrerie dans le même tableau : SimpleTES y figure deux fois, même modèle, même budget de 51 200 générations, avec des moyennes de 3804,8 et 8318,4 — un facteur 2,2 d'écart. La seconde ligne porte une croix (†) que l'article ne définit jamais. La lecture naturelle est qu'il s'agit de la reproduction des auteurs sur leur propre matériel, ce qui en ferait la référence réellement comparable ; si c'est le cas, c'est cette ligne qu'il faudrait comparer, et l'écart entre les deux dépasse la plupart des différences discutées ici.
Les tâches mathématiques sont la partie la plus faible, les noyaux GPU la plus solide
Sur trois problèmes de découverte mathématique, les résultats sont les suivants : somme–différence à 1,145427 contre 1,144047 pour sa propre référence fixe, soit 0,12 % d'amélioration ; empilement de cercles à 2,635983, identique au chiffre à quatre décimales rapporté par AlphaEvolveV2, ShinkaEvolve, TTS-Discovery et SimpleTES, ce qui relève d'un benchmark saturé plutôt que d'un gain ; et inégalités d'autocorrélation à 1,456375, où plus bas est meilleur et où sa propre référence à exploration fixe obtient 1,456001 — une défaite. Le résumé de l'article, « égale ou dépasse des références solides », est exact, le « ou » portant l'essentiel du poids. Le cadrage honnête de cette section est que Dream-RSI atteint la parité avec moins de 1 000 générations là où SimpleTES en utilisait 51 200 : un résultat de coût, pas de qualité.
C'est sur l'ingénierie de noyaux GPU que la démonstration porte vraiment. Sur quatre tâches de KernelBench face à la même référence contrôlée, Dream-RSI atteint une performance comparable avec 2,43× moins de générations sur VGG16 et 1,79× moins sur LayerNorm, et, à budget équivalent, obtient 2,09× et 1,44× de performance en plus sur ConvDiv et ConvMax. Ce sont des marges assez larges pour résister à beaucoup de scepticisme, sur le domaine où l'espace de recherche est le moins saturé. Quatre tâches et un seul modèle sous-jacent, c'est mince, mais c'est la partie de l'article qui fait le vrai travail.
Le résultat le plus intéressant est celui qui a échoué
Enfoui dans la section d'analyse se trouve un résultat négatif qui mérite plus d'attention que l'article ne lui en accorde. Les auteurs ont testé l'usage évident et alternatif de l'historique : résumer les trajectoires passées en intuitions directionnelles de haut niveau et les injecter dans le prompt comme guidage sémantique. Appliqué à la fois à Dream-RSI et à la référence fixe, ce guidage a systématiquement fait moins bien que la version non guidée de chacun. Leur explication : en découverte à long horizon avec de nombreux fils parallèles, des a priori sémantiques forts sur les directions prometteuses sur-contraignent l'espace et étouffent la diversité.
Cela va directement à l'encontre de la direction prise par une bonne partie des travaux sur la mémoire des agents — distiller l'expérience en intuitions, compétences et leçons réutilisables que l'on réinjecte dans le contexte. Il s'agit d'une seule comparaison contrôlée sur une seule tâche, la question n'est donc pas tranchée. Mais « l'historique est plus utile comme environnement où tester des stratégies que comme conseil à suivre » est l'affirmation la plus tranchante de l'article, et c'est la partie la plus susceptible de compter en dehors de ce système.
La trace comportementale est l'autre chose à retenir. Sur neuf rondes sur ConvDiv, la meilleure performance par ronde passe de 0,427 à 1,898, et le profil de dépense de la politique n'est pas monotone : elle réduit d'abord les tentatives évaluées de 110 à 50 tant que les gains viennent facilement, puis remonte l'effort dans la fourchette 80–92 quand les progrès plafonnent, les gains repartant ensuite. Un calendrier « réduire puis ré-élargir » que personne n'a écrit, émergeant d'une boucle qui optimise un objectif explicite ajusté au coût, illustre concrètement l'idée centrale, y compris là où les chiffres agrégés du benchmark sont discutables.
Rien de tout cela ne fait de Dream-RSI un article faible. Traiter l'historique de découverte comme un environnement rejouable plutôt que comme un contexte statique est une contribution réelle, c'est la même astuce que Schema utilisait pour retester ses programmes de jeu contre l'historique enregistré à coût d'action nul, et les résultats sur les noyaux la soutiennent. Ce qui manque à l'article, c'est la partie où il plaide contre lui-même : pas de section sur les limites, aucune vérification rapportée que le score de rejeu prédit la performance en ligne, aucune reconnaissance du fait que la moyenne phare est portée par une seule colonne, et un titre qui revendique bien plus de territoire qu'un ordonnanceur par lots qui se réécrit n'en occupe. Pour un laboratoire qui s'est montré prudent avec ce vocabulaire ailleurs — et avec AlphaEvolve dans le même bâtiment comme point de comparaison évident —, ce sont des omissions à nommer plutôt qu'une raison d'écarter le travail.