Préparation et traitement des données De Mosaïque AutoML

Cet article décrit comment Mosaïque AutoML prépare les données pour l’apprentissage automatique et décrit les paramètres de données configurables. Vous pouvez ajuster ces options durant la configuration de l’expérience dans l’IU AutoML. Pour configurer ces paramètres à l’aide de l’API AutoML), consultez les informations de référence sur l’API Python AutoML.

Types de fonctionnalités de données pris en charge

Les types de fonctionnalités n’étant pas répertoriés ci-dessous ne sont pas pris en charge. Par exemple, les images ne sont pas prises en charge.

Seuls les types de fonctionnalités suivants sont pris en charge :

• Numerique ( ByteType, ShortType, IntegerType, LongType, FloatType , et DoubleType)
• Boolean
• Chaîne (texte catégorique ou anglais)
• Horodatages (TimestampType, DateType)
• ArrayType [Numeric] (Databricks Runtime 10.4 LTS ML et versions ultérieures)
• DecimalType (Databricks Runtime 11.3 LTS ML et versions ultérieures)

Sélection de colonnes

Dans Databricks Runtime 10.3 ML et versions ultérieures, vous pouvez spécifier les colonnes que AutoML doit utiliser pour l’apprentissage. Pour exclure une colonne de l’IU, décochez-la dans la colonne Inclure. Dans l’API, utilisez le paramètre exclude_cols. Pour plus d’informations, consultez la référence de l’API Python Mosaïque AutoML.

Vous ne pouvez pas supprimer la colonne sélectionnée en tant que cible de prédiction ou en tant que colonne de temps pour fractionner les données.

Les colonnes de jointure sont incluses par défaut.

Imputer des valeurs manquantes

Dans Databricks Runtime 10.4 LTS ML et versions ultérieures, vous pouvez spécifier la manière dont les valeurs null sont imputées. Dans l’interface utilisateur, sélectionnez une méthode dans la liste déroulante dans la colonne Imputer avec dans le schéma de table. Dans l’API, utilisez le paramètre imputers. Pour plus d’informations, consultez la référence de l’API Python Mosaïque AutoML.

Par défaut, AutoML sélectionne une méthode d’imputation en fonction du type et du contenu de la colonne.

Fractionner les données en jeux de formation, de validation et de test

AutoML fractionne vos données en trois parties à des fins de formation, de validation et de test. Selon le type de problème ML, vous disposez de différentes options pour le fractionnement des données.

Fractionner les données pour la régression et la classification

Utilisez les méthodes suivantes pour diviser les données en jeux de formation, de validation et de test pour les tâches de régression et de classification :

(Par défaut) Fractionnement aléatoire : si aucune stratégie de fractionnement des données n’est spécifiée, le jeu de données est fractionné de manière aléatoire en étant composé à 60 % de formation, 20 % de validation et 20 % de test. Pour la classification, un fractionnement aléatoire stratifié vérifie que chaque classe est représentée de manière adéquate dans les jeux de formation, de validation et de test.

Fractionnement chronologique : dans Databricks Runtime 10.4 LTS ML et versions ultérieures, vous pouvez sélectionner une colonne de temps en créant des fractionnements chronologiques d’apprentissage, de validation et de test. Les fractionnements chronologiques utilisent les premiers points de données pour la formation, puis les premiers points suivants pour la validation et les derniers points pour le test. La colonne temps peut être un horodatage, un nombre entier ou une chaîne.

Fractionnement manuel : dans Databricks Runtime 15.3 ML et versions ultérieures, vous pouvez utiliser l’API pour configurer un fractionnement manuel. Spécifiez une colonne fractionnée et utilisez les valeurs train, validate ou test pour identifier les lignes que vous souhaitez utiliser pour la formation, la validation et les jeux de données de test. Toutes les lignes avec des valeurs de colonne fractionnées autres que train, testou validate sont ignorées et une alerte correspondante est déclenchée.

Fractionner les données pour la prévision

Pour les tâches de prévision, AutoML utilise la validation croisée de série chronologique. Cette méthode étend de façon incrémentielle le jeu de données de formation chronologiquement et effectue la validation sur les points de temps suivants. La validation croisée fournit une évaluation robuste des performances d’un modèle sur différents segments temporels. Elle garantit que le modèle de prévision est rigoureusement testé par rapport aux données futures invisibles, en conservant la pertinence et la précision des prédictions.

