MLE-World prédit le résultat d'une expérience de ML sans l'exécuter : 77,9 % de précision

Les agents qui écrivent et améliorent eux-mêmes du code pour des tâches de machine learning se heurtent à un poste de dépense coûteux : chaque candidat doit être réellement entraîné et évalué. L'équipe de MLE-World propose de remplacer une partie de ces exécutions par une prédiction. À partir du code du programme et de la description des données, son world model produit ce qu'afficherait le terminal : trace d'erreur, logs d'entraînement et score de validation. Sur des programmes mis de côté, il coïncide avec la sortie réelle dans 77,9 % des cas. De grands modèles, auxquels la même tâche était soumise par prompt, atteignent 41,1 %.

Un seul appel au lieu d'un entraînement complet

Le goulet d'étranglement des agents de ML se situe dans la boucle de rétroaction. À chaque étape, l'agent ne peut tester que quelques variantes, car chacune exige d'entraîner un modèle, ce qui représente des minutes, voire des heures de GPU. Résultat : soit l'agent retient peu de candidats, soit il dépense son budget en calculs qui, le plus souvent, aboutissent à un « ça ne marche pas ».

MLE-World change l'arithmétique. Une prédiction coûte un appel d'inférence, et non un entraînement. Le test-time scaling, c'est-à-dire la génération de plusieurs variantes à chaque étape puis le choix de la meilleure, devient ainsi accessible aux agents de recherche. Jusqu'ici, cette technique butait sur le coût de vérification de chaque candidat.

Le modèle ne prédit pas une « note de qualité » abstraite, mais la sortie textuelle du programme. Cela inclut les exécutions qui échouent : erreur d'import, dimensions incompatibles, manque de mémoire. L'agent a intérêt à savoir à l'avance qu'un candidat va planter, pour ne pas lui consacrer une exécution réelle.

Un niveau de confiance pour chaque prédiction

Tout world model a un point faible : il peut se tromper avec aplomb. Le système intègre donc un second composant, qui estime dans quelle mesure la prédiction est probablement juste. Ce n'est pas un ornement. L'exécution réelle d'un candidat n'est déclenchée que de façon sélective, en fonction de cette estimation de fiabilité : lorsque la confiance dans la prédiction est faible, l'agent paie pour une véritable exécution.

Sur cette base, les auteurs ont construit cinq politiques de test-time scaling. Toutes comparent, à chaque étape, plusieurs candidats d'après leurs sorties prédites, et non leurs sorties réelles. L'une d'elles ajoute à la sélection un bonus d'exploration, lui aussi fondé sur l'estimation de fiabilité. Il évite que l'agent ne s'enferme dans des variantes sur lesquelles le modèle est simplement sûr de lui.

Les chiffres et ce qu'ils disent

• Concordance de la prédiction avec la sortie réelle du terminal sur les programmes mis de côté : 77,9 %.
• Référence, des modèles nettement plus grands sollicités par prompt : 41,1 %.
• Gain du résultat moyen observé pour l'agent équipé de MLE-World par rapport à l'agent sans world model : jusqu'à 22,1 %.
• Le volume d'exécution réelle est, dans le même temps, inférieur à celui de l'agent sans modèle.
• Nombre de politiques de test-time scaling dans l'étude : cinq.
• Preprint : arXiv 2610.37175, page du projet mle-world.github.io.

Le point clé est la comparaison avec les grands modèles. Un prédicteur spécialisé, entraîné sur des paires « code et données → sortie », est presque deux fois plus précis que des LLM généralistes, qui n'ont pas vu assez d'exécutions réelles. La connaissance du comportement des pipelines s'acquiert mieux à partir de logs d'exécution que d'un pré-entraînement généraliste.

La formule « jusqu'à 22,1 % » désigne le meilleur cas, et non une garantie sur n'importe quelle tâche. La direction n'en reste pas moins cohérente sur le plan économique : une inférence bon marché remplace des heures de GPU coûteuses.

Si vous construisez des agents pour l'AutoML ou le code, l'approche a une application directe. Il vaut la peine de collecter, dans vos propres logs, des paires « code, description des données et sortie de l'exécution », car c'est précisément ce type de jeu de données qui entraîne un world model. Dans la boucle de l'agent, il convient de séparer le filtrage peu coûteux par prédiction de la vérification coûteuse par exécution réelle, en fixant le seuil de confiance grâce à l'évaluateur de fiabilité. Le budget GPU va ainsi aux candidats pour lesquels la prédiction est ambiguë ou le choix réellement important, tandis que les variantes manifestement cassées sont écartées avant l'exécution.