Sur 1 598 articles de RL, 37 ont atteint les frameworks : audit de sept stacks open source

Une nouvelle analyse de sept frameworks open source de post-entraînement des modèles de langage par RL montre à quel point le chemin est étroit entre l'article et le code opérationnel. Les auteurs ont épluché l'historique des commits et l'ont croisé avec 6 939 travaux sélectionnés sur arXiv, de janvier 2025 à juin 2026. Sur 1 598 articles proposant une méthode générale d'entraînement par RL, seuls 37 figurent dans au moins un framework. Cela représente environ 2,3 %.

Pour les praticiens, l'enjeu est simple : quand une méthode est dans un framework, elle s'active en une ligne de configuration. Sinon, il faut la réécrire soi-même, ce qui coûte cher et comporte des risques à l'échelle de dizaines de milliards de paramètres.

Le flux d'articles grossit, la file d'intégration n'avance pas

Les auteurs ont réparti les travaux en cinq cohortes trimestrielles. La taille d'une cohorte est passée de 72 à 386 articles, soit un facteur 5,4. Le nombre de méthodes que les frameworks ont intégrées dans un délai de 180 jours est pourtant resté dans une fourchette de 5 à 7. Estimation grossière à partir des bornes de cette fourchette : cela représente environ 7–10 % de la cohorte au départ, et seulement 1,3–1,8 % à la fin de la période.

Le goulot d'étranglement se situe apparemment non pas dans la production d'idées, mais dans les ressources des mainteneurs. Chaque nouvelle implémentation exige des tests, de la maintenance et une compatibilité avec le reste du code.

Ce qui passe la sélection

Les articles intégrés se distinguent nettement des autres travaux des mêmes trimestres :

• Politiques de 30B paramètres et plus : 41 % des articles intégrés contre 10 % des autres.
• Modification d'un coefficient, du clip, des masques ou des poids dans une fonction de perte existante : 29 % contre 9 %.
• Publication du code : aussi fréquente dans les deux groupes, donc un dépôt ouvert ne donne pas d'avantage.
• Les deux écarts persistent si l'on retire les articles des entreprises qui maintiennent elles-mêmes les frameworks.

Ce dernier point écarte l'objection évidente selon laquelle les frameworks se contenteraient de reprendre leurs « propres » travaux. Le tableau est plus large : passent les méthodes validées sur de grands modèles et intégrables par une petite modification. Si l'article exige un nouveau composant ou une refonte du pipeline, les chances diminuent.

Les refus sont presque invisibles

L'observation la plus inattendue concerne les discussions publiques. Dans les issues et les pull requests, les méthodes sont rarement rejetées ouvertement. Pour plus de neuf méthodes générales sur dix qui n'ont intégré aucun framework, il n'existe aucun fil où elles seraient citées ou même nommées. Beaucoup de propositions qui apparaissent malgré tout restent ouvertes, sans réponse. La méthode ne reçoit pas de refus : elle n'entre tout simplement pas dans le champ de vision.

Deux vérifications supplémentaires complètent le tableau. Les utilisateurs signalent rarement publiquement les échecs d'entraînement, si bien que les mainteneurs disposent de peu de signaux sur les méthodes réellement nécessaires. Par ailleurs, les rapports techniques de 13 grands modèles open-weight citent 8 des 13 méthodes largement intégrées. La pratique des grands laboratoires semble donc être un levier puissant, au même titre que la qualité de l'article lui-même.

Un tracker pour ceux qui choisissent une méthode

Les auteurs publient leurs données sous forme de tracker. Il relie les échecs d'entraînement aux implémentations dans les frameworks, et recense aussi les règles de contribution de chaque projet ainsi que les propositions de méthodes antérieures.

Plusieurs enseignements se dégagent pour les équipes qui entraînent des modèles. Avant d'adopter une méthode issue d'un article récent, il vaut la peine de vérifier si elle existe dans le framework et dans quel état se trouve son issue. L'absence d'implémentation ne signifie pas que la méthode est faible, mais cela implique que vous la testerez seul.

Les chercheurs qui veulent voir leurs idées dans ces stacks gagneraient à présenter leur méthode comme une petite modification du coefficient, du clip ou des masques dans une fonction de perte existante, et à la tester sur des modèles de 30B et plus. Quant aux utilisateurs de frameworks, ils devraient décrire plus souvent leurs échecs en public : c'est aujourd'hui presque inexistant, et les mainteneurs choisissent les méthodes à l'aveugle.