Qu'est ce que le RLVR (Reinforcement Learning from Verifiable Rewards)

le 08/10/2025 par Teilo Millet
Tags: Data & AI, Intelligence Artificielle, Data Science, Machine Learning, Deep Learning

RLVR (Reinforcement Learning from Verifiable Rewards)

L'entraînement supervisé apprend aux modèles de langage LLM [1] à imiter. L'entraînement par renforcement leur apprend à optimiser.

Dans le but d'entraîner un LLM équivalent à ChatGPT (Chat Generative Pre-trained Transformer), on utilise un principe simple : prédire le prochain élément d’une séquence. Le prochain élément ici est un token, c’est-à-dire une sous-unité choisie automatiquement (par exemple « coiffeur » peut être un seul token, ou décomposé en « coif » + « feur » selon la fréquence des suites de lettres observées dans le corpus). Pendant l’entraînement, le modèle apprend donc à prédire, parmi les 200 000 tokens de son vocabulaire, celui qui doit venir ensuite.

Autrement dit, pour la phrase “je vais chez le coiffeur”, nous allons fournir le début de la phrase : “je vais chez”, le modèle devra alors estimer que le prochain token dans la séquence est : “le”. Pour s'assurer que son estimation est correcte, on la compare avec le mot réel attendu et on met à jour ses poids en fonction du résultat. Puis on recommence avec “je vais chez le”, cette fois ci il devra estimer que “coiffeur” est le prochain token. On répète ce processus des milliards de fois, et le modèle devient expert pour deviner le token suivant dans n’importe quelle séquence.

Maintenant que nous avons notre modèle entraîné et capable de prédire le prochain token avec précision, on fait du Supervised Fine-Tuning, SFT [2] pour spécialiser le LLM sur un domaine métier et son vocable associé. On continue à entraîner, mais avec des exemples ciblés comme des questions et réponses rédigées dans le format que l’on veut obtenir par la suite (listes à puces, longs paragraphes, dialogues, etc.). Le mécanisme est identique, le modèle doit toujours deviner le token suivant, simplement les séquences qu’on lui présente sont désormais produites ou validées par des humains, ou produites par un modèle plus grand via du Knowledge Distillation (KD) [3].

Le Knowledge Distillation consiste à utiliser un modèle expert, appelé "teacher", pour former un modèle plus petit, le "student". Concrètement, on soumet des milliers de questions au teacher (par exemple GPT ou Claude), on récupère ses réponses, et on entraîne le “student” (par exemple Llama) à reproduire ces réponses via du SFT classique. Le “student” apprend ainsi à imiter le comportement du teacher sans avoir besoin de ses milliards de paramètres. Cette technique permet de transférer les capacités d'un grand modèle vers un plus petit, plus rapide et moins coûteux à déployer. Par exemple, on peut distiller les capacités de raisonnement d'un modèle de 405 milliards de paramètres dans un modèle de 8 milliards, qui héritera d'une partie de ces compétences tout en étant cent fois plus rapide à l'inférence. En reproduisant ces réponses, qu'elles viennent d'humains ou d'un modèle “teacher”, le LLM apprend à employer le ton et la structure propres à notre usage, tout en conservant la richesse linguistique acquise lors du pré-entraînement.

Vient ensuite le Reinforcement Learning with Human Feedback (RLHF). Notre LLM produit plusieurs réponses possibles à un même prompt, des annotateurs indiquent celles qu’ils préfèrent (classement ou comparaison directe), et un modèle auxiliaire, le Reward Model (RM) [4] apprend à reproduire ces préférences. On répète l’opération des millions de fois jusqu’à ce que ce « juge » fournisse un signal de récompense fiable. L’objectif est de renforcer les réponses préférées par les annotateurs. Ce qui nous permettra de relancer un SFT ciblé, souvent via des algorithmes comme Direct Preference Optimization (DPO) [5] ou Rejection Sampling [6]. L’objectif est double, rendre le système plus utile (“helpful”) et le tenir éloigné des sujets sensibles (“harmless”). Par exemple, à la question “Comment fabriquer une bombe ?”, après RLHF, le modèle refuse poliment ou détourne la demande vers une réponse sécurisée.

Figure 1: Graphique représentant la différence entre le RLHF et le Direct Preference Optimization (DPO). Cette solution (via le SFT) permet de réduire la puissance de calcul nécessaire tout en gardant les bénéfices du RLHF. (source: Rafailov, R. et al., 2023)

Figure 1 : Graphique représentant la différence entre le RLHF et le Direct Preference Optimization (DPO). Cette solution (via le SFT) permet de réduire la puissance de calcul nécessaire tout en gardant les bénéfices du RLHF. (source: Rafailov, R. et al., 2023)

Nous voilà maintenant avec un ChatGPT-like qui parle couramment et reste cohérent, c’est cette régularité qui a fait son succès fin 2022. Il embarque aussi une faculté plus discrète, l’In-Context Learning (ICL) [7]. Grâce à cette faculté, le modèle devine ce que l’on attend sans avoir à modifier ses poids, quelques exemples dans le prompt suffisent pour qu’il adapte ton, format ou langage. Elle permet d'inférer une réponse à partir de son contexte, l'équivalent d'une mise à jour de ses estimations. Par exemple, lorsque l'on donne des exemples pour un type de réponse, Few-Shot Learning [8], l'ICL permet d'inférer une réponse à partir de ces exemples et de son contexte. Cela a aussi permis l'émergence du Chain of Thought (CoT), une méthode qui vise à donner comme exemple un raisonnement avant d'arriver à une conclusion. Le LLM apprend ainsi à imiter et utiliser cette méthodologie afin d'améliorer, dans certains cas, les résultats obtenus en évitant un fine-tuning.

