Python appliqué en apprentissage automatique (Applied Python in Machine Learning)

Python appliqué en apprentissage
automatique
(Machine Learning)
Présenté par : Guillaume Chevalier
Cours #1/3
1

Résultat d’un sondage de mes précédentes formations
Ce que vous voulez savoir:
● Comment bien déployer en production
● Comment faire du Clean Machine Learning
● Les bases du Machine Learning
● Comment faire du Automated Machine Learning
3

Rappel des fondements du
Machine Learning & du Deep
Learning
7

Intelligence Artificielle v.s. Apprentissage Automatique
v.s. Apprentissage Profond
8

Le processus d’apprentissage supervisé
9

Apprendre en minimisant l’erreur
réduire la perte (loss, ou erreur) à chaque itération
d’entraînement
Ajuster les poids à chaque itération
10

Le Machine Learning implique
1. De charger des données
2. De les prétraiter
3. De créer un modèle
4. D’optimiser le modèle
5. D’optimiser à nouveau avec différents hyperparamètres
6. Le sauvegarder une fois appris
7. Servir le modèle en production
8. Suivre et continuer à évaluer la qualité des prédictions dans le temps
11

Workflow de R&D en ML typique
1. Charger les données
2. Les transformer
3. Les dumper sur disque
4. Loader les résultats sur disques
5. Entraîner des modèles sur les données
6. Ré-entraîner manuellement des modèles sur les données (Graduate student descent)
7. Dumper les résultats sur disques
8. Loader les résultats sur disques
9. Stacker des modèles ou faire des ensembles
10. Score final
11. Le code n’est pas réutilisable en prod à cause des interactions de disques.
12

Workflow de R&D en ML désirable
1. Charger les données
2. Les transformer
(automatic disks checkpoints
that can be deactivated)
1. Entraîner des modèles sur les données
2. Ré-entraîner automatiquement des modèles sur les données (AutoML)
(automatic disks checkpoints
that can be deactivated)
1. Stacker des modèles ou faire des ensembles
2. Score final
3. Le code est réutilisable en prod avec une REST API ! :D
13

Ce qu’il faut:
A-Z :
● Checkpoints automatiques (caching) entre les steps d’un pipeline
● Gestion facile des espaces d’hyperparamètres
● Algorithmes d’AutoML
● Compatibilité avec les autres librairies
● REST API : model serving
14

Qu’est-ce qu’un pipeline?
Une série d’étapes dans lesquelles les données
sont transformées.
Un graphique acyclique dirigé (DAG) dans lequel
les données circulent.
Une mise en œuvre du modèle de conception du
tuyau et du filtre.
Est un composite.
Voir un exemple:
https://www.neuraxle.org/stable/ex
amples/sklearn/plot_boston_housi
ng_regression_with_model_stacki
ng.html#sphx-glr-examples-
sklearn-plot-boston-housing-
regression-with-model-stacking-py
16

Composite : Pipelines emboîtés
Un pipeline peut lui-même se trouver dans un autre
pipeline.
Voir un exemple:
amples/getting_started/plot_nested
_pipelines.html
19

Les étapes et le lien avec les pipelines
1. De loader des données
2. De les pré-traiter
3. De créer un modèle
4. D’optimiser le modèle
5. D’optimiser à nouveau avec différents hyperparamètres
6. Le sauvegarder une fois appris
7. Le loader pour enfin le servir en production
20

Dans un pipeline,
tout est un step.
21

Une classe de base pour tous (BaseStep)
class BaseStep(ABC):
def __init__(self, hyperparams: HyperparameterSamples = None, hyperparams_space: HyperparameterSpace = None):
def set_hyperparams(self, hyperparams: HyperparameterSamples) -> 'BaseStep':
def get_hyperparams(self) -> HyperparameterSamples:
def set_hyperparams_space(self, hyperparams_space: HyperparameterSpace) -> 'BaseStep':
def get_hyperparams_space(self, flat=False) -> HyperparameterSpace:
def fit_transform(self, data_inputs, expected_outputs=None) -> ('BaseStep', Any):
def fit(self, data_inputs, expected_outputs=None) -> 'BaseStep':
def transform(self, data_inputs):
def inverse_transform(self, processed_outputs):
def predict(self, data_input):
def transform_one(self, data_input):
def tosklearn(self) -> 'NeuraxleToSKLearnPipelineWrapper':
def reverse(self) -> 'BaseStep':
22

