Axion 1.0-35B atteint 52,2 % sur HLE : ses auteurs publient le code d’entraînement de l’agent

Si votre agent doit trouver des informations dans plusieurs sources, les confronter et calculer une réponse, lui donner accès à un moteur de recherche ne suffit pas. Il faut aussi apprendre au modèle à exploiter ce qu’il trouve. Axion 1.0 propose une méthode ouverte pour cet entraînement. Pour les développeurs, c’est l’occasion d’étudier la préparation des données et de tester cette approche sur leurs propres tâches.

Le projet affiche un chiffre marquant : Axion 1.0-35B a obtenu 52,2 % sur Humanity’s Last Exam avec des outils. Mais pour une équipe qui construit un produit, une autre question est plus utile : quelles composantes de ce résultat peut-elle reproduire, et à quel coût dans son propre cas d’usage ?

Ce qui a précisément été publié

Selon le dépôt du projet, le plus petit modèle compte 35 milliards de paramètres, dont 3 milliards sont actifs lors des calculs. Le dépôt contient le code de génération et de filtrage des données, des instructions, ainsi que le code d’entraînement et d’évaluation. Toutefois, le README oriente les utilisateurs vers une reproduction des poids par la communauté et précise explicitement qu’il ne s’agit pas d’un checkpoint officiel d’Axion. La promesse de « télécharger le modèle des auteurs et reproduire le résultat » reste donc à vérifier séparément.

L’entraînement comprend deux étapes à partir d’exemples préparés, puis une étape d’apprentissage par renforcement. Le modèle commence par résoudre des tâches avec les informations disponibles dans l’énoncé, puis apprend à obtenir les renseignements manquants à l’aide d’outils. Lors de la dernière étape, il reçoit une récompense pour le résultat et pour des progrès intermédiaires vérifiables. Cette séquence est décrite dans la publication des auteurs.

L’intérêt pratique réside dans la possibilité d’examiner chaque composante du processus. Par exemple, une équipe pourrait trouver la méthode de construction de tâches vérifiables plus utile que le modèle lui-même. C’est particulièrement pertinent si son agent sait déjà appeler des outils, mais choisit régulièrement les mauvaises données pour ses calculs.

À quoi cela ressemble dans une tâche professionnelle

Imaginons un assistant chargé des achats. Il doit choisir le fournisseur offrant le coût de commande le plus bas tout en respectant un délai de livraison donné. Il lui faut trouver les offres, vérifier les disponibilités, convertir les prix dans une même devise et ajouter les frais de livraison. Une réponse bien rédigée ne vaut rien si l’agent a comparé des configurations différentes.

Pour entraîner cet assistant, on peut préparer à l’avance un tableau d’offres et calculer par programme le bon choix. On ne donne ensuite au modèle que la question et l’accès aux sources autorisées. On conserve la solution réussie, ainsi que la séquence d’actions. Cet exemple illustre comment transposer l’idée de tâches vérifiables dans un produit ; les auteurs n’annoncent pas d’agent d’achat prêt à l’emploi.

Il faut vérifier davantage que le montant final. La configuration choisie est-elle correcte ? Les délais correspondent-ils ? La livraison a-t-elle été prise en compte ? Ces vérifications intermédiaires permettent de comprendre à quel endroit précis la chaîne se rompt. Si la bonne réponse a été obtenue par hasard, mieux vaut ne pas considérer cet exemple comme une démonstration de fonctionnement fiable.

Il est possible de commencer sans entraîner soi-même un modèle. Constituez un petit ensemble de requêtes typiques, consignez les sources et les bonnes réponses, puis testez votre agent actuel. Cette seule étape révélera déjà ses lacunes : recherche, calcul ou compréhension des contraintes. Il sera ensuite plus facile de décider si un nouveau jeu de données est nécessaire.

Pourquoi 52,2 % ne suffisent pas pour choisir un modèle

Dans la description de l’évaluation, les auteurs indiquent le meilleur résultat d’une exécution individuelle, et non une moyenne. Pour l’évaluation principale sur HLE, l’accès à certains sites est restreint. Une partie des résultats des concurrents provient de rapports externes : les conditions de comparaison ne sont donc pas entièrement identiques. L’égalité avec GPT-5.5 dans le tableau ne peut pas être généralisée à toutes les tâches professionnelles.

Trois milliards de paramètres actifs ne signifient pas non plus qu’une quantité de mémoire adaptée à un modèle classique de cette taille suffit à l’héberger. Il faut tenir compte de l’ensemble des poids, du contexte et du mode d’exécution retenu. Le coût d’une tâche réussie inclut également la recherche, l’exécution de code et les nouvelles tentatives.

Pour un pilote, je comparerais Axion à la solution actuelle avec les mêmes outils et les mêmes limites. Je mesurerais la proportion de réponses correctes, le temps d’exécution et le coût par tâche achevée. Je testerais séparément les cas où une source est inaccessible ou les données contradictoires. Si l’avantage se maintient dans ces conditions, il y aura matière à envisager un déploiement. Pour l’heure, le principal apport pratique de cette publication est un processus d’entraînement d’agent accessible à l’étude.