Dépendances des données

Les données sont aussi importantes pour les développeurs de ML que le code pour les programmeurs traditionnels. Cette leçon se concentre sur les types de questions que vous devriez vous poser sur vos données.

Dépendances des données

  • Les données d'entrée (caractéristiques) déterminent le comportement du système de ML.
    • Nous écrivons des tests unitaires pour les bibliothèques de logiciels, mais qu'en est-il des données ?
  • Faites attention lorsque vous choisissez des signaux d'entrée.
    • Peut-être même plus que lorsque vous décidez quelles bibliothèques logicielles choisir ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Le sauriez-vous ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Le sauriez-vous ?
  • Gestion des versions
    • Le système qui calcule ce signal change-t-il ? À quelle fréquence ? Que se passerait-il ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Le sauriez-vous ?
  • Gestion des versions
    • Le système qui calcule ce signal change-t-il ? À quelle fréquence ? Que se passerait-il ?
  • Nécessité
    • L'utilité du signal justifie-t-elle le coût de son inclusion ?
  • Corrélations
    • Certains de mes signaux d'entrée sont-ils si liés que nous avons besoin de stratégies supplémentaires pour les séparer ?
  • Corrélations
    • Certains de mes signaux d'entrée sont-ils si liés que nous avons besoin de stratégies supplémentaires pour les séparer ?
  • Boucles de rétroaction
    • Quels signaux d'entrée peuvent être affectés par les sorties de mon modèle ?

Résumé du cours vidéo

Le comportement d'un système de ML dépend du comportement et des qualités de ses caractéristiques d'entrée. Les données d'entrée pour ces caractéristiques changent également pour votre modèle. Parfois, ce n'est pas ce qu'il faut, mais parfois ce n'est pas le cas.

Dans le développement logiciel traditionnel, vous vous concentrez davantage sur le code que sur les données. Dans le développement du machine learning, bien que le codage fasse toujours partie de votre travail, vous devez élargir votre champ de vision pour inclure les données. Par exemple, dans des projets de développement de logiciels traditionnels, il est recommandé d'écrire des tests unitaires pour valider votre code. Sur les projets de ML, vous devez également tester, vérifier et surveiller vos données d'entrée en continu.

Par exemple, vous devez surveiller en permanence votre modèle pour supprimer les caractéristiques inutilisées (ou peu utilisées). Imaginez une caractéristique qui n'a apporté que peu, voire rien, au modèle. Si les données d'entrée pour cette caractéristique changent brusquement, le comportement de votre modèle peut également changer brusquement de manière indésirable.

Fiabilité

Voici quelques questions à vous poser sur la fiabilité de vos données d'entrée:

  • Le signal sera-t-il toujours disponible ou provient-il d'une source non fiable ? Exemple :
    • Le signal provient-il d'un serveur qui plante en cas de charge importante ?
    • Le signal provient-il de personnes qui partent en vacances chaque année ?

Gestion des versions

Questions à vous poser sur la gestion des versions:

  • Le système qui calcule ces données change-t-il ? Si oui :
    • À quelle fréquence ?
    • Comment savoir quand ce système change ?

Parfois, les données proviennent d'un processus en amont. Si ce processus change brusquement, votre modèle peut en pâtir.

Envisagez de créer votre propre copie des données que vous recevez du processus en amont. Ensuite, n'accédez à la version suivante des données en amont que si vous êtes certain que cela ne présente aucun risque.

Nécessité

La question suivante peut vous rappeler la régularisation:

  • L'utilité de cette fonctionnalité justifie-t-elle le coût de son intégration ?

Il est toujours tentant d'ajouter des caractéristiques au modèle. Par exemple, supposons que vous trouviez une nouvelle caractéristique dont l'ajout améliore légèrement la précision du modèle. Une plus grande justesse est a priori une bonne idée. Cependant, vous venez d'augmenter votre charge de maintenance. Cette fonctionnalité supplémentaire pourrait se dégrader de manière inattendue. Vous devez donc la surveiller. Réfléchissez bien avant d'ajouter des caractéristiques qui mènent à de petites victoires à court terme.

Corrélations

Certaines caractéristiques sont corrélées (positivement ou négativement) avec d'autres caractéristiques. Posez-vous la question suivante:

  • Disposez-vous de fonctionnalités si liées que vous avez besoin de stratégies supplémentaires pour les séparer ?

Boucles de rétroaction

Parfois, un modèle peut affecter ses propres données d'entraînement. Par exemple, les résultats de certains modèles sont eux-mêmes des caractéristiques d'entrée directement ou indirectement au même modèle.

Parfois, un modèle peut affecter un autre modèle. Prenons l'exemple de deux modèles de prédiction du cours d'une action:

  • Le modèle A, qui est un mauvais modèle prédictif.
  • Modèle B.

Le modèle A présentant un bug, il décide par erreur d'acheter des actions en bourse X. Ces achats font augmenter le cours de l'action X. Le modèle B utilise le cours de l'action X comme caractéristique d'entrée. Il peut donc facilement conclure à de fausses conclusions sur la valeur de l'action X. Le modèle B pourrait donc acheter ou vendre des actions de la société X en se basant sur le comportement problématique du modèle A. Le comportement du modèle B peut à son tour affecter le modèle A, ce qui risque de déclencher une tulipomanie ou une chute du stock de la société X.