Blog dédié à la donnée sous toutes ses formes actuelles
Author: methodidacte
Passionné par les chiffres sous toutes leurs formes, j'évolue aujourd'hui en tant que consultant senior dans les différents domaines en lien avec la DATA (décisionnel self service, analytics, machine learning, data visualisation...).
J'accompagne les entreprises dans une approche visant à dépasser l'analyse descriptive pour viser l'analyse prédictive et prescriptive.
J'ai aussi à coeur de développer une offre autour de l'analytics, du Machine Learning et des archictectures (cloud Azure principalement) dédiées aux projets de Data Science.
Azure Data Factory est à la fois un ordonnanceur de traitements, un ETL ou un ELT selon la manière dont on pense les transformations et le chargement dans la destination (« sink » dans le vocable d’ADF). Il est muni d’une fenêtre de monitoring permettant de superviser l’exécution de pipelines au travers de triggers (déclencheurs en bon français). Et il ne sera pas rare (le plus rare possible, on vous le souhaite !) de rencontrer les icônes rouges de l’échec du traitement dans cette fenêtre.
Pipeline run : status failed
Dans cet article, nous allons explorer différentes méthodes
de déclenchement ou relance d’un pipeline Azure Data Factory.
Relancer manuellement
Depuis le monitoring des pipelines, nous disposons de plusieurs boutons comme le bouton « rerun » au niveau de l’exécution globale du trigger.
Lorsqu’il existe une ou plusieurs activités dans le pipeline, il suffit d’aller sur le détail de l’exécution du pipeline pour choisir une des activités (cliquer dessus) et la relancer (« rerun from failed activity »). Ce second mode est particulièrement intéressant lorsqu’une chaîne de traitement a déjà réalisé des étapes importantes et ne nécessite pas d’être reprise depuis le début. Les gains de temps de traitement seront sans doute conséquents.
Ces deux stratégies sont bien sûr manuelles et nécessitent
de venir observer la console de supervision. Nous allons maintenant explorer
des stratégies plus automatisées.
Démarrage ou relance automatique
Une approche classique de déclenchement des pipelines consiste à définir un jour et une heure de déclenchement. S’il existe des dépendances aux activités, on prendra soin d’inclure différentes activités au sein du même pipeline et de les relier grâce aux différentes sorties disponibles (« add activity on »).
Il existe quatre types de conditions :
Success
Failure
Completion : exécution de l’activité suivante en cas de succès ou d’échec de l’activité
Skipped : exécution de l’activité suivante uniquement si l’activité n’a pas été exécutée
Ce blog vous
permettra de rentrer plus en détails dans le fonctionnement de ces conditions.
Mais certains événements comme la présence d’un fichier, de
lignes dans une table ou encore la réponse à une requête HTTP peuvent être des
conditions de déclenchement attendues.
Par le paramétrage d’une activité
La manière sans doute la plus simple et basique de relancer
une activité consiste à utilise le paramétrage de l’activité elle-même.
Pour cela, dans la section General du module :
Renseigner un nombre maximum de Retry
Renseigner un intervalle en secondes entre chaque essai
Remarque : le time out par défaut est à 7 jours, il
peut être diminuer.
Il faut toutefois anticiper ici un nombre maximum fini de relances, ce que l’on n’est pas forcément en capacité d’anticiper.
A la première exécution avec succès, les retry ne
sont bien sûr plus pris en compte.
Les activités de type for each ou execute pipeline
ne disposent pas de ce paramétrage.
Avec le composant Until
La documentation du composant Until est disponible sur ce lien
et définit son fonctionnement de la sorte :
The Until activity provides the same functionality that a do-until looping structure provides in programming languages. It executes a set of activities in a loop until the condition associated with the activity evaluates to true. You can specify a timeout value for the until activity in Data Factory.
Nous allons créer ainsi le scénario suivant : sur présence d’un fichier testé par le composant Until, nous déclenchons une activité de copie.
Une variable nommée FileExists, de type chaîne de texte (string), est définie au niveau du pipeline.
A l’intérieur du composant Until, nous allons travailler avec deux activités que sont Get Medatada et Wait.
L’activité Get Metadata permet d’obtenir des informations sur un dataset préalablement défini, comme un checksum de type MD5, le nom, le type ou l’existence d’un item.
Le composant suivant Set variable n’est pas indispensable mais il nous permet d’illustrer ici la manière de conserver dans une variable une partie de l’information obtenue par l’activité Get Metadata.
La valeur de la variable est définie de la sorte :
@string(activity('Get Metadata from Source').output.exists)
On utilisera la fenêtre d’ajout de contenu dynamique pour obtenir directement certaines parties de cette expression.
Enfin, une activité Wait est déclenchée pour laisser un laps de temps s’écouler avant de tester à nouveau la présence du fichier.
Le composant If exists permet de ne pas jouer l’activité
Wait lorsque le fichier attendu est détecté. Il n’est pas nécessaire de définir
la partie True de ce composant.
L’activité Until peut enfin paramétrée à l’aide de
l’expression suivante :
@equals(variables(‘FileExists’),’True’)
Voici enfin une démonstration du fonctionnement complet de ce pipeline.
Suite à mon premier article sur le nouveau programme 2020 de cette certification Microsoft, je continue à décrire les différents outils présents dans le nouveau studio Azure Machine Learning, en suivant le plan donnée par le programme de la certification. Attention, le contenu peut ne pas être exhaustif comme le rappelle la mention “may include but is not limited to“.
Run experiments and train
models
Create models by using
Azure Machine Learning Designer
Le Concepteur (ou Designer en anglais) n’est accessible qu’avec la licence Enterprise et correspond à l’ancien portail Azure Machine Learning Studio. La documentation complète est disponible ici.
Nous cliquons ensuite sur le bouton « + » pour démarrer une nouvelle expérimentation. Mais il sera très intéressant regarder les différents exemples disponibles, en cliquant sur « afficher plus d’échantillons ».
May include but is not limited to:
• create a training
pipeline by using Designer
La première chose à paramétrer est l’association de l’expérience avec une cible de calcul de type « cluster d’entrainement ».
Nous utiliserons ensuite les modules disponibles dans le menu latéral de gauche.
Ces modules nous permettront de construire un « pipeline » dont la structure classique est décrite par le schéma ci-dessous.
• ingest data in a
Designer pipeline
La première étape consiste à désigner les données qui
serviront à l’expérience. Nous choisissons pour cet exemple le jeu de données
« German Credit Card UCI dataset » en réalisant un
glisser-déposer du module de la catégorie Datasets > Samples.
Les jeux de données préalablement chargés à partir des magasins de données sont quant à eux disponibles dans Datasets > My Datasets.
Le module « Import Data » permet de se connecter directement à une URL via HTTP ou bien à un magasin de données.
Il est enfin possible de charger des données manuellement à l’aide du module « Enter Data Manually ».
Ces deux dernières méthodes ne
sont pas recommandées, il est préférable de passer par la création propre d’un
jeu de données dans le menu dédié.
Afin de bien appréhender le jeu de données, nous ajoutons temporairement un composant « Summarize Data », de la catégorie Statistical Functions. Les deux modules doivent être reliés l’un à l’autre, en glissant la sortie du précédent vers l’entrée du suivant.
Nous cliquons sur le bouton « Envoyer » pour exécuter ce premier pipeline.
Un nom doit être donné à
l’expérience (entre 2 et 36 caractères, sans espace ni caractères spéciaux
hormis les tirets haut et bas).
Au cours de l’exécution, une vue d’ensemble est disponible.
Depuis le menu Calcul, un graphique résume l’état des nœuds du cluster d’entrainement.
Une fois les étapes validées (coche verte sur chaque module), les sorties et journaux d’exécution sont accessibles. Le symbole du diagramme en barres donne accès aux indicateurs de centrage et de dispersion sur les différentes variables.
• use Designer modules to
define a pipeline data flow
Nous recommandons d’utiliser l’édition des métadonnées pour identifier la variable jouant le rôle de label. Cette astuce permettra par la suite de conserver un paramétrage des modules utilisant la colonne de type « label ». Il sera également possible de désigner toutes les autres colonnes du jeu de données par « all features » dans les boîtes de dialogue de sélection.
Pour une variable binaire dans la cadre d’une classification, la variable est également déclarée comme catégorielle.
Nous construisons ensuite un pipeline classique de la sorte :
Une fois un modèle entrainé avec succès, un nouveau bouton apparaît en haut à droite de l’écran.
Nous créons un pipeline d’inférence en temps réel pour obtenir un service Web prédictif à partir de notre modèle. Des modules d’input ou d’output sont automatiquement ajoutés.
Il est alors nécessaire d’exécuter une nouvelle fois le pipeline pour ensuite publier le service d’inférence. Le bouton « déployer » est ensuite accessible.
Une fois le déploiement réussi avec succès, le point de terminaison (“endpoint“) est visible dans le menu dédié.
Nous retrouvons dans les écrans dédiés l’URL du point qui donnera accès aux prévisions. Il s’agit d’une API REST, sous la forme suivante :
Une fenêtre de test facilite la soumission de nouvelles données.
L’onglet “consommer” donne enfin des exemples de codes prêts à l’emploi en C#, Python ou R, ainsi qu’un mécanisme de sécurité basé sur des clés ou jetons d’authentification.
• use custom code modules
in Designer
Des modules personnalisés peuvent être intégrés dans le pipeline, en langage R ou Python.
Les modules de script disposent d’entrées et de sorties, accessibles au travers de noms de variables réservés.
Ainsi, pour un script R personnalisé, le modèle de code généré est une structure de fonction :
# R version: 3.5.1
azureml_main <- function(dataframe1, dataframe2){
print("R script run.")
# If a zip file is connected to the third input port, it is
# unzipped under "./Script Bundle". This directory is added
# to sys.path.
# Return datasets as a Named List
return(list(dataset1=dataframe1, dataset2=dataframe2))
}
Les entrées 1 & 2 sont identifiées respectivement sous
les noms dataframe1 et dataframe2.
Les deux sorties sont par défaut nommées dataset1 et
dataset2 et retournées sous forme d’une liste de deux éléments. Il est possible
de modifier ces noms même si cela n’est pas conseillé.
Pour nommer les colonnes du jeu de données German Credit Card, nous utilisons le code R suivant :
azureml_main <- function(dataframe1, dataframe2){
print("R script run.")
colnames(dataframe1) = c("chk_acct", "duration", "credit_his", "purpose", "amount", "saving_acct", "present_emp", "installment_rate", "sex", "other_debtor", "present_resid", "property", "age", "other_install", "housing", "n_credits", "job", "n_people", "telephone", "foreign", "response")
# Return datasets as a Named List
return(list(dataset1=dataframe1, dataset2=dataframe2))
La troisième entrée du module est dédiée à un fichier zip
contenant des librairies supplémentaires. Ces packages doivent être au préalable
installer sur un poste local, généralement dans le répertoire :
C:\Users\[user]\Documents\R\win-library\3.2
Créer
un dossier contenant les sous-dossiers des packages transformés en archives
(.zip) puis réaliser une nouvelle archive .zip à partir de ce dossier. Importer
ensuite l’archive obtenu comme un jeu de données. Le module obtenu sera
raccordé à la troisième entrée du module Execute R/Python Script : Script
Bundle (Zip).
Pour les scripts Python, nous disposons également d’un module permettant de créer un modèle d’apprentissage qui sera ensuite connecté à un module « Train Model ».
Le code Python à rédiger se base sur les packages pandas et scikit-learn et doit s’intégrer dans le modèle suivant :
import pandas as pd
from sklearn.linear_model import LogisticRegression
class AzureMLModel:
# The init method is only invoked in module "Create Python Model",
# and will not be invoked again in the following modules "Train Model" and "Score Model".
# The attributes defined in the init method are preserved and usable in the train and predict method.
def init(self):
# self.model must be assigned
self.model = LogisticRegression()
self.feature_column_names = list()
# Train model
# Param: a pandas.DataFrame
# Param: a pandas.Series
def train(self, df_train, df_label):
# self.feature_column_names record the names of columns used for training
# It is recommended to set this attribute before training so that later the predict method
# can use the columns with the same names as the train method
self.feature_column_names = df_train.columns.tolist()
self.model.fit(df_train, df_label)
# Predict results
# Param: a pandas.DataFrame
# Must return a pandas.DataFrame
def predict(self, df):
# Predict using the same column names as the training
return pd.DataFrame({'Scored Labels': self.model.predict(df[self.feature_column_names])})
Le modèle utilisé peut être remplacé dans la fonction __init__.
Les variables en entrée du modèle peuvent être également listées dans cette
fonction.
(Nous parlerons ici du service cloud Power BI, destiné au partage et à la collaboration. Si vous partagez vos fichiers .pbix, une autre réflexion sera nécessaire 😉 )
Mais tout d’abord, pourquoi bloquer l’export des données depuis les rapports Power BI ?
La méthode radicale : l’interdiction par l’utilisateur
La méthode douce : l’interdiction (ou la limitation) au dataset
La méthode (ultra) fine : le retrait de l’option au niveau du visuel
Enfin, rappelons que tout utilisateur ayant les droits nécessaires et une version d’Excel suffisamment récente peut installer l’extension “Power BI Publisher” qui, comme son nom ne l’indique pas, peut accéder aux datasets hébergés sur le service Power BI et pour lesquels ils disposent des droits suffisants.
Le code utilisé dans un notebook peut échouer pour une raison autre qu’un erreur de développement : fichier absent, API ne répondant pas, etc. Il peut donc être pertinent de relancer automatiquement un traitement en cas d’échec.
La documentation Databricks fournit un exemple de fonction, en Python ou en Scala, qui réalise ce mécanisme. Le code est bien sûr basé sur la fonction dbutils.notebook.run déjà présentée dans un précédent post.
Voici le code en Python, où un nombre d’essais maximum de 3 est paramétré par défaut :
# Errors in workflows thrown a WorkflowException.
def run_with_retry(notebook, timeout, args = {}, max_retries = 3):
num_retries = 0
while True:
try:
return dbutils.notebook.run(notebook, timeout, args)
exceptExceptionas e:
if num_retries > max_retries:
raise e
else:
print "Retrying error", e
num_retries += 1
Et voici ce que l’on obtient à l’exécution. Attention à bien préciser le chemin relatif du notebook ainsi piloté, si celui-ci n’est pas situé au même niveau que le ce “master notebook”.
Attention à ne pas abuser de ce processus ! Il est essentiel de comprendre la nature des erreurs rencontrées et d’y apporter des réponses au travers du code.
Une fois l’infrastructure définie autour d’un cluster Databricks, les notebooks sont les éléments qui vont évoluer au gré des développements. Il faut bien sûr a minima définir deux environnements : l’un de développement, l’autre de production. Nous verrons ainsi plusieurs astuces et bonnes pratiques permettant de réaliser le processus du déploiement continu des notebooks.
Nous avons pu voir dans de précédents articles :
Comment définir un point de montage vers un compte de stockage Azure
Comment versionner les notebooks Databricks par exemple sous GitHub
Nous allons utiliser ici la notion de variable d’environnement, propre au cluster Spark.
Le schéma ci-dessous illustre le mécanisme DevOps qui sera mis en place.
Mais pour l’instant, focalisons-nous sur le chemin menant vers les données. Nous utilisons ici deux environnements identiques d’un point de vue de l’architecture, dont une vision simplifiée est donnée sur le schéma ci-dessous :
L’accès au point de montage défini sur le compte de stockage Azure se fait par exemple au moyen des commandes Databricks dbutils :
dbutils.fs.ls('/mnt/dev/mysfilesystem/')
Les variables d’environnement sont quant à elles définies au niveau d’un cluster. Elles seront donc accessibles de n’importe quel notebook attaché au cluster. Nous les trouvons en dépliant le menu des options avancées, onglet Spark.
Par convention, nous utilisons une casse majuscule pour le nom des variables.
Attention à ne pas mettre d’espace autour du signe « = ». Les guillemets ne sont en revanche pas indispensables autour de la valeur de la variable.
Un redémarrage du cluster sera alors nécessaire, suite à la modification des variables d’environnement.
Maintenant, différentes commandes, dans les langages supportés, vont nous permettre d’accéder aux variables définies. Pour la compatibilité dans un même notebook, les lignes de scripts seront ici précédées du langage dans lequel elles sont écrites, vous pourrez ainsi copier ce code tel quel dans n’importe quel notebook Databricks.
Liste des variables d’environnement :
%sh printenv
Valeur de la variable en Shell :
%sh echo $MOUNT_PATH
Valeur de la variable d’environnement en Python :
%python
import os
key = 'MOUNT_PATH'
value = os.getenv(key)
print("Value of 'MOUNT_PATH' environment variable :", value)
A noter que la commande getenv() peut être remplacée par environ.get() issue également de la librairie os. Les différences entre les deux sont traitées dans cette question sur StackOverFlow.
Valeur de la variable d’environnement en Scala :
%scala
sys.env("MOUNT_PATH")
Il est donc maintenant possible d’utiliser ces variables dans les chaînes d’accès au système de fichier, avec un code qui réagira alors en fonction de l’environnement !
La définition des variables d’environnement est également réalisable si vous utilisez un “automated cluster“, c’est-à-dire un cluster créé à la volée lors du lancement d’un job planifié.
La configuration du cluster est disponible en cliquant sur le bouton “edit”.
La donnée classique et structurée n’a plus de secret pour vous si vous avez lu les deux billets précédents (ici et là) traitant de l’analyse avancée et de la modélisation des données. Pour autant, ces méthodes sont valables, et performantes, lorsque la donnée est de type alphanumérique et organisée sous forme tabulaire. Pour les données dites non structurées comme les images, le son ou encore le texte rédigé, il faut faire appel à un tout autre arsenal d’outils.
Du temps, de la puissance et des données
Soyons pragmatiques, pour être ingérée par un algorithme,
toute donnée devra devenir numérique mais le cheminement pour y arriver va être
complexe. Des approches comme la métrique TF-IDF ont fait leurs preuves, pour
le référencement de documents pertinents dans des corpus de textes. Cela reste
vrai tant que la puissance de calcul disponible est suffisante, et donc le
volume de données relativement raisonnable. Dans le domaine des images, on
distinguera deux usages principaux : la classification (catégoriser
une image parmi des labels existants) et la reconnaissance d’objets
(présence et position sur l’image). Les progrès ont été remarquables avec
l’arrivée (voire le retour…) des réseaux de neurones dits profonds, ce que l’on
nomme le « Deep Learning ».
Les frameworks de Deep Learning sont aujourd’hui nombreux :
Cognitive Toolkit créé par Microsoft, TensorFlow mis en place par Google ou
encore PyTorch. Leur maîtrise implique une bonne connaissance du fonctionnement
mathématique des réseaux de neurones et de l’état de l’art des différents types
de couches de neurones pouvant être utilisées. Mais ensuite, il faudra beaucoup de données et beaucoup de
puissance de calcul pour obtenir un modèle performant.
C’est ici que le mécanisme du Transfer Learning prend
tout son intérêt. En effet, au fur et à mesure des couches du réseau de
neurones profond, l’apprentissage va se spécifier. Pour donner une image
didactique, on pourrait dire que l’algorithme commence par reconnaître des
formes simples avant d’identifier des formes plus complexes. C’est d’une
certaine manière ce que font nos yeux et notre cerveau lorsque nous découvrons
un nouvel environnement. J’entre dans un nouveau bâtiment et je vois des
bureaux, des écrans, des tasses à café, un babyfoot, je reconnais… l’open space d’une ESN parisienne !
Les services cognitifs
Imiter les capacités humaines de perception ou de cognition
est depuis longtemps un défi pour le monde de l’informatique et la discipline
de l’Intelligence Artificielle s’y emploie, présentant des succès majeurs
depuis quelques années. Pensons ici à la qualité des outils de traduction automatique,
à l’efficacité de la transcription orale en texte ou encore à la pertinence des
moteurs de recommandation.
Les départements de Recherche et Développement des géants du
numérique rivalisent de performances dans ces différents domaines et mettent à
disposition leurs algorithmes, en les encapsulant dans des interfaces (web,
API, SDK…) facilitant leur utilisation. En ce sens, nous pouvons parler d’Intelligence
Artificielle as a Service !
Les services cognitifs de Microsoft se répartissent en cinq catégories présentées sur l’image suivante.
Documentation Microsoft
Plusieurs de ces services sont accessibles en démonstration
ou test sur le site de
Microsoft. Pour une utilisation plus régulière et dans un cadre professionnel, un
abonnement Azure sera nécessaire.
Pour une entreprise est convaincue de la création de valeur
potentielle au travers des données non structurées (texte, image, son, vidéo…),
elle doit dorénavant s’interroger sur la faisabilité d’un développement
équivalent : existe-t-il des ressources (personnes et machines) capables
de produire le niveau de performance attendu des algorithmes ? A la
négative, il pourra être très intéressant d’exploiter les services cognitifs.
Microsoft Custom Vision
Le site customvision.ai
de Microsoft vous permet de vous lancer rapidement dans l’évaluation de modèles
de classification ou de reconnaissance d’objets, sans avoir à saisir une seule
ligne de code !
Identifiez-vous sur le portail, avec votre compte Azure. Il sera possible de créer et conserver simultanément deux projets sur la plateforme, et ce, sans facturation. Dans l’exemple ci-dessous, nous choisissons un projet de type « Object detection ». Notre cas d’usage sera ici d’identifier l’existence d’un panneau de limitation de vitesse sur une photo.
Il sera alors nécessaire de créer ou d’associer un groupe de ressources Azure. Si cette
notion ne vous parle pas, rapprochez-vous des administrateurs de votre
souscription Azure.
Trois domaines sont proposés : il s’agit ici de
spécifier le « début » du réseau de neurones profond qui sera employé
dans notre démarche d’apprentissage par transfert. Nous restons ici sur le
domaine général. L’utilisation du domaine « Logo » permettrait de
bénéficier de couches de neurones déjà entrainées à la reconnaissance de logos
de marques commerciales.
Chargement des images et ajout de tags
L’écran suivant correspond à l’interface de chargement des données et d’entrainement du modèle. Nous rentrons ici dans la logique dite supervisée de l’apprentissage automatique : il faut fournir des exemples que le réseau interprétera pour construire le modèle, qui lui permettra ensuite de réaliser des prévisions. En résumé, prédire le futur correspond à reproduire le passé, en le généralisant !
La première étape consiste à charger des images (« add images ») à partir de l’ordinateur que nous utilisons. Ces images peuvent être de format .jpg, .png, .bmp ou .gif et il n’y a pas d’exigence à ce qu’elles soient de la même résolution. Le poids de l’image utilisée en entrainement ne pourra pas dépasser 6Mo et 4Mo en prévision. Les images dont la largeur se situe en dessous de 256 pixels sont automatiquement remises à l’échelle par le service.
Un minimum de 15 images est requis pour débuter un modèle de détection d’un objet. Toutefois, il faudra viser une cinquantaine d’images pour une première expérience significative et s’en tenir à des cas d’usage relativement « visibles ». Même si la technologie s’en rapproche, ce n’est pas cet outil qui sert par exemple à détecter des pathologies dans des clichés médicaux.
Il est maintenant nécessaire de travailler chaque image en entourant la zone souhaitée (ici le panneau rond de limitation) et en y associant un « tag » (mot clé identifiant l’objet). C’est la partie manuelle et sans doute la plus rébarbative de l’entrainement du modèle.
Si l’on souhaite reconnaitre plusieurs objets, il sera
nécessaire de compter au moins 15 images par objet.
Première itération du modèle
Lors de la phase d’entrainement, l’algorithme cherche à
réduire l’erreur de prévision sur la base des images déjà taguées.
Deux types d’entrainement sont disponibles :
Fast training
Advanced training
Deux règles s’appliquent ici de manière assez générale :
Plus il y a beaucoup de données, plus le temps
d’entrainement sera long et meilleur sera le modèle.
Plus l’entrainement est long ou sollicite de
machines puissantes, plus celui-ci sera cher.
L’entrainement peut durer plusieurs minutes et s’étendre sur
plusieurs heures en cas de volumétrie et de complexité importante. Nous
privilégions ici dans un premier temps l’entrainement rapide.
Evaluer et tester le modèle
Le menu Performance permet de consulter les indicateurs de
qualité du modèle.
La précision correspond,
pour un tag donné, à la proportion d’images correctement classées ou avec une
reconnaissance d’objets exacte sur l’ensemble des images.
Le rappel (Recall)
correspond à la proportion d’images appartenant réellement à une classe parmi
toutes les images prédites dans cette classe.
On définira le seuil de probabilité (Probability Threshold) pour savoir si la confiance dans une
prévision est suffisante pour classer une image ou détecter un objet.
Le score mAP
(mean Average Precision) est un calcul synthétisant les indicateurs de
précision et de rappel, en moyenne pour l’ensemble des classes ou des objets à
détecter.
On cherchera à maximiser ces trois indicateurs mais attention,
ce n’est pas forcément souhaitable que de disposer d’un modèle
« parfait » comme sur l’illustration ci-dessus. La perfection en
apprentissage automatique est nommée surapprentissage (« overfitting »)
et peut se traduire par un manque de capacité de généralisation. Concrètement,
le modèle a de forts risques d’échec dès que de nouvelles images dévieront des
images d’entrainement.
Une solution consiste ici à augmenter le nombre d’images
utilisées pour l’apprentissage, en prenant soin de varier les contextes d’images (routes de jour / de nuit, panneaux
étrangers, etc.).
L’interface de Custom Vision nous propose maintenant de tester le modèle établi.
Nous utilisons bien sûr ici une image qui n’a pas servi à
l’entrainement du modèle. Il est possible d’utiliser une image de l’ordinateur
local ou bien une URL web d’image.
Il sera également possible de comparer les résultats du test sur les différentes itérations d’entrainement.
Sur cette première image, le panneau est bien identifié avec une probabilité de plus de 98% mais nous observons également que l’arrière du camion a été analysé comme un panneau. Pour autant, la probabilité est très faible (< 25%) et nous pourrons rejeter cette hypothèse en définissant un seuil d’acceptation.
Le panneau de limitation est bien identifié, avec un score de confiance dépassant 82%
Sur ce second test, deux panneaux sont identifiés avec une
probabilité forte (> 80%) d’être une limitation de vitesse. Ce n’est
pourtant le cas que sur le panneau de bas. Nous devons à nouveau grossir le jeu
d’entrainement, en incluant plus de diversité de panneaux et relancer une
itération !
Microsoft donne plusieurs conseils pour améliorer un
classifieur sur cette page.
Un principe générique consistera à ajouter des images variées selon l’arrière-plan,
l’éclairage, les tailles d’objet, les angles de vue…
Exploiter le modèle depuis une application tierce
Bien sûr, un usage professionnel du modèle obtenu ne pourra
se faire au niveau du portail. On utilisera une application tierce qui appellera
le modèle au travers d’une API.
Le modèle obtenu au travers de la meilleure itération doit tout d’abord être publié (bouton « Publish ») et associé au groupe de ressources préalablement défini sur le portail Azure.
En cliquant ensuite sur « Prediction URL », on obtiendra l’URL et la clé de prévision (prediction URL & prediction-key). L’URL de prévision est aussi appelée endpoint.
La prediction key est aussi visible depuis le portail Azure, au niveau de la ressource créée pour l’utilisation du service Custom Vision.
Deux kits de développement (SDK) existent également et
permettent de réaliser l’ensemble des étapes en programmation .NET
(téléchargeables pour l’entrainement
et la prévision)
ou en Python à l’aide de la commande suivante :
Décrire, approfondir, prédire sont les trois étapes d’une analyse avancée de données, auxquelles il est possible d’ajouter « prévenir » ou « prescrire » qui sont l’aboutissement d’une stratégie pilotée par la data.
Nous avons vu dans un précédent billet comment l’approche statistique permettait d’identifier des facteurs explicatifs dans les données, en particulier quand une variable est centrale dans l’analyse et qu’elle joue le rôle de variable à expliquer. Il s’agit tout simplement de la donnée qui répond à la problématique principale : le chiffre d’affaires ou la marge pour une entreprise, le taux de conversion pour un site de e-commerce, la présence d’une pathologie ou dans l’exemple que nous reprenons ci-dessous, la gravité d’un accident pour la sécurité routière.
L’apprentissage automatique supervisé
Nous entrons ici dans la discipline dite du Machine Learning ou apprentissage automatique. Le Machine Learning se base sur des événements passés pour construire un modèle statistique qui sera ensuite appliqué à de nouvelles données (ici, les caractéristiques d’un accident de la route). En fonction de ces données et du modèle, une prévision du résultat (la variable à expliquer, ici la gravité de l’accident) sera rendue, accompagnée d’une probabilité exprimant la chance ou le risque qu’un tel résultat se produise.
Lorsque la variable prédite est catégorielle, voire au plus
simple, binaire, on parle de techniques de classification.
Certaines méthodes de classification ont fait leurs preuves depuis de
nombreuses années : régression logistique, arbre de décisions, Naïve
Bayes. Elles ont été, avec l’essor du Big Data, complétées par des algorithmes
puissants mais gourmands en ressources de calcul comme les forêts
aléatoires (random forest) ou le
Gradient Boosting (XGBoost),
Une approche de développement : le langage Python
Les Data Scientists disposent aujourd’hui d’un grand panel
d’outils pour travailler la donnée et entraîner des modèles de Machine
Learning. Il existe ainsi des plateformes graphiques permettant de construire le
pipeline de données (la Visual Interface d’Azure Machine
Learning Service, Alteryx, Dataïku DSS, etc.). Une autre approche, souvent
complémentaire, consiste à utiliser un langage de développement comme R, Python
ou encore Scala, ce dernier pour une approche distribuée dans un environnement
Spark.
Lorsque la volumétrie de données permet de travailler en
plaçant le jeu de données (dataset)
complet en mémoire, les langages R et Python sont tout à fait appropriés. Nous
choisirons ici Python pour la simplicité d’usage et l’efficacité de sa
librairie dédiée au Machine Learning : scikit-learn.
Les développeurs apprécieront d’utiliser un environnement de
développement intégré (IDE) comme Visual
Studio Code ou PyCharm. Pour donner plus de lisibilité à notre code, nous
choisissons pour cet article de travailler dans un notebook Jupyter qui permet d’alterner dans une même page, code,
sorties visuelles et commentaires.
Afin de maîtriser les ressources de calcul qui seront associées à l’exécution des traitements, il est également possible de souscrire à un espace de travail Azure Machine Learning Service. Celui-ci permet de lancer une machine virtuelle de son choix sur laquelle sont déjà configurés les notebooks Jupyter ainsi que l’environnement Jupyter Lab.
Dans la fenêtre Jupyter Lab ci-dessous, nous retrouvons le code à exécuter ainsi qu’un menu latéral permettant de naviguer dans les fichiers précédemment téléchargés dans l’environnement.
L’indispensable préparation des données
Avant de soumettre les données chargées à l’approche algorithmique, il est nécessaire d’effectuer quelques calculs préparatoires pour mettre en forme les données et les rendre utilisables par les différents algorithmes.
Ainsi, la date et l’heure de l’accident sont exploitées pour créer deux nouvelles variables : le jour de la semaine et la tranche horaire.
Ces deux calculs illustrent le principe du feature
engineering, c’est-à-dire du travail sur les variables en entrée du
modèle pour proposer les plus pertinentes et les plus efficaces. Attention, il
n’est parfois pas possible de le déterminer a
priori. Au-delà de toute formule mathématique et en l’absence d’une
quelconque baguette magique, des échanges
avec les personnes ayant une connaissance métier forte seront très
profitables aux Data Scientists et les orienteront vers une bonne préparation
des données.
Modéliser, entraîner, évaluer
Nous comparons ici deux modèles, l’un étant un modèle
« simple » : celui des K plus proches voisins, le second étant
un modèle « ensembliste », c’est-à-dire combinant plusieurs
modèles : une forêt aléatoire d’arbres de décisions.
Une fois l’entraînement réalisé, nous pouvons calculer
différentes métriques évaluant la qualité des modèles.
Nous observons tout d’abord la matrice de confusion qui nous permet de comparer la valeur prédite (décès ou non) avec la valeur réelle qui a été « oubliée » le temps du calcul de la prévision.
Nous observons ici 6 449 « faux positifs »,
personnes réellement décédées suite à l’accident, pour lesquelles l’algorithme
n’a pas été en mesure de prévoir ce niveau de gravité. Il sera possible de
jouer sur le seuil de la probabilité de décès (par défaut à 50%) pour réduire
ce nombre.
Une vision graphique de ces informations est possible au travers de la courbe ROC et du calcul de l’aire situé sous cette courbe : l’AUC. Cet indicateur prend une valeur en 0 et 1 et plus celle-ci s’approche de 1, meilleur est le modèle.
Nous retenons ici le modèle de la forêt aléatoire (AUC = 0.730 contre 0.597), tout en étant bien conscients que son coût de calcul est plus élevé que celui des K plus proches voisins. Une propriété de l’objet nous permet d’obtenir un coefficient d’importance des variables dans le modèle. Cette information est particulièrement appréciable pour prioriser par exemple une campagne d’actions contre la mortalité sur les routes. Nous remarquons dans le top 10 ci-dessous que l’année de naissance de la personne, et donc son âge au moment de l’accident, constitue le facteur le plus aggravant. Viennent ensuite des informations sur la temporalité de l’accident (tranche horaire, mois, etc.) puis enfin le motif de déplacement (trajet), la déclivité de la route (prof), le type de collision (col), le nombre de voies (nbv) et le tracé de la route (plan). Ces derniers facteurs sont toutefois 4 à 5 fois moins importants que l’âge de la personne impliquée.
Le meilleur modèle est enfin enregistré dans un format binaire sérialisé (package pickle) afin d’être exploité par la suite en production, comme le permet par exemple la ressource Azure Machine Learning Service.
Plus vite vers le meilleur modèle : l’Automated Machine Learning
Le travail de sélection du meilleur modèle (ainsi que de ces meilleurs hyper paramètres, c’est-à-dire le réglage fin de l’algorithme) peut s’avérer une tâche répétitive et fastidieuse car il n’existe pas réellement à l’heure actuelle de méthode ne nécessitant pas de réaliser toutes les évaluations. « No free lunch » !
Heureusement, l’investigation peut se faire de manière automatique, sorte de « force brute » du Machine Learning. Au travers d’Azure Machine Learning Service, nous soumettons le jeu de données à une batterie d’algorithmes qui seront comparés selon leur performance sur les différentes métriques d’évaluation.
Nous retenons ici l’approche XGBoostClassifier dont l’AUC
atteint la valeur 0.867, soit 0.137 point supplémentaire, par rapport au modèle
trouvé manuellement.
L’approche prédictive, au travers du Machine Learning, se révèle être incontournable pour quiconque souhaite aujourd’hui anticiper les valeurs de ses données et découvrir des leviers d’action qui permettront de mettre en place des actions concrètes pour par exemple, éviter l’attrition (churn) d’une clientèle, prévenir d’un défaut de paiement ou d’une tentative de fraude, élaborer un premier diagnostic ou encore anticiper des pannes.
En conclusion, nous avons vu ici que le cloud Azure se marie au meilleur de l’Open Source pour devenir une plateforme parfaite pour les Data Scientists et les Data Engineers.
(*) Revenir à l’essentiel : l’analyse des données !
Intelligence Artificielle,
Machine Learning, RGPD… la donnée ne quitte plus le devant de la scène
médiatique, qui attribue bien souvent à la data des pouvoirs thaumaturges. Le
monde du recrutement s’emballe autour des profils « Data Scientists »
tout en présentant des listes de compétences impossibles à maîtriser pour une
seule et même personne, allant de l’architecture Big Data à la programmation de
réseaux de neurones convolutifs (le fameux Deep Learning). A l’exception des entreprises
dont la data constitue le cœur de métier comme Booking, AirBNB ou Uber, quelles
sont celles qui ont réellement modifié et amélioré leur activité par une approche
« data driven »,
c’est-à-dire pilotée par la donnée ? Ce phénomène de « hype » autour de la donnée peut
poser question et générer une certaine méfiance.
Pourtant, une réaction inverse qui reviendrait à rejeter tout apport de la donnée serait aussi improductive. Et tant qu’à stocker la data, autant en tirer profit ! Dans une série de trois articles, nous nous arrêterons successivement sur l’intérêt, pour les entreprises, de l’analyse de données exploratoire, l’analyse prédictive grâce au Machine Learning et les promesses du Deep Learning sur les données non structurées.
Une même finalité, de nouveaux outils
Bien avant l’explosion de l’engouement pour la Data Science, certaines personnes dans l’entreprise pratiquaient déjà l’analyse de données sous des intitulés de poste tels que « chargé.e d’études statistiques », « statisticien.ne », « actuaire », « data miner », etc. Souvent éloignées du département IT et des architectures de production, ces personnes en charge de forer la donnée réalisent des extractions puis travaillent ces échantillons dans un classeur Excel ou un logiciel spécialisé. Une fois les conclusions obtenues, celles-ci figurent dans une présentation au format Word ou PowerPoint, c’est-à-dire sans possibilité simple de mise à jour ni d’extension à d’autres données. Nous allons voir ici que c’est aujourd’hui, non pas un bouleversement méthodologique, mais bien une simplification et une meilleure performance des outils qui changent ces métiers.
Notre approche méthodologique visera à répondre aux quatre temps de l’analyse de données.
Les quatre temps de l’analyse de données
Prenons un exemple concret : l’analyse des accidents corporels de la circulation pour laquelle les données sont disponibles en open data sur le portail data.gouv.fr.
Pour une première
approche du jeu de données, nous travaillerons dans l’outil Microsoft Power BI Desktop qui, même s’il
n’est pas un logiciel statistique à proprement parler, permet de nettoyer et
visualiser les données très rapidement. Nous verrons même qu’il cache plusieurs
fonctionnalités analytiques particulièrement intéressantes. Enfin, lorsque
l’étude exploratoire sera terminée, il ne sera plus nécessaire de quitter
l’outil pour présenter les résultats dans un logiciel bureautique figé.
L’interface proposera une visualisation dynamique et adaptée à la restitution.
L’indispensable nettoyage des données
Observons tout d’abord le
schéma des données collectées, dont la description précise des champs est
disponible dans ce document. Nous travaillerons ici avec les notions
de :
Caractéristiques de l’accident
Lieu de l’accident
Véhicules impliqués
Usagers des véhicules impliqués
Modélisation des données dans Power BI Desktop
La qualité des données en entrée déterminera la qualité des résultats qui seront obtenus (ou tout du moins, garbage in, garbage out !). Un travail d’inspection de chaque champ est nécessaire et celui-ci se fait rapidement grâce au profil de la colonne, comme par exemple ci-dessous, sur l’année de naissance de l’usager.
La lecture des indicateurs de synthèse (moyenne, médiane, écart-type, etc.) nous permet de débusquer des valeurs aberrantes (un conducteur né en 1924, cela reste plausible) et de comptabiliser des valeurs manquantes qui nécessiterait un traitement spécifique (ici, toutes les lignes sont renseignées.)
L’interaction pour une meilleure
exploration des données
L’une des grandes forces de Power BI réside dans son haut niveau d’interaction avec la donnée, au moyen de filtres visuels ou en sélectionnant un élément graphique pour obtenir instantanément la mise à jour des autres visuels.
L’analyse descriptive est ainsi rapidement obtenue. A vous de jouer, ce rapport est totalement interactif !
Bien sûr, il ne faudra
pas tomber dans le travers de chercher à filtrer sur toutes les dimensions
possibles ! L’être humain n’est pas en capacité d’appréhender un trop
grand nombre d’informations mais les méthodes d’analyse avancée sont là pour
nous aider.
Des fonctionnalités pour l’analyse
explicative
Observons l’évolution du nombre d’accidents dans le temps, au niveau annuel. On constate une hausse en 2016 avec un recul des accidents sur les années précédentes.
Expliquer (automatiquement) la hausse
Power BI va rechercher les facteurs explicatifs de la hausse de l’indicateur en testant tous les champs du modèle et nous fera plusieurs propositions. Nous retenons ici celle du département de l’accident qui met en évidence une hausse significative sur les départements d’Ile-de-France 75 et 93, contre une baisse dans les Alpes-Maritimes. Cette piste nous mettrait sur la voie de données décrivant ces départements (population, infrastructures routières, etc.).
Visuels générés automatiquement par Power BI : l’utilisateur choisit le plus parlant.
L’analyse faite jusqu’ici
nous permet de comprendre les données dans leur ensemble mais il est
fondamental de répondre à une problématique levée par le sujet, ici
l’accidentologie, et nous allons donc rechercher des explications à la
mortalité routière.
Nous disposons pour cela d’une information sur la gravité de l’accident qui permet de déterminer si l’usager est décédé.
Influenceurs clés : une régression logistique visuelle !
L’analyseur d’influenceurs clés (key influencers, basé sur une approche de modélisation par régression logistique) identifie la non utilisation d’un équipement de sécurité (ceinture, casque, etc) comme le facteur le plus fort dans un décès lié à un accident : la probabilité est presque multipliée par 6. L’âge est également un facteur très important. Si celle-ci est inférieure à 1932, le risque de décès est ici multiplié par 4.
Nous obtenons ici, grâce
à l’analyse, des leviers d’actions concrets pour la sécurité routière, ce qui
constitue une première forme d’analyse prescriptive
… et une première analyse prédictive !
Reprenons l’évolution du
nombre d’accidents dans le temps mais cette fois-ci, au niveau mensuel. La
courbe traduit clairement une notion de saisonnalité : il y a beaucoup
(trop) d’accidents lors des périodes de vacances scolaires par exemple. Si l’on
ajoute une droite de tendance, on voit que celle-ci est légèrement à la hausse.
Prolonger cette droite ne donnerait pas une bonne prévision au détail mensuel
puisqu’il faut tenir compte de cette saisonnalité.
Nous utilisons ici la fonctionnalité de « forecast » de Power BI basée sur la méthode statistique du lissage exponentiel. N’allons pas trop loin, il est conseillé de ne pas dépasser une prévision au tiers de l’historique disponible. Cette prévision est encadrée par un intervalle de prévision, donnant les bornes entre lesquelles on espère voir apparaître la « vraie » valeur, avec un niveau de confiance de 95%.
Paramètres de la prévision
On obtient alors la prévision sur le graphique et l’infobulle donne les valeurs chiffrées.
Une présentation dynamique sans changer
d’outil
Résumons maintenant toutes les informations découvertes au travers de cette première analyse. Pour communiquer ces résultats, nous pourrions utiliser un support externe comme PowerPoint ou un fichier PDF mais nous perdrions toute interaction. Les bookmarks (ou signets) de Power BI sont ici un outil extrêmement pratique pour garder en mémoire une sélection personnalisée de filtres et enchainer la lecture de plusieurs pages de rapport comme l’on enchainerait des diapositives.
Cette certification Microsoft a vu
son contenu complètement remis à jour au 22 janvier 2020. Le contenu tourne
maintenant exclusivement autour de Azure Machine Learning Service. Mais ce
service Azure et son portail d’accès (dit le « studio ») regorgent
d’outils aussi bien graphiques (Designer, Automated ML) que destinés au code
(SDK et la librairie azureml.core). Dans cet article, je vous propose mes notes
préparatoires à cette certification, en conservant la terminologie d’origine et
non la traduction française car la certification se passe en anglais.
A la question qui m’est fréquemment posée sur les conseils pour réussir les certifications Microsoft, je réponds toujours : de la pratique, de la pratique et encore de la pratique. Prenez également soin de noter les noms des différents services ainsi qu’une courte définition de leurs rôles respectifs.
Page d’accueil de la certification DP-100
Si vous n’avez jamais passé de certifications Microsoft, sachez qu’il s’agit essentiellement de QCM et que vous pourrez revenir en arrière sur la plupart des questions, à l’exception des « Yes/No questions ».
La formulation « May include but is not limited to» qui revient tout au long du
programme de la certification met en garde sur le fait que certaines questions
pourront sortir de cette liste.
Set
up an Azure Machine Learning workspace (30-35%)
Create an Azure Machine
Learning workspace
May include but is not limited to:
create an Azure Machine Learning workspace
Le workspace (ou espace de travail) désigne la ressource
Azure qu’il est nécessaire de créer afin d’accéder aux fonctionnalités d’Azure
ML Service et en particulier au portail encore appelé « studio ». Ce
dernier est aussi accessible depuis l’URL https://ml.azure.com/ et attend votre identifiant et mot de passe reconnu par Azure
Active Directory.
Le terme « studio » peut porter à confusion car la première ébauche du Designer s’est appelée Azure Machine Learning à sa création, puis Azure Machine Learning Studio. Il est encore possible de s’inscrire sur cette ressource renommée « classic » et accessible sur l’URL https://studio.azureml.net/ sans inscription préalable sur le portail Azure. Cette interface correspond aujourd’hui au Designer (Concepteur en français) qui s’est lui-même rapidement appelé « Visual interface ».
Azure Machine Learning Studio (classic)
Depuis la Marketplace Azure, dans la catégorie AI + Machine Learning, rechercher le service « Machine Learning ».
Ressource Azure Machine Learning
Aucun paramétrage particulier si ce n’est le choix de la licence entre Basic et Enterprise. Nous indiquerons plus tard les fonctionnalités uniquement disponibles en version Enterprise.
Création de la ressource
A noter que la création de cette ressource engendrera la
création simultanée :
d’un compte de stockage (Azure
Storage)
d’un coffre fort (Azure Key
Vault)
d’un outil de monitoring (Azure
Application Insights)
Par la suite, de nouveaux services pourront être ajoutés, pour
l’exposition des services prédictifs :
Azure Container Instance
Azure Kubernetes Service
Lien vers le portail
configure workspace settings
Le menu latéral de l’interface Azure donne les entrées classiques d’une ressource. Le groupe de fonctionnalités Assets correspond à l’ensemble des manipulations qui pourront être faites depuis le portail dédié.
On définira en particulier l’accès des autres personnes à la ressource en configurant l’Access Control (IAM).
Access Control (IAM)
Il est également possible de télécharger un fichier de configuration JSON dont nous comprendrons l’intérêt lorsque nous réaliserons des interactions avec les fonctionnalités depuis un script.
Enfin, La page de la ressource Azure donne le lien vers le studio et lancera le portail dédié dans un nouvel onglet du navigateur.
Connexion au portail Azure Machine Learning studio
manage a workspace by using Azure Machine Learning Studio
A partir de cet item du programme, nous passons sur le portail (dit « studio »), à ce jour (février 2020) toujours en préversion. La barre latérale permet de naviguer dans les différentes parties du studio dont deux uniquement sont exclusives à la licence Enterprise : Automated ML et Designer.
Les seuls paramètres disponibles concernent la langue d’affichage et les formats régionaux. Pour préparer la certification, nous recommandons d’utiliser l’anglais pour l’interface.
Si l’on dispose de plusieurs ressources Azure ML Service, sur une ou plusieurs souscriptions, il sera possible de passer de l’une à l’autre sans quitter le portail.
Manage data objects in an
Azure Machine Learning workspace
May include but is not limited to:
register and maintain data
stores
Les data stores sont des sources de données répertoriées dans le but de mettre ensuite à disposition des datasets.
La création d’un nouveau datastore se fait à partir de
l’écran ci-dessous, pour l’instant uniquement à partir de ressources Azure de
type compte de stockage (Blob, file share ou Data Lake) ou service
managé de bases de données (SQL DB, PostgreSQL ou MySQL).
Les informations habituelles d’authentification seront attendues. Il n’est pas possible à ce jour de pointer vers un coffre-fort de type Azure Key Vault déjà paramétré.
Pour le paramétrage d’un compte de stockage, il faudra
descendre du niveau du container, c’est-à-dire le premier niveau
d’organisation des données.
L’étape suivante de création d’un jeu de données sera
indispensable pour donner réellement accès aux données depuis les interfaces de
traitement.
create and manage datasets
Les datasets (jeux de données) sont également créés depuis le menu latéral.
Cliquer ici sur le bouton « Create dataset ».
Les datasets sont issus des data sources définis
préalablement (« from datastore ») mais peuvent aussi venir d’autres sources :
Cette initiative de Microsoft met à disposition des jeux de données Open Data, très utiles pour tester rapidement un algorithme et prendre en main l’interface. J’utilise dans les exemples ci-dessous le jeu de données « diabetes ».
Une fois le jeu de données chargé, de nombreuses
fonctionnalités sont disponibles.
Les datasets sont tout d’abord versionnés, il est donc possible de revenir à une version précédemment chargée.
Le bouton Refresh réalise l’actualisation du jeu de
données.
La génération du profil (« Generate profile ») demande une ressource de calcul de type « training cluster » (voir ci-après).
La génération du profil est considérée comme « le run d’une experiment », notion qui sera revue plus tard.
Une fois la préparation terminée, le menu Explore
donne les informations suivantes par variables :
Distribution
Type (string, integer, etc.)
Min, Max
Count, Missing count, Empty count,
Error count
La fonctionnalité Unregister supprime simplement le jeu de données de l’interface, mais le datastore correspond est conservé.
Le menu Consume est particulièrement pratique puisqu’il donne les lignes de script Python permettant de charger le jeu de données sous forme de pandas dataframe.
Le menu Explore donne également un aperçu des lignes du jeu de données.
Le menu Models ne sera renseigné que lorsqu’un
premier modèle aura été entrainé à partir du jeu de données.
Enfin, il reste une fonctionnalité très prometteuse : Datasets monitor. Si j’interprète bien la documentation, il s’agira de détecter l’éventuelle dérive prédictive d’un modèle de Machine Learning (ce que l’on nomme parfois silent failure).
Le monitoring peut être défini à des fréquentes quotidienne, hebdomadaire ou mensuelle.
Les alertes sont envoyées à une adresse email en cas de
dépassement d’un seuil défini arbitrairement.
Manage experiment compute
contexts
May include but is not
limited to:
create a compute instance
Les cibles de calcul sont indispensables pour le
lancement de tout traitement, quelque-soit l’outil mis en œuvre (notebook,
pipeline, endpoint…). C’est aussi ce qui induit sur la facturation du service
Azure. Tant que le service Azure Machine Learning est en préversion, il
n’existe pas de coefficient multiplicateur sur le montant associé à la
ressource de calcul.
Les compute instances (instance de calcul) remplacent dorénavant les « notebooks VM » comme annoncé ici.
Une instance de calcul se paramètre de la manière suivante :
Les instances de calcul disposent
d’environnements et d’outils déjà installés pour R et Python, et en particulier
le SDK
Python d’Azure Machine Learning. Nous évoquerons ce SDK au cours des
prochains points de cette préparation. Nous trouvons ainsi un raccourci pour
lancer RStudio et deux autres pour Jupyter et JupyterLab sur lesquelles le
kernel Python 3 sera disponible.
Pensez à arrêter vos instances de calcul une fois que vous
ne les utilisez plus, afin d’arrêter la facturation (hormis celle associée au
disque).
determine appropriate compute specifications for a training workload
Le tableau suivant, issu de la documentation officielle Microsoft, donne les correspondances entre les cibles de calcul et les différentes approches permettant de réaliser du Machine Learning.
Nous reviendrons plus tard sur la notion de pipeline.
Celle-ci peut être comprise comme la succession d’étapes nécessaires dans un
projet de Machine Learning : préparation des données (sélection des
variables, normalisation…), entrainement du modèle, calcul des métriques d’évaluation,
etc.
Les cibles de calcul doivent être différenciées des cibles
de déploiement dont le rôle sera de porter le modèle prédictif une fois que
celui-ci aura été entrainé et validé.
create compute targets for experiments and training
Un training cluster est un environnement managé constitué d’un ou plusieurs nœuds, qui ne sont autres que des machines virtuelles, dont les caractéristiques seront choisies lors de la création du training cluster. La documentation complète est disponible ici.
Le nouveau cluster apparaît alors dans la liste des ressources de calcul disponibles.
A l’inverse d’une instance de calcul, le training cluster ne
peut être éteint mais il passera par différents états. En cliquant sur le nom
du cluster, nous accédons aux compute details qui donnent en particulier
l’état du cluster :
Idle
Leaving
Preparing
Running
Preempted
Unsuable
L’état Idle (inactif) correspond à l’état lorsque le
cluster est arrêté.
Enfin, le menu attached compute permet d’associer une ressource Azure déjà créée et de l’utiliser ainsi pour des tâches réalisées dans Azure Machine Learning. Seules les machines virtuelles Linux Ubuntu sont supportées. Il est ainsi possible d’exploiter l’image Data Science Virtual Machine, préconfigurée avec les principaux packages utilisés en Data Science, et récemment mise à jour (fin 2019).
Afin de terminer le tour de ce menu, nous évoquons les cibles de déploiement que sont les inference clusters. Ceux-ci servirontpour supporter les Web services Web prédictifs, une fois qu’un modèle aura été entrainé et déployé. Ces clusters sont basés sur le service managé Kubernetes d’Azure et créeront une ressource correspondante dans le groupe de ressources contenant l’espace de travail Azure Machine Learning. Nous aborderons ce point dans le 4e chapitre de la préparation à cette certification.
En version Dev-test, un seul nœud est proposé contre
3 minimum pour un cluster de production.
Nous terminons ici le premier chapitre du programme de la
certification DP-100, nouvelle version. Celui-ci a permis de découvrir
l’environnement de travail, les principales configurations et la mise à
disposition des données, accompagnées par des ressources de calcul. Maintenant,
il va être temps de coder !
Un post rapide pour vous donner le programme de cet événement que j’ai le plaisir de co-organiser.
Un triple merci à l’attention :
de l’ESGI qui nous accueille dans ses locaux
des communautés GUSS et AZUGfr dont les membres participent à l’organisation
des entreprises Cellenza et Azeo qui sponsorisent l’événement et plus directement l’accueil petit déjeuner
A ce jour (12/12/2019), l’événement est “sold out” depuis plus d’une semaine, ce qui nous conforte dans l’idée que parler d’IA est aujourd’hui une priorité à la fois professionnelle et sociétale.
N’oublions pas enfin que Global AI Bootcamp est un événement mondial, porté par la Global AI Community et Microsoft.
Voici le lien vers la carte des 130 villes organisatrices dans le monde :
