LM2LM : Qwen3.8-27B surpasse GPT-6-sol pour proposer des améliorations de LLM, et coûte 33% de moins

L'idée qu'un réseau de neurones améliore lui-même d'autres réseaux de neurones est depuis longtemps évoquée comme une voie vers l'auto-amélioration récursive. L'équipe derrière LM2LM en présente une version qui fonctionne : un modèle de langage entraîné par RL à générer des propositions efficaces pour améliorer des LM. Lors de la validation sur des tâches mises de côté, dans huit environnements de développement (autorégressifs et à diffusion), Qwen3.8-27B a surpassé GPT-6-sol. Même avec 300 enregistrements expérimentaux réels dans son contexte, ce dernier a perdu, tandis que la génération de données de LM2LM a coûté 33% de moins.

Pourquoi on ne peut pas obtenir une récompense fiable pour une idée

L'obstacle principal est économique. Pour apprendre à un modèle à proposer de bonnes améliorations, le RL doit évaluer des dizaines de milliers de propositions. Chacune exige, à la limite, un entraînement complet du modèle. À raison de dix heures GPU par entraînement, les seules récompenses consommeraient des centaines de milliers d'heures GPU. Pour la plupart des laboratoires, ce budget est irréaliste : il faut un substitut peu coûteux.

Ce substitut pose lui-même un problème. Une évaluation de substitution reste fiable tant que la politique génère des propositions proches de celles sur lesquelles le substitut a été construit. Dès que l'optimisation commence à déplacer la distribution des propositions, la politique trouve celles que le substitut surestime. C'est le reward hacking classique : le modèle apprend à plaire à l'évaluateur, pas à améliorer de vrais modèles.

Un modèle du monde pour la recherche, recalé sur la réalité

LM2LM traite les deux problèmes avec deux éléments. Le premier est un research world model (RWM) : un LLM gelé, dont le contexte contient des enregistrements d'expériences réelles. À partir de ces données, il prédit le gain qu'apportera une nouvelle proposition. Le RWM sert de reward model pour le RL et remplace des milliers d'entraînements complets par un seul appel de modèle.

Le second élément est un recalage périodique. Les propositions de la politique courante que le RWM a le mieux notées sont réellement exécutées, et les résultats mesurés sont ajoutés au contexte du RWM. L'évaluateur voit ainsi précisément la zone de l'espace des idées vers laquelle la politique s'est déplacée, et se recalibre là où elle risque de le tromper. Les candidats les plus suspects, c'est-à-dire ceux qui ont justement obtenu des notes élevées, sont vérifiés par un véritable lancement.

Paramètres clés de l'étude :

• politique : Qwen3.8-27B, entraîné par RL ;
• reward model : un LLM gelé (RWM) avec des enregistrements expérimentaux réels dans son contexte ;
• référence : GPT-6-sol, à qui l'on a fourni 300 enregistrements réels dans son contexte ;
• environnements : huit environnements de développement de LM, autorégressifs et à diffusion ;
• évaluation : exécution réelle des propositions sur des tâches mises de côté ;
• économie : coût de génération des données inférieur de 33% ;
• généralisation : transfert à une famille de modèles absente de l'entraînement.

Les conditions de la comparaison méritent d'être soulignées. GPT-6-sol a reçu un indice de poids, 300 enregistrements réels, mais un modèle de plus petite taille, doté d'une capacité apprise, a tout de même fait mieux. Il semble donc plus efficace de transmettre l'expérience accumulée par l'entraînement d'une politique que par un long contexte chez un modèle plus généraliste.

À quoi cela peut servir en pratique

Pour les équipes qui mènent beaucoup d'expériences d'entraînement de modèles, l'intérêt principal est de transformer les journaux des lancements passés en actif. Les notes sur les changements d'hyperparamètres, de données ou d'architecture qui ont fonctionné peuvent servir de contexte au RWM et de source de signal d'apprentissage pour le générateur d'idées. Les entraînements coûteux ne sont consacrés qu'à la vérification des candidats les plus prometteurs.

Une conclusion prudente s'impose aussi. Ce schéma ne fonctionne qu'avec de la discipline : sans vérification régulière par des lancements réels, le substitut se met à surestimer des idées et la politique le suit. Il faudra donc inscrire le budget des expériences réelles dans le pipeline comme une dépense permanente. Le transfert vers une famille de modèles inconnue indique que l'expérience accumulée n'est pas liée à une seule architecture, mais il faudra tout de même la vérifier soi-même sur ses propres stacks.