Vérificateurs pas à pas : ce que démontrent les Process Reward Models et jusqu’où ils généralisent

La question : mieux sélectionner signifie-t-il raisonner de façon fiable ?

Lorsqu’un modèle résout un problème en plusieurs étapes, il existe plusieurs façons d’évaluer sa réponse. On peut juger uniquement la conclusion, ou examiner les étapes intermédiaires et estimer si chacune est valide. La deuxième approche semble offrir un diagnostic plus détaillé : si l’on repère le début d’une erreur, on pourrait, en principe, écarter une solution avant que cette erreur ne contamine la suite du raisonnement.

Un Process Reward Model (PRM) est un modèle entraîné à attribuer des scores aux étapes d’une solution, généralement afin de distinguer les étapes correctes des étapes incorrectes, ou utiles des défectueuses. Un Outcome Reward Model (ORM), à l’inverse, évalue le résultat dans son ensemble. Tous deux sont des évaluateurs : aucun ne produit nécessairement la solution. Lorsqu’ils servent à classer plusieurs réponses candidates, ils participent à une recherche ; cette recherche est une opération supplémentaire, et non une propriété démontrée par le score lui-même.

La conclusion que l’on peut tirer des travaux examinés reste circonscrite : les vérificateurs de processus peuvent aider à sélectionner des solutions pour certaines tâches et dans certaines conditions expérimentales. Cela ne suffit pas à conclure que chaque étape notée est correcte, qu’une explication visible reproduit fidèlement le processus interne du modèle, ou que le vérificateur se comportera de la même façon dans un autre domaine. Il est important de distinguer les résultats obtenus sur une tâche précise des affirmations plus générales sur la fiabilité.

Quatre notions à ne pas confondre

La supervision de processus fournit des annotations portant sur les étapes intermédiaires. La supervision de résultats fournit des annotations pour des solutions complètes ou leurs réponses finales. Un PRM apprend à exploiter des signaux relatifs au processus ; un ORM apprend à partir de signaux relatifs au résultat. Un critique généraliste peut recevoir une solution et produire une évaluation en langage naturel, sans être nécessairement un PRM entraîné sur des annotations d’étapes.

La vérification et la recherche guidée ne sont pas non plus équivalentes. Vérifier consiste à attribuer un jugement ou un score à une solution ou à ses étapes. Dans une recherche, un générateur produit des possibilités et une règle de sélection décide lesquelles conserver ou explorer. Un PRM peut servir de règle de sélection, mais le résultat final dépend aussi du générateur, du nombre de candidats, de la procédure de recherche et du budget de calcul.

Ces distinctions comptent lorsqu’on lit les résultats. Si une configuration utilisant un PRM obtient davantage de réponses correctes qu’une configuration utilisant un ORM, cela peut étayer l’idée que le PRM est utile pour cette combinaison de tâche, de modèle et de recherche. Cela n’établit pas automatiquement qu’il détecte mieux les erreurs, ni que l’amélioration vient exclusivement d’une compréhension du raisonnement.

Let’s Verify Step by Step : des résultats sur des problèmes mathématiques

« Let’s Verify Step by Step » étudie la supervision de processus par rapport à la supervision de résultats dans le raisonnement mathématique. L’article présente PRM800K, un jeu de données comprenant 800 000 annotations de correction au niveau des étapes pour des solutions de modèles à des problèmes de MATH. L’unité d’annotation est importante : ces annotations permettent d’entraîner et d’évaluer des jugements intermédiaires sur ce type de contenu, mais elles ne constituent pas un ensemble universel de règles de raisonnement.

Dans ses expériences sur des problèmes mathématiques, l’article rapporte que la supervision de processus peut améliorer la sélection de solutions par rapport à la supervision de résultats. Il faut interpréter ce résultat dans le cadre expérimental de l’étude : problèmes de MATH, solutions candidates générées par des modèles et vérificateurs entraînés à l’aide des données et des procédures décrites. Cela ne montre pas que n’importe quel PRM surpasse n’importe quel ORM, quel que soit le générateur ou la tâche.

Il faut aussi distinguer la réussite dans la sélection d’une réponse du jugement correct de chaque étape. Si un vérificateur classe correctement les solutions d’un test, cela mesure son utilité comme outil de sélection pour ce test. Pour affirmer qu’il localise les erreurs de façon fiable, il faudrait évaluer directement sa capacité à identifier les étapes correctes et incorrectes à partir de références appropriées. Un score agrégé sur les réponses finales ne remplace pas cette analyse.

