Prétraitement des données pour le ML : options et recommandations

Ce document est le premier d'une série en deux parties qui explore le thème de l'ingénierie des données et de l'ingénierie des fonctionnalités pour l'apprentissage automatique (ML), en mettant l'accent sur les tâches d'apprentissage supervisé. Cette première partie traite des bonnes pratiques de prétraitement des données dans un pipeline ML sur Google Cloud. Le document se concentre sur l'utilisation de TensorFlow et de la bibliothèque open source TensorFlow Transform ( tf.Transform ) pour préparer les données, entraîner le modèle et servir le modèle à des fins de prédiction. Ce document met en évidence les défis liés au prétraitement des données pour le ML et décrit les options et les scénarios permettant d'effectuer efficacement la transformation des données sur Google Cloud.

Ce document suppose que vous connaissez BigQuery , Dataflow , Vertex AI et l'API TensorFlow Keras .

Le deuxième document, Prétraitement des données pour le ML avec Google Cloud , fournit un didacticiel étape par étape expliquant comment implémenter un pipeline tf.Transform .

Introduction

ML vous aide à trouver automatiquement des modèles complexes et potentiellement utiles dans les données. Ces modèles sont condensés dans un modèle ML qui peut ensuite être utilisé sur de nouveaux points de données : un processus appelé faire des prédictions ou effectuer une inférence .

La création d'un modèle ML est un processus en plusieurs étapes. Chaque étape présente ses propres défis techniques et conceptuels. Cette série en deux parties se concentre sur les tâches d'apprentissage supervisé et le processus de sélection, de transformation et d'augmentation des données sources pour créer de puissants signaux prédictifs pour la variable cible. Ces opérations combinent connaissance du domaine et techniques de science des données. Les opérations sont l'essence même de l'ingénierie des fonctionnalités .

La taille des ensembles de données de formation pour les modèles ML du monde réel peut facilement être égale ou supérieure à un téraoctet (To). Par conséquent, vous avez besoin de cadres de traitement de données à grande échelle afin de traiter ces ensembles de données de manière efficace et distribuée. Lorsque vous utilisez un modèle ML pour effectuer des prédictions, vous devez appliquer les mêmes transformations que celles que vous avez utilisées pour les données d'entraînement sur les nouveaux points de données. En appliquant les mêmes transformations, vous présentez l'ensemble de données en direct au modèle ML de la manière attendue par le modèle.

Ce document aborde ces défis pour différents niveaux de granularité des opérations d'ingénierie de fonctionnalités : agrégations au niveau de l'instance, à passage complet et par fenêtre temporelle. Ce document décrit également les options et les scénarios permettant d'effectuer une transformation de données pour le ML sur Google Cloud.

Ce document fournit également une présentation de TensorFlow Transform ( tf.Transform ), une bibliothèque pour TensorFlow qui vous permet de définir à la fois une transformation de données au niveau de l'instance et une transformation complète via des pipelines de prétraitement des données. Ces pipelines sont exécutés avec Apache Beam et créent des artefacts qui vous permettent d'appliquer les mêmes transformations pendant la prédiction que lorsque le modèle est servi.

Prétraitement des données pour le ML

Cette section présente les opérations de prétraitement des données et les étapes de préparation des données. Il aborde également les types d'opérations de prétraitement et leur granularité.

Ingénierie des données comparée à l'ingénierie des fonctionnalités

Le prétraitement des données pour le ML implique à la fois l'ingénierie des données et l'ingénierie des fonctionnalités. L'ingénierie des données est le processus de conversion de données brutes en données préparées . L'ingénierie des fonctionnalités ajuste ensuite les données préparées pour créer les fonctionnalités attendues par le modèle ML. Ces termes ont les significations suivantes :

Données brutes (ou simplement données )

Les données sous leur forme source, sans aucune préparation préalable au ML. Dans ce contexte, les données peuvent être sous leur forme brute (dans un lac de données) ou sous forme transformée (dans un entrepôt de données). Les données transformées qui se trouvent dans un entrepôt de données peuvent avoir été converties à partir de leur forme brute d'origine pour être utilisées à des fins d'analyse. Cependant, dans ce contexte, les données brutes signifient que les données n'ont pas été préparées spécifiquement pour votre tâche ML. Les données sont également considérées comme des données brutes si elles sont envoyées à partir de systèmes de streaming qui appellent finalement des modèles ML pour des prédictions.

Données préparées

L'ensemble de données sous la forme prêt pour votre tâche ML : les sources de données ont été analysées, jointes et mises sous forme de tableau. Les données préparées sont agrégées et résumées avec la granularité appropriée : par exemple, chaque ligne de l'ensemble de données représente un client unique et chaque colonne représente des informations récapitulatives sur le client, comme le total dépensé au cours des six dernières semaines. Dans un tableau de données préparé, les colonnes non pertinentes ont été supprimées et les enregistrements non valides ont été filtrés. Pour les tâches d’apprentissage supervisé, la fonctionnalité cible est présente.

