Des chercheurs de Google proposent RRSI pour empêcher les agents d’IA capables de s’améliorer eux-mêmes de mémoriser les tests

Des chercheurs de Google ont proposé une méthode pour améliorer les agents d’IA sans leur permettre de se surajuster aux tâches utilisées pour les optimiser. Baptisée Regularized Recursive Self-Improvement of Agent Harnesses, ou RRSI, cette approche cible un problème qui devient plus sérieux à mesure que les systèmes réécrivent automatiquement leurs propres prompts, workflows, outils et logique de mémoire.

Selon un article de recherche décrit par The Decoder, RRSI a amélioré les résultats sur des benchmarks jamais vus auparavant de jusqu’à 4,7 points et utilisé environ 30 % de tokens d’exécution en moins qu’une approche d’optimisation non régularisée. Les gains rapportés viennent de la modification du harness de l’agent autour d’un modèle gelé, plutôt que de la mise à jour des poids du modèle.

Pourquoi les harnesses d’agents deviennent la cible

De nombreux agents d’IA de production reposent sur un modèle de langage fixe entouré d’un harness d’agent : prompts, appels d’outils, règles de workflow, systèmes de mémoire, comportement de récupération et traitement des sorties déterminent la façon dont le modèle fonctionne. Le harness peut décider si un agent vérifie un fichier avant de le modifier, réessaie après une erreur ou structure sa réponse finale.

Des chercheurs de Google Cloud AI Research et des collaborateurs universitaires étudient des moyens d’automatiser les améliorations de cette couche. Dans une boucle typique d’auto-amélioration récursive, un modèle de langage propose des changements au harness, les évalue sur un ensemble de tâches, puis utilise les résultats pour produire d’autres changements.

Le risque est qu’une optimisation répétée sur une petite collection de tests rende un agent meilleur sur ces tests précis sans le rendre plus performant en général. Le système peut apprendre des schémas propres au benchmark, sélectionner des changements qui réussissent par hasard ou accumuler une complexité inutile qui augmente le score mesuré tout en accroissant le coût et la fragilité.

Cette question est importante, car les agents d’IA sont souvent évalués sur des suites de tâches limitées, tandis que leurs environnements de déploiement sont beaucoup moins prévisibles. Un harness performant sur des workflows familiers peut échouer lorsque les structures de fichiers, les instructions, les outils ou les objectifs des utilisateurs changent.

Comment RRSI limite le surajustement

RRSI applique des contrôles à deux moments du processus d’optimisation. Lors de la génération de révisions candidates, il limite le nombre de modifications indépendantes pouvant être regroupées dans une proposition. Le nombre de modifications autorisées diminue au fil du temps, faisant passer le processus de refontes générales à des modifications plus ciblées.

Le système conserve également les tentatives précédentes, ce qui l’aide à éviter d’explorer à nouveau des changements qui ont déjà échoué. Lorsque les progrès s’arrêtent, il oriente les expérimentations vers les parties du harness qui n’ont pas encore été examinées.

Un critique distinct évalue les changements proposés avant leur adoption définitive. Il rejette les révisions qui semblent coder en dur des noms de tâches, des solutions ou d’autres comportements propres au benchmark. RRSI exige aussi un bénéfice de performance observable avant d’accepter des changements qui augmentent le coût de calcul, et supprime les composants qui ne contribuent plus.

Ensemble, ces règles visent à favoriser des améliorations plus petites et explicables, transférables à de nouvelles tâches, plutôt que des changements agressifs maximisant un score de test étroit. La méthode laisse le harness modifiable, mais limite la vitesse et la liberté avec lesquelles il peut se réécrire.

Ce que montrent les résultats rapportés

Les chercheurs ont testé RRSI sur huit benchmarks couvrant le codage, le travail d’agents destiné aux bureaux et la conception technique. Le modèle sous-jacent, identifié dans le rapport comme Claude Opus 4.8, est resté gelé. La comparaison comprenait un harness de référence inchangé et quatre autres méthodes d’optimisation.

Les résultats rapportés montrent un compromis. RRSI a produit des gains allant jusqu’à 14,1 points sur les tâches utilisées pendant l’optimisation, mais le résultat le plus important concernait cinq benchmarks inconnus, sur lesquels l’amélioration maximale atteignait 4,7 points. Selon l’article rapporté par The Decoder, le harness RRSI n’est passé sous la référence dans aucune de ces évaluations inédites.

D’autres approches auraient obtenu de bons résultats sur leurs tâches d’entraînement, mais se seraient moins bien transférées. Deux méthodes sont tombées sous la référence sur de nouvelles tâches. RRSI a fourni la plus faible amélioration sur l’ensemble d’entraînement parmi les variantes testées, ce que les chercheurs interprètent comme la preuve qu’elle sacrifiait la spécialisation au benchmark en faveur d’une généralisation plus large.