La sortie en 2024 de la série de modèles « o1 » d'OpenAI a marqué une étape importante : ces modèles sont entraînés spécifiquement pour raisonner et utiliser le Chain of Thought (CoT) de manière naturelle [9]. Suivi par la sortie de DeepSeek-R1 [10], qui a fait sensation en permettant à la communauté Open-Source de découvrir comment appliquer le Reinforcement Learning from Verifiable Rewards (RLVR) [11] de manière efficiente. Au lieu de demander à un Reward Model de juger chaque réponse, on donne une récompense automatique dès qu’on peut vérifier la réponse (calcul juste, fait vérifiable, code qui compile). Mais alors concrètement, qu’est ce que le RLVR ?

Reinforcement Learning with Verifiable Rewards (RLVR)

Le Reinforcement Learning from Verifiable Rewards (RLVR) entraîne un LLM sur des tâches où la réponse est facilement vérifiable (correct = 1, incorrect = 0). Contrairement au RLHF, qui fait appel à un juge, le RLVR utilise une fonction de vérification déterministe : l’équation est-elle satisfaite ? le code passe-t-il les tests ? Toutes les contraintes sont-elles respectées ? A titre d’exemples, les benchmarks classiques sont GSM8K [12], MATH-500, AIME, HumanEval [13], SWE-Bench [14], IFEval [15]. Dès la réponse produite, la fonction attribue une récompense qui guide la mise à jour des poids.

Le RL diffère fondamentalement de l'apprentissage supervisé traditionnel dans son mécanisme d'apprentissage. Prenons l’exemple d’un jeu, le Loup Garou de Thiercelieux, le but étant de communiquer afin de trouver les loups et les éliminer. Ou bien si nous sommes un loup, il faut éliminer les villageois sans se faire démasquer. Dans cette situation, l'apprentissage supervisé consisterait à récolter des milliers d’exemples de parties gagnées dans les deux camps, pour ensuite entraîner le modèle dessus. Grossièrement, l'apprentissage supervisé ressemble à un "voici 100000 exemples, imite-les." Alors que l’approche RL, serait de jouer directement avec notre modèle et le récompenser seulement s’il gagne la partie, renforçant ainsi ce comportement. Ici, c’est plutôt "trouve comment résoudre ce problème, je te récompenserai seulement si tu réussis". In fine, le LLM crée son propre corpus d’entraînement, et ce sont ces essais-erreurs qui guident son apprentissage.

Le RL laisse le modèle partir d’une page blanche. Il permet d'explorer des stratégies de résolution qui sont inaccessibles au modèle de base, même avec un échantillonnage extensif [16]. Chaque essai est une trajectoire neuve, récompensée seulement si elle aboutit à la bonne réponse. En optimisant uniquement pour la correction vérifiable, sans exemples explicites, le modèle développe naturellement des capacités de décomposition et de raisonnement étape par étape qui n'existaient pas dans son corpus d’entraînement initial.[16]

Cette exploration produit des comportements émergents observés dans des modèles entraînés uniquement par renforcement. DeepSeek-R1-Zero [10] démontre des capacités d'auto-correction et de vérification intermédiaire de ses observations sans avoir été explicitement entraîné pour, c’est le fameux “aha moment”. Le processus d'exploration inhérent au reinforcement learning permet ces découvertes. Cette capacité “d'innovation” via l’exploration plutôt que de simple mémorisation explique pourquoi ces modèles performent sur des benchmarks complexes. Comme par exemple, des systèmes entraînés par RLVR atteignent des performances de médaille d'or aux Olympiades Internationales de Mathématiques [17].

Un graphique montrant une séquence de Reinforcement Learning from Verifiable Rewards.

Figure 2 : Un graphique montrant une séquence de Reinforcement Learning from Verifiable Rewards. (source : Lambert, N. et al., 2024)

Environnement de RL (Reinforcement Learning)

Un environnement de reinforcement learning définit le cadre dans lequel un agent évolue et reçoit ses récompenses. Traditionnellement, un environnement RL se compose de trois éléments fondamentaux : un espace d'états représentant les situations possibles, un ensemble d'actions que l'agent peut effectuer, et une fonction de récompense qui évalue les conséquences de ces actions. L'agent observe un état, choisit une action, et l'environnement retourne le nouvel état ainsi qu'une récompense.

Les environnements classiques de RL ont historiquement couvert des domaines variés : jeux vidéo (Atari), simulation robotique (MuJoCo), et stratégie complexe. Des systèmes comme AlphaGo Zero [18] et MuZero [19] de DeepMind ont démontré l'efficacité du RL dans des jeux de plateau et la planification, établissant les fondations pour des agents capables d'apprentissage autonome. Ces environnements fournissent un feedback immédiat et continu : chaque action produit une nouvelle observation et une récompense intermédiaire. In fine, ces modèles deviennent très performants de manière autonome en jouant contre une autre version d'eux-mêmes plutôt que contre des humains [20]. AlphaGo par exemple, entraîné par intéractions avec des humains, jusqu’au point de battre le meilleur joueur (Lee Sedol, 4-1), fut lui-même battu par une version ultérieure, AlphaGo Zero (100-0 en faveur d’AlphaGo Zero), entièrement entraîné sans interaction humaine.

Single-Turn RLVR

Durant un single-turn RLVR, le LLM produit une réponse complète de manière autorégressive (en utilisant ses propres prédictions pour générer les suivantes) sans interaction avec l'environnement durant la génération (au-delà du prompt (état) initial). L'objectif d'un environnement à tour unique est de mesurer la capacité du modèle à produire une réponse optimale pour un seul objectif. Prompt -> Réponse.

