Spaces:
Running
Running
| import streamlit as st | |
| st.set_page_config(layout="wide") | |
| from streamlit_extras.switch_page_button import switch_page | |
| st.markdown( | |
| """ | |
| ## Concevoir votre évaluation automatisée | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown( | |
| """ | |
| ### Choisir un jeu de données | |
| Pour votre évaluation, vous pouvez soit sélectionner un jeu de données existant (voir la section suivante pour des exemples), soit concevoir votre propre jeu de données. Tout au long de ce processus, il est très important de garder à l'esprit que **votre résultat d'évaluation sera uniquement aussi bon que votre jeu de données d'évaluation**. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Sélection d'un jeu de données existant | |
| Vous devez impérativement regarder les composants suivants. | |
| ##### Processus de création | |
| - **Qui a créé les échantillons ?**<br> | |
| Selon moi : un jeu de données créé par un expert **>** un jeu de données d'annotateurs rémunérés **~** jeu de données crowdsourcé **>** un jeu de données MTurked.<br> | |
| Il est important de rechercher une carte de données où vous trouverez des données socio-démographiques sur les annotateurs pouvant être importante pour comprendre la diversité linguistique du jeu de données. | |
| - **Les échantillons ont-ils été examinés par d'autres annotateurs ou par les auteurs eux-mêmes?**<br> | |
| Vous voulez savoir :<br> | |
| - si le score inter-annotateurs sur les échantillons est élevé (= les annotateurs sont-ils d'accord ?)<br> | |
| - et/ou si le jeu de données complet a été examiné par les auteurs.<br> | |
| Ceci est particulièrement important pour les jeux de données avec l'aide d'annotateurs sous-payés qui ne sont généralement pas des locuteurs natifs de votre langue cible (c'est souvent le cas pour AWS Mechanical Turk par exemple), car vous pourriez autrement trouver des fautes de frappe/des erreurs grammaticales/des réponses absurdes. | |
| - **Les annotateurs ont-ils reçu des directives claires pour la création des données ?**<br> | |
| En d'autres termes, votre jeu de données est-il cohérent ? | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ##### Échantillons | |
| Prélevez 50 échantillons au hasard et inspectez-les manuellement :<br> | |
| - *Pour la qualité* :<br> | |
| - les questions sont-elles claires et sans ambiguïté ? <br> | |
| - les réponses sont-elles correctes ? (ex : [TriviaQA](https://huggingface.co/datasets/mandarjoshi/trivia_qa) contient plusieurs réponses de référence (champ des alias) parfois contradictoires.)<br> | |
| - des informations sont-elles manquantes ? (ex : [MMLU](https://huggingface.co/datasets/cais/mmlu) manque de schémas de référence dans un certain nombre de questions.)<br> | |
| - *Pour la pertinence par rapport à votre tâche* :<br> | |
| - ces questions correspondent-elles au type de questions sur lesquelles vous souhaitez évaluer un LLM ?<br> | |
| - ces exemples correspondent-ils à votre cas d'utilisation ?<br> | |
| Vous voulez également savoir combien d'échantillons sont présents (pour vous assurer que les résultats sont statistiquement significatifs, 100 échantillons sont généralement un minimum pour les jeux d'évaluation automatisés). | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| #### Conception de votre propre jeu de données | |
| Vous avez trois possibilités pour concevoir votre propre jeu de données.<br> | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ##### Agrégation de données existantes | |
| Vous pouvez agréger des données existantes provenant de différentes sources, en évaluant une capacité pertinente pour votre tâche. Un certain nombre de jeux de données d'évaluation sont par exemple construits à partir de l'agrégation de jeux de données d'évaluation humaine (tels que MATH, LSAT, etc.). Dans ce cas, suivez les étapes ci-dessus. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ##### Utilisation d'annotateurs humains | |
| Il y a toute une section consacrée à ce point dans la section <a href="III.2._Utiliser_des_annotateurs_humains" target='_self'>Utiliser des annotateurs humains</a>. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ##### Utilisation de données synthétiques | |
| - **Utilisation de LLM**<br> | |
| À ce sujet, vous pouvez consulter l'article de blog sur [Cosmopedia](https://huggingface.co/blog/cosmopedia) de mes collègues d'Hugging Face ! Il traite principalement de la création d'un jeu de données d'entraînement synthétique, mais des techniques similaires peuvent être utilisées pour l'évaluation. | |
| Assurez-vous de vérifier/filtrer/inspecter manuellement votre jeu de données par la suite (en suivant les étapes ci-dessus).<br> | |
| - **Utilisation de techniques basées sur des règles**<br> | |
| Si votre tâche le permet, c'est un très bon moyen d'obtenir un nombre pratiquement infini d'échantillons et d'éviter la contamination !<br> | |
| Pour quelques exemples, vous pouvez consulter [NPHardEval](https://arxiv.org/abs/2312.14890), [DyVal](https://arxiv.org/abs/2309.17167), [MuSR](https://arxiv.org/abs/2310.16049), [BabiQA](https://arxiv.org/abs/1502.05698), etc. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Choisir une méthode d'inférence | |
| Vous devez choisir le type de méthode d'inférence dont vous avez besoin. | |
| L'utilisation des log-probabilités (MCQA pour *multi-choice question answer*) est très utile pour les réponses à des QCM (généralement pour tester la connaissance du modèle ou la capacité de désambiguïsation). <br> | |
| - Avantages ➕ : <br> | |
| - Permet de s'assurer que tous les modèles ont accès à la bonne réponse.<br> | |
| - Fournit une approximation de la « confiance » du modèle (et de la calibration).<br> | |
| - Rapide à évaluer, en particulier lorsque nous demandons au modèle de prédire un seul élément (A/B/C/D les indices des choix, ou Oui/Non, etc.).<br> | |
| - Permet d'obtenir un signal sur les performances des petits modèles. <br> | |
| - Inconvénients ➖ : <br> | |
| - Les petits modèles, qui auraient généré quelque chose en dehors de l'éventail des choix disponibles si on leur avait donné carte blanche, sont légèrement surévalués.<br> | |
| - Certains modèles [favorisent des choix spécifiques en fonction de l'ordre dans lequel ils ont été présentés](https://arxiv.org/abs/2309.03882), ce qui pourrait conduire à des évaluations non représentatives. | |
| L'utilisation de générations (QA, *question answering*) est très utile pour toutes les tâches où vous souhaitez tester la fluidité, le raisonnement ou la capacité de votre modèle à répondre à des questions.<br> | |
| - Avantages ➕ :<br> | |
| - Devrait être corrélé avec la capacité du LLM à générer du texte fluide, sera la plupart du temps ce qui intéresse les gens.<br> | |
| - Inconvénients ➖ :<br> | |
| - Peut être plus difficile à évaluer (voir la partie « Métriques » ci-dessous)<br> | |
| - Généralement un peu plus cher que les évaluations par log-vraisemblance, surtout si elles incluent l'échantillonnage. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Choisir une instruction (*prompt* en anglais) | |
| L'instruction va définir : | |
| - la quantité d'informations données à votre modèle sur la tâche | |
| - la manière dont ces informations sont présentées à votre modèle.<br> | |
| Une instruction pour du QCM ou du QA est généralement composée de certains des éléments suivants : | |
| - une description de la tâche (facultatif) : présente votre tâche. | |
| - un contexte : fournit un contexte supplémentaire pour votre question.<br>Par exemple pour une tâche de résumé ou d'extraction d'informations, vous pouvez fournir une source de contenu. | |
| - une question : le cœur de votre instruction. | |
| - dans le cas d'une évaluation à choix multiples, vous pouvez ajouter des options | |
| - des mots connecteurs (`Question`, `Contexte`, `Choix`, ...)<br> | |
| Lorsque vous définissez votre instruction, vous devez être conscient que :<br> | |
| - même de petits changements sémantiquement équivalents dedans peuvent faire varier les résultats de manière significative (voir la section <a href='V.2._Dépanner la reproductibilité' target='_self'>Dépanner la reproductibilité</a>), et les formats utilisés peuvent avantager ou désavantager des modèles spécifiques.<br> | |
| - Comment atténuer ce problème : <br> | |
| - Una approche coûteuse est de refaire l'évaluation plusieurs fois avec des variations de l'instruction.<br> | |
| - Une solution moins coûteuse consiste à effectuer l'évaluation une seule fois en utilisant une série de formats d'instruction attribués à différents échantillons de difficulté équivalente.<br> | |
| - vous pouvez fournir des exemples à votre modèle pour l'aider à suivre le format attendu (appelés exemples *few-shot*) ainsi que de mots connecteurs qui ont tendance à aider.<br> | |
| - mais les modèles ont maintenant tendance à être surentraînés à des formats d'instruction spécifiques.<br> | |
| - [Ce papier](https://arxiv.org/abs/2407.07890) est excellent sur le sujet, montrant notamment comment certains modèles peuvent être surévalués parce qu'ils sont surentraînés sur le **format** du jeu de test.<br> | |
| - Sur l'[*Open LLM Leaderboard 2*](https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard), nous avons notamment observé que Llama 3.2 et Qwen 2.5 ne suivent plus le format de l'instruction fournie dans les exemples *few-shot* à cause de ce point.<br> | |
| - pour un certain nombre de métriques, vous souhaitez une génération ou une sortie contrainte.<br> | |
| Vous pouvez en apprendre plus à ce sujet dans la partie « Contraindre les sorties du modèle » de la section <a href='I.1._Inférence_et_évaluation_des_modèles.' target='_self'>Inférence et évaluation des modèles</a>. | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Choisir une métrique | |
| Si vous étudiez les **log-probabilités**, le choix est simple : regardez l'*accuracy* (combien de fois le choix le plus probable est le meilleur choix). Il est important de la normaliser en fonction de la longueur (de caractère, de *tokens*, etc.). | |
| Vous pouvez également considérer la [perplexité](https://huggingface.co/spaces/evaluate-metric/perplexity), le [rappel](https://huggingface.co/spaces/evaluate-metric/recall) ou le [score f1](https://huggingface.co/spaces/evaluate-metric/f1). | |
| Pour les évaluations **génératives**, l'éventail des métriques est plus large. <br> | |
| Vous devrez :<br> | |
| 1. décider si vous comparez les générations telles quelles ou si vous les normalisez préalablement. <br> | |
| - Les normalisations peuvent facilement [être injustes si elles ne sont pas bien conçues](https://huggingface.co/blog/fr/open-llm-leaderboard-drop) (en français), mais dans l'ensemble, elles fournissent toujours un signal au niveau de la tâche.<br> | |
| - Elles sont très importantes pour des tâches spécifiques, telles que les évaluations mathématiques, pour lesquelles vous pourriez vouloir extraire vos résultats à partir de sorties formatées.<br> | |
| - Elles seront également importantes si vous souhaitez évaluer avec des mécanismes supplémentaires, tels que la chaîne de pensée (*Chain of Thought*), car vous devrez retirer la trace du raisonnement du résultat réel.<br> | |
| 2. décider de la manière dont vous comparez la génération avec la référence.<br> | |
| Vous pouvez utiliser n'importe quelles métriques basées sur les correspondances ([correspondance exacte](https://huggingface.co/spaces/evaluate-metric/exact_match), correspondance par préfixe, etc.) ou des métriques de résumé et de traduction ([ROUGE](https://huggingface.co/spaces/evaluate-metric/rouge), [BLEU](https://huggingface.co/spaces/evaluate-metric/bleu), comparaisons de caractères/n-grammes). Pour une liste des métriques existantes, vous pouvez regarder [ici](https://github.com/huggingface/lighteval/wiki/Metric-List). | |
| Plus généralement, lorsque vous choisissez votre métrique, vous devez garder à l'esprit l'objectif réel de votre tâche. Pour certains domaines (ex : médical, chatbots avec interaction publique, etc.), vous ne voulez pas mesurer la performance moyenne mais avez besoin d'un moyen d'évaluer la **plus mauvaise performance** que vous obtiendrez (sur la qualité médicale de la sortie, sur la toxicité, etc.).<br> | |
| Pour aller plus loin, jetez un coup d'œil à cet article de [blog](https://ehudreiter.com/2024/07/10/challenges-in-evaluating-llms/). | |
| """, unsafe_allow_html=True) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" """) | |
| st.markdown(""" | |
| ### Nouvelles tâches intelligentes : qu'en est-il des tests fonctionnels ? | |
| Dans le domaine du code, vous souhaitez évaluer les programmes générés non seulement sur leur sémantique, mais aussi sur leur fonctionnalité réelle. Une bonne façon de le faire est donc de vérifier si le code généré à la suite d'une instruction passe correctement une suite de tests unitaires conçus pour s'adapter à la tâche. | |
| Cette approche fonctionnelle est extrêmement prometteuse, car elle<br> | |
| - permet de générer des cas de test plus facilement (c'est assez facile d'en générer à base de règles)<br> | |
| - de réduire ainsi le surentraînement<br> | |
| - de tester les modèles sur des capacités actives spécifiques | |
| Il s'agit toutefois d'une approche qui requiert de la créativité pour être traduite en texte ! | |
| Un bon exemple est [IFEval](https://huggingface.co/datasets/google/IFEval), un jeu d'évaluation qui teste si les modèles peuvent suivre des instructions. Il s'agit de créer un certain nombre d'instructions de formatage (« Ajouter tel nombre de puces », « Mettre une seule phrase en majuscule », etc.), et de tester strictement si le format est respecté. Un travail supplémentaire est clairement nécessaire pour étendre cette idée à d'autres caractéristiques à analyser dans un texte ! | |
| """, 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("II.1._Bases") | |
| 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("II.3._Quelques_jeux_de_données_d'évaluation") |