Chaque step peut avoir des
Hyperparamètres et/ou
un Espace d'hyperparamètres.
25

Distributions d'hyperparamètres
26

Distributions d'hyperparamètres
27

Espaces d'hyperparamètres
hyperparameter_space = HyperparameterSpace({
"uniform": Uniform(-10, 10),
"loguniform": LogUniform(0.1, 1),
"normal": Normal(0.0, 1.0, hard_clip_min=-4, hard_clip_max=4),
"lognormal": LogNormal(1.0, 0.5, hard_clip_min=0, hard_clip_max=10)
})
hyperparameters = hyperparameter_space.rvs()
28

Échantillons (Samples) d’hyperparamètres
>>> hyperparameters = hyperparameter_space.rvs()
>>> print(hyperparameters)
HyperparameterSamples([
('uniform', -2.4938587716619747),
('loguniform', 0.6268865869860825),
('normal', -0.08721404310165681),
('lognormal', 1.3740549989839108)
])
29

Espaces d'hyper paramètres de toutes sortes
HyperparameterSpace({
"a__test": Boolean(),
"a__lr": Choice([0, 1, False, "Test"]),
"a__b__c": PriorityChoice([0, 1, False, "Test"]),
"a__b__q": Quantized(Uniform(-10, 10)),
"d__param": RandInt(-10, 10),
"d__u": Uniform(-10, 10),
"e__other": LogUniform(0.001, 10),
"e__alpha": Normal(0.0, 1.0),
"e__f__g": LogNormal(0.0, 2.0),
"p__fixed": FixedHyperparameter(3),
})
30

Hyperparamètres imbriqués ou plats
31

Comment définir des Hyperparamètres?
Varie selon une distribution statistique.
Voir un exemple :
https://www.neuraxle.org/stable/r
andom_distributions.html
32

Hyperparameters & Espaces d’Hyperparametres dans les
Pipelines
Un pipeline devrait pouvoir gérer les
hyperparamètres de ses steps et des autres steps
sous-jacents.
Voir exemple :
amples/hyperparams/plot_hyperpa
rams.html
33

Ajout d’espaces d’hyperparamètres aux étapes d’un
pipeline
Les espaces des hyperparamètres doivent être
définis à l’intérieur de chaque étape plutôt qu’à
l’extérieur du pipeline.
Cela ne devrait pas s’appliquer uniquement aux
hyperparamètres.
Voir un exemple:
https://www.neuraxle.org/stable/
examples/sklearn/plot_boston_h
ousing_meta_optimization.html
34

Considérations plus avancées
en programmation orientée
objet
35

OOP Diamond Problem (a.k.a. Deadly Diamond of Death)
● Commun en développement de GUI:
○ Bouton hérite de Rectangle et Clickable
○ Rectangle hérite de UIObject
○ Clickable hérite de UIObject
● Maintenant, si la méthode “equals” est appelée
sur Bouton, mais qu’elle est définie sur
Rectangle et Clickable, quelle(s) méthode(s)
appeler ?
36

Une solution: les Mixins
● Faire en sorte que certaines classes “add-on”
n’héritent pas directement de la classe de base.
Ça permet:
○ De fournir plusieurs features optionnelles
à nos classes
○ De permettre d’utiliser plusieurs features
optionnelles pour nos classes
⇒ Bref, beaucoup de petites classes comme C !
37

