Le problème caché de l'RL pour les LLM : pourquoi on n'améliore que les tâches faciles
En bref
- Un article de recherche met en lumière un biais systémique dans l'entraînement par renforcement des LLM : on améliore surtout les tâches que le modèle sait déjà bien faire.
- L'auteur appelle ce phénomène l'Effet Matthew (les riches deviennent plus riches) et montre que c'est visible sur AIME, le code, et les benchmarks agents.
- La cause n'est pas seulement le manque d'échantillons corrects sur les problèmes difficiles, mais aussi le temps de calcul gaspillé à réentraîner sur des problèmes faciles qui obtiennent des solutions rares mais incorrectes.
- Un paramètre contre-intuitif ressort des expériences : k=4 (4 complétions par prompt) résout mieux les problèmes difficiles que k=32, notamment après une certaine étape d'entraînement.
Ce que dit la source
L'auteur, Michael Noukhovitch, observe que quand on applique l'RL classique aux LLM pour améliorer leur performance mathématique ou leur capacité à écrire du code, les courbes d'évaluation globales montent, mais cache un phénomène : les gains proviennent presque entièrement des tâches faciles ou moyennes, tandis que les tâches très difficiles stagnent. Sur AIME par exemple, les questions où le modèle initial échoue systématiquement restent échouées après l'RL. Il propose d'appeler ce comportement l'Effet Matthew, et soutient que le problème vient moins d'une insuffisance d'échantillons corrects que d'un gaspillage de calcul à réentraîner sur les cas faciles où le modèle trouve par chance une mauvaise solution.
- Les courbes d'éval agrégées masquent une régression : sur AIME, les problèmes faciles passent de 22,7% à presque 100% de réussite, les difficiles restent bloqués à 0%.
- Le phénomène est reproductible sur d'autres domaines : code RL (Deepcoder) et agents (DeepSWE) montrent le même biais vers les tâches faciles.
- Contre-intuitivement, k=4 (4 complétions par prompt) améliore mieux les problèmes durs que k=32, surtout après 200 étapes d'entraînement.
- L'explication : k=32 augmente les chances de trouver une rare solution correcte aux problèmes durs, mais aussi une rare solution fausse aux problèmes faciles, ce qui pollue le batch d'entraînement.
- Après un point d'inflexion, les gains du filtrage de plus de problèmes faciles (avec k=4) surpassent le coût de moins d'échantillons sur les difficiles.
- L'auteur distingue signal loss (ne pas obtenir un signal sur un problème dur faute de solution) d'une source plus importante selon lui : gaspiller du calcul sur des problèmes faciles avec solutions rares incorrectes.
Dans les commentaires
Débat très limité : un commentaire techniques pertinent reste noyé, un commentaire signale des liens brisés, un autre déraille vers une anecdote de performance TypeScript sans lien avec l'article.
- Un commentateur souligne des liens cassés en haut de l'article (pointers vers le paper et le code pointent vers la même page).
- Un autre apporte une anecdote sur la confirmation bias en RL (Claude a confirmé un nombre de messages faux pour les mêmes raisons que l'auteur y a d'abord cru), ce qui effleure tangentiellement le sujet sans l'éclairer vraiment.
Notre lecture
L'observation de l'Effet Matthew sur l'RL pour LLM semble solide et bien documentée sur plusieurs domaines (math, code, agents), mais elle n'est pas révolutionnaire : la communauté RL sait depuis longtemps que les algorithmes de gradient épars (quand pas de signal = pas de mise à jour) régulent les zones d'amélioration. Ce qui est nouveau ici, c'est l'hypothèse que k petit améliore mieux les problèmes durs parce qu'on dépense moins de calcul en faux positifs sur les faciles. À tester et à creuser si vous entraînez vos propres LLM en RL. Pour la plupart des équipes, le sujet reste académique : c'est la version post-training fine-tuned qui en bénéficierait, pas les approches naïves d'RL sur une base existante.