TTRL: entraîner un modèle de raisonnement sur des données de test sans étiquettes

Le problème: produire une récompense là où il n'y a pas de réponse connue

L'entraînement par renforcement sur des tâches de raisonnement suppose un signal de récompense. Dans le cas habituel, ce signal vient d'une réponse de référence: le modèle produit une solution, on la compare à la vérité terrain, on met à jour les poids. TTRL attaque le cas où cette référence n'existe pas, en particulier sur les données de test d'un benchmark public dont les réponses ne sont pas distribuées. Le README formule l'objectif ainsi: une solution open source pour le RL en ligne sur des données sans étiquettes de vérité terrain, en particulier les données de test. Le public visé est donc étroit: des équipes qui font déjà du post-entraînement de modèles de raisonnement, qui ont accès à un jeu d'évaluation, et qui acceptent de le traiter comme un jeu d'entraînement. Ce n'est pas un outil d'inférence au sens classique. C'est une boucle de mise à jour des poids qui se déclenche au moment du test.

Le vote majoritaire comme substitut de la vérité terrain

Le mécanisme central tient en une substitution. Au lieu de comparer la sortie du modèle à une réponse de référence, TTRL échantillonne plusieurs réponses pour une même question, puis prend la réponse majoritaire comme cible. Cette cible sert de récompense: les réponses qui convergent vers la majorité sont renforcées. Le README décrit cette idée comme le fait que des pratiques courantes du Test-Time Scaling, comme le vote majoritaire, produisent des récompenses étonnamment efficaces pour piloter l'entraînement RL. Le dépôt fournit un pseudo-code de cette fonction de récompense, présenté comme une modification rapide du code existant. Le point à retenir est que le signal est auto-généré. Il ne provient d'aucune source externe, ce qui explique à la fois l'intérêt de la méthode et sa fragilité: si le modèle se trompe de façon systématique et cohérente, la majorité est fausse et l'entraînement renforce l'erreur.

Ce que le dépôt contient réellement: une surcouche de verl

TTRL n'est pas une base de code indépendante. Le README indique que l'implémentation repose sur verl, et l'installation se fait en entrant dans le sous-répertoire verl du dépôt cloné. Les scripts d'exemple vivent sous verl/examples/ttrl, et la documentation renvoyée pour les détails du code est celle de verl, pas une documentation propre à TTRL. Cette dépendance a une conséquence pratique: la compatibilité suit le rythme des versions de verl. Les notes de version mentionnent qu'à partir de verl v0.4.1, TTRL s'active par un simple +ttrl.enable=True. Autrement dit, une partie du projet a été absorbée en amont, et le dépôt sert surtout de référence pour reproduire les expériences et pour les variantes de recherche. Les deux entrées de version listées, verl v2.0.0 et OpenRLHF v1.0.0, concernent ces projets tiers et non TTRL lui-même.

Installation et lancement d'une reproduction sur AIME 2024

La séquence d'installation donnée par le README est explicite. On clone le dépôt, on se place dans TTRL/verl, on crée un environnement conda en Python 3.10, on active cet environnement, on exécute bash scripts/install_ttrl_deps.sh, puis pip install -e . pour installer le paquet en mode éditable. La reproduction des résultats sur AIME 2024 tient en une commande: bash examples/ttrl/Qwen2.5/aime.sh. Deux points d'outillage sont signalés dans les notes. D'abord, le script verl/data/preprocess.py convertit les données du format JSON vers le format Parquet attendu par verl pour l'entraînement. Ensuite, le répertoire verl/examples/ttrl regroupe des scripts couvrant plusieurs modèles et plusieurs benchmarks. Le README précise que toutes les expériences ont été menées sur 8 GPU NVIDIA A100 de 80 Go. Cette dernière phrase est la contrainte la plus concrète du document: elle fixe le plancher matériel de toute reproduction sérieuse.

Ce que les chiffres annoncés disent, et ce qu'ils ne disent pas