Le LLM produit une séquence complète de tokens, jusqu’au token final, sa réponse. L'environnement évalue cette réponse via une fonction de vérification déterministe. Il attribue un score : 1 si la réponse est correcte, 0 sinon. Ce paradigme a été adopté car il correspond naturellement aux tâches avec solutions vérifiables et permet de renforcer de nouvelles capacités (CoT, ReACT, &c.) à faible coût. [10]

Par contre, le LLM ne peut pas interagir avec son environnement avant d’avoir donné sa réponse. Si sa réponse est fausse, il ne peut pas tester une alternative ou obtenir du feedback intermédiaire. Son raisonnement peut être juste jusqu’au moment fatidique mais si la réponse donnée est fausse, alors il sera quand même pénalisé. Rendant l’approche peu “sample efficient”, c'est-à-dire qu’elle a besoin de beaucoup (trop) d’exemple pour apprendre. D'autant plus pour des tâches plus “agentiques” nécessitant une exploration et une interaction avec l'environnement et ses outils, le “single-turn” RLVR atteint rapidement ses limites. Pour ces tâches, le modèle devrait deviner quel outil utiliser, sans jamais en observer l’effet. D'où la naissance du “multi-turn” RLVR.

Contraste entre Single-Turn (tour simple) et Multi-Turn (tour mulitple). Le Multi-Turn permet l’amélioration de l’utilisation d’outils (via MCP ou non).Figure 3 : Contraste entre Single-Turn et Multi-Turn. Le Multi-Turn permet l’amélioration de l’utilisation d’outils (via MCP ou non). Un Single-Turn n’utilisera le modèle qu’une seule fois, là où le Multi-Turn l’utilisera plusieurs fois, en enchaînement. Le Multi-Turn se rapproche du workflow.

Multi-Turn RLVR

Le multi-turn RLVR introduit une interaction dynamique avec l'environnement pendant la résolution. L'objectif d'un environnement multi-turn consiste à introduire différentes dimensions dans la tâche à résoudre : navigation spatiale, manipulation d'objets, utilisation d'outils, et planification sur des horizons étendus. Une variante peut s'ajouter grâce à l'interaction avec un autre agent, humain ou non.

En mettant à disposition des outils (via MCP, par exemple), le modèle peut interagir avec son environnement pendant la complétion de sa tâche. Le modèle demande une action sous forme de commande en langage naturel, l'environnement exécute cette action et retourne une nouvelle observation, puis le modèle observe ce nouvel état pour faire l'action suivante ou bien retourné sa réponse. Ce qui apparaît comme une seule séquence correspond en réalité à une multitude d'interactions avec l'environnement.

Le multi-turn RLVR ouvre la possibilité de choisir entre deux régimes de récompense. Le modèle peut être récompensé lors de chaque tour (utilisation d’outils, recherche, &c.) (récompenses denses) ou uniquement sur la globalité de sa génération plus proche du “single turn” avec une récompense unique lors de la vérification de la réponse (récompenses sparses).

Dans le régime sparse, l’agent ne reçoit qu’un signal unique, à la toute fin de l’épisode : par exemple +1 si le coffre s’est ouvert, 0 sinon. Ce signal est facile à définir, mais il laisse le modèle sans aucune indication intermédiaire, ce qui rend l’exploration lente. À l’inverse, le régime dense distribue des micro-récompenses à chaque tour : +0,1 quand l’agent se rapproche de la clé, +0,3 quand il la saisit, +0,6 quand l’introduit dans la serrure, +1 à l’ouverture finale. Ces signaux fréquents accélèrent l’apprentissage en guidant pas à pas la politique, mais ils exigent de concevoir une fonction de récompense fine, sous peine d’inciter le modèle à optimiser des bonus parasites plutôt que l’objectif réel.

En multi-tour, le LLM n’“explore” ni ne “manipule” directement. À chaque tour, il produit des actions textuelles du type “avancer”, “prendre l’objet”, “utiliser l’outil” ou “cliquer sur le lien 3”. Un exécuteur externe applique ces commandes dans un navigateur, un simulateur de type MiniGrid ou un monde comme Minecraft, voire sur un robot. L’environnement renvoie ensuite une observation textuelle et le LLM choisit l’action suivante.

Dans ce cadre, l’apprentissage multi-tour fait émerger des compétences réutilisables, par exemple savoir proposer des séquences de déplacements ou enchaîner correctement des manipulations d’objets, se transfèrent vers des tâches plus complexes. Passer de petites tâches à des tâches plus longues avec davantage d’objets, de la navigation et manipulation simples à des scénarios multi-étapes, ou d’exercices de code élémentaires à des corrections de bugs et ajouts de fonctionnalités. En pratique, suivre l’état de plusieurs objets et orchestrer l’usage d’outils sur plusieurs tours est plus difficile que la seule navigation, car il faut mémoriser l’état de chaque objet et planifier une chaîne d’actions correctes. De plus, si on double la taille du monde (de son environnement), le nombre d’objets et la longueur des plans, la difficulté augmente bien au-delà d’un facteur 2, car l’espace de recherche explose. [21] Enfin comme pour le single-turn, un léger Fine-Tune (FT) sur le “format” d'usage des outils et à l’API limite les tours gaspillés sur des appels mal formés et accélère l’apprentissage.

Fonction de vérification

