Les tests permettent d'améliorer la viabilité d'un projet. Ce sont des hypothèses testables et reproductibles. Lors de l'exécution des tests, l'objectif est d'apporter des améliorations continues et incrémentielles en évaluant diverses architectures de modèle et fonctionnalités. Lorsque vous effectuez des tests, procédez comme suit:
Déterminez vos performances de référence. Commencez par établir une métrique de référence. La référence sert de jauge de mesure pour comparer les tests.
Dans certains cas, la solution actuelle, autre que le ML, peut fournir la première métrique de référence. S'il n'existe actuellement aucune solution, créez un modèle de ML avec une architecture simple et quelques fonctionnalités, puis utilisez ses métriques comme référence.
Effectuez de petites modifications uniques. N'apportez qu'une seule modification mineure à la fois, par exemple les hyperparamètres, l'architecture ou les fonctionnalités. Si la modification 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 de tests n'apportant qu'une seule modification mineure:
- inclure la fonctionnalité X.
- utiliser un abandon de 0,5 sur la première couche cachée.
- Prenons la transformation logarithmique de la caractéristique Y.
- définir le taux d'apprentissage sur 0,001.
Enregistrez la progression des tests. Vous devrez sans doute réaliser de nombreux tests. Il est toujours utile de suivre les tests dont la qualité de prédiction est médiocre (ou neutre) par rapport à la référence. Elles signalent quelles approches 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 soulignant toutes les raisons qui ne fonctionnent pas, en plus de vos progrès 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 (voire des jours), envisagez d'exécuter plusieurs tests indépendants simultanément pour explorer rapidement l'espace. Au fur et à mesure des itérations, vous devriez vous rapprocher du niveau de qualité dont vous avez besoin pour la production.
Bruit dans les résultats expérimentaux
Notez que vous pouvez rencontrer du bruit dans les résultats expérimentaux ne provenant pas des modifications du modèle ou des données. Il sera donc difficile de déterminer si une modification que vous avez apportée a réellement amélioré le modèle. Voici des exemples d'éléments qui peuvent produire du bruit dans les résultats expérimentaux:
Brassage 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 de parallélisme asynchrone, l'ordre dans lequel les différentes parties du modèle sont mises à jour peut également affecter ses performances.
Petits ensembles d'évaluation: un ensemble d'évaluation trop petit peut ne pas être représentatif des performances globales du modèle, ce qui peut entraîner des variations inégales de la qualité du modèle.
Effectuer un test plusieurs fois permet de confirmer les résultats.
Alignez-vous sur les pratiques d'expérimentation
Votre équipe doit avoir une compréhension claire de ce qu'est exactement un "test", avec un ensemble défini de pratiques et d'artefacts. Vous aurez besoin d'une documentation décrivant les éléments suivants:
Artefacts. Quels sont les artefacts d'une expérience ? 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 caractéristiques et les hyperparamètres) qui indiquent les changements entre les tests et leur impact sur la qualité du modèle.
Pratiques de codage. Chacun utilisera-t-il son propre environnement d'expérimentation ? Dans quelle mesure 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 peut-elle n'afficher que des tracés ? Comment les données expérimentales seront-elles enregistrées: sous forme de requêtes SQL ou d'instantanés de modèle ? Où les journaux de chaque expérience seront-ils documentés: dans un document, une feuille de calcul ou un CMS pour gérer les expériences ?
Prédictions erronées
Dans le monde réel, aucun modèle n'est parfait. Comment votre système va-t-il gérer les prédictions erronées ? Commencez à réfléchir dès le début à la façon de les gérer.
Une stratégie basée sur les bonnes pratiques encourage les utilisateurs à étiqueter correctement les prédictions erronées. Par exemple, les applications de messagerie enregistrent les e-mails mal classés en consignant les messages que les utilisateurs déplacent dans leur dossier de spam, et inversement. En capturant les étiquettes de vérité terrain des utilisateurs, vous pouvez concevoir des boucles de rétroaction automatisées pour la collecte des données et le réentraînement des modèles.
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éentraînement.
Implémenter une solution de bout en bout
Pendant que votre équipe expérimente le modèle, il est judicieux de commencer à construire des parties du pipeline final (si vous disposez des ressources nécessaires).
La création des différentes parties du pipeline, telles que la collecte de données et le réentraînement du modèle, facilite le passage du modèle final en production. Par exemple, l'obtention d'un pipeline de bout en bout pour l'ingestion de données et la diffusion des prédictions peut aider l'équipe à commencer à intégrer le modèle dans le produit et à effectuer les premiers tests utilisateur à un stade précoce.
Résoudre les problèmes liés aux projets bloqués
Vous pourriez vous trouver dans des scénarios où l’avancement d’un projet s’interrompt. Peut-être que votre équipe a travaillé sur un test prometteur, mais qu'elle n'a pas réussi à améliorer le modèle depuis des semaines. Que devez-vous faire ? Voici quelques approches possibles:
Phase stratégique. Vous devrez peut-être recadrer le problème. Après avoir passé du temps en phase de tests, vous comprenez probablement mieux le problème, les données et les solutions possibles. Avec une connaissance plus approfondie du domaine, vous pouvez probablement encadrer le problème plus précisément.
Par exemple, vous souhaitez peut-être utiliser la régression linéaire pour prédire une valeur numérique. Malheureusement, les données ne sont pas suffisantes pour entraîner un modèle de régression linéaire viable. Une analyse plus poussée révèle peut-être que le problème peut être résolu en prédisant si un exemple est supérieur ou inférieur à une valeur spécifique. Cela vous permet de recadrer le problème sous la forme d'une classification binaire.
Si la progression est plus lente que prévu, n’abandonnez pas. Des améliorations progressives au fil du temps peuvent être le seul moyen de résoudre le problème. Comme indiqué précédemment, ne vous attendez pas à voir le même niveau de progression d'une semaine à l'autre. Souvent, l'obtention d'une version de modèle prête pour la production prend beaucoup de temps. L'amélioration du modèle peut être irrégulière et imprévisible. Des périodes de lenteur peuvent être suivies de pics d'amélioration, ou inversement.
Technique. Prenez le temps de diagnostiquer et d'analyser les prédictions erronées. Dans certains cas, vous pouvez identifier le problème en isolant quelques prédictions erronées et en diagnostiquant le comportement du modèle dans ces instances. Par exemple, vous pouvez identifier des problèmes liés à l'architecture ou aux données. Dans d'autres cas, obtenir plus de données peut aider. Vous pouvez obtenir un signal plus clair indiquant que vous êtes sur la bonne voie ou produire plus de bruit, indiquant d'autres problèmes dans l'approche.
Si vous travaillez sur un problème nécessitant des ensembles de données étiquetés manuellement, il peut être difficile d'obtenir un ensemble de données étiquetées pour l'évaluation du modèle. Trouvez des ressources pour obtenir les ensembles de données dont vous aurez besoin pour l'évaluation.
Peut-être qu’aucune solution n’est possible. Encadrez votre approche dans le temps, en vous arrêtant si vous n'avez pas fait de progrès dans les délais impartis. Cependant, si vous avez un énoncé de problème cohérent, alors il mérite probablement une solution.