Never Give Up : cette méthode RL révèle que vos benchmarks cachent une stagnation — les problèmes à 0 % de réussite y restent après entraînement

Never Give Up : cette méthode RL révèle que vos benchmarks cachent une stagnation — les problèmes à 0 % de réussite y restent après entraînement

🔎 La courbe monte, mais votre modèle n'apprend plus rien

Mi-septembre 2026, Michael Noukhovitch, Hamish Ivison, Nathan Lambert et Aaron Courville publient sur arXiv un paper qui devrait mettre mal à l'aise quiconque brandit une courbe de récompense RL en pente régulière : Learning to Solve Hard Problems in RL for LLMs by Never Giving Up. Derrière le titre, une démonstration gênante pour tout le secteur.

Le constat tient en une phrase, extraite du billet d'accompagnement de Noukhovitch : « Easy AIME problems improve drastically but problems that start with pass@32=0 mostly end with pass@32=0! ». Traduction : le reinforcement learning améliore drastiquement les problèmes que le modèle sait déjà (un peu) résoudre — et laisse à zéro ceux qu'il ne sait pas faire.

Pourquoi c'est important maintenant ? Parce que le RL est devenu le moteur des modèles de raisonnement, et que les courbes agrégées de benchmarks alimentent threads, slides d'investisseurs et notes de presse. Si ces courbes masquent une stagnation quasi totale sur les problèmes durs, alors une partie de la narrative « les modèles acquièrent de nouvelles compétences » repose sur un artefact statistique. Le paper propose aussi un correctif — NGU, Never Give Up — d'une simplicité désarmante. On décortique.

L'essentiel

• Le RL pour LLMs n'améliore pas uniformément un dataset : gros gains sur les problèmes que le modèle résout déjà parfois, gains quasi nuls sur les autres. Les auteurs nomment ce biais « effet Matthew » — the rich get richer.
• Un problème est dit « dur » quand le modèle de départ affiche un pass@32 = 0 : 32 tentatives, aucune réussite. Après entraînement RL standard, la majorité de ces problèmes restent à 0.
• Les courbes agrégées masquent cette stagnation : les problèmes faciles, plus nombreux et en forte progression, tirent la moyenne vers le haut.
• NGU continue d'échantillonner un problème jusqu'à obtenir une réussite — espérance de k/(1−p) échantillons, soit 40 avec k=4 et p=0,9 — et entraîne sur tous les échantillons accumulés, échecs compris.
• Résultats : NGU bat le GRPO standard à toutes les valeurs de k sur GSM8k platinum ; le scale-up DeepScaler (~120 heures de H100 sur Qwen 3 4B base) améliore surtout les subsets les plus durs d'AIME 2025 et BRUMO 2025 ; sur Manufactoria, le GRPO standard échoue là où NGU itère jusqu'à la réussite complète.
• Limites assumées : échantillons plus off-policy en début d'entraînement, et méthode peu efficace si la tâche est presque entièrement très dure.

Outils recommandés

Le constat : des problèmes à pass@32 = 0 qui y restent

Non, une courbe de récompense RL qui monte ne prouve pas que votre modèle apprend. La question posée par les auteurs — « What is your eval actually measuring? » — mérite d'être posée à chaque annonce d'entraînement.

Rappel express : le pass@k mesure la probabilité de résoudre un problème en k tentatives. Un problème étiqueté « dur » dans ce paper est un problème où le modèle initial, en 32 échantillons, ne produit jamais une seule réponse correcte. Ce n'est pas une abstraction : c'est un plafond mesuré, problème par problème.

L'équipe a ensuite entraîné avec du RL standard et observé ce qui bougeait, difficulté par difficulté, sur des évals code et agentiques : Deepcoder et DeepSWE — deux projets open-source aux modèles et logs publics, et dont nous avons déjà montré qu'ils avaient permis de documenter la triche des agents de code —, LCBv6 avec un découpage par difficulté (Deepseek-R1-Distilled-Qwen-14B), et SWE-Bench platinum, qui fournit des labels de difficulté existants.

