Maîtriser l'évaluation du Machine Learning : Meilleures pratiques
Apprends des techniques essentielles pour évaluer efficacement le machine learning.
Luciana Ferrer, Odette Scharenborg, Tom Bäckström
― 10 min lire
Table des matières
- Les bases : tâches et applications
- Comprendre les systèmes et méthodes
- Division des données
- Éviter les erreurs courantes
- Choisir les bonnes métriques
- Évaluation des prédictions séquentielles
- Gérer les probabilités de classes
- Tâches de régression
- Normaliser les métriques de performance
- Garder un œil sur les erreurs courantes dans les métriques
- Intervalles de confiance : le filet de sécurité
- Évaluer les systèmes vs. méthodes
- Conclusion : La morale
- Source originale
- Liens de référence
Quand il s'agit de vérifier si un système d'apprentissage automatique (ML) fonctionne bien, tout comme s'assurer que ton plat préféré est bien cuisiné, le processus d'évaluation est super important. Plein d'éléments peuvent influencer les résultats des expériences ML. Ça inclut les données d'entraînement, les caractéristiques utilisées, la conception du modèle et la façon dont le modèle est peaufiné. Cependant, le point le plus crucial reste le processus d'évaluation lui-même.
Si l'évaluation est mal faite, les conclusions peuvent être inutiles ou même mener à de mauvaises décisions en développement. Donc, un processus d'évaluation soigneusement conçu est essentiel avant de se lancer dans les expériences. Cet article va décrire les meilleures pratiques pour évaluer les systèmes ML tout en gardant un ton léger.
Les bases : tâches et applications
Commençons par comprendre la différence entre une "tâche" et une "application". Une application, c'est un scénario d'utilisation spécifique pour un système ML. Par exemple, pense à la vérification de locuteurs comme une tâche. Dans cette tâche, il y a différentes applications, comme vérifier l'identité de quelqu'un ou déterminer si une voix correspond à un enregistrement.
Le truc, c'est que l'application détermine le type de données nécessaires et les Métriques qui comptent. Dans des applications judiciaires, le coût d'une mauvaise identification (faux positif) peut être bien plus élevé qu'une appli où ne pas identifier quelqu'un (faux négatif) pourrait être plus dommageable. Donc, deux applications sous la même tâche peuvent avoir des priorités différentes.
Comprendre les systèmes et méthodes
Ensuite, différencions les "systèmes" et les "méthodes". Un système est un modèle ML spécifique qui a été entraîné et est prêt à être utilisé. En revanche, une méthode se réfère à différentes façons d’entraîner ou d'améliorer ces systèmes.
Imagine que tu fais des cookies ! Si tu as une recette de cookie préférée (le système), tu pourrais vouloir tester différentes techniques de cuisson comme ajuster la température ou le temps de cuisson (les méthodes). Parfois, tu veux savoir comment ta recette originale va tourner. D'autres fois, tu veux expérimenter de nouvelles techniques pour rendre tes cookies encore meilleurs. Cette différence peut influencer la façon dont les données sont gérées et comment les résultats sont calculés.
Division des données
Dans le ML, c'est courant de diviser les données en trois ensembles principaux : entraînement, développement et évaluation.
- Ensemble d'entraînement : C'est là où le modèle apprend ses paramètres.
- Ensemble de développement : Cela aide à peaufiner la conception du modèle en prenant des décisions sur les caractéristiques ou les réglages.
- Ensemble d'évaluation : Le moment de vérité, où la performance finale du modèle est testée.
L'ensemble d'évaluation est crucial parce que ses résultats devraient prédire comment le modèle va performer dans la vraie vie. Idéalement, les données d'évaluation devraient ressembler à ce que le modèle va rencontrer quand il sera réellement utilisé.
Par exemple, si le modèle est censé fonctionner avec des voix de différents environnements, les données d'évaluation devraient inclure des enregistrements similaires. Si tu entraînes le modèle avec un groupe spécifique de locuteurs, l'évaluation devrait avoir des locuteurs différents pour s'assurer qu'il peut bien généraliser.
Éviter les erreurs courantes
Quand tu mets en place l'évaluation, il y a quelques pièges communs à éviter, car ils peuvent mener à des résultats trop optimistes.
-
Ne pas utiliser les mêmes données pour le développement et l'évaluation : Utiliser l'ensemble d'évaluation pendant le développement peut donner l'impression que la performance est meilleure qu'elle ne l'est. C'est comme essayer de gagner un jeu en t'entraînant contre toi-même : sûr, tu pourrais bien jouer, mais la vraie compétition est là dehors !
-
Fais attention à la division des données : Si tu sépares tes données au hasard après avoir fait des changements (comme de l'augmentation ou de l'upsampling), tu pourrais finir avec des échantillons identiques dans différents ensembles. Imagine couper une tarte et réaliser que la moitié des morceaux sont les mêmes.
-
Attention aux corrélations trompeuses : Parfois, le modèle peut capter des schémas qui ne devraient pas compter. Si les données d'entraînement et d'évaluation proviennent de la même source, le modèle peut apprendre ces schémas trompeurs, menant à de mauvaises performances sur de nouvelles données.
En suivant ces conseils, tu peux éviter de prendre des décisions qui pourraient nuire à ton évaluation.
Choisir les bonnes métriques
Un des plus grands défis dans l'évaluation des systèmes ML est de choisir la bonne métrique de performance. C'est comme choisir le bon outil pour un job ; utiliser un marteau quand tu devrais utiliser un tournevis ne sera pas bon !
Les métriques devraient refléter comment un utilisateur va vivre le système. Pour les tâches de classification (où la sortie est une catégorie), il est essentiel d'évaluer à quel point ces décisions catégoriques sont précises. La surface sous la courbe (AUC) ou le taux d'erreur égal (EER) sont des exemples de métriques, mais elles pourraient ne pas refléter précisément l'expérience utilisateur puisque elles ne tiennent pas compte de la manière dont les décisions sont prises.
Au lieu de cela, il est souvent mieux d'utiliser des métriques de coût attendu qui attribuent des coûts à différents types d'erreurs. Comme ça, tu peux comprendre comment le modèle va performer dans un scénario du monde réel.
Pour les problèmes multi-classes, il est conseillé d'éviter de combiner des métriques binaires de manière indiscriminée. Reste plutôt avec la métrique de coût attendu, qui peut être ajustée à la tâche.
Évaluation des prédictions séquentielles
Dans des tâches comme la reconnaissance automatique de la parole (ASR) ou le scoring de prononciation, l'objectif est de faire correspondre des séquences d'unités prédites avec les bonnes. Ça peut être compliqué, surtout si les prédictions ont des longueurs variées.
Le "dynamic time warping" est une méthode utilisée pour aligner ces séquences et mesurer leurs similarités. Cependant, il est souvent préférable d'utiliser des métriques comme le taux d'erreur de mots (WER) au lieu de la seule précision, car la précision peut être trompeuse s'il y a beaucoup d'unités supplémentaires prédites.
Gérer les probabilités de classes
Dans certains scénarios, la logique de décision peut ne pas être connue à l'avance, surtout en développant des modèles pour des tâches générales sans application spécifique en tête. Dans ces cas, le modèle devrait produire des probabilités, permettant de prendre des décisions plus tard.
Mesurer la qualité de ces probabilités est crucial. Utiliser des règles de scoring appropriées comme le score de Brier peut garantir que les sorties de probabilité sont fiables et peuvent mener à de bonnes décisions par la suite.
Tâches de régression
Pour les tâches de régression, il est essentiel de considérer comment l'utilisateur final perçoit les différences entre les valeurs prédites et réelles. Des métriques comme l'erreur absolue moyenne (MAE) ou l'erreur quadratique moyenne (MSE) entrent en jeu ici, mais le choix dépend du contexte spécifique de l'application.
Normaliser les métriques de performance
Quand tu rapportes la performance d'un modèle, c'est pratique d'avoir un point de référence pour comparer. Par exemple, si tu as une tâche de classification, savoir comment une supposition naïve (comme toujours deviner la classe majoritaire) performe peut être utile.
Un coût attendu normalisé (NEC) peut être un excellent moyen de mesurer la performance tout en tenant compte de la façon dont des suppositions naïves s'en sortiraient. Comme ça, tu peux voir si ton modèle est vraiment meilleur ou juste légèrement supérieur à une supposition.
Garder un œil sur les erreurs courantes dans les métriques
Quelques erreurs courantes avec les métriques incluent :
-
Utiliser la précision avec des données déséquilibrées peut induire en erreur les évaluations de performance. Un coût attendu normalisé est une meilleure option ici.
-
Oublier de fournir une valeur de référence pour la précision peut mener à une vision exagérée des capacités d'un modèle.
-
Utiliser des métriques de calibration sans aborder la qualité réelle des prédictions peut créer un faux sentiment de sécurité.
Intervalles de confiance : le filet de sécurité
Une fois que tu as choisi tes données d'évaluation et tes métriques, il est crucial de considérer à quel point les résultats pourraient changer à cause de facteurs aléatoires. Pour cela, utiliser des intervalles de confiance peut fournir une gamme de performances attendues basées sur la variabilité dans l'évaluation.
Le bootstrapping est une technique souvent utilisée à cette fin. Cela te permet de tirer des échantillons de tes données d'évaluation plusieurs fois pour mieux comprendre la variabilité. Cela peut te donner une idée de la confiance que tu peux avoir dans tes résultats.
Évaluer les systèmes vs. méthodes
Quand tu compares différents systèmes, les intervalles de confiance peuvent aider à déterminer lequel pourrait mieux performer dans la pratique. Si le système A montre une meilleure performance que le système B, tu devrais te demander si cette différence est vraiment significative ou juste le résultat du hasard.
Lors de l'évaluation des méthodes, il est également essentiel de réaliser plusieurs essais en utilisant différentes graines aléatoires. Comme ça, tu peux voir si les avantages d'une méthode sont solides ou juste des coups de chance.
Conclusion : La morale
Évaluer efficacement les systèmes d'apprentissage automatique n'est pas juste une case à cocher ; c'est essentiel pour obtenir des résultats significatifs. En établissant un bon processus d'évaluation, en choisissant des métriques appropriées et en tenant compte des intervalles de confiance, tu peux construire des modèles qui vont vraiment bien performer dans le monde réel.
Alors, la prochaine fois que tu évalues un système ML, souviens-toi : ce n'est pas juste une question de métriques de performance brillantes ou d'algorithmes cool ; il s'agit de s'assurer que ton modèle est prêt pour le monde réel. Après tout, personne ne veut servir des cookies mal cuits !
Source originale
Titre: Good practices for evaluation of machine learning systems
Résumé: Many development decisions affect the results obtained from ML experiments: training data, features, model architecture, hyperparameters, test data, etc. Among these aspects, arguably the most important design decisions are those that involve the evaluation procedure. This procedure is what determines whether the conclusions drawn from the experiments will or will not generalize to unseen data and whether they will be relevant to the application of interest. If the data is incorrectly selected, the wrong metric is chosen for evaluation or the significance of the comparisons between models is overestimated, conclusions may be misleading or result in suboptimal development decisions. To avoid such problems, the evaluation protocol should be very carefully designed before experimentation starts. In this work we discuss the main aspects involved in the design of the evaluation protocol: data selection, metric selection, and statistical significance. This document is not meant to be an exhaustive tutorial on each of these aspects. Instead, the goal is to explain the main guidelines that should be followed in each case. We include examples taken from the speech processing field, and provide a list of common mistakes related to each aspect.
Auteurs: Luciana Ferrer, Odette Scharenborg, Tom Bäckström
Dernière mise à jour: 2024-12-04 00:00:00
Langue: English
Source URL: https://arxiv.org/abs/2412.03700
Source PDF: https://arxiv.org/pdf/2412.03700
Licence: https://creativecommons.org/licenses/by/4.0/
Changements: Ce résumé a été créé avec l'aide de l'IA et peut contenir des inexactitudes. Pour obtenir des informations précises, veuillez vous référer aux documents sources originaux dont les liens figurent ici.
Merci à arxiv pour l'utilisation de son interopérabilité en libre accès.