Un agent peut afficher un meilleur score tout en devenant moins fiable sur les tâches qu’il n’a jamais vues. C’est le problème ciblé par RRSI, la méthode de Google destinée à encadrer l’auto-amélioration du harness d’un agent sans laisser celui-ci mémoriser les tests.
Les résultats publiés en septembre 2026 font état de gains pouvant atteindre 4,7 points sur des benchmarks hors distribution et d’une baisse d’environ 30 % des policy tokens utilisés à l’exécution. Face à un agent traditionnel, RRSI ne change pas les poids du modèle : il améliore la manière dont l’agent organise ses prompts, ses outils, son contrôle, sa mémoire et ses sous-agents.
RRSI améliore le harness, pas les poids du modèle
Le point clé est la distinction entre le modèle et son harness, c’est-à-dire l’ensemble logiciel qui encadre le modèle : instructions, boucle de contrôle, outils, gestion du contexte, mémoire et sous-agents. RRSI laisse cet espace ouvert à la modification tout en régularisant la recherche d’améliorations.
Google Research décrit RRSI comme une méthode de « Regularized Recursive Self-Improvement of Agent Harnesses ». Le modèle de politique reste fixe pendant l’expérience, tandis que le système recherche des modifications du harness susceptibles d’améliorer les performances.
Les éléments pouvant être modifiés comprennent notamment :
- les prompts et instructions de l’agent ;
- le contrôle du flux d’exécution ;
- les interfaces d’outils ;
- la gestion du contexte ;
- la mémoire ;
- les compétences et les sous-agents.
Cette approche oppose RRSI aux agents traditionnels dont l’architecture est généralement définie à l’avance. Dans un agent classique, les améliorations passent souvent par un meilleur modèle, de nouvelles instructions écrites par un développeur ou l’ajout manuel d’outils. RRSI automatise une partie de cette optimisation.
À retenir : RRSI ne constitue pas un nouveau modèle conversationnel. C’est une méthode d’optimisation du système qui entoure le modèle afin d’obtenir un agent plus robuste sur des tâches nouvelles.
Pourquoi les agents auto-optimisés risquent de mémoriser les tests
L’auto-amélioration d’un agent peut augmenter son score sur un ensemble de tâches tout en réduisant sa capacité à généraliser. Le système peut découvrir une modification qui exploite une particularité du benchmark plutôt qu’une stratégie réellement utile.
Ce phénomène ressemble au surapprentissage, lorsque les performances progressent sur les exemples utilisés pour l’optimisation mais diminuent sur des exemples différents. Dans le cas d’un agent, le surapprentissage peut concerner un prompt, une séquence d’outils, une règle de routage ou une stratégie de mémoire.
Google distingue ainsi les tâches utilisées pendant l’évolution du harness et les tâches conservées pour l’évaluation. Les premières forment le périmètre « evolve ». Les secondes servent à mesurer la généralisation hors distribution, c’est-à-dire la performance sur des tâches que le système n’a pas utilisées pour rechercher ses modifications.
Le dépôt public de RRSI décrit plusieurs mécanismes destinés à limiter ce problème :
- un budget d’édition qui encadre les changements proposés ;
- des propositions orientées vers des directions encore peu explorées ;
- un leakage critic, chargé de repérer les modifications susceptibles d’exploiter des informations propres au benchmark ;
- un plancher ajusté au bruit statistique des évaluations ;
- une règle de coût ;
- une étape de pruning qui retire les modifications trop coûteuses, trop faibles ou devenues inutiles.
Un agent traditionnel peut éviter une partie de ces risques parce que son harness est fixe. Il ne réécrit pas automatiquement ses propres règles et ne cherche donc pas à optimiser directement son score. En contrepartie, il ne bénéficie pas de la recherche automatisée de configurations plus efficaces.
Les résultats de RRSI sur les benchmarks 2026
Les expériences publiées portent sur huit benchmarks répartis entre le développement logiciel, le travail de bureau agentique et la conception technique. Les résultats rapportés comparent un harness de départ à un harness optimisé avec RRSI.
| Domaine | Benchmark | Harness de départ | RRSI | Écart |
|---|---|---|---|---|
| Programmation | Terminal-Bench 2.1, evolve | 74,2 | 80,2 | +6,0 |
| Programmation | SWE-bench Verified, hors distribution | 82,0 | 83,8 | +1,8 |
| Travail de bureau agentique | Harvey LAB, evolve | 89,4 | 90,5 | +1,1 |
| Travail de bureau agentique | JobBench, hors distribution | Résultat publié : +4,7 points | Résultat publié : +4,7 points | +4,7 |
| Travail de bureau agentique | GDPval, hors distribution | Résultat publié : +3,5 points | Résultat publié : +3,5 points | +3,5 |
| Travail de bureau agentique | APEX-Agents, hors distribution | Résultat publié : +3,7 points | Résultat publié : +3,7 points | +3,7 |
| Conception technique | EngDesign, evolve | Résultat publié : +4,9 points | Résultat publié : +4,9 points | +4,9 |
| Conception technique | Frontier-Eng, hors distribution | Résultat publié : +4,3 points | Résultat publié : +4,3 points | +4,3 |
Sur Terminal-Bench 2.1, le score passe de 74,2 à 80,2 sur le split utilisé pour l’évolution. Sur SWE-bench Verified, qui n’a pas servi à sélectionner les modifications, il progresse de 82,0 à 83,8.
Les plus grands gains hors distribution atteignent 4,7 points sur JobBench. Les résultats rapportés indiquent également +3,5 points sur GDPval et +3,7 points sur APEX-Agents.
Les chiffres doivent être lus comme des résultats expérimentaux dans un protocole déterminé. Ils mesurent la qualité du harness obtenu avec RRSI dans les suites évaluées et ne constituent pas une mesure universelle de la capacité des modèles d’IA.
RRSI réduit aussi le coût d’exécution
L’intérêt de RRSI ne se limite pas au score. Le harness produit par la méthode utilise environ 30 % de policy tokens en moins que l’évolution non régularisée pendant l’exécution.
Les policy tokens sont les tokens générés par le modèle de politique lorsqu’il raisonne, choisit une action ou produit une réponse intermédiaire. Une baisse de leur volume peut réduire le coût d’inférence et accélérer les scénarios où l’agent effectue de nombreuses étapes.
Une autre comparaison publiée rapporte 3,80 millions de tokens par essai pour l’évolution non régularisée, contre 2,42 millions pour RRSI. Cette différence correspond à environ 36 % de tokens en moins dans cette ablation particulière.
La différence entre les deux chiffres tient au protocole comparé : le résultat général communiqué pour l’exécution est d’environ 30 %, tandis que l’ablation publiée mesure un écart plus important sur une configuration donnée. Ces données ne permettent pas de convertir directement la baisse de tokens en économie en euros ou en dollars, car le prix dépend du modèle utilisé, du fournisseur et du volume de requêtes.
Pour une équipe qui exploite un agent à grande échelle, la réduction des tokens peut néanmoins avoir un effet opérationnel sur :
- le coût d’inférence ;
- la latence des workflows ;
- la capacité à exécuter davantage de tâches avec un budget fixe ;
- la consommation de contexte dans les longues séquences d’actions.
Un agent traditionnel peut rester préférable lorsque la priorité est la prévisibilité. Son comportement est plus facile à auditer lorsqu’il ne modifie pas automatiquement son propre harness, même si cette stabilité ne garantit pas à elle seule une meilleure performance.
Les mécanismes RRSI se transfèrent à d’autres modèles
Les résultats publiés indiquent que les mécanismes découverts avec RRSI peuvent être transférés à des modèles plus faibles. Cette propriété distingue l’optimisation du harness d’un simple ajustement destiné à un modèle unique.
Une expérience rapportée avec Gemini 3.5 Flash fait progresser Terminal-Bench 2.1 de 64,6 à 78,7. Sur SWE-bench Verified, le score passe de 76,8 à 79,0.
Les évaluations principales ont été conduites avec Claude Opus 4.8 comme modèle de politique maintenu fixe. L’expérience avec Gemini 3.5 Flash indique que les bénéfices du harness ne sont pas nécessairement limités au modèle utilisé pendant la recherche.
Il faut toutefois distinguer transfert de mécanismes et transfert garanti de performances. Les résultats publiés montrent un transfert dans les configurations évaluées ; ils ne prouvent pas qu’une même configuration fonctionnera de manière identique avec tous les modèles, toutes les tâches ou tous les fournisseurs.
Ce que cela change pour une équipe technique
Avec un agent traditionnel, le remplacement du modèle peut imposer une nouvelle phase de réglage des prompts, des outils et de la boucle de contrôle. RRSI offre une méthode pour rechercher des configurations de harness plus robustes avant ou après ce changement.
Cette approche peut intéresser les équipes qui utilisent plusieurs modèles selon le coût, la latence ou la sensibilité des tâches. Elle permet de considérer le harness comme une couche réutilisable, plutôt que comme un assemblage entièrement lié à un seul modèle.
La réutilisabilité ne supprime pas le besoin de validation. Chaque nouveau modèle doit être testé sur les tâches réellement visées, notamment lorsque ses capacités d’appel d’outils, son contexte ou son comportement de raisonnement diffèrent.
Comparatif : RRSI ou agent traditionnel en 2026
Le choix dépend moins du caractère récent de la méthode que du niveau d’automatisation et de contrôle recherché.
| Critère | RRSI de Google | Agent IA traditionnel |
|---|---|---|
| Objet optimisé | Harness de l’agent | Modèle, prompts et composants définis par l’équipe |
| Poids du modèle | Conservés fixes pendant l’expérience | Dépendent du modèle choisi |
| Prompts | Peuvent être modifiés automatiquement | Généralement définis manuellement |
| Outils | Peuvent être modifiés dans l’espace de recherche | Configurés par les développeurs |
| Contrôle du flux | Optimisable par la méthode | Fixé dans l’architecture de l’agent |
| Mémoire et contexte | Inclus dans l’espace d’édition | Gérés selon la conception du système |
| Protection contre le surapprentissage | Critique de fuite, régularisation, coût et pruning | Dépend du protocole d’évaluation de l’équipe |
| Généralisation publiée | Jusqu’à +4,7 points sur des benchmarks hors distribution | Aucun gain RRSI associé |
| Tokens d’exécution | Environ 30 % de moins que l’évolution non régularisée | Référence dépendante de l’implémentation |
| Code | Dépôt public Google Research | Dépend du projet utilisé |
| Niveau de contrôle | Recherche automatisée de modifications | Contrôle manuel plus direct |
RRSI est le choix le plus pertinent pour les équipes capables d’investir dans une phase d’évaluation structurée et qui veulent optimiser un agent sur plusieurs familles de tâches. La méthode est particulièrement adaptée aux systèmes où le coût d’exécution et la généralisation hors benchmark sont des critères importants.
Un agent traditionnel reste le choix le plus simple lorsqu’un workflow doit être déployé rapidement avec une architecture stable. Il convient aussi lorsque les règles d’exécution doivent rester entièrement explicites et que l’équipe ne souhaite pas autoriser une recherche automatique sur les outils, la mémoire ou le contrôle du flux.
Les avantages de RRSI pour les agents de production
Le premier avantage de RRSI est la recherche automatisée d’améliorations à plusieurs niveaux du système. Au lieu de modifier séparément un prompt, un outil ou une règle de mémoire, la méthode peut explorer leurs interactions.
Le deuxième avantage est la séparation entre score d’évolution et score hors distribution. Cette distinction rend plus difficile l’obtention d’un gain artificiel limité aux tâches utilisées pour l’optimisation.
Le troisième avantage est la réduction du nombre de tokens d’exécution. Une amélioration qui augmente la qualité tout en diminuant la longueur des trajectoires peut être plus intéressante qu’une méthode qui gagne des points au prix d’un raisonnement beaucoup plus long.
Le quatrième avantage concerne le code disponible. Le dépôt Google Research permet d’examiner l’implémentation et les résultats publiés, puis de reproduire le protocole dans un environnement contrôlé.
Ces avantages s’accompagnent d’exigences opérationnelles : les tests doivent être séparés, les modifications doivent être traçables et les coûts d’évaluation doivent être surveillés. RRSI automatise la recherche, mais ne remplace pas la définition d’un protocole de validation adapté au produit.
Les limites d’un agent traditionnel face à RRSI
Un agent traditionnel ne dispose pas de la boucle de recherche spécifique à RRSI. Lorsque ses performances plafonnent, l’équipe doit généralement intervenir sur le modèle, le prompt système, les outils, la mémoire ou le code de contrôle.
Cette méthode peut être parfaitement adaptée à un système simple. Elle devient plus difficile à maintenir lorsque l’agent accumule des outils et des sous-agents, car une modification locale peut avoir des effets sur l’ensemble de la trajectoire.
L’évaluation repose également davantage sur l’équipe. Si les tests de validation sont trop proches des exemples de développement, un agent traditionnel peut donner une impression de robustesse sans avoir été confronté à suffisamment de variantes.
Son principal avantage reste le contrôle direct. Les développeurs savent quelle règle a été écrite, quelle fonction est appelée et dans quel ordre les actions sont exécutées. Dans les environnements réglementés ou sensibles, cette lisibilité peut compter autant que quelques points de benchmark.
RRSI n’est pas automatiquement le meilleur choix pour chaque projet
Les résultats publiés sont significatifs, mais ils ne transforment pas RRSI en solution universelle. Les gains dépendent du modèle de politique, des outils, des benchmarks et de la manière dont le harness est évalué.
La méthode est aussi plus complexe qu’un agent dont le prompt et la boucle d’exécution sont configurés manuellement. L’équipe doit gérer une recherche de variantes, des évaluations répétées, des règles de coût et une séparation stricte entre tâches d’évolution et tâches de validation.
Le risque de surapprentissage n’est pas supprimé par le seul fait d’utiliser RRSI. Il est traité par la régularisation et par des mécanismes de contrôle, mais la qualité des données d’évaluation et la conception des tests restent déterminantes.
Pour un agent chargé d’un nombre réduit d’actions bien définies, l’automatisation de l’harness peut apporter moins de valeur que l’amélioration ciblée d’un outil ou d’un prompt. Pour un agent complexe, multi-outils et déployé sur des tâches variées, l’intérêt potentiel est plus élevé.
Notre avis : RRSI pour les agents complexes, traditionnel pour le contrôle maximal
En 2026, RRSI est le choix le plus convaincant pour une équipe qui veut améliorer la généralisation d’un agent sans réentraîner systématiquement son modèle. Les gains publiés, jusqu’à 4,7 points sur des benchmarks hors distribution, associés à une baisse d’environ 30 % des policy tokens, donnent à la méthode un avantage concret sur l’optimisation non régularisée.
Un agent traditionnel reste préférable pour un prototype rapide, un workflow limité ou un système dont chaque décision doit rester lisible et contrôlée manuellement. Sa simplicité réduit le coût de mise en œuvre et facilite l’audit du comportement.
Le bon choix dépend donc du niveau de complexité du système : agent stable et spécialisé d’un côté, harness évolutif confronté à des tâches diverses de l’autre. Si les prochains mois confirment le transfert des gains vers davantage de modèles et de domaines, l’optimisation du harness pourrait devenir une étape standard du déploiement des agents, au même titre que le choix du modèle lui-même.