ProcessBench : évaluer où apparaît la première erreur

ProcessBench aborde une question plus directe sur l’évaluation des étapes : étant donné un raisonnement erroné, l’évaluateur peut-il identifier la première étape incorrecte ? Le benchmark rassemble 3 400 cas et s’appuie sur des annotations humaines de spécialistes pour désigner la première erreur. Sa conception permet d’étudier autre chose que la simple sélection d’une réponse finale : la localisation d’une erreur dans une séquence de raisonnement.

L’article compare des PRM à des modèles critiques et présente des résultats sur des tâches de raisonnement mathématique. Ces comparaisons fournissent un cadre commun pour les systèmes inclus dans le benchmark, mais leur portée est délimitée par les tâches, les solutions et les critères d’annotation qui y figurent. Un bon score sur ProcessBench étayerait la performance lors de cette évaluation ; il ne démontrerait pas une capacité identique en programmation, en sciences ou dans d’autres formes de raisonnement.

L’annotation de la première erreur ne répond pas à toutes les questions possibles sur une solution. Il peut exister un désaccord raisonnable sur le niveau de détail d’une étape, des erreurs de transcription, ou des cas où une étape semble incorrecte alors que la conclusion ultérieure est juste par un autre chemin. En plus du score global, il convient donc d’examiner la définition des unités évaluées, les consignes fournies aux annotateurs et la manière de résoudre les désaccords.

Le dépôt officiel du projet documente l’accès au benchmark et à ses ressources. Pour reproduire une expérience, connaître le nom du benchmark ne suffit pas : il faut consigner la version des données, le format d’entrée, le modèle, les consignes et la configuration utilisés.

Rewarding Progress et ThinkPRM : d’autres façons de construire et de tester des vérificateurs

« Rewarding Progress » présente les Process Advantage Verifiers et étudie leur utilisation pour des tâches de raisonnement, notamment dans la recherche guidée et l’apprentissage par renforcement avec des vérificateurs. Pour notre propos, l’intérêt est de déplacer la question de « quelle solution obtient le meilleur score ? » vers la manière dont un signal de progrès peut être utilisé dans des procédures qui génèrent ou sélectionnent des solutions. L’article compare des configurations faisant appel à des vérificateurs de processus et de résultats, mais ces comparaisons correspondent aux modèles, aux tâches et aux budgets définis dans ses expériences.

Un résultat de recherche guidée combine plusieurs choix : les candidats produits par le modèle, le signal utilisé par le vérificateur, le nombre d’itérations et la quantité de calcul autorisée. Si le taux de solutions correctes augmente, cette amélioration concerne la configuration complète. Pour l’attribuer au vérificateur en particulier, l’expérience doit contrôler les autres variables et rendre compte des coûts, et pas seulement de la qualité finale.

ThinkPRM étudie des vérificateurs de processus qui produisent des raisonnements pour évaluer les étapes. L’article fait état d’évaluations sur ProcessBench, MATH-500 et AIME ’24, ainsi que de tests hors distribution sur GPQA et LiveCodeBench. Cela élargit le type de preuves par rapport à un seul test mathématique, mais ne transforme pas quelques résultats en garantie de généralisation sans limites. Chaque jeu représente une couverture précise, et les performances peuvent varier selon la tâche, la distribution et la façon de présenter les étapes.

Le nom d’une méthode ne détermine pas, à lui seul, le volume ou le type de supervision dont elle a besoin, ni le baseline qui convient. Pour comparer ces travaux, il faut relever dans chaque article les jeux d’entraînement, les annotations utilisées, les modèles générateurs et évaluateurs, les consignes, les budgets et les métriques. Lorsque ces éléments ne sont pas identiques, établir un simple classement des « gagnants » serait trompeur.

Limites : annotations coûteuses, erreurs de jugement et sur-optimisation du proxy

La supervision au niveau des étapes peut être plus informative qu’une annotation finale, mais elle impose de déterminer ce qui constitue une étape et si elle est correcte. PRM800K illustre l’ampleur d’une ressource consacrée aux annotations d’étapes pour des problèmes mathématiques ; cette ampleur ne supprime pas le coût de production, de vérification et de maintien d’annotations fiables. En outre, une convention d’annotation conçue pour des solutions mathématiques ne se transpose pas automatiquement à des tâches dont les critères sont moins discrets.

