Les tests permettent de rendre un projet viable. Il s'agit d'hypothèses testables et reproductibles. Lorsque vous effectuez des tests, l'objectif est d'apporter des améliorations continues et incrémentielles en évaluant diverses architectures et fonctionnalités de modèle. Lorsque vous effectuez des tests, procédez comme suit:
Déterminer les performances de référence Commencez par établir une métrique de référence. La référence sert de référence pour comparer les tests.
Dans certains cas, la solution actuelle sans ML peut fournir la première métrique de référence. Si aucune solution n'existe actuellement, créez un modèle de ML avec une architecture simple, quelques fonctionnalités et utilisez ses métriques comme référence.
Apportez de petites modifications ponctuelles. Ne faites qu'un seul petit changement à la fois, par exemple au niveau des hyperparamètres, de l'architecture ou des fonctionnalités. Si le changement améliore le modèle, les métriques de ce modèle deviennent la nouvelle référence à laquelle comparer les futurs tests.
Voici des exemples d'expérimentations qui ne comportent qu'une seule petite modification:
- inclure la fonctionnalité X ;
- utilisez un taux de persévérance de 0,5 pour la première couche cachée.
- effectuez la transformation logarithmique de la caractéristique Y.
- définissez le taux d'apprentissage sur 0,001.
Enregistrez la progression des tests. Vous devrez probablement effectuer de nombreux tests. Les tests dont la qualité de prédiction est médiocre (ou neutre) par rapport à la référence restent utiles à suivre. Ils indiquent les approches qui ne fonctionneront pas. Étant donné que la progression est généralement non linéaire, il est important de montrer que vous travaillez sur le problème en mettant en évidence toutes les solutions que vous avez trouvées qui ne fonctionnent pas, en plus de votre progression dans l'amélioration de la qualité de référence.
Étant donné que chaque entraînement complet sur un ensemble de données réel peut prendre des heures (ou des jours), envisagez d'exécuter plusieurs expériences indépendantes simultanément pour explorer l'espace rapidement. À mesure que vous continuerez à itérer, vous devriez vous rapprocher de plus en plus du niveau de qualité dont vous aurez besoin pour la production.
Bruit dans les résultats des tests
Notez que vous pouvez rencontrer du bruit dans les résultats expérimentaux qui ne proviennent pas de modifications apportées au modèle ou aux données, ce qui rend difficile de déterminer si une modification que vous avez apportée a réellement amélioré le modèle. Voici des exemples de facteurs pouvant générer du bruit dans les résultats expérimentaux:
Mélange des données: l'ordre dans lequel les données sont présentées au modèle peut affecter ses performances.
Initialisation des variables: la manière dont les variables du modèle sont initialisées peut également affecter ses performances.
Parallélisme asynchrone: si le modèle est entraîné à l'aide du parallélisme asynchrone, l'ordre dans lequel les différentes parties du modèle sont mises à jour peut également affecter ses performances.
Ensembles d'évaluation de petite taille: si l'ensemble d'évaluation est trop petit, il risque de ne pas être représentatif des performances globales du modèle, ce qui entraîne des variations inégales de la qualité du modèle.
Exécuter un test plusieurs fois permet de confirmer les résultats du test.
S'aligner sur les pratiques d'expérimentation
Votre équipe doit avoir une compréhension claire de ce qu'est exactement une "expérimentation", avec un ensemble défini de pratiques et d'artefacts. Vous devez fournir les documents suivants:
Artefacts Quels sont les artefacts d'un test ? Dans la plupart des cas, un test est une hypothèse testée qui peut être reproduite, généralement en enregistrant les métadonnées (telles que les fonctionnalités et les hyperparamètres) qui indiquent les changements entre les tests et leur impact sur la qualité du modèle.
Bonnes pratiques de codage Est-ce que chacun utilisera ses propres environnements expérimentaux ? Sera-t-il possible (ou facile) d'unifier le travail de chacun dans des bibliothèques partagées ?
Reproductibilité et suivi. Quelles sont les normes de reproductibilité ? Par exemple, l'équipe doit-elle utiliser le même pipeline de données et les mêmes pratiques de gestion des versions, ou est-il acceptable de n'afficher que des graphiques ? Comment les données expérimentales seront-elles enregistrées: en tant que requêtes SQL ou en tant qu'instantanés de modèle ? Où les journaux de chaque test seront-ils documentés: dans un document, une feuille de calcul ou un CMS pour la gestion des tests ?
Prédictions incorrectes
Aucun modèle du monde réel n'est parfait. Comment votre système gérera-t-il les prédictions incorrectes ? Commencez à réfléchir tôt à la façon de les gérer.
Une stratégie basée sur les bonnes pratiques encourage les utilisateurs à étiqueter correctement les prédictions incorrectes. Par exemple, les applications de messagerie enregistrent les e-mails mal classés en enregistrant les e-mails que les utilisateurs déplacent dans leur dossier de spam, et inversement. En capturant des étiquettes de vérité terrain auprès des utilisateurs, vous pouvez concevoir des boucles de rétroaction automatisées pour la collecte de données et le réentraînement du modèle.
Notez que, bien que les enquêtes intégrées à l'interface utilisateur recueillent les commentaires des utilisateurs, les données sont généralement qualitatives et ne peuvent pas être intégrées aux données de réapprentissage.
Implémenter une solution de bout en bout
Pendant que votre équipe teste le modèle, il est recommandé de commencer à développer des parties du pipeline final (si vous disposez des ressources nécessaires).
Établir différentes parties du pipeline (comme l'ingestion de données et le réentraînement du modèle) facilite le passage du modèle final en production. Par exemple, obtenir un pipeline de bout en bout pour l'ingestion de données et la diffusion de prédictions peut aider l'équipe à commencer à intégrer le modèle dans le produit et à effectuer des tests utilisateur à un stade précoce.
Résoudre les problèmes liés aux projets bloqués
Il peut arriver que la progression d'un projet stagne. Peut-être que votre équipe travaille sur un test prometteur, mais qu'elle n'arrive pas à améliorer le modèle depuis des semaines. Que devez-vous faire ? Voici quelques approches possibles:
Phase stratégique. Vous devrez peut-être repenser le problème. Après avoir passé du temps dans la phase d'expérimentation, vous comprenez probablement mieux le problème, les données et les solutions possibles. Avec une connaissance plus approfondie du domaine, vous pouvez probablement définir le problème plus précisément.
Par exemple, vous souhaitiez peut-être initialement utiliser la régression linéaire pour prédire une valeur numérique. Malheureusement, les données n'étaient pas assez bonnes pour entraîner un modèle de régression linéaire viable. Une analyse plus approfondie peut révéler que le problème peut être résolu en prédisant si un exemple est supérieur ou inférieur à une valeur spécifique. Vous pouvez ainsi reformuler le problème en problème de classification binaire.
Si la progression est plus lente que prévu, ne vous découragez pas. Des améliorations incrémentielles au fil du temps peuvent être la seule solution pour résoudre le problème. Comme indiqué précédemment, n'attendez pas le même niveau de progression d'une semaine à l'autre. Obtenir une version prête à la production d'un modèle nécessite souvent beaucoup de temps. L'amélioration du modèle peut être irrégulière et imprévisible. Les périodes de progression lente peuvent être suivies d'une amélioration soudaine, ou l'inverse.
Technique Passez du temps à diagnostiquer et à analyser les prédictions incorrectes. Dans certains cas, vous pouvez identifier le problème en isolant quelques prédictions incorrectes et en diagnostiquant le comportement du modèle dans ces instances. Par exemple, vous pouvez découvrir des problèmes liés à l'architecture ou aux données. Dans d'autres cas, obtenir plus de données peut vous aider. Vous pouvez obtenir un signal plus clair qui suggère que vous êtes sur la bonne voie, ou il peut produire plus de bruit, ce qui indique que d'autres problèmes existent dans l'approche.
Si vous travaillez sur un problème qui nécessite des ensembles de données étiquetés manuellement, il peut être difficile d'obtenir un ensemble de données étiqueté pour l'évaluation du modèle. Trouvez des ressources pour obtenir les ensembles de données dont vous avez besoin pour l'évaluation.
Il est possible qu'aucune solution ne soit possible. Limitez votre approche dans le temps et arrêtez-vous si vous n'avez pas progressé dans le délai imparti. Toutefois, si vous disposez d'une énoncée de problème solide, elle mérite probablement une solution.