Le résultat mis en avant est une amélioration d'environ 211 pour cent du pass@1 de Qwen-2.5-Math-7B sur AIME 2024, à partir de données de test non étiquetées uniquement. Le README ajoute que TTRL dépasse l'upper limit que constitue la métrique maj@n du modèle initial, et s'approche des performances d'un modèle entraîné directement sur les données de test avec étiquettes. Ces chiffres proviennent du papier et des journaux d'expériences, pas d'une vérification indépendante. Le document rapporte aussi trois exécutions indépendantes avec la version preview du code: deux ont atteint un pass@1 glouton de 43,3 et une a atteint 46,7. Cet écart entre exécutions est instructif. Il indique une variance non négligeable d'un run à l'autre, sur un seul benchmark et un seul modèle. Un lecteur qui planifie un déploiement doit traiter ces valeurs comme un ordre de grandeur, pas comme une garantie reproductible.

La limite structurelle: quand la majorité n'est pas la bonne réponse

Le signal de récompense est la majorité des échantillons. Cela fonctionne pour des tâches à réponse courte et vérifiable, du type problème de mathématiques avec un résultat final unique. Cela se dégrade dès que la tâche admet plusieurs formulations correctes, une réponse libre, ou un raisonnement dont la qualité ne se réduit pas à une chaîne finale. Dans ces cas, deux réponses correctes mais formulées différemment se divisent, et une réponse fausse mais fréquente peut l'emporter. Le README ne propose pas de mécanisme de détection de cette situation. Il n'y a pas non plus d'indication sur un seuil de confiance à partir duquel le vote majoritaire serait jugé trop faible pour être utilisé, ni sur un filtrage des questions trop ambiguës. C'est le point où la méthode devient le mauvais outil: une équipe qui travaille sur de la génération ouverte, du code sans tests exécutables, ou de l'analyse de documents, n'a pas de majorité à calculer. La section sur l'URLVR, publiée plus tard, explore d'ailleurs d'autres usages du RL non supervisé, ce qui suggère que le vote majoritaire n'est qu'une instanciation parmi d'autres.

Face à un entraînement supervisé classique, la différence n'est pas la vitesse

L'alternative directe est l'entraînement par renforcement avec vérificateur, tel que le propose verl seul: on dispose d'un jeu de données étiqueté, on compare les sorties à une réponse de référence, et la récompense est exacte. La différence avec TTRL ne porte pas sur l'infrastructure, puisque les deux passent par verl, mais sur la source du signal. Un pipeline classique exige des étiquettes, donc soit une annotation coûteuse, soit des données déjà résolues. TTRL supprime cette exigence en échange d'un signal bruité, dont la qualité dépend de la capacité du modèle à être cohérent avec lui-même. Le compromis est donc clair: moins de préparation de données, plus d'incertitude sur ce que l'entraînement optimise réellement. Sur un jeu déjà étiqueté, utiliser TTRL n'apporte rien et introduit du bruit là où une comparaison exacte était disponible.

Maintenance, licence et coût de mise à jour

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un produit commercial, à condition de conserver l'avis de licence. Ce texte ne constitue pas un avis juridique: les obligations exactes dépendent de la manière dont le code est redistribué et des licences des dépendances, notamment celles de verl et des modèles utilisés. Sur la maintenance, le dépôt n'est pas archivé et la dernière poussée date du 15 avril 2026. Le suivi de verl est le principal coût caché: puisque TTRL s'active via +ttrl.enable=True à partir de verl v0.4.1, une mise à jour majeure de verl peut modifier les chemins de configuration ou le comportement de l'entraîneur. La branche urlvr-dev, mentionnée dans les notes, montre qu'il existe du code de recherche parallèle qui ne suit pas forcément la branche principale. Toute équipe qui fige une version doit donc figer aussi la version de verl correspondante, sous peine de voir les scripts d'exemple cesser de fonctionner.

Conclusion éditoriale

TTRL vise les équipes qui disposent déjà de verl et d'un parc de GPU de classe A100, et qui veulent exploiter un jeu de test non étiqueté plutôt que d'annoter. Il ne convient pas à qui cherche une bibliothèque autonome, ni à des tâches où la réponse n'est pas vérifiable automatiquement, car le vote majoritaire n'a alors rien à mesurer. Avant d'investir, vérifier deux points dans le dépôt: la présence de la clé +ttrl.enable dans la version de verl installée, et le script de conversion verl/data/preprocess.py pour le passage du JSON au Parquet.

Sources officielles

1. License: MIT
2. PRIME-RL/TTRL on GitHub
3. Project website
4. README
5. Releases