Contrôler l'effort de raisonnement dans les LLM

Les 7 benchmarks qui comptent vraiment pour le raisonnement des agents autonomes dans les LLM

Alors que les agents d'intelligence artificielle quittent les laboratoires pour entrer dans les environnements de production, une question s'impose : comment évaluer concrètement leurs capacités ? Les métriques classiques comme les scores MMLU ou la perplexité ne disent rien sur la capacité d'un modèle à naviguer sur un site web, à résoudre un ticket GitHub ou à gérer un flux de service client sur des centaines d'interactions. Face à ce vide, la communauté a développé une nouvelle génération de benchmarks agentiques, dont sept ont émergé comme de véritables signaux de capacité. Premier avertissement fondamental : ces scores dépendent fortement du scaffolding utilisé. Le design du prompt, les outils disponibles, le budget de tentatives, l'environnement d'exécution et la version de l'évaluateur peuvent tous modifier significativement les résultats publiés. Un chiffre isolé ne vaut rien sans son contexte de production. Le benchmark SWE-bench, disponible sur swebench.com, est aujourd'hui la référence la plus citée pour l'ingénierie logicielle. Il soumet les agents à 2 294 problèmes réels tirés d'issues GitHub sur 12 dépôts Python populaires : le modèle doit produire un patch fonctionnel qui passe les tests unitaires, pas simplement décrire une solution. Le sous-ensemble Verified, composé de 500 échantillons validés par des ingénieurs professionnels en collaboration avec OpenAI, est la version standard des évaluations actuelles. Sa trajectoire est éloquente : en 2023, Claude 2 ne résolvait que 1,96 % des problèmes ; fin 2025 et début 2026, les modèles frontier les plus avancés franchissent la barre des 80 % sur ce même jeu de données. GAIA, hébergé sur Hugging Face, teste quant à lui des capacités d'assistance généraliste : raisonnement en plusieurs étapes, navigation web, usage d'outils et compréhension multimodale. Ses tâches paraissent simples en surface mais exigent des chaînes d'opérations non triviales, ce qui en fait un détecteur efficace de fragilité dans l'usage des outils. WebArena, sur webarena.dev, évalue la navigation web autonome dans des environnements fonctionnels simulant e-commerce, forums, développement collaboratif et gestion de contenus. Ces benchmarks reflètent une transformation profonde de ce que l'on attend des LLMs. L'ère des modèles évalués sur des QCM académiques est révolue : l'enjeu est désormais de mesurer leur capacité à agir de façon autonome dans des environnements complexes et bruités. Un score élevé sur SWE-bench indique une force spécifique en réparation de code, pas une autonomie universelle, ce qui explique pourquoi les équipes sérieuses croisent plusieurs benchmarks. Les modèles propriétaires tendent à surpasser les modèles open source, mais la performance dépend autant du harness d'exécution que du modèle sous-jacent. À mesure que les déploiements agentiques se généralisent en entreprise, ces outils d'évaluation deviennent des instruments de pilotage essentiels, non plus de simples curiosités académiques.

💬 SWE-bench à 80%, c'est le chiffre qui claque, mais le vrai message est ailleurs : un score sans son contexte de scaffolding ne vaut rien, et les équipes qui déploient des agents en prod commencent à l'intégrer. Passer de 2% à 80% sur ce benchmark en deux ans, ça donne le vertige, mais ça mesure la réparation de code Python sur GitHub, pas l'autonomie universelle. Reste à voir si les prochains modèles seront entraînés dessus et rendront ces évaluations caduques avant même qu'elles soient adoptées en entreprise.

Z.ai lance GLM-5.2 : contexte de 1 million de tokens, deux niveaux d'effort de raisonnement, sans benchmarks au lancement

Z.ai a dévoilé le 13 juin 2026 GLM-5.2, troisième sortie majeure de sa gamme GLM-5 après GLM-5 (11 février), GLM-5-Turbo (15 mars) et GLM-5.1 (7 avril), soit quatre modèles de premier plan dédiés au codage en environ quatre mois. La caractéristique phare de ce nouveau modèle est sa fenêtre de contexte de 1 000 000 de tokens, une variante que Z.ai désigne glm-5.2[1m] dans sa propre configuration, contre 200 000 tokens pour GLM-5.1, soit une multiplication par cinq. Chaque réponse peut générer jusqu'à 131 072 tokens en sortie. Le modèle introduit également deux niveaux d'effort de raisonnement, High et Max, ce dernier étant recommandé par Z.ai pour les tâches de codage complexes en plusieurs étapes. Z.ai n'a publié aucun score de référence au lancement: ni SWE-bench, ni Terminal-Bench, ni Code Arena. La licence est MIT, mais les poids du modèle ne seront diffusés que la semaine suivante. Cette fenêtre d'un million de tokens transforme concrètement le travail d'un agent de codage. L'agent peut désormais conserver un dépôt de taille moyenne entier en mémoire de travail, fichiers sources, tests, configuration et historique de conversation compris, évitant ainsi les résumés permanents qu'imposent les fenêtres plus réduites. En pratique, cela ouvre la voie à des refactorisations à l'échelle d'un dépôt complet: un agent peut charger un pipeline de données Python de quarante fichiers et suivre les dépendances entre fichiers en une seule session, sans avoir à recharger le code. Le modèle vise aussi les exécutions autonomes de longue haleine, ces boucles soutenues de planification, d'exécution, de test et de correction; à titre de comparaison, GLM-5.1 enchaînait environ 1 700 étapes d'agent en une session, avec des boucles autonomes pouvant durer jusqu'à huit heures. GLM-5.2 se présente enfin comme un remplaçant direct de Claude Code, l'utilisateur n'ayant qu'à changer l'URL de base et l'identifiant du modèle, et permet d'analyser de longs documents, spécifications, journaux ou transcriptions dépassant les 200 000 tokens. Sur le plan technique, Z.ai n'a pas détaillé l'architecture de GLM-5.2 dans ses supports de lancement, mais selon les notes de la communauté, la base GLM-5 repose sur un modèle Mixture-of-Experts de 744 milliards de paramètres, dont 40 milliards sont activés par token, une ossature que GLM-5.1 avait conservée en réorientant seulement son post-entraînement. L'absence de tout chiffre de performance au lancement détonne dans un secteur où les classements façonnent la perception des modèles, d'autant que GLM-5.1 affichait un score de 58,4 sur SWE-bench Pro; la communication de Z.ai s'est concentrée sur la disponibilité, le contexte étendu et la feuille de route open source plutôt que sur les comparaisons. Ce positionnement illustre la cadence effrénée d'un acteur chinois qui multiplie les sorties pour s'imposer comme alternative crédible aux modèles propriétaires occidentaux, en misant à la fois sur une licence MIT permissive et sur une compatibilité directe avec les outils existants. Reste à voir si les benchmarks, attendus avec la publication des poids, confirmeront que cette fenêtre d'un million de tokens s'accompagne des gains de qualité que la concurrence exigera.

Kimi K2.7-Code réduit les tokens de raisonnement de 30 %, mais les praticiens contestent les benchmarks

Moonshot AI a publié cette semaine Kimi K2.7-Code, une mise à jour open source de sa famille de modèles de codage K2. Construit sur la même architecture mixture-of-experts à un trillion de paramètres que son prédécesseur K2.6, le modèle est disponible sous licence Modified MIT, téléchargeable sur HuggingFace et déployable via vLLM ou SGLang. Il s'intègre via une API compatible OpenAI, ce qui facilite la migration pour les équipes déjà en production avec K2.6. La principale promesse de Moonshot AI : une réduction de 30 % des tokens de raisonnement ("thinking tokens") par rapport à K2.6, ce qui se traduirait directement par une baisse des coûts d'inférence dans les workflows agentiques. Sur ses propres benchmarks propriétaires, l'entreprise annonce des gains de 21,8 % sur Kimi Code Bench v2, 11 % sur Program Bench et 31,5 % sur MLS Bench Lite. Sur le plan technique, le modèle génère désormais du code bas niveau en l'écrivant directement, là où K2.6 s'appuyait sur des wrappers de bibliothèques existantes, une approche censée améliorer la généralisation sur Rust, Go et Python. Le problème, soulevé immédiatement par des praticiens, est que ces chiffres proviennent exclusivement de benchmarks internes à Moonshot. Le chercheur Elliot Arledge a testé K2.7-Code face à K2.6 et à Claude Fable 5 sur KernelBench-Hard, un benchmark public spécialisé dans l'optimisation de kernels GPU, et a publié ses logs complets. Son verdict : "K2.7 est plus honnête, mais pas plus capable." Sur cinq des six problèmes testés, K2.7-Code a bien produit des kernels Triton réels là où K2.6 utilisait des wrappers, mais deux de ces kernels ont échoué à cause de bugs du modèle lui-même. Sur le kernel MoE, le score a même régressé, passant de 0,222 à 0,157 par rapport à K2.6. Claude Fable 5, lui, "arrive en tête sur chaque cellule où il n'échoue pas honnêtement", note Arledge. Sugumaran Balasubramaniyan, développeur d'un routeur de tâches pour la plateforme Hermes Agent, a interpellé Moonshot directement : "Avec tout le respect dû, chaque modèle 'progresse' de deux chiffres sur sa propre suite de tests." Il a rappelé que K2.6 ne score que 24 % sur DeepSWE, un benchmark indépendant bien plus discriminant, au même niveau que GPT-5.4-mini, et a demandé si K2.7-Code serait soumis au même test. Cette situation illustre un problème structurel dans l'évaluation des modèles de codage : la prolifération des benchmarks propriétaires rend les comparaisons quasi impossibles, tandis que des outils indépendants comme DeepSWE, qui produit un écart de 70 points entre modèles contre seulement 30 pour SWE-Bench Pro, restent sous-utilisés. Moonshot AI avait réussi une percée remarquée en avril lorsque K2.6 était arrivé en tête du classement hebdomadaire d'OpenRouter, fondé sur les décisions réelles de routage des développeurs. K2.7-Code, lui, n'a pas encore été soumis à ce type de validation externe. Pour les équipes en production, la bonne nouvelle est concrète : la réduction des tokens de raisonnement est testable immédiatement via l'API compatible OpenAI, sans refonte d'architecture. Mais la question de savoir si ces gains se maintiennent sur des tâches réelles, et si le modèle dépasse effectivement K2.6 sur des benchmarks indépendants, reste entière.

💬 Tout le monde annonce des gains à deux chiffres sur sa propre suite de tests, et Moonshot ne fait pas exception. La bonne nouvelle, c'est que la réduction de tokens de raisonnement est testable directement via l'API, sans refonte d'archi. K2.6 score 24 % sur DeepSWE au niveau de GPT-5.4-mini, alors avant de migrer, je veux voir K2.7 passer les mêmes épreuves.

Guide pratique : affiner un LLM avec TRL, du supervised fine-tuning au raisonnement DPO et GRPO

Un guide complet consacré à l'entraînement post-initialisation des grands modèles de langage vient d'être publié, proposant une progression pédagogique couvrant quatre techniques clés : le réglage fin supervisé (SFT), la modélisation de récompense (RM), l'optimisation directe des préférences (DPO) et l'optimisation de politique par groupe relatif (GRPO). Le tutoriel s'appuie sur la bibliothèque TRL (Transformer Reinforcement Learning), développée et maintenue par Hugging Face, combinée à des outils comme PEFT et LoRA, qui permettent de réduire drastiquement la mémoire nécessaire. Point notable : l'ensemble du pipeline peut tourner sur un GPU T4 de Google Colab, soit environ 15 Go de VRAM, rendant ces techniques accessibles à quiconque dispose d'un compte Google. Le modèle de base utilisé est Qwen2.5-0.5B-Instruct, un modèle léger de 500 millions de paramètres développé par Alibaba, qui sert de point de départ à chacune des quatre étapes d'alignement. Ce guide se distingue par sa complétude : peu de tutoriels enchaînent l'intégralité du pipeline d'alignement, du SFT jusqu'au raisonnement par GRPO, avec du code fonctionnel et des explications progressives. Pour les équipes techniques cherchant à adapter un modèle open-weight à des usages métiers spécifiques, ou à reproduire les techniques d'alignement des grands laboratoires, ce type de ressource pratique est précieux. Le GRPO notamment, popularisé par DeepSeek-R1 en janvier 2025, est désormais intégré nativement dans TRL, ce qui permet d'entraîner des modèles à raisonner par étapes vérifiables sans les coûts prohibitifs d'un pipeline RLHF classique avec modèle de récompense séparé. L'alignement des LLMs s'est imposé comme l'un des sujets centraux de l'IA depuis qu'InstructGPT d'OpenAI a montré qu'un volume relativement faible de données de préférence pouvait radicalement améliorer le comportement d'un modèle. TRL est devenu la référence open source pour implémenter ces méthodes, avec des mises à jour qui intègrent régulièrement les dernières avancées de la recherche. La tendance est aujourd'hui aux approches qui n'exigent pas de modèle de récompense distinct, comme DPO et GRPO, car elles simplifient le pipeline tout en atteignant des résultats comparables. Ce contexte explique l'intérêt croissant pour le fine-tuning de modèles open-weight comme Qwen, Llama ou Mistral, que des startups et des équipes internes cherchent à spécialiser sans dépendre d'API propriétaires.