Systèmes de ML de production : dépendances des données

Les données sont aussi importantes pour les développeurs de ML que l'est le code pour les programmeurs traditionnels. Cette leçon est consacrée aux types de questions que vous devez vous poser au sujet de vos données.

Dépendances des données

  • Les données d'entrées (caractéristiques) déterminent le comportement des systèmes de ML.
    • Nous concevons des tests unitaires pour les bibliothèques de logiciels, mais qu'en est-il des données ?
  • Il est important de choisir les signaux d'entrée avec soin.
    • Avec peut-être encore plus de soin que pour déterminer les bibliothèques de logiciels desquelles dépendre ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Pouvez-vous le savoir ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Pouvez-vous le savoir ?
  • Gestion des versions
    • Le système qui calcule ce signal change-t-il ? À quelle fréquence ? Que peut-il se passer ?
  • Fiabilité
    • Que se passe-t-il lorsque le signal n'est pas disponible ? Pouvez-vous le savoir ?
  • Gestion des versions
    • Le système qui calcule ce signal change-t-il ? À quelle fréquence ? Que peut-il se passer ?
  • Nécessité
    • L'utilité du signal justifie-t-elle le coût de l'inclusion de celui-ci ?
  • Corrélations
    • Certains de mes signaux d'entrée sont-ils liés entre eux au point de nécessiter des stratégies supplémentaires pour les séparer ?
  • Corrélations
    • Certains de mes signaux d'entrée sont-ils liés entre eux au point de nécessiter des stratégies supplémentaires pour les séparer ?
  • Boucles de rétroaction
    • Parmi mes signaux d'entrée, lesquels peuvent être influencés par les sorties de mon modèle ?

Le comportement d'un système de ML dépend du comportement et des qualités de ses caractéristiques d'entrée. Le modèle change à mesure que les données d'entrée pour ces caractéristiques changent. Parfois ce changement est souhaitable, parfois il ne l'est pas.

Dans le développement de logiciel classique, vous vous concentrez davantage sur le code que sur les données. Dans le développement du Machine Learning, bien que le code fasse toujours partie de votre travail, vous devez avoir une vision plus large et inclure les données. Par exemple, dans les projets de développement de logiciel classiques, une bonne pratique consiste à concevoir des tests unitaires pour vérifier votre code. Pour les projets de ML, vous devez également tester, vérifier et surveiller en continu vos données d'entrée.

Par exemple, vous devez surveiller en permanence votre modèle afin de supprimer les caractéristiques peu ou pas utilisées. Supposons une caractéristique dont la contribution au modèle est faible, voire nulle. Si les données d'entrée pour cette caractéristique changent subitement, le comportement de votre modèle peut également changer subitement de façon 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 ? Par exemple :
  • Le signal provient-il d'un serveur qui plante en cas de forte charge ?
  • Le signal provient-il de personnes qui partent toujours en vacances au mois d'août ?

Gestion des versions

Voici quelques 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 saurez-vous quand ce système change ?

Parfois, les données sont issues d'un processus en amont. Si ce processus change soudainement, votre modèle peut en être affecté.

Envisagez de créer votre propre copie des données que vous recevez du processus en amont. Ne passez à la version suivante des données en amont que si vous êtes certain que cela ne posera pas de problème.

Nécessité

La question suivante peut vous rappeler la régularisation :

  • L'utilité de la caractéristique justifie-t-elle le coût de son inclusion ?

Il est toujours tentant d'ajouter des caractéristiques au modèle. Par exemple, supposez que vous trouviez une caractéristique dont l'ajout améliore légèrement la justesse de votre modèle. Une amélioration de la justesse est a priori une bonne idée. Toutefois, vous venez de compliquer la maintenance du modèle. Comme cette caractéristique supplémentaire peut se détériorer de manière inattendue, vous devez la surveiller. Réfléchissez donc bien avant d'ajouter des caractéristiques conduisant à des gains minimes à 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 :

  • Certaines de mes caractéristiques sont-elles liées entre elles au point de nécessiter des stratégies supplémentaires pour les séparer ?

Boucles de rétroaction

Parfois, un modèle peut avoir une incidence sur ses propres données d'apprentissage. Par exemple, les sorties de certains modèles peuvent être à leur tour, directement ou indirectement, des caractéristiques d'entrée de ces mêmes modèles.

Parfois, un modèle peut avoir une incidence sur un autre modèle. Soit, par exemple, deux modèles de prédiction du cours d'actions :

  • Le modèle A, qui est un modèle prédictif peu performant.
  • Le modèle B.

Le modèle A étant médiocre, il décide par erreur d'acheter des actions de la société X. Ces achats font monter le cours de l'action X. Le modèle B utilisant le cours de l'action X comme caractéristique d'entrée, il peut facilement aboutir à des conclusions erronées quant à 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 cours des actions de la société X.