Quelques Mixins Intéressant en ML
- MetaStepMixin
- NonFittableMixin
- NonTransformable Mixin
- ResumableStepMixin
- HandleOnlyMixin
- ForceHandleMixin
- TransformHandlerOnlyMixin
- ForceHandleOnlyMixin
- EvaluableStepMixin
Voir exemples:
https://www.neuraxle.org/stable/exa
mples/getting_started/plot_non_fitta
ble_mixin.html
Et
https://www.neuraxle.org/stable/exa
mples/getting_started/plot_force_ha
ndle_mixin.html
38

Exemples de classes qui utilisent des mixins
- MetaStepMixin:
- ForEachDataInput
- TrainOnlyWrapper
- TestOnlyWrapper
- OutputTransformerWrapper
- EpochRepeater
- NonFittableMixin:
- NumpyFlattenDatum
- DataShuffler
- MultipyByN
- Toutes classes de transformation de données qui n’a pas de state (e.x.: Mean)
- NonTransformableMixin:
- Identity (+NonFittableMixin)
- ….
...
39

Cycle de vie des Objets
(Object Lifecycle)
Un jour dans la vie d’un objet
40

Qui connait ?
● VueJS
● React
● Composantes en UI
41

Comment appliquer ça au
Machine Learning ?
45

Voici le cycle de vie du Machine
Learning.
46

The ML Lifecycle, with Handlers
47

The Data Container
dact: DACT[List[str], List[int], List[float]] = DACT(
ids=['a', 'b', 'c'],
data_inputs=[1, 2, 3],
expected_outputs=[1.0, 2.0, 3.0]
)
48

Principes
SOLID?
Single responsibility principle, Open-closed principle, Liskov
substitution principle, Interface segregation principle, Dependency
inversion principle
(+ Tell Don’t Ask)
52

SOLID
Single responsibility principle : 1 responsabilité par classe
Open-closed principle : classes fermées à la modification, ouvertes à l’extension
Liskov substitution principle : Sous-type interchangeables (contrats)
Interface segregation principle : Plusieurs interfaces sont mieux qu’une seule
Dependency inversion principle : Dépendre d’abstractions plutôt que de concrétions
(+ Tell Don’t Ask : Pas de “Leaky Abstractions”)
53

Single Responsibility Principle (SRP)
- On cherche à avoir 1 responsabilité par classe
⇒ Cela va faciliter les choses quand vient le temps de faire des changements et de réutiliser du code
Clairement, les steps d’un pipeline représentent chacunes 1 seule étape. Yay!
Plus de longues routines dégeu…
Symptôme: voir souvent le mot clé “and” dans des noms de classe.
Voir exemple: https://www.neuraxle.org/stable/api/steps/neuraxle.steps.numpy.html
54

Open-Closed Principle (OCP)
- Classes fermées à la modification, ouvertes à l’extension
- Fortement relié au SRP
⇒ Implique de créer plus de classes abstraites et de mettre en commun les fonctionnalités. Ça simplifie
le code et le rends plus réutilisable.
Clairement, dans les pipelines, une hiérarchie de classe est bien faite, tout est un step.
Symptôme: voir souvent des “if elif elif elif else” (a.k.a. “Poor Man’s Polymorphism”)
Exemples: TruncableSteps et MetaStep: (voir diapos suivantes)
https://www.neuraxle.org/stable/api/neuraxle.base.html
56

Liskov Substitution Principle (LSP)
- On veut qu’un objet soit changeable avec les sous-types de ce même objet sans briser
l’application
- Un canard en plastique n’est pas un animal
⇒ Implique une cohérence dans les possibilités de substituer des objets pour d’autres dans certains
contextes pour rendre le code plus générique.
Clairement, dans un pipeline, un step est un step. Les steps sont très remplaçables et flexibles.
Symptôme : faire des “if isinsitance(obj, SomeClass)” avant de faire des traitements est un symptôme
que les sous-types briseraient l’application lorsqu’utilisés dans certains contextes.
59