Le résultat est identique partout. Les problèmes que le modèle réussissait déjà parfois progressent vite et fort. Ceux qui commençaient à pass@32 = 0 y restent, dans leur écrasante majorité. Le RL n'a pas appris à résoudre de nouveaux problèmes : il a appris à mieux résoudre les anciens.

L'effet Matthew : quand la moyenne ment

Les scores agrégés surestiment structurellement ce que le RL apporte. Un benchmark agrège des dizaines ou des centaines de problèmes en un chiffre. Or ce chiffre est une moyenne pondérée : les problèmes faciles y sont souvent majoritaires, et ce sont eux qui progressent « drastiquement ». Les problèmes durs, peu nombreux et plats, pèsent à peine.

Les auteurs empruntent à la sociologie le terme d'effet Matthew : the rich get richer. Le RL enrichit les modèles là où ils sont déjà riches en capacités. Hugging Face résume le paper en une ligne : « Reinforcement learning for large language models disproportionately improves easy tasks ».

Conséquence dérangeante : un score agrégé en hausse de dix points est parfaitement compatible avec zéro capacité nouvelle acquise. Ce n'est pas de la triche, ni de la contamination — c'est plus insaisissable, un problème de lecture. Et il n'existe qu'un seul antidote : découper les résultats par difficulté, ce que presque aucun communiqué ne fait.

NGU, comment ça marche : réallouer le compute, pas inventer la magie

NGU ne change pas l'algorithme d'apprentissage : il change ce qu'on lui montre. Le diagnostic des auteurs est que les méthodes RL modernes exacerbent l'effet Matthew en gaspillant le compute sur les problèmes faciles. Leur correctif tient en quelques lignes.

La mécanique : on échantillonne k réponses pour un prompt. Si tout est faux, on remet le prompt dans le générateur avec probabilité p, et on répète jusqu'à obtenir une réussite. L'espérance du nombre d'échantillons suit une loi géométrique : k/(1−p). Avec k=4 et p=0,9, un problème têtu reçoit en moyenne 40 échantillons, contre 4 pour un problème facile filtré dès la première passe. Le compute est réalloué, pas augmenté.

Deuxième point, souvent raté dans les résumés : on entraîne sur tous les échantillons accumulés, y compris les échecs. Les tentatives ratées sur les problèmes durs ne sont pas jetées — elles deviennent le signal d'entraînement. C'est là que le RL asynchrone fait le travail : la génération en continu permet de nourrir la boucle sans attendre qu'un lot entier réussisse.

Précision honnête : alphaXiv identifie un précurseur méthodologique proche, une méthode qui ressamplait aussi adaptativement les prompts pour traiter l'undersampling et la perte de signal. NGU n'invente pas la catégorie ; il la dote d'un diagnostic chiffré et de résultats solides.

k=4 contre k=32 : le retournement vers l'étape 200

La dynamique est contre-intuitive. En début d'entraînement, k=32 trouve plus tôt les solutions rares aux problèmes durs. Mais passé un point d'inflexion vers l'étape 200, k=4 fait mieux : filtrer un problème facile exige d'obtenir 4 réussites sur 4, contre 32 sur 32 avec un k élevé. Autrement dit, plus k est grand, plus les problèmes faciles consomment de compute avant d'être écartés.

La formule de l'annonce tient en une ligne : « NGU solve hard prompts like k=32 and filters easy prompts like k=4 ».

Les résultats : GSM8k platinum, DeepScaler, Manufactoria

Les gains sont réels — et concentrés exactement là où les courbes standard ne regardent pas. Trois séries d'expériences structurent le paper.