Le nombre de plis de validation croisée dépend des caractéristiques de la table d’entrée, par exemple le nombre de séries chronologiques, la présence de covariables et la longueur des séries chronologiques.

Échantillonnage de jeux de données volumineux

Bien qu’AutoML distribue les essais de réglage d’hyperparamètres sur les nœuds Worker d’un cluster, chaque modèle est entraîné sur un nœud Worker unique.

AutoML estime automatiquement la mémoire requise pour charger et entraîner votre jeu de données, et échantillonne le jeu de données si nécessaire.

Dans les versions allant de Databricks Runtime 9.1 LTS ML à Databricks Runtime 10.4 LTS ML, la fraction d’échantillonnage ne dépend pas du type de nœud du cluster ni de la quantité de mémoire sur chaque nœud.

Dans Databricks Runtime 11.x ML :

• La fraction d’échantillonnage augmente pour les nœuds Worker qui ont plus de mémoire par cœur. Vous pouvez augmenter la taille de l’échantillon en choisissant un type d’instance de Mémoire optimisée.
• Vous pouvez augmenter davantage la taille de l’échantillon en choisissant une valeur plus importante pour spark.task.cpus dans la configuration Spark du cluster. Le paramètre par défaut est 1 ; la valeur maximale est le nombre de processeurs dans le nœud Worker. Lorsque vous augmentez cette valeur, la taille de l’échantillon est supérieure, mais moins d’essais s’exécutent en parallèle. Par exemple, sur une machine avec quatre cœurs et un total de 64 Go de RAM, le spark.task.cpus=1 par défaut exécute quatre essais par Worker, chaque essai étant limité à 16 Go de RAM. Si vous définissez spark.task.cpus=4, chaque Worker n’exécute qu’un seul essai, mais cet essai peut utiliser 64 Go de RAM.

Dans Databricks Runtime 12.2 LTS ML et versions ultérieures, AutoML peut effectuer l’entraînement sur des jeux de données plus volumineux en allouant davantage de cœurs de processeur par tâche d’entraînement. Vous pouvez augmenter la taille de l’échantillon en choisissant une taille d’instance ayant une mémoire totale plus importante.

Dans Databricks Runtime 11.3 ML LTS et versions ultérieures, si AutoML a échantillonné le jeu de données, la fraction d’échantillonnage s’affiche sous l’onglet Vue d’ensemble de l’interface utilisateur.

Dans le cas des problèmes de classification, AutoML utilise la méthode sampleBy de PySpark pour l’échantillonnage stratifié afin de préserver la distribution des étiquettes cibles.

Dans le cas des problèmes de régression, AutoML utilise la méthode sample de PySpark.

Prise en charge de jeux de données déséquilibrés pour résoudre des problèmes de classification

Dans Databricks Runtime 11.3 LTS ML et versions ultérieures, si AutoML détecte qu’un jeu de données est déséquilibré, il tente de réduire le déséquilibre du jeu de données d’entraînement en sous-échantillonnant les classes principales et en ajoutant des pondérations de classe. AutoML équilibre uniquement le jeu de données d’entraînement, et n’équilibre pas les jeux de données de test et de validation. Cela garantit que les performances du modèle sont toujours évaluées sur le jeu de données non enrichi avec la vraie distribution de classe d’entrée.

Pour équilibrer un jeu de données d’entraînement déséquilibré, AutoML utilise des pondérations de classe qui sont inversement liées au degré de sous-échantillonnage d’une classe donnée. Par exemple, si un jeu de données d’apprentissage de 100 échantillons comporte 95 échantillons appartenant à la classe A, et cinq échantillons appartenant à la classe B, AutoML réduit ce déséquilibre en baissant l’échantillonnage de la classe A à 70 échantillons, c’est-à-dire en réduisant l’échantillonnage de la classe A selon un rapport de 70/95 ou 0,736 tout en maintenant à 5 le nombre d’échantillons dans la classe B. Pour que le modèle final soit correctement étalonné et que la distribution de probabilité de la sortie du modèle soit identique à celle de l’entrée, AutoML met à l’échelle la pondération de classe de la classe A selon le ratio 1/0,736 ou 1,358, tout en maintenant à 1 la pondération de la classe B. AutoML utilise ensuite ces pondérations de classe comme paramètres dans l’entraînement du modèle pour que les échantillons de chaque classe soient pondérés de manière appropriée pendant l’entraînement du modèle.

Agrégation de séries chronologiques