Interface Segregation Principle (ISP)
- On veut plusieurs interfaces (classes abstraites) plutôt qu’une seule
- Ne pas forcer les utilisateurs d’une interface d’utiliser trop de méthodes
⇒ Code léger et sans obligations d’implémenter toutes les fonctionnalités dans tous les objets. Vaut
mieux avoir un objet qui implémente plusieurs interfaces.
Clairement, les nombreux mixins des steps dans les pipelines permettent ça et ça évite de forcer à
chaque objet d’implémenter du comportement inutile.
Symptôme: “god class” trop longue dont on hérite pourrait être divisée en plusieurs classes de base avec
Mixins.
Voir exemple BaseService v.s. BaseTransformer:
https://www.neuraxle.org/stable/api/neuraxle.base.html#neuraxle-base
61

Dependency Inversion Principle (DIP)
- On veut utiliser des abstractions et non des implémentations
- On ne veut pas gérer toutes les choses concrètement et on veut déléguer
⇒ De la sorte, notre code se découplerait du loading des données et de toute gestion d’état sur les
disques.
Clairement, dans les pipelines, les données sont “reçues, traitées, et retournées” plutôt que “loadées,
traitées et sauvegardées”. Trop de code de machine learning ne respecte pas ce principe (e.x.: BERT,
Fasttext).
Voir exemple de contexte : https://stackoverflow.com/questions/64477316/how-to-implement-a-
repository-for-lazy-data-loading-with-neuraxle/64850395#64850395
63

Tell Don’t Ask (TDA)
- On ne veut pas “micro-manager” nos objets ni devoir aller jouer dedans
- On veut plutôt leur dire quoi faire et qu’ils soient autonomes
⇒ Ainsi, on évite la duplication de code, le code est plus scalable, réutilisable et la logique est gérée aux
bons niveaux d’abstractions.
Clairement, chaque step d’un pipeline s’auto-gère. Chose importante : chaque step est indépendant des
autres steps qui l’entoure, sans quoi le code deviendrait lourd et en spaghetti (e.x.: Loi de Déméter).
Voir exemple d’objets défaits : https://www.neuraxle.org/stable/intro.html
66

Machine Learning propre:
quelques stratégies
67

Mini Batching
Mini-batch gradient descend est une variation de
l’algorithme de descente de gradient qui divise
l’ensemble de données de formation en petits lots
qui sont utilisés pour calculer l’erreur du modèle et
mettre à jour les coefficients du modèle.
Mini Batch Sequential Pipeline(
Pipeline([...]),
batch_size=100
)
68

Époques (Epochs)
Une époque représente une itération complète sur
le dataset. 50 époques représentent un ré-
entraînement sur 50 boucles du dataset.
EpochRepeater(
MiniBatchSequentialPipeline(
Pipeline([...]),
batch_size=100
),
), epochs=50)
70

Boucle For (For Each)
Lorsqu’une dimension du jeu de données doit être
bouclée dessus
EpochRepeater(
ForEach(
MiniBatchSequentialPipeline(
Pipeline([...]),
batch_size=100
),
),
), epochs=50)
72

Et plus… pipelining as a language.
ForEach(...)
While(...)
BreakIf(...)
ContinueIf(...)
ForEach(...)
Try(...)
Catch(...)
Raise(...)
If(...) & ElseIf(...) & Else(...)
Switch(...)
…
73

Exemple de Pipeline de Deep
Learning
75

Exemple simple d’utilisation
81

Pourquoi utiliser les
Notebooks ?
82

Bonnes utilisations des notebooks :
- Code à jeter
- Le “DE” dans RS&DE
- Visualisations et graphiques
- Démos
- Tutoriels
- EDA et création de features
- Analyze des résultats
- Intéressant pour prototyper les modèles
84

Reconnaissance d’activité
humaine
85

Données structurées dans le temps:
● Samples (batch_size, e.x.: exemples d’entraînement en plusieurs mini-batches)
● Steps (time_steps, e.x.: 30 lectures par seconde)
● Features (features, e.x.: 9 mesures de senseurs par lecture)
Exemples pratique:
● Signaux à une dimension (tenseur 3D):
[batch_size, time_steps, signal_features]
● Données vidéos (tenseur 5D):
[batch_size, time_steps, x, y, channel_features_rvb]
86