Sur GSM8k platinum, NGU (k=4, p=0,9) bat toutes les valeurs de k du GRPO standard. Détail qui compte : il résout plus de problèmes durs sans dégrader les problèmes faciles. La réallocation n'est pas un transfert forcé, c'est un désengorgement.

Sur DeepScaler, le scale-up porte sur Qwen 3 4B base, pour environ 120 heures de H100 — un budget de labo académique, pas de géant du cloud. À l'évaluation sur AIME 2025 et BRUMO 2025, les gains se concentrent sur les subsets les plus durs, et DeepScaler affiche la meilleure performance par compute, précisément sur ces problèmes.

Sur Manufactoria, enfin, la démonstration la plus parlante : le GRPO standard avec reward par test n'arrive pas à résoudre complètement des problèmes mêlant tests faciles et tests durs. NGU itère jusqu'à la réussite complète. Sur les tests de code les plus difficiles, l'échantillonnage standard échoue là où la persistance suffit.

Ce que ça implique pour la fiabilité des benchmarks

Un benchmark vedette peut grimper pendant des mois sans qu'aucun problème réellement nouveau ne soit résolu. C'est l'implication la plus inconfortable du paper, et elle dépasse le cercle des chercheurs.

La course aux chiffres récompense le delta agrégé : +X points sur AIME, +Y sur SWE-Bench. Si le delta provient des buckets faciles, la communication dépasse la réalité — un mécanisme que nous suivons de près, du benchmark gaming autour de GPT-5.6 Sol sur Cerebras aux alternatives à SWE-Bench proposées par FrontierCode.

Ce que NGU ajoute à ce débat : même sans triche ni contamination, une courbe honnête peut tromper. La stagnation des problèmes durs est invisible tant qu'on ne découpe pas par difficulté — et SWE-Bench platinum, avec ses labels de difficulté, prouve que le découpage est possible quand la volonté existe.

La question à poser à tout fournisseur de modèle devient donc simple : « montrez-nous la courbe sur les problèmes que votre modèle de départ rate 32 fois sur 32. »

Les limites, assumées par les auteurs

NGU n'est pas une machine à résoudre l'impossible, et le paper ne prétend pas le contraire.

Première limite : en rééchantillonnant un même prompt, on accumule des échantillons plus off-policy en début d'entraînement, ce qui dégrade le signal. Le gain sur les problèmes durs se paie en qualité de gradient temporaire.

Deuxième limite : si la tâche est presque entièrement très dure, NGU perd son levier. Il n'y a plus de problèmes faciles à filtrer pour libérer du compute, et la boucle tourne à vide sur des problèmes peut-être hors de portée.

Troisième limite, plus conceptuelle : le « dur » est défini relativement au modèle de départ et au k choisi. Un pass@32 = 0 pour Qwen 3 4B base n'a rien d'un verdict d'intelligence. Et l'entraînement reste un exercice risqué en soi : le fine-tuning peut casser un modèle de façons bien plus visibles, l'alignement en premier. Réallouer le compute ne corrige pas tout.

Concrètement, qu'est-ce que vous en tirez ?

Trois réflexes, selon votre point de vue.

Si vous entraînez des modèles : découpez vos évals par difficulté (pass@32 = 0 contre pass@32 > 0) avant même de lancer la moindre run RL. C'est gratuit, et c'est la seule façon de savoir si vous apprenez ou si vous polissez.

Si vous évaluez des modèles pour votre stack : exigez des fournisseurs les breakdowns par difficulté, et méfiez-vous des moyennes seules. Un modèle peut gagner deux points agrégés en régressant sur tout ce qui vous intéresse.

Si vous voulez vérifier vous-même : les modèles utilisés dans le paper (Qwen 3 4B base, Deepseek-R1-Distilled-Qwen-14B) et les open-weights auto-hébergeables comme GLM-5 ou Kimi K2.6 permettent de lancer vos propres campagnes pass@k. Un serveur chez Hostinger (à partir de quelques euros par mois, septembre 2026, vérifiez sur hostinger.fr) suffit pour héberger l'infrastructure d'évaluation de modèles 4B à 14B. La méthode du paper — étiqueter, découper, mesurer — tient dans un notebook.

