Le modèle maison Mellum de JetBrains fait passer la part du code écrit par complétion de 0,25 à 0,39 en Python

Le problème

Les développeurs attendent de leurs outils de programmation qu’ils terminent les lignes et les blocs de code au fil de la frappe. La plupart des outils de ce type reposent sur des services fermés d’autres éditeurs ou sur de grands modèles de conversation, qui sont, selon JetBrains, coûteux et lents pour un usage à la vitesse de frappe, et dont les licences compliquent la redistribution. JetBrains proposait aussi déjà un petit modèle de complétion qui s’exécute sur l’ordinateur de chaque utilisateur, et voulait une qualité supérieure sans le délai d’un grand modèle.

Ce qu’ils ont construit

JetBrains a entraîné Mellum, un modèle de 4 milliards de paramètres conçu uniquement pour la complétion de code, et l’utilise pour la complétion dans le cloud au sein de ses outils pour développeurs. Il a été entraîné à partir de zéro sur du code sous licence permissive. La version publiée est open-weight (à poids ouverts : ses fichiers sont publiés, n’importe qui peut donc l’exécuter et l’adapter) sous licence Apache-2.0. Selon l’article, les modèles en production sont proches de ceux publiés, mais pas identiques.

Comment ils s’y sont pris

L’entraînement s’est déroulé en plusieurs étapes : un préentraînement large sur du code, puis un entraînement au remplissage du milieu d’un fichier, puis un entraînement avec le contexte du projet tiré d’autres fichiers, enfin une étape de préférences qui décourage les sorties inutiles comme les instructions vides et la génération sans fin. L’équipe a gardé le modèle petit pour qu’il réponde vite et tienne sur des GPU économiques. La qualité a été vérifiée hors ligne sur des benchmarks, puis en ligne à partir de la télémétrie des utilisateurs dans les outils.

Résultats

Dans la télémétrie de production, la part du code écrit avec la complétion était plus élevée pour le modèle cloud que pour le modèle local dans les neuf langages, par exemple 0,39 contre 0,25 en Python et 0,49 contre 0,42 en Java. La part des suggestions acceptées était plus élevée dans la plupart des langages, comme Python avec 0,34 contre 0,26, mais égale pour Java et Rust et plus basse pour Go et PHP. Une requête isolée prend 400 ms côté serveur, 700 ms aux pics.

Ce qu’il faut retenir

Si votre cas d’usage est étroit et que la latence compte, testez un petit modèle conçu pour cet usage avant un grand modèle généraliste. Mesurez-le sur l’usage réel et gardez à la fois une métrique d’usage et une métrique de qualité, car elles peuvent diverger.