Fonctionnalités d'ingénierie

L'ensemble de données avec les fonctionnalités optimisées attendues par le modèle, c'est-à-dire les fonctionnalités créées en effectuant certaines opérations spécifiques au ML sur les colonnes de l'ensemble de données préparé et en créant de nouvelles fonctionnalités pour votre modèle pendant l'entraînement et la prédiction, comme décrit plus loin. dans Opérations de prétraitement . Des exemples de ces opérations incluent la mise à l'échelle des colonnes numériques à une valeur comprise entre 0 et 1, les valeurs de découpage et les fonctionnalités catégorielles à codage à chaud .

Le diagramme suivant, figure 1, montre les étapes impliquées dans la préparation des données prétraitées :

Dans la pratique, les données provenant d’une même source se trouvent souvent à des stades de préparation différents. Par exemple, un champ d'une table de votre entrepôt de données peut être utilisé directement comme fonctionnalité d'ingénierie. Dans le même temps, un autre champ de la même table devra peut-être subir des transformations avant de devenir une fonctionnalité d'ingénierie. De même, les opérations d’ingénierie des données et d’ingénierie des fonctionnalités peuvent être combinées dans la même étape de prétraitement des données.

Opérations de prétraitement

Le prétraitement des données comprend plusieurs opérations. Chaque opération est conçue pour aider ML à créer de meilleurs modèles prédictifs. Les détails de ces opérations de prétraitement sortent du cadre de ce document, mais certaines opérations sont brièvement décrites dans cette section.

Pour les données structurées, les opérations de prétraitement des données sont les suivantes :

• Nettoyage des données : suppression ou correction des enregistrements dont les valeurs sont corrompues ou invalides à partir des données brutes, et suppression des enregistrements pour lesquels il manque un grand nombre de colonnes.
• Sélection et partitionnement des instances : sélection de points de données à partir de l'ensemble de données d'entrée pour créer des ensembles de formation, d'évaluation (validation) et de test . Ce processus comprend des techniques d'échantillonnage aléatoire répétable, de suréchantillonnage des classes minoritaires et de partitionnement stratifié.
• Réglage des fonctionnalités : amélioration de la qualité d'une fonctionnalité pour le ML, ce qui inclut la mise à l'échelle et la normalisation des valeurs numériques, l'imputation des valeurs manquantes, l'écrêtage des valeurs aberrantes et l'ajustement des valeurs dont les distributions sont asymétriques.
• Transformation de fonctionnalités : conversion d'une fonctionnalité numérique en une fonctionnalité catégorielle (via la bucketisation ) et conversion de fonctionnalités catégorielles en une représentation numérique (via un codage à chaud, un apprentissage avec des comptes , des intégrations de fonctionnalités clairsemées, etc.). Certains modèles fonctionnent uniquement avec des fonctionnalités numériques ou catégorielles, tandis que d'autres peuvent gérer des fonctionnalités de type mixte. Même lorsque les modèles gèrent les deux types, ils peuvent bénéficier de différentes représentations (numériques et catégorielles) de la même fonctionnalité.
• Extraction de fonctionnalités : réduire le nombre de fonctionnalités en créant des représentations de données de dimension inférieure et plus puissantes à l'aide de techniques telles que la PCA , l'extraction par intégration et le hachage .
• Sélection de fonctionnalités : sélectionner un sous-ensemble de fonctionnalités d'entrée pour entraîner le modèle et ignorer celles qui ne sont pas pertinentes ou redondantes, à l'aide de méthodes de filtrage ou de wrapper . La sélection de fonctionnalités peut également impliquer simplement la suppression de fonctionnalités s'il leur manque un grand nombre de valeurs.
• Construction de fonctionnalités : création de nouvelles fonctionnalités en utilisant des techniques typiques, telles que l'expansion polynomiale (en utilisant des fonctions mathématiques univariées) ou le croisement de fonctionnalités (pour capturer les interactions de fonctionnalités). Les fonctionnalités peuvent également être construites en utilisant la logique métier du domaine du cas d’utilisation du ML.

Lorsque vous travaillez avec des données non structurées (par exemple, des images, des documents audio ou texte), l'apprentissage profond remplace l'ingénierie des fonctionnalités basée sur la connaissance du domaine en l'intégrant à l'architecture du modèle. Une couche convolutive est un préprocesseur de fonctionnalités automatique. Construire la bonne architecture de modèle nécessite une certaine connaissance empirique des données. De plus, un certain nombre de prétraitements sont nécessaires, tels que les suivants :