❌ Erreurs courantes

Erreur 1 : lire une courbe agrégée comme un progrès uniforme

Une moyenne qui grimpe peut cacher un 0 % plat sur les problèmes durs — le paper le démontre sur AIME, LCBv6 et SWE-Bench platinum. La solution : tracez vos courbes par bucket de difficulté et regardez-les séparément, jamais empilées.

Erreur 2 : payer k=32 partout « pour être sûr »

Un k élevé trouve plus tôt des solutions rares, mais il fait payer les problèmes faciles au prix fort : il faut 32 réussites sur 32 pour les filtrer, contre 4 sur 4 avec k=4. Après l'étape ~200, k=4 fait mieux. La solution : un échantillonnage adaptatif qui dépense le compute là où il manque.

Erreur 3 : jeter les échecs sur les problèmes durs

Beaucoup de pipelines écartent les prompts sans aucune réussite, faute de signal exploitable. C'est précisément ce qu'il ne faut pas faire : ces trajectoires sont votre seule matière première sur les problèmes durs. NGU entraîne sur tous les échantillons accumulés, échecs compris.

Erreur 4 : confondre « dur pour ce modèle » et « dur tout court »

Le pass@32 = 0 est relatif à un modèle de départ et à un k. Recalibrez vos étiquettes de difficulté à chaque changement de modèle de base, sinon vous optimisez contre un mirage — et vous communiquerez sur un mirage.

❓ Questions fréquentes

Le pass@32 mesure quoi, exactement ?

Le taux de réussite en 32 tentatives indépendantes sur un même problème. Un pass@32 = 0 signifie que sur 32 générations, aucune n'était correcte. Dans le paper, ce seuil définit les problèmes « durs » : le modèle n'a pas accès à la solution, même par tirage aléatoire sur ses propres distributions.

Le code et les données de NGU sont-ils publics ?

Le paper est librement accessible sur arXiv, détaillé sur le blog de l'auteur, et les évals mobilisées (Deepcoder, DeepSWE) sont open-source avec modèles et logs publics. La méthode elle-même tient en quelques lignes — rééchantillonner avec probabilité p, entraîner sur tout — et se réimplémente dans n'importe quelle boucle RL asynchrone.

NGU remplace-t-il le GRPO ?

Non. NGU est une stratégie d'échantillonnage qui se greffe sur une boucle RL existante — le paper le combine justement avec du GRPO sur du RL asynchrone. Il ne modifie ni la fonction de récompense ni l'objectif : il décide seulement quels prompts reçoivent du compute, et combien d'échantillons chacun mérite.

Est-ce transposable aux modèles propriétaires comme GPT-5.5 ?

Personne ne le sait : les expériences portent sur des modèles ouverts (Qwen 3 4B base, Deepseek-R1-Distilled-Qwen-14B). Mais le diagnostic, lui, est universel : quel que soit le modèle, exigez un découpage des résultats par difficulté avant de conclure qu'un entraînement a apporté de nouvelles capacités.

Combien coûte une reproduction ?

Le scale-up DeepScaler du paper représente environ 120 heures de H100 sur Qwen 3 4B base — de l'ordre de quelques centaines d'euros en location GPU ponctuelle. Les expériences principales (GSM8k platinum, LCBv6) tournent sur des modèles 14B, donc accessibles à un labo académique ou une équipe produit motivée.

✅ Conclusion

Ce paper ne dit pas que le RL ne marche pas : il dit que vos chiffres, tels qu'ils sont présentés, ne prouvent pas qu'il marche — et NGU montre qu'on peut faire mieux à budget constant. Avant votre prochaine run RL, découpez vos évals par difficulté : le billet des auteurs est la meilleure porte d'entrée.