Pourquoi le RL post-entraînement rend parfois les modèles « plus bêtes »

Contexte technique

Je vois souvent la même réaction : une nouvelle version post-entraînée sort, le modèle s’améliore sur les démos et les benchmarks, donc il est censé être plus intelligent dans l’ensemble. Hélas, ce n’est pas ainsi que cela fonctionne. Le RL post-entraînement pousse presque toujours le modèle là où une récompense spécifique augmente, et non là où une large universalité est préservée.

En termes concrets, c’est le prix habituel d’une implémentation IA pilotée par des KPI clairs. J’optimise le système pour le suivi d’instructions, le taux de préférence, la précision mathématique ou un style de réponse sûr, et le modèle commence à vivre plus étroitement dans ce couloir. Dans les scénarios populaires, cela apporte des gains. Dans les tâches rares, étranges ou non anticipées, de petites régressions apparaissent.

J’ai creusé ce genre de pipelines à plusieurs reprises, et les effets secondaires les plus courants sont familiers : détournement de récompense, effondrement de l’entropie, surapprentissage sur une métrique proxy. Le modèle apprend à faire non pas ce que je voulais, mais ce qui est le mieux rémunéré par la fonction de récompense. Il peut donc sembler plus soigné, plus confiant et plus obéissant, tout en étant légèrement moins bon pour gérer les tournures inattendues d’une requête.

C’est particulièrement amusant à observer sur les modèles de raisonnement. Je peux améliorer la justesse étape par étape en mathématiques ou en code, mais simultanément dégrader la calibration, la diversité des solutions ou le comportement en dehors d’un format de réponse étroit. Ce n’est pas une catastrophe, plutôt une mort par mille coupures, mais en production, ces petits détails finissent par ressortir.

Impact sur les entreprises et l’automatisation

Pour l’automatisation IA, la leçon est simple : ne confondez pas l’amélioration des scores de benchmark avec une fiabilité accrue du système. Si votre agent gère le support, les ventes ou la recherche interne, il peut devenir meilleur dans 80 % des dialogues fréquents et moins bon dans les cas rares et coûteux où une erreur coûte réellement de l’argent.

Le deuxième point concerne l’architecture. Je n’appliquerais pas le même post-entraînement à tous les rôles en même temps. Certains endroits nécessitent une variante RL peaufinée, tandis que d’autres gagnent à conserver un modèle de base plus large, encadré par des règles, une validation et un routage.

Ce sont précisément ces compromis que nous, chez Nahornyi AI Lab, détaillons pour nos clients : où une intégration IA agressive est pertinente, et où il vaut mieux ne pas étouffer le modèle pour une métrique flatteuse. Si votre automatisation est devenue trop « correcte » mais échoue sur des cas réels, examinons votre pipeline et concevons un développement de solutions IA sans ce piège.

Nous avons précédemment exploré la méthode Simple Self-Distillation, qui améliore la génération de code sans RL complexe ni vérificateurs. Cette approche devient particulièrement pertinente lorsque l’on constate comment le RL post-entraînement peut dégrader les performances sur les tâches moins courantes.