Un vérificateur peut également se tromper. Un faux positif accepte une étape défectueuse ; un faux négatif rejette une étape valide. Si le système sélectionne parmi de nombreuses réponses, ces erreurs n’ont pas nécessairement des effets symétriques : un score élevé mais erroné peut promouvoir une solution incorrecte. Il faut donc mesurer les deux types d’erreurs et examiner des exemples, plutôt que de se limiter à une métrique moyenne.

La sur-optimisation du proxy constitue un autre risque concret. Si le générateur est optimisé de façon répétée pour obtenir des scores élevés auprès d’un vérificateur, il peut apprendre des régularités récompensées par l’évaluateur sans que la correction réelle s’améliore. Cela ne prouve pas que ce phénomène se produise systématiquement, mais il mérite d’être étudié : comparer le score du PRM à des vérifications indépendantes, auditer les solutions sélectionnées et rechercher les cas où une trace persuasive ou une formulation superficielle obtient une note élevée tout en restant défectueuse.

Enfin, noter un raisonnement écrit ne prouve pas que ce texte retranscrive fidèlement les calculs internes du modèle. Les expériences sur la sélection ou la localisation d’erreurs évaluent des comportements observables dans le cadre de tâches définies. Elles ne suffisent pas à établir une transparence interne, ni à affirmer que l’intégration d’un PRM rend une application sûre.

Protocole pratique pour évaluer son propre PRM

Une équipe qui envisage d’intégrer un PRM peut commencer par un test de petite envergure et contrôlé, sans confondre la comparaison des évaluateurs avec une évaluation complète du produit. L’objectif doit être défini avant l’expérience : cherche-t-on à choisir de meilleures réponses, à détecter la première erreur, à réduire le nombre d’appels à un modèle critique ou à améliorer une recherche ? Chaque objectif nécessite des données et des métriques différentes.

Pour comparer les systèmes, il faut disposer d’un ensemble de tâches figé, comprenant des cas qui n’ont pas servi à ajuster les consignes, ainsi que de références vérifiées par des personnes ou des méthodes indépendantes. Lorsque l’objectif est de comparer les évaluateurs, il faut fixer les mêmes modèles générateurs et les mêmes candidats, et maintenir constant le budget de sélection. Si le PRM nécessite davantage d’appels ou permet une exploration plus large que le baseline, la comparaison doit signaler cette différence.

L’ensemble des systèmes devrait comprendre au minimum un PRM, un juge généraliste et un vérificateur de résultat. Le juge généraliste évalue la solution à partir d’une consigne en langage naturel ; le vérificateur final ne contrôle que la conclusion, lorsque la tâche permet une vérification fiable. Aucun de ces systèmes ne constitue un contrôle universel : ils permettent de déterminer si l’information sur les étapes améliore le jugement par rapport à des solutions de rechange concrètes.

Au-delà de la métrique principale, il faut consigner séparément réussites et erreurs, la qualité de localisation de la première erreur le cas échéant, le coût par candidat, le nombre de candidats et le taux de solutions correctes lorsque le budget varie. Il est utile de réserver une partie des tâches à des changements de domaine ou de difficulté, et d’examiner manuellement un échantillon des cas où le PRM et les baselines ne sont pas d’accord.

Conclusions défendables

Les recherches sur les PRM apportent des éléments indiquant que l’évaluation des étapes intermédiaires peut aider à sélectionner des solutions et, dans des benchmarks conçus à cette fin, à étudier la détection des erreurs. « Let’s Verify Step by Step » documente la supervision de processus sur des problèmes mathématiques ; ProcessBench formalise une évaluation axée sur la localisation de la première erreur ; « Rewarding Progress » explore les vérificateurs dans des procédures de recherche et d’apprentissage ; ThinkPRM élargit les tests à des jeux mathématiques et à des évaluations hors distribution bien définies.

La conclusion n’est pas qu’il existe un vainqueur universel. Les tâches, les données, les annotations, les modèles, les budgets et les critères de réussite varient. La formulation la plus rigoureuse est conditionnelle : un PRM peut apporter de la valeur dans une configuration évaluée, et cette valeur doit être mesurée par rapport à des baselines comparables, avec une analyse explicite des coûts et des erreurs.

Pour décider s’il convient à un flux de travail donné, il ne suffit pas de demander si le modèle attribue des scores convaincants. Il faut mesurer si ces scores améliorent l’objectif opérationnel, vérifier quels cas posent problème, tester les changements de distribution et distinguer la correction de la réponse, la validité des étapes et la fidélité du raisonnement visible. Cette distinction rend les conclusions plus modestes, mais aussi plus utiles.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.