La tâche:
https://www.youtube.com/watch?v=XOEN9W05_4A
87

La tâche:
Classifier le type de mouvement selon les lectures
spatiales du téléphone cellulaire.
Entrées (X), forme (shape) du tenseur:
[batch_size, time_steps, features] ⇒ [ _ , 128, 9]
● Prédictions (Y), catégories:
● WALKING
● WALKING_UPSTAIRS
● WALKING_DOWNSTAIRS
● SITTING
● STANDING
● LAYING
Prédictions (Y), forme (shape) du tenseur:
[batch size, n_classes] ⇒ [ _, 6]
Features:
- Acc x
- Acc y
- Acc z
- Gyro x
- Gyro y
- Gyro z
- Acc x gravity
- Acc y gravity
- Acc z gravity
*Note: x, y et z ici sont des coordonnées dans l’espace et diffèrent des coordonnées à gauche
dans cette diapositive.
88

Quels autres types de traitements peuvent être faits?
E.x.: Seq2seq, LSTM RNN, GRU RNN, U-Nets pour signaux, et pipelines de machine
learning classiques (tels que présentés ici), en mixant des sources de données variées
tels que du texte et des images...
89

Kata #1
Bienvenue au Dōjō
https://drive.google.com/file/d/1Yc6PlF0DOzgwJj2vg5vyt2Ivj1
TgdiSI/view?usp=sharing
92

Solution
Explorons le notebook corrigé.
https://drive.google.com/file/d/1x_uH3fPOUnuiC2UkfU9V1xT
Ibv0aTOTi/view?usp=sharing
93

Pourquoi optimiser les
hyperparamètres?
97

Techniques de validation
- Communément Train/Test Split
- Cross Validation Split
- Walk-Forward Cross Validation
- Anchored Walk-Forward Cross Validation
99

Algorithmes de sélection des hyperparamètres
● Objectif : prédiction des meilleurs prochains hyperparamètres
● Exploration v.s. Exploitation
○ Au début, essayer des trucs variés
○ Ensuite, tenter vraiment plutôt d’optimiser les choix en fonction de ce qu’on sait
⇒ Certains algorithmes ont avantages à même observer les loss au cours de l’apprentissage et entre les
modèles
⇒ Certains algorithmes pourraient même observer des statistiques sur les poids des réseaux de neurones
pendant et suite à l’entraînement pour mieux les optimiser
100

Effet de la quantité des données sur l’erreur
101

Effet de la complexité du modèle sur l’erreur
102

Effet du taux d’apprentissage sur la perte (loss)
103

Observer les poids
https://github.com/guillaume-chevalier/Hyperopt-Keras-CNN-CIFAR-
100/blob/Vooban/AnalyzeTrainHyperoptResults.ipynb
104

Bien choisir ses paramètres
Grid search: recherche dans une “grille”:
● Si 3 paramètres : Triple loop ⇒ Espace d’hyperparamètres 3D
best_result_metric = 0.0
best_hyperparameters = [None, None, None]
for learning_rate in [0.01, 0.007, 0.001, 0.0007, 0.0001]:
for lambda_loss_amount in [0.005, 0.001, 0.0002]:
for clip_gradients in [15.0, 10.0, 5.0]:
result_metric = train_new_net(learning_rate, lambda_loss_amount, clip_gradients)
if (best_result_metric < result_metric):
best_result_metric = result_metric
best_hyperparameters = learning_rate, lambda_loss_amount, clip_gradients
105

Grid Search v.s. Random Search
106

Sauvegarde des résultats et inspection
Quelques trucs sont cruciaux:
● Sauvegarder les résultats pour chaque hyperparamètres essayés
○ Meilleur score tout au long de l’apprentissage
○ Loss et scores le long de l’apprentissage
○ Parfois visualiser les poids, etc.
● Pouvoir visualiser les résultats
● Parfois, on voudra même sauvegarder chaque modèles entraîné
107

