Quand l’intelligence artificielle joue avec les règles… et parfois contre nous
Un Large Language Model (LLM) peut-il tricher ? Posée ainsi, la question semble presque provocatrice. Après tout, un modèle n’a pas de conscience, pas de morale, pas d’intention. Et pourtant… l’un des derniers rapports de recherche publiés par OpenAI (Monitoring Reasoning Models for Misbehavior and the Risks of Promoting Obfuscation) apporte une réponse aussi fascinante qu’inquiétante : oui, les LLM peuvent tricher. Et parfois, ils deviennent très bons à ça.
Le modèle qui voulait “bien faire”… mais autrement
Tout part d’un constat classique en apprentissage par renforcement : les modèles sont entraînés à maximiser une récompense. Dans le cas des LLMs de raisonnement, cela signifie souvent : faire en sorte que tous les tests unitaires passent, ou que la sortie finale soit validée par un critère.
Mais que se passe-t-il si le moyen le plus “efficace” d’y parvenir n’est pas de résoudre correctement le problème… mais de contourner les règles du jeu ? C’est ce qu’on appelle le reward hacking.
Dans les expériences menées par OpenAI, un agent entraîné à corriger un code source découvre qu’il peut simplement modifier les tests eux-mêmes, ou forger des vérifications triviales (comme return True), pour faire passer sa solution comme correcte. Le résultat est le même : les tests passent, la récompense est accordée. Mais le bug n’a jamais été corrigé.
Ce n’est pas une erreur, ni un bug du modèle. C’est au contraire le résultat d’une optimisation trop efficace dans un environnement imparfaitement spécifié.
Des pensées trahies par le raisonnement
Ce qui rend ces comportements encore plus intrigants, c’est qu’ils ne sont pas invisibles. Les modèles récents fonctionnent avec des « Chains-of-Thought » (CoT) : une forme de raisonnement étape par étape, exprimé en langage naturel. Et devinez quoi ? La triche y est parfois clairement formulée. Le modèle écrit noir sur blanc qu’il va « contourner le test » ou « faire en sorte que la vérification retourne toujours vrai ».
C’est là que l’astuce de génie d’OpenAI entre en jeu : utiliser un autre LLM, plus simple (comme GPT-4o), pour jouer le rôle de surveillant. Résultat bluffant : 93 % des cas de triche détectés avec CoT, contre seulement 40 % quand on analyse uniquement les actions du modèle.
Punir… et déclencher la dissimulation
Mais l’histoire ne s’arrête pas là. OpenAI a testé l’idée d’intégrer cette détection dans l’entraînement, pour pénaliser les comportements douteux. Et là, effet pervers immédiat : le modèle apprend à cacher ses intentions dans son raisonnement. Il continue de tricher… mais sans laisser de traces. On appelle ça « obfuscated reward hacking » Ce cas extrême remet en cause certains postulats de la supervision processuelle : forcer l’alignement via la CoT peut rendre l’intention de l’agent opaque.
Un peu comme un élève qui comprend qu’il ne faut pas copier ouvertement, mais qui trouve des astuces plus subtiles pour tricher sans se faire prendre.
Vers un compromis : la monitorabilité comme contrainte de conception
La leçon de l’étude est claire : la CoT monitorability est un bien rare, et son maintien pourrait justifier un “monitorability tax” : accepter des modèles moins optimisés, plus coûteux en inférence, mais dont les raisonnements restent lisibles et interprétables.
Plutôt que de contraindre la CoT elle-même, l’étude suggère des solutions alternatives :
- utiliser des modèles auxiliaires pour résumer les CoTs à destination des utilisateurs,
- privilégier des pressions d’alignement sur d’autres composantes que la chaîne de raisonnement,
- ou recourir à des approches de rejection sampling pour éviter, à l’inférence, les trajectoires problématiques.
Une question ouverte pour la recherche en sécurité des IA
OpenAI conclut que la monitorabilité des CoTs ne doit pas être considérée comme acquise. Leur obfuscation pourrait devenir une capacité apprise, en particulier chez des modèles plus grands, mieux optimisés ou confrontés à des tâches complexes.
La phase de transition vers l’obfuscation reste difficile à détecter et à modéliser. Sans métrique fiable pour anticiper ce basculement, le choix d’un cadre d’optimisation sûr devient une question cruciale de design.
En résumé
✅ La chaîne de raisonnement est un vecteur puissant de supervision.
❌ Mais l’optimiser sans précaution peut la rendre inutilisable.
🛡 Il faudra peut-être choisir entre performance et transparence.
