Machine Learning de bout en bout avec Amazon SageMaker

Transcript

Pour ce dernier webinar de la semaine, incroyable, on ne voyait pas le bout, même si on s'amuse beaucoup, on est quand même content d'en finir. On va donc parler de SageMaker, qui est un service managé qui va vous permettre de gérer vos workflows, vos processus de machine learning de bout en bout. On l'a vu à l'instant, c'est un service qui se trouve dans la couche plateforme, donc qui n'est pas un service de haut niveau comme Polly, Recognition, etc. C'est un service qui va nécessiter que vous écriviez du code et que vous utilisiez des modèles, etc. Donc vous allez avoir bien plus de flexibilité, mais un peu plus de complexité évidemment. Les principaux points de SageMaker, je l'ai dit déjà plusieurs fois, c'est qu'on va y trouver tous les composants dont on a besoin pour faire du machine learning. On va trouver un composant d'expérimentation via des notebooks Jupyter, on va trouver la capacité à entraîner des modèles avec de l'infrastructure managée, on va trouver la capacité à héberger les modèles qui auront été entraînés et que vous pourrez déployer par la suite soit au sein de SageMaker, soit comme on l'a vu hier sur DeepLens ou comme on l'a dit tout à l'heure sur Greengrass ML, etc. SageMaker va devenir le point central qui va héberger les modèles de machine learning que vous allez ensuite utiliser et déployer dans votre infrastructure. Et donc si vous décidez de le déployer avec SageMaker, ce qu'on va voir tout à l'heure, eh bien là aussi vous allez déployer sur de l'infrastructure managée et disposer d'une API REST que vous allez pouvoir invoquer. Donc on va pouvoir utiliser l'un ou l'autre de ces composants. Peut-être vous avez envie juste d'utiliser des notebooks ou peut-être vous avez envie de déployer un modèle pré-entraîné déjà sur votre plateforme à l'extérieur de SageMaker, vous allez avoir la flexibilité de combiner ou pas ces différents modules de SageMaker pour construire votre plateforme. Il n'y a absolument rien à configurer. On démarre lorsqu'on a besoin de travailler avec des notebooks, on va démarrer une instance de notebook, on va attendre trois minutes, et puis on a directement Jupyter, on n'a rien, vraiment absolument rien à faire. Idem pour l'entraînement, pour le déploiement, vous ne gérez absolument aucune infrastructure, vous passez simplement la configuration à appliquer pour ce déploiement ou pour cette prédiction et c'est tout. Donc vraiment on masque complètement l'infrastructure. Vous allez pouvoir utiliser différentes librairies de manière complètement différente, automatique pour entraîner vos modèles. Dans la version initiale qui est sortie à re:Invent, vous allez pouvoir entraîner vos modèles sur MXNet. On a des environnements préconfigurés pour MXNet et Gluon. On a un environnement pour TensorFlow, on a un environnement Spark, PySpark. Mais on va voir aussi tout à l'heure que vous pouvez arriver avec votre propre environnement si vous avez un algo spécifique de training ou un algo spécifique de prédiction, vous allez pouvoir le déployer et l'intégrer au sein de l'infrastructure de SageMaker. Ça c'est vraiment à mon avis une grande force du service. On peut faire très très simple ou on peut faire très très custom comme on va voir tout à l'heure. Et puis on paye à la seconde, vous allez payer à la seconde comme sur EC2 finalement, en fonction du nombre d'instances et de la puissance des instances de training ou de prédiction que vous utilisez. Donc on va commencer par démarrer une instance, ce qu'on appelle une notebook instance, qui est une instance toute prête, donc qui va démarrer en quelques minutes et dont l'interface va être pour vous Jupyter. Alors vous pouvez bien sûr ouvrir un terminal sur cette instance via Jupyter, vous avez accès à un shell, mais si vous voulez installer des librairies ou cloner des repositories git ou des choses comme ça, mais bon le but du jeu c'est quand même plutôt de travailler dans le notebook. On va vous fournir sur étagère un ensemble d'algorithmes de machine learning implémenté par Amazon, on va voir ça tout à l'heure. Donc des algorithmes parmi lesquels vous allez aller piocher et qui vont vous permettre déjà de résoudre tout un tas de problèmes avec très peu de code et en tout cas aucune ligne de code nécessaire sur le modèle. Donc là c'est vraiment idéal pour des gens qui n'ont pas vraiment d'expertise en machine learning qui ont besoin juste de faire une classification ou du clustering ou même de la classification d'image, etc. Donc on va prendre cet algo, lui passer les données et c'est tout. On va également pouvoir lancer des jobs de training avec différentes librairies. Donc on l'a vu également MXNet, TensorFlow, Scikit qui fait partie de l'environnement Python, Spark, etc. On va vous fournir, vous allez le voir, des API vraiment vraiment simples pour dire voilà, voilà mon script de training MXNet, et bien tu le lances sur MXNet, sur une instance de telle taille et c'est tout. Donc vous n'avez même pas à démarrer une instance vous-même, à installer MXNet, ou à prendre la Deep Learning AMI, à démarrer un truc, à copier votre script dessus, etc. Il y a un ensemble de raccourcis comme ça qui sont vraiment extra et qui permettent d'aller droit au but et de démarrer vraiment en un clic ou en appel d'API des jobs de training. Alors on a un feature qui est à mon avis assez révolutionnaire, qui est encore en preview, que je ne vais pas vous montrer aujourd'hui, pour la même raison que tout à l'heure parce que j'ai pas suffisamment joué avec donc on en reparlera certainement début d'année prochaine. On a un feature d'optimisation automatique des hyperparamètres, alors dit comme ça ça a l'air très compliqué. On a vu plutôt dans la semaine que l'une des problématiques importantes du deep learning c'était choisir la taille de batch, choisir le nombre d'époque, choisir le learning rate, etc. On est en train de développer et d'affiner une fonctionnalité qui va optimiser automatiquement pour vous ces valeurs-là. Vous n'aurez plus à les choisir, elles seront générées automatiquement par un modèle de machine learning. La sélection des hyperparamètres elle-même va être traitée par un modèle de machine learning. Je ne le montrerai pas aujourd'hui, il faut encore que je creuse ce sujet, on en reparlera certainement au début d'année, mais ça, on l'a vu en début de semaine, c'est un problème et là on va le résoudre. Donc c'est vraiment dans la lignée de ce que veut faire SageMaker, c'est-à-dire simplifier les processus de machine learning, permettre aux clients et aux développeurs de se concentrer sur ce qui est important, c'est-à-dire comprendre ces données, les nettoyer, les préparer, etc., puis ensuite essayer différents modèles pour en extraire le maximum de résultats et le maximum de précisions puis finalement tout le reste, toute la plomberie infra ou la plomberie deep learning vous la rendre la plus invisible possible. Et enfin lorsque vous avez entraîné votre modèle vous allez pouvoir le déployer et on en a parlé avec Predixis en début de semaine du fameux fossé qui pouvait exister entre l'environnement data science, en tout cas l'environnement expérimentation et l'environnement production, qui est vraiment un fossé difficile à franchir et qui cause pas mal de soucis et d'échecs dans ces projets, et bien là, ce fossé est complètement comblé. On va pouvoir, en un appel d'API, prendre un modèle qui est hébergé dans SageMaker et le déployer sur une, deux, quatre, douze instances et sans avoir à manager la moindre infrastructure. Donc ça c'est vraiment super intéressant. Donc vous voyez on a tous les modules de l'expérimentation au déploiement et une fois de plus on va voir dans les exemples que je vais vous montrer tout à l'heure qu'on peut en utiliser un ou deux ou trois ou tous et puis on construit comme ça son usine de machine learning. Alors on a déjà là aussi des clients. Si vous avez vu la keynote d'Andy J.C à re:Invent, si vous ne l'avez pas vue, je ne peux que vous encourager à la regarder. C'est vraiment... Je vais le dire, mais c'est une des plus belles keynotes IT que je n'ai jamais vue. Il y a rarement vu autant de densité, autant d'annonces que cette fois-là. Et je ne dis pas ça parce que je travaille chez AWS. J'étais dans la salle, c'était vraiment très très impressionnant. Et on avait des clients sur scène. On avait notamment la DSI de la NFL, donc la National Football League. Alors c'est du football américain, donc pas du vrai football, mais c'était quand même intéressant. Et... Elle racontait comment, avec SageMaker, ses équipes de data scientists étaient capables de construire rapidement des modèles basés sur les statistiques collectées pendant les matchs en temps réel, etc. Y compris avec des capteurs sur les joueurs pour mesurer l'accélération des joueurs, la vitesse des joueurs. C'était très étonnant. Si vous n'avez pas vu cette keynote, vraiment, je vous incite à la regarder. Voilà, c'était le cas NFL, mais on en a d'autres. Donc Intuit, qu'on connaît bien, qui fait des applications métiers et finances et donc qui utilise SageMaker pour modéliser un certain nombre de fonctionnalités dans ses applis. Et puis Digital Globe qui fait, que vous connaissez peut-être, parce que je crois que c'était le premier client, en tout cas le premier Vous savez ce fameux semi-remorque qui contient 100 pétaoctets de stockage. Là aussi si vous n'avez jamais vu ça, vous tapez Snowmobile dans votre moteur de recherche préféré, vous allez voir. Et évidemment ils font du traitement d'images à immense échelle. C'est le cas de le dire, quand on a 100 pétaoctets d'images satellites, je pense qu'on a une certaine échelle. Et donc ils utilisent Amazon SageMaker pour entraîner des modèles d'analyse d'images et de classification d'images, etc. Donc là, avec des volumes qui sont démentiels. Bon, il y en a d'autres, je n'ai pris que ces deux-là, mais vous trouverez plus d'informations à cette URL. Donc on va passer aux démos. Alors je vais aller du plus simple au plus compliqué. D'abord... Je vais vous montrer un premier... Alors quatre notebooks en fait. Je vais vous montrer un premier notebook où je vais prendre un algo sur étagère. Je vais vous montrer la liste des algos qui sont disponibles. Donc là, je ne vais même pas me soucier de savoir est-ce que c'est du MXNet, est-ce que c'est du TensorFlow ou est-ce que c'est autre chose. Je vais juste dire, voilà, moi j'ai mon dataset MNIST et j'ai envie de le classifier avec cet algo qui s'appelle XGBoost et c'est tout. Et puis ce qui se passe en dessous ça ne m'intéresse pas. Ensuite on va faire un deuxième exemple où cette fois on va amener notre propre script de Python d'entraînement et on va utiliser un script TensorFlow pour classifier le dataset Iris qu'on a utilisé je crois le premier jour Quand on a fait la... Vous vous souvenez de mon exemple de régression logistique ? Eh bien, c'était ce même dataset. Donc un dataset de fleurs qui permet de classer trois variétés d'iris différentes en fonction de la taille des pétales, etc. Donc là, c'est un exemple où j'amène mon script, je décide que je vote AnswerFlow, et voilà. Troisième exemple. Cette fois, je vais arriver avec un... modèle pré-entraîné. Donc j'aurai un modèle de clustering avec K-Means fait avec la librairie Scikit qui est une librairie Python ultra populaire. Donc j'aurai entraîné ce modèle sur mon poste ou peu importe. Enfin en tout cas je ne l'aurai pas entraîné au sein d'un processus de training SageMaker. J'arrive avec le fichier qui contient les paramètres du modèle et j'ai envie de le déployer derrière une API. Donc là on voit la modularité de SageMaker. Et puis le dernier exemple qui est l'exemple complètement custom où cette fois je veux faire du training et je veux faire de la prédiction mais je veux amener mon propre code, mon propre algorithme, donc je ne veux pas utiliser quelque chose de tout packagé, je veux pouvoir amener complètement mon code et mes librairies. Et on va le faire avec des containers Docker. Et ici on reclassifiera encore le dataset Iris avec des arbres de décision et un programme custom réalisé en Python. On va voir au fur et à mesure qu'on peut faire les choses de manière très simple en réutilisant ou alors on peut les faire de manière très spécifique en s'appuyant sur l'architecture de SageMaker mais en amenant l'intégralité du code d'entraînement et de prédiction. On retrouve les éléments que j'ai mentionnés, les notebook instances. J'en ai une qui est ici. Je ne vais pas vous faire l'insulte de vous montrer comment on en crée une. On lui donne un nom, on choisit sa taille. On a du T2, du M4 ou du P2. Vous allez me dire T2 c'est quand même bizarre, on ne va jamais faire du deep learning sur T2. Non, c'est sûr. Par contre, c'est très suffisant pour héberger des notebooks et déclencher des jobs de training qui vont se faire sur des instances managées. On peut la lancer dans un VPC, etc. Et c'est tout. Vous cliquez sur « Create notebook instance » et quelques minutes plus tard, vous avez votre instance. Ok ? Donc voilà, j'en ai créé une sur une P2, donc avec un GPU. Et puis ici, je clique sur Open, sans surprise. J'arrive sur mon notebook Jupyter qui contient les notebooks que j'ai déjà utilisés. C'est peut-être très petit là. Et en particulier, tous les exemples. Ouh, c'est trop. Voilà. Une grande quantité d'exemples qui sont vraiment hyper intéressants, enfin, ils sont tous plus intéressants que les autres, je vous incite à les lire. Je trouve que c'est même une excellente façon de découvrir le machine learning et le deep learning, de les prendre tous un par un, de lire, d'aller voir dans Google si on n'a pas compris. Il y en a une collection intéressante. Voilà, comment faire de la churn prediction, comment faire un peu de CRM, comment faire de la prédiction ici, comment faire des time series. Enfin, il y a vraiment les grands, grands cas d'usage du deep learning et je vous incite à les lire. Donc là, on a la liste des algorithmes sur étagère. Voilà, on a vraiment plein, plein de notebooks disponibles. J'en ai choisi quatre qui vont illustrer un petit peu le sujet. On va commencer par l'utilisation d'un algo sur étagère. Je vais ressortir peut-être juste... Je voulais vous montrer la liste des algos qui sont disponibles. On les voit ici. C'est de ça que je parle. Ces algos-là sont disponibles. Là, je vais prendre XGBoost, mais ça marcherait de manière totalement similaire pour les autres algos. Là, ce sont des algos, des implémentations qui ont été faites par Amazon, dont on peut imaginer qu'elles sont optimisées et optimisées. et qui vont s'appuyer sur des containers Docker qui vont faire tourner le job de training. Mais la seule chose qu'on va choisir ici, c'est l'un de ces algorithmes. On va lui passer les données et on va faire le boulot. Alors en avant, donc ici, on va utiliser le dataset MNIST qu'on commence à connaître. qu'on va classer avec un algorithme qui s'appelle XGBoost, qui est un algorithme d'arbre de décision amélioré. Alors j'ai exécuté les notebooks à l'avance parce que je ne voulais pas qu'on perde de temps, je voulais vraiment vous montrer les quatre et ça ne tient pas dans le délai en partie. Donc je les ai exécutés, je vais vous les expliquer et comme ça on ne perd pas. Donc on importe un peu les librairies dont on a besoin. Le point que vous allez voir dans tous les notebooks SageMaker, c'est qu'on travaille toujours en S3 sans surprise. Donc on a besoin d'avoir un bucket S3 qui va nous servir à soit mettre nos données de départ, soit sauver le modèle qu'on aura entraîné, etc. Donc vous aurez toujours besoin d'un bucket S3 ou de plusieurs. Un piège dans lequel je suis tombé, alors autant vous le dire, c'est qu'il faut que ce bucket soit dans la même région que SageMaker. Donc si vous bossez, là je vais être dans US East, donc il faut que le bucket soit là. Si vous travaillez sur SageMaker en Irlande, il faut que le bucket soit dans la même région, sinon ça ne marche pas. Ok ? On va définir le nom du bucket et le chemin du bucket dans lequel on va stocker nos données. On va télécharger pour la 958e fois le dataset MNIST. Ici on va le convertir. Je ne vais pas expliquer tout ça, mais sachez que vous le trouverez dans la doc. Cette implémentation de XGBoost a besoin que les données soient dans un format lib-svm. Il va falloir qu'on convertisse le dataset qu'on vient de télécharger ici dans ce format-là. La bonne nouvelle, c'est qu'on a les fonctions utilitaires ici et que sans aucun doute elles sont réutilisables pour d'autres datasets. Tout ça, c'est expliqué dans la doc des algorithmes. On va convertir le dataset MNIST dans le format LibSVM qui est attendu par XGBoost. On voit qu'on réécrit les fichiers convertis dans S3. Maintenant, on arrive sur la partie qui est vraiment essentielle. On a nos données. et on veut les classifier avec XGBoost. Je l'ai dit tout à l'heure, tous ces processus de training et d'inférence vont être basés sur des containers Docker. Dans les régions où SageMaker est disponible, on a poussé sur un repository ECR, qui est le repository Docker Managé d'AWS. EC2 container repository, on a poussé des containers qui contiennent cette implémentation du XGBoost. Ici, on va aller chercher le nom du container qui correspond à la région en laquelle on se trouve. Ce container contient l'implémentation du XGBoost. On n'a rien à fournir. Donc il va falloir maintenant qu'on spécifie le training, les paramètres du training. En particulier, les plus importants, c'est sans doute ça. Donc combien d'instances et quel type d'instances est-ce qu'on veut démarrer pour faire le job ? Quels sont les hyperparamètres ? on va passer à l'algo. Donc quelle est la profondeur maximum des arbres, combien de classes on veut classifier, pendant combien d'itérations est-ce qu'on veut entraîner le modèle, etc. Donc ça, une fois de plus, ce sont des paramètres qui sont spécifiques à l'algorithme. Donc ça, ce sont les paramètres pour XGBoost. Pour un autre algo, ça serait différent. Et tout ça est décrit dans la doc que je vous ai montrée rapidement tout à l'heure. Vous avez la description des hyperparamètres à fournir. Vous pouvez mettre un temps maximum d'exécution. Là, ça paraît très long. Je crois que c'est même 24 heures. Il y a peu de chances que ce job dure 24 heures. Mais si vous voulez bloquer et terminer votre job, mettre une limite dure, vous pouvez le faire là. Vous allez indiquer où sont les données. D'accord ? Donc dans le bucket qu'on a défini tout à l'heure. Les données d'entraînement. Les données de validation. Ok ? Donc ça, ce sont les données qu'on a converties au format SVM tout à l'heure. Et c'est tout. Ok ? Voilà. Donc un bout de JSON. Alors, c'est vrai que ça fait une grosse bouchée vu comme ça. C'est pas mal expliqué dans la doc. Et je crois savoir que l'équipe produit travail sur une façon simplifiée de gérer ses paramètres. Là, on est sur la première version, donc on place le JSON brut, mais je m'attends à ce que dans les releases ultérieures, on ait une façon un petit peu plus digeste de faire ça. Donc là, on a défini les paramètres de notre job. Et donc maintenant, on va tout simplement créer le job de training. On va lui donner un nom. On va lui dire où est-ce qu'il doit écrire. On va lui dire combien d'instances il faut qu'il démarre. Ok. Alors là, on peut le faire sur une instance. On peut le faire de manière... Si on voulait le faire de manière distribuée, finalement, la seule chose qui change, c'est que... Donc, on va lui dire qu'on veut deux instances. D'accord ? et on va devoir lui dire comment on veut partager le dataset entre les différentes instances. On voit là le datasource S3 datasource S3 data distribution type. On va les sharder par clé S3 en fonction du nom du fichier dans S3, du nom de l'objet dans S3, on va l'envoyer sur une instance ou sur une autre. Ici, évidemment, c'est vraiment juste à titre d'exemple parce que le dataset est tellement petit que ça n'a aucune importance. Mais voilà. Donc ici, on va faire... Vous voyez, comment est-ce qu'on peut faire un training distribué ? Juste comme ça, en fait. C'est très simple. On lui dit qu'on veut deux instances. On lui dit comment on partage les données entre les noix et tout. OK ? Donc ensuite, on va lancer les jobs. Alors là, on va utiliser le SDK de SageMaker. Toutes ces appels que vous voyez là, sm.blablabla, ça c'est le SDK de SageMaker, puisque dans SageMaker il y a toutes les fonctionnalités que j'ai décrites tout à l'heure, et il y a un SDK Python. L'avantage étant bien sûr que programmatiquement on va pouvoir lancer toutes ces opérations, et on va même pouvoir les lancer en dehors d'AWS. C'est-à-dire que là ce notebook je l'exécute dans SageMaker par symbolique, mais je pourrais tout à fait exécuter le même notebook sur mon mac localement ok donc je pourrais faire mon expérimentation mon bricolage localement et puis ensuite je pourrais dire ok maintenant je veux lancer le training sur un sur un plus gros data set et j'ai besoin de le faire dans AWS et à ce moment là depuis mon mac et bien je utiliserai le SDK de SageMaker pour lancer ça comme vous utilisez les SDK AWS, Boto etc pour faire des appels à AWS. Vous pouvez aussi évidemment utiliser tout ça à l'extérieur d'AWS. Donc on va créer les deux jobs et puis on attend un petit peu qu'ils se terminent. Voilà, là ça a pris 8 minutes. Donc à ce moment là, le job est terminé. D'ailleurs on le voit on les voit ici dans la console, on voit l'ensemble des jobs qui sont exécutés. Voilà le XGBoost, la single machine. On voit quelle image a été utilisée, où est-ce que les résultats sont stockés, etc. On a les hyperparamètres qui ont été utilisés, on a le modèle donc maintenant qui a été sauvé dans S3 qu'on pourrait aller télécharger et analyser on a cet historique des jobs et puis on a donc le modèle lui même voilà mon modèle mon modèle d'un jeu pour vous il ya peut-être que le modèle distribué j'ai peut-être fait que le distribuer j'ai le modèle de distribuer qui est là ok et qui est prêt à être. Alors revenons là. Maintenant j'ai mon modèle et j'ai envie de le déployer. Et ça comme on disait tout à l'heure c'est la partie la plus délicate. Donc maintenant je vais importer le modèle. donc le modèle qui a été entraîné je l'importe et je le sauvegarde dans SageMaker avec CreateModel. A ce moment là effectivement il apparaît dans la liste de mes modèles et je vois mon modèle distribué ici donc c'est celui qu'on vient de voir à l'instant. Donc là maintenant le modèle est sauvegardé, il est hébergé et maintenant j'ai envie de le déployer. Donc on va créer ce qu'on appelle une Endpoint Configuration donc on va lui dire ce modèle tu vas tu vas le déployer derrière un endpoint qui va être constitué d'une instance C4xLarge et c'est tout. Et on pourrait créer des configurations complexes, on pourrait déployer plusieurs modèles derrière le même endpoint, on pourrait faire de l'AB testing entre les modèles, ce qui est une fonctionnalité super utile quand on veut se rassurer sur le fait que le nouveau modèle marche bien. au moins aussi bien que le précédent. Donc ici on va donner la configuration de ce endpoint et puis on va le créer. Et tout ça on continue à le faire avec le SDK SageMaker. Et donc à ce moment là, il va démarrer une instance, il va tout déployer. Ça dure 13 minutes ici. Et donc là maintenant j'ai mon modèle déployé derrière un endpoint. et je peux m'en servir. Donc ici on va télécharger les données de test d'EMNIST et on peut faire des prédictions. On peut faire Invoke Endpoint et lui passer des données et vérifier que ça fonctionne. Et on fait donc les prédictions. Alors ici on fait les prédictions avec cet appel d'API mais une fois de plus c'est un endpoint REST donc on pourrait tout à fait le faire depuis une appli extérieure. Et donc si je... Tiens on va le refaire là, paf ça va fonctionner. Donc on prend le jeu de test MNIST, on le passe à travers ce endpoint et on voit qu'on a 10% d'erreur, donc 90%. 10% de validation. Ici on affiche quelques prédictions et quelques labels, on voit que effectivement ça, tout ça, là on a de la chance, ces 10 là correspondent donc ils ont été prédits correctement. Et puis il y a encore d'autres petites fonctions, la matrice de confusion, etc. Donc on voit que c'est pas mal, là on a un peu d'erreur, on a un peu de confusion entre 7 et 9, entre 9 et 4, un peu de entre 7 et 2 mais bon globalement c'est pas trop mal donc voilà un exemple simple où on fournit pas de script de training on choisit un algo on le paramètre on l'entraîne sur un jeu de données on héberge le modèle on déploie le modèle et on s'en sert donc un mode de fonctionnement simple pas de codage de machine learning à proprement parler et pas de gestion d'infrastructures. Deuxième exemple, cette fois on va regarder ce qui se passe quand on amène son propre modèle. Ici on est toujours sur SageMaker, cette fois on a entraîné un modèle à l'extérieur de SageMaker. On a fait du clustering sur MNIST. Donc, alors ici, évidemment, l'entraînement est fait dans le notebook parce qu'il faut bien générer le modèle. Mais supposons que toute cette partie-là, finalement, que jusque-là, tout ça, vous l'ayez fait localement sur votre poste ou sur une instance EC2 et que vous arrivez ensuite avec ce modèle pré-entraîné. Donc, il va falloir... Cette fois, il va falloir dans le container K-Means qu'Amazon a mis au point, qu'on aille injecter ce modèle, c'est-à-dire les paramètres qui ont été appris pendant cette phase d'entraînement. Ici, comme on passe de Scikit à MXNet, En K-Means, c'est K-Means, mais le format du modèle qui a été sauvé par Scikit n'est pas le format qu'attend MXNet. Donc il faut qu'on le convertisse, il faut qu'on exporte, qu'on remette au format NDR les paramètres de l'algo K-Means. Ça, ce n'est pas très compliqué. Et puis on va prendre ce modèle et on va le mettre dans S3. Donc là, on a dans S3 la finition. La forme MXNet du modèle qui a été entraîné préalablement par Scikit. Ensuite, le reste est très similaire. On va choisir le container K-Means qui correspond à la région où on se trouve. On va créer un modèle à partir du modèle qu'on a mis dans S3 qui est là. On recommence, on crée une endpoint configuration. On dit qu'on va déployer ça sur une C4XLarge et une seule instance C4XLarge. Ensuite on va créer le endpoint. Et ensuite il est prêt à servir. Ces deux phases sont complètement identiques. le même algo, mais c'est exactement la même logique. On sauve le modèle dans SageMaker et on se déploie. Et donc maintenant, ce qu'on va faire, c'est qu'on va comparer la prédiction du modèle initial avec la prédiction du modèle hébergé, histoire de s'assurer qu'on a vraiment la même chose. Donc on va invoquer le endpoint avec une centaine d'échantillons MNIST. On va comparer les labels prédits par le modèle hébergé dans SageMaker aux labels qu'on avait obtenus via le modèle entraîné dans Scikit. Et puis on voit qu'ils sont tous égaux, ce qui est une bonne nouvelle. C'est un bon test à faire de se dire, j'ai converti mon modèle au format MXNet, je l'ai mis dans SageMaker, je vais être sûr qu'il continue à bien se comporter. Donc cette étape de validation est intéressante. Donc vous voyez comment finalement on peut, là on a choisi de ne pas utiliser SageMaker pour faire l'entraînement, on a pris un modèle qui venait de l'extérieur, on l'a remis au bon format, on l'a hosté dans SageMaker et ensuite on le déploie. Donc vous choisissez si vous avez déjà des modèles, vous pouvez les importer et les héberger. Si c'est ça votre souhait. Alors troisième exemple, donc cette fois on va entraîner, enfin on va définir entraîner et héberger un modèle à partir de zéro. On va le faire ici avec TensorFlow. C'est l'équivalent de ce qu'on a fait les jours précédents avec MXNet lorsqu'on prenait un script de training, on prenait un dataset, on entraînait un modèle, on le sauvait, etc. Donc là on va refaire la même chose sur SageMaker et cette fois la différence étant qu'on va utiliser l'infra-manager de SageMaker pour l'entraînement et on va utiliser l'infra-manager de SageMaker pour l'entraînement. Et accessoirement, on utilise le notebook aussi de SageMaker. Donc voilà ce dataset, si vous l'aviez raté les jours précédents. C'est un dataset qui date de 1936, extraordinaire, qui contient 150 mesures, 50 pour chaque type d'iris, et pour chaque mesure, on a 4... On a 4 features, on a la largeur des pétales, la longueur des pétales et la largeur et la longueur sépale. Alors je ne suis pas un immense spécialiste de fleurs mais je ne vous cache pas que j'ai regardé. Ça correspond à la longueur et à la largeur de cette partie verte qui retient la corolle de pétales. Le deep learning ça permet d'apprendre aussi l'horticulture, c'est pas mal. Donc voilà à quoi ressemble le dataset. Pour chaque échantillon, on va avoir ces quatre features et puis on a une catégorie 012 qui nous indique à quelle espèce de fleur, à quel type de fleur correspond cet échantillon. Donc un dataset très très simple. Et donc cette fois, on va le travailler avec TensorFlow. Donc une fois de plus, on va avoir besoin de notre petit bucket S3. Comme d'habitude. Alors, on va sauter tout ça. Je ne vais pas faire un tuto TensorFlow, je pense que vous avez eu votre dose. Les points importants, en gros, c'est qu'on va utiliser, lorsque TensorFlow appelle un D, DNN classifier, c'est-à-dire Direct Neural Network, c'est l'équivalent de ce que MXNet appelle un Fully Connected Network. Donc on va avoir une couche d'entrée qui va prendre, comme on le voit ici, input, elle va prendre les quatre features. Elle va avoir trois couches de neurones cachées, qui vont être Fully Connected, Donc une première couche avec 10 neurones, une deuxième couche avec 20 neurones, une troisième couche avec 10 neurones et une couche de sortie qui va contenir 3 classes donc 3 neurones. Donc avec cette API TensorFlow on crée le modèle. Ensuite on va définir les fonctions qui vont servir les données au modèle. On le faisait avec des itérateurs. C'est un concept un petit peu différent. Si je peux me permettre, un peu moins lisible avec TensorFlow. Mais bon, c'est les mêmes idées. On va charger le dataset. Et puis ensuite, on va retourner cet objet qui va servir le dataset au modèle. OK ? Voilà, on ne va pas trop s'attarder sur les horreurs de TensorFlow, sur les features de TensorFlow, pardon. Et on va donc déclencher le job de training avec un objet SageMaker, cette fois, vous voyez, from SageMaker TensorFlow import TensorFlow. Donc cet objet-là, cet objet de haut niveau, il va paramétrer l'intervention l'intégralité du job de training. On va lui passer le script de training, c'est ce qu'on a vu là au-dessus. Voilà ce truc là, où on définit le réseau, etc. Donc le script Python. On va lui passer l'emplacement du bucket S3 où il faut qu'il travaille. On va lui dire combien d'instances il faut créer, de quel type. pendant combien de steps il faut entraîner, pendant combien de steps il faut évaluer. Donc on retrouve tous les grands paramètres. Et à partir de ça, on fait tout simplement fit et on lance le job de training. Donc vous voyez là en gros ce qu'on va faire, ce qui se passe en dessous, c'est qu'en gros on lui dit tu démarres une C4X Large avec un container qui contient TensorFlow et tout ce qui va bien. Tu injectes dedans mon DNN classifier.py avec les paramètres, le dataset, etc. que je t'ai indiqué là-dedans. Et c'est parti. Alors si on le faisait à la main, qu'est-ce qu'on ferait ? On démarrait une Deep Learning AMI, on copierait dessus le script d'entraînement, on ferait l'entraînement, on récupérerait les résultats, on les copierait dans S3, etc. Et maintenant, comme tout à l'heure, on va pouvoir le déployer. On va faire deploy une instance, le type de l'instance, donc voilà, 13 minutes plus tard, mon modèle est déployé automatiquement et je peux l'invoquer. Ici, on fait un appel de fonction mais gardez à l'esprit qu'on fait une invocation sur une API REST. On prend un iris dont les quatre features sont ça, et le label attendu est 1. 99% c'est 1. On peut faire des prédictions comme ça en invoquant l'endpoint qui est derrière le modèle. Dans le premier cas, on ne s'est pas posé la question de savoir si j'avais un script de training, quelle librairie j'utilise, etc. On a juste dit je veux faire du XGBoost et on aurait pu faire autre chose. Dans ce deuxième cas, on choisit d'utiliser un script dans TensorFlow, on fournit le script, on fournit les paramètres et on fait l'entraînement comme on aurait fait sur sa propre machine mais en ayant de l'infra manager de bout en bout pour le training et surtout la prédiction ou le déploiement vers la prod se fait en un appel d'API. Troisième exemple, non, pardon, c'était le troisième exemple, donc le dernier exemple. C'est l'exemple où on va vouloir tout faire soi-même. On va récapituler pour bien comprendre la différence. XGBoost, j'ai juste choisi un algo et j'ai fourni mes données. K-Means, j'arrivais avec un modèle pré-entraîné et je voulais juste l'héberger et le déployer. TensorFlow Iris, j'arrive avec un dataset, j'arrive avec un script d'entraînement et je veux faire l'entraînement sur l'infra-manager et le déploiement sur l'infra manager avec TensorFlow. Et puis, dernier cas, je veux tout faire moi-même. J'ai mon algo d'entraînement, j'ai mon algo de prédiction. Ce n'est pas basé sur TensorFlow, ce n'est pas basé sur AmixNet, c'est mon code à moi. Peut-être que je l'ai développé en C++ ou je ne sais quoi. C'est un truc custom, mais je veux quand même profiter de l'infrastructure de SageMaker. Tout est basé sur Docker. La première étape, ça va être de construire son container Docker avec le code d'entraînement et le code de prédiction. Il faut respecter une structure standardisée pour que SageMaker puisse invoquer le training et la prédiction. On a un script train qui va contenir l'entraînement, un script serve qui va servir les requêtes, etc. Si vous ne connaissez pas Docker, je ne vais pas l'expliquer aujourd'hui, mais ce n'est pas grave, vous irez lire ce que c'est que Docker. Si vous connaissez Docker, vous voyez tout à fait de quoi il s'agit. On a un Dockerfile, ici on va le construire même, vous avez un exemple construit. On part d'Ubuntu, on ajoute scikit-learn puisque le script custom va tourner sur scikit-learn. Donc on installe toutes les dépendances à l'intérieur du container Docker. Une fois que le container est prêt, et je vous incite à le tester localement sur votre machine, vérifiez que vous pouvez l'invoquer, que tout fonctionne correctement. Ensuite, on va le pousser dans un repository ECR, pour que l'infra SageMaker puisse aller le rechercher. Là, vous avez un petit rappel sur toutes les commandes ECR, comment créer un repository, etc. Et ça se termine par Docker Push, où le container Docker que vous avez créé, vous finissez par le pousser sur le repo. À la fin, on a poussé l'image. Au même titre que tout à l'heure, on voyait des images Docker, XGBoost, etc., vous avez construit votre propre container Docker avec votre propre code. Une fois de plus, à partir du moment où vous avez bien respecté les instructions précédentes, et où la disposition des fichiers dans le container, le nom des fichiers dans le container sont corrects, SageMaker va réussir à l'invoquer. Une fois qu'on en est là, la suite est relativement similaire. On va uploader des données pour l'entraînement. On va créer le job de training avec un estimator. Là, on n'est plus sur MXNet ou TensorFlow, etc. On est sur votre propre container. Donc, voilà l'image. Et donc, on lui dit, tu me lances un job de training avec cette image Docker sur cette instance-là, tu écris les résultats dans S3, et voilà. On retrouve exactement les mêmes concepts, c'est juste que cette fois on est en termes de couche, là on est à un cran plus bas, puisque vous amenez votre propre container. Tout ça s'exécute, se termine, et puis, comme tout à l'heure, maintenant je peux le déployer, c'est exactement la même façon, on va donc déployer ce job, donc on va sur une instance C4XLarge, démarrez votre container, et au lieu d'utiliser le script de training, cette fois, on va utiliser la prédiction. On va faire du predict. On prend quelques échantillons d'iris, on appelle, on prend ici, on en prend combien ? C'est compliqué. C'est trop compliqué pour un vendredi soir. On en prend, je ne sais pas, une trentaine manifestement, 10 chacun, ça a l'air d'être 10 chacun, et on les prédit. Vous voyez ce quatrième exemple où, après toute la phase de préparation du container, on profite de l'infrastructure de Docker, structure de SageMaker et du SDK de SageMaker, mais avec son propre code. Si on résume une dernière fois, il y a vraiment quatre exemples ici. Soit je choisis un algo sur étagère, et je vous ai montré qu'il y en avait pas mal. Vous avez vu, il y a image classification algorithm. Donc, on peut faire de la classification d'image sur étagère. C'est assez intéressant. Il y en a plein d'autres. Je vous laisserai les explorer. On peut arriver avec un modèle pré-entraîné. Ici, c'était un modèle scikit qu'on a importé dans MXNet. Il y avait cette phase de conversion qui était un peu embêtante. Si on avait entraîné un modèle MXNet ou un modèle TensorFlow à l'extérieur et qu'on voulait l'importer, on n'aurait pas eu cette phase de conversion, on l'aurait fait tel quel. Ici, on fait tout le trajet. On amène un script, on envoie, on déploie et ici on va un cran plus loin, c'est-à-dire qu'on fournit même le code complet d'entraînement et le code complet de prédiction sans s'appuyer sur les containers MXNet, TensorFlow, etc. prédéfinis dans SageMaker. Voilà, c'est sans doute les quatre grandes combinaisons possibles. Si vous avez d'autres idées, ça m'intéresse. J'imagine que ça va être les quatre grandes façons d'utiliser SageMaker. Je vous laisserai explorer les autres books. Vraiment, une fois de plus, je vous incite à aller les lire. C'est vraiment très, très instructif. J'ai découvert pas mal de choses en les disant, il y a des algos que je ne connaissais pas ou pas bien et en les voyant comme ça en action, c'était vraiment super intéressant. Donc in fine on a ce service SageMaker qui est, à mon avis, un service fondamental maintenant dans la plateforme et qui va continuer à être de plus en plus le point central où on va entraîner, stocker et déployer des modèles de deep learning, soit en les déployant via des instances comme vous l'avez vu là, soit en les déployant vers des devices qui peuvent être DeepLens ou des devices IoT avec Greengrass ML dont j'ai parlé tout à l'heure. Un service vraiment fondamental et dont je suis assez fan, je dois dire. Voilà les quelques liens que je vous ai déjà montrés sur les pages de haut niveau et sur mon blog. Je compte bien passer pas mal de temps dans les semaines qui viennent à travailler sur SageMaker. Si le sujet vous intéresse, gardez un œil sur mon blog Medium. Je pense qu'on aura du contenu intéressant. On est arrivé au bout de cette magnifique semaine. 10 webinaires ! 10 webinaires live. Merci beaucoup de votre présence tout au long de la semaine. Vous avez été ultra nombreux. Et voilà, que dire ? C'est pour vous qu'on le fait. On s'amuse aussi à le faire. C'est énormément de préparation. Donc j'espère que vous êtes contents. J'espère que vous avez appris plein de choses. Et puis si vous avez raté des webinaires, ils sont tous sur YouTube. Donc vous pourrez tout revoir. Vous pouvez m'envoyer vos questions, comme vous le faites d'ailleurs sur LinkedIn ou sur Twitter. Et j'essaierai de vous répondre. Et puis je vais continuer à creuser ce sujet avec DeepLens, avec SageMaker et les autres services. J'ai pas mal d'idées et pas mal de démos rigolotes à faire. Hugo va vous afficher le sondage pour la dernière fois cette semaine. Donc voilà, 5 là-mêmes. Il y a une question de Vincent qui me dit « Ah, j'ai raté où étaient stockés les notebooks. » Les notebooks, en fait, tous ces notebooks que je vous ai montrés, ils sont présents sur les notebooks instance que vous démarrez. Donc, à chaque fois que vous allez démarrer une instance de notebook SageMaker, comme je l'ai fait là, notebook instance, create, etc. En fait, à la racine de Jupyter, il y a ce répertoire qui s'appelle Sample Notebooks et où vous allez trouver tous ces fameux notebooks. Si vous voulez rajouter les vôtres, par exemple, moi j'ai rajouté ici des notebooks, comment on fait ? Les experts de Jupyter le savent, mais peut-être que les autres ne le savent pas. Ça vaut la peine de le montrer. Vous faites New, Terminal. Vous arrivez sur un petit shell dans Jupyter. La ruse, c'est qu'il faut aller dans le répertoire SageMaker. Et donc là, vous faites Git Clone, et vous pouvez cloner vos notebooks et vous les verrez apparaître ici. Voilà, tout simplement. Il y a une question de François-Paul. Est-ce qu'on sait quels sont les algos implémentés par les différents services ? Alors François-Paul, je pense que tu fais référence aux services de haut niveau, j'imagine. Parce que là, on le voit dans SageMaker, les algos disponibles sur étagère sont explicites. Quant à Recognition, Poly, Translate, etc., on ne donne pas d'informations sur les algorithmes qui sont utilisés. Sur Comprehend, on a fait une session à ReInvent où on explique qu'on utilise LDA, etc. Pour Translate, je ne sais plus si je vais vous montrer Sokai. Donc Sokai, c'est ce fameux projet open source réalisé par l'équipe, une de nos équipes, qui fait de la traduction automatique, qui est basée sur des réseaux LSTM, etc. Donc AWS, Slabs Sokai. Je ne suis pas dans le secret des dieux, mais de là à dire qu'il y a sans doute du Sokai dans Translate ou des bouts de Sokai dans Translate, je pense que c'est un choix raisonnable. Quant à Recognition et Recognition Video, on se doute bien qu'il y a des CNN, du Single Shot Detector, etc. Bon, on ne soulève pas le capot, on le fera peut-être plus tard. Mais je pense qu'avec tout ce que je vous ai raconté cette semaine, vous pouvez avoir une petite idée de la façon dont ces services fonctionnent et puis surtout de l'investissement et du temps nécessaire pour le faire. Il faut vraiment avoir une bonne raison de le faire. Si c'est juste pour se faire plaisir, vous risquez d'être déçu. Recognition doit être entraîné sur des dizaines de millions d'images. Je ne suis pas sûr que vous ayez ces datasets à portée de la main, je ne suis pas sûr que vous ayez les ressources pour le faire, etc. Le fait aussi de voir ce que c'est de soulever le capot de ces algos, de ces services avec ces notebooks, ça montre aussi que pour réussir à faire un service comme Recognition, comme Poly, ou comme Translate, où en un appel d'API, on obtient un résultat qui est quand même globalement de bonne qualité, il y a du travail, ce n'est pas juste un algorithme, c'est aussi des datasets, du traitement de données, de l'optimisation, etc. Ça prouve bien que juste l'algo, ce n'est pas suffisant, il faut avoir autour l'infrastructure et les données pour arriver à de bons résultats. Je crois qu'on n'a plus de questions. Non, on n'a plus de questions. On a beaucoup de merci. Alors, on va vous remercier encore. Ce n'est pas pour faire les faux culs, ce n'est pas vraiment le genre de la maison, mais on a eu beaucoup, beaucoup de gentils messages pendant toute la semaine. J'en ai reçu, il y a des gens qui m'ont envoyé des tweets et tout. Il y en a plein à l'écran, donc ça fait super plaisir. Ah, il reste une dernière question. Est-ce qu'on peut évaluer SageMaker sur une instance gratuite avant de passer sur une instance P2XLarge ? Je n'ai pas l'impression qu'il y ait un free tier pour SageMaker. Je ne l'ai pas vu. Donc, je pense que le choix le plus raisonnable, c'est de commencer sur une T2 Medium qui va être, enfin T2 Medium, c'est même pas en cent par heure, donc voilà, testez le service en T2 Medium, vous aurez, vous pouvez faire même du MNIST ou de l'IRIS sur du T2 Medium, ça va pas être rapide, mais ça vous permet de voir comment ça marche, et puis ensuite vous pourrez continuer sur des instances plus puissantes si vous voulez. Voilà, je pense qu'on a fini. Merci infiniment. On va pouvoir se reposer un peu maintenant. Je vous souhaite à tous de très très bonnes fêtes. De très bonnes fêtes de fin d'année. Profitez-en bien, soyez prudents sur la route et faites-vous plaisir quand même. Et puis on se retrouve en janvier pour de nouveaux webinaires et de nouvelles aventures sur AWS. Voilà, merci beaucoup. On est très très fier d'avoir fait tout ça pour vous. À bientôt, au revoir. Thank you.