• Pour les documents texte : radicalisation et lemmatisation , calcul TF-IDF et extraction de n-grammes , recherche d'intégration.
• Pour les images : découpage, redimensionnement, recadrage, flou gaussien et filtres canari.
• Pour tous les types de données (y compris le texte et les images) : apprentissage par transfert , qui traite toutes les couches sauf la dernière du modèle entièrement formé comme une étape d'ingénierie des fonctionnalités.

Granularité du prétraitement

Cette section traite de la granularité des types de transformations de données. Il montre pourquoi cette perspective est essentielle lors de la préparation de nouveaux points de données pour les prédictions à l'aide de transformations appliquées aux données d'entraînement.

Les opérations de prétraitement et de transformation peuvent être classées comme suit, en fonction de la granularité des opérations :

• Transformations au niveau de l'instance pendant la formation et la prédiction . Il s'agit de transformations simples, dans lesquelles seules les valeurs de la même instance sont nécessaires pour la transformation. Par exemple, les transformations au niveau de l'instance peuvent inclure le découpage de la valeur d'une fonctionnalité à un certain seuil, l'expansion polynomiale d'une autre fonctionnalité, la multiplication de deux fonctionnalités ou la comparaison de deux fonctionnalités pour créer un indicateur booléen.

  Ces transformations doivent être appliquées de la même manière lors de l'entraînement et de la prédiction, car le modèle sera entraîné sur les caractéristiques transformées, et non sur les valeurs d'entrée brutes. Si les données ne sont pas transformées de manière identique, le modèle se comporte mal car il est présenté avec des données présentant une distribution de valeurs avec laquelle il n'a pas été entraîné. Pour plus d’informations, consultez la discussion sur le décalage entre la formation et la diffusion dans la section Défis du prétraitement .

• Transformations complètes pendant la formation, mais transformations au niveau de l'instance pendant la prédiction . Dans ce scénario, les transformations sont avec état, car elles utilisent des statistiques précalculées pour effectuer la transformation. Pendant l'entraînement, vous analysez l'ensemble des données d'entraînement pour calculer des quantités telles que le minimum, le maximum, la moyenne et la variance afin de transformer les données d'entraînement, les données d'évaluation et les nouvelles données au moment de la prédiction.

  Par exemple, pour normaliser une caractéristique numérique pour l'entraînement, vous calculez sa moyenne (μ) et son écart type (σ) sur l'ensemble des données d'entraînement. Ce calcul est appelé opération passe complète (ou analyse ). Lorsque vous diffusez le modèle à des fins de prédiction, la valeur d'un nouveau point de données est normalisée pour éviter un biais d'entraînement et de diffusion. Par conséquent, les valeurs μ et σ calculées pendant l’entraînement sont utilisées pour ajuster la valeur de la caractéristique, ce qui correspond à l’opération simple suivante au niveau de l’instance :

  $$ value_{scaled} = (value_{raw} - \mu) \div \sigma $$

  Les transformations complètes incluent les éléments suivants :

  • Fonctionnalités numériques de mise à l'échelle MinMax à l'aide des valeurs min et max calculées à partir de l'ensemble de données d'entraînement.
  • Caractéristiques numériques de mise à l'échelle standard (normalisation du score z) utilisant μ et σ calculées sur l'ensemble de données d'entraînement.
  • Compartiment des caractéristiques numériques à l'aide de quantiles.
  • Imputation des valeurs manquantes à l'aide de la médiane (caractéristiques numériques) ou du mode (caractéristiques catégorielles).
  • Conversion de chaînes (valeurs nominales) en entiers (index) en extrayant toutes les valeurs distinctes (vocabulaire) d'une caractéristique catégorielle d'entrée.
  • Compter l'occurrence d'un terme (valeur de caractéristique) dans tous les documents (instances) à calculer pour TF-IDF.
  • Calcul de la PCA des entités en entrée pour projeter les données dans un espace dimensionnel inférieur (avec des entités linéairement dépendantes).

  Vous devez utiliser uniquement les données d'entraînement pour calculer des statistiques telles que μ, σ, min et max . Si vous ajoutez les données de test et d'évaluation pour ces opérations, vous perdez des informations des données d'évaluation et de test pour entraîner le modèle. Cela affecte la fiabilité des résultats des tests et des évaluations. Pour garantir que vous appliquez une transformation cohérente à tous les ensembles de données, vous utilisez les mêmes statistiques calculées à partir des données d'entraînement pour transformer les données de test et d'évaluation.