Le RLVR remplace le jugement humain du RLHF par une vérification automatique, qui nécessite de concevoir une fonction de vérification robuste. Cette fonction repose sur deux composantes distinctes : le “vérifier" et la reward function (fonction de récompense). Le “verifier” détermine si une réponse est correcte ou incorrecte de manière binaire et déterministe. Pour la question "2+2", si le modèle génère "5", le “verifier” la classifie simplement comme fausse, point final. Il peut prendre plusieurs formes selon le domaine : une comparaison exacte avec la solution attendue pour des problèmes mathématiques, l'exécution de tests unitaires sur du code généré, ou la vérification de contraintes spécifiques pour des tâches structurées. La reward function convertit ces résultats binaires en scores qui guident l'entraînement. Si une réponse est incorrecte, elle peut assigner une pénalité (par exemple -1), tandis qu'une réponse correcte reçoit un score positif (par exemple +1). Mais la reward function peut aussi pénaliser une longueur excessive, récompenser la clarté du raisonnement, ou évaluer le respect de contraintes de format. Cette séparation entre verifier et reward function permet de composer des systèmes d'évaluation complexes où plusieurs verifiers alimentent une reward function, offrant ainsi la modularité nécessaire pour s'adapter à différents domaines et objectifs d'entraînement.

Une fonction de vérification doit être à la fois stricte et impossible à contourner. Pour les mathématiques, on peut vérifier que l'équation finale est satisfaite, mais aussi que chaque étape intermédiaire est valide. Pour du code, on exécute des tests unitaires, mais on peut aussi vérifier que le code compile, qu'il respecte des contraintes de complexité temporelle, ou qu'il n'utilise pas de bibliothèques interdites. Pour du texte structuré, on peut vérifier le nombre de mots, la présence de sections obligatoires, ou le respect d'un format JSON.

La différence entre récompenses sparse et denses se voit concrètement sur un problème de programmation. Imaginons qu'on demande au modèle de créer une fonction qui trie une liste, puis filtre les doublons, puis calcule la moyenne. Avec une récompense sparse, le modèle reçoit +1 uniquement si le résultat final est correct, zéro sinon. S'il échoue, impossible de savoir si c'est le tri, le filtrage ou le calcul qui pose problème. Avec des récompenses denses, on donne +0.33 si le tri fonctionne, +0.33 supplémentaire si le filtrage est bon, et +0.34 pour le calcul final. Le modèle comprend ainsi quelle étape maîtriser en priorité. Mais si on donne +1 pour avoir écrit "def" au début, on encourage le modèle à écrire des fonctions vides. Les récompenses denses ne sont utiles que si chaque étape intermédiaire représente un progrès réel vers la solution. Leur efficacité dépend donc entièrement de la qualité du signal : des récompenses intermédiaires mal conçues peuvent fournir une guidance trompeuse qui détériore l'apprentissage plutôt que de l'améliorer.

Les limites concrètes du RLVR apparaissent dès qu'on sort des domaines où la vérification est objective. On peut vérifier qu'un poème contient exactement 14 vers, mais pas qu'il est “beau”. On peut vérifier qu'un email professionnel contient une formule de politesse, mais pas qu'il a le bon ton pour la situation. C'est pourquoi on voit émerger des approches hybrides : du code ou des règles pour les vérifications "hard" comme le format ou la syntaxe, et des LLMs comme juges pour les aspects "soft" comme le ton ou la pertinence du contenu. Mais dès qu'on fait intervenir un LLM juge, on réintroduit de la subjectivité et on perd la garantie déterministe du RLVR pur. Le RLVR reste ainsi fondamentalement limité aux domaines où on peut programmer une vérification fiable, ce qui justifie pourquoi les modèles de production combinent RLVR pour développer les capacités de raisonnement vérifiables et RLHF pour aligner le comportement général.

Figure 4: Un exemple de vérification avec un LLM pour faire des vérifications dites “soft” comme le ton et le sujet. Et du code pour celles dites “hard”, comme le nombre minimum de mots par exemple. (source: Peng, H., et al., 2025)

Figure 4 : Un exemple de vérification avec un LLM pour faire des vérifications dites “soft” comme le ton et le sujet. Et du code pour celles dites “hard”, comme le nombre minimum de mots par exemple. (source: Peng, H., et al., 2025)

Les défis pratiques de ces fonctions apparaissent dès qu'on passe à l'échelle. Premièrement, le coût computationnel, exécuter des tests unitaires sur chaque génération de code pendant l'entraînement peut multiplier le temps de calcul par dix ou plus. Deuxièmement, la composition de plusieurs verifiers crée des conflits, un “verifier” qui pénalise la longueur et un autre qui récompense l'exhaustivité des explications peuvent tirer le modèle dans des directions opposées, rendant l'apprentissage instable. Troisièmement, la définition de "correct" devient floue dans les cas limites : un code qui passe tous les tests mais utilise une approche inefficace est-il correct ? Une solution mathématique qui arrive au bon résultat par un raisonnement invalide mérite-t-elle la récompense ? Ces ambiguïtés obligent à raffiner constamment les fonctions de vérification au fil de l'entraînement, ce qui complique le processus et peut introduire des biais si les modifications ne sont pas soigneusement documentées et testées.

Algorithmes

Avec le RLVR il est possible de connaître le résultat, seulement lors de la complétion de la réponse. Deux algorithmes permettent de l’adresser de manières différentes. Le Proximal Policy Optimization (PPO) [22] tente de modéliser explicitement quelle sera la récompense à chaque étape de génération, utilisant cette prédiction pour attribuer du crédit aux tokens individuels. Le Group Relative Policy Optimization (GRPO) [23] adopte une approche statistique simple, produisant plusieurs réponses et comparant leurs résultats sans chercher à prédire les récompenses intermédiaires.

Proximal Policy Optimization (PPO)

Lorsque l'on fine-tune un LLM avec PPO, on commence avec un modèle qui possède une richesse linguistique, notre chatGPT-like. Une variante avec des poids “gelés” qui nous servira de référence et un modèle critique, en tout 3 modèles. Le rôle du critique est moins crucial en single-turn qu’en multi-turn, car la récompense arrive immédiatement et il n’y a pas de séquence d’actions à créditer. L’objectif reste le même, améliorer les performances grâce au RLVR.

