Recherche · 2026-10-24 · Toutes les recherches

+23 points sur un modèle ouvert de 70B, sans nouvelles données humaines. Ce que fait RLVR, et ce qu'il ne fait pas.

Nous avons fait passer Apertus-70B de 41.6% à 64.8% sur des problèmes de code mis de côté en un seul cycle, en laissant le modèle apprendre uniquement de ses propres réponses qui passaient les tests. Nous avons aussi trouvé où la méthode s'arrête.

Photo: Nemuel Sereti / Pexels

Apertus-70B est le modèle entièrement ouvert de la Swiss AI Initiative : poids, données d'entraînement et recette sont tous publics. Ses auteurs l'ont aligné sur des préférences humaines. Il n'avait jamais été entraîné par apprentissage par renforcement à partir de récompenses vérifiables, la technique derrière la plupart des progrès récents en programmation et en mathématiques.

C'était donc un test propre. Si l'on applique la méthode à un modèle qui ne l'a jamais vue, de combien progresse-t-il, et qu'est-ce qui progresse exactement ?

En un cycle, sur des problèmes de code mis de côté, il est passé de 41.6% à 64.8%. Cet article explique comment, et décrit les trois endroits où la méthode a cessé de fonctionner, car ils sont aussi utiles que le chiffre principal.

D'abord, ce qui n'a pas marché : enseigner par l'exemple

La manière intuitive de rendre un modèle meilleur en raisonnement est de lui montrer de bons raisonnements. Nous avons pris des solutions détaillées de haute qualité produites par des modèles plus forts et avons affiné Apertus dessus.

Il s'est dégradé, et d'autant plus que nous l'entraînions. Sur un ensemble de problèmes récents de programmation compétitive, le modèle de base en résolvait 24%. Après 8,000 exemples, il en résolvait 14%. Après 37,000, 10%.

Nous avons vérifié les données, et elles étaient propres. Le problème tenait à ce que le modèle en apprenait. Il a appris à ressembler au modèle plus fort : des explications assurées et bien structurées, suivies d'un code qui ne fonctionnait pas. L'imitation enseigne un style. Elle n'enseigne pas la capacité sous-jacente.

Ce qui a marché : n'apprendre que de ses propres réponses qui passent

L'alternative inverse la source des données d'entraînement. Au lieu d'apprendre des solutions de quelqu'un d'autre, le modèle :

1. génère plusieurs tentatives pour chaque problème,
2. fait vérifier automatiquement chaque tentative, en exécutant les tests ou en comparant la réponse finale,
3. ne garde que les tentatives qui ont réussi,
4. est entraîné sur celles-ci.

Rien n'entre dans le jeu d'entraînement sans avoir été vérifié correct, et tout ce qu'il contient vient du modèle lui-même. C'est toute l'idée de RLVR : la récompense n'est pas l'avis d'un juge, c'est un test qu'on ne peut pas contester.

Sur les mathématiques de niveau primaire (GSM8K), le premier cycle a fait passer Apertus de 65.2% à 74.6%, un gain de 9.4 points. Même mécanique que l'expérience d'imitation. La seule différence était l'origine des données.

Le chiffre qui nous a indiqué la suite

Avant d'investir dans le code, nous avons posé une question de diagnostic simple : le modèle est-il incapable d'écrire ce code, ou simplement peu fiable ?

Les deux se ressemblent si l'on ne laisse le modèle répondre qu'une fois. Ils diffèrent nettement si on le laisse essayer 24 fois. Sur un benchmark de code standard, Apertus résolvait 38.2% des problèmes du premier coup, mais 62.4% au moins une fois en 24 tentatives.

Cet écart de 24 points est la clé. La capacité était déjà là ; le modèle ne la produisait simplement pas de façon régulière. Cela signifiait que nous n'avions pas besoin d'un pré-entraînement supplémentaire coûteux. Il fallait transformer « parfois » en « de manière fiable ».

Le résultat : +23.2 points en un cycle

Nous avons constitué un ensemble de 8,445 problèmes Python vérifiés, chacun avec ses propres tests, et retiré tout ce qui recoupait nos jeux d'évaluation. Apertus a généré des tentatives, chaque tentative a été exécutée contre ses tests, et 11,727 solutions correctes sont devenues le jeu d'entraînement.

Sur des problèmes jamais vus, issus de la même distribution :

C'est le gain le plus important de tout le projet, en un seul cycle, sans aucune nouvelle donnée rédigée par des humains.

Où cela s'arrête

Trois constats définissent les limites de la méthode. Nous pensons qu'ils comptent davantage que le chiffre principal pour quiconque envisage de l'utiliser.

Le gain appartient au type de problème sur lequel on entraîne. Le même modèle amélioré, évalué sur un benchmark de code rédigé dans un autre style, n'a pas progressé du tout : 38.2% avant, 37.8% après. Le modèle est devenu bien meilleur sur les problèmes qu'il a pratiqués, pas en programmation en général. La règle pratique est simple et stricte : entraînez sur la distribution sur laquelle vous serez évalué, et pour une entreprise, cela veut dire sur vos propres tâches.

Cela fonctionne une fois, pas de manière répétée. Un second cycle sur l'ensemble de code n'a rien donné : de 64.8% à 64.0%. En mathématiques, le second cycle n'a ajouté que 1.4 point. La méthode convertit l'écart entre « parfois » et « de manière fiable » en performance, et elle en fait l'essentiel au premier passage. La taille du gain correspond à peu près à la taille de l'écart de départ. Aller au-delà demande des problèmes plus difficiles ou une autre technique, pas davantage de la même chose.

Plus d'entraînement sur les mêmes tentatives dégrade le résultat. Quand nous avons réutilisé un même lot de tentatives générées sur plusieurs passes d'entraînement, la performance a baissé régulièrement, de 76.0% à 74.8%. Après la première passe, le modèle n'est plus celui qui a produit ces tentatives, il apprend donc sur des données périmées. La solution est de régénérer de nouvelles tentatives à chaque cycle plutôt que de réutiliser les anciennes.

Ce que cela signifie pour une entreprise

La méthode est générale. N'importe quel modèle ouvert, n'importe quelle tâche dont la réponse peut être vérifiée automatiquement : du code qui doit passer des tests, des chiffres qui doivent correspondre à une source, un document qui doit respecter un ensemble de règles. La plupart des entreprises en ont plus qu'elles ne le pensent.

Elle fixe aussi des attentes honnêtes. RLVR ne transformera pas un modèle en quelque chose qu'il ne savait pas déjà faire dans un bon jour. Ce qu'elle fait, c'est faire du bon jour le jour normal, exactement sur le travail qui vous importe. Pour la plupart des usages en entreprise, c'est la différence entre une démo et un outil.

Où cela a tourné

Entraîner ainsi un modèle de 70 milliards de paramètres implique de générer et de vérifier des centaines de milliers de tentatives. Nous l'avons fait sur LUMI, le supercalculateur EuroHPC hébergé par CSC à Kajaani, en Finlande, sur des accélérateurs AMD MI250X, dans le cadre d'une allocation attribuée sur concours par l'EuroHPC Joint Undertaking (AI Factory Playground, EHPC-AIF-2026PG01-685).

Nous remercions l'EuroHPC Joint Undertaking d'avoir accordé à ce projet l'accès au supercalculateur EuroHPC LUMI, hébergé par CSC (Finlande) et le consortium LUMI, dans le cadre de l'appel EuroHPC AI Factory Playground Access.