• Agrégations historiques pendant la formation et la prédiction . Cela implique la création d'agrégations commerciales, de dérivations et d'indicateurs comme signaux d'entrée pour la tâche de prédiction, par exemple, la création de métriques de récence, de fréquence et monétaires (RFM) permettant aux clients de créer des modèles de propension. Ces types de fonctionnalités peuvent être précalculés et stockés dans un magasin de fonctionnalités pour être utilisés lors de la formation du modèle, de la notation par lots et de la diffusion de prédictions en ligne. Vous pouvez également effectuer une ingénierie de fonctionnalités supplémentaire (par exemple, transformation et réglage) sur ces agrégations avant l'entraînement et la prédiction.

• Agrégations historiques pendant la formation, mais agrégations en temps réel pendant la prédiction . Cette approche consiste à créer une fonctionnalité en résumant les valeurs en temps réel au fil du temps. Dans cette approche, les instances à agréger sont définies via des clauses de fenêtre temporelle. Par exemple, vous pouvez utiliser cette approche si vous souhaitez entraîner un modèle qui estime le temps de trajet en taxi en fonction des mesures de trafic pour l'itinéraire au cours des 5 dernières minutes, des 10 dernières minutes, des 30 dernières minutes et à d'autres moments. intervalles. Vous pouvez également utiliser cette approche pour prédire la défaillance d'une pièce du moteur en fonction de la moyenne mobile des valeurs de température et de vibration calculées au cours des 3 dernières minutes. Bien que ces agrégations puissent être préparées hors ligne pour la formation, elles sont calculées en temps réel à partir d'un flux de données pendant la diffusion.

  Plus précisément, lorsque vous préparez des données d'entraînement, si la valeur agrégée ne figure pas dans les données brutes, la valeur est créée lors de la phase d'ingénierie des données. Les données brutes sont généralement stockées dans une base de données au format (entity, timestamp, value) . Dans les exemples précédents, entity est l'identifiant de segment d'itinéraire pour les itinéraires de taxi et l'identifiant de pièce de moteur pour la panne moteur. Vous pouvez utiliser des opérations de fenêtrage pour calculer (entity, time_index, aggregated_value_over_time_window) et utiliser les fonctionnalités d'agrégation comme entrée pour la formation de votre modèle.

  Lorsque le modèle de prédiction en temps réel (en ligne) est servi, le modèle attend en entrée les caractéristiques dérivées des valeurs agrégées. Par conséquent, vous pouvez utiliser une technologie de traitement de flux telle qu'Apache Beam pour calculer les agrégations à partir des points de données en temps réel diffusés dans votre système. La technologie de traitement de flux regroupe les données en temps réel en fonction de fenêtres temporelles à mesure que de nouveaux points de données arrivent. Vous pouvez également effectuer une ingénierie de fonctionnalités supplémentaire (par exemple, transformation et réglage) sur ces agrégations avant l'entraînement et la prédiction.

Pipeline de ML sur Google Cloud

Cette section présente les principaux composants d'un pipeline de bout en bout typique pour entraîner et diffuser des modèles TensorFlow ML sur Google Cloud à l'aide de services gérés. Il explique également où vous pouvez implémenter différentes catégories d'opérations de prétraitement des données et les défis courants auxquels vous pourriez être confronté lors de la mise en œuvre de telles transformations. La section Comment fonctionne tf.Transform montre comment la bibliothèque TensorFlow Transform aide à relever ces défis.

Architecture de haut niveau

Le diagramme suivant, figure 2, montre une architecture de haut niveau d'un pipeline ML typique pour la formation et la diffusion de modèles TensorFlow. Les étiquettes A, B et C dans le diagramme font référence aux différents endroits du pipeline où le prétraitement des données peut avoir lieu. Les détails de ces étapes sont fournis dans la section suivante.

Le pipeline comprend les étapes suivantes :

1. Une fois les données brutes importées, les données tabulaires sont stockées dans BigQuery et d'autres données telles que les images, l'audio et la vidéo sont stockées dans Cloud Storage. La deuxième partie de cette série utilise comme exemple les données tabulaires stockées dans BigQuery.
2. L'ingénierie des données (préparation) et l'ingénierie des fonctionnalités sont exécutées à grande échelle à l'aide de Dataflow. Cette exécution produit des ensembles de formation, d'évaluation et de test prêts pour le ML qui sont stockés dans Cloud Storage. Idéalement, ces ensembles de données sont stockés sous forme de fichiers TFRecord , qui est le format optimisé pour les calculs TensorFlow.
3. Un package d'entraînement de modèle TensorFlow est soumis à Vertex AI Training, qui utilise les données prétraitées des étapes précédentes pour entraîner le modèle. Le résultat de cette étape est un TensorFlow SavedModel formé qui est exporté vers Cloud Storage.
4. Le modèle TensorFlow entraîné est déployé sur Vertex AI Prediction en tant que service doté d'une API REST afin de pouvoir être utilisé pour les prédictions en ligne. Le même modèle peut également être utilisé pour les tâches de prédiction par lots.
5. Une fois le modèle déployé en tant qu'API REST, les applications clientes et les systèmes internes peuvent appeler l'API en envoyant des requêtes avec certains points de données et en recevant des réponses du modèle avec des prédictions.
6. Pour orchestrer et automatiser ce pipeline, vous pouvez utiliser Vertex AI Pipelines comme planificateur pour appeler les étapes de préparation des données, de formation du modèle et de déploiement du modèle.