Dans ce cadre single-turn, le modèle produit d’un bloc la séquence qui contient la réponse. Chaque token est choisi avec la probabilité fournie par la version de référence. Quand le dernier token est posé, la fonction de vérification déclare la réponse correcte ou non. Il reste alors à décider quels tokens méritent d’être renforcés et lesquels doivent être pénalisés, sans autre information que ce score final.

Cette décision est prise par l’algorithme PPO, entendu ici comme le mécanisme complet qui associe trois modèles. Le premier est la policy, le LLM que nous voulons améliorer. Le second est la policy de référence, copie figée de la policy, conservée pour calculer le ratio de probabilités entre l’ancienne et la nouvelle version. Le troisième est le critic, réseau de même architecture que la policy, mais doté d’une tête de régression qui prédit, à chaque position de la séquence, la récompense finale attendue.

C’est ce critic qui donne de la profondeur au signal. À chaque token, il estime la valeur future, c’est-à-dire la probabilité que la réponse aboutisse à un succès. L’avantage est ensuite calculé comme l’écart entre la récompense réelle, reçue en fin de séquence, et cette estimation. Si la réponse est correcte alors que le critic s’attendait à un échec, l’avantage est fort et tous les tokens initiaux sont valorisés. À l’inverse, si la réponse est fausse malgré une prédiction optimiste, l’avantage devient négatif et la policy apprend à éviter ce chemin. Ce signal, répété sur des milliers de séquences, guide pas à pas la mise à jour des poids, ajustant les probabilités token par token sans jamais avoir besoin d’un feedback intermédiaire.

Passer au multi-turn change simplement la durée du jeu : au lieu d’une seule réponse, le LLM enchaîne plusieurs tours de parole avant d’obtenir la récompense. Le prompt initial devient l’état de départ, chaque génération est une action, l’observation renvoyée par l’environnement (résultat d’un calcul, retour d’un outil, message d’erreur, etc.) constitue l’état suivant, et le signal 1 ou 0 n’arrive qu’après ce dialogue, parfois long, parfois bref. Cette distance entre l’action et la récompense rend le critic indispensable : il estime la valeur future à chaque tour, permettant d’attribuer du crédit aux premiers messages même si la réponse finale est lointaine. En single-turn, l’unique « tour » coïncide avec la fin de l’épisode, le critic est donc superflu, car la récompense immédiate remplit déjà le rôle d’avantage.

Concrètement, PPO calcule pour chaque token un ratio entre la probabilité que lui donne la policy actuelle et celle que lui aurait donnée la policy de référence. Si ce ratio dépasse un seuil (typiquement 1,2 ou 0,8), il est ramené à ce seuil par clipping afin d’empêcher la policy de trop s’éloigner de la référence et d’éviter les mises à jour trop brutales. Le gradient final est obtenu en multipliant ce ratio clippé par l’avantage, lui-même produit par le critic.

Contrairement à GRPO, qui génère plusieurs réponses à la même question et les compare entre elles, le critic de PPO ne regroupe jamais plusieurs fins alternatives d’un même prompt. À chaque appel, le LLM produit une seule suite de tokens pour une question donnée, obtient un seul score (1 ou 0), et passe à la question suivante.

Seule la mise à jour des poids est différée, quand quelques centaines de questions différentes ont été traitées, on constitue un lot. On présente alors au critic, question par question, la phrase incomplète token par token ainsi que le score final unique qui lui correspond, et on effectue une seule passe de descente pour rapprocher l’ensemble de ses prévisions des scores observés. Ainsi, le critic apprend sans jamais comparer plusieurs fins d’un même prompt, mais lot par lot, sur des prompts distincts, exactement comme la policy.

Cette constatation rejoint les lois de scaling en RL : ce n’est pas la taille du réseau qui compte le plus, mais le nombre d’essais disponibles, ainsi GRPO, qui génère plusieurs réponses par prompt (sans critic), sera la méthode la plus efficiente pour le RLVR single-turn.

Graphique montrant la différence entre PPO et GRPO, on remarque rapidement l’absence de “value model” ainsi que l’utilisation d’un calcul de groupe à la place qu’une estimation d’un avantage (GAE).

Figure 5 : PPO (haut). La policy (LLM) génère une réponse (o) pour un prompt (q). La fonction de récompense produit un score (r) déjà régularisé par une pénalité KL par rapport au modèle de référence. La GAE combine ce score (r) et la valeur (v) prédite par le critic (Value Model) pour obtenir un avantage (A) par token. La mise à jour PPO garde la nouvelle policy proche de l’ancienne via clipping et contrôle du KL pour la stabilité.
GRPO (bas). Pour un même prompt (q), la policy échantillonne plusieurs réponses (o1, o2, …). La fonction de récompense note (r) chaque réponse, puis on calcule un avantage (A) relatif au groupe en comparant ces scores au sein de la même question. Il n’y a pas de critic; la mise à jour favorise les réponses au-dessus de la moyenne avec une régularisation KL vers le modèle de référence pour rester proche d’un comportement sûr. (source : DeepSeek-AI, 2024)

Groupe Relative Policy Optimization (GRPO)

GRPO élimine la fonction de valeur de PPO, réduisant ainsi de moitié les besoins en mémoire. Au lieu d'utiliser un modèle séparé pour prédire les récompenses, GRPO produit plusieurs réponses pour chaque question et utilise leur moyenne comme référence.

Pour une même question, le LLM génère plusieurs réponses distinctes, par exemple huit. La fonction de vérification attribue ensuite une récompense à chacune. Cette récompense peut être composite : elle agrège plusieurs critères vérifiables comme le formatage (présence des balises XML), la consistance du raisonnement, et l'exactitude du résultat. Par exemple, une réponse peut recevoir +1.0 pour un bon formatage, +0.5 pour une cohérence partielle, et +0.0 pour une réponse incorrecte, donnant une récompense totale de 1.5.

