Upload 5 files

Add recent Clementine updates

pages/25_RESSOURCES.py

@@ -104,4 +104,7 @@ with col1:
         switch_page("Notebook")
 with col2:
     if st.button("Accueil", use_container_width=True):
-        switch_page("Home")
+        switch_page("Home")
+with col3:
+    if st.button("Section suivante", use_container_width=True):
+        switch_page("Panoramas annuels")

pages/26_PANORAMAS_ANNUELS.py

@@ -0,0 +1,23 @@
+import streamlit as st
+st.set_page_config(layout="wide")
+from streamlit_extras.switch_page_button import switch_page
+
+st.markdown("""## Panoramas annuels""")
+st.markdown(""" """)
+
+st.markdown("""
+Chaque année, Clémentine réalise un panorama des ressources intéressantes apparues lors de l'année qu'il ne fallait pas louper. Cette section les récapitulent tous.""")
+
+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("Ressources")
+with col2:
+    if st.button("Accueil", use_container_width=True):
+        switch_page("Home")
+with col3:
+    if st.button("Section suivante", use_container_width=True):
+        switch_page("Panorama 2023")

pages/27_Panorama_2023.py

@@ -0,0 +1,229 @@
+import streamlit as st
+st.set_page_config(layout="wide")
+from streamlit_extras.switch_page_button import switch_page
+
+st.markdown("""# Panorama 2023""")
+st.markdown(""" """)
+
+st.markdown("""        
+## 2023, année des LLM ouverts
+
+L'année 2023 a vu un regain d'intérêt du public pour les grands modèles de langage (LLM), et maintenant que la plupart des gens savent ce qu'ils sont et peuvent faire, les débats publics autour de l'*open source* vs *closed source* ont également atteint un large public. Chez Hugging Face, nous suivons les modèles ouverts avec beaucoup d'intérêt, car ils permettent à la recherche d'être reproductible, à la communauté de participer au développement de modèles d'IA, d'examiner plus facilement les biais et les limites des modèles, et réduisent l'impact carbone global de notre domaine en favorisant la réutilisation des points de contrôle (parmi [de nombreux autres avantages](https://huggingface.co/papers/2302.04844)). 
+
+Alors faisons une rétrospective des LLM ouverts de cet année ! 
+
+Notez, que pour que ce document reste gérable, nous n'examinerons pas les modèles de code.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### 🍜 Recette pour un LLM pré-entraîné
+
+Tout d'abord, comment obtenons-nous un grand modèle de langage ? (N'hésitez pas à sauter cette section si vous le savez déjà !)
+
+L'**architecture** du modèle (son code) décrit son implémentation spécifique et sa forme mathématique : il s'agit d'une liste de tous ses paramètres, ainsi que de la façon dont ils interagissent avec les entrées. À l'heure actuelle, les LLM les plus performants sont des variations de l'architecture Transformer « décodeur uniquement » (plus de détails dans le [papier original des *transformers*](https://huggingface.co/papers/1706.03762)). 
+
+Le **jeu de données d'entraînement** contient tous les exemples et documents sur lesquels le modèle est entraîné (c'est-à-dire sur lesquels les paramètres sont appris), et donc les motifs spécifiques appris. La plupart du temps, ces documents contiennent du texte, soit en langage naturel (ex : français, anglais, chinois), soit en langage de programmation (ex : Python, C), soit en tout type de données structurées exprimables sous forme de texte (ex : tableaux en markdown ou latex, équations, ...). 
+
+Un ***tokenizer*** définit comment le texte du jeu de données d'entraînement est converti en nombres (car un modèle est une fonction mathématique et a donc besoin de nombres comme entrées). La tokenisation se fait en transformant le texte en sous-unités appelées *tokens* (qui peuvent être des mots, des sous-mots ou des caractères, selon les méthodes de tokenisation). La taille du vocabulaire du *tokenizer* indique le nombre de *tokens* différents qu'il connaît, généralement entre 32k et 200k. La taille d'un jeu de données est souvent mesurée comme le **nombre de *tokens*** qu'il contient une fois divisé en une séquence de ces unités individuelles « atomistiques ». Ces jours-ci les modèles vont de plusieurs centaines de milliards de *tokens* à plusieurs billions de *tokens* !
+
+Les **hyperparamètres d'entraînement** définissent ensuite comment le modèle est entraîné. Dans quelle mesure les paramètres doivent-ils changer pour s'adapter à chaque nouvel exemple ? À quelle vitesse le modèle doit-il être mis à jour ?
+
+Une fois ces paramètres sélectionnés, vous n'avez besoin que de 1) beaucoup de puissance de calcul pour entraîner le modèle et 2) de personnes compétentes (et gentilles) pour exécuter et surveiller l'entraînement. L'entraînement lui-même consistera à instancier l'architecture (création des matrices sur le matériel utilisé pour l'entraînement) et à exécuter l'algorithme d'entraînement sur le jeu de données d'entraînement avec les hyperparamètres mentionnés ci-dessus. Le résultat est un ensemble de **poids**. Il s'agit des paramètres du modèle après l'apprentissage et de ce que la plupart des gens entendent lorsqu'ils discutent de l'accès à un modèle pré-entraîné ouvert. Ces poids peuvent ensuite être utilisés pour l'inférence, c'est-à-dire pour la prédiction sur de nouvelles entrées, par exemple pour générer du texte.
+
+Les LLM pré-entraînés peuvent également être spécialisés ou adaptés à une tâche spécifique après le pré-entraînement, en particulier lorsque les poids sont ouvertement relâchés. Ils sont ensuite utilisés comme point de départ pour des cas d'utilisation et des applications grâce à un processus appelé **finetuning**. Le finetuning consiste à appliquer des étapes d'entraînement supplémentaires sur le modèle sur un jeu de données différent, souvent plus spécialisé et plus petit, afin de l'optimiser pour une application spécifique. Même si cette étape a un coût en termes de puissance de calcul nécessaire, elle est généralement beaucoup moins coûteuse que l'entraînement d'un modèle à partir de zéro, tant sur le plan financier qu'environnemental. C'est l'une des raisons pour lesquelles les modèles pré-entraînés open-source de haute qualité sont très intéressants, car ils peuvent être librement utilisés et développés par la communauté, même lorsque les praticiens n'ont accès qu'à un budget informatique limité. 
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### 🗝️ 2022, d'une course à la taille à une course aux données
+Quels modèles ouverts étaient disponibles pour la communauté avant 2023 ?
+
+Jusqu'au début de l'année 2022, la tendance de l'apprentissage automatique était que plus un modèle était grand (c'est-à-dire qu'il avait de paramètres), meilleures étaient ses performances. En particulier, il semble que les modèles dépassant des seuils de taille spécifiques font alors un bond en capacités, deux concepts qui ont été surnommés « capacités émergentes » et « lois d'échelle ». Les familles de modèles open source pré-entraînés publiées en 2022 ont principalement suivi ce paradigme. 
+
+1. [BLOOM](https://huggingface.co/papers/2211.05100) (*BigScience Large Open-science Open-access Multilingual Language Model*) 
+BLOOM est une famille de [modèles](https://huggingface.co/bigscience/bloom) publiée par BigScience, un effort collaboratif comprenant 1000 chercheurs de 60 pays et 250 institutions, coordonné par Hugging Face, en collaboration avec les organisations françaises GENCI et IDRIS. Ces modèles utilisent un *transformer* décodeur, avec des modifications mineures (normalisation post-embedding pour rendre l'apprentissage plus stable et utilisation d'embeddings positionnels ALiBi qui introduisent une pénalité lorsque des *tokens* trop éloignés dans une séquence sont connectés ensemble). Le plus grand modèle de cette famille est un modèle de 176 milliards de paramètres, entraîné sur 350 milliards de *tokens* de données multilingues dans 46 langues humaines et 13 langages de programmation. La plupart des données d'entraînement ont été publiées, et les détails de leurs sources, de leur conservation et de leur traitement ont été publiés. Il s'agit du plus grand modèle open source massivement multilingue à ce jour.
+
+2. [OPT](https://huggingface.co/papers/2205.01068) (*Open Pre-trained Transformer*)
+La famille des modèles [OPT](https://huggingface.co/facebook/opt-66b) a été lancée par Meta. Ces modèles utilisent une architecture de *transformer* décodeur, suivant les astuces du papier de GPT-3 (initialisation de poids spécifiques, pré-normalisation), avec quelques modifications du mécanisme d'attention (alternance de couches d'attention denses et localement bandées). Le plus grand modèle de cette famille est un modèle de paramètres 175B entraîné sur 180 milliards de *tokens* de données provenant principalement de sources publiques (livres, données sociales via Reddit, actualités, Wikipédia et autres sources Internet diverses). Cette famille de modèles avait des performances comparables à celles des modèles GPT-3, en utilisant des optimisations pour la rendre moins gourmande en calcul.
+
+3. [GLM-130B](https://huggingface.co/papers/2210.02414) (*General Language Model*)
+[GLM-130B](https://huggingface.co/THUDM/glm-roberta-large) a été publié par l'Université Tsinghua et Zhipu.AI. Il utilise un transformer complet avec quelques modifications (post-normalisation de couche avec DeepNorm, embeddings rotatifs). Le modèle de paramètres 130B a été entraîné sur 400 milliards de *tokens* de données Internet en anglais et en chinois (The Pile, Wudao Corpora, et d'autres corpus chinois). Il a également des performances comparables à celles des modèles GPT-3.
+
+4. LLM ouverts plus petits ou plus spécialisés
+Des modèles open-source plus petits ont également été publiés, principalement à des fins de recherche : Meta a publié la série [Galactica](https://huggingface.co/papers/2211.09085), LLM  allant jusqu'à [120B](https://huggingface.co/facebook/galactica-120b) de paramètres, pré-entraînée sur 106B de *tokens* de littérature scientifique, et EleutherAI a publié le modèle [GPT-NeoX-20B](https://huggingface.co/EleutherAI/gpt-neox-20b), un *transformer* décodeur entièrement open source (architecture, poids, données incluses) entraîné sur 500B de *tokens* (en utilisant RoPE et quelques modifications de l'attention et de l'initialisation), pour fournir un artefact complet pour les investigations scientifiques.
+
+Ces énormes modèles étaient passionnants mais aussi très coûteux à faire fonctionner ! Lors de l'exécution d'une inférence (calcul des prédictions à partir d'un modèle), le modèle doit être chargé en mémoire, mais un modèle de 100 B de paramètres nécessitera généralement 220 Go de mémoire pour être chargé (nous expliquons ce processus ci-dessous), ce qui est très volumineux et n'est pas accessible à la plupart des organisations et des praticiens !
+
+Cependant, en mars 2022, un [nouvel article](https://huggingface.co/papers/2203.15556) de DeepMind est sorti, étudiant quel est le rapport optimal entre les *tokens* et les paramètres du modèle pour un budget de calcul donné. En d'autres termes, si vous n'avez qu'un montant X à dépenser pour l'entraînement du modèle, quelles doivent être les tailles respectives du modèle et des données ? Les auteurs ont découvert que, dans l'ensemble, pour le budget de calcul moyen consacré aux LLM, les modèles devraient être plus petits, mais entraînés sur beaucoup plus de données. Leur propre modèle, Chinchilla (non open source), était un modèle de paramètres de 70B (un tiers de la taille des modèles ci-dessus) mais entraîné sur 1,4T de *tokens* (entre 3 et 4 fois plus de données). Il avait des performances similaires ou supérieures à celles de ses homologues plus grands, à la fois open source et source fermée.
+
+Ce changement de paradigme, bien que probablement déjà connu dans les laboratoires fermés, a pris d'assaut la communauté de la science ouverte.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### 🌊 2023, une année de sorties ouvertes
+
+#### L'essor de plsu petits modèles de langage
+L'année 2023 a vu l'émergence d'une vague de *transformers* décodeur, avec de nouveaux modèles pré-entraînés sortis chaque mois, et bientôt chaque semaine voire chaque jour : LLaMA (par Meta) en février, StableLM (par StabilityAI) et Pythia (par Eleuther AI) en avril, MPT (par MosaicML) en mai, X-GEN (par Salesforce) et Falcon (par TIIUAE) en juin, Llama 2 (par Meta) en juillet,  StableLM v2 (par StabilityAI) en août, Qwen (par Alibaba) et Mistral (par Mistral.AI) en septembre, Yi (par 01-ai) en novembre, DeciLM (par Deci), Phi-2 et SOLAR (par Upstage) en décembre. 
+
+Toutes ces versions a) incluaient des poids de modèle (sous des licences plus ou moins ouvertes) et b) avaient de bonnes performances pour les modèles plus petits (entre 3B et 70B de paramètres), et donc, ils ont été instantanément adoptés par la communauté. Presque tous ces modèles utilisent l'architecture *transformer* décodeur, avec divers ajustements (ALiBi ou RoPE, pré-normalisation RMS, SwiGLU), ainsi que quelques modifications des fonctions d'attention (Flash-Attention, GQA, fenêtres coulissantes) et différentes implémentations de base de code pour optimiser la vitesse d'entraînement ou d'inférence. Ces ajustements sont susceptibles d'affecter les performances et la vitesse d'entraînement dans une certaine mesure. Cependant, comme toutes les architectures ont été publiées publiquement avec les poids, les principales différences qui subsistent sont les données d'entraînement et la licence des modèles.
+
+La première famille de modèles de cette série était la famille [LLaMA](https://huggingface.co/papers/2302.13971), publiée par Meta AI. L'objectif explicite des chercheurs était d'entraîner un ensemble de modèles de différentes tailles avec les meilleures performances possibles pour un budget de calcul donné. Pour l'une des premières fois, l'équipe de recherche a explicitement décidé de prendre en compte non seulement le budget d'entraînement, mais aussi le coût d'inférence (pour un objectif de performance donné, combien cela coûte-t-il d'exécuter une inférence avec le modèle). Dans cette perspective, ils ont décidé d'entraîner des modèles plus petits sur encore plus de données et pour plus d'étapes que ce qui était habituellement fait, atteignant ainsi des performances plus élevées à une taille de modèle plus petite (le compromis étant l'efficacité de calcul de l'entraînement). Le plus grand modèle de la famille Llama 1 est un modèle de paramètres 65B entraîné sur 1,4T de *tokens*, tandis que les modèles plus petits (paramètres 6 et 13B) ont été entraînés sur 1T de *tokens*. Le petit modèle 13B LLaMA a surpassé GPT-3 sur la plupart des benchmarks, et le plus grand modèle LLaMA était à la pointe de la technologie lors de sa sortie. Les poids ont cependant été publiés avec une licence non commerciale, limitant ainsi l'adoption par la communauté. 
+
+Les modèles [Pythia](https://huggingface.co/papers/2304.01373) ont été publiés par le laboratoire open source à but non lucratif Eleuther AI, et étaient une [suite de LLM](https://huggingface.co/collections/EleutherAI/pythia-scaling-suite-64fb5dfa8c21ebb3db7ad2e1) de différentes tailles, entraînés sur des données entièrement publiques, fournis pour aider les chercheurs à comprendre les différentes étapes d'entraînement de LLM.
+
+Les [modèles MPT](https://www.mosaicml.com/blog/mpt-7b), qui sont sortis quelques mois plus tard, publiés par MosaicML, étaient proches en termes de performances, mais avec une licence permettant une utilisation commerciale, et les détails de leur combinaison d'entraînement. Le premier modèle MPT était un [modèle 7B](https://huggingface.co/mosaicml/mpt-7b), suivi par des versions 30B en juin, toutes deux entraînées sur 1T de *tokens* d'anglais et du code (en utilisant des données de C4, CommonCrawl, The Stack, S2ORC). 
+
+Les modèles MPT ont été rapidement suivis par les modèles 7 et 30B (https://huggingface.co/tiiuae/falcon-7b) de la série Falcon (https://huggingface.co/collections/tiiuae/falcon-64fb432660017eeec9837b5a), publiés par TIIUAE, et entraînés sur 1 à 1,5T de *tokens* d'anglais et de code (RefinedWeb, Project Gutemberg, Reddit, StackOverflow, Github, arXiv, Wikipedia, entre autres sources) - plus tard dans l'année, un gigantesque modèle 180B a également été publié. Les modèles, les données et le processus d'entraînement de Falcon ont été détaillés dans un rapport technique et un [papier de recherche ultérieur](https://huggingface.co/papers/2311.16867). 
+
+Héritant du modèle GPT-Neo-X, StabilityAI a publié les modèles [StableLM-Base-Alpha](https://huggingface.co/stabilityai/stablelm-base-alpha-7b), une petite série pré-entraînée (3B et 7B) utilisant 1,5T de *tokens* d'un jeu de données expérimental construit sur ThePile. Suivie d'une [série v2](https://huggingface.co/stabilityai/stablelm-base-alpha-7b-v2) avec un mélange de données comprenant RefinedWeb, RedPajama, ThePile, et des jeux de données internes non divulgués, et enfin par un très petit modèle 3B, le [StableLM-3B-4E1T](https://huggingface.co/stabilityai/stablelm-3b-4e1t), accompagné d'un [rapport technique détaillé](https://stability.wandb.io/stability-llm/stable-lm/reports/StableLM-3B-4E1T--VmlldzoyMjU4?accessToken=u3zujipenkx5g7rtcj9qojjgxpconyjktjkli2po09nffrffdhhchq045vp0wyfo).
+
+Alors que les données des modèles précédents étaient principalement publiques, à partir de ce moment-là, les versions suivantes n'ont donné pratiquement aucune information sur ce qui a été utilisé pour entraîner les modèles, et leurs efforts ne peuvent pas être reproduits. Cependant, ils fournissent des points de départ pour la communauté grâce aux poids publiés.
+
+Au début de l'été sont arrivés les [modèles](https://huggingface.co/Salesforce/xgen-7b-4k-base) [X-Gen](https://huggingface.co/papers/2309.03450) de Salesforce, des modèles de 7B paramètres entraînés sur 1,5T *tokens* de langage naturel et de code, en plusieurs étapes, suivant un système d'ordonnancement des données (toutes les données ne sont pas introduites en même temps dans le modèle). 
+
+X-Gen a été un peu éclipsé par la nouvelle famille très visible [LLaMA-2](https://huggingface.co/papers/2307.09288) de Meta, une gamme de [modèles de 7 à 70B](https://huggingface.co/meta-llama/Llama-2-7b) entraînés sur 2T de *tokens* « provenant de sources accessibles au public », avec une licence communautaire permissive et un processus de finetuning basé sur des préférences humaines (RLHF), ce qu'on appelle la procédure d'alignement.
+
+Quelques mois plus tard, le premier [modèle](https://huggingface.co/mistralai/Mistral-7B-v0.1) de la startup Mistral nouvellement créée, [Mistral-7B](https://huggingface.co/papers/2310.06825) a été lancé, entraîné sur un nombre non divulgué de *tokens* à partir de données « extraites du Web ouvert ». La fin de l'année 2023 a été chargée par les sorties de modèles avec un deuxième modèle plus grand par Mistral (Mixtral 8x7B), un premier [modèle](https://huggingface.co/Deci/DeciLM-7B) impressionnant de Deci.AI appelé [DeciLM](https://deci.ai/blog/introducing-DeciLM-7B-the-fastest-and-most-accurate-7b-large-language-model-to-date) ainsi qu'une plus grande fusion de modèles d'upstage, [SOLAR](https://huggingface.co/upstage/SOLAR-10.7B-v1.0) également entraînés sur des quantités et des sources de données non divulguées. Tous ces modèles ont connu des augmentations constantes dans les classements et les benchmarks ouverts.
+
+En parallèle, un événement notable de la fin de l'année 2023 a été l'augmentation des performances et un certain nombre de modèles entraînés en Chine et publiés ouvertement. Deux séries de modèles bilingues anglais-chinois ont été lancées : [Qwen](https://huggingface.co/papers/2309.16609) d'Alibaba, [modèles](https://huggingface.co/Qwen/Qwen-72B) de 7 à 70B de paramètres entraînés sur 2,4T *tokens*, et [Yi](https://huggingface.co/01-ai/Yi-34B) de 01-AI, modèles de 6 à 34B de paramètres, entraînés sur 3T de *tokens*. Les performances de ces modèles avaient une longueur d'avance sur les modèles précédents, à la fois sur les classements ouverts comme l'[*Open LLM leaderboard*](https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard) et certains des benchmarks les plus difficiles comme [Skill-Mix](https://huggingface.co/papers/2310.17567). Un autre concurrent sérieux de la fin de 2023 était le modèle de codage DeepSeek de [DeepSeek AI](https://huggingface.co/deepseek-ai) entraîné à partir de zéro sur 2T de *tokens*, avec une composition de 87 % de code et de 13 % de langage naturel en anglais et en chinois (principalement un modèle de code). 
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### Des modèles de dialogue partout
+
+Par rapport à 2022, presque tous les modèles pré-entraînés sortis en 2023 sont à présent livrés avec une version pré-entraînée et une version finetunée pour dialoguer via l'une des nombreuses approches existantes. Alors que des approches de finetuning pour chatter ont été développées en 2022 et avant, l'adoption généralisée de ces techniques a réellement décollé en 2023, mettant l'accent sur l'utilisation croissante de ces modèles de chat par le grand public ainsi que sur l'évaluation manuelle croissante des modèles en discutant avec eux (évaluation « *vibe-check* »). Nous détaillons ici les approches les plus connues pour adapter des modèles pré-entraînés au chat, mais de nombreuses variantes existent !
+
+Le **chat-finetuning** est une variante du finetuning supervisé, où les données annotées sont des données de chat (données de type dialogue à plusieurs tours, un peu comme ce que vous trouveriez sur les réseaux sociaux). Vous utilisez la même technique que lors de l'entraînement de votre modèle : pour les *transformers* décodeur, vous apprenez à votre modèle à prédire les mots suivants un par un (approche auto-régressive). 
+
+L'IFT (**Instruction fine-tuning** suit la même approche, mais avec des jeux de données d'instructions, qui contiennent une collection de prompts de type requête et des réponses (avec des entrées supplémentaires facultatives si nécessaire). Ces jeux de données enseignent aux modèles comment suivre une instruction et peuvent être générés par l'homme ou par LLM. 
+ L'utilisation de jeux de données synthétiques à grande échelle (jeux de données composés de générations de modèles, par exemple, des générations de GPT-4 à partir d'instructions ou d'interactions entre les utilisateurs et ledit modèle) est l'un des moyens d'effectuer un finetuning d'instructions et de chat. C'est ce qu'on appelle souvent la « distillation », car elle consiste à prendre les connaissances d'un modèle très performant pour entraîner un modèle plus petit.
+
+Ces deux méthodes sont relativement faciles à mettre en œuvre : il vous suffit de trouver ou de générer des jeux de données associés, puis de finetuner votre modèle en utilisant la même technique que lors de l'entraînement. Un grand nombre de jeux de données instruct ont été publiés l'année dernière, ce qui a amélioré les performances du modèle dans des configurations de type dialogue. Pour plus d'informations sur ce sujet, vous pouvez lire cet [article de blog](https://huggingface.co/blog/dialog-agents). Cependant, les modèles, bien que meilleurs, ne peuvent toujours pas correspondre à ce que les humains attendent. 
+ 
+L'apprentissage par renforcement à partir de la rétroaction humaine (**Reinforcement learning from human feedback** ou RLHF) est une approche spécifique qui vise à aligner ce que le modèle prédit sur ce que les humains préfèrent (en fonction de critères spécifiques). Il s'agissait (au début de l'année) d'une nouvelle technique. À partir d'une instruction donnée, le modèle génère plusieurs réponses possibles. Les humains classent ces réponses. Les classements sont utilisés pour entraîner ce qu'on appelle un modèle de préférence (qui apprend à donner un score reflétant la préférence humaine pour les réponses). Le modèle de préférence est ensuite utilisé pour finetuner le modèle de langage à l'aide de l'apprentissage par renforcement. Pour plus d'informations, voir cet [article de blog](https://huggingface.co/blog/rlhf), l'[article original du RLHF](https://huggingface.co/papers/1909.08593), ou l'article d'Anthropic sur [RLHF](https://huggingface.co/papers/2204.05862). Il s'agit d'une méthode coûteuse (l'annotation/classement + l'entraînement d'un nouveau modèle + la mise au point sont assez coûteuses) qui a été principalement utilisée pour aligner les modèles sur des objectifs de sécurité. Une variante moins coûteuse de cette méthode a été développée, qui utilise un LLM de haute qualité pour classer les résultats du modèle plutôt que les humains : **apprentissage par renforcement à partir de la rétroaction de l'IA** (RLAIF). 
+
+L'optimisation directe des préférences (**Direct preference optimization** ou DPO) est une autre variante de RLHF, mais ne nécessite pas l'entraînement et l'utilisation d'un modèle de préférence distinct. La méthode nécessite le même jeu de données de classement humain ou IA, mais utilise ces données pour mettre à jour le modèle directement en examinant la différence entre sa politique d'origine (méthode de prédiction) et la politique optimale (qui prédirait les réponses les mieux classées). En d'autres termes, le modèle aligné est aussi le modèle de préférence, ce qui simplifie considérablement la procédure d'optimisation tout en donnant ce qui semble être des performances finales équivalentes.
+
+Donc, pour revenir à notre vague de modèles à poids ouvert de sociétés (principalement) privées, beaucoup d'entre eux ont été publiés avec leur variantes finetunées : MPT-7B est également venu avec une version instruct et une version chat, des versions instruct-tuned des modèles Falcon et XGen ont été lancées à la fin de l'année, Llama-2, Qwen et Yi ont été sortis avec des versions chat et DeciLM avec une version instruct. La sortie de Llama-2 a été particulièrement remarquable en raison de l'accent mis sur la sécurité, à la fois dans les modèles de pré-entraînement et de finetuning. 
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### Qu'en est-il de la communauté ?
+Alors que les modèles de chat et les modèles d'instructions étaient généralement fournis directement avec les nouvelles versions de modèles, la communauté et les chercheurs n'ont pas pris cela pour acquis. Une communauté large et saine de perfectionneurs de modèles s'est épanouie sur les terrains fructueux fournis par ces modèles de base, avec des discussions ayant lieu spontanément sur Reddit, Discord, le Hub et Twitter. Les anoonces de modèles communautaires ont été fréquentes, parallèlement à la création de nouveaux jeux de données intéressants (également utilisés pour finetuner les modèles afin de déterminer leurs bonnes performances et leur qualité).
+
+Au début de l'année 2023, quelques jeux de données d'instructions/chats ont déjà été publiés. Par exemple, pour les préférences humaines, [WebGPT](https://huggingface.co/datasets/openai/webgpt_comparisons) d'OpenAI, [HH-RLHF](https://github.com/anthropics/hh-rlhf) d'Anthropic et [Summarize](https://huggingface.co/datasets/openai/summarize_from_feedback) d'OpenAI ont été pionniers dans cette direction. Des exemples de jeux d'instructions sont le [Public Pool of Prompts](https://huggingface.co/datasets/bigscience/P3) de BigScience, [FLAN](https://github.com/google-research/FLAN) 1 et 2 de Google, [Natural Instructions](https://github.com/allenai/natural-instructions) d'AllenAI, [Self Instruct](https://github.com/yizhongw/self-instruct), un cadre pour générer des instructions automatiques par des chercheurs de différentes affiliations, [SuperNatural instructions](https://aclanthology.org/2022.emnlp-main.340/), un benchmark d'instructions créé par des experts, parfois utilisé comme données de réglage fin, [Unnatural instructions](https://aclanthology.org/2023.acl-long.806.pdf), un jeu d'instructions généré automatiquement par l'Université de Tel Aviv et Meta, entre autres.
+
+❄️ Hiver 2022/2023 :  
+En janvier de cette année, le [Human ChatGPT Instruction corpus](https://huggingface.co/datasets/Hello-SimpleAI/HC3) (HC3) a été publié par des chercheurs chinois de diverses institutions, et contenait des réponses humaines par rapport à des modèles à diverses questions. Le mois de mars a été riche en sorties : Stanford a ouvert le modèle [Alpaca](https://github.com/tatsu-lab/stanford_alpaca), qui était le premier modèle LLaMA (7B) suivant des instructions, et le jeu de données associé, 52K instructions générées avec un LLM. LAION (un laboratoire open source à but non lucratif) a publié [Open Instruction Generalist](https://laion.ai/blog/oig-dataset/) (OIG), 43M instructions à la fois créées avec l'augmentation des données et compilées à partir d'autres sources de données préexistantes. Le même mois, LMSYS org (à l'UC Berkeley) a publié [Vicuna](https://lmsys.org/blog/2023-03-30-vicuna/), également une mise au point LLaMA (13B), cette fois sur les données de chat : conversations entre les utilisateurs et ChatGPT, partagées publiquement par les utilisateurs eux-mêmes sur [ShareGPT](https://share-gpt.com/). [Guanaco](https://huggingface.co/datasets/JosephusCheung/GuanacoDataset), une extension d'Alpaca (contenant 500K entrées supplémentaires dans plus de langues), a également été publié, ainsi que le finetuning de LLaMA-7B associé. 
+
+🌱 Printemps :  
+En avril, BAIR (Berkeley AI Research lab) a publié [Koala](https://bair.berkeley.edu/blog/2023/04/03/koala/), un modèle LLaMA utilisant plusieurs des jeux de données précédents (Alpaca, HH-RLHF, WebGPT, ShareGPT) et DataBricks a publié [Dolly](https://huggingface.co/datasets/databricks/databricks-dolly-15k), un grand effort humain de 15K instructions générées manuellement ainsi que le modèle associé, un finetuning de Pythia. En mai, l'Université Tsinghua a publié [UltraChat](https://arxiv.org/abs/2305.14233), un jeu de données de 1,5 million de conversations contenant des instructions, et UltraLLaMA un finetuning dudit jeu de données. Microsoft a ensuite publié le dataset/framework [GPT4-LLM](https://github.com/Instruction-Tuning-with-GPT-4/GPT-4-LLM) pour générer des instructions avec GPT4, et en juin, une recherche de Microsoft a partagé une nouvelle méthode, [Orca](https://arxiv.org/pdf/2306.02707.pdf), pour construire des jeux de données d'instructions en utilisant la trace de raisonnement de modèles plus grands (qui expliquent leur raisonnement étape par étape). Elle a rapidement été reproduite par la communauté (notamment Alignmentlab.ai), qui a créé [Open Orca](https://huggingface.co/Open-Orca, plusieurs millions d'entrées, puis utilisés pour finetuner un certain nombre de modèles (Llama, Mistral, ...). En mai et juin, [Camel-AI](https://huggingface.co/camel-ai) a publié un certain nombre de jeux de données d'instructions ou de chat sur différents sujets (plus de 20K exemples dans chaque domaine, physique, biologie, chimie, ...) obtenus avec GPT4. En juin également, [Airoboros](https://github.com/jondurbin/airoboros) permettant de finetuner les modèles à l'aide de données générées par le modèle (selon l'approche d'auto-instruction) a été publié, ainsi qu'un certain nombre de [instruct datasets](https://huggingface.co/jondurbin). 
+
+🌻Été :  
+En août, [UltraLM](https://github.com/thunlp/UltraChat) (un finetuning de LLaMA très performante pour le chat) a été publié par OpenBMB, une organisation chinoise à but non lucratif, et en septembre, ils ont publié le jeu de données de préférence associé [UltraFeedback](https://huggingface.co/datasets/openbmb/UltraFeedback) obtenu via rétroaction d'entrées comparées par GPT4 (avec annotations). Tout au long de l'été, le collectif [NousResearch](https://huggingface.co/NousResearch), a publié plusieurs finetunings (notamment les collections Hermès et Capybara) à partir de plusieurs jeux d'instructions privées et publiques. En septembre, une équipe d'étudiants de l'Université de Tsinghua a publié [OpenChat](https://huggingface.co/openchat/openchat_3.5), un finetuning d'un LLaMA utilisant une nouvelle stratégie de RL, et Intel a publié un [jeu de données de DPO de style Orca](https://huggingface.co/datasets/Intel/orca_dpo_pairs). 
+
+🍂 Automne :  
+En octobre, Hugging Face a sorti [Zephyr](https://huggingface.co/HuggingFaceH4/zephyr-7b-beta), un finetuning de Mistral utilisant DPO et AIF sur UltraChat et UltraFeedback, et les membres de la communauté ont sorti [OpenHermes 2](https://huggingface.co/teknium/OpenHermes-2-Mistral-7B), un finetuning de Mistral-7B sur 900K entrées provenant du web ou générées avec Axolotl. Lmsys a publié LMSYS-Chat-1M, des conversations d'utilisateurs réels avec 25 LLM. En novembre, OpenBuddy a publié OpenBuddy-Zephyr, un Zephyr spécialisé sur des données de dialogue à plusieurs tours, et Argilla a sorti [Notus](https://huggingface.co/argilla/notus-7b-v1). NVIDIA a publié [HelpSteer](https://huggingface.co/datasets/nvidia/HelpSteer), un jeu d'alignement fournissant des instructions, des réponses de modèle associées et des notes desdites réponses sur plusieurs critères, tandis que Microsoft Research a publié le modèle [Orca-2](https://huggingface.co/microsoft/Orca-2-13b), un Llama 2 spécialisé sur un nouvel jeu de raisonnement synthétique. Intel a sorti [Neural Chat](https://huggingface.co/Intel/neural-chat-7b-v3-1), un finetuning de Mistral sur Orca et avec DPO. En décembre, Berkeley a publié [Starling](https://huggingface.co/berkeley-nest/Starling-LM-7B-alpha), un RLAIF  d'Open-Chat et le jeu de données associé [Nectar](https://huggingface.co/datasets/berkeley-nest/Nectar), 200K entrées de données de comparaison.
+
+Comme nous pouvons le constater, le développement de toute cette année repose à la fois sur la création de nouveaux jeux de données grâce à l'utilisation de LLM pré-entraînés de haute qualité, ainsi que sur tous les modèles ouverts publiés par la communauté, faisant avancer le domaine à pas de géant ! Et si vous voyez maintenant l'un de ces noms dans le nom d'un modèle, vous pourrez vous faire une idée de son origine 🤗
+""", unsafe_allow_html=True)
+
+st.info("""
+Certains jeux de données plus spécialisés (tels que [MetaMath](https://meta-math.github.io/) ou [MathInstruct](https://huggingface.co/datasets/TIGER-Lab/MathInstruct) jeux de problèmes mathématiques, [Evol-Instruct](https://huggingface.co/datasets/WizardLM/WizardLM_evol_instruct_70k), instructions mathématiques et de code, [CodeAlpaca](https://huggingface.co/datasets/sahil2801/CodeAlpaca-20k) et [CodeCapybara](https://github.com/FSoft-AI4Code/CodeCapybara) instructions de code) ont été également publiés. Nous ne les couvrirons pas en détail ici, bien qu'ils aient également été utilisés pour améliorer les performances du modèle sur des tâches spécifiques. Vous pouvez également consulter l'[*awesome instructions dataset*](https://github.com/jianzhnie/awesome-instruction-datasets) pour une compilation d'autres jeux de données pertinents.
+""")
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### Démocratiser l'accès
+Remarque : un certain nombre d'outils ont également émergé pour prendre en charge l'inférence et le déploiement pour les utilisateurs débutants, tels que llama.cpp, ollama, text-generation-inference, vllm, entre autres. Ils sont hors du champ d'application du présent document.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown("""
+#### Fusion : Personnalisation extrême
+D'une manière typiquement open-source, l'un des points de repère de la communauté est la fusion de modèle/données. À chaque fusion/commit, il peut être plus difficile de retracer à la fois les données utilisées (car un certain nombre de jeux de données publiés sont des compilations d'autres jeux de données) et l'historique des modèles, car les modèles très performants sont des versions affinées de versions affinées de modèles similaires (voir par exemple « l'arbre des modèles enfants » de Mistral [ici](https://huggingface.co/spaces/davanstrien/mistral-graph)). Dans ce résumé, nous n'avons pas encore eu le temps de parler de cette technique étonnante, alors consacrons-y quelques mots de la fin. 
+
+Qu'est-ce que cela signifie de fusionner un modèle ?
+
+La fusion de modèles est un moyen de fusionner les poids de différents modèles en un seul modèle afin (idéalement) de combiner les forces respectives de chaque modèle dans un seul modèle unifié. Il existe quelques techniques pour le faire qui ont été étendues et souvent publiées principalement dans des forums communautaires, un cas frappant de recherche entièrement décentralisée se déroulant dans le monde entier entre une communauté de praticiens, de chercheurs et d'amateurs. L'une des méthodes publiées les plus simples consiste à calculer la moyenne des paramètres d'un ensemble de modèles partageant une architecture commune ([exemple 1](https://huggingface.co/papers/2204.03044), [exemple 2](https://huggingface.co/papers/2109.01903)). Des combinaisons de paramètres plus complexes existent, telles que déterminer quels paramètres sont les plus influents dans chaque modèle pour une tâche donnée ([moyenne pondérée](https://huggingface.co/papers/2111.09832)), ou prendre en compte les interférences de paramètres entre les modèles avant de sélectionner les paramètres à conserver lors de la fusion ([Ties Merging](https://huggingface.co/papers/2306.01708)). Pour un bon aperçu de la littérature, vous pouvez consulter cette [collection d'articles](https://huggingface.co/collections/osanseviero/model-merging-65097893623330a3a51ead66) !
+
+Ces techniques permettent à n'importe qui de générer facilement des combinaisons de modèles et sont rendues particulièrement faciles par le fait que la plupart des modèles sont aujourd'hui des variations de la même architecture. C'est la raison pour laquelle certains modèles soumis à l'[*Open LLM Leaderboard*](https://huggingface.co/spaces/HuggingFaceH4/open_llm_leaderboard) ont des noms tels que `llama2-zephyr-orca-ultra`. Cet exemple particulier est probablement une fusion des modèles `lama2` et `zephyr`, finetunés sur des jeux de données `orca` et `ultra`. En général, vous trouverez plus de détails dans la fiche de modèle correspondante sur le Hub.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown("""
+#### PEFT : La personnalisation au bout des doigts
+Parfois, vous pouvez souhaiter une personnalisation plus contrôlée, sans avoir suffisamment de mémoire pour charger un modèle entier afin de le finetunr. Saviez-vous qu'il n'est pas nécessaire d'utiliser un modèle entier lors du *finetuning* ?
+
+Vous pouvez utiliser ce que l'on appelle le **parameter efficient fine-tuning** (PEFT).
+Cette technique gèle d'abord les paramètres du modèle d'intérêt pré-entraîné, puis ajoute un certain nombre de nouveaux paramètres par-dessus, appelés adaptateurs. Ce que vous affinez ensuite dans votre tâche, ce sont uniquement les poids (légers) de l'adaptateur, considérablement plus petits que le modèle d'origine. Il ne vous reste plus qu'à partager vos petits poids d'adaptateur (et le modèle de base) ! Vous trouverez une liste d'approches intéressantes pour le PEFT [ici](https://github.com/huggingface/peft).
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown("""
+#### Quantification : des modèles qui tournent partout
+Nous avons vu que les modèles performants sont maintenant de toutes formes et de toutes tailles... Mais même dans ce cas, cela ne veut pas dire qu'ils sont accessibles à tous ! Un modèle de paramètres 30B peut nécessiter plus de 66 Go de RAM rien que pour se charger en mémoire (même pas l'utiliser), et tout le monde dans la communauté n'a pas le matériel nécessaire pour le faire.
+
+C'est là qu'intervient la quantification ! La quantification est une technique spéciale qui permet de réduire la taille d'un modèle en modifiant la précision de ses paramètres. 
+
+Qu'est-ce que cela signifie ? 
+
+Dans un ordinateur, les nombres sont stockés avec une précision donnée (par exemple, `float32`, `float16`, `int8`, etc.). Une précision indique à la fois le type de nombre (s'il s'agit d'un nombre à virgule flottante ou d'un entier) ainsi que la quantité de mémoire stockée du nombre : `float32` stocke les nombres à virgule flottante sur 32 bits. Pour une explication plus approfondie, voir [ce lien](https://huggingface.co/docs/optimum/concept_guides/quantization#going-further-how-do-machines-represent-numbers). Ainsi, plus la précision est élevée, plus un nombre prend de mémoire physique, car il sera stocké sur plus de bits. 
+
+Si vous réduisez la précision, vous réduisez la mémoire que chaque paramètre du modèle prend en stockage, réduisant ainsi la taille du modèle ! Cela signifie également que vous réduisez... la précision réelle des calculs, qui peut réduire les performances du modèle. Cependant, nous avons découvert que sur les modèles plus grands, cette dégradation des performances est en réalité très [limitée](https://huggingface.co/blog/overview-quantization-transformers).
+
+Pour revenir à notre exemple ci-dessus, notre modèle de paramètres 30B en `float16` nécessite un peu moins de 66G de RAM, en `8bit` il n'en nécessite que la moitié, donc 33G de RAM, et en `4bit` nous atteignons même la moitié de cela, donc environ 16G de RAM, ce qui le rend considérablement plus accessible.
+
+Il existe de nombreuses façons de passer d'une précision à une autre, avec de nombreux schémas de « traduction » différents, chacun ayant ses propres avantages et inconvénients. Les approches populaires incluent [bitsandbytes](https://huggingface.co/papers/2208.07339), [GPTQ](https://huggingface.co/papers/2210.17323) et [AWQ](https://huggingface.co/papers/2306.00978). Certains utilisateurs, comme [TheBloke](https://huggingface.co/TheBloke), convertissent même des modèles populaires pour les rendre accessibles à la communauté. Tous sont très récents et encore en développement, et nous espérons voir encore plus de progrès à ce sujet au fil du temps.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### Quelle est la prochaine étape ?
+L'année n'est pas encore finie ! Et ces derniers jours/heures sont déjà arrivés avec leur lot de surprises : une nouvelle architecture va-t-elle finalement surpasser le simple et efficace *transformer* ?
+
+Les nouvelles sorties incluent
+- Un mélange d'experts :
+	- [Mixtral](https://huggingface.co/mistralai/Mixtral-8x7B-v0.1), le modèle est composé de 8 sous-modèles (*transformer* décodeur), et pour chaque entrée, un routeur sélectionne les 2 meilleurs sous-modèles et additionne leurs sorties.
+- Plusieurs SSM (modèles qui associent l'entrée à la sortie à travers un espace latent et qui peuvent être exprimés soit comme un RNN, soit comme un CNN selon les tâches, [cette ressource](https://srush.github.io/annotated-s4/) est excellente pour expliquer les modèles d'état si vous voulez plus d'informations) :
+	- [Mamba](https://huggingface.co/papers/2312.00752), un SSM RNN avec un mécanisme de sélection
+	- [StripedHyena](https://huggingface.co/togethercomputer/StripedHyena-Nous-7B), un SSM convolutif
+
+Il est encore un peu tôt pour dire si ces nouvelles approches vont prendre le relais du Transformer, mais les modèles d'espace d'état sont assez prometteurs !
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### À retenir
+- Cette année a vu une augmentation des sorties ouvertes de toutes sortes d'acteurs (grandes entreprises, start-ups, laboratoires de recherche), ce qui a permis à la communauté de commencer à expérimenter et à explorer à un rythme jamais vu auparavant.
+- Les annonces d'ouverture de modèles ont connu des hauts et des bas, des premières versions de cette année très ouvertes (mélanges de jeux de données, poids, architectures) aux versions tardives n'indiquant rien sur leurs données d'entraînement, étant donc non reproductibles.
+- Des modèles ouverts ont émergé de nombreux nouveaux endroits, y compris de la Chine, avec plusieurs nouveaux acteurs se positionnant comme de solides concurrents dans le monde des LLM.
+- Les possibilités de personnalisation ont atteint un niveau record, avec de nouvelles stratégies de finetunig (RLHF, adaptateurs, fusion), qui n'en sont qu'à leurs débuts.
+- Les modèles de plus petite taille et les améliorations des méthodes de quantification ont rendu les LLM vraiment accessibles à beaucoup plus de personnes !
+- De nouvelles architectures sont également apparues : vont-elles enfin remplacer le *transformer* ?
+
+C'est tout les amis ! 
+J'espère que vous avez apprécié la revue de cette année, que vous avez appris une chose ou deux, et que vous êtes aussi enthousiaste que moi quant à la mesure dans laquelle les progrès de l'IA reposent désormais sur l'open source et l'effort de la communauté ! 🤗
+""", unsafe_allow_html=True)
+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("Panoramas annuels")
+with col2:
+    if st.button("Accueil", use_container_width=True):
+        switch_page("Home")
+with col3:
+    if st.button("Section suivante", use_container_width=True):
+        switch_page("Panorama 2024")

pages/28_Panorama_2024.py

@@ -0,0 +1,164 @@
+import streamlit as st
+st.set_page_config(layout="wide")
+from streamlit_extras.switch_page_button import switch_page
+
+st.markdown("""# Panorama 2024""")
+st.markdown(""" """)
+st.success("""Ce panorama 2024 est extrêmement redondant avec ce que vous avez déjà pu lire dans ce guide. Il s'agit de l'[article de blog de Clémentine](https://huggingface.co/blog/clefourrier/llm-evaluation) qui lui a servi de base dans sa réflexion pour rédaction du guide. Vous pouvez ainsi ou pas lire ce panorama ou bien passer directement à celui de 2025.""")
+st.markdown(""" """)
+st.markdown("""## Parlons de l'évaluation des LLM
+
+Étant donné que mon équipe travaille sur l'évaluation et les benchmarks à Hugging Face, à l'ICLR 2024, beaucoup de gens ont voulu me demander mon avis sur le sujet (ce qui était très inattendu, merci beaucoup à tous ceux qui étaient intéressés). 
+
+Grâce à toutes ces discussions, j'ai réalisé qu'un certain nombre de choses que je tiens pour acquises en termes d'évaluation sont 1) des idées peu répandues 2) apparemment intéressantes.
+
+Alors, partageons la conversation plus largement !
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown("""
+### Comment faisons-nous l'évaluation LLM ?
+
+Tout d'abord, posons quelques définitions. Il y a, à ma connaissance, à l'heure actuelle, 3 façons principales de faire de l'évaluation : les benchmarks automatisés, l'évaluation humaine, et l'utilisation via des modèles (*LLM-as-a-judge*). Chaque approche a sa propre raison d'être, ses utilisations et ses limites.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" 
+#### Benchmarks
+
+Les benchmarks automatisés fonctionnent généralement de la manière suivante : vous aimeriez savoir comment votre modèle se comporte sur quelque chose. Il peut s'agir d'une **tâche** concrète bien définie, telle que « Dans quelle mesure mon modèle peut-il classer le spam des e-mails non spam ? », ou d'une **capacité** plus abstraite et générale, telle que « Quelle est la qualité de mon modèle en mathématiques ? ».
+
+À partir de là, vous construisez une évaluation, généralement composée de deux choses :
+- une collection d'*échantillons*, donnés en entrée au modèle pour voir ce qui en sort, parfois couplé à une référence (appelée or) à laquelle comparer. Les exemples sont généralement conçus pour essayer d'émuler ce sur quoi vous voulez tester le modèle. Par exemple, si vous examinez une classification d'e-mails, vous créez un jeu de données d'e-mails désirables et indésirables, essayez d'inclure des cas limites difficiles, etc. Pour les LLM, les deux tâches principales sont l'évaluation de la génération (comparaison du texte généré avec une référence après normalisation) ou le choix multiple (comparer les probabilités logarithmiques relatives des continuations possibles après une invite).
+- une *métrique*, qui est un moyen de calculer un score pour le modèle. Par exemple, avec quelle précision votre modèle peut-il classer le spam (score de l'échantillon bien classé = 1, mal classé = 0).
+
+C'est plus intéressant à faire sur des données qui n'ont pas été incluses dans le jeu d'entraînement du modèle, car vous voulez tester si cela se généralise bien. Vous ne voulez pas d'un modèle qui ne peut classer que les emails qu'il a déjà « vus », ce ne serait pas très utile ! 
+""", unsafe_allow_html=True)
+st.info(""" 
+Un modèle qui ne peut que bien prédire sur ses données d'entraînement (et qui n'a pas appris de manière latente des modèles généraux de haut niveau) est dit **surentraîné**. Dans les cas moins extrêmes, vous souhaitez tout de même tester si votre modèle est capable de généraliser à des modèles de données qui n'étaient pas dans la distribution de l'ensemble d'entraînement (par exemple, classez les spams concernant les produits de « santé » après n'avoir vu que des spams concernant de fausses banques).
+""")
+st.markdown(""" 
+Cela fonctionne assez bien pour des tâches très bien définies, où les performances sont « faciles » à évaluer et à mesurer : lorsque vous testez littéralement votre modèle sur de la classification des spams, vous pouvez dire « le modèle a correctement classé n % de ces échantillons ». Pour les benchmarks de LLM, certains problèmes peuvent survenir, tels que les modèles [favorisant des choix spécifiques basés sur l'ordre dans lequel ils ont été présentés pour les évaluations à choix multiples](https://arxiv.org/abs/2309.03882), et les évaluations génératives reposant sur des normalisations qui peuvent facilement [être injustes si elles ne sont pas bien conçues](https://huggingface.co/blog/fr/open-llm-leaderboard-drop), mais dans l'ensemble, elles fournissent toujours un signal au niveau de la tâche.
+
+Pour les capacités, cependant, il est difficile de les décomposer en tâches bien définies et précises : que signifie « bon en mathématiques » ? Bon en arithmétique ? à la logique ? capable de raisonner sur des concepts mathématiques ?
+
+Dans ce cas, les gens ont tendance à faire des évaluations plus « holistiques », en ne décomposant pas la capacité dans des tâches réelles, mais en supposant que la performance sur des échantillons généraux sera un **bon indicateur** de ce que nous visons à mesurer. Par exemple, le jeu GSM8K est composé de problèmes mathématiques réels de lycée, qui nécessitent tout un ensemble de capacités pour être résolus. Cela signifie également que l'échec et le succès sont très difficiles à interpréter. Certaines capacités ou sujets, tels que « ce modèle est-il bon pour écrire de la poésie ? » ou « les résultats du modèle sont-ils utiles ? » sont encore plus difficiles à évaluer avec des mesures automatiques. Et en même temps, les modèles semblent maintenant avoir de plus en plus de capacités **généralistes**, nous devons donc évaluer leurs capacités de manière plus large. Par exemple, il y a eu un débat dans la communauté scientifique sur la question de savoir si les LLM [peuvent dessiner](https://arxiv.org/abs/2303.12712) des licornes [ou non](https://twitter.com/DimitrisPapail/status/1719119242186871275). Très probablement pas à ce stade, mais clairement un point important à étudier.
+
+Les benchmarks automatisés ont également tendance à avoir un autre problème : une fois qu'ils sont publiés publiquement en texte brut, ils sont très susceptibles de se retrouver (souvent accidentellement) dans les jeux de données d'entraînement des modèles. Certains créateurs de benchmarks, comme les auteurs de BigBench, ont essayé d'atténuer cela en ajoutant une « chaîne canari » (une combinaison très spécifique de caractères) pour que les gens puissent la rechercher et la supprimer des ensembles d'entraînement, mais tout le monde n'est pas conscient du mécanisme ni n'essaie de faire cette suppression. Il existe également une quantité non négligeable de benchmarks, de sorte que la recherche de copies accidentelles d'absolument tous ces benchmarks dans les données est coûteuse. D'autres options incluent la fourniture de benchmarks sous une [forme cryptée](https://arxiv.org/pdf/2309.16575), ou derrière un [système de contrôle](https://huggingface.co/datasets/Idavidrein/gpqa). Cependant, lors de l'évaluation de modèles fermés derrière des API de boîte noire, il n'y a aucune garantie que les données fournies ne seront pas utilisées ultérieurement en interne pour l'entraînement ou le finetuning. 
+
+Le cas où un jeu de données d'évaluation se retrouve dans le jeu d'entraînement s'appelle la **contamination**, et un modèle qui a été contaminé aura une performance de référence élevée qui ne se généralise pas bien à la tâche sous-jacente (une description détaillée de la contamination peut être trouvée [ici](https://aclanthology.org/2023.findings-emnlp.722/), et voici une façon amusante de [la détecter](https://arxiv.org/abs/2311.06233)). Une façon de lutter contre la contamination est d'exécuter des [**benchmarks dynamiques**](https://arxiv.org/abs/2104.14337) (évaluations sur des données qui sont régulièrement actualisées pour fournir des scores sur de nouvelles données systématiquement invisibles), mais cette approche est coûteuse à long terme.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" 
+#### L'humain comme juge
+
+Une solution à la fois à la contamination et à une évaluation plus ouverte consiste à demander aux humains d'évaluer les résultats du modèle.
+
+Cela se fait généralement en demander à des humains d'interroger des modèles puis de noter une réponse de modèle ou de classer plusieurs résultats selon des directives. Utiliser des humains comme juges permet d'étudier des tâches plus complexes, avec plus de flexibilité que les mesures automatisées. Cela permet également d'éviter la plupart des cas de contamination, puisque les instructions écrites sont (espérons-le) nouvelles. Enfin, il est bien corrélé avec la préférence humaine, puisque c'est littéralement ce qui est évalué !
+
+Différentes approches existent pour évaluer les modèles avec des humains dans la boucle.
+
+**Vibes-checks** est le nom donné aux évaluations manuelles effectuées individuellement par certains membres de la communauté, généralement sur des instructions non divulguées, pour obtenir une « sensation » globale de la performance des modèles sur de nombreux cas d'utilisation, qui vont du codage à la qualité des écrits.
+Souvent partagés sur Twitter et Reddit, ils constituent pour la plupart des preuves anecdotiques et ont tendance à être très sensibles au biais de confirmation (en d'autres termes, les gens ont tendance à trouver ce qu'ils cherchent). Cependant, certaines personnes ont essayé de faire des évaluations plus méthodiques ; par exemple, l'utilisateur *Wolfram Ravenwolf* partage ses résultats de comparaisons de modèles de manière très systématique à travers des blogs (voir [ici](https://huggingface.co/blog/wolfram/llm-comparison-test-llama-3) pour un exemple).
+
+L'utilisation des commentaires de la communauté pour établir des classements massifs de modèles est ce que nous appelons une **arène**. Un exemple bien connu est l'arène des chatbots LMSYS(https://huggingface.co/spaces/lmsys/chatbot-arena-leaderboard), où les utilisateurs sont invités à discuter avec des modèles jusqu'à ce qu'ils trouvent que l'un est meilleur que l'autre. Les votes sont ensuite agrégés dans un classement Elo (un classement de matchs) pour sélectionner quel modèle est « le meilleur ». Le problème évident d'une telle approche est la grande subjectivité. Il est difficile d'imposer une notation cohérente à de nombreuses personnes en utilisant des directives générales, d'autant plus que les préférences des annotateurs ont tendance à être [culturellement liées](https://arxiv.org/abs/2404.16019v1) (avec différentes personnes privilégiant différents sujets de discussion, par exemple). On peut espérer que cet effet est atténué par l'ampleur des votes, par un effet de « sagesse de la foule » (cet effet a été constaté par un statisticien nommé Galton, qui a observé que les réponses individuelles essayant d'estimer une valeur numérique, comme le poids d'un porc, pouvaient être modélisées comme une distribution de probabilité centrée autour de la réponse réelle).  
+
+La dernière approche est les annotations systématiques, où vous fournissez des directives extrêmement spécifiques aux annotateurs sélectionnés rémunérés, afin d'éliminer autant que possible le biais de subjectivité (c'est l'approche utilisée par [ScaleAI](https://scale.com/guides/data-labeling-annotation-guide#hight-quality-data-annotations), et la plupart des sociétés d'annotation de données). Cependant, cela peut rapidement devenir extrêmement coûteux, car vous devez continuer à faire des évaluations de manière continue et non automatique pour chaque nouveau modèle que vous souhaitez évaluer, et il peut toujours être la proie de préjugés humains (cette [étude](https://arxiv.org/abs/2205.00501) a montré que les personnes ayant des identités différentes ont tendance à évaluer la toxicité des réponses du modèle très différemment). 
+
+Des [travaux récents](https://arxiv.org/pdf/2309.16349) ont également montré que les évaluateurs humains ont tendance à estimer la qualité des réponses en se basant sur les premières impressions, plutôt que sur la réalité ou la fidélité. Les annotateurs sont notamment très sensibles au ton et sous-estiment le nombre d'erreurs factuelles ou logiques dans une réponse affirmée. En d'autres termes, si un modèle dit des choses fausses sur un ton confiant, les évaluateurs humains sont beaucoup moins susceptibles de le remarquer, ce qui pourrait biaiser les évaluations en faveur des modèles les plus affirmés. 
+Les annotateurs experts sont moins susceptibles d'être la proie de ces biais. Ce type de biais humain a été confirmé dans un autre [article](https://arxiv.org/pdf/2310.13548) : les humains sont plus susceptibles de préférer des réponses qui font appel à leurs opinions ou s'alignent sur leurs opinions ou erreurs, plutôt que des réponses qui sont factuellement correctes. 
+
+Ces biais ne sont pas inattendus, mais ils doivent être pris en compte : tous les cas d'utilisation ne doivent pas reposer sur l'utilisation d'annotateurs humains, en particulier ceux qui sont issus du *crowdsourcing* et qui ne sont pas experts - toute tâche nécessitant des faits (comme l'écriture de code, l'évaluation de la connaissance du modèle, etc.) doit inclure un autre type d'évaluation, plus robuste, pour compléter le benchmark.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown("""
+#### *Model-as-a-judge*
+
+Pour atténuer le coût des annotateurs humains, certaines personnes ont envisagé d'utiliser des modèles ou des artefacts dérivés (de préférence alignés sur les préférences humaines) pour évaluer les résultats des modèles. Cette approche n'est pas nouvelle, car vous pouvez trouver des techniques pour mesurer la qualité de la synthèse à partir de [d'embeddings de modèles](https://arxiv.org/abs/1904.09675) en 2019.
+
+Il existe deux approches pour la notation : l'utilisation de [modèles généralistes à haute capacité](https://arxiv.org/abs/2306.05685v4) ou l'utilisation de [petits modèles spécialisés](https://arxiv.org/pdf/2405.01535) entraînés spécifiquement pour distinguer les données de préférence. La première approche donne des résultats bien corrélés avec la préférence humaine, mais la plupart des modèles suffisamment solides ont tendance à être à source fermée, donc sujets à changement derrière les API et ininterprétables.
+
+Les LLM en tant que juges ont plusieurs fortes limites : ils ont tendance à [favoriser leurs propres résultats](https://arxiv.org/abs/2404.13076) lors de la notation des réponses, sont [mauvais pour fournir des plages de scores cohérentes](https://twitter.com/aparnadhinak/status/1748368364395721128) (bien que vous puissiez améliorer cela en demandant au modèle d'expliquer son raisonnement [avant de fournir un score](https://twitter.com/seungonekim/status/1749289437165769177)), et ne sont en fait pas si cohérents [avec les humains classements](https://arxiv.org/pdf/2308.15812).
+
+Mon principal reproche avec l'utilisation de cette approche est que ces modèles introduisent un biais très subtil et ininterprétable dans la sélection des réponses. J'ai l'impression que, tout comme lorsque vous faites trop de croisements dans les études génétiques, vous vous retrouvez avec des animaux ou des plantes dysfonctionnels, en utilisant des LLM pour sélectionner et entraîner des LLM, nous sommes tout aussi susceptibles d'introduire des changements infimes qui auront des répercussions plus importantes dans quelques générations. Je pense que ce type de biais est moins susceptible de se produire dans des modèles plus petits et plus spécialisés en tant que juges (tels que les classifieurs de toxicité), mais cela reste à tester et à prouver rigoureusement.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" 
+### Pourquoi faisons-nous de l'évaluation de LLM ?
+
+Maintenant que nous avons vu comment nous faisons de l'évaluation, à quoi cela sert réellement ?
+
+Je crois fermement qu'il y a 3 raisons principales pour lesquelles les gens font de l'évaluation, qui ont tendance à être confondues, mais qui sont en fait **très différentes**, et chacune répond à une question distincte.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" 
+#### 1) Mon modèle s'entraîne-t-il bien ? Ma méthode d'entraînement est-elle solide ? : Tests de non-régression
+
+Un test de non-régression est un concept qui vient de l'industrie du logiciel, pour s'assurer que de petits changements n'ont pas cassé l'approche globale.
+
+L'idée est la suivante : lorsque vous ajoutez une nouvelle fonctionnalité à votre logiciel, ou que vous corrigez un problème dans la base de code, avez-vous cassé quelque chose d'autre ? C'est à cela que servent les tests de non-régression : s'assurer que le comportement attendu et de haut niveau de votre logiciel n'est pas soudainement interrompu par un changement (apparemment sans rapport).
+
+Lorsque vous sélectionnez une configuration pour entraîner des modèles, vous voulez tester quelque chose de très similaire et vous assurer que vos modifications (choix de données d'entraînement, d'architecture, de paramètres différents, etc.) n'ont pas « cassé » les performances attendues pour un modèle de ces propriétés.
+
+Pour donner un exemple concret, on s'attendrait à ce qu'un LLM de base 7B obtienne entre 50 et 65 sur MMLU (à choix multiples) après l'entraînement, et d'autre part des performances fluctuant entre 20 et 30 indiquent qu'aucun apprentissage n'a eu lieu.
+
+Pour l'évaluation « non-régression », vous devez regarder 1) les scores d'évaluation **trajectoires** (est-ce que la performance est meilleure maintenant qu'au début de l'entraînement), 2) les **plages** des scores d'évaluation (c'est la performance dans ce qui est attendu). En fait, vous ... ne se soucient pas du score précis eux-mêmes !
+
+Cette évaluation n'est donc pas là pour vous dire quoi que ce soit sur les capacités réelles du modèle, mais plutôt pour confirmer que votre approche d'entraînement est « aussi solide » que l'autre, et que votre modèle se comporte de manière similaire. Je crois que même certaines évaluations portant simplement sur les changements dans la perplexité (probabilités) du texte pourraient être suffisantes pour cette étape, mais vous voulez généralement des points de référence qui ont un rapport « signal sur bruit » élevé, ou en d'autres termes, vous voulez vous assurer qu'un grand changement dans le score reflète un grand changement dans votre modèle.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" 
+#### 2) Quel est le meilleur modèle ? Mon modèle est-il meilleur que le vôtre ? : Classements
+
+Le rôle suivant de l'évaluation consiste simplement à trier les modèles pour trouver et sélectionner les meilleures architectures et approches globales. Si vous avez un classement, que vous prenez le meilleur modèle et qu'il ne fonctionne pas sur votre cas d'utilisation, il est peu probable que le meilleur modèle suivant fonctionne. Dans [leur article](https://arxiv.org/pdf/2404.02112) sur les leçons apprises sur l'analyse comparative et la conception de jeux de données de l'ère ImageNet, les auteurs soutiennent que, puisque les scores sont susceptibles d'être instables, la seule façon robuste d'évaluer les modèles est d'utiliser les classements. Plus précisément de trouver de grands groupes d'évaluations qui fournissent des classements cohérents et stables.
+
+Je crois que la recherche de la stabilité d'un classement est en effet une approche extrêmement intéressante pour l'analyse comparative des modèles, car nous avons montré que les *scores* des LLM sur les benchmarks automatisés sont extrêmement sensibles aux [changements infimes du *prompt*](https://huggingface.co/blog/fr/evaluation-structured-outputs), et que les évaluations humaines ne sont pas plus cohérentes. Les *classements* sont en fait plus stables lors de l'utilisation de méthodes d'évaluation robustes. 
+
+Si les scores, en eux-mêmes, ne sont pas si pertinents que cela, l'utilisation de l'ordre relatif des modèles pourrait-elle nous dire quelque chose de valeur à la place ?
+
+Lors de la séance plénière d'évaluation d'ICLR 2024, Moritz Hardt a comparé l'ajout de perturbations à l'*Open LLM Leaderboard* (par une modification minuscule du score, bien dans les fourchettes de scores) et sur l'arène du chatbot (en ajoutant un mauvais concurrent à l'arène pour voir comment cela a affecté le classement Elo). Ces benchmarks ne fournissent pas non plus de classements stables et cohérents à l'heure actuelle. Nous ne manquerons pas d'explorer cet aspect avec les futures versions de l'Open LLM Leaderboard !
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" 
+#### 3) Où en sommes-nous, en tant que domaine, en termes de capacités de modèle ? Mon modèle peut-il faire X ?
+
+« Comment savez-vous si les modèles peuvent faire X ? » est une question qui revient souvent, et je pense que c'est une question très valable.
+
+Cependant, pour toute capacité complexe, nous ne pouvons pas pour l'instant simplement dire « ce modèle est le meilleur dans ce domaine », mais plutôt « ce modèle est le meilleur sur cette tâche que nous espérons être un bon proxy pour cette capacité, sans aucune garantie ». 
+
+Nous manquons cruellement de bonnes définitions et de cadres sur ce qu'est une capacité pour un modèle d'apprentissage automatique, en particulier pour ceux qui entourent le raisonnement et la théorie de l'esprit. Cependant, ce n'est pas spécifique à l'apprentissage machine ! Dans les études humaines et animales, il est également assez difficile de définir ce qui constitue une « capacité », et les mesures qui tentent de fournir des scores précis (QI et QE par exemple) sont vivement débattues et controversées, à juste titre.
+
+Nous pourrions vouloir nous tourner vers les sciences sociales pour réfléchir à l'évaluation des capacités, car dans ces domaines, les gens sont habitués à réfléchir sérieusement aux facteurs de confusion dans la collecte et l'analyse des données. Cependant, je crois aussi qu'il est probable que 1) nous ne pouvons pas du tout définir ces grandes capacités, puisque nous ne pouvons pas les définir chez les humains et les animaux pour le moment, 2) les cadres conçus avec l'humain/l'animal à l'esprit ne seront pas bien transférés aux modèles, car les comportements et les hypothèses sous-jacents ne sont pas les mêmes.
+""", unsafe_allow_html=True)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" """)
+st.markdown(""" 
+### Conclusion
+
+L'évaluation d'un LLM se fait aujourd'hui de la manière suivante :
+- En utilisant des benchmarks automatisés, affectés par la contamination et le manque de « généralité » (ce dernier n'étant pas forcément une mauvaise chose, tant les évaluations spécialisées sont intéressantes). 
+- En utilisant des évaluateurs humains, qui ont tendance à souffrir d'un manque de reproductibilité à petite échelle, et les biais psychologiques en général (tels que la préférence pour les réponses flagorneuses), bien que l'on puisse espérer que certains des biais soient lissés à grande échelle.
+- En utilisant des modèles, ce qui présente des biais très subtils lors de l'évaluation, susceptibles de passer inaperçus mais d'introduire des perturbations en aval.
+  
+Cependant, tout n'est pas perdu : l'évaluation, dans ses limites, est toujours en mesure de fournir un signal sur les nouvelles méthodes d'entraînement ou les jeux de données qui semblent prometteurs ou non, à la fois en examinant comment les performances se situent dans les plages attendues (tests de non-régression) et comment les modèles sont classés globalement (avec des évaluations suffisamment stables). Nous pouvons également espérer que la combinaison de suffisamment de points de données entre les sujets et les tâches nous fournira suffisamment de signal pour nous faire une idée des performances globales du modèle, sans toutefois supposer quoi que ce soit sur des capacités plus « générales ». 
+
+Contrairement au battage médiatique, nous ne pouvons pas vraiment évaluer les « capacités générales d'un modèle » pour le moment, tout d'abord parce que nous n'avons pas défini ce que cela signifie. Cependant, l'évaluation du LLM, en tant que domaine de recherche, n'en est qu'à ses balbutiements à l'heure actuelle, et il y a beaucoup à faire, ce qui est très excitant ! L'inspiration peut être puisée dans de nombreux domaines, de l'apprentissage automatique (https://transformer-circuits.pub/2024/scaling-monosemanticity/index.html) à la sociologie, afin de définir de nouvelles métriques et tâches. Le travail interdisciplinaire ouvrira probablement de très nouvelles directions intéressantes pour le domaine !
+""", unsafe_allow_html=True)
+
+
+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 2023")
+with col2:
+    if st.button("Accueil", use_container_width=True):
+        switch_page("Home")
+with col3:
+    if st.button("Section suivante", use_container_width=True):
+        switch_page("Panorama 2025")

pages/29_Panorama_2025.py

@@ -0,0 +1,221 @@
+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")