Vous pouvez également utiliser Vertex AI Feature Store pour stocker les caractéristiques d'entrée afin d'effectuer des prédictions. Par exemple, vous pouvez créer périodiquement des fonctionnalités d'ingénierie à partir des dernières données brutes et les stocker dans Vertex AI Feature Store. Les applications clientes récupèrent les fonctionnalités d'entrée requises dans Vertex AI Feature Store et les envoient au modèle pour recevoir des prédictions.

Où effectuer le prétraitement

Dans la figure 2, les étiquettes A, B et C montrent que les opérations de prétraitement des données peuvent avoir lieu dans BigQuery, Dataflow ou TensorFlow. Les sections suivantes décrivent le fonctionnement de chacune de ces options.

Option A : BigQuery

En règle générale, la logique est implémentée dans BigQuery pour les opérations suivantes :

• Échantillonnage : sélection aléatoire d'un sous-ensemble à partir des données.
• Filtrage : suppression des instances non pertinentes ou invalides.
• Partitionnement : diviser les données pour produire des ensembles de formation, d'évaluation et de test.

Les scripts BigQuery SQL peuvent être utilisés comme requête source pour le pipeline de prétraitement Dataflow, qui correspond à l'étape de traitement des données de la figure 2. Par exemple, si un système est utilisé au Canada et que l'entrepôt de données contient des transactions du monde entier, le filtrage vers Il est préférable d'obtenir des données d'entraînement uniquement au Canada dans BigQuery. L'ingénierie des fonctionnalités dans BigQuery est simple et évolutive, et prend en charge la mise en œuvre de transformations de fonctionnalités au niveau de l'instance et des agrégations historiques.

Toutefois, nous vous recommandons d'utiliser BigQuery pour l'ingénierie des fonctionnalités uniquement si vous utilisez votre modèle pour la prédiction par lots (score) ou si les fonctionnalités sont précalculées dans BigQuery, mais stockées dans Vertex AI Feature Store pour être utilisées lors de la prédiction en ligne. Si vous envisagez de déployer le modèle pour les prédictions en ligne et si vous ne disposez pas de la fonctionnalité d'ingénierie dans un magasin de fonctionnalités en ligne, vous devez répliquer les opérations de prétraitement SQL pour transformer les points de données brutes générés par d'autres systèmes. En d'autres termes, vous devez implémenter la logique deux fois : une fois dans SQL pour prétraiter les données d'entraînement dans BigQuery, et une seconde fois dans la logique de l'application qui consomme le modèle pour prétraiter les points de données en ligne à des fins de prédiction.

Par exemple, si votre application client est écrite en Java, vous devez réimplémenter la logique en Java. Cela peut introduire des erreurs dues à des écarts de mise en œuvre, comme décrit dans la section sur l'asymétrie de la diffusion et de la formation des défis de prétraitement plus loin dans ce document. Cela représente également une surcharge supplémentaire pour maintenir deux implémentations différentes. Chaque fois que vous modifiez la logique dans SQL pour prétraiter les données d'entraînement, vous devez modifier l'implémentation Java en conséquence pour prétraiter les données au moment de la diffusion.

Si vous utilisez votre modèle uniquement pour la prédiction par lots (par exemple, en utilisant la prédiction par lots Vertex AI) et si vos données pour l'évaluation proviennent de BigQuery, vous pouvez mettre en œuvre ces opérations de prétraitement dans le cadre du script SQL BigQuery. Dans ce cas, vous pouvez utiliser le même script SQL de prétraitement pour préparer les données de formation et de notation.

Les transformations avec état passe complète ne conviennent pas à la mise en œuvre dans BigQuery. Si vous utilisez BigQuery pour des transformations complètes, vous avez besoin de tables auxiliaires pour stocker les quantités nécessaires aux transformations avec état, telles que les moyennes et les variances pour mettre à l'échelle les caractéristiques numériques. De plus, la mise en œuvre de transformations complètes à l'aide de SQL sur BigQuery crée une complexité accrue dans les scripts SQL et crée une dépendance complexe entre l'entraînement et les scripts SQL de notation.

Option B : flux de données

Comme le montre la figure 2, vous pouvez implémenter des opérations de prétraitement coûteuses en termes de calcul dans Apache Beam et les exécuter à grande échelle à l'aide de Dataflow. Dataflow est un service d'autoscaling entièrement géré pour le traitement des données par lots et par flux. Lorsque vous utilisez Dataflow, vous pouvez également utiliser des bibliothèques externes spécialisées pour le traitement des données, contrairement à BigQuery.