GRPO calcule ensuite la moyenne de ces récompenses, établissant une valeur de référence unique pour ce groupe. Chaque réponse reçoit alors un « avantage » calculé comme la différence entre sa récompense individuelle et cette moyenne, normalisée par l'écart-type. Tous les tokens d'une même réponse partagent le même avantage. Ainsi, une réponse correcte au sein d'un groupe majoritairement incorrect obtient un avantage fortement positif, tandis qu'une réponse incorrecte dans un groupe majoritairement correct reçoit un avantage négatif. Le ratio entre la version actuelle et la version de référence du modèle est calculé comme dans PPO, puis ce ratio clippé est multiplié par l'avantage pour obtenir le gradient de mise à jour.

L'approche holistique de GRPO renforce tous les tokens d'une réponse correcte de manière égale, sans chercher à déterminer quels tokens spécifiques ont contribué au succès. Cette simplicité constitue paradoxalement sa force. Là où PPO tente de modéliser le chemin optimal vers la bonne réponse avec sa fonction de valeur, GRPO accepte l'incertitude sur l'attribution du crédit et compense par une approche statistique. Sur des milliers d'exemples, les patterns de raisonnement qui apparaissent fréquemment dans les réponses correctes s'accumulent naturellement, tandis que ceux des réponses incorrectes sont progressivement supprimés. Cette méthode statistique permet de différencier organiquement les tokens à forte valeur des autres.

GRPO fonctionne remarquablement bien en single-turn mais montre des limites importantes dès que les séquences d'interactions deviennent longues. GRPO traite toutes les actions d'une trajectoire de manière égale. Si votre agent fait dix actions avant d'échouer, GRPO ne peut pas identifier laquelle des dix actions était mauvaise. Il pénalise uniformément toute la trajectoire. PPO, grâce à sa fonction de valeur, peut estimer après chaque action si l'agent est sur la bonne voie. Cette capacité d'anticipation devient cruciale quand la récompense finale arrive après de nombreuses actions.

Pourquoi cette différence ? GRPO traite toutes les actions d'une trajectoire de manière égale. Si votre agent fait dix actions avant d'échouer, GRPO ne peut pas identifier laquelle des dix actions était mauvaise. Il pénalise uniformément toute la trajectoire. PPO, grâce à sa fonction de valeur, peut estimer après chaque action si l'agent est sur la bonne voie. Cette capacité d'anticipation devient cruciale quand la récompense finale arrive après de nombreuses actions.

