Hugging Face et Lambda : comment analyser et affiner à partir des reasoning traces d'agents

MarkTechPost a publié une analyse pratique du jeu de données lambda/hermes-agent-reasoning-traces, qui aide à étudier comment les agents d'IA réfléchissent, appellent des outils et répondent dans des dialogues à plusieurs étapes. Il ne s'agit pas de la sortie d'un nouveau modèle, mais d'un pipeline de travail prêt à l'emploi : du parsing de traces brutes à l'analyse, aux graphiques et à la préparation des données pour le fine-tuning.

Le contenu du jeu de données

L'article repose sur un jeu de données de Lambda sur Hugging Face, avec deux configurations : kimi et glm-5.1. La première compte 7646 exemples, la seconde 7055. Chaque exemple comprend une liste de messages, la description des outils disponibles, la catégorie de la tâche, la sous-catégorie et la requête d'origine de l'utilisateur. Le format est proche de ShareGPT : le dialogue contient des messages système, utilisateur, agent et outil, si bien qu'un seul enregistrement permet de reconstituer presque tout le travail de l'agent.

«

Chaque exemple est un véritable dialogue agentique, avec un raisonnement pas à pas et de vrais résultats d'appels d'outils. »

La principale valeur du jeu de données tient à ce qu'il ne contient pas seulement la réponse finale, mais aussi les étapes intermédiaires. La configuration kimi affiche en moyenne 24,3 tours et 13,9 appels d'outils par exemple ; glm-5.1, 19,1 tours et 9,7 appels. L'ensemble compte neuf catégories au total, dont Terminal & Coding, Agent Tools, Repository Tasks, Browser Automation et File Operations. Autrement dit, ce ne sont pas des prompts jouets, mais des scénarios réels où l'agent écrit du code, navigue dans un navigateur, manipule des fichiers et sollicite des fonctions externes.

Comment fonctionne l'analyse

Les auteurs commencent par une inspection de base du split train via la bibliothèque datasets : ils examinent les champs, les catégories et un exemple précis. Ils construisent ensuite des parsers à base d'expressions régulières pour extraire séparément les blocs de raisonnement, les appels de fonctions et les réponses des outils. Cette étape découpe une trajectoire d'agent en parties lisibles et permet d'analyser à part le raisonnement interne, les actions et la réponse finale.

• Les pensées, les appels d'outils et le texte final sont extraits des messages de l'agent
• Les erreurs de parsing JSON sont signalées à part, pour ne pas casser le pipeline
• Sur un échantillon, on calcule la longueur des dialogues, le nombre d'appels et la fréquence des erreurs
• Des graphiques sont générés pour les outils les plus utilisés, les appels parallèles et la répartition des catégories

Sur un échantillon de 3000 trajectoires, le guide calcule les moyennes et les visualise avec matplotlib. Il montre aussi comment afficher une trace complète sous une forme lisible : où se trouvait la requête de l'utilisateur, où l'agent raisonnait, quel outil il a appelé et ce que celui-ci a renvoyé. Pour les équipes qui évaluent des agents, c'est particulièrement utile : au lieu d'un score final unique, on peut observer de vrais schémas de comportement, des appels superflus, des pensées vides et des erreurs récurrentes dans les réponses des outils.

Préparation à l'entraînement

Dans sa seconde moitié, le document passe de l'analyse à la pratique du ML. Les dialogues sont convertis dans un format de messages compatible avec les modèles de chat et les pipelines d'entraînement classiques, et les réponses des outils sont reconditionnées en contexte d'entrée pour l'étape suivante. Viennent ensuite la tokenisation et le label masking : seuls les tokens des messages de l'assistant entrent dans la loss, tout le reste est masqué. C'est une base importante pour le supervised fine-tuning lorsque l'objectif est d'apprendre au modèle à répondre et à agir à partir d'une trajectoire déjà parcourue.

Les auteurs ajoutent également un petit trace replayer, qui rejoue pas à pas le comportement de l'agent, et une boucle d'entraînement de démonstration avec TRL. L'exemple utilise le tokenizer de Qwen2.5 et un petit sous-ensemble de train : c'est donc davantage un modèle de départ qu'une recette prête pour la production. Mais c'est justement l'intérêt du document : on peut le lancer rapidement, changer la configuration, ajouter ses propres métriques et obtenir un laboratoire de base pour analyser des traces d'agents, sans longue préparation ni infrastructure superflue.

Ce que cela signifie

Le marché s'éloigne peu à peu de l'évaluation de la seule réponse finale pour analyser le comportement complet de l'agent d'IA. Des jeux de données et des guides de ce type offrent aux équipes un moyen concret de regarder non seulement ce que le modèle a répondu, mais aussi comment il a raisonné, s'est trompé et a appelé des outils, et sur quoi il convient de l'affiner ensuite.