Dataflow peut effectuer des transformations au niveau de l'instance, ainsi que des transformations de fonctionnalités d'agrégation historiques et en temps réel. En particulier, si vos modèles ML attendent une fonctionnalité d'entrée telle que total_number_of_clicks_last_90sec , les fonctions de fenêtrage d'Apache Beam peuvent calculer ces fonctionnalités en agrégeant les valeurs des fenêtres temporelles des données d'événements en temps réel (streaming) (par exemple, les événements de clic). Dans la discussion précédente sur la granularité des transformations , cela était appelé « agrégations historiques pendant la formation, mais agrégations en temps réel pendant la prédiction ».

Le diagramme suivant, figure 3, montre le rôle de Dataflow dans le traitement des données de flux pour des prédictions en temps quasi réel.

Comme le montre la figure 3, pendant le traitement, des événements appelés points de données sont ingérés dans Pub/Sub . Dataflow consomme ces points de données, calcule les fonctionnalités en fonction des agrégats au fil du temps, puis appelle l'API du modèle ML déployé pour les prédictions. Les prédictions sont ensuite envoyées à une file d'attente Pub/Sub sortante. Depuis Pub/Sub, les prédictions peuvent être consommées par des systèmes en aval tels que la surveillance ou le contrôle, ou elles peuvent être renvoyées (par exemple, sous forme de notifications) au client demandeur d'origine. Les prédictions peuvent également être stockées dans un magasin de données à faible latence comme Cloud Bigtable pour une récupération en temps réel. Cloud Bigtable peut également être utilisé pour accumuler et stocker ces agrégations en temps réel afin de pouvoir les consulter en cas de besoin à des fins de prédiction.

La même implémentation d'Apache Beam peut être utilisée pour traiter par lots les données d'entraînement provenant d'une banque de données hors ligne comme BigQuery et pour traiter en continu les données en temps réel afin de fournir des prédictions en ligne.

Dans d'autres architectures typiques, telles que l'architecture illustrée à la figure 2, l'application client appelle directement l'API du modèle déployé pour les prédictions en ligne. Dans ce cas, si des opérations de prétraitement sont mises en œuvre dans Dataflow pour préparer les données d'entraînement, les opérations ne sont pas appliquées aux données de prédiction qui sont directement transmises au modèle. Par conséquent, de telles transformations doivent être intégrées dans le modèle lors de la diffusion des prédictions en ligne.

Dataflow peut être utilisé pour effectuer une transformation complète, en calculant les statistiques requises à grande échelle. Cependant, ces statistiques doivent être stockées quelque part pour être utilisées lors de la prédiction afin de transformer les points de données de prédiction. En utilisant la bibliothèque TensorFlow Transform ( tf.Transform ), vous pouvez directement intégrer ces statistiques dans le modèle au lieu de les stocker ailleurs. Cette approche est expliquée plus loin dans Comment fonctionne tf.Transform .

Option C : TensorFlow

Comme le montre la figure 2, vous pouvez implémenter des opérations de prétraitement et de transformation des données dans le modèle TensorFlow lui-même. Comme le montre la figure, le prétraitement que vous implémentez pour entraîner le modèle TensorFlow devient partie intégrante du modèle lorsque celui-ci est exporté et déployé pour les prédictions. Les transformations dans le modèle TensorFlow peuvent être effectuées de l'une des manières suivantes :

• Implémentation de toute la logique de transformation au niveau de l'instance dans la fonction input_fn et dans la fonction serving_fn . La fonction input_fn prépare un ensemble de données à l'aide de l' API tf.data.Dataset pour entraîner un modèle. La fonction serving_fn reçoit et prépare les données pour les prédictions.
• Placer le code de transformation directement dans votre modèle TensorFlow en utilisant des couches de prétraitement Keras ou en créant des couches personnalisées .

Le code logique de transformation dans la fonction serving_fn définit l'interface de service de votre SavedModel pour la prédiction en ligne. Si vous implémentez les mêmes transformations que celles utilisées pour préparer les données d'entraînement dans le code logique de transformation de la fonction serving_fn , cela garantit que les mêmes transformations sont appliquées aux nouveaux points de données de prédiction lorsqu'ils sont servis.

Toutefois, étant donné que le modèle TensorFlow traite chaque point de données indépendamment ou en petit lot, vous ne pouvez pas calculer des agrégations à partir de tous les points de données. Par conséquent, les transformations complètes ne peuvent pas être implémentées dans votre modèle TensorFlow.

Défis de prétraitement

Voici les principaux défis liés à la mise en œuvre du prétraitement des données :