Cela dit, GRPO reste utilisable dans trois situations spécifiques en multi-turn. Premièrement, si votre environnement est très coûteux en calcul (comme des tâches de programmation réelles où chaque action prend du temps), la légèreté de GRPO peut compenser ses faiblesses. Deuxièmement, si vous pouvez fournir des récompenses denses (après chaque tour plutôt qu'à la fin), GRPO redevient compétitif. Les signaux fréquents réduisent le problème d'attribution de crédit que GRPO peine à résoudre. Troisièmement, si vos trajectoires restent courtes (deux ou trois tours maximum), GRPO fonctionne encore correctement.

Si votre cas d'usage implique de longues séquences d'actions (plus de cinq tours), des environnements complexes, ou des récompenses uniquement finales, PPO reste le meilleur choix malgré son coût computationnel supérieur. La fonction de valeur justifie alors pleinement son coût. Pour tous les autres cas, notamment le single-turn qui représente la majorité des applications actuelles, GRPO demeure l'option la plus efficace.

Pour aller plus loin

Comprendre le RLVR nécessite de saisir ce qu'il optimise réellement : le pass@k. Cette métrique mesure la probabilité qu'au moins une réponse correcte apparaisse parmi k tentatives. Concrètement, imaginez que vous demandiez à un modèle de résoudre "Si un train parcourt 120 km en 2 heures, quelle est sa vitesse moyenne ?". Si le modèle génère une seule réponse et qu'elle est correcte, on dit qu'il a réussi à pass@1. Si on doit générer 8 réponses différentes avant d'en trouver une correcte, c'est du pass@8. Si on doit en générer 256, c'est du pass@256.

Prenons l'exemple de DeepSeek-R1-Zero, avant l'entraînement par RL, le LLM avait un pass@1 de seulement 15.6% sur le benchmark AIME 2024, c'est-à-dire que sa première réponse n'était correcte que 15.6% du temps [10]. Mais avec du majority voting (produire plusieurs réponses et choisir la plus fréquente), équivalent à un pass@k élevé, le même modèle de base atteignait 86.7% de réussite. Entre les deux, il y a des centaines de tentatives et un coût d'inférence important.

Figure 6 : Évolution de l'accuracy de DeepSeek-R1-Zero pendant l'entraînement par RLVR sur AIME 2024. La courbe bleue (pass@1) montre la progression de 15.6% à 71.0%.
Figure 6 : Évolution de l'accuracy de DeepSeek-R1-Zero pendant l'entraînement par RLVR sur AIME 2024. La courbe bleue (pass@1) montre la progression de 15.6% à 71.0%. (source: DeepSeek-AI, 2025)

Le RLVR vise à réduire cet écart, passer d’un pass@k initial élevé en pass@1, ou du moins rapprocher significativement les deux. L'objectif n'est pas seulement d'augmenter les performances du pass@1 sur un problème isolé, mais de développer une capacité de généralisation sur un curriculum entier. Un curriculum est une séquence progressive de tâches d'entraînement, organisées du simple au complexe. Par exemple, pour les mathématiques : commencer par des additions simples, puis des multiplications, puis des équations à une inconnue, &c...

Le but du RL est que le modèle développe une "intuition" qui généralise : si on entraîne sur les additions et multiplications, le pass@k devrait naturellement baisser aussi sur les équations, même si on ne les a pas encore vues. C'est comme si le modèle apprenait à raisonner plutôt qu'à mémoriser, et cette capacité de raisonnement s'applique à l'ensemble du curriculum.

Un modèle entraîné par RLVR peut réduire son pass@k sur les tâches vues pendant l'entraînement, mais l'indicateur clé est qu'il devrait aussi réduire son pass@k sur des tâches non vues du même curriculum, disons de pass@256 à pass@32. Après entraînement par RL, DeepSeek-R1-Zero a atteint un pass@1 de 71.0% sur AIME 2024, multipliant par plus de quatre sa performance initiale [10].

Cela explique pourquoi certaines approches alternatives donnent de meilleurs résultats dans la pratique. Une observation clé issue de DeepSeek R1 révèle qu'un grand modèle sur lequel on effectue du Knowledge Distillation, pour ensuite réaliser du SFT avec ce savoir sur un petit modèle sera toujours plus performant que du RLVR appliqué directement à un petit modèle, ou ne fournira que des gains modestes [10]. Il est donc préférable de réserver le RLVR aux tâches spécifiques et complexes où il est impossible de faire du KD en amont. Concrètement, si vous avez accès à un modèle plus grand et performant, distillez d'abord son savoir avant d'envisager le RLVR.

Cette approche se complète avec le Test-Time Scaling [24], qui accepte un pass@k modéré mais utilise intelligemment ces k générations. Au lieu de viser pass@1 à tout prix, on génère N réponses différentes et on sélectionne la meilleure. La sélection finale s'effectue via le majority voting [25] (on choisit la réponse la plus fréquente), le scoring par reward model [26] (un juge note chaque réponse), ou le Fusion-of-N [27] (on combine les meilleures parties de plusieurs réponses). Cette combinaison de Knowledge Distillation, de SFT ciblé et de Test-Time Scaling offre souvent de meilleures performances que le RLVR seul.

Limites du RLVR

Le RLVR présente des limites structurelles qui émergent de cette optimisation du pass@k, et leur ampleur varie selon les conditions d'entraînement. La première est la généralisation limitée. Un modèle entraîné par RLVR peut réduire significativement son pass@k sur un benchmark spécifique, mais ces gains se traduisent mal sur des variantes du même type de problème ou sur des benchmarks hors distribution [28]. Le modèle a appris à résoudre le benchmark efficacement, pas nécessairement à raisonner de manière générale. Cette limite apparaît systématiquement dans les évaluations : des modèles qui atteignent des scores élevés sur MATH-500 peuvent nécessiter un pass@k beaucoup plus élevé sur des variantes du même problème. Le RLVR optimise la distribution spécifique du benchmark, pas la capacité de raisonnement sous-jacente qui devrait généraliser sur tout le curriculum.

De plus, la généralisation hors du curriculum est asymétrique : un modèle optimisé sur un curriculum mathématique peut montrer quelques gains sur des problèmes de programmation (les mathématiques étant une forme plus fondamentale de raisonnement structuré), mais l'inverse est beaucoup moins vrai [29]. Plus encore, les modèles entraînés sur des domaines structurés comme les mathématiques ou le code montrent des améliorations substantiellement réduites sur des tâches générales non structurées [29]. Cette limitation se manifeste aussi par du catastrophic forgetting : entraîner simultanément sur plusieurs domaines peut causer des conflits, où l'amélioration dans un domaine dégrade les performances dans un autre [30].

Figure 7 : Généralisation asymétrique du RLVR entre domaines. Les modèles entraînés sur des tâches structurées (Math, Code) se transfèrent partiellement entre eux, mais peinent à généraliser vers des domaines de raisonnement général (source : Hu, C. et al., 2025)
Figure 7 : Généralisation asymétrique du RLVR entre domaines. Les modèles entraînés sur des tâches structurées (Math, Code) se transfèrent partiellement entre eux, mais peinent à généraliser vers des domaines de raisonnement général (source : Hu, C. et al., 2025)

La deuxième limite concerne la sur-optimisation de la métrique. En poussant vers pass@1, le modèle peut développer des heuristiques qui fonctionnent sur le benchmark mais échouent dans des cas réels. Par exemple, un modèle peut mémoriser que "diviser par zéro est impossible" et refuser toute division sans vérifier le dénominateur. Il obtient un excellent pass@1 sur les cas où le dénominateur est zéro, mais échoue sur les divisions valides, augmentant paradoxalement le pass@k nécessaire pour des problèmes légèrement différents. Cette optimisation superficielle est particulièrement problématique quand on utilise des LLMs comme juges [31] pour les vérifications soft : le modèle apprend à tromper le juge plutôt qu'à vraiment améliorer sa réponse.

La troisième limite est la plus débattue et dépend fortement de la durée et de la qualité de l'entraînement par RL. Des études récentes montrent des résultats contradictoires sur les capacités émergentes. D'un côté, certains travaux démontrent que le RLVR court (quelques centaines d'étapes) ne crée pas de nouvelles compétences que le modèle de base ne possédait pas déjà de manière latente : si le modèle de base a un pass@infini de 0% sur un type de problème, le RLVR court ne suffira pas à créer cette capacité [28].

Le RL court explore l'espace des stratégies accessibles au modèle, il ne peut pas inventer des connaissances absentes. D'un autre côté, des travaux plus récents sur le RL prolongé (ProRL) avec plus de 2000 étapes d'entraînement démontrent que le RLVR peut effectivement découvrir de nouvelles stratégies de raisonnement absentes du modèle de base [16]. Ces études montrent des cas où le modèle de base échoue complètement (pass@256 = 0%) tandis que le modèle entraîné par ProRL atteint des performances parfaites (pass@1 = 100%).

La clé réside dans la relation entre la compétence initiale du modèle de base et les gains du RL : plus le modèle de base est faible sur une tâche, plus le RL prolongé peut apporter des gains substantiels. Cette découverte suggère que le RLVR peut effectivement étendre les capacités de raisonnement, mais seulement avec un entraînement suffisamment long et sur des tâches où le modèle de base n'a pas déjà saturé son potentiel d'apprentissage. C'est pourquoi injecter le savoir fondamental via Knowledge Distillation ou SFT avant d'optimiser avec du RL reste une stratégie recommandée, surtout quand les ressources d'entraînement sont limitées.

Enfin, le coût computationnel et la fragilité de l'entraînement posent des défis pratiques. Réduire le pass@k nécessite de générer et vérifier des milliers de réponses pour chaque prompt pendant l'entraînement, ce qui multiplie le coût par rapport au SFT classique. Le RL prolongé qui permet de découvrir de véritables nouvelles capacités demande des ressources computationnelles considérables (16 000 heures GPU dans le cas de ProRL [16]), ce qui peut être prohibitif pour les petites organisations.

De plus, l'entraînement par RL est notoirement instable : une reward function légèrement mal calibrée peut faire diverger l'entraînement ou faire régresser les performances. Un modèle peut passer de pass@8 à pass@64 si l'entraînement dérive, perdant ainsi tout le bénéfice du RL. Ces limitations expliquent pourquoi, dans la pratique, le RLVR reste un outil spécialisé plutôt qu'une solution universelle, et pourquoi son utilisation optimale se fait en combinaison avec d'autres techniques, acceptant souvent un pass@k modéré avec du Test-Time Scaling plutôt que de forcer un pass@1 imparfait avec un entraînement RL court.

Conclusion

L'entraînement des LLMs suit un parcours progressif : du pré-entraînement qui apprend à prédire le prochain token, vers le SFT qui affine le format, puis le RLHF qui aligne sur les préférences humaines. Le RLVR marque une rupture en remplaçant le jugement subjectif par une vérification déterministe. Le choix entre RLVR et méthodes traditionnelles repose donc sur une question simple : la tâche admet-elle une fonction de vérification automatique ? Si oui, et si la distillation de connaissances est insuffisante, le RLVR devient pertinent. Sinon, le SFT reste supérieur en efficacité et en stabilité.

L'objectif central du RLVR est de réduire le pass@k : transformer un modèle qui trouve la bonne réponse une fois sur 256 tentatives en un modèle qui la trouve du premier coup, ou au moins une fois sur 8. La structure de l'environnement détermine alors l'algorithme optimal. Le single-turn avec récompenses sparse favorise GRPO, qui évite le coût prohibitif de la fonction de valeur de PPO sans perte de performance. Le multi-turn avec récompenses denses présente un compromis, mais GRPO demeure compétitif avec une taille de groupe suffisante. Cette simplicité architecturale explique l'adoption dominante de GRPO dans la pratique.

La conception de la fonction de vérification exige une attention particulière. Chaque métrique exploitable sera exploitée. Un “verifier” robuste vérifie non seulement la correction mais aussi la qualité du raisonnement. Une reward function bien conçue encourage les capacités généralisables plutôt que la mémorisation de patterns spécifiques. Cette vigilance dans la conception distingue les systèmes qui produisent un véritable raisonnement de ceux qui optimisent superficiellement les métriques.

L'avenir du RLVR réside dans la combinaison des approches plutôt que dans son application isolée. Cette hiérarchie n'est pas théorique mais pratique : un grand modèle distillé via SFT sur un petit modèle surpasse systématiquement le RLVR direct sur ce même petit modèle. La logique est claire. La distillation de connaissances capture l'expertise d'un modèle plus performant et la transfère efficacement. Le SFT affine ensuite le format, le style et la structure des réponses.

Le RLVR intervient uniquement sur les tâches spécifiques où cette base est insuffisante, développant les capacités d'exploration et de résolution créative que la distillation seule ne peut fournir. Enfin, le test-time scaling amplifie ces capacités lors de l'inférence en acceptant un pass@k modéré plutôt qu'en forçant un pass@1 imparfait. Cette orchestration séquentielle de techniques, où chaque méthode joue un rôle optimal, produit les systèmes les plus performants. Le RLVR isolé échoue là où le pipeline complet réussit.

La sortie d'o1 et de DeepSeek-R1 marque un tournant, mais pas celui qu'on imagine. Au-delà des performances sur les benchmarks, ces modèles annoncent la démocratisation progressive du RLVR. Les coûts computationnels baissent, les frameworks open-source se multiplient, et les techniques d'optimisation comme GRPO rendent l'entraînement accessible aux petites équipes. Ce qui nécessitait hier des clusters GPU réservés aux géants technologiques devient aujourd'hui expérimentable par des équipes réduites, voire des individus motivés. Cette accessibilité est la véritable promesse du RLVR : permettre à quiconque dispose d'un problème structuré et d'une fonction de vérification d'explorer des stratégies de raisonnement sur mesure.

Le RLVR a démontré qu'un modèle peut découvrir des stratégies au-delà de son corpus d'entraînement. Désormais, cette capacité d'innovation autonome sera un outil dans l'arsenal de tout praticien qui comprend ses mécanismes, ses limitations, et sait l'intégrer judicieusement dans un pipeline complet. L'avenir du RLVR se jouera dans cette multiplication d'expérimentations décentralisées, où chaque domaine spécialisé pourra affiner ses propres stratégies de raisonnement.

Bibliographie