Automated Machine Learning (AutoML)
Une classe pour les combiner toutes:
- Spécifier un pipeline
- Spécifier un algorithme de sélection des prochains hyperparamètres
- Spécifier une technique de validation
- Spécifier une métrique
- Spécifier une façon de sauvegarder les résultats sur disques
108

AutoML : choix automatique
Choisir algo automatiquement
- Optional( SomeStep() )
- ChooseOneStepOf( [SomeStep(), SomeStep(), SomeStep()] )
- ChooseOneOrManyStepsOf( [SomeStep(), SomeStep(), SomeStep()] )
Certains steps dans un pipeline deviennent done aléatoirement désactivables dans la boucle d’AutoML
112

Tree-structured Parzen Estimator (TPE)
⇒ Mieux que du random
Exemple:
https://www.neuraxle.org/stable/examples/sklearn/plot_boston_housing_meta_optimization.html 114

Hyperband
- Ne pas entraîner chaque modèle jusqu’à la fin
- On entraîne jusqu’au bout seulement les
meilleurs modèles aux premières époques
- Basé sur l’estimation qu’un apprentissage rapide
au début mène à de meilleurs résultats à la fin.
115

Thème: Python appliqué en
apprentissage automatique
(Machine Learning)
Cours #2/3
117

Développement par tests unitaires
(Test-Driven Development - TDD)
1. Écrire un test
2. Écrire du code pour faire passer le test
3. Peaufiner le code pour que tout soit propre
⇒ Aussi appelé les étapes “Red, Green, Blue”
119

Comment écrire un test ?
1. Arrange
2. Act
3. Assert
⇒ La méthode des triples A (AAA)
120

Exemple de test
https://colab.research.google.com/drive/1w9XuPuTZDBTDPRVdCrKCUtbVuDDDN64K?usp=sharing 121

TDD & Notebooks
Vous avez souvent déjà vos AAA !
1. Arrange : des données en entrées
2. Act : un algorithme (e.x. : modèle, réseau de neurones)
3. Assert : un print pour voir les résultats
123

Ce qu’il faut penser à faire
1. Extraire votre algorithme en une abstraction appropriée, et vers un fichier externe dans votre
architecture
2. Extraire votre test vers vos dossiers de tests
3. Réorganiser vos modules et votre base de code
124

Tout le monde passe par là…
- Mauvais versionnage des notebooks
- Je l’ai fait moi-même
- Erreurs typiques en entreprise et en recherche académique.
125

Comment coder de belles
architectures logicielles ?
126

Quelques Patrons de Conception (Design Patterns)
Source: https://blog.startifact.com/posts/framework-patterns.html
ML Design Patterns:
- Pipe and Filter;
- State;
- Service Locator;
- Composite;
- Decorator;
Framework Design Patterns:
- Callback functions;
- Subclassing;
- Interfaces;
- Imperative registration (saving) API;
- And more.
127

Gestion des modules : cohésion
Devraient faire partie du même modules les classes qui:
- Sont utilisées seulement par les autres classes de ce module
- Changent ensemble
- Sont souvent utilisées ensemble
Source: https://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
128

Gestion des modules : couplage
Entre les modules, on devrait :
- Ne pas avoir de dépendances circulaires dans les imports
- Dépendre vers la direction de la stabilité
- Avoir plus d’abstractions lorsqu’il y a plus de stabilité
Source: https://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
129

Architecture par couches
- API (REST)
- Application Service
- Domain
- Infrastructure & Persistence
130

Kata #2
Nous revoici au Dōjō
https://colab.research.google.com/drive/1JKQijk1IBjMMa
M6XWm-fNyHvJUkiDSrz
132

Solution
Explorons le notebook corrigé.
https://colab.research.google.com/drive/18ricbnHQrnB5E
hbyWtcYvT2H1JTHii58
133

Exercice pratique additionnel
https://colab.research.google.com/drive/1y65Gxl4zhbNk
OfQzzq7IdRKAnPm17P1y#scrollTo=R3uyyoRGOzSm
134