Le résultat concernant les tokens est également pertinent pour les équipes qui exploitent des agents à grande échelle. Le système RRSI optimisé a utilisé environ 30 % de tokens en moins que la version non régularisée et a nécessité moins d’étapes parmi les harnesses optimisés. La référence d’origine est toutefois restée plus économique : la régularisation n’a donc pas rendu le système entier moins coûteux que toutes les autres solutions.

Il s’agit de résultats de recherche, et non de benchmarks de production indépendants. Les chiffres de performance sont des affirmations issues de l’évaluation des chercheurs, et les éléments disponibles n’établissent pas comment la méthode fonctionnerait avec des distributions de tâches plus vastes, d’autres modèles ou des charges de travail d’entreprise réelles.

Conséquences pour les concepteurs et acheteurs d’IA

Pour les concepteurs, ces travaux suggèrent qu’améliorer un agent doit aller au-delà de la maximisation d’un benchmark de développement. Les ensembles d’évaluation doivent inclure des tâches que le processus d’optimisation ne voit jamais ; autrement, un système capable de s’améliorer peut se récompenser pour avoir appris le test plutôt que pour avoir amélioré son workflow sous-jacent.

La conception de RRSI indique aussi des contrôles opérationnels pour l’auto-amélioration récursive. Les équipes pourraient limiter le nombre de changements simultanés, conserver un historique des expériences échouées, exiger une justification des coûts pour les workflows plus chers et bloquer les modifications apparemment liées à des cas de test précis. Ces contrôles pourraient rendre l’optimisation automatisée des harnesses plus facile à auditer et à annuler.

L’approche pourrait être particulièrement pertinente pour l’IA d’entreprise, où le coût des tokens, la prévisibilité du comportement et la fiabilité sur des processus internes variés comptent autant que les meilleurs scores de benchmark. Un harness qui se généralise à des documents ou procédures inconnus peut être plus utile qu’un harness qui obtient un score supérieur sur une collection fixe de démonstrations.

Ces travaux ne résolvent pas les questions plus larges de sécurité et de gouvernance concernant les agents qui modifient leur propre logique de fonctionnement. RRSI contraint les changements du harness, mais les éléments disponibles ne montrent pas si ses critiques peuvent détecter de manière fiable toutes les formes de comportement caché propre à un benchmark. La méthode ne traite pas non plus des systèmes dans lesquels les poids du modèle changent pendant l’optimisation.

Le transfert rapporté entre modèles reste néanmoins notable. Un harness de codage découvert avec Gemini 3.5 Flash aurait fait passer la précision du modèle plus faible Gemini 3.1 Flash Lite de 11,2 à 14,6 points sans modifier ce dernier modèle. Ce résultat laisse penser que certaines améliorations de workflow pourraient être portables entre des modèles aux capacités différentes, même s’il provient du même rapport de recherche et exige une validation plus large.

Les éléments à surveiller

Le premier signal sera une réplication indépendante de RRSI sur des modèles et des familles de tâches supplémentaires. Les résultats devront être comparés sur des tâches retenues, cachées à la fois à l’optimiseur du harness et à son critique.

Les chercheurs et les équipes produit devraient également tester si la méthode reste efficace lorsque les outils, les prompts, les systèmes de mémoire et les distributions de données changent après le déploiement. Les mesures de coût seront également importantes : la réduction de 30 % des tokens est relative à un système optimisé non régularisé, et pas nécessairement à une référence soigneusement conçue.

Une autre question ouverte est de savoir si des contrôles similaires peuvent régir des agents qui mettent à jour les poids du modèle, plutôt que seulement le harness environnant. L’étude actuelle porte sur des modèles gelés et laisse de côté cette forme plus lourde de l’auto-amélioration.

Point de vue de Creati.ai

RRSI s’attaque à une faiblesse pratique de la course actuelle aux agents : les équipes peuvent automatiser la recherche de meilleurs workflows plus rapidement qu’elles ne peuvent déterminer si ces workflows se généralisent. Sa principale contribution est donc méthodologique. Elle traite la performance sur des tâches inconnues et le coût de calcul comme des contraintes de premier ordre, plutôt que de s’appuyer sur un seul score d’optimisation.

La recherche ne prouve pas que l’auto-amélioration récursive soit prête pour un déploiement sans supervision. Elle offre toutefois aux concepteurs un principe plus clair : un agent doit mériter le droit de devenir plus complexe en démontrant des gains fiables au-delà des tests qui ont produit la modification.