Un modèle de code ouvert qui a appris sur le tas

Un modèle de code ouvert qui a appris sur le tas

JetBrains a publié Mellum2.1 le 8 octobre. C'est un modèle mixture-of-experts de 12 milliards de paramètres conçu pour les agents de codage, disponible sur Hugging Face sous licence Apache 2.0. Ces seuls faits en feraient l'une des nombreuses sorties similaires du mois. Ce qui le distingue, c'est sa méthode d'entraînement.

Le post-entraînement de Mellum2.1 repose sur l'apprentissage par renforcement dans de vrais environnements de code. Pas un banc d'essai simulé, pas un jeu de données statique de problèmes résolus. Le modèle explore des dépôts, modifie des fichiers et vérifie ses propres changements, comme le ferait un développeur en activité.

Pourquoi la méthode d'entraînement compte plus que le nombre de paramètres

La plupart des modèles de code actuels sont entraînés à prédire le prochain morceau de code, puis affinés sur des exemples de bons correctifs. C'est un pipeline raisonnable, et il produit des modèles capables de compléter et d'expliquer. C'est une piètre préparation à la réalité désordonnée d'un dépôt qui ne compile pas, où le premier correctif casse un test et le second casse autre chose.

La compétence utile n'est pas d'écrire une fonction. C'est de boucler la boucle : formuler une hypothèse, changer quelque chose, observer le résultat, corriger. L'apprentissage par renforcement en environnement réel récompense exactement ce comportement, car la récompense vient du fait que le changement a réellement fonctionné.

C'est le même basculement qui a rendu les agents de codage utiles au départ. Un modèle qui ne sait qu'écrire du code est une autocomplétion sophistiquée. Un modèle qui sait lancer les tests, lire les échecs et réessayer est un collaborateur. Les données d'entraînement de Mellum2.1, c'est la boucle elle-même.

Un modèle de 12B, une taille délibérée

Douze milliards de paramètres, c'est peu à côté des modèles de pointe. C'est justement le but. Un agent de codage fonctionne dans une boucle serrée : lire des fichiers, lancer des commandes, inspecter des diffs. Il est donc appelé en permanence. Un modèle peu coûteux à exécuter et rapide à répondre peut être utilisé bien plus agressivement qu'un modèle qui coûte vraiment de l'argent à chaque étape.

La conception mixture-of-experts renforce la même idée. Les activations par token restent modestes même quand la capacité totale augmente, ce qui garde l'inférence bon marché sans priver le modèle de connaissances. Pour un outil susceptible d'être appelé des dizaines de fois pour une seule tâche, ce compromis est exactement le bon.

Un schéma se dessine tout au long d'octobre. Des modèles petits, spécialisés et sous licence ouverte apparaissent pour faire le travail répétitif au sein de systèmes plus vastes : JetBrains ici, les modèles de décision de Liquid AI, la version 27B compressée d'Underdog AI. Le modèle de pointe fixe le plafond. Les petits modèles fixent le plancher, et c'est là que la majorité des tokens est dépensée.

Publier les poids comme stratégie de diffusion

JetBrains n'est pas un laboratoire qui se dispute des couronnes de benchmarks. Il vend des outils de développement, et son intérêt est de les rendre meilleurs, pas de garder un modèle sous clé. Publier Mellum2.1 sous Apache 2.0 permet au modèle de se répandre dans l'écosystème, y compris dans des éditeurs concurrents et des harnais d'agents.

Cela mérite qu'on s'y arrête. Quand une société d'outils ouvre le code d'un modèle de codage, elle parie que la valeur réside dans l'intégration et le flux de travail, pas dans les poids. C'est le même pari que font beaucoup d'entreprises d'infrastructure cette année, et c'est un pari qui vieillit généralement bien. Un modèle que personne ne peut adopter est un modèle qui ne peut pas devenir un standard.

La licence Apache 2.0 compte particulièrement pour l'adoption. Une licence permissive supprime la revue juridique qui ralentit une grande entreprise désireuse d'essayer un nouveau modèle. Pour une entreprise dont les clients sont précisément ces grandes structures, livrer un modèle sous licence permissive est un moyen de semer la familiarité avant de vendre quoi que ce soit.

Comparaison avec les modèles de code de pointe

Les modèles de code de pointe sont meilleurs sur les problèmes difficiles. Ce n'est pas contesté, et cela ne changera sans doute pas de sitôt. Ce qui est contesté, c'est de savoir si chaque tâche de codage a besoin de la pointe. La plupart n'en ont pas besoin. Renommer une fonction dans tout un projet, mettre à jour une dépendance, écrire un test pour un comportement existant : ces tâches sont courantes, fastidieuses, et largement à la portée d'un petit modèle doté d'un bon harnais.

Mellum2.1 ne cherche pas à battre les plus grands modèles sur leurs meilleures tâches. Il cherche à être suffisamment bon sur les tâches qui remplissent la journée d'un développeur. C'est un objectif plus étroit, et plus durable, car il ne dépend pas de gagner une course qu'il ne gagnera pas.

Il y a aussi une raison stratégique pour une société d'outils de maintenir un modèle à cette taille. Un modèle assez petit pour tourner en local peut être proposé sans facturation à la requête, ce qui supprime la mesure qui rend les développeurs hésitants à utiliser librement les agents. Un éditeur capable d'invoquer son propre modèle sans aller-retour réseau est un produit différent d'un éditeur qui ne le peut pas, et la différence se voit dans l'audace avec laquelle les utilisateurs s'appuient sur lui.

Pourquoi l'apprentissage par renforcement en environnement réel est différent

La distinction entre apprendre sur des exemples et apprendre sur des résultats mérite un dernier passage, car c'est le détail le plus lourd de conséquences de cette sortie. Un modèle entraîné sur des exemples apprend à quoi ressemble une bonne sortie. Un modèle entraîné sur des résultats apprend quelles actions mènent à de bons résultats, ce qui est une compétence différente et plus difficile.

Les actions sont des séquences. Un correctif qui passe les tests n'est pas une décision mais une chaîne de décisions : où regarder, quoi changer, quoi exécuter, comment lire un échec. L'apprentissage par renforcement en environnement réel donne au modèle un signal sur toute la chaîne, ce qui est le seul moyen d'apprendre que certains choix localement raisonnables mènent quelque part de mauvais. C'est l'intuition derrière l'usage de vrais dépôts plutôt qu'un ensemble de problèmes sélectionnés.

Cette approche est plus coûteuse et plus fragile à exploiter que l'affinage supervisé, ce qui explique pourquoi davantage de modèles ne l'adoptent pas. Elle tend aussi à produire des agents qui se comportent mieux dans des situations inconnues, parce qu'ils se sont entraînés à se remettre d'une erreur plutôt qu'à imiter ce qui est juste.

Ce qu'il faut surveiller

Le test évident est de savoir si un agent de 12B entraîné ainsi tient la route sur une vraie tâche de dépôt : diagnostiquer un test en échec, proposer un correctif, vérifier le résultat. Si c'est le cas, la question intéressante devient : jusqu'où un petit modèle ouvert peut-il approcher la qualité de code de pointe quand on lui donne un bon harnais et une boucle de rétroaction serrée.

Cette question a plus de conséquences que n'importe quelle sortie de modèle isolée. Si l'écart entre un agent de 12B et un modèle de pointe se réduit en pratique, alors une grande partie du marché des agents de codage cesse de tourner autour de qui a le meilleur modèle et commence à tourner autour de qui a les meilleurs outils autour d'un modèle suffisamment bon. Mellum2.1 est un point de données petit et concret dans cette direction, et c'est la direction qui compte.