• Désalignement entre la formation et le service . L’asymétrie entraînement-service fait référence à une différence entre l’efficacité (performance prédictive) pendant l’entraînement et pendant le service. Ce biais peut être dû à un écart entre la manière dont vous gérez les données dans la formation et dans les pipelines de diffusion. Par exemple, si votre modèle est entraîné sur une fonctionnalité transformée de manière logarithmique, mais qu'il est présenté avec la fonctionnalité brute lors de la diffusion, le résultat de la prédiction peut ne pas être précis.

  Si les transformations font partie du modèle lui-même, il peut être simple de gérer les transformations au niveau de l'instance, comme décrit précédemment dans Option C : TensorFlow . Dans ce cas, l'interface de service du modèle (la fonction serving_fn ) attend des données brutes, tandis que le modèle transforme ces données en interne avant de calculer la sortie. Les transformations sont les mêmes que celles qui ont été appliquées aux points de données bruts d’entraînement et de prédiction.

• Transformations en passe complète . Vous ne pouvez pas implémenter de transformations complètes telles que des transformations de mise à l'échelle et de normalisation dans votre modèle TensorFlow. Dans les transformations complètes, certaines statistiques (par exemple, les valeurs max et min pour mettre à l'échelle les caractéristiques numériques) doivent être calculées au préalable sur les données d'entraînement, comme décrit dans Option B : Flux de données . Les valeurs doivent ensuite être stockées quelque part pour être utilisées pendant la diffusion du modèle à des fins de prédiction afin de transformer les nouveaux points de données brutes en transformations au niveau de l'instance, ce qui évite le biais de formation et de diffusion. Vous pouvez utiliser la bibliothèque TensorFlow Transform ( tf.Transform ) pour intégrer directement les statistiques dans votre modèle TensorFlow. Cette approche est expliquée plus loin dans Comment fonctionne tf.Transform .

• Préparer les données à l'avance pour une meilleure efficacité de la formation . La mise en œuvre de transformations au niveau de l'instance dans le cadre du modèle peut dégrader l'efficacité du processus de formation. Cette dégradation se produit parce que les mêmes transformations sont appliquées de manière répétée aux mêmes données d'entraînement à chaque époque. Imaginez que vous disposez de données d'entraînement brutes avec 1 000 fonctionnalités et que vous appliquez une combinaison de transformations au niveau de l'instance pour générer 10 000 fonctionnalités. Si vous implémentez ces transformations dans le cadre de votre modèle, et si vous alimentez ensuite le modèle avec les données brutes d'entraînement, ces 10 000 opérations sont appliquées N fois sur chaque instance, où N est le nombre d'époques. De plus, si vous utilisez des accélérateurs (GPU ou TPU), ils restent inactifs pendant que le processeur effectue ces transformations, ce qui ne constitue pas une utilisation efficace de vos accélérateurs coûteux.

  Idéalement, les données d'entraînement sont transformées avant l'entraînement, à l'aide de la technique décrite sous Option B : Dataflow , où les 10 000 opérations de transformation ne sont appliquées qu'une seule fois sur chaque instance d'entraînement. Les données de formation transformées sont ensuite présentées au modèle. Aucune autre transformation n'est appliquée et les accélérateurs sont constamment occupés. De plus, l'utilisation de Dataflow vous aide à prétraiter de grandes quantités de données à grande échelle, à l'aide d'un service entièrement géré.

  La préparation des données de formation à l'avance peut améliorer l'efficacité de la formation. Cependant, la mise en œuvre de la logique de transformation en dehors du modèle (les approches décrites dans Option A : BigQuery ou Option B : Dataflow ) ne résout pas le problème du déséquilibre entre la formation et la diffusion. À moins que vous ne stockiez la fonctionnalité conçue dans le magasin de fonctionnalités pour l'utiliser à la fois pour la formation et la prédiction, la logique de transformation doit être implémentée quelque part pour être appliquée aux nouveaux points de données destinés à la prédiction, car l'interface du modèle attend des données transformées. La bibliothèque TensorFlow Transform ( tf.Transform ) peut vous aider à résoudre ce problème, comme décrit dans la section suivante.

Comment fonctionne tf.Transform

La bibliothèque tf.Transform est utile pour les transformations qui nécessitent une passe complète. La sortie de la bibliothèque tf.Transform est exportée sous forme de graphique TensorFlow qui représente la logique de transformation au niveau de l'instance et les statistiques calculées à partir des transformations complètes, à utiliser pour la formation et le service. L’utilisation du même graphique pour l’entraînement et le service peut éviter les biais, car les mêmes transformations sont appliquées aux deux étapes. De plus, la bibliothèque tf.Transform peut s'exécuter à grande échelle dans un pipeline de traitement par lots sur Dataflow pour préparer les données d'entraînement à l'avance et améliorer l'efficacité de l'entraînement.