Lectures supplémentaires
- Clean Code (voir principes SOLID) : https://www.amazon.ca/-/fr/Robert-Martin/dp/0132350882/
- Awesome Deep Learning Resources : https://github.com/guillaume-chevalier/Awesome-Deep-Learning-Resources
- Résumé des principes SOLID : http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod
- Tell Don’t Ask : https://martinfowler.com/bliki/TellDontAsk.html
- Principes SOLID appliqués au Machine Learning et Tell Don’T Ask (TDA) : https://www.umaneo.com/post/the-solid-principles-
applied-to-machine-learning
- Structure orienté objet du framework Neuraxle à prendre en exemple :
https://www.neuraxle.org/stable/classes_and_modules_overview.html
- Comment tester unitairement du code de machine learning : https://www.neuraxio.com/blogs/news/how-to-unit-test-machine-
learning-code
- Une critique du code de programmation issu de compétitions pour usage commercial, liens avec les patrons de conception :
https://www.neuraxio.com/blogs/news/a-rant-on-kaggle-competition-code-and-most-research-code
- Refactoring de code d’apprentissage automatique : https://www.neuraxle.org/stable/intro.html
- Automated Machine Learning (AutoML) : https://www.youtube.com/watch?v=Ct2Lg0lOLoE
- Comment être un bon programmeur en intelligence artificielle : https://www.youtube.com/watch?v=02ydyb2RT0Q
- Concepts d’architecture logicielle propre en Python avec Jupyter Notebooks : https://github.com/guillaume-chevalier/How-
to-Grow-Neat-Software-Architecture-out-of-Jupyter-Notebooks
135

Thème: Python appliqué en
apprentissage automatique
(Machine Learning)
Cours #3/3
137

Les Savers
- Les savers permettent de traiter l’usage de steps normalement non-sérialisable
- Appliqués récursivement comme un apply lorsque demandé
- Une liste de savers permettent de retirer peu à peu des parties de l’objet
E.x. : https://www.neuraxle.org/stable/step_saving_and_lifecycle.html

Producer-Consumer
Producer Consumer
Queue

Producer-Consumer
Producer
Producer
Producer
Consumer
Consumer
Consumer
Queue

Pipelining parallèle
SequentialQueuedPipeline([
# (n_workers, step)
(1, F()),
(1, D()),
(1, E()),
(1, W()),
])

Step 2
Producer-Consumer
SequentialQueuedPipeline([
# (step_name, n_workers, step)
(3, Step1()),
(5, Step2()),
(3, Step3()),
]
max_queued_minibatches=64
)
Produc
erProduc
er
Step 1
Consum
erConsum
er
Step 2
Queue
Consum
erConsum
er
Step 3
Queue Joiner
Queue
Step 2
Queue

Ainsi :
153
BaseStep
-> Pipeline
-> MinibatchSequentialPipeline
-> SequentialQueuedPipeline
https://www.neuraxle.org/stable/api/distributed/neuraxle.distributed.streaming.html

PyTorch dans Neuraxle
- Adapter design pattern:
- Doit avoir un step qui adapte le nn.Module utilisé
- Rappel: ce nn.Module utilisé peut lui-même contenir d’autres nn.Module
- Fournit un saver (idéalement)

PyTorch avec Neuraxle
https://colab.research.google.com/drive/1747hG8ZKqNu9Gzh6K
dbvLKAb_jffq8ZY#scrollTo=xgykEd1D3UpK

TensorFlow dans Neuraxle
https://github.com/Neuraxio/Neuraxle-TensorFlow

Python appliqué en apprentissage automatique (Applied Python in Machine Learning)

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Ähnlich wie Python appliqué en apprentissage automatique (Applied Python in Machine Learning)

Ähnlich wie Python appliqué en apprentissage automatique (Applied Python in Machine Learning) (20)

Kürzlich hochgeladen

Kürzlich hochgeladen (6)

Python appliqué en apprentissage automatique (Applied Python in Machine Learning)