Rufus-Air : la recette de post-entraînement d’un LLM open enfin documentée
L’essentiel
Ce qui change. Pour la première fois, toutes les étapes qui transforment un modèle de langage brut en assistant capable de coder, raisonner et utiliser des outils sont publiées en détail et reproductibles avec des données publiques.
Qui est concerné. Les équipes qui entraînent, adaptent ou évaluent des modèles de langage open source pour construire des agents, des assistants de code ou des outils de recherche.
À retenir. Rien à faire dans l’immédiat si vous consommez des LLM via une API commerciale, mais à surveiller si vous évaluez des alternatives ouvertes pour des tâches agentiques ou de code : la méthode devient reproductible, ce qui facilite les comparaisons et les adaptations maison.
Ce que documente Rufus-Air
Rufus-Air n’est pas un nouveau modèle de langage, mais la description complète de la manière d’en fabriquer un bon à partir d’un modèle brut. Le point de départ est GLM-4.5-Air-Base, un grand modèle de langage (LLM) de 106 milliards de paramètres dont 12 milliards sont actifs à chaque calcul (architecture dite « mixture of experts »). L’équipe, composée de chercheurs ayant tous mené ce travail alors qu’ils étaient employés par Amazon, publie la recette de post-entraînement complète : les données utilisées, la conception des récompenses, l’infrastructure et les résultats obtenus à chaque étape.
Ce niveau de détail est ce qui distingue ce travail. La plupart des post-entraînements de LLM ouverts publient le modèle final mais gardent secrète la manière dont on y arrive : quelles données, dans quel ordre, avec quels signaux de récompense. Ici, l’objectif affiché est la reproductibilité.
Huit étapes, un ordre qui n’est pas anodin
La recette s’organise comme un pipeline séquentiel de huit étapes : un ajustement supervisé (SFT), puis un apprentissage par renforcement (RL) pour le raisonnement, un RL pour le code, un RL pour le suivi d’instructions, un stade « agent généraliste », un stade « agent de code », un stade « agent de recherche », et enfin un ajustement par retour humain (RLHF).
L’ordre progresse des capacités de base vers les capacités avancées, et des signaux de récompense faciles à vérifier (un test qui passe ou échoue) vers des signaux plus mous, jugés par un modèle évaluateur plutôt que par une règle stricte. Les auteurs formulent quatre principes qui justifient ce choix : un ajustement supervisé diversifié et de bonne qualité établit un socle de capacités solide, un filtrage de la difficulté des prompts maintient l’apprentissage par renforcement dans une zone productive, la fiabilité de la récompense sert de critère pratique pour ordonner les étapes, et les choix d’infrastructure font partie intégrante de la recette, pas d’un détail d’implémentation secondaire.
Autre point notable : l’entraînement s’appuie sur des composants open source et des données publiques, utilisées en grande partie telles quelles, sans nouvelle annotation humaine ni modèle de distillation propriétaire développé en interne. C’est une différence importante avec les recettes qui s’appuient sur un modèle enseignant privé pour générer les données d’entraînement.
Résultat annoncé : Rufus-Air surpasse la version officielle post-entraînée de GLM-4.5-Air et se montre compétitif face à des modèles ouverts de taille comparable.
Ce que ça change pour qui construit des agents
Les trois dernières étapes du pipeline — agent généraliste, agent de code, agent de recherche — correspondent exactement aux usages qui intéressent l’automatisation de processus et les agents no-code : un modèle capable d’enchaîner des appels d’outils, d’écrire et corriger du code, ou de mener une recherche multi-étapes. Que la recette de ces capacités soit documentée, avec l’ordre des étapes et la conception des récompenses, change la donne pour qui veut adapter un modèle ouvert à un usage spécifique plutôt que de dépendre d’une API fermée.
Dans nos propres automatisations de rédaction éditoriale, nous combinons déjà un modèle économique pour préparer un brief et un modèle plus coûteux pour la rédaction finale : le choix du modèle se fait étape par étape, selon la difficulté de la tâche. C’est précisément la logique que Rufus-Air formalise et documente à l’échelle d’un pipeline d’entraînement complet — passer d’un signal de récompense simple et fiable à un signal plus fin à mesure que la tâche se complexifie. Voir cette logique posée noir sur blanc, avec des résultats à chaque étape, donne un cadre transposable à d’autres contextes que l’entraînement pur, y compris pour orchestrer des chaînes de modèles dans des workflows d’automatisation.
Ce qui reste flou
Le résumé ne précise pas si les poids du modèle final sont mis à disposition, ni sous quelle licence exacte. Aucun chiffre de benchmark précis n’est donné dans le résumé lui-même — seulement une comparaison qualitative avec la version officielle de GLM-4.5-Air et des modèles ouverts de taille similaire. Le document complet, 48 pages avec 9 figures et 20 tableaux, contient probablement ces éléments chiffrés : à vérifier avant toute décision d’adoption.
Sources
- arXiv — cs.CL (Computation and Language) — publie le 2026-09-25, consulte le 2026-09-28
Informations verifiees le 2026-09-28.