Le diagramme suivant, figure 4, montre comment la bibliothèque tf.Transform prétraite et transforme les données pour l'entraînement et la prédiction. Le processus est décrit dans les sections suivantes.

Transformez les données de formation et d’évaluation

Vous prétraitez les données d'entraînement brutes à l'aide de la transformation implémentée dans les API tf.Transform Apache Beam et vous les exécutez à grande échelle sur Dataflow. Le prétraitement s'effectue selon les phases suivantes :

• Phase d'analyse : pendant la phase d'analyse, les statistiques requises (telles que les moyennes, les variances et les quantiles) pour les transformations avec état sont calculées sur les données d'entraînement avec des opérations de passe complète. Cette phase produit un ensemble d'artefacts de transformation, notamment le graphe transform_fn . Le graphe transform_fn est un graphe TensorFlow dont la logique de transformation est une opération au niveau de l'instance. Il inclut les statistiques calculées lors de la phase d'analyse sous forme de constantes.
• Phase de transformation : pendant la phase de transformation, le graphique transform_fn est appliqué aux données d'entraînement brutes, où les statistiques calculées sont utilisées pour traiter les enregistrements de données (par exemple, pour mettre à l'échelle les colonnes numériques) au niveau de l'instance.

Une approche en deux phases comme celle-ci répond au défi de prétraitement consistant à effectuer des transformations en passe complète.

Lorsque les données d'évaluation sont prétraitées, seules les opérations au niveau de l'instance sont appliquées, en utilisant la logique du graphe transform_fn et les statistiques calculées à partir de la phase d'analyse dans les données d'entraînement. En d’autres termes, vous n’analysez pas les données d’évaluation de manière complète pour calculer de nouvelles statistiques, telles que μ et σ, afin de normaliser les caractéristiques numériques des données d’évaluation. Au lieu de cela, vous utilisez les statistiques calculées à partir des données d’entraînement pour transformer les données d’évaluation au niveau de l’instance.

Les données de formation et d'évaluation transformées sont préparées à grande échelle à l'aide de Dataflow, avant d'être utilisées pour entraîner le modèle. Ce processus de préparation de données par lots répond au défi de prétraitement consistant à préparer les données à l'avance pour améliorer l'efficacité de la formation. Comme le montre la figure 4, l'interface interne du modèle s'attend à des fonctionnalités transformées.

Attacher des transformations au modèle exporté

Comme indiqué, le graphique transform_fn produit par le pipeline tf.Transform est stocké comme un graphique TensorFlow exporté. Le graphique exporté se compose de la logique de transformation comme opérations au niveau de l'instance, et toutes les statistiques calculées dans les transformations passes complètes sous forme de constantes de graphe. Lorsque le modèle formé est exporté pour servir, le graphique transform_fn est attaché au SavedModel dans le cadre de sa fonction serving_fn .

Pendant qu'il sert le modèle de prédiction, l'interface de service du modèle attend des points de données dans le format brut (c'est-à-dire avant toute transformation). Cependant, l'interface interne du modèle s'attend à des données dans le format transformé.

Le graphique transform_fn , qui fait maintenant partie du modèle, applique toute la logique de prétraitement sur le point de données entrant. Il utilise les constantes stockées (comme μ et σ pour normaliser les caractéristiques numériques) dans le fonctionnement au niveau de l'instance pendant la prédiction. Par conséquent, le graphique transform_fn convertit le point de données bruts au format transformé. Le format transformé est ce qui est attendu par l'interface interne du modèle afin de produire une prédiction, comme le montre la figure 4.

Ce mécanisme résout le défi de prétraitement de la biais de formation de formation, car la même logique (implémentation) qui est utilisée pour transformer les données de formation et d'évaluation est appliquée pour transformer les nouveaux points de données lors de la fonction de prédiction.

Résumé des options de prétraitement

Le tableau suivant résume les options de prétraitement des données dont ce document a discuté. Dans le tableau, "N / A" signifie "Non applicable".

^* Avec TensorFlow, des transformations comme le croisement, l'intégration et le codage à un hot doivent être effectués de manière déclarative sous forme de colonnes feature_columns .

Et après

• Pour implémenter un pipeline tf.Transform et l'exécuter à l'aide de DataFlow, lisez la deuxième partie de cette série, le prétraitement des données pour ML à l'aide de TensorFlow Transform .
• Suivez la spécialisation Coursera sur le ML avec TensorFlow sur Google Cloud .
• Découvrez les meilleures pratiques en matière d'ingénierie ML dans Rules of ML .
• Pour plus d'architectures de référence, de diagrammes et de meilleures pratiques, explorez les solutions de cloud TFX .