Spaces:
Running
Running
| import streamlit as st | |
| st.set_page_config(layout="wide") | |
| from streamlit_extras.switch_page_button import switch_page | |
| st.markdown("""# Panorama 2025""") | |
| st.markdown(""" """) | |
| st.markdown("""## Evaluer en 2025 : aller au-delà des simples benchmarks pour construire des modèles réellement utilisables par les gens | |
| Je crois que nous devrions cibler la construction de modèles qui « fonctionnent bien » plutôt que des modèles « intelligents ». C'est une meilleure mesure du succès de l'utilisation d'outils utiles et efficaces pour les gens plutôt que de cibler « l'intelligence générale » afin de résoudre les problèmes à notre place tout en créant toute une série d'autres problèmes sur le chemin. | |
| D'après les récents rapports d'[Anthropic](https://www.anthropic.com/research/anthropic-economic-index-september-2025-report) et d'[OpenAI](https://cdn.openai.com/pdf/a253471f-8260-40c6-a2cc-aa93fe9f142e/economic-research-chatgpt-usage-paper.pdf), les cas d'utilisation actuels les plus fréquents des LLM semblent en effet être des assistants pour le codage, le support administratif ainsi et les modèles ont fait des progrès cette année sur les cas d'utilisation agentiques généraux. | |
| Alors, que devriez-vous tester si vous voulez construire un modèle qui est un bon assistant ? | |
| Un bon assistant doit être capable de faire ce qui suit : à partir d'une requête, il doit gérer l'ambiguïté des instructions, construire un plan étape par étape, identifier correctement les ressources nécessaires, appliquer ledit plan sans se laisser distraire, appeler les outils au besoin, s'adapter aux événements inattendus lors de l'application de son plan ou aux nouvelles informations qu'il trouve, tout cela sans conneries. Ce comportement nécessite une combinaison de capacités, telles que le « raisonnement » étape par étape, la gestion d'un long contexte, l'adaptabilité, de faibles taux d'hallucination, avec des capacités d'appel d'outil, de mathématiques, de code. Des modèles aussi petits que les 7B peuvent être de bons agents assistants (bien que nous ayons observé qu'une taille inférieure se heurte à une barrière en dessous de 3B). | |
| Comment évaluer si les agents sont bons dans toutes ces tâches ? Cela nécessite une approche à plusieurs niveaux : tester les capacités individuelles pendant le développement, mesurer les performances intégrées sur des tâches réalistes et sonder l'adaptabilité dans des environnements dynamiques. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Tester des capacités spécifiques | |
| Vous pouvez évaluer les **capacités spécifiques** d'un modèle. Il est généralement intéressant d'obtenir un signal lors de l'entraînement, ou lors de la comparaison de modèles de base/pré-entraînés. | |
| Cependant, si vous sélectionnez et validez vos méthodes d'entraînement sur ces capacités, la pertinence du modèle final sera légèrement biaisé car vous avez déjà orienté votre méthode d'entraînement vers de bons résultats sur celles-ci. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Connaissances | |
| Le principal jeu de données d'évaluation des connaissances a été [MMLU](https://arxiv.org/abs/2009.03300) (2020). Il a fini par être saturé/contaminé et après un examen plus approfondi, un certain nombre de problèmes ont été identifiés : des questions incomplètes renvoyant à des documents absents, des réponses cibles incorrectes, des questions ambiguës et un américanocentrisme flagrant dans les sujets choisis. Il a donc été nettoyé dans [MMLU-Redux](https://arxiv.org/abs/2406.04127) (2024), complété avec des questions plus complexes et davantage de réponses dans [**MMLU-Pro**](https://arxiv.org/abs/2406.01574) (2024, le principal remplaçant utilisé par la communauté à l'heure actuelle), et traduit/annoté pour les biais culturels dans [Global-MMLU](https://arxiv.org/abs/2412.03304) (2024). | |
| Un autre jeu de données de connaissances de haute qualité est [**GPQA**](https://arxiv.org/abs/2311.12022) (2023), des questions personnalisées de niveau doctorat en biologie/chimie/physique, conçues pour être adressées par des doctorants dans le bon domaine et pas autrement. Le sous-ensemble le plus utilisé est celui dit « diamant », mais depuis sa publication en 2023, il a également commencé à être contaminé. | |
| Enfin, le pompeusement nommé mais de très haute qualité [**Humanity's Last Exam**](https://agi.safe.ai/) (2024) contient 2,5K questions posées par des experts dans leur domaine, dans tous les domaines. C'est la plupart du temps privé, et les questions nécessitent à la fois des connaissances et un raisonnement complexes. Il n'a pas encore été cassé, et c'est un jeu de données cool. Le seul problème est que, puisqu'il n'y a aucun moyen d'obtenir un score rapidement lors de l'évaluation d'un modèle, les gens évaluent utilisent principalement un *LLM-as-a-judge* pour évaluer leurs réponses au lieu de vérifier par rapport à la vérité terrain. C'est donc l'une évaluation où vous obtiendrez des résultats probablement incomparables dans la nature. | |
| Cependant, bien que tester les modèles pour la qualité brute de leurs connaissances latentes avait beaucoup de sens il y a quelques années (et est toujours intéressant lors de l'entraînement pour tester la qualité des modèles, avec des évaluations comme MMLU-Pro pendant le pré-entraînement et GPQA/HLE pour le post-entraînement), je pense que nous allons lentement éliminer progressivement des repères comme celui-ci dans les prochaines années. | |
| Pour 2 raisons : | |
| 1. Elles deviennent de plus en plus indéchiffrables pour l'homme : les questions deviennent si complexes qu'il est presque impossible pour les non-experts de comprendre ce que signifie la performance sur chaque question (et de s'assurer que les jeux de données eux-mêmes ne contiennent pas d'erreurs) | |
| 2. Maintenant que nos modèles sont connectés à des outils, tels que l'accès à Internet, les évaluations des connaissances latentes deviennent de plus en plus des évaluations de recherche et d'extraction sur le Web, de sorte qu'elles ont moins de sens en tant que telles. En bref, on passe d'une évaluation à livre fermé à une évaluation à livre ouvert. À titre de comparaison, dans le système scolaire français, vous avez des examens à livres fermés au lycée, mais lorsque vous entrez à l'université, on suppose souvent que vous aurez accès aux bases de données, à Internet, et la notation devient moins sur ce que vous avez appris par cœur, et plus sur la façon dont vous raisonnez en donnant un accès libre à l'information. Je pense que c'est aussi un changement que nous verrons dans l'évaluation LLM avec l'augmentation des capacités du modèle. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Mathématiques | |
| Les jeux de données d'évaluation des mathématiques ont été utilisés comme substituts pour le raisonnement et l'analyse comparative de la logique, indépendamment, bien sûr, de la vérification de la capacité des modèles à résoudre des problèmes mathématiques. | |
| Les deux jeux de données d'évaluation mathématique de référence étaient [GSM8K](https://arxiv.org/abs/2110.14168) (2021), contenant des problèmes de mathématiques d'école primaire et [MATH](https://arxiv.org/abs/2103.03874) (2021), une agrégation de problèmes d'olympiades présents sur le Web, qui ont fini saturatés/contaminés au cours des dernières années. Le premier a été étendu par [GSM1K](https://arxiv.org/abs/2405.00332) (2024) qui est une reconstruction du jeu de données incluant 1000 nouveaux problèmes, pour tester quels modèles ont été contaminés sur le premier, [GSM-Plus](https://arxiv.org/pdf/2402.19255) qui est une réécriture de modèles avec des changements contradictoires (distracteurs, variations numériques, etc.) et [GSM-Symbolic](https://arxiv.org/abs/2410.05229) (2024) qui est moins utilisé mais est une réécriture très intéressante de GSM8K en tant que modèles de problèmes, pour éviter la contamination et où mes problèmes peuvent être régénérés à l'infini. | |
| La communauté se concentre maintenant sur l'utilisation : | |
| - Des dérivés de MATH, soit [**MATH-500**](https://huggingface.co/datasets/HuggingFaceH4/MATH-500) (un sous-ensemble représentatif de 500 problèmes échantillonnés pour éviter le surentraînement) et MATH-Hard (uniquement les 500 questions les plus difficiles) | |
| - **AIME** ([24](https://huggingface.co/datasets/HuggingFaceH4/aime_2024), [25](https://huggingface.co/datasets/math-ai/aime25)), jeux de données des Olympiades américaines pour les lycéens, pris en l'état lors de la publication. Ces jeux de données sont intéressants car, puisqu'ils sont constitués de problèmes renouvelés chaque année avec une difficulté équivalente, ils permettent de tester la contamination en comparant les résultats à la publication avec les résultats de l'ensemble de données de l'année précédente | |
| - [**Math-Arena**](https://matharena.ai/), une compilation à jour des compétitions et olympiades actualisées régulièrement (elle contient AIME25, mais beaucoup d'autres compétitions aussi !) | |
| La plupart de ces jeux de données ne sont en fait plus « si difficiles », puisqu'ils s'arrêtent au niveau de l'école primaire (même si GSM-Symbolic permet de générer des problèmes avec plus de niveaux de récursivité, ce qui les rend synthétiquement plus difficiles). De l'autre côté du spectre, [FrontierMath](https://arxiv.org/abs/2411.04872) (2024) était une tentative de fournir des problèmes mathématiques considérablement plus difficiles, écrits individuellement par des mathématiciens pour l'occasion. Le jeu de données était théoriquement privé (mais il semble qu'OpenAI ait eu accès à certaines parties...). [Humanity's Last Exam](https://agi.safe.ai/) (2025) (introduit dans la section des connaissances) contient également des problèmes mathématiques intéressants « faits pour l'occasion » nécessitant un raisonnement complexe (notamment la preuve de certains théorèmes). | |
| Personnellement, j'utiliserais AIME25 et MATH-500 pour les évaluations de pré-entraînement, et le Math-Arena pour le post-entraînement. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Le code | |
| Comme les agents ont besoin d'interagir avec des outils, ils ont besoin de capacités de codage, soit pour appeler directement ces outils, soit pour comprendre comment déboguer la sortie de l'outil en cas de problème (voir la différence entre ces deux types d'agents [ici](https://huggingface.co/learn/agents-course/fr/unit2/smolagents/tool_calling_agents)). Les jeux d'évaluation de codage sont également de bons indicateurs du raisonnement. | |
| Historiquement, en 2021, les jeux d'évaluation de code étaient [MBPP](https://arxiv.org/abs/2108.07732), 1K problèmes d'entrée de gamme de programmation en Python, [APPS](https://arxiv.org/abs/2105.09938), 10K problèmes de génération de code organisés à partir d'entretiens de programmation et de sites Web de partage, et [HumanEval](https://arxiv.org/abs/2107.03374), introduit avec le modèle Codex, qui contrairement au précédent est composé de problèmes « spécifiquement conçus pour la sortie », ce qui était super chouette à l'époque ! Il est également livré avec un bac à sable pour éviter l'exécution problématique du code sur la machine de l'évaluateur. (La dernière chose que cet article a introduite est un estimateur pour le pass@k, qui avant cela était calculé avec une vérification littérale sur le fait qu'une évaluation était un succès plus de k fois sur n). | |
| L'équipe [EvalPlus](https://openreview.net/pdf?id=1qvx610Cu7) (2023) a créé HumanEval+ et MBPP+, des extensions du premier, en ajoutant plus de cas de test et en corrigeant des bogues dans les jeux originaux, ainsi qu'en ajoutant plus d'entrées. [EvoEval](https://arxiv.org/abs/2403.19114) (2024) a également introduit une variante d'HumanEval en réécrivant sémantiquement les problèmes et en ajoutant un étiquetage de difficulté. | |
| [**LiveCodeBench**](https://arxiv.org/abs/2403.07974) (2024) suit une approche similaire de « saisie sur les sites Web Leetcode », mais est très intéressante car elle stocke la date du problème, pour comparer les performances du modèle sur les problèmes créés avant et après la fin de l'entraînement. C'était un excellent point de référence sans contamination, et j'ai hâte de voir une mise à jour ! | |
| [**AiderBench**](https://aider.chat/docs/leaderboards/) (en ligne depuis fin 2024 je crois ?) utilise également des données de sites Web de codage existants (Exercism pour être précis), mais va au-delà de la résolution de problèmes en testant spécifiquement l'édition de code et la refactorisation. | |
| Quelques benchmarks sont ensuite allés au-delà de l'évaluation sur des problèmes autonomes, qui n'évaluaient pas des capacités de codage complexes. [RepoBench](https://arxiv.org/abs/2306.03091) (2023) teste les systèmes d'autocomplétion en Python ou Java, en utilisant le code de Github comme source. Il a été construit en masquant des lignes aléatoires dans les bases de code et en demandant des complétions, soit une fonction de fichier croisé, soit une fonction de fichier, et définit plusieurs niveaux de test (récupération, complétion, une combinaison). | |
| [**SweBench**](https://openreview.net/pdf?id=VTF8yNQM66) (2024) est une version plus connue et plus complète de celle-ci, utilisant également GitHub, mais cette fois en testant si les modèles peuvent résoudre des problèmes existants, la compréhension logique, l'édition et l'exécution de fichiers croisés, le raisonnement contextuel long, etc. | |
| À ce stade, je recommanderais de suivre LiveCodeBench, AiderBench et le sous-ensemble de qualité supérieure de SWE-Bench (vérifié par SWE-Bench), et de lire le [rapport METR](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/) sur l'utilité réelle de l'assistant de code. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Long contexte | |
| Pour interagir correctement avec les utilisateurs au cours d'une longue discussion, sans perdre le fil, vous avez besoin d'une bonne gestion du contexte (c'est drôle de penser qu'il y a 3 ans, les longueurs maximales de contexte pour les modèles étaient de 2048 *tokens*, alors que maintenant nous sommes largement à 128K et au-delà). | |
| L'évaluation qui a commencé à tester cela en 2023 est probablement [NIAH](https://github.com/gkamradt/LLMTest_NeedleInAHaystack), où vous placez un fait aléatoire dans un long texte sans rapport et demandez au modèle de le récupérer. Il fournit un cadre soigné pour évaluer où dans le contexte un modèle est le plus susceptible d'oublier des choses, et à partir de quelle durée de contexte. En 2023, les modèles étaient vraiment mauvais dans ce domaine, en 2025, ils sont proches de la solution. | |
| Des extensions plus complexes ont émergé depuis. [RULER](https://arxiv.org/pdf/2404.06654) (2024) ajoute le traçage multi-sauts (obligeant le modèle à suivre des chaînes de variables pour obtenir la valeur correcte), les changements de fréquence des mots et ajoute une variante QA de NIAH. Il est également sur le point d'être résolu maintenant. [Michel-Ange](https://arxiv.org/pdf/2409.12640v2) (2024, aussi parfois appelé MRCR pour *multi round co reference*) utilise également des données synthétiques : des tâches (de longueur variable) testent si les modèles peuvent reproduire précisément des parties uniques du contexte (ainsi que d'identifier si des informations pertinentes sont présentes) et de comprendre la séquence de modifications d'un texte. Il a ensuite été prolongé dans [MRCR](https://huggingface.co/datasets/openai/mrcr) (2025). [Banc de l'infini](https://arxiv.org/abs/2402.13718) (2024) est multilingue (anglais & chinois), et fournit 100K tokens de tâches de données synthétiques, à travers une variété d'objectifs (QA, récupération comme dans NIAH, calculs sur un contexte très long, ...). InfinityBench fournit toujours un certain signal. | |
| [**CASQUE**](https://arxiv.org/abs/2410.02694) (2024) combine les tâches et les benchmarks existants pour obtenir un grand jeu de données unique avec plus de signal : RAG et QA (Natural questions, TriviaQA, PopQA, HotpotQA, Narrative QA et InfinityBench), rappel (RULER et JSONKV), génération avec citation (sous-ensembles d'ALCE), résumé, reclassement de passages (MS MARCO), apprentissage en contexte (TREC, NLU, Banking77, CLINIC150). Les agrégations de benchmarks sont exhaustives mais présentent le risque de mesurer les choses deux fois : n'allez pas tester votre modèle à la fois contre HELMET et InfinityBench, puis agréger les résultats, par exemple, car vous feriez deux fois la même évaluation ! En 2025, il dispose encore d'un pouvoir discriminant suffisant pour comparer les modèles. | |
| Mes idées préférées d'évaluations de long contexte sont le [Novel Challenge](https://arxiv.org/abs/2406.16264) (2024), 1K affirmations vraies/fausses sur des livres fictifs publiées l'année dernière (par les lecteurs desdits livres !) nécessitant d'avoir lu et compris le texte intégral pour répondre correctement, et le [*Kalamang translation dataset**](https://arxiv.org/abs/2309.16575) (2024), où les modèles doivent traduire correctement de l'anglais vers le kalamang à partir de la lecture d'un livre de grammaire (le kalamang est une langue si peu ressource qu'il n'a aucune présence en ligne - seulement 200 intervenants). L'ensemble de traductions en kalamang pourrait notamment être étendu à d'autres langues à faibles ressources (mais ce serait cool de l'étendre pour utiliser un vérificateur de grammaire basé sur des règles pour tester la validité de la génération afin d'obtenir une précision stricte au lieu de compter sur BLEU...). | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Suivre des instructions | |
| Les deux principaux jeux de données de suivi d'instructions sont [**IFEval**](https://arxiv.org/abs/2311.07911) (2023) et son extension [**IFBench**](https://arxiv.org/abs/2507.02833) (2025). IFEval est l'une des idées d'évaluation les plus intelligentes de ces dernières années, à mon avis : on demande aux modèles de suivre des instructions de formatage (sur les mots-clés, la ponctuation, le nombre de mots/phrases, le formatage du type de fichier tel que markdown ou html, etc.). Chacune de ces conditions peut être vérifiée avec un test d'analyse spécifique : cela signifie que cette évaluation est l'une des rares évaluations génératives de forme libre où vous pouvez obtenir un score strict sans vous fier à un *model-as-a-judge*. | |
| Plus généralement, il s'agit d'une évaluation de l'exactitude fonctionnelle et des tests unitaires, qui est ma façon préférée d'évaluer les modèles. Il est également très facile de le régénérer ou de l'étendre pour éviter la contamination. | |
| """, unsafe_allow_html=True) | |
| st.info("""Certains benchmarks testent également le « non suivi d'instruction » (non-conformité) : [CoCoNot](https://www.arxiv.org/pdf/2407.12043) (2024) teste notamment si les modèles se conformeront ou non à des demandes incomplètes (sous-spécifiées/peu claires), sans réponse (par manque d'information ou humanisation de l'IA, déclenchant souvent des hallucinations) ou dangereuses. Il utilisait l'écriture manuelle de requêtes, de modèles pour écrire des requêtes non conformes, puis filtré pour créer un ensemble d'évaluations présenté comme un problème de classification. | |
| """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### L'appel d'outils | |
| L'émergence des outils est l'une des caractéristiques qui ont commencé à faire passer les LLM dans le domaine agentique. | |
| [**TauBench**](https://arxiv.org/pdf/2406.12045) (2024) évalue un modèle sur sa capacité à répondre à la requête d'un utilisateur dans les domaines de la vente au détail et du transport aérien (commander/réserver/rechercher des produits/etc). La base de données imite les données du domaine réel avec des échantillons synthétiques, et le modèle est considéré comme correct lorsque 1) ses actions ont correctement mis à jour la base de données et 2) il a répondu à l'utilisateur de manière appropriée. Pour rendre ce benchmark automatique, l'utilisateur est maquillé par un LLM, ce qui rend cette évaluation assez coûteuse à exécuter et sujette à des erreurs. Malgré ces limitations, il est assez utilisé, notamment parce qu'il reflète bien les cas d'utilisation réels. | |
| [ToolBench](https://arxiv.org/pdf/2305.16504) (2023) nécessitent l'appel d'API (OpenWeather, Cat, HomeSearch, TripBooking, GoogleSheets, WebShop, Tabletop, etc.) pour résoudre 100 cas de test dans le jeu de données, nécessitant entre 1 et 10 appels d'outil pour être résolus. Certaines de ces API sont des maquettes et d'autres sont réelles, ce qui rend le jeu de données susceptible de tomber en panne accidentellement. Il a donc été corrigé et étendu dans [StableToolBench](https://arxiv.org/pdf/2403.07714) (2025), qui introduit un *VirtualAPIServer* général simulant tout pour assurer la stabilité de l'évaluation, mais s'appuyant sur un *LLM-as-a-judge* pour l'évaluation, introduisant une autre couche de biais. | |
| [**BFCL**](https://openreview.net/pdf?id=2GmDdhBdDk) (2025, mais le benchmark a en fait quelques années) a considérablement évolué au cours de l'année, et dans sa version actuelle contient 4 sous-ensembles : tour unique (appels d'outils simples), appels de fonctions de la vie réelle provenant d'utilisateurs, conversations à plusieurs tours (pour tester la précision dans un contexte long et répondre aux requêtes avec des appels d'outils) et agentique (recherche Web, mémoire, interaction de données SQL). Il s'agit d'utiliser une combinaison d'arbres de syntaxe abstraits, de réponse d'exécution et de correspondance d'état (l'état final est-il attendu) pour évaluer si les appels sont corrects. Les gens se concentrent sur la v3 pour tester spécifiquement l'appel d'outils, et la v4 teste l'utilisation du Web et de l'outil de recherche. | |
| Enfin, avec la création des MCP, certains benchmarks sont apparus pour tester l'appel d'outils orientés MCP. Cependant, tous s'appuyant principalement sur des *LLM-as-a-judge* et utilisant des API du monde réel, qui peuvent introduire des cas d'échec potentiels/un manque de reproductibilité en raison de problèmes de réseau (il semble que la charge supplémentaire pour les créateurs de sites Web ne soit pas trop un problème car la base d'utilisateurs de la plupart des MCP couverts est assez grande). | |
| [MCPBench](https://arxiv.org/abs/2508.20453) (2025) connecte les LLM à des serveurs MCP réels en direct (Wikipédia, HF, Reddit, Steam, arxiv, ...) avec des tâches nécessitant plusieurs tours pour être résolues (créées synthétiquement). L'évaluation combine des vérifications basées sur des règles sur la validité et le succès des appels d'outils avec un *LLM-as-a-judge* pour évaluer si les requêtes ont été correctement répondues. | |
| [**Univers MCP**](https://arxiv.org/abs/2508.14704) (2025) utilise 11 serveurs MCP sur des sujets variés du monde réel (navigation IRL, conception 3D, recherche sur le Web, etc.). Ce qui est cool dans celui-ci, c'est que l'évaluation repose sur plusieurs évaluateurs stricts, un pour l'exactitude du format, et deux pour l'exactitude des réponses : comme les tâches peuvent être statiques (demander des choses qui ne changent pas) ou dynamiques (étoiles github dans un dépôt, météo, ...), dans ce dernier cas, l'exactitude des réponses utilise un cadre d'évaluation basé sur l'exécution dépendante de la tâche qui récupère automatiquement la dernière réponse correcte de la source pertinente et compare la sortie du modèle à celle-ci. C'est beaucoup plus chouette que de compter sur un *LLM-as-a-judge* ! | |
| [**LiveMCPBench**](https://arxiv.org/abs/2508.01780) (2025) fournit une vaste collection de serveurs MCP déployables localement pour tester la capacité des modèles à distinguer les outils pour accomplir des tâches. Les meilleurs modèles atteignent déjà 80 % et sommes donc proches de la saturation. Cependant, tester si les modèles peuvent sélectionner les outils appropriés dans de très longues listes est un bon cas d'utilisation qui sera de plus en plus important à mesure que le Web deviendra un MCP. | |
| """, unsafe_allow_html=True) | |
| st.info("""Voici un [doc](https://www.anthropic.com/engineering/writing-tools-for-agents) sympa sur la façon d'écrire de bons outils.""") | |
| st.markdown(""" | |
| Alors que le test des capacités individuelles fournit un signal précieux, les performances réelles des assistants proviennent de la façon dont ces capacités se combinent. Un modèle peut exceller dans le raisonnement, mais échouer lorsque ce raisonnement doit être intégré simultanément à l'appel d'outils et à la gestion de long contexte, de sorte que nous avons besoin d'évaluations nécessitant l'orchestration de plusieurs capacités ensemble. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Tâches pour un assistant | |
| Je crois que les **tâches pour un assistant** vont être l'un des principaux moyens de faire des évaluations de niveau supérieur : les résoudre nécessite une combinaison de nombreuses capacités (long contexte, raisonnement, appel d'outils, ...), tandis que les benchmarks eux-mêmes fournissent un aperçu des performances de domaines spécifiques dans une configuration utile du monde réel. Ils ont également tendance à être plus compréhensibles (par le grand public) que les benchmarks de capacités spécifiques. Si les benchmarks sont suffisamment généraux, ils ne vérifient pas quels outils précis ont été utilisés, mais plutôt si le résultat final est correct, car les tâches complexes permettent plusieurs chemins vers le succès. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Récupération d'informations dans la vie réelle | |
| [**GAIA**](https://arxiv.org/abs/2311.12983) (2023) a donné le coup d'envoi de l'évaluation agentique moderne en exigeant des modèles qu'ils utilisent une combinaison d'outils, de raisonnement et de récupération pour résoudre des requêtes de la vie réelle (incluant parfois des documents). Les questions ont été divisées en 3 niveaux, le premier maintenant saturé et le troisième toujours difficile pour les modèles. C'est aussi l'un de ces benchmarks où les chiffres sont répartis en fonction des méthodes d'évaluation, car les gens font soit des évaluations sur l'ensemble de validation public, soit via des *LLM-as-a-judge* pour évaluer par rapport à l'ensemble de tests privés (lorsqu'il existe un classement public [ici](https://huggingface.co/spaces/gaia-benchmark/leaderboard)). | |
| Il a ensuite été répliqué dans [BrowseComp](https://cdn.openai.com/pdf/5e10f4ab-d6f7-442e-9508-59515c65e35d/browsecomp.pdf) (2025) qui teste la même chose (un modèle peut-il trouver la réponse adéquate à une requête spécifique à l'aide d'outils et d'informations en ligne) mais ne garantit pas l'unicité du résultat, car les questions ont été construites en partant du résultat et en construisant une question à partir de celui-ci, avec différents niveaux de difficulté : par exemple, à partir d'un article spécifique à récupérer, une question sera créée en combinant des informations sur les métadonnées du style « quel article sur le sujet a été publié à la conférence avec un auteur de nationalité et deux personnes de l'entité ? ». Le benchmark est probablement un des plus difficile à l'heure actuelle. | |
| Enfin, [GAIA2](https://huggingface.co/blog/gaia2) est allé au-delà de la simple recherche d'informations, en utilisant une maquette d'environnement mobile pour tester comment les assistants sont capables de répondre correctement aux requêtes en s'appuyant sur des chaînes d'événements et des appels d'outils. À l'heure actuelle, les sous-ensembles sensibles au temps et délibérément bruyants (simulant des appels API défaillants) sont les plus difficiles pour les modèles, lorsque la recherche et l'exécution semblent extrêmement faciles pour les modèles SOTA. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Assistants pour le domaine scientifique | |
| [SciCode](https://arxiv.org/abs/2407.13168) (2024) teste si les modèles peuvent résoudre des problèmes scientifiques réels en écrivant un code approprié, dans tous les domaines des STIM (de la biologie aux mathématiques/chimie/...). Les problèmes sont tirés de *workflow* réels, et chaque problème central est décomposé en sous-problèmes plus faciles. Pour la première version, l'évaluation a été faite par des scientifiques et un *LLM-as-a-judge*. Les modèles étaient plutôt mauvais lors de la publication (moins de 5 % de scores) mais je ne sais pas où l'on peut trouver des résultats à jour. | |
| [PaperBench](https://arxiv.org/abs/2504.01848) (2025) teste de la même manière si les modèles peuvent reproduire la recherche en ML, mais cette fois avec une configuration plus difficile. Etant donné des papiers de haute qualité (publiés à ICML), les modèles doivent reconstruire la base de code correspondante (8K tâches notées individuellement ont été fournies par les auteurs desdits articles, regroupées sous forme d'arbres de rubriques avec pondération pour les notes finales). Ce benchmark est évalué par un *LLM-as-a-judge* (bien que je soupçonne qu'une partie pourrait être faite automatiquement en contraignant un peu la forme du code demandé). | |
| [DSBench](https://arxiv.org/pdf/2409.07703) (2025) est un benchmark d'analyse de données multimodales utilisant des échantillons Kaggle et ModelOff (données financières). D'après les exemples de l'annexe, il semble que les questions de ModelOff soient fournies dans une configuration à choix multiples, ce qui facilite probablement la tâche, où les tâches Kaggle ont chacune leur propre métrique. | |
| [**DABStep**](https://arxiv.org/abs/2506.23719) (2025) évalue le modèle sur des *workflows* d'analyse de données opérationnelles auparavant privées (donc non contaminées) à l'aide de questions et de données réelles. Tous les problèmes nécessitent un raisonnement en plusieurs étapes et une analyse variée des documents, ainsi que bien sûr des compétences spécifiques en manipulation de données. C'est une évaluation intéressante parce qu'elle est difficile et qu'elle reproduit des cas d'utilisation réels utiles en pratique, et parce que chaque problème a une vérité de terrain, de sorte que l'évaluation est impartiale et pas trop coûteuse. | |
| Ces types de tâches testent les fonctionnalités intégrées dans des scénarios réalistes, mais elles sont soit dynamiques et en lecture seule, soit statiques dans un environnement qui ne change pas. Pour évaluer l'adaptabilité et la prise de décision dynamique, nous avons besoin d'environnements qui peuvent « surprendre » le modèle. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Évaluations basées sur un jeu | |
| Les benchmarks basés sur un jeu sont très intéressants pour plusieurs raisons : ils évaluent généralement l'adaptabilité à un environnement changeant (contrairement à la plupart des tâches d'assistant qui sont statiques), nécessitent un long raisonnement contextuel, et enfin et surtout, sont **compréhensibles** par la plupart des gens. Cependant, ils ne sont pas fondés sur la vie réelle ni ne reflètent nécessairement de bonnes performances sur des cas d'utilisation réellement utiles. | |
| L'évaluation formelle la plus célèbre parmi celles-ci est probablement [ARC-AGI](https://arcprize.org/arc-agi). La première version (2019) était composée de grilles de puzzles dans une séquence, où les modèles devaient trouver le dernier élément de ladite séquence sans que des règles explicites ne soient fournies. Ce benchmark me rappelle beaucoup les tests de QI orientés logique, et il a presque été résolu en 2024. Un benchmark similaire (extrapolation des règles) est [Baba is AI](https://arxiv.org/abs/2407.13729) (2024). La dernière version du benchmark, ARC-AGI3 (2025, en cours), est toujours en développement, et contient de tout nouveaux jeux (nécessitant de l'exploration, une planification complexe, une gestion de la mémoire, ...). Il est toujours en cours, et les meilleures solutions actuelles aux problèmes disponibles sont des approches bourrines. | |
| La communauté et les fournisseurs de modèles ont exploré un certain nombre de jeux existants avec des LLM. Les jeux d'aventure/RPG solo comme [TextQuests](https://huggingface.co/blog/textquests) (2025) ou [Pokemon](https://github.com/benchflow-ai/benchflow/tree/main/libs/pokemon-gym) (2024) (Twitch pour [Claude](https://www.twitch.tv/claudeplayspokemon) et [Gemini](https://www.twitch.tv/gemini_plays_pokemon) par exemple) nécessitent une combinaison de planification à très long terme pour atteindre des objectifs, qui nécessitent des capacités adéquates de gestion de la mémoire de contexte long, de raisonnement et de retour en arrière. Les mêmes capacités sont nécessaires pour les jeux de survie solo comme [Crafter](https://arxiv.org/abs/2109.06780) (2021, inspiré de Minecraft). Un certain nombre d'environnements de jeu solo ont été intégrés dans le benchmark [Balrog](https://arxiv.org/pdf/2411.13543) (2024). | |
| Les jeux de bluff compétitifs comme le [Poker](https://arxiv.org/html/2501.08328v1) (2025) ou les variantes de Mafia comme [Town of Salem](https://github.com/summersonnn/Town-Of-Salem-with-LLMs) (2025) et Werewolf (2025, [ici](https://arxiv.org/abs/2407.13943)/[là](https://werewolf.foaster.ai/)) sont très intéressants pour tester la logique, le raisonnement, ainsi que les capacités de tromperie. Claude Opus 4 est par exemple incapable de gagner la ville de Salem en tant que vampire (rôle trompeur) mais s'en sort bien en tant que paysan (rôle non trompeur). Les jeux coopératifs comme le Hanabi peuvent également être utilisés pour tester l'adaptabilité et la capacité de communication dans un environnement contraint. | |
| Ce qui est également très intéressant, c'est qu'ils ont une seule métrique de réussite/échec sans ambiguïté : le LLM a-t-il gagné le match ou non ? À l'heure actuelle, si je devais les utiliser pour évaluer des modèles, je regarderais probablement TextQuests pour les capacités et Town of Salem pour la sécurité. | |
| Au-delà des capacités de test dans des environnements contrôlés, il existe un type d'évaluation qui est intrinsèquement impossible à déjouer : prédire l'avenir. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### La prévision | |
| L'année dernière, une nouvelle catégorie de tâches impossibles à contaminer a émergé : la prévision. | |
| Je suppose que techniquement, les prévisions sur les marchés boursiers peuvent être trompées par une certaine manipulation, mais j'espère que nous n'en sommes pas encore là en termes d'incitations financières à gâcher les évaluations. | |
| Ils devraient nécessiter une combinaison de raisonnements entre les sources pour essayer de résoudre des questions sur des événements qui ne se sont pas encore produits, mais il n'est pas certain que ces benchmarks soient suffisamment discriminants pour avoir une forte valeur, et ils renforcent probablement l'ambiance de « succès de la machine à sous » des LLM. (La performance de certains événements est-elle proche de l'aléatoire parce qu'ils sont impossibles à prédire ou parce que les modèles sont mauvais dans ce domaine ? Dans l'autre sens, si les modèles sont capables de prédire correctement l'événement, la question est-elle trop facile ou trop conventionnelle ?) | |
| [FutureBench](https://huggingface.co/blog/futurebench) teste si les modèles peuvent prédire des événements futurs dignes d'intérêt. Il utilise 2 sources : la navigation et un LLM générant des questions avec un horizon temporel hebdomadaire, et les prédictions des utilisateurs des marchés de paris. Toutes les données sont fortement filtrées et nettoyées avant d'être utilisées. Pour l'instant, les modèles sont à peine meilleurs que le hasard sur les paris créés par l'homme, et réussissent 3/4 du temps sur les questions générées par le modèle (probablement plus facile). | |
| [FutureX](https://arxiv.org/abs/2508.11987) est similaire, mais utilise un éventail de sites Web spécifiques (parcs de prédiction, sites Web gouvernementaux, sites Web de classement général et plateformes de données en temps réel), puis utilise des modèles pour générer des questions sur des événements futurs potentiels (« quand STOCK atteindra-t-il POINT ? »). 500 questions sont générées chaque jour, avec filtrage des questions accidentellement non pertinentes. | |
| Une approche similaire est utilisée pour générer des questions dans [Arbitrage](https://arxiv.org/pdf/2412.18544), la différence fondamentale étant l'horizon temporel : les événements devraient être résolus en 2028. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Obtenir des modèles réellement utiles grâce à l'évaluation | |
| Le paysage de l'évaluation a évolué au gré des sauts de capacités, de la mise à l'essai de compétences isolées à la mesure de la performance intégrée dans des scénarios plus réalistes. | |
| À partir de septembre 2025, je recommande d'utiliser : | |
| - **Capacités de base** (pour les créateurs de modèles) : Anciennes évaluations de capacités pour l'entraînement et pour le post-entraînement comme MATH500/AIME24, GPQA, IFEval, SWE-Bench, une évaluation longue portée de votre choix comme HELMET, TauBench ou BFCL si vous ciblez l'utilisation d'outils | |
| - **Capacités de base** (pour comparer les modèles à l'inférence) : IFBench, HLE, MathArena, AiderBench et LiveCodeBench, MCP-Universe | |
| - **Tâches à long terme** (pour des performances réelles) : GAIA, DABStep, SciCode, ou évaluations spécifiques à un domaine pour vos cas d'utilisation | |
| - **Jeux** (pour un peu plus de plaisir à mesurer la robustesse et l'adaptabilité) : ARC-AGI3 quand il est sorti, TextQuests, Town of Salem si vous êtes intéressé par la sécurité, ou tout autre jeu que vous aimez qui va au-delà du Poker/Chess/Go. | |
| Le domaine s'oriente vers des évaluations qui testent l'orchestration des capacités plutôt que des compétences isolées pour une utilisation réelle. Cela correspond à notre objectif de créer des modèles qui « fonctionnent bien », c'est-à-dire des systèmes capables de combiner de manière fiable les capacités de base, l'utilisation d'outils et une bonne orchestration pour résoudre des problèmes réels. | |
| """, unsafe_allow_html=True) | |
| st.info(""" | |
| A titre personnel, j'espère que le domaine mettra davantage l'accent sur les tests fonctionnels plutôt que sur les *LLM-as-a-judge*, et sur des jeux de données et tâches généralement compréhensibles. | |
| """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| col1, col2, col3= st.columns(3) | |
| with col1: | |
| if st.button('Section précédente', use_container_width=True): | |
| switch_page("Panorama 2024") | |
| with col2: | |
| if st.button("Accueil", use_container_width=True): | |
| switch_page("Home") |