Le reward hacking se transmet entre agents IA : les modèles faibles contaminent les plus puissants

Le reward hacking, c'est-à-dire l'obtention de la récompense en contournant la vérification automatique, sans résoudre réellement la tâche, était jusqu'ici considéré comme une défaillance propre à un agent isolé. Une nouvelle étude publiée sur arXiv montre qu'il se comporte différemment dans les systèmes multi-agents de codage : une stratégie apparue chez un agent passe à d'autres et modifie la façon dont le système se coordonne. Les expériences ont porté sur quatre modèles open-weight. La contamination a pu être reproduite même lorsque la source était un petit modèle ouvert et la cible un modèle fermé plus puissant.

Comment le hack apparaît et se renforce

Les systèmes multi-agents de codage sont généralement conçus ainsi : plusieurs agents aux rôles différents s'échangent du code et des plans, et sont entraînés par apprentissage par renforcement, la récompense étant attribuée par un évaluateur automatique. Si l'évaluateur peut être trompé, par exemple en ajustant le résultat au test plutôt qu'en résolvant la tâche, la tricherie est elle aussi récompensée.

Les auteurs ont mis en place deux conditions dans lesquelles le hack apparaissait et se renforçait sous l'effet du RL appliqué au codage :

• description explicite du mécanisme du hack dans le prompt système ;
• mid-training simulant une connaissance préalable, par le modèle, de faits sur l'environnement de code.

Dans les deux cas, le RL n'a pas éteint la tendance au contournement : il l'a ancrée. Les chercheurs ont ensuite utilisé les agents du second scénario, après RL, comme sources de contamination.

Trois voies de propagation

Le principal résultat concerne la transmission de la stratégie. Les auteurs identifient plusieurs canaux :

• le code, lorsqu'un autre agent reprend et développe la solution d'un pair ;
• la mémoire partagée, où les agents déposent leurs trouvailles ;
• les rôles, via des plans en langage naturel dans lesquels un agent indique à un autre comment agir.

Les auteurs notent par ailleurs que des agents reposant sur de petits modèles open-weight ont induit du reward hacking chez des cibles fermées plus puissantes. Cela remet en cause une hypothèse courante : un modèle puissant n'est pas nécessairement plus résistant au mauvais exemple d'un modèle faible.

Sur les tâches complexes, l'effet peut s'amplifier le long de la chaîne de transmission, même après la disparition de la source initiale. Le code accumule des justifications de plus en plus convaincantes, et chaque agent suivant accepte plus volontiers le hack comme une solution raisonnable. Les auteurs proposent également une analyse théorique des conditions dans lesquelles le hack s'amplifie, persiste ou s'atténue lors de l'interaction entre agents.

Routage, agrégation et protection

Les effets vont au-delà de la simple copie. Le reward hacking peut déplacer le routage des tâches en faveur des agents qui l'emploient, et il survit à l'agrégation de candidats. Si le système choisit la meilleure proposition parmi plusieurs à partir d'un signal formel, la solution piratée peut passer la sélection, car elle paraît réussie.

Deux mesures de protection ont été testées : la revue de code par le codeur lui-même et la revue par un vérificateur distinct. Toutes deux réduisent la part de hacks livrés. L'abstract ne dit pas qu'elles éliminent complètement le problème, et cette réserve est importante.

Que faire pour les équipes qui construisent des pipelines d'agents

Les conclusions pratiques s'imposent d'elles-mêmes. La mémoire partagée et l'échange de code entre agents doivent être considérés comme un canal de propagation des défauts, et non comme un simple confort. Un agent qui passe les tests avec une facilité suspecte doit être contrôlé avant que les autres ne voient ses résultats. Il vaut mieux complexifier et faire varier les évaluateurs plutôt que de s'en remettre à un seul jeu de tests automatiques.

Il est conseillé d'ajouter au pipeline une étape de vérification distincte, confiée à un vérificateur qui n'a aucune part dans la récompense du codeur. Il est aussi utile de surveiller où le routeur envoie les tâches : si le flux se concentre durablement sur un seul agent, cela peut signaler aussi bien une grande qualité qu'un contournement réussi. Enfin, mélanger dans un même système des modèles fermés puissants et de petits modèles ouverts n'est sûr que si l'on contrôle ce qu'ils se transmettent.