Pour les problèmes de prévision, lorsqu’il existe plusieurs valeurs pour un horodatage dans une série chronologique, AutoML utilise la moyenne des valeurs.

Pour utiliser la somme à la place, modifiez le notebook de code source généré par les exécutions d’essai. Dans la cellule agréger les données par... , remplacez .agg(y=(target_col, "avg")) par .agg(y=(target_col, "sum")), comme indiqué ci-dessous :

group_cols = [time_col] + id_cols
df_aggregation = df_loaded \
  .groupby(group_cols) \
  .agg(y=(target_col, "sum")) \
  .reset_index() \
  .rename(columns={ time_col : "ds" })

Détection de type sémantique

Avec Databricks Runtime 9.1 LTS ML et les versions ultérieures, AutoML tente de détecter si les colonnes ont un type sémantique différent du type de données Spark ou Pandas dans le schéma de table. AutoML traite ces colonnes comme le type sémantique détecté. Ces détections sont effectuées au mieux, mais il arrive parfois que l’existence de types sémantiques ne soit pas détectée. Vous pouvez également définir manuellement le type sémantique d’une colonne ou indiquer à AutoML de ne pas appliquer la détection de type sémantique à une colonne à l’aide d’annotations.

Plus précisément, AutoML effectue ces ajustements :

• Les colonnes de type chaîne et entier représentant des données de date ou d’horodateur sont traitées en tant que type horodateur.
• Les colonnes de type chaîne qui représentent des données numériques sont traitées comme un type numérique.

Avec Databricks Runtime 10.1 ML et versions ultérieures, AutoML effectue également les réglages suivants :

• Les colonnes numériques qui contiennent des ID catégoriques sont traitées comme une caractéristique catégorique.
• Les colonnes de chaînes qui contiennent du texte anglais sont traitées comme une caractéristique de texte.

Annotations de type sémantique

Avec Databricks Runtime 10.1 ML et versions ultérieures, vous pouvez contrôler manuellement le type de sémantique assigné en plaçant une annotation de type sémantique sur une colonne. Pour annoter manuellement le type sémantique de colonne <column-name> en tant que <semantic-type> , utilisez la syntaxe suivante :

metadata_dict = df.schema["<column-name>"].metadata
metadata_dict["spark.contentAnnotation.semanticType"] = "<semantic-type>"
df = df.withMetadata("<column-name>", metadata_dict)

<semantic-type> peut s'agir d'une des méthodes suivantes :

• categorical: La colonne contient des valeurs catégoriques (par exemple, des valeurs numériques qui doivent être traitées comme des ID).
• numeric:La colonne contient des valeurs numériques (par exemple, des valeurs de chaîne qui peuvent être analysées en nombres).
• datetime:La colonne contient des valeurs timestamp (chaîne, numérique ou date qui peuvent être converties en horodateurs).
• text: La colonne de chaîne de caractères contient du texte en anglais.

Pour désactiver la détection de type sémantique sur une colonne, utilisez l’annotation native spéciale Keyword.

Intégration de Feature Store

Dans Databricks Runtime 11.3 LTS ML et les versions ultérieures, vous pouvez utiliser les tables de caractéristiques existantes dans Feature Store afin d’étendre le jeu de données d’entrée d’origine pour vos problèmes de classification et de régression.

Dans Databricks Runtime 12.2 LTS ML et les versions ultérieures, vous pouvez utiliser les tables de caractéristiques existantes dans Feature Store afin d’étendre le jeu de données d’entrée d’origine pour vos problèmes AutoML de classification, de régression et de prévision.

Pour créer une table de caractéristiques, consultez Ingénierie de caractéristiques et service.

Pour utiliser des tables de caractéristiques existantes, vous pouvez sélectionner des tables de caractéristiques avec l’IU AutoML ou définir le paramètre feature_store_lookups dans votre spécification d’exécution AutoML.

feature_store_lookups = [
  {
     "table_name": "example.trip_pickup_features",
     "lookup_key": ["pickup_zip", "rounded_pickup_datetime"],
  },
  {
      "table_name": "example.trip_dropoff_features",
     "lookup_key": ["dropoff_zip", "rounded_dropoff_datetime"],
  }
]

Exemple de notebook : expérience AutoML avec Feature Store

Le notebook suivant explique comment entraîner un modèle ML avec des tables de fonctionnalités AutoML et Feature Store.

Exemple de notebook d’expérience AutoML avec